IRC channel logs


back to list of logs

<kmicu>They are not so important in libre world. Kernel has mitigations too. More details in the linked presentation.
<kmicu>(Unless we suspect that Emacs (or any other libre software) uses Metldown to hack us.)
<gnstaxo>Where can I buy a wifi card libre?
<kmicu>(OTOH if we don’t use IceCat and run random proprietary (js) code on our machine then yes, there's a risk.)
<kmicu>gnstaxo: IIRC the cheapest one is from
<nckx>I buy mine from 'local' (the joy of living in a tiny country is that everything's local) second hand shops & Web sites.
<gnstaxo>How will they deliver it to me?
<gnstaxo>I'll do a search on FB's marketplace...
<kmicu>A second‑hand option is nice though we must know which revision of TP-Link dongle to buy. Newer versions are Relteak based.
<nckx>Like most Web shops in the world today Olimex ships their products to you, although their FAQ states you're welcome to pick it up at their offices in Bulgaria too.
<nckx>kmicu: True, and the number of sellers who just Google $model_number and paste the manufacturer blurb instead of checking the label can be frustrating.
<kmicu>Exactly. Without a safe return policy or checking in person buying TP-Link is risky though very cheap ~6$.
<kmicu>(Which is very little for an air-gapped‑on‑demand libre laptop. Business pays fortune for such high‑security solutions 🤭)
<nckx>...the paper trail of which immediately signals the closest TLA that this is the shipment to intercept and modify.
<nckx>Your solution is probably safer.
<kirisime>I have a java application that attempts to load libX11 from glibc's store path. Is it simply because the application wasn't built against guix or..?
<apteryx>does anyone know what are the 'module-import-compiled' derivations? It seems I'm compiling the same modules multiple times for different 'module-import-compiled' derivations.
<apteryx>I guess they are the imported modules used with Gexps, but I find it weird that they treat the same files as different compilation units.
<apteryx>nckx: o/ Good to see you here.
<efraim>I bought my wifi stick from ali express #Aliexpress US $7.51 7%OFF | WTXUP for Atheros AR9271 150Mbps 802.11n Wireless WiFi USB Adapter Wi Fi Dongle internal Antenna Soft AP for Windows7/8/10/Linux
<efraim>Wow, what an obnoxious copy/paste they gave me from the app
***modula is now known as defaultxr
<colemickens>Is there maybe a "Guix System for NixOS users" table/article/etc?
<colemickens>Also, is there a Home-Manager equivalent for Guix System (or features that make it unnecessary)
<NieDzejkob>yeah, there is a home manager channel
<Gooberpatrol66>can I just keep a manifest for all packages in /etc/config.scm?
<colemickens>No Guix wiki? Is that a consciouce choice? is there somewhere else that someone might make notes that they think are useful to others beyond silo-ed blog posts?
***apteryx is now known as Guest15789
***apteryx_ is now known as apteryx
<kmicu>colemickens: that's by design.
<colemickens>kmicu: by design I should use libreplanet, or everything should go in the manual, or something else?
<kmicu>There’s no official wiki by design.
<efraim>we have the cookbook for shorter bits
<kmicu>There’s manual and if you want contribute something.
<kmicu>efraim: thank you for pointing out Ali (and Taobao) option. I completely forgot about it. That can be a good and cheap option too.
<efraim>On one had I don't want to take business away from technoetical, on the other hand it was less than $10 with shipping
<dftxbs3e>hey, I'm getting a 'mmap(PROT_NONE) failed' error during GNU Guix `make`, any idea what could cause it?
*kmicu is not very fond of that business model so I don’t mind.
<dftxbs3e>to reflect on the previous error, even though I had well enough RAM and swap, reducing the concurrency from 8 to 4 fixed it. I have 8GB of RAM and 4GB of swap.
<dftxbs3e>The RAM usage was just below 2GB when the error occured
<dftxbs3e>occurred *
<efraim>cbaines: we could also just skip the parallel-tests on subversion only on some architectures
***jonsger1 is now known as jonsger
<dftxbs3e>getting weird errors bootstrapping GNU Guix on IBM POWER9 ppc64 (big endian): -- seems like bootstrapping with GNU Guile 2.2 is largely untested and I do not know how to build bootstrap binaries with GNU Guile 2.0 instead here
<dftxbs3e>this happen when running `guix build hello` on -- branch is patched with bootstrap binaries built from master as well.
<efraim>dftxbs3e: When I last tied on 32-bit PPC I set GUILE_SYSTEM_COMPILED_PATH to "" and exported GUILE_AUTO_COMPILE=0 but that didn't quite fix it for me
<efraim>plus my hardware was really slow
<dftxbs3e>efraim, okay, I'm on speedy hardware this time, Talos II. I'm about to run the GNU Guile test suite right now, maybe it has issues on big endian systems
<efraim>possibly, but I think more likely there's an issue on the cross-built static guile
<dftxbs3e>efraim, even with good 4Ghz single threaded performance, interpreting GNU Guile Scheme without bytecode seems to be just **very** slow.
<vits95>Not important: If somebody know why `sudo echo NUM > /sys/class/backlight/SOME/brightness` doesn't works; but runningh `sudo` works?
<efraim>You have sudo echo, you want 'echo NUM | sudo tee /sys/...' I'm pretty sure
<alextee[m]>if i want to add a new package and then add it as a dependency to an existing package, should i send 1 patch or a patch series?
<alextee[m]>actually nvm i'll send the other patch for the other package later
<alextee[m]>why is libyaml in web.scm?
<alextee[m]>i'm packaging another yaml-related library and wondering where to put it
<alextee[m]>put it under libyaml for now
<vits95> "Thereonce was a tall man from Ealing..." great piece.
<scmguru`>Good morning, all.
<scmguru`>What's up, vits95?
<vits95>Summary: Didn't understanded how to set up udisks for hdd APMs. Setted-up a sway, a qutebrowser and a kitty. USB-tethering mostly useable. Thinking to connect to tor due to routing issues.
<vits95>Also i did `fc-cache -r`. It and deleting of the user profile allowed me to look at IceCat. Also in sway, if old i3wm configs present in ~/, qutebrowser possibly doesn't start. But now the everything works.
<nckx>apteryx: \o Same.
<nckx>vits95: Background: redirection is handled by the shell. What ‘sudo echo foo > bar’ does behind the scenes is: 1) your current shell sees ‘> bar’ and opens bar, as you 2) then launches ‘sudo echo foo’ (note that ‘>’ is already gone at this point) 3) echo runs as root and writes ‘foo’ to the file descriptor it got from the shell. If bar isn't accessible to your user, step 1 already fails, your sudo comes far too late and has no relevant effect.
<apteryx>eh, we have a 'nintendo-nes-classic-edition-installation-os'. Can Guix really be installed on such target machine?
<nckx>apteryx: At the risk of stating the obvious: …yes?
<apteryx>:-) I'm just morning-baffled. Thanks.
<vits95>Thanks, nckx.
*apteryx probably meant gobsmacked, but isn't a native English speaker ;-)
<apteryx>Shouldn't 'dmesg' be setuid or something? It needs root to work, which is not typical.
<bricewge>Hi Guix!
<bricewge>When should one use an origin snippet versus adding an additional phase that patches the source?
<vits95>apteryx: ?
<bricewge>apteryx: Maybe a polkit rule is better security wise.
<apteryx>bricewge: My opinion: source snippets when you want to remove files that don't need to be there (bundled software) or that pose a freedom issue, phases for the rest.
<zimoun>janneke: bug#39575 should hurt the time-machine. Maybe 1100+ commits are broken because of the upstream in-place change of the sha256. Ouch!
<janneke>zimoun: i "like" it you found that even --help breaks :-/
<bricewge>apteryx: Ho yes, I remember reading something of that effect about not letting non free code on a user machine when she was building from sources; to respect the FSDG.
<janneke>zimoun: this is pretty bad, afaiu an evil upstream could dos our time-machine
<zimoun>janneke: yes, it sounds bad, really bad.
<zimoun>janneke: maybe we could try to recreate this tarbal and push it to SWH and add a mechanism to fallback to SWH when there is a hash mismatch.
<bricewge>apteryx: The issues about dmesg
<janneke>zimoun: that could work
<smithras>zimoun: can software heritage store different versions like that?
<smithras>I mean differing copies with the same official "version"
<zimoun>smithras: I do not know.
*janneke has to go afk for a bit
<zimoun>let raise the issue on guix-devel and confirm that the diagnostic is correct
<apteryx>Hmm, I've generated my own installer image, and I'm now getting 'failed to resolve partition "1970-01-01-19-49-46-83"' upon trying to boot.
<apteryx>It works using the online available Guix install image.
<nckx>apteryx: The point is to disallow non-root users from viewing the kernel log (whether or not this is ‘not typical’ is debatable — it's actually quite common today, and this was an argument to do so in Guix); setuid would negate that. I don't know what polkit does but it's probably a better idea.
<apteryx>nckx: OK, thanks for explaining. I don't know much about polkit, but I'll look it up when the itch grows ;-)
*apteryx about the boot problem; it's my own causing. Testing Btrfs subvolume patches.
<nckx>apteryx: AIUI Linus/the Linux people don't want to remove information leaks like (ASLR'd) memory addresses from the kernel log ‘because that would hurt debugging’, so distros felt they had little choice but to make it a privileged operation. For the same reason, we should probably make /var/log/messages root/wheel-readable as is already the case with journald.
<nckx>apteryx: Did the system tests pass?
<bricewge>apteryx: Argh, you mean v2 of #37305 doesn;t works on your system? I wanted to try it myself.
<apteryx>nckx: yeah :-/
<apteryx>I don't understand why
<apteryx>Perhaps the installer os has some weird way to address its root disk, but I can't reproduce at the REPL, because (current-source-directory) is broken in Geiser.
<apteryx>(which is used by the local-file gexp)
***chipb_ is now known as chipb
<apteryx>just checked: the device is #<file-system-label "Guix_image">
<apteryx>so root in linux-boot.scm around line 544 should be #<file-system-label "Guix_image"> for the installer image.
<nckx>apteryx: Oh, not the answer I was hoping for. That's a dangerous hole in our test suite.
<apteryx>nckx: is it?
<nckx>No? I think so.
<apteryx>So I don't really know where that Guix_image file system label got turned into a "1970-01-01-19-49-46-83' time stamp.
<apteryx>I thought our installer tests generate the installation disk, then install a machine from it, then boot that machine. That should cover that use case, no?
<apteryx>i'll retry with origin/master to make sure it's my changes causing the breakages (likely).
<civodul>apteryx: "1970-01-01-19-49-46-83" is an ISO-9660 "UUID"
<apteryx>I think I've broken the ISO uuid
<civodul>it's computed in (gnu system vm)
<apteryx>it used to do raw uuid_string_var -> to bytevector -> uuid->string 'dce, now my routine was simply doing (uuid->string uuid_string_var)
<apteryx>for some reason the installation tests didn't flag that
<apteryx>my suspect code is in (gnu system), for the bootable-kernel-arguments. I'll try from the REPL to see the results it gives.
<apteryx>civodul: thanks for the info!
*apteryx confirms origin/master is ok, and my branch broken ;-)
<bricewge>sneek: later tell divansantana: Missing OS list in virt-manager should be fixed in #39579.
<sneek>Will do.
<shader>any comments on using kubernetes on top of guix, or guix instead of kubernetes for deploying decentralized applications?
<shader>I feel like the hpc stuff should cover some of that, but I haven't seen much on it
<civodul>shader: i'm not familiar with kubernetes but it seems that there's "something" to be done with both tools
<civodul>i don't see kubernetes being used in HPC, though
<atw>I would eventually like to try generating Docker images with Guix and then running those on Kubernetes. Right now it's just an idle thought though.
<shader>civodul: yeah, it seems that most of the hpc clusters use other job management utilities
<civodul>shader, atw: it may be worth starting a discussion on help-guix
<civodul>there are probably others who've been thinking about that
<bandali>hey folks, so uh, how many more decades before libreoffice becomes available on the official substitute server again? :p
<bandali>i'm, in a way, stuck not being able to upgrade because i have icecat and libreoffice in my default profile manifest
<apteryx>bandali: perhaps an interesting time to try out inferiors :-)
<atw>what are inferiors?
<bandali>apteryx, ha, what are inferiors?
*bandali goes looking in the manual
<bandali>very cool. next natural question is, is there a quick/easy way of finding the latest commit *before* a package has to be rebuilt? especially when one of the package's dependencies have changed, as opposed to an easily noticeable version bump in the package itself
<bandali>hmm, any way to use inferiors with specifications->manifest ?
<bandali>(rather than using packages->manifest and mapping specification->manifest over a list)
<apteryx>bandali: at this point you're starting to know more than I do about inferiors :-)
<apteryx>I reckon seeing something about manifests and inferiors in the manual, but you must have seen this already.
<bandali>ah hehe; yeah
<apteryx>is there a shortcut to import a module at the Geiser REPL? I know ,use, but that "switches" to the module, loosing bindings I had active. I want something like (use-modules (x module)).
<dftxbs3e>efraim, looks like you were right, the statically linked binary itself is broken. Trying to run in REPL mode results in a segfault. Troubleshooting the issue now.
<apteryx>I think we should recommend bs=4M or bs=8M in the manual to dd the installation image to a flash device... it's much faster.
<dftxbs3e>apteryx, personally, I just use GNOME Disks to 'Restore images' to devices -- the speed with the varying block size depends on the hardware
<apteryx>4M is very typical for flash chips
<dftxbs3e>apteryx, maybe there's a way to query for such cache size
<dftxbs3e>or make a quick stress test before flashing
<apteryx>I think it has to do with the size of a "page" more than cache. Flash devices typically write 4 MB at a time, no matter the size of the write. So it's just much more efficient to write to it using chunks of 4 MB.
<nckx>Disappointing that the OS cannot even (apparently) coalesce blocksized writes arriving in a perfectly linear manner :-/ What hope do other workloads have.
<apteryx>correction; writes 4 - 16 KiB in size, while erasing is multiple pages and MBs at a time.
<alextee[m]>is someone free to merge ?
<noobly>if i plan to install libreboot with full disk encryption later, there's no need to do it during the guix install, right?
<efraim>dftxbs3e: I think I tried x86_64 -> i686 bootstrap binaries and didn't have the segfault issue. I wonder if it could be a little-endian -> big-endian thing
*efraim makes this suggestion by pulling words out of a hat
<dftxbs3e>efraim, I wonder the same, I've asked in #guile already
<efraim>it sounds plausible, but I wonder if it could also be a guix thing
<efraim>I thought most people were running their Talos in little endian mode
<nckx>apteryx: In your NFS patch, ‘Fixes #nnn <external link>’ should just be ‘Don't try to validate [or whatever] network file systems’ or something. Keep it simple 🙂
<nckx>I'll probably need to add (multi-device) bcachefsen to that list but the wording can be adjusted later.
<dftxbs3e>efraim, little endian suffered a double format change which breaks bootstrap, it's actually easier to bootstrap GNU Guix on ppc64 big endian because of that, so I'm just trying it here.
<dftxbs3e>There's ppc64 big endian distros such as Adelie Linux, Void Linux or CentOS 7
<efraim>I didn't realize Adelie went big endian
<nckx>Well fuck. So I chose the wrong endianness?
<nckx>dftxbs3e: What's the ‘double format change’?
<dftxbs3e>nckx, you didnt choose the wrong one, little endian is preferred (at least for me), I'm just trying to get something that works right now.
<nckx>dftxbs3e: All right, and good luck.
<dftxbs3e>nckx, the amdgpu driver for example is largely untested on big endian
<dftxbs3e>and that driver is quite important to a modern desktop experience
<dftxbs3e>But anyways, Linux-libre wont provide firmware for the AMD card
<dftxbs3e>llvmpipe's swarst will be used instead then
<efraim>i reverted 8aaf42c037584aa823339180b6e9cdada361bbcf and i'm now trying downgrading the bootstrap guile to 2.0
<efraim>(locally of course)
<dftxbs3e>Ah cool! Thanks a lot
<dftxbs3e>nckx, this explains everything:
<dftxbs3e>There's a change in both GLIBC and GCC
<dftxbs3e>The change only becomes transparent from GCC 9
<dftxbs3e>Otherwise you'd need to add additional compile time flags for things to work properly
<nckx>dftxbs3e: Hm! Thank you! I did try GCC 9 (I tried ‘everything’), maybe I should keep poking that way…
<nckx>Since I don't currently care about GPUs at all.
<dftxbs3e>nckx, I'm really desperate :S
<nckx>Sure, I understand, this is all an adventure for me but I don't have an expensive machine depreciating under my desk.
<dftxbs3e>It's been so long I'm trying to *Just Port Guix*
<nckx>Just a free GPU-less VM.
*nckx will try more newer glibc/gcc combinations.
<nckx>Eh, WTF. ‘[VERY URGENT] GNU ideas for GSOC 2020’ ‘This should be done before this Thursday (yes tomorrow).’ OK.
<nckx>Is there someone handling Guix GSoC? I'm aware of .
<apteryx>nckx: oh, is it not desirable to keep track of closed issues #? The subject of the commit says what it's about already; unless I'm missing something :-)
<nckx>apteryx: If it's a large and complex issue or the fix was hard to nail, perhaps, but sprinkling #s around the code doesn't really help track anything.
<nckx>Even in that case I'd argue that if a link is needed, the comment is inadequate, but that's hypothetical.
<apteryx>ah, I understand, you are talking about the code.
<apteryx>I wholly agree then.
<apteryx>(I thought you meant in the commit message)
<nckx>One of the things that I love about Guix is that it understands what commit messages are and aren't, and ‘git blame’ is not an out-of-band comment machine (most other projects don't).
<nckx>apteryx: Oh, commit message is fine by me. I mean ‘comment’ as actuly ‘comment’, not simply ‘comment’. Happy to clarify 😛
<apteryx>Am I supposed to see a drive appear on UEFI systems?
<nckx>Where and when?
<apteryx>for UEFI, I'm supposed to mount some device partition to /boot/ufi, but there doesn't seem to be any drive that are exposed by the system (others than the one I know).
*apteryx is installing Guix on yet another machine
<dftxbs3e>efraim, so it has to be the cross compiled bytecode. Copying the bytecode from a Gentoo install worked
<efraim>so that'll be a fun problem to work out. How to compile its own bytecode first
<dftxbs3e>efraim, for now I'll just replace the bytecode in the archive lol
<nckx>apteryx: How familiar are you with UEFI? In general, your target drive itself should contain a small (5-100 MiB is common) ‘EFI System’ partition that is FAT32-formatted, and is mounted on [/mnt]/boot/efi. It will contain GRUB once you install.
<nckx> /dev/sda3 99M 398K 99M 1% /boot/efi
<apteryx>I see! I have to host this partition on one of my drives. As you can tell, I don't know much about UEFI.
<apteryx>nckx: nfs patch updated
<nixo_>Hello guix! I just tried guix offload, it's so cool! I thought "The other machine is on a different version, it will need to download/build a lot of stuff.." in the meanwhile it started sending 200Mb from my machine. Really really impressed on how cool it is
<nixo_>However, the setup is still a bit boring, maybe something like ssh-copy-id would help!
<apteryx>nckx: Can the 'EFI System' partition live on a LUKS encrypted device?
<apteryx>I guess not... the magic used to be the MBR that could host enough of GRUB to decrypt the disk before loading more of itself /boot/grub, IIUC.
<nckx>apteryx: No. Your UEFI ‘BIOS’ has to read it, and it looks for a FAT32 partition of the right type, nothing funky.
<NieDzejkob>(but /boot itself can be encrypted)
<nckx>The EFI partition is a huge-butt extensible MBR that is shared amongst all OSes.
<nckx>If your / is encrypted, /boot even must be, because Guix doesn't support a separate (unencrypted) /boot yet.
<nckx>apteryx: Nowadays, firmware loads /boot/efi/EFI/Guix/grubx64.efi from FAT, then starts it. Then GRUB asks you for the passphrase, uses that to decrypt /, loads modules & grub.cfg from /boot, then loads & boots the menu entry's kernel + initrd from /gnu.
<NieDzejkob>funny thing, my firmware refuses to load /boot/efi/EFI/Guix/grubx64.efi and insists on /EFI/BOOT/BOOTX64.EFI
*nckx should've written /EFI/Guix/grubx64.efi at that stage but you hopefully get the point 🙂
<nckx>NieDzejkob: Oh, yeah, that's hilarious, I have a similar machine.
<nckx>There are even machines that hard-code ‘Windows boot manager’ as name 😒
<NieDzejkob>smh my head
<nckx>OEMs: hold our beers.
<dftxbs3e>efraim, worked after replacing the bytecode in the bin and updating 2.0 to 2.2 in paths for guile
<dftxbs3e>at least, for the guile part
<dftxbs3e>waiting for the rest
<dftxbs3e>in bootstrap.scm, the paths
<efraim>dftxbs3e: nice! of course it can't be upstreamed like that but it's good to know where all the problems are
<nckx>apteryx: That said, while knowing how your system boots is in your best interest, if the manual doesn't walk you through every single step without knowing it should be improved. Installation time is not the time for learning interesting background.
<efraim>dftxbs3e: the guile-2.0 bootstrap binaries I just built and copied over to my G4 worked when I ran 'guile --version' and 'guile --help'
<dftxbs3e>efraim, cool! want to commit this?
<dftxbs3e>did you build from amd64?
<efraim>yeah, from amd64
<efraim>i'm going to copy them over to my local box and then up to my server and try them out on my G4
<dftxbs3e>G4 is ppc 32bit or 64bit?
<dftxbs3e>efraim, maybe it's a good idea to ask nckx for a user on the OSUOSL machine
<nckx>I wonder if I could split up the pool into an LE and BE VM. Unlikely.
<dftxbs3e>nckx, if nested virtualization is enabled then yes. You can probably ask them for such
<nckx>‘Bootstrapping’ in the lowest sense is done (, it's ‘commencement’ that's currently stuck.
<nckx>dftxbs3e: I think I asked for all the whistles, I'll take a look, thanks.
<efraim>when they finish uploading my binaries will be here:
*efraim thought it was the 13th
<NieDzejkob>well, it's probably right in at least one timezone ;)
<nckx>alextee[m]: OK.
<Gooberpatrol66>I put something in config.scm that depends on a channel. If I run sudo -E guix system reconfigure /etc/config.scm, it can't find the channel specification. i have to do su and then run it from a root shell.
<dftxbs3e>OMG! The long double incompatibility also happens on big endian for some reason.. it really shouldnt... *dies out of despair*
<nckx>[Fully sympathetic] sadtrombone.flac
<dftxbs3e>GCC expert needed urgently
<nckx>alextee[m]: This will take a while, for some reason we're now building git and its interminable test suite.
<alextee[m]>nckx: no worries, thanks for looking at it !
<nckx>Lol. TIL git am --scissors.
<dftxbs3e> /gnu/store/k5x0z0y65yhpi8479jl628n6hm14l47k-binutils-bootstrap-0/bin/ld: .libs/compatibility-ldbl.o uses 64-bit long double, ../src/c++98/.libs/libc++98convenience.a(complex_io.o) uses 128-bit long double
<efraim>dftxbs3e: something seems to be going right, I'm still building. Looks like switching bootstrap-guile to 2.0 was the key
<efraim>can you bootstrap 64-bit from my 32-bit binaries? :P
<dftxbs3e>efraim, I already have bootstrap binaries over here, but yes ppc is backwards compatible
<dftxbs3e>what doesnt work is `guix build hello` with the bootstrap binaries
<dftxbs3e>it fails to build /gnu/store/nj27mfy3zx396662xy065ipgxnm4cvg1-libstdc++-boot0-4.9.4.drv with the error I sent above
<nckx>dftxbs3e: So this is different from the (sigh) classic --with-long-double-128 issue?
<efraim>what if you switch libstdc++-boot0 to use gcc-7
<dftxbs3e>nckx, BE shouldnt need this flag.. but I just added it and trying to see..
<dftxbs3e>same issue
<dftxbs3e>efraim, trying..
***ChanServ sets mode: +o nckx
<dftxbs3e>efraim, succeeded it seems
<efraim>dftxbs3e: nice. iirc it's really there for bootstrapping from earlier gcc versions
<dftxbs3e>seems like simplet/samplet (don't remember what their name was) doesnt join in here anymore
<dftxbs3e>and now.. the header issue
<dftxbs3e>efraim, ../../gcc-7.4.0/gcc/system.h:488:14: error: conflicting declaration of C function 'void* sbrk(int)'
<dftxbs3e>AFAIK it's due to conflicting libstdc++ version..?
<nckx>Eyy, that looks familiar.
*nckx AFK tho ☹
<dftxbs3e>nckx, could you solve it?
<dftxbs3e>it's the same issue I was stuck with on little endian actually..
<dftxbs3e>so it's ALSO on big endian
<nckx>dftxbs3e: Can't say now :-/ I'd need to check my notes, which are on another machine than the one I do all the power9ing on because I am a genius™.
<dftxbs3e>nckx, alright!
<apteryx>some part which is confusing is that label doesn't work for LUKS, nor fat32, but UUID does?
*** sets mode: +o ChanServ
<sirgazil>I'm trying to install a package that uses an SSH authenticated repository. The package is defined in an SSH authenticated channel as well. I get this error:
<sirgazil>error: cannot run ssh: No such file or directory
<sirgazil>Full error:
<sirgazil>For what it's worth, here is the package definition:
<apteryx>sirgazil: there's no authentication support in Guix proper currently. There was a discussion to allow using a users SSH key IIRC, but that kindof goes against what Guix stands for (purity of builds, reproducibility).
<apteryx>(for fetching source code, that is)
<sirgazil>apteryx: In a previous pull, I read that there is support for SSH authenticated repositories now. Actually, my private channel works, but this particular package fails to build with that error.
<rekado_>oof, another GWL release obstacle: call-with-container doesn’t always work!
<rekado_>it’s really puzzling: I’m listing all directories that should be mounted in the container but for *some* invocations this doesn’t work.
<rekado_>the directories appear but they are empty!
<rekado_>I wonder if that’s a problem with my kernel, a problem with the number of bind mounts, or something else.
<apteryx>sirgazil: I see! Thanks for the heads up.
<apteryx>sirgazil: about the error, I'm not sure. Is it using special features of SSH?
<rekado_>also weird: the *same* unchanged file using call-with-container *sometimes* works
<rekado_>this points to runtime problems
<sirgazil>apteryx: the packaged program? It doesn't use SSH.
<apteryx>sirgazil: I have to read up; I was thinking depending on how the authentication is defined (~/.ssh/config) ? There might be SSH options there or something that guile-ssh (I guess that's what is used) can't handle yet.
<sirgazil>Ah, I see...
<apteryx>nckx: I'm confused as to the exact mount location of that EFI system partition; /mnt/boot/efi vs /boot/efi? The latter probably wouldn't fly on the installer, so I'm guessing the earlier... But my config says it should be mounted at /boot/efi. Hm.
*apteryx tries /mnt/boot/efi
<apteryx>seems to have worked!
<apteryx>bricewge: I've hit issues in the installer, and due to some other place in file-systems->fstab that expects strings but now we have alists, so a file-system-options->string call is missing there.
<apteryx>(about #37305 v2) also when using the installer, my generated grub.cfg didn't have the prepended submodule path, as it should be...
*apteryx is investigating
<apteryx>how can I bulid a <computed-file> object?
<apteryx>I tried lower-object, then ,run-in-store -> I get some derivation, like: $6 = #<derivation /gnu/store/w11f2vnficj3r471hllf33k1gmi4y8g0-grub.cfg.drv => /gnu/store/q1211g5w10cjn35imdb8czr5cz39psrc-grub.cfg 7fd7ad544230>
<apteryx>ah, nevermind, it actually worked to build that derivations :-)
<rekado_>oh, interesting: the problem with call-with-container only happens when “.” is among the mounted directories.
<janneke>i'm trying to run screen to connect to a pinebook pro; any idea what /var/run/utmp: No such file or directory means?
<janneke>should i be adding/running a service?
<janneke>hmm, maybe i'm connecting screen to the wrong usb?
<theruran>I am trying to guix pull or guix pull --bootstrap and they both fail. On the bootstrap, I get the error: "ERROR: In procedure dynamic-pointer: Symbol not found: strverscmp" on building module-import-compiled.drv :(
<theruran>this is a fresh store. I have only been able to build `hello' so far
<theruran>and using the default savannah channel just ends up with HTTP 404, 550, 404, and timeout on the linux-libre package
<wheeler>Having some issues with X11 dependencies while packaging flpsed.... libx11 is there in native-inputs but I'm getting "Error: not found" in the build. Any ideas?
<bavier>wheeler: would probably be more appropriate for "inputs"
<nckx>apteryx: Like your root is /mnt during the installation but / everywhere else, it's /mnt/boot/efi during the installation.
<nckx>I.e. you might have been overthinking it…? 🙂 I'm glad it worked out.
***ChanServ sets mode: -o nckx
<bavier>anyone else get error on 'guix show choqok'?
<theruran>bavier: yeah, "guix: show: command not found"
<bavier>weird, wonder what the issue is; maybe parsing the description? idk.
<theruran>is guix supposed to be hiding its version? guix --version just give me the f'ing license notice
<nckx>theruran: What's the first line?