IRC channel logs


back to list of logs

<nckx>OK, so creating a cpio archive at evaluation time is trivial thanks to (guix cpio). Not really worth writing a helper for that 😛 It's about ~5 lines in your system.scm, the only vaguely tricky part is stripping leading directories from the key file name.
<nckx>opalvaults2: I had never heard of Star Labs! Thank you.
***nf is now known as nfir
***nfir is now known as sapinf
***sapinf is now known as nfir
<opalvaults2>nckx: me either, glad you found it helpful. :)
<nckx>Now 'f only you'd told me pre-brexit.
<Aurora_v_kosmose>nckx: Nginx in cache-mode turned out to be both relatively simple to setup and works nicely, thanks for that recommendation.
<KE0VVT>I have heard there is an issue with getting Plasma. What is the issue?
<nckx>I'm glad it worked. ‘Relatively’ is the right word but from what I've heard, dedicated HTTP caching software isn't much easier to configure correctly.
<KE0VVT>Not that I personally care about Plasma. I love GNOME.
<KE0VVT>A shame the UK Dvorak keyboard layout cannot do curly quotes.
<KE0VVT>Or arrow symbols.
<Aurora_v_kosmose>nckx: Squid's the only other one I've really tried (since it's one of the few FOSS ones), so I can only speak for that one. It's pretty easy for plain HTTP, but http->https reverse proxying requires you to get creative with things its documentation doesn't quite come out and say you can do.
<Aurora_v_kosmose>(Abusing its peer cache setup, mainly)
<Aurora_v_kosmose>Nginx is about as complex to setup, but it is much clearer about the fact you can do so and that it's a supported configuration.
<Aurora_v_kosmose>Well, I could talk about apt-cacher-ng... but it's not a general-purpose forward/reverse proxy program, so it doesn't count.
<nckx>Oh, I'd never heard of the latter.
<Aurora_v_kosmose>It was originally made specifically to support the package repositories for Debian-style Apt packages. It also understands their structure so it can do some smarter cache management when things disappear from indexes & so on.
<nckx>Something like that for Guix would be nice to avoid the cached-narinfo-with-missing-upstream-nar problem, which I currently work around by caching narinfos for a relatively short time.
<nckx>Yeah, sounds like the same issue.
<Aurora_v_kosmose>But support for other repository types (like Arch's) has to be added separately (which it has, but I hear Fedora package support is flaky).
<nckx>(Another work-around is simply never to GC :)
<Aurora_v_kosmose>Works out better for slow-moving distros than fast like Guix.
<Aurora_v_kosmose>nckx: What kind of instruction did you use for the narinfo exception?
<Aurora_v_kosmose>Separate caches for / and /nar paths?
<nckx>Here's my (embarrassingly messy :-/) partial nginx configuration:
<nckx>Separate caches indeed.
<nckx>Don't worry, most of it is fluff.
<nckx>Like, I care about HTTP header size. Sane people don't.
<nckx>Oh, and $dollar is a stupid hack at the http{} level: geo $dollar { default "$"; } #
<Aurora_v_kosmose>heh, a hack indeed
<Aurora_v_kosmose>nckx: Thanks for the config. The location matches will be quite helpful.
<nckx>You're welcome. Looking at it now, it needs a good clean-up, I no longer connect to the world's most unreliable wi-fi network.
<raghavgururajan>nckx: Last known good commit is e5e307b6768088e35be0c7526f25a3e16d93c242. Right after that it fails.
<nckx>But we don't believe that, do we ☺ (Look at the commit.)
<raghavgururajan>Yeah, not sure how BIND is related to this.
<nckx>To quote an earlier me: raghavgururajan: Bisection only makes sense for reproducible failures (the result of bisecting transient failures is simply random).
<nckx>This simply appears to be an unreliable failure.
<raghavgururajan>I did --check
<nckx>Let me think.
<nckx>There's a ‘hidden’ dependency on BIND through isc-dhcp, which won't show up with e.g. ‘guix graph’ because it's not a real package.
<nckx>Buuut… 4ca0e9 doesn't update that BIND, the next commit (37186e) does.
<nckx>So I'm still a bit confused: if this is to blame, 4ca0e9 should be good, 37186e bad.
<nckx>It's still suspicious to say the least.
<nckx>(Regardless, bisecting is a valuable skill, so it's good you practiced :)
*nckx busy.
<raghavgururajan>Oh wait. I must have the commit mixed. I did try e5e307b and it passed. After that I must have tried 37186e, thinking that its 4ca0e9.
<raghavgururajan>I tries 4ca0e9 and 37186e again.
<raghavgururajan>I did the bisecting manually.
<raghavgururajan>process of elimination.
<raghavgururajan>nckx: Yep, last known good commit is 4ca0e9. Commit 37186e and one after that fails.
<raghavgururajan>I checked the bash history. I indeed used 37186e which failed, but read the commit message of 4ca0e9 in the browser.
***jonsger1 is now known as jonsger
<sozuba>Hi, any idea of parameterized packages is implemented yet?
<sozuba>I've spent the past few days reading a lot about Guix and, i not only love it, but for some reason feel proud (may be because i've shunned windows for a while now?). I wanted to move back to source based linux and was looking at different options and in a way guix seems awesome. I love  gentoo's use flags and profile settings where i choose to
<sozuba>biuld my systems with only specific functionalities of packages, for example -X.
<nckx>There are package transformation options which are vaguely related, but not parameters like ‘no X please’.
<sozuba>nckx, okay, thanks :)
<sozuba>i want to build a very specific and customized build for my machine.
<sozuba>looks like i have to wait. Thanks
<nckx>You can customise packages, for example by inheriting from Guix's version and modifying #:configure-flags and inputs &c. There just aren't switches where the package authors do all that work for you.
<nckx>And it's a lot of work, so honestly, I think it makes sense.
<nckx>We shouldn't compete with Gentoo on what Gentoo already does best 😉
<sozuba>nckx, i very much understand. My point was not about competing with gentoo or any OS. It was purely based on requirements.
<nckx>I didn't mean to imply otherwise.
<sozuba>great :)
<nckx>Some form of parameterisation may well happen some day. I just wouldn't busywait on it, because that's been the case for years.
<sozuba>Yeah i was just checking the conversations on this topic over mailing lists, and it seems its been in discussion for a while now.
<sam_>nckx++ ;)
<nckx>Somebody's got their highlights covered :)
<sozuba>sam_ are you the same sam at #gentoo? :d
<sam_>the very same!
<sozuba>cool :)
<zamfofex>sozuba: I’ll note that the existing package transformation options are not completely useless. I use it to apply local patches to st, and it works really well for me!
<sozuba>sam_ are you using guix on gentoo?
<sam_>no, although I've been wondering about playing with it. Someone posted some interesting bits to and I've been quite tempted. I think the main thing I'm curious about is how to discover 'toggleables' for packages (basically like what you were describing)
<sozuba>zamfofex, yes I agree. But my use case is not much complex. I am not a big developer or programmer, while i do things mostly now and then. The requirements are due to me being paranoid? or extreme case of OCD, being a control freak (i mean in software terms ;))
<sozuba>sam_ cool I will check losste.rc. Yeah that would be a great boon. :)
<sozuba>I do like Guix shell (Guix environment), it's so cool.
<KE0VVT>Is Libreboot just slow, or will my system not boot? :(
<nckx>I'm sorry to say that on average it's faster than proprietary firmware.
<nckx>Plenty of people boot Guix System with it though.
<sozuba>I wish Libreboot would work on my chipset :(
*nckx had to settle for Coreboot which is still very nice.
<KE0VVT>nckx: My system crashed after a memory overflow, and I edited my /etc/config.scm without getting the chance to to do "guix system reconfigure". System will not boot.
<KE0VVT>nckx: Libreboot's payloads are jank. Normal computers have so much many more features in the firmware, and don't have issues booting things.
<drakonis>sam_: was it me on irc?
<nckx>The contents of the system configuration file don't matter if you didn't reconfigure with it.
<nckx>KE0VVT: Well, that's kind of the point. You're welcome not to like it but it's not ‘jank’.
<nckx>It's quite solid.
<drakonis>i don't believe anything too recent was published on lobsters
<nckx>In general more so than ‘featureful’ vendor firmware.
<KE0VVT>nckx: Libreboot can't boot as many things. It's irritating.
<nckx>You're misunderstanding what it is and does.
<drakonis>sam_: however, there's a fairly recent thing that got included, package tweaking for specific hardware
<drakonis>where it actually provides gains
<nckx>I.e., what won't Libreboot supposedly boot that doesn't itself require blobs?
<nckx>Nothing, I dare say.
<KE0VVT>nckx: Ventoy won't boot.
<drakonis>cpu tuning, that is.
<drakonis>this branch in particular is interesting
<nckx>KE0VVT: That's not… Libreboot's problem?
<KE0VVT>nckx: It's not like I'm booting Windows. I just want to run FreeDOS.
<nckx>Are you saying it won't boot with SeaBIOS?
<nckx>I really think you don't understand the nature of Libreboot.
<nckx>It's not a boot loader.
<KE0VVT>nckx: And my Guix system will not currently boot all the way with SeaBIOS or the [o] option.
*nckx doesn't know what the [o] option is.
<KE0VVT>nckx: I don't know, either. It's some crazy slew of GRUB commands that are baked into Libreboot. I have no clue how it works.
<KE0VVT>But it's slow on this version.
<nckx>Maybe it's a script that does some autoconfiguration magic in GRUB's shell-like scripting language, which is… not fast. But I'm just guessing here. But no, SeaBIOS boots Guix System just fine (/me waves from one), I think you're on the wrong debugging track.
<KE0VVT>SeaBIOS was booting my system just fine before. Now it won't.
<nckx>Then it's definitely not to blame?
<KE0VVT>I said this earlier.
<KE0VVT>The screen is just stuck at the Guix logo after selecting the OS in the GRUB menu.
<nckx>Then I wasn't around.
<KE0VVT>Just going to nuke and pave. :(
<nckx>I thought you didn't want to boot Windows ☺
<KE0VVT>I don't know what to do, when Guix just gets stuck at the Guix logo.
<KE0VVT>What? No Windows.
<nckx>What's ‘the Guix logo’?
<nckx>The GRUB background image?
<KE0VVT>That image alone. The GRUB menu is now gone. It just stays there. It's been there for what seems like ten or more minutes.
<nckx>So Linux boots, but then something goes wrong and there's no Linux display driver to print what it was.
<nckx>Try running ‘terminal_output console’ from the GRUB command line before selecting the menu entry to boot. If that alone doesn't help, try also adding ‘nomodeset’ to the kernel command line first.
<nckx>Not that reinstalling isn't allowed. It's up to you.
<KE0VVT>nckx: Guix GRUB or Libreboot GRUB?
<KE0VVT>So many GRUBs. WHY!
<nckx>Because you chose GRUB when flashing Libreboot?
<KE0VVT>nckx: GRUB is the default.
<KE0VVT>nckx: Complain to the people who set defaults.
<nckx>This is all user (well, admin/owner) choice, it's tiring to constantly read between your pointless Libreboot-bashing.
<KE0VVT>Bottom line: It makes my computer act weird.
<nckx>No, stop complaining, and ask for a full refund of what you paid for Libreboot/GRUB/Guix.
<nckx>Your current problem, at least, has nothing to do with Libreboot.
<raghavgururajan>KE0VVT: Could you share your config.scm?
<KE0VVT>What if I symlinked /etc/config.scm -> /home/caleb/Projects/dotfiles/config.scm?
<KE0VVT>If I did, I'd have a link for raghavgururajan. Right now, my system is kaput, so I can't.
<raghavgururajan>Does your libreboot has sea_bios only payload or grub+sea_bios payload?
<KE0VVT>GRUB+SeaBIOS raghavgururajan
<podiki[m]>/etc/config.scm is just a default from the installer I believe, otherwise nothing uses it, you specifcy when you run reconfigure
<raghavgururajan>I'll get back to you on how to boot manually.
<podiki[m]>it does get saved in the store in the system generation at that location though
<KE0VVT>podiki[m]: I might just keep config.scm in my dotfiles repo, then.
<KE0VVT>This is what my boot process looks like - [1] [2]
<nckx>I think it's time to merge
<nckx>2 people in 1 day can't be a coincidence.
<nckx>KE0VVT: Type your passphrase when you think it's ‘hung’.
<KE0VVT>Oh, so this is a known bug. Cool.
<KE0VVT>OK, will try typing passphrase.
<KE0VVT>Pressed Enter. Disk light flashed.
<nckx><What if I symlinked /etc/config.scm> Guix doesn't care about the name.
<KE0VVT>Screen flashed. Text appears.
<KE0VVT>I think it's hilarious that I see Failed: Success. lol
<KE0VVT>Oh, thank God, the system is up.
<nckx>We must never remove that, it would be too sad, it's a beloved tradition at this point. People would think something went wrong.
<nckx>Yeah, it was just waiting for your passphrase at the second prompt.
<KE0VVT>nckx: Where is your tip jar, for enduring my annoying noobness
<nckx>I wonder what changed in (presumably) Linux to make this happen more often recently.
<KE0VVT>nckx: Yeah, keep the "Failed: Success" line.
<nckx>KE0VVT: ☺ No tips needed, happy to help.
<nckx>(Let that explain my grumpiness earlier: I sympathise with your frustration, but it does rather suck the fun out of helping being its own reward. Still, sorry for letting it get to me.)
<nckx>raghavgururajan: The issue isn't ‘booting with Libreboot’, though, that works fine here (through SeaBIOS). There's a bug/regression with how (or if?) Linux detects coreboot's framebuffer, which needs its own driver to work before i915 takes over.
<nckx>5.15 reorganised and renamed all the relevant options :-/
<nckx>(Granted: partly to stop labelling them as ‘Google firmware drivers’, so that's good.)
<nckx>But it makes it hard to (1) port my old patch above and (2) find out if and where a regression slipped in.
<raghavgururajan>nckx: Ah I see.
<nckx>Your Libreboot guide has helped countless others though ☺
<KE0VVT>What Libreboot guide?
<raghavgururajan>nckx: Ah. I was gonna suggest booting from grub's command line? Not Guix's grub though.
<nckx>The problem is with our Linux-Libre, not GRUB, and it wouldn't matter which GRUB launched Linux-Libre.
<nckx>GRUB can drive the framebuffer just fine, which is why KE0VVT spent 10 minutes staring at a beautiful Guix logo!
<nckx>Why he isn't simply content with doing so all day is anyone's guess.
<nckx>It's pretty.
<raghavgururajan>KE0VVT: One of them is on libreboot site. But not compatible for this issue though.
*raghavgururajan goes back to eating french vanilla icecream
*nckx continues eating Belgian marzipan.
<bandali>hey nckx can i msg you?
<nckx>Sure, he said, dreadingly.
<bandali>ahaha thanks, it's nothing bad/serious, promise :p
<nckx>Then doubly so!
<bandali>yay ^_^
<KE0VVT>The auto-generated Guix Home configuration is very strange.
<raghavgururajan>Ah, so that's why I am not facing that issue. I am using 2016 libreboot which doesn't use corebootFB, instead uses vesaFB.
<raghavgururajan>KE0VVT: Are you using 2020/2021 testing release of libreboot?
<KE0VVT>raghavgururajan: 2021
<raghavgururajan>Okay. That makes sense now with nckx patch.
<nckx>guix build: error: gcry_md_hash_buffer: Function not implemented
<nckx>I'm just going to download the linux-libre source manually…
<nckx>Could someone running Guix from git on x86{,-64} test booting from <>? I can't, because $reasons.
<nckx>It should boot just fine, to be clear.
<jpoiret>hello guix, happy sunday :)
<efraim>hello guix!
<jonsger>nckx: so boot on a coreboot amd64 or a non-coreboot amd64?
<PurpleSym>Is anyone able to successfully install Guix on real hardware™ with cryptsetup? I tried the installer and manual mode, but I end up in a grub rescue shell, which has zero commands available.
<jonsger>PurpleSym: try to boot from an USB stick with a guix image and when the USB-Sticks GRUB starts type 'e'
<PurpleSym>Thanks, jonsger. Gotta figure out how to circumvent fast boot first to get into the BIOS.
<zamfofex>Quick question: Would it be reasonable for channels to be able to be specified from tarballs? (Either from URLs or locally.) Then ‘guix pull’ would simply read from the tarball instead of using Git. Locally, they could even be specified as a directory.
<PurpleSym>`cryptomount` just does nothing in the Grub shell.
<bricewge>Why is there a `postgresql-13` and a `postgresql-13.3` defined?
<bricewge>I'm updating the PostgreSQL packages, and was wondering if they were still needed
<bricewge>I mean the 13.3 version
<jonsger>PurpleSym: this bug has maybe some helpful statements
<vivien>zamfofex, how would guix pull know whether a new version of the channel is available? With a git repository, it is easy to know whether a new commit has been added.
<vivien>(without downloading everything again)
<zamfofex>vivien: It would just always download it. I think it could be useful for small channels. And also for local channels, of course.
<PurpleSym>jonsger: The problem right now is that `cryptomount` just does nothing at all. I’ll try a Debian live image. Should be easier to diagnose the issue that way.
<PurpleSym>Debian mounts the partition just fine.
<jpoiret>PurpleSym: is it a LUKS2 encrypted drive?
<Tekto>Hi Guix! I want to add the udev rules of "Ledger Nano S" to the guix. How can I do?
<PurpleSym>jpoiret: Whatever Guix’ installer used. I’ll check later. Is LUKS2 not supported?
<KE0VVT>Did I read the docs right, on how to add environment variables to Guix Home?
<roptat>tekakutli, you'll need a package that provides these rules, then you can add it to a udev-service in your configuration
<roptat>ah I didn't ping the right person, sorry
<luis-felipe>sneek: Later tell mothacehe thanks for pushing my patch :)
<KE0VVT>Whoa. I just realized how awesome Guix Home will work with Git branches!
<KE0VVT>Keep a stable home config for production, and develop an experimental setup in a branch. So cool!
<wigust>hi guix
<efraim>I wasn't sure it would work but I now really love ':Guix shell -D guix -- make' from inside vim
<jpoiret>PurpleSym: it depends. LUKS2 is not supported out of the box because GRUB doesn't handle it well enough
<jpoiret>if you have a /boot/ that is accessible from outside a luks encrypted partitions, it will work properly, but the installer's default config doesn't do it that way necessarily
<jpoiret>there was a small-ish commit window where it was enabled but didn't work, because i mistakenly thought it would
<jpoiret>you can know if it is the case on any distribution with `cryptsetup luksDump /dev/sdX`
<PurpleSym>jpoiret: Indeed, it says version 2. But the dev manual also says to use LUKS2, so I’m not sure what to do.
<jpoiret>uhm, yes, that's totally my bad. Let's say that right now, we're blocked by
<jpoiret>the installer on the most recent master commit should default to luks1
<jpoiret>and, there's an in-place luks1 to luks2 converter, so migrating once support is better should be no problem
<jpoiret>i could add a warning about this issue to the manual
<PurpleSym>Okay, I’ll try the manual installation method with luks1 then.
<PurpleSym>How does the unencrypted /boot work?
<PurpleSym>Just mount a partition and done?
<jpoiret>well, you just have an additional unencrypted partition for /boot
<jpoiret>if you're on EFI, there's a cleaner way
<PurpleSym>Yep, it’s EFI.
<jpoiret>my setup is: mount the EFI partition on /esp, bind mount /esp/EFI/Guix to /boot, and install the bootloader to /esp
<jpoiret>you're just reusing the already existing EFI partition that way, and the grub files are neatly stored inside the EFI/Guix/ subdir
<jpoiret>the issue is that on non EFI you cannot do that anyway
<jpoiret>you'd need an additional /boot/ partition
<PurpleSym>Why not just use the ESP as /boot?
<jpoiret>well, the EFI partition has a standard structure
<jpoiret>it has /EFI/ with subdirs for each os/efi application
<jpoiret>and you have the /EFI/boot/bootx64.efi if i'm not mistaken that is the default application for UEFI firmwares
<jpoiret>(ie when you install an efi bootloader on a usb key, you won't be able to add UEFI boot entries on the target computer, and so you'll have to install to the default loading path)
<jpoiret>(that's grub-install's --removable option)
<PurpleSym>Yeah, but grub will dump all of its (internal) files – minus EFI stub – into /boot/grub anyway. I don’t see any conflict so far.
<jpoiret>but then you'd have a single /grub directory alongside /EFI right?
<PurpleSym>I think so, yes.
<jpoiret>whereas you'd want the GRUB config alongside the grubx64.efi inside Guix/, no?
<PurpleSym>That sounds unnecessary complex. I thought grub would always look at /boot/grub anyway.
<jpoiret>well, no, grub knows where it installs its own files, and will automatically use the /EFI/Guix/grub/grub.cfg
<PurpleSym>I’ll give it a shot with /boot.
<cbaines>Downloading the guix release is super slow
<cbaines>I'm seeing speeds of ~20KB/s
<cbaines>this is testing both from the UK and Germany
<ss2>I just pulled it at 20MB/s
<cbaines>interesting, where from ss2 ?
<ss2>Germany, from a VPS.
<ss2>and from home, also in Germany at 6 MB/s
<cbaines>Haha, I've found a machine that can download it quickly
<cbaines>It's quick if you use IPv4, slow if you use IPv6
<cbaines>this is not how progress is meant to work :/
<ss2>how do I force a connection over ipv6? I'm connected with ipv6 at home too.
<ss2>wget -6, which is also going strong.
<cbaines>as in, you're seeing it download quickly over v6?
<jpoiret>maybe your ISP's IPv6 routing is poor cbaines
<ss2>interesting, but on my server, the connection is not completing.
<cbaines>jpoiret, would have to be my ISP, plus the internet connections of the several international data centres I've tested from
<cbaines>if it's fast for ss2 though, it's possible I guess that performance is degraded for some large fraction of the internet though
<jpoiret>well, looks like ipv6 doesn't even work for me so eh (my own connection that is)
<ss2>My server is timing out with ipv6. It could be routing problems.
<cbaines>In an hour when the download finishes (if it finishes), I'll file a bug...
<lispmacs>Hi, I've been struggling lately trying to replace my failing Nvidia graphics card, because every other graphics card I try (mainly old Radeon cards) causes my graphics system to freeze up during the boot process
<lispmacs>I was wondering if there was some kind of kernel boot parameters or other configuration tricks I need to try
<jpoiret>you could try nomodeset to disable kernel modesetting
<lispmacs>am running Guix System on x86-64
<lispmacs>jpoiret: what does that look like as a boot parameter?
<jpoiret>well, just "nomodeset", surrounded by spaces if following/preceding other parameters
<lispmacs>jpoiret: okay, thanks, I'll give that a try in a little while
<jpoiret>you can try without reconfiguring if you're using grub
<jpoiret>select an option and press e to edit the boot cmdline, and add that parameter
***piyo` is now known as piyo
<lispmacs>okay, that is what I thought. I'd do it right now but of course I've got to swap out the graphics card again, so need to wait for a convenient moment
<jpoiret>of course. Guix unfortunately doesn't handle mechanically swapping graphics card on your unit yet, although someone could write a service for it
<lispmacs>oh, probably won't happen for another 10 years then ;)
<lispmacs>that mysterious "someone" who never comes along to write the service. I'd like to meet him someday
***jonsger1 is now known as jonsger
<yewscion>Good Morning, Guix!
<fcw>Hello Guix!
<fcw>How do I close an issue in the issue tracker? ("[WIP SMLnj 0/1] Add SMLnj.") should be closed because smlnj is already in Guix.
<jpoiret>you can send a mail to
<fcw>jpoiret: Do I have the appropriate permissions/powers to close that issue?
<f1refly>is it easy to create a guix package when an equivalent nix package exists?
<f1refly>Nix has the crystal-lang compiler packaged, but I think there where issues bootstrapping it with guix
<f1refly>Nix seems to have done it somehow, so it has to be possible
<cbaines>nixpkgs has lower standards concerning building from source compared to guix
<Karthik[m]>cbaines: hello! I have stumbled upon your website some time ago. Good to know you're here :)
<cbaines>yep, I'm always lurking in #guix
<nckx>Good morning, Guix.
<nckx>fcw: Yes.
<Zambyte>Good morning :)
<nckx>jonsger: It doesn't really matter.
<lispmacs>hi, someone was helping me a few minutes ago with trying to run a radeon graphics card. I tried nomodeset. This does prevent the computer from freezing up, but now instead of booting into gdm, I just get a black screen. I'm currently using a virtual terminal
<lispmacs>there is an error in dmesg log: "[drm:radeon_module_init [radeon]] *ERROR* No UMS support in radeon module!"
<jpoiret>fcw: I think so
<nckx>drill aaaa → 2001:470:142:3::b
<nckx>That looks like a Hurricane Electric address.
<lispmacs>I found another error message: radeon 0000:01:00.0: Fatal error during GPU init
<nckx>Which is not bad! It just means that IPv4 vs. IPv6 routing will be vastly different.
<lispmacs>that might been an old message, found it in /var/log/messages
<jpoiret>lispmacs: maybe that radeon card needs proprietary blobs to function properly
<jpoiret>i'm not familiar with video cards on guix though
<\a>nckx, I don't think it's hurricane electric
<\a>AS | IP | BGP Prefix | CC | Registry | Allocated | AS Name
<\a>22989 | 2001:470:142:3::b | 2001:470:142::/48 | US | arin | 2001-03-22 | FREEASINFREEDOM, US
<lispmacs>jpoiret: I suppose so, I don't know
<nckx>OK, that was just from memory.
<\a>The IP may be rented from hurricane electric, but it's announced from the FSF's ASN
<lispmacs>every radeon card I've tried has a similiar failure
<nckx>AS6939 IRR Valid ROA Signed and Valid 2001:470::/32 Hurricane Electric LLC
<lispmacs>they are all old radeon cards though
<nckx>\a: Sounds right.
<\a>2001:470::/32 is hurricane electric, 2001:470:142::/48 is the FSF
<lispmacs>this one looks to be a Radeon HD 7470/8470
<nckx>It does go over for me.
<lispmacs>I guess it can't be too old, has HDMI port
<nckx>\a: So does that mean it's not a tunnel? Or is there no way to tell?
<\a>nckx, It's probably a BGP tunnel
<lispmacs>jpoiret: I see that there are xf86-video-ati and xf86-video-amdgpu packages in guix, do I need to integrate these somehow?
<lispmacs>I presume just installing them wouldn't work
<jpoiret>those are xorg drivers, and are included by default
<jpoiret>in %default-xorg-modules in gnu/services/xorg.scm
<lispmacs>I see that in guix system there is some option to set drivers for xorg
<jpoiret>do you startx yourself, or do you use a DM?
<lispmacs>jpoiret: whatever it is that boots gnome automatically, gdm I think
<jpoiret>alright, then that driver should be loaded properly
<lispmacs>jpoiret: xorg-server herd service appears to be running, and with ps I see a .gdm-real
<jpoiret> tells me R6000 and newer need non-free blobs
<lispmacs>I'm not sure what to do. My ancient NVIDIA card is failing
<lispmacs>h-node only lists like two graphics card that supposedly work with free drivers only
<lispmacs>both ancient cards
<lispmacs>I've asked here if anybody had a recommendation on which pci-ex16 card would work well with Guix, but never got any responses
<fcw>jpoiret, nckx: Thank you. I will try to close the issue.
<cbaines>I was about to install Guix on a IPv6 only server, but neither or are available over IPv6... which means no substitutes
<nckx>(Experienced same ☹)
<cbaines>I was not aware the situation was this bad, I guess I should have been paying more attention...
<nckx>Adding a tunnel to berlin turned out not to be possible, but I don't think I ever investigated bayfront.
<nckx>I know less about its hostabouts.
<cbaines>bayfront looks like it might be possible to get IPv6 working
<cbaines>I sent a message to guix-sysadmin
<cbaines>we probably need the help of Andreas or Ludo
<nckx>Saw the mail in the meantime.
<nckx>Why do you say that cbaines?
<nckx>About needing help.
<cbaines>nckx, I think we need to find out the subnet/route from Aquilenet (the hosting provider)
<cbaines>or at least check it
<cbaines>the information in the config file is from 2016, so it's quite possibly out of date
<nckx>Thanks. They claim to fully support IPv6, not that I expected otherwise. <>
<KE0VVT>Where does KeePassXC keep its lock file?
<jpoiret>KE0VVT: lockfiles should be in /run/user/UID/ if they want to respect the FHS
<KE0VVT>jpoiret: Not there.
<jpoiret>then you can strace the program to see what files it checks
<KE0VVT>I've never done that.
<jpoiret>you can `guix shell strace -- strace keepassxc 2> /tmp/strace.log` and inspect /tmp/strace.log
<jpoiret>then look at the latest open/openat calls in that file
<KE0VVT>jpoiret: It was in /tmp/.
<jpoiret>heh, not great, but alas
<jpoiret>i was looking at keepass source code, but it uses QLocalSocket and i'm not going into Qt5 source
<KE0VVT>Since I can't get to my email right now: IceDove loses its configuration after it is updated.
*nckx nudges jonsger.
<podiki[m]>with the librsvg/rust workaround pushed, was that the last blocker for core-updates-frozen?
<KE0VVT>Did somebody say GNOME 40?
<KE0VVT>What would be the obstacle to running Guix on a BeagleBone Black?
<csantosb>c = np.zeros((3, 4))
<drakonis>yes its in c-u-f
<csantosb>Sorry, wrong buffer ;-)
<nckx>KE0VVT: High-level answer because I don't have one, but I'd say performance & architecture support. Although the ARM substitute situation has improved greatly since I last heard someone talk about the Beaglebone Black, armhf is not as well supported as aarch64. You might be better of cross-compiling from a powerful system <> just so you don't have to wait days before try-debug-fix-retry iterations.
<KE0VVT>nckx: Was thinking of attaching a BBB to a compact keyboard and non-backlit character screen, to run Emacs with few distractions.
<nckx>Emacs as an Appliance. Neat.
<KE0VVT>nckx: Magic Emacs typewriter.
<nckx>I like the BBB and similar boards a lot, but they're borderline embedded devices and Guix and similar general-purpose, build-lots-yourself distributions aren't really optimised for them.
<KE0VVT>nckx: But I use substitutes.
<nckx>Right, but the cost of a missing substitute goes way up.
<KE0VVT>nckx: And you have to always ^C before your machine blows up.
<nckx>If you do build derivations directoly on the BBB itself, you should not track master but always use a commit that has good weather (a few days old).
*nckx AFK.
<itd>Hi, regarding ("[PATCH] gnu: Add tmate-ssh-server service."): apart from having patience, anything else I should/can do? Thank you.
<ArneBab>with guix graph I can plot build-time dependencies. Is there a way to also plot propagated-inputs?
<ArneBab>asking for this:
<nckx>I don't think there's a built-in way to keep only the propagated ones.
<nckx>In general, e.g. in vulnerability analysis, you ‘wouldn't care’ whether an input is propagated or not.
<nckx>If you want the run-time closure, you can use -t references, but again that will include much more than strictly propagated-inputs. In both cases they'll be included in the graph, of course.
<nckx>Thinking of inputs and references as ‘build time’ and ‘run time’ ‘dependencies’ has never clicked for me though. I think it leads to misconceptions but that's just me.
<GNUtoo>hi, I'm running GuixSD and GDM works and can launch xfce4. Is there anything special I need to do have sway appear in the choice of desktop environments?
<Festerdam>Hi, all!
<KE0VVT>GNUtoo: It needs an entry in a directory somewhere. I know of a video on it.
<KE0VVT>(Hold on.)
<csantosb>I'm thinking about best (if any) strategy to run gitlab ci tests inside a guix container, provided I include a couple of manifest.scm and channels.scm along with the project.
<csantosb>They're both expected to evolve along with code in commits.
<csantosb>Ideally, I'd like to spawn a container with 'guix shell --container' at every commit. No idea how.
<csantosb>Option 1. Docker image with any os and guix installed. Upon every commit, ci opens the image, and runs guix shell ... Not very, efficient, I'd say (lots of downloads). Not clear to me how to handle daemons and the like within the container.
<csantosb>Option2. Produce a docker image out of guix pack -f docker, and use it instead. Here, problem is I'd have to do it manually ... fas from ideal.
<csantosb>Any experience with this ?
<KE0VVT>GNUtoo: Personally, I used this issue as an excuse to forgo GDM.
<GNUtoo>KE0VVT: The issue is that I don't know any alternatives to gdm, AFAIK there was some lightdm services but the work stalled if I recall well
<singpolyma>csantosb: sourcehut has a guix image natively for their CI and can be triggered from gitlab. Might be worth looking at
<KE0VVT>GNUtoo: Right. I think that video expl. how to add the entry to GDM.
<KE0VVT>GNUtoo: Oh, I was wrong. He removed GDM.
<KE0VVT>Man, having whole OSes in Git rocks!
<csantosb>singpolyma: thanks, i'll have a look
<KE0VVT>I don't like Source Hut's aesthetic.
<Festerdam>My installation seems to be going excruciatingly slow (the guix pull step), despite my internet not even being that bad. It eventually fails with an early EOF (guix substitute error: TLS error in procedure read_from_session_record_port: Error decoding the received TLS packet. guide system: error: corrupt input while restoring archive from #<closed: file 7ff5514e42a0>). The installation can't recover after that (guix system: error: executing SQLite query:
<Festerdam>database disk image is malformed Command failed with exit code 1). Why does that happen how to fix that? I have the impression that some packages download extremely fast while other extremely slow.
<dhruvin>csantosb: note that you can cut down build times significantly if you have build-caches, which sourcehut currently does not have.
<csantosb>singpolyma: this is what you refer to ?
<singpolyma>csantosb: yes
<KE0VVT>I'm still amazed at Guix's maturity now.
<KE0VVT>Can I remove aliases from my .bashrc now that they are defined in my home-configuration.scm?
<csantosb>Ok, so the idea is going full guix, not on top of a foreign distro ... hum.
<GNUtoo>KE0VVT: thanks, at least I've now an example how to remove a service from %desktop-services
*GNUtoo wonders how to launch sway in a way that is safe
<KE0VVT>For Sway, I like the minimal aesthetic of just using a TTY to log in.
<GNUtoo>The issue is that I'm always afraid that someone could use that same tty somehow
<KE0VVT>GNUtoo: What's wrong with typing 'sway'? :(
<GNUtoo>Like if someone crashes sway, that person has a shell
<Festerdam>What I mentioned happens all the time, so I'm unable to install Guix.
<Festerdam>Oh, wait. Seems like it does recover, but starts from the beginning.
<Festerdam>So, it will after quite some time fail for the same reason.
<GNUtoo>What package was it failing on?
<samplet>GNUtoo: I bet that the special support we added for GDM to find packages’ “share/xsessions” directories didn’t get updated to support “share/wayland-sessions” when GDM get Wayland support.
<samplet>Just a guess.
<GNUtoo>samplet: Thanks, I should look into that
<Festerdam>GNUtoo: Once it failed on Python2 then it failed on Guix (I only ran it two times since it takes so long).
<KE0VVT>GNUtoo: What about "sway && exit"? :P
<ArneBab>nckx: I mean: I want to see openjdk when I graph tomcat.
<KE0VVT>(GDM needs support, I just don't want it myself.)
<GNUtoo>KE0VVT: sway;exit might have a race condition
<GNUtoo>You could probably ctrl+c it
<samplet>GNUtoo: Yup – see “gnu/packages/patches/gdm-default-session.patch”.
<nckx>ArneBab: Why?
<samplet>We add “xsessions”, bet we should also now add “wayland-sessions”.
<KE0VVT>GNUtoo: A what condition?
<nckx>ArneBab: IIUC there's an implicit icedtea input through the ant-build-system, but I don't see openjdk. The naming of this stuff always confuses me though. I don't see how propagated-inputs are involved.
<GNUtoo>KE0VVT: the word is badly chosen, but I meant that someone could try to crash and right after try ctrl+c to not have the exit run
<nckx>ArneBab: I assume this is about log4j?
<ArneBab>nckx: because I would like to see all actual dependencies to be able to graph every package involved in running tomcat.
<GNUtoo>Typically race conditions is when things are not executed in the same order or cases like that where the order or things or timings affect the outcome
<ArneBab>nckx: yes, but not as package but as concept: Seeing dependencies so you can check whether all your deps are well-maintained.
<nckx>But why do you want openjdk to be in there when it doesn't seem to be?
<ArneBab>icecat is the same for me :-)
<ArneBab>(icedtea ~ openjdk@8)
<GNUtoo>This is a common issue with programs that use threads: when there is a bug the order of execution of the threads can trigger the bug or not trigger it
<zamfofex>KE0VVT GNUtoo: I think the word “race” in “race condition” refers to the verb “to race” rather than the noun “race”.
<GNUtoo>yes, something that has to do with speed
<ArneBab>two processes racing to see who is first
<ArneBab>and if your program only works correctly if a specific one wins, you have a problem.
<nckx>ArneBab: How would java-tomcat use a specific icedtea if it doesn't hold a reference to one?
<ArneBab>nckx: it uses some icedtea when I run it
<nckx>Well, the Guix qcow2 ‘uses’ a qemu when you run it with ‘qemu … foo.qcow2’.
<nckx>Doesn't mean you can graph the qcow2 for qemu vulnerabilities.
<nckx>Aren't *you* supplying the icedtea here? Maybe I misunderstand.
*nckx looks in /bin
<nckx>‘Neither the JAVA_HOME nor the JRE_HOME environment variable is defined
<nckx>At least one of these environment variable is needed to run this program’
<nckx>Maybe it's insufficient wrapping, but if java-tomcat were bringing its own JRE to the party I'd expect that to be set for me.
<nckx>I get that error for each tomcat .sh script I try.
<GNUtoo>ah apparently the definition works for the case I described: "A race condition or race hazard is the condition of an electronic, software, or other system where the systems's substantive behavior is dependent on the sequence or timings of other uncontrollale events" ([[Race condition]]), I was unsure if it could apply to the full system or just within a program
<KE0VVT>>race hazard xD
<nckx>ArneBab: ‘guix install java-tomcat’ does not give me a JDK AFAICT.
<ArneBab>nckx: then tomcat is not actually self-contained.
<GNUtoo>For instance if the program doesn't crash anymore when you add debugging, then you usually have a race condition
<nckx>Many things aren't.
<nckx>You can't make everything self-contained. You have to cut somewhere.
<GNUtoo>Sometimes also running the program in the debugger makes it not crash anymore...
<ArneBab>That also means that what runs is not actually a function of the inputs — but yes
<GNUtoo>So these are usually painful to debug...
<Festerdam>It seems like initially the guix downloads packages at normal network speeds but then starts slowing down. Is there some kind of mirror I can use? Also, why do python versions take so long to download, despite being only around 10 megabytes?
<nckx><what runs is not actually a function of the inputs> Correct. Imagine if bash had to include every single command you can run from it.
<ArneBab>that’s not really the same
<nckx>I don't see why not.
<ArneBab>imagine if every bash script had bash as package in it — which they have.
<ArneBab>bash does not need a script to run, tomcat requires a JDK or JRE to run
<nckx>Sounds like introducing dependency hell TBH.
<KE0VVT>Do I need aliases in my .bashrc, now that the aliases are declared in my home-configuration.scm?
<ArneBab>nckx: not really — that’s what grafting is for
<ArneBab>(as far as I understand)
<Festerdam>And it failed again on Python 2.
<KE0VVT>What is Python 2?
<nckx>ArneBab: If you think every Java package should be wrapped with its build-time (implicit) icedtea, you can open an issue. I think it's a big price to pay for limited (if cool) static analysis but I don't have a dog in this fight ☺
<ArneBab>nckx: I realized that this is missing when I saw how tiny the dependencies of tomcat are :-)
<nckx>(Again… what even are dependencies. I assume you mean references here.)
<nckx>The stuff that ‘guix size’ prints (transitive) or ‘guix gc --references’ (not).
<nckx>I also looked at ‘guix size’ first, BTW ☺
<nckx>It's a good sniff test.
<nckx>ArneBab: Re: adding a reference to the JDK for all Java packages, I'd be interested in the discussion such a proposal would generate. I don't know if you're a Java dev. I'm not.
<nckx>Or should that be JRE. (See?)
<ArneBab>I am a Java dev nowadays, yes
<AwesomeAdam54321>nckx: All Java packages need the JRE to run(unless they're compiled) but since the JDK is for development, that should be discussed
<nckx><what runs is not actually a function of the inputs> By the way, depends on what you mean by ‘what runs’: the .jar and everything else under /gnu/store/java-tomcat is functional and probably bit-reproducible. ‘The programme’ in that sense is a fixed value. How it ‘runs’, interacts with its environment, is not, but that's never the case on Unix. The question is just whether to make the JRE/JDK part of the fixed output, or the environment (as it is now).
<nckx>That's why I think my bash argument was accurate, if rather ridiculous.
<singpolyma>Well you would want a script that runs the jar with the right JRE. Just as we do for python and ruby shebangs, etc
<nckx>AwesomeAdam54321: Right. I wasn't disputing that.
<nckx>singpolyma: It's not similar to shebangs because the jar doesn't embed a reference to the JRE (as if it were an It's just a wrapper, with all the disadvantages those have. But it could be made to mostly work with effort.
<ArneBab>singpolyma: yes, that’s what I mean. It might be a viable idea to create run-scripts that depend on the java package and a given JDK. That would keep the dependencies simpler but still allow functional definition of what runs.
<singpolyma>nckx: the missing reference is the problem, yes, so would need to make a script or the program can't be run
<ArneBab>I don’t understand, though, how a jar can be built without the JDK available. Or even be built reliably (if you build something against openjdk@17 it might not actually run with openjdk@9 (I already had a few cases of that — the internal libraries changed, and they are referenced in the built jar)
<nckx>It is built with a JDK, that's what I meant earlier by implicit icedtea input to the ant-build-system. Like how the gnu-build-system implicitly includes GCC et al.
<ArneBab>that implicit input should be in the deps, I think
<singpolyma>ArneBab: "deps" are classified in guix, they're not a blob
*nckx sighs.
<singpolyma>They *are* in the build time "deps"
<nckx>Your continued use of ‘deps’ makes us do all the work of figuring out what you mean. Just because that's usually possible doesn't make it pleasant, and increases the odds of miscommunication.
<ArneBab>singpolyma: they are not in the package graph
<ArneBab>I mean that which is given by guix graph
<nckx>Nor should they be.
<ArneBab>(see my initial qustion)
<singpolyma>ArneBab: right, well most jars sholud not have jre in the graph. Only programs you run
<reza[m]>is there a gpg-agent service in guix?
<nckx>Whether to include JRE references in each Java package is a bit of a policy question, but whether ‘guix graph’ should show icedtea today is not — it shouldn't, it's doing the right thing.
<Festerdam>KE0VVT: python2-2.7.17, in the guix installation. Error decoding received TLS packet.
<nckx>s/Java package/end-user &/, good point.
<ArneBab>… just realized: that’s because tomcat includes java-ecj as dependency
<ArneBab>the eclipse compiler
*nckx sighs.
<ArneBab>which means that it actually does include all it needs to build (making my point moot)
<nckx>reza[m]: Add ‘use-agent’ to your .gnupg/gpg.conf.
<Festerdam>The python3 and 2 package take an above average time to download.
<nckx>ArneBab: I looked at ecj earlier but couldn't quite figure out if it was enough to serve as reproducible run time ☝
<nckx>…that was supposed to be one of those sweaty smiles that are hip with the kids but I screwed it up.
<nckx>The very same!
<nckx>Ta ☺
<ArneBab>it’s not the runtime, just the compiler, but with this, a runscript that references both tomcat and openjdk would be complete
*nckx adds alias.
<reza[m]>nckx: is this documented somewhere, I ask because I didn't found anything in the manual?
<nckx>Well, coming from my (mostly) C(++) background, ‘compiler’ and ‘run-time’ aren't really that clear as might be the case in Java. So I was clueless.
<nckx>reza[m]: Well, it's not really a Guix question. I don't think so.
<nckx>There is no such thing as a system-wide ‘GPG agent’, it's just an option you can toggle in GNUPG that will make it launch some behind-the-scenes process when you invoke it.
<nckx>Maybe this could go in the cookbook? I never really know what's suitable.
<ArneBab>nckx: for java it actually isn’t completely clear. For example I have to build Freenet with icedtea@8 because if I build with something newer, it will not run on Java 8 — though that’s not really advertised widely.
<nckx>Probably not, since I'm sure it's documented in the gnupg manual.
<ArneBab>But if people run that build with Java 15, they get the benefits of the better gc
<nckx>The icedtea/openjdk/version numbering mess confuses me further.
<ArneBab>rightly so :-)
<ArneBab>icedtea is a harness to build Java up to 8 without depending on proprietary Sun/Oracle tech. Openjdk is the free release from Oracle where those parts are supplied by the core project.
<nckx>I'll try to remember that, but I'll probably have to look it up again next year (I knew this… once, but it was GC'd).
<ArneBab>glad to — and thank you for putting up with me ;-)
<nckx>Oh? Gladly. And same.
*nckx will read any issue you file on the matter with interest.
<nckx>reza[m]: If guix home includes a gnupg configuration generator (I didn't check) it could expose that option, which would then be documented briefly by the guix home docs.
<nckx>guix home is rather separate from the rest of guix though, you don't need to use it to use Guix or Guix System.
<nckx>Most people just twiddle their dot files manually.
<KE0VVT>I'd like to port my dotfiles to Guix Home. :(
<reza[m]>nckx: I am in the process of migration to a home-environment and was wondering what would be the best approach forgnupg
<nckx>Then I shall shut up because I am not a user.
<KE0VVT>I'd probably just keep using GNU Stow for private stuff like GPG keys.
***nfir is now known as nf
<florhizome[m]>wait there are actually official guix tutorial videos
<florhizome[m]>but they don’t play on my iPad :/
<Festerdam>python2-2.7.17 is downloading at 15 KiB/s. My network is capable of at least 1 Megabyte per second (many packages also do download at 1 MiB/s). Why is it so slow?
<Festerdam>And it failed for the 4th time with the same error again!
<nckx>florhizome[m]: Some effort was made to be compatible with ithings back when they were made. Mind opening a bug? ☺
<nckx>Festerdam: Which server are you downloading from?
<florhizome[m]>nckx: will do
<KE0VVT>I'm scared to run this change to home config.
<nckx>Festerdam: You can swap the default preference order with --substitute-urls="", that will only work if bordeaux has the same copy of Python built.
<Festerdam>nckx: The installation didn't ask me to choose any mirror, so the default one, I think.
<florhizome[m]>KE0VVT: You should always be able to rollback
<KE0VVT>florhizome[m]: Sure, but it takes a long time to run the change. I have to update all my packages, etc.
<nckx>We don't really have mirrors except perhaps a Chinese one of which I don't know the name.
<Festerdam>The what is Bordeaux?
<florhizome[m]>KE0VVT: really? Has been pretty smoothe for me forever
<florhizome[m]>I actually haven’t tried out home files service so pls keep us uptodate :D
<nckx>Festerdam: The name of the second substitute server. The primary substitute server ( is also known its home ( so that became something of a pattern.
<KE0VVT>florhizome[m]: I'm scared I did not write the code snippet correctly.
<nckx>It is not a mirror of berlin content.
<Festerdam>What's the difference between a mirror and a substitute server?
<nckx>Well, a substitute server could be both (just a server serving substitutes after all). Bordeaux and berlin are both build farms: they each have multilpe relatively powerful machines that do nothing but build packages independently. A mirror would simply be a copy/cache of packages built elsewhere, for e.g. faster downloads in another part of the world. The Guix project doesn't run one.
<nckx>It's possible for berlin to have a substitute that bordeaux still needs to build, and vice versa.
<nckx>Berlin is generally faster but is having scaling issues.
***jonsger1 is now known as jonsger
<nckx>It also has weird network speed issues which you might be hitting, which nobody's been able to figure out.
<cbaines>I'm close to deploying mirrors for, I've been working on it to avoid the space constraints of bayfront, but the approach I'm taking is pretty much mirroring
<nckx>Oh good.
<nckx>I'm tired of that speech :)
<Festerdam>So the difference is that one builds them themselves and offers the binaries to be downloaded and the other just offers the binaries? Sounds like mirrors to me except for the building part. Ok, will try Bordeaux.
<nckx>Yes, they are basically mirrors, except for the fact that they aren't.
<civodul>Festerdam: has more details
<Noisytoot>nckx, Why does bordeaux not have IPv6?
<nckx>Because it hasn't been configured yet. (Really.)
<nckx>I doubt there's any structural issue whatsoever.
<nckx>Guix's very spartan static networking service didn't used(?) to offer it, so it wasn't offered.
<unmatched-paren>hi guix!
<nckx>Noisytoot: Chris is waiting for nice-to-have details such as ‘what is our address, anyway?’ to hopefully change this soon.
<nckx>Hi (.
<unmatched-paren>some of the svg icons in gnome are garbled, is this a known issue?
<nckx>It's a very old known bug because the fix was on c-u. Should be fixed on c-u-f.
<unmatched-paren>ok, thanks
<unmatched-paren>actually, is there some way to modify the .desktop files in guix by hand? or are they immutable? neovim has a desktop entry which annoys me a little since it's a terminal program and i never launch it from the app menu
<unmatched-paren>i guess modification of the .desktops would also be useful to change the gnome web icon to the new one in later versions of gnome, which hopefully would not be garbled
<jpoiret>they're included in the store, so no
<jpoiret>you'd have to modify the package definition
<unmatched-paren>right, ok
<unmatched-paren>they'd be overwritten on update anyway
<unmatched-paren>ok, one last thing (sorry, it's been a while since i've been in #guix, so i have a couple of questions)
<unmatched-paren>is it possible to use guix for build orchestration on local projects? like, you define a package in some file in your project's directory and make it build/install the package from the local source when you run guix package/build -f on it
<unmatched-paren>basically, you declare a package that builds from a local directory instead of a remote git repo or tarball
<unmatched-paren>i think that'd be a really cool functionality, you package your application as you develop it
<jonsger>nckx: what doesnt really matter?
<nckx><jonsger> nckx: so boot on a coreboot amd64 or a non-coreboot amd64?
<nckx>jonsger: My nudging you earlier was in response to <KE0VVT> Since I can't get to my email right now: IceDove loses its configuration after it is updated.
<jonsger>nckx: yeah, if you start it via gnome
<jonsger>from the terminal it works for me
<nckx>(You do maintain our IceDove package, rite?)
<jonsger>I'll try to do :)
<Festerdam>How do I reset the database disk image? I'm getting "error: executing SQLite query: database disk image is malfoemes".
<Festerdam>guix system init command
<jonsger>KE0VVT: so first start it from the command line and then you can start it via GNOME/DE of your choice
<jonsger>I guess its a problem with .desktop or somewhere else. Debugging that profile stuff of firefox/thunderbird is a bit tiring :(
<KE0VVT>jonsger: Running IceDove from Terminal still brought me to Account Setup.
<KE0VVT>And I still can't get KeePass to open.
<jonsger>KE0VVT: then icedove --ProfileManager and delete all profiles not named "default"
<Festerdam>Yeah, it also doesn't work through the graphical installer anymore. Even after I try the step again and again.
<jpoiret>Festerdam: what are you running, and from what system
<jonsger>choose default and hit start daily if you get your email settings you can delete the others...
<jpoiret>ie, when precisely do you get this error?
<KE0VVT>OK, default-default worked.
<KE0VVT>Such a headache...
<civodul>efraim: with the introduction of librsvg-bootstrap, i was wondering whether some apps would find themselves depending on both "librsvg" and "librsvg-bootstrap", but that's apparently not the case
<civodul>at least this shows only one: guix graph -t references emacs |grep 'label = "librsvg'
<Festerdam>jpoiret: guix system unit /mnt/etc/confic.scm /mnt/ --subatitute-urls="" from the guix system installed. I'm running it after the installer failed to download some packages. Before, the error would appear, but if tried it again it would suddenly start from the beginning. I'm now trying to do it from the command line because I'm trying to see if the packages fail to install due to the o
<Festerdam>*some problem of the official substitute server
<jpoiret>have you tried to reboot the installer image?
<jpoiret>also, if you do it from the command line, you should remember to run `herd start cow-store /mnt` after mounting the filesystems
<Festerdam>jpoiret: Restarting will probably fix it, but I don't want to lose the settings. I only switched to the command-line on the last step of the graphical install.
<Festerdam>Eh, I'll restart.
<jpoiret>i mean, it is definitely weird, and if it happens again it might just be an installer bug (or faulty usb)
<nckx>Speaking of borked DBs, I still get: guix gc: error: executing SQLite statement: FOREIGN KEY constraint failed
<Festerdam>jpoiret: The database error did occur before after the installation failed. I restarted and tried again, after it failed again I got that error again after restarting the installer, so I restarted and now the installer is running and I have yet to see if the error happens again with the substitute server.
<nckx>Is there a way to make Guix give more information than ‘oops’?
<Festerdam>My installation media ran out of storage during the installation, despite it being 16 a 16G drive. Isn't the data cleared in restart?
<fluffyballoon>Is there a good article anywhere comparing and contrasting Guix and Propellor?
<Festerdam>The partition on the drive that is full however is only 1.9G big.
<nckx>The database dump does not contain any mention of ‘constraint’ :-/
<nckx>Oh, it doesn't need to.
<Festerdam>The partition that is full is mounted as /
<Festerdam>On the installer drive.
<Festerdam>Seems like /gnu is occupying 2.3 G.
<Festerdam>Wait that's impossible if the partition is only 1.9G.
<nckx>It's full of hard links that can confuse certain naive size calculations.
<scolobb>fluffyballoon: Never heard of Propellor. Can you give more details, or a link?
<fluffyballoon>scolobb: - The Haskell declarative configuration system
<fluffyballoon>It tries to be a system that is impossible to misconfigure: any errors should cause the configuration fail to compile at all.
<fluffyballoon>It's a really interesting way of using data-types.
<Festerdam>But why is the drive full? It shouldn't be. I restarted the device and then did the exact same procedure as I did countless times before but with the new substitute server and now the installation medium if full?
<Festerdam>*is full
<Festerdam>How do I fix it?
<scolobb>fluffyballoon: Looks nice indeed. From a quick look at the docs, the main difference between Propellor and Guix (as well as Nix) is that the former is a deployment tool, while Guix is first of all a package manager.  If you take a look at , Propellor seems to deploy (Debian) disk
<scolobb>images and then configure the hosts.  The contents of the disk image depend on some other providers.  Guix is a package manager, which allows defining package building and installation recipes.  Guix also allows defining the configuration of the entire system.  However, Guix itself is not specifically a deployment tool, as far as I understand
<scolobb>A tool which reminds me of Propellor in the Nix ecosystem is krops : it's a deployment tool specialized in deploying Nix hosts.  I suppose Guix has something similar, but I'm not knowledgeable enough yet.
<scolobb>Main take-away: Guix is a package manager, which can also manage your system configuration, but doesn't directly handle deployement. Propellor is a deployment tool, which manages the system configuration, but not manage packages
<fluffyballoon>scolobb: Thank you, that's an interesteing summary. I'm not sure I understand /how/ Guix's ability to configure the system differs from the others, but maybe that's nonessential.
<podiki[m]>there's guix deploy:
<fluffyballoon>I have a Propellor system configuration and, if the mood strikes, I might try rewriting it in Guix-form just to see how they differ.
<Festerdam>How do I get more space on the installation medium?
<vdv>on the usb stick @Festerdam?
<vdv>maybe make the partition a bit bigger with gparted
<nckx>The installation medium stores all data in RAM. It does not care about the size of the partition on the medium and I'd advise against messing with it. There are some bootable-CD hacks in place that could break.
<nckx>When you start the graphical installation, it mounts the target partition and starts the cow-store service.
<vdv>yeah maybe he wants to install some program with nix-env before starting the cow-store?
<nckx>This service acts as a union file system that transparently stores all new writes to /gnu/store (which is ostensibly a tmpfs in RAM like all of /) on the target partition instead.
<vdv>*guix install sry
<nckx>You can do that but I don't see the advantage.
<nckx>Why not first mount /mnt, start cow-store, then guix pull and/or guix install…
<nckx>Oh well.
<vagrantc>fluffyballoon: you have a propellor configuration for guix?
<Festerdam>It's because my installt
<Festerdam>Installation medium ran out of space before. It now seems to be doing fine now, though.
<Festerdam>For the moment.
<robin>blah, i just finished packaging moscow ml (for mlton bootstrapping) but it's non-free because it's derived from caml light, which used qpl for the compiler
<robin>i wonder if inria would consider relicensing it, considering that caml light was last updated ~20 years ago and ocaml is all lgpl (afaict)
<ArneBab>sneek later tell unmatched-paren: See what I did for gst-plugins-base-gl here: — with pre-inst-env guix environment that pulls in my own adaptions to packages.
<sneek>Will do.
<fluffyballoon>vagrantc: No, I have a propellor system configuration that I might try to rewrite in Guix.
<ArneBab>sneek: botsnack
<vagrantc>using guix deploy to install guix, or using it to install debian? :)
<robin>i guess i'll try bootstrapping mlton with polyml, although i suspect polyml itself isn't properly bootstrapped (maybe an SML version of camlboot is needed, as the only other bootstrappable sml implementation i could find is in typescript...)
*GNUtoo would like one day to be able to install other FSDG compliant distributions through Guix
<fluffyballoon>Probably to install Guix, because using an overlay system on an existing system is a good way to reproduce the original system.
<fluffyballoon>It's a research paper, so functionally reproducing the original is a goal.
<GNUtoo>I tried to add Trisquel and PureoOS byzantium to debootstrap but nobody reviewed the pull request though:
<vagrantc>fluffyballoon: ah, guix has some strength there, then. :)
<GNUtoo>Though maybe I'm not understanding what propellor is
<vagrantc>propellor is a configuration management system
<vagrantc>which can be used to install certain systems ... very haskell
*GNUtoo would also like to handle other FSDG compliant distributions through Guix
*vagrantc tried it long ago but couldn't grok haskell enough
<GNUtoo>Like you install Parabola or Trisquel and use the Guix configuration management to produce images
<GNUtoo>(It'd use apt or pacman to fetch the packages though)
<GNUtoo>This way we'd have an unified configuration management that can handles several systems
<GNUtoo>Though the first step in that is actually to be able to bootstrap other FSDG compliant distributions
<vagrantc>yeah, not sure how the apt/pacman integration would even work :)
<vagrantc>very different design decisions...
<GNUtoo>There are already things for non-fsdg distributions though
<Festerdam>Using the Bordeaux substitute server, python still fails to download.
<Festerdam>What is it with individual packages downloading at different speeds? What's so different about python that it is only downloaded at an absolute snails pace that it causes an early EOF?
<GNUtoo>Ah I forgot about PureOS amber, so we have 1 FSDG distribution at least
<GNUtoo>So we can have VM running other distribution handled by Guix but not create images and so on yet
<GNUtoo>(at least not without GuixSD inside)
<GNUtoo>The big question would be how to interact with the distribution's init system if we want to go beyond that
<jpoiret>guix as a system manager really has at its heart the guix store and derivations, I don't know how you would handle another distro with it
<jpoiret>you'd have to start from scratch and i'm not sure they could be unified
<GNUtoo>Both Guix and OpenWRT have special init daemons to handle the system configuration, though maybe Mandrivia manages to do it without that
<civodul>GNUtoo: we could have "marionette" running in that distro VM, but that also raises bootstrapping issues
<civodul>(see (gnu build marionette))
<GNUtoo>That has the potential to even run on the same installation
<GNUtoo>like a standalone Parabola installation whose configuration is handled by Guix
<GNUtoo>For bootstrapping the ganetti blog post has code to boottrap VMs at least
<vagrantc>sounds like a long, long road to walk, but theoretically possible :)
<GNUtoo>Though some simple stuff might not take that long, like handling the bootstraping in a generic way and having some very basic configuration management, like copying files for instance
<Noisytoot>What should the dependencies field in swap-space be set to for a swapfile on a btrfs filesystem?
<GNUtoo>Guix already handles /etc/ for instance
<Festerdam>OK, it happened again. And it completely baffles me why python is a problem if all packages come from the same server. I don't understand why that happens and I don't understand why early EOFs occur (what about users on slow connections?).
<GNUtoo>The big question would be to find ways to also make the other distribution (like Parabola) happy by integrating well with it
<GNUtoo>like the package manager would need to run hooks that would make sure that Guix handles certain files and so on
<Festerdam>I think I give up installing Guix.