IRC channel logs


back to list of logs

<divansantana>hmmm, after a recent guix update my iptables nat rules are broken with "can't initialize iptables table `nat': Table does not exist"
<divansantana>perhaps because of custom kernel...
<efraim>Yay for rollbacks? Unfortunately I have no experience with iptables
<divansantana>think need to update my kernel. Testing with guix vm and non custom kernel, seems all is fine.
<efraim>Upgraded from 4.18 to 4.19?
<divansantana>efraim: true.
<divansantana>efraim: no, doing so now. Thanks :)
<rekado>Hi Guix
<rekado>we need to do something about GHC creating its package database in a non-reproducible fashion.
<rekado>This problem makes it impossible to compile Haskell packages reliably.
<g_bor>hello guix!
<g_bor>I noticed diffoscope does not build on core-updates any more.
<g_bor>It is failing the berkeleydb isinstance assertion in the testsuite.
<efraim>Not at my computer, does it want the other version of bdb?
<g_bor>I will try to have a look, I don't know yet what to look for...
<g_bor>it says this:
<g_bor>=================================== FAILURES ===================================
<g_bor>_____________________________ test_identification ______________________________
<g_bor>db1 = <<class 'diffoscope.comparators.binary.FilesystemFile'> /tmp/guix-build-diffoscope-104.drv-0/diffoscope-104/tests/data/test1.db>
<g_bor> def test_identification(db1):
<g_bor>> assert isinstance(db1, BerkeleyDBFile)
<g_bor>E AssertionError: assert False
<g_bor>E + where False = isinstance(<<class 'diffoscope.comparators.binary.FilesystemFile'> /tmp/guix-build-diffoscope-104.drv-0/diffoscope-104/tests/data/test1.db>, BerkeleyDBFile)
<g_bor>tests/comparators/ AssertionError
<g_bor>also, this is only on core-updates, it builds fine on master.
<efraim>Bdb probably didn't change, so python?
<efraim>Are the python inputs up to date?
<manumanumanu>So. I managed to bork my guix install so that the guix command does not work. How do I best revert?
<manumanumanu>is it possible?
***rekado_ is now known as rekado
<rekado>manumanumanu: does ~/.config/guix exist?
<rekado>manumanumanu: you might have an older version of Guix there.
<rekado>e.g. ~/.config/guix/current-2-link/bin/guix
<manumanumanu>only latest
<rekado>oh, that means you’re using a pretty old version.
<rekado>how is it borked?
<manumanumanu>"no code for module (gcrypt hash)"
<rekado>that’s not too bad.
<rekado>you just need guile-gcrypt then.
<manumanumanu>but it worked before I did some guix pull stuff
<rekado>this has been a common problem when upgrading Guix from the old “latest”-style “guix pull” to the newer “current”-style “guix pull”
<rekado>the old style was not self-contained
<rekado>the new Guix pull style installs self-contained versions of Guix into ~/.config/guix/
<rekado>it’s much more robust
<rekado>but to get there from an older version means pain, I’m afraid.
<manumanumanu>I'll do a re-install :D
<manumanumanu>My distro is beyond saving anyway
<rekado>you could try to move ~/.config/guix/latest out of the way
<rekado>that way you get the system-wide Guix
<rekado>with that version of Guix you could then upgrade to the last version that does not require guile-gcrypt, but which offers it as a package.
<rekado>then you would install guile-gcrypt and run “guix pull” again to get the latest version.
<manumanumanu>it works
<rekado>(and then you could get rid of guile-gcrypt again)
<rekado>note that running just “guix pull” from that old Guix is going to get you into the same problematic situation.
<rekado>you need to do this awkward two-step upgrade.
<manumanumanu>so, the steps are again? guix pull, guix package -i guile-gcrypt and guix pull again?
<rekado>“guix pull --commit=b0cb92b2d43a2c4d5fa9b3f8c04c5732c60061e7”, “guix package -i guile-gcrypt guile”, then “guix pull”
<rekado>the commit there is the one that added the guile-gcrypt package to Guix.
<manumanumanu>thank you
<rekado>hope this works for you!
<manumanumanu>haha, my guix doesn't support guix pull --commit :D
<manumanumanu>I don't want to waste your time. I'll just blow the installation and redo it. I have the time
<manumanumanu>rekado: if I install 0.15, can I do a clean upgrade without anything bad happening?
<manumanumanu>using guix pull, I mean
<rekado>manumanumanu: I think so.
<manumanumanu>trying now. thanks for your time
*rekado finally updated R to 3.5.1, a few months late
<thomassgn>I'm wondering, how do you get bash to complete (with tab) guix commands? It used to do this a while a go, but at some point last winter I think it stopped completing (i.e. 'guix packa<tab>' became 'guix package '). I just installed the bash-completion package, but on it's own this did not change anything in a fresh shell...
<efraim>It works on one machine but not another for me
<thomassgn>ok, so I ofcourse need to source the bash-completion script...
<efraim>I don't use the second often though so I never bothered to look into it
<thomassgn>mm, same reason I never looked it up, wasn't bothering me enough. :)
<jonsger>bash completion as well as fish and zsh works out-of-the-box with the suse package :P
<thomassgn>But doing 'source ~/.guix-profile/share/bash-completion/bash-completion' made it work. Now it completes as I described above... :)
<snape>rekado, civodul: berlin returns 502
<snape>hmm not anymore
<rekado>I just hopped on and checked
<rekado>enough space and cuirass ran
<rekado>I saw the 502 as well
<civodul>rekado: i've just run gc
<civodul>and restarted cuirass
<civodul>kinda annoying :-/
<rekado>oh, thanks
<rekado>I really want to get the external storage working
<rekado>I’ve just been too busy / sick in the past weeks.
<civodul>bah don't worry, you shouldn't have to have all this on your shoulders
<rekado>so… I’d like to figure out when I can mount the storage. Can this be done at the end of the initrd?
<civodul>i don't really know what the problem is, though
<civodul>you said GRUB wouldn't detect it, right?
<civodul>in that case, you can't even load and boot the kernel, right?
<rekado>and once linux has booted I see the devices.
<rekado>so I want to copy the kernel and the initrd to the local disk
<rekado>have it boot from there
<rekado>and then bind-mount /gnu/store from the detected external storage.
<rekado>this should happen before any other services are started, so that we don’t have anything running that depends on the old /gnu/store location which would be shadowed.
<civodul>note that GuixSD supports a separate /gnu (or /gnu/store) partition
<civodul>so this bit should Just Work
<civodul>that's already handled
<rekado>where can I find more information about this?
*rekado checks the manual
<civodul>there's a "separate-store-os" test that does exactly that
<civodul>what's the device model name again?
<civodul>i find it crazy that GRUB can't handle it
<rekado>yeah, it’s very frustrating and unexpected.
<rekado>the device name is: LSI Logic / Symbios Logic SAS3008 PCI-Express Fusion-MPT SAS-3 (rev 02)
*rekado goes afk for a few mins
<civodul>well, i browsed the internet but didn't draw any new conclusions :-)
*civodul wonders why we're rebuilding python3
<pkill9_>wasn't it due to a memory leak in a test?
<civodul>yeah but i don't think we changed it in master?
<rekado>I’m afraid that the separate-store-os configuration isn’t going to work in the case of
<rekado>I remember that I tried it before and couldn’t mount the disk early while booting.
<rekado>It’s possibly that I had never tried to do this without needed-for-boot? though.
<rekado>I’ll give this a try again.
<rekado>civodul: would it be okay if I rebooted berlin to test this?
*rekado syncs /gnu/store to the external storage before rebooting
<kristofer>hello guix!
<rekado>mbakke: is it fine to push things to staging or is it currently frozen?
<mbakke>rekado: Staging is open for business. It probably won't get started until core-updates is merged though.
<rekado>okay, thanks
<rekado>I just want to push a change to remove custom bootstrap phases.
<mbakke>rekado: Great! Could be worth waiting until core-updates is merged in case it has already been fixed there.
<civodul>rekado: sure, you can reboot
*mbakke solves "invoke" conflict on r-with-tests (aaaede49 vs 2eaaadb4).
<mbakke>civodul: I'll start core-updates on Hydra shortly.
<kristofer>I'd like the vm to have a static internet IP. How do I setup a bridge with guix?
<rekado>mbakke: oh, sorry for creating more work for you!
<mbakke>kristofer: I use 'openvswitch' for that.
<mbakke>rekado: np, these things must happen :-)
*rekado still waits for /gnu/store to be synced
<rekado>rsync on the store is very slow :(
<rekado>there’s got to be a better syncing mechanism that takes into account that most of the directories are unchanged.
<pkill9>doesnt rsync already do that? only copy over unchanged files/directories
<rekado>maybe just “cp -au”
<rekado>yes, but it performs a lot of expensive checks, which slows it down.
<civodul>mbakke: maybe the web UI at is a bit better now, FWIW
<mbakke>civodul: Oooh, indeed. Showing only failed is nice, and logs too!
<civodul>rekado: "cp -au" is probably the best we can do, "rsync -u" might be close to that
<rekado>I wonder why guix-modular-master fails
<rekado>starting with my commit adding r-h5
<civodul>apparently it's a hook failure, not an actual build failure
<civodul>(i was wondering too)
<rekado>I might reboot berlin later tonight or tomorrow
<rekado>the sync takes too long
<rekado>hmm, this didn’t work
<rekado>the GRUB record seems to be wrong; it lists the initrd and kernel image as /store/… instead of /gnu/store/…
<rekado>that’s easy to fix
<rekado>when trying to boot, though, it says that the device with the given UUID does not exist.
<rekado>it’s booting now, but I don’t know if the device was mounted already
<rekado>seems stuck
<rekado>I see that sdc and sdc1 have been detected, but there’s no further boot progress
<rekado>rolling back
<hulten>Hi, I'm/Guix's having difficulties with profile symlinks.
<hulten>I am getting, when doing 'guix pull': guix pull: error: rename-file: Invalid cross-device link
<hulten>The only different device I can think of that could be involved is the one mounted on /home/.
<hulten>But it are all just symlinks (so there is not the principle issue of impossible hardlinks between different devices). Any idea?
<rekado>“guix pull” creates/created a profile at ~/.config/guix/current
<rekado>which version of Guix are you using?
<hulten>guix (GNU Guix) ed9d7cb4d95f8f4776e6fee2778ab52bc2852969
<hulten>$ realpath current
<hulten>(and this path exists).
<hulten>rekado: the 'current' link is from 11 Oct.
<rekado>that’s also the date of the commit
<hulten>That's consist at least :-)
<hulten>Should both ~/.guix-profile and ~/.config/guix/current point to my profile; if so, why do these links both exist? (They link to different profiles.)
<rekado>the commit before that turned ~/.config/guix/current into a symlink to /var/guix/profiles
<rekado>they are different profiles
<rekado>~/.config/guix/current is the profile that’s used exclusively for “guix pull”
<rekado>this profile only provides versions of Guix.
<rekado>~/.guix-profile on the other hand is where all your installed packages are.
<hulten>including (some version of) guix?
<rekado>you wouldn’t use Guix to install Guix.
<rekado>that would necessarily install an older version than the version you are using to install it.
<hulten>What would you use to install Guix?
<rekado>you wouldn’t do “guix package -i guix” but “guix pull” instead.
<hulten>Ah, I see.
<rekado>now, about this error
<rekado>is there some more information about where the error happens?
<rekado>what are the arguments to rename-file, for example
<rekado>I’m guessing that it’s trying to migrate the “guix pull” profile, or something like that.
<hulten>What is 'rename-file'?
<rekado>it’s a Guile procedure that renames a file.
<rekado>do you get a backtrace that you could paste somewhere?
<hulten>Installing gdb now.
<rekado>you don’t need it for a “guix pull” backtrace.
<rekado>Could you post the complete error message?
<hulten>I'll try to get more info, like a backtrace.
<rekado>Oh, that’s the full error message. Oh well.
<rekado>so, it does indeed try to migrate the profile.
<rekado>let me check the code to see how.
<hulten>In ~/.config/guix/ there is this: current current-1-link latest latest.old
<hulten>I guess the latest* symlinks is obsolete stuff?
<rekado>The “latest” stuff is old. The new “guix pull” no longer uses it.
<rekado>“guix/scripts/pull.scm” implements the migration.
<rekado>it only symlinks the profile to the new location.
<rekado>is this a reproducible error or does it no longer appear when running “guix pull” again?
<rekado>is ~/.config/guix/current a symlink?
<hulten>It is reproducible, in the sense that it keeps on doing it every time I do 'guix pull'.
<hulten>(I have no other systems where I get this error.)
<hulten>Yes, it is a link to current-1-link
<hulten>In the end (realpath) it links to /gnu/store/09vmdzhc9hn8f2jyl405p33imdn5wwvc-profile/, which contains stuff.
<hulten>So if it is just a symlinking issue, trying --bootstrap is nonsensical, raight?
<rekado>IIUC it should be a link straight to /var/guix/…/current-guix-123-link
*rekado runs “guix pull” now to get one of those links
<hulten>current-1-link -> /gnu/store/09vmdzhc9hn8f2jyl405p33imdn5wwvc-profile
<rekado>that’s what “guix pull” was trying to correct.
<rekado>currently, the profile lives in your home directory.
<rekado>it should live in localstatedir, though.
<rekado>I wonder why the migration fails.
<rekado>ah, I see.
<rekado>this was fixed in 8036b0942b89022147aaf9cd9940988fdbcc19ef
<hulten>Where is localstatedir?
<rekado>usually /var/guix
<hulten>OK, then it is :)
<rekado>but the problem is that in your version we used “rename”
<rekado>this doesn’t work across devices.
<rekado>so you may have to do this manually.
<hulten>OK, so it is a bug in an old version, or rather a shortcoming that gives problems across devices.
<hulten>I can symlink to the most recent guix-profile.
<rekado>it’s a problem with that slightly older version of Guix.
<rekado>hulten: does /var/guix/profiles/per-user/kodi/current-guix-1-link exist?
<rekado>you could symlink ~/.config/guix/current to /var/guix/profiles/per-user/kodi/current-guix-1-link
<hulten>The files/symlinks there are named guix-profile and guix-profile-*-link.
<rekado>that’s fine
<rekado>that’s for ~/.guix-profile
<rekado>we want to do the same thing for “current-guix”
<rekado>okay, like this:
<rekado>let’s create a link from /var/guix/profiles/per-user/kodi/current-guix-1-link to the current final target of ~/.config/guix/current (somewhere in /gnu/store).
<rekado>then let’s create a link from /var/guix/profiles/per-user/kodi/current-guix to current-guix-1-link in the same directory
<rekado>and finally, let’s link ~/.config/guix/current to /var/guix/profiles/per-user/kodi/current-guix
<rekado>you should then be able to run “guix pull” again.
<hulten>\/var/guix/profiles/per-user/kodi/current-guix-1-link doesn't exist.
<hulten>There are the guix-profile* symlinks.
<rekado>you should create that link and make it point to the current final target of ~/.config/guix/current (somewhere in /gnu/store).
<hulten>Need a bit of time.. should link correctly.
<rekado>the procedure here is: 1. create /var/guix/profiles/per-user/kodi/current-guix-1-link; 2. create /var/guix/profiles/per-user/kodi/current-guix; 3. redirect ~/.config/guix/current
<rekado>the final target remains the same, we just add some indirection here.
<rekado>put another way: ~/.config/guix/current -> /var/guix/profiles/per-user/kodi/current-guix -> /var/guix/profiles/per-user/kodi/current-guix-1-link -> /gnu/store/09vmdzhc9hn8f2jyl405p33imdn5wwvc-profile
<rekado>hope that makes sense
<hulten>I still get the same error, but let me carefully inspect if everything seems right to me...
<hulten>I linked current via current-1-link to /var/guix/profiles/per-user/kodi/current-guix. Now I link directly and 'guix pull' works!
<hulten>Even though using current-*-link links in ~/.config/guix/ does not make sense if it links to similar things in /var/guix/profiles/per-user/kodi/, I still find it strange that 'guix pull' fails on that.
<hulten>But things are working now, so thanks a lot, rekado!
<hulten>So the issue was: a bug in a specific version of Guix that made a migration triggered by 'guix pull' fail if symlinks cross different devices?
<rekado>it should be the other way around: current-guix should point to current-1-link.
<rekado>yes, that older version did *not* use “symlink” but “rename-file”
<rekado>and the rename syscall failed when the target and source are on different devices.
<hulten>I think it now works properly, because 'guix pull' created a new current-guix-2-link where current-guix now points to.
<rekado>okay, good.
<rekado>sorry about this hiccup.
<hulten>No problem.
<hulten>Apropos, as Guix may be nearing 1.0, what does the develop model look like then? Will there be a separate 'stable' branch?
<hulten>To compare with, I'm also using OpenBSD-current, which has *never* issues in my experience. Could one expect Guix converging to something as stable as that?
<hulten>(It sounds a bit confusing, because OpenBSD also has a -stable branch, but usually, and always in my experience, -current is, in fact, without issues.)
<hulten>I should reformulate this in an e-mail to devel@, maybe. I'm being confusing.
<pkill9>can guix be run on any of the BSDs?
<rekado>pkill9: no.
<rekado>pkill9: it could probably be done, though. It’s more realistic than porting to macOS.
<rekado>hulten: we like to consider the possibility of a “stable” branch independent from 1.0.
<rekado>maintaining a “stable” branch for the package collection is a lot of work, and I don’t think that we could guarantee to maintain it at the level of quality that would be required.
<rekado>we’d need more contributers for that
<rekado>a stable branch would require security fixes to be backported and breaking changes to be worked around.
<rekado>I also think that there is little to be gained when roll-backs are so cheap
<rekado>with the new “guix pull” mechanism we expect to be able to at least provide a stable roll-back mechanism.
<rekado>(“guix pull” was much less reliable in the past, but I think now the kinks have been worked out.)
<hulten>rekado: yes, if 'guix pull' is robust, providing reliable roll-backs, this is good.
<hulten>Maintaining an extra branch may cost too much resources.
<hulten>I think the question (always?) is if package maintainers provide the level of quality that we want.
<hulten>Similar issues are in OpenBSD, where *ports* may not work, but I have never seen a(n OpenBSD) *package* fail.
<rekado>not all packages get the same amount of attention
<rekado>we have a percentage of packages that are broken.
<hulten>What do you do with those packages?
<rekado>many of them are fixed when they have responsive maintainers or when they are used by a number of people.
<hulten>Would they be removed if they are broken for too long?
<rekado>but there are some that are rather obscure
<rekado>if nobody notices that they are broken because nobody uses them … does the package really exist in that case…?
<hulten>Or very difficult, maybe. I can imagine that TexLive is difficult, e.g.
<rekado>texlive is too important to be broken.
<hulten>I am happy to hear that.
<Laalf>can you chroot in a guixsd system?
<rk4>Laalf: i'd be surprised if there was a distro where you couldn't, given it's a linux syscall
<Laalf>rk4: i dont know if you can in nixos and i dont know about guixsd.
<Laalf>since nothing is really there, there is nothing to chroot
<rk4>all you need to chroot is a process and a file tree, surely?
<rekado> now uses Guile-Email instead of mailutils thanks to Arun. If you find any new bugs or problems displaying issues, please report them to me.