<divansantana>hmmm, after a recent guix update my iptables nat rules are broken with "can't initialize iptables table `nat': Table does not exist" <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. <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>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>=================================== 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/test_berkeley_db.py:33: 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? ***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 <rekado>oh, that means you’re using a pretty old version. <rekado>you just need guile-gcrypt then. <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>but to get there from an older version means pain, I’m afraid. <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. <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>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? *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 <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>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 <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>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 berlin.guixsd.org. <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>civodul: would it be okay if I rebooted berlin to test this? *rekado syncs /gnu/store to the external storage before rebooting <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>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. *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>yes, but it performs a lot of expensive checks, which slows it down. <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 <rekado>I might reboot berlin later tonight or tomorrow <rekado>the GRUB record seems to be wrong; it lists the initrd and kernel image as /store/… instead of /gnu/store/… <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>I see that sdc and sdc1 have been detected, but there’s no further boot progress <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>\/gnu/store/09vmdzhc9hn8f2jyl405p33imdn5wwvc-profile <hulten>rekado: the 'current' link is from 11 Oct. <rekado>that’s also the date of the commit <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>~/.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. <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. <rekado>it’s a Guile procedure that renames a file. <rekado>do you get a backtrace that you could paste somewhere? <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>this was fixed in 8036b0942b89022147aaf9cd9940988fdbcc19ef <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>we want to do the same thing for “current-guix” <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 <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. <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: 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. <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>issues.guix.info 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.