IRC channel logs


back to list of logs

*davexunit notices that guix 0.6 build has been failing on hydra for a long time
<jxself>Yes, for many moons.
<davexunit>the i686 build, that is. no wonder I can't install it
<davexunit>I feel dumb.
<jxself>Meh. Don't.
<jxself>A new machine for Hydra is needed.
<jxself>More RAM, more disk space, more CPU horsepower, etc.
<jxself>More everything. :)
<davexunit>I need to figure out how to make this install image use the dev version of guix, I thought it was already using it
<davexunit>I guess the gexp #$guix is choosing the stable package, not the dev package. let's see if I can change that.
<davexunit>can't figure out why it's using 0.6 instead of 0.6.20b1d19
<davexunit>I checked what the gexp expands to and it's the dev versioin.
<davexunit>%base-packages includes the dev version as well
<davexunit>okay, disabled test suite for 0.6 on installation image... now we're installing!
<davexunit>I guess this is a temporary problem since what will be guix 0.7 has a working test suite.
<davexunit>damn it. system install finished, but I got a kernel panic when I booted
<jxself>Oh? What about?
<jxself>But at least it installed. :)
<jxself>Think positively. :)
<davexunit>yeah, it's a big step forward.
<davexunit>I had screw around with grub on this machine to boot from the right partition, but it booted
<jxself>And then you ended up in BASH?
<davexunit>"In procedure network-interface-flags: No such device
<davexunit>I am not in bash
***jxself_ is now known as jxself
<civodul>Hello Guix!
<sneek>civodul, you have 2 messages.
<sneek>civodul, mark_weaver says: I think I fixed the problem on the build slave. can you try again?
<sneek>civodul, SideEffffECt says: Hi, I've come across this pull-request in nixpkgs so I would like to ask, how is guix standing? how is it good at binary determinism? this post also talks about big performace hit on GCC. so how is it with Guix?
<civodul>sneek: later tell SideEffffECt please bring up the determinism issue to
<sneek>Got it.
<bavier`>is there any form of ngettext for two numeric values?
<civodul>bavier`: good question, i don't think so
<civodul>at least not in Guile
<bavier`>a message could be split in two, but I'd worry about losing context during translation.
<civodul>if that's the only concern, you can add a "TRANSLATORS:" comment that translators will see in the pot file
<bavier`>I might be able to just do some checks outside of the format statement
<civodul>as long as the code doesn't make any assumption about the format of plurals, that's OK
<bavier`>got it
<DusXMT>In the GNU System, where is the dynamic linker? (
<davexunit>try: find /gnu/store -name
<DusXMT>What I think is happening with my setup is that the dynamic linker disappears, since every program starts remporting "no such file or directory"
<mark_weaver>DusXMT: in #guix, the dynamic linker is in /gnu/store/*-glibc-2.19/lib/
<mark_weaver>try this: readelf -l ~/.guix-profile/bin/ls | grep 'interpreter'
<mark_weaver>that will tell you precise file
<mark_weaver>(or replace some other executable)
<DusXMT>mark_weaver: thanks
<DusXMT>Does this mean that if someone installs a new version of glibs, all programs need to be modified to use it?
<mark_weaver>DusXMT: well, they don't need to. they can keep using the same version of glibc they were originally linked with. but if they want to use the new glibc, then they need to be rebuilt, yes.
<davexunit>civodul: I lost the link to the guix sticker image. if you get a chance, could you send it again?
<DusXMT>mark_weaver: because i'm having a strange problem when I try to install man-db on the guix system. When I try to guix package -i man-db, it eventually hangs and the system starts behaving like if I deleted, I'll try to reinstall and see if that's happening
<mark_weaver>DusXMT: this is both a strength and a weakness. it means that if there's a security flaw in glibc, you need to rebuild everything. on the plus side, you can install a new version of glibc without risking bricking your system.
*jxself points davexunit to
<davexunit>thanks jxself
<mark_weaver>civodul: would you like to try the build slave again?
<davexunit>I always forget that I can just check the channel logs for these things...
<jxself>Or your own personal logs.
*jxself pressed Page Up repeatedly until he found it
<davexunit>I don't keep logs.
<mark_weaver>DusXMT: hmm
<mark_weaver>DusXMT: when you say "the system starts behaving like if I deleted", do you mean that other shell sessions where commands used to work suddenly stop working?
<mark_weaver>DusXMT: if you can describe what's happening more precisely, I might be able to guess what's going on.
<mark_weaver>DusXMT: that's very odd.
<DusXMT>Okay. After a certain point in the installation program, it crashes that substitute-build or something like that is missing, and then it gives that same error for every command
<DusXMT>"File not found" or something like that
<DusXMT>I'm going to experiment with it, to see if I can find out what's happening
<DusXMT>and then, once that happens, if I try to reboot, I get a kernel panic when starting, tried to kill init
<davexunit>DusXMT: I get kernel panics when booting, as well.
<DusXMT>davexunit: did it work the first time?
<DusXMT>Maybe your user has gid 100?
<DusXMT>That was my first problem, changing it to 1000 solved it
<davexunit>it's because it's installing the wrong version of guix.
<davexunit>it's using the 0.6 release instead of the dev version
<davexunit>so I looked at %base-packages, and it includes the dev version.
<DusXMT>strange... it seems to be working for me
<davexunit>and I looked at install.scm, and it also uses the dev version inside of a gexp
<DusXMT>but even if it installs guix 0.6, I don't think it should kernel panic...
<davexunit>it's trying to use qemu-networking
<DusXMT>is that a kernel module? Or some sort of configuration?
<davexunit>it's for use with VMs
<davexunit>which is all that 0.6 could do
<DusXMT>mmm. Are you installing the system from 0.6, or the dev version? (I'm certain the latter, just making sure)
<davexunit>dev version
<DusXMT>May I see your os definition?
<davexunit>it's exactly as in the manual in the installation section
<davexunit>I just used ludovic's minimal config
<DusXMT>Hmm. Then you're probably wiser than me, sorry
<davexunit>trying to reduce the number of variables in this problem so I did everything pretty much per the documented installation instructions
<DusXMT>The only thing I did different is that I'm not installing off of the USB stick, but I don't think that should make a big difference
<DusXMT>yes, that's what's happening, but not just disappears, the entire glibc directory in the store disappears
<DusXMT>this is strange...
<jxself>What are you installing it from then?
<DusXMT>jxself: from an existing GNU/Linux system on a different partition. Maybe I should try the USB-image then?
<jxself>Files randomly disappearing could also be the sign of a more serious problem. Perhaps it's time to check the device health with smartctl?
<DusXMT>But I've been reliably able to reproduce this problem, why does it happen with exactly the same directory always? (but I will check out smartctl)
<mark_weaver>I would try the USB-image
<phant0mas>I am downloading it now to try it as well
<DusXMT>I don't think that'll be possible, this thing has broken USB ports, any USB device keeps disconnecting and reconnecting
<DusXMT>examining the file system, the filder with glibc doesn't exist, but there's a file with the same name, ending with .lock
<DusXMT>and it's the only .lock file in the store
<mark_weaver>how exactly are you trying to do the install?
<mark_weaver>which instructions are you following, and how are you deviating from them?
<mark_weaver>DusXMT: ^^
<DusXMT>mark_weaver: I have a GNU/Linux system installed on /dev/sda1, with the dev version of GUIX installed on it, and from there, I filled out an os definition, created a partition /dev/sda3, formatted it, mounted it, and then I called guix system init
<civodul>mark_weaver: yes i'm trying now, "waiting for a build slot" it says
<DusXMT>It boots properly, works okay, until it tries to install "glibc-2.19-locales"
<DusXMT>maybe if I add it to the base system, I won't have this issue? (heads off to try it out)
<mark_weaver>civodul: The logs on the build slave show no login attempts from you since yesterday morning.
<civodul>DusXMT: when does it try to install that?
<DusXMT>civodul: when I run, as a user: guix package -i man-db
<civodul>mark_weaver: yes i'm running "guix build ... -s mips64el-linux", but it's waiting :-/
<civodul>business on the side
<civodul>i think we can merge gettext-upgrade now:
<jmd>Does that mean that now would be a good time to run guix gc ?
<sneek>Welcome back jmd, you have 1 message.
<sneek>jmd, mark_weaver says: see the 'setuid-programs' field of 'operating-system'.
<civodul>davexunit: i'm preparing answers and solutions to the problems you reported :-)
<civodul>davexunit: it's really great that you keep testing despite all these failures
<civodul>i imagine it's a lot of frustration
<civodul>but it's very useful feedback
<davexunit>yeah it can be frustrating, but I want a working Guix system badly, and I know that getting it to run well on a laptop that is RYF certified will be a good thing to show off.
<civodul>after the release, i'd like to come up with a test strategy of the installation image using QEMU
<civodul>i'm not yet sure how to do that, but that's doable
<davexunit>do simulate different system architectures and things?
<civodul>to simulate what you would normally type at the keyboard when installing the system
<jmd>mark_weaver: So how does this setuid-programs thing work?
<civodul>and to make sure that the installed system actually works
<civodul>jmd: see the brand new commit 0ae8c15 :-)
<davexunit>civodul: cool, I'd be interested in how that works.
<jmd>Ohhh. I'm in the middle of a build. I'm not going to pull just yet!
<davexunit>I did a lot of unit/integration testing at my previous job.
<mark_weaver>jmd: I don't know. The message I wrote you was originally from civodul, but he made a mistake asking sneek to deliver it to you.
<davexunit>civodul: oh, cool commit. I've been meaning to learn more about that.
<davexunit>glad there's documentation. :)
<mark_weaver>I'd like to test i686 installation on my X60. is there a recent precompiled image somewhere?
<mark_weaver>(for USB installation)
<civodul>mark_weaver: nope, you'd have to build it yourself :-/
<davexunit>mark_weaver: when civodul pushes another patch or two, I can build the image and upload it somewhere if you need.
<civodul>i'd like to upload a new x86_64 image, but i can't promise an i686 one because of lack of disk space...
<mark_weaver>no worries, I can build it myself.
<mark_weaver>davexunit: what patches are you waiting for?
<mark_weaver>(wondering if I should wait for them also)
<davexunit>mark_weaver: at least on i686, the install image tries to install guix 0.6 instead of the dev version, and there are a few problems. notably, make check fails and your installation will fail as a result.
<davexunit>and if you disable the test suite, like I tried, you'll get an installed system that kernel panics.
<mark_weaver>davexunit: ah, thanks!
<civodul>davexunit: i fixed that just a minute ago
<davexunit>I'm not sure what the bug is, because from what I can the dev version is specified in %base-packages and in the install.scm operating-system definition.
<davexunit>civodul: yeah? is it pushed? I'd like to view the patch
<davexunit>I couldn't spot the error, so I want to learn a bit. :)
<civodul>i replied to your email actually, with the explanation
<civodul>it's a bit convoluted as you'll see ;-)
<davexunit>ah, cool. I'll go fetch mail, then. :)
<davexunit>my machine here at the FSF doesn't pull down mail to my address.
<davexunit>civodul: ohhhhhhh
<davexunit>the commit just needed to be updated.
<DusXMT>When installing the system, is it okay to use substitites from hydra?
<davexunit>DusXMT: yes
<davexunit>civodul: thanks so much. I didn't think to check that commit, I made a bad assumption.
<civodul>well it's not intuitive
<civodul>mark_weaver: can you create "${state-directory}/gcroots/tmp" on the MIPS machine?
<civodul>that's hopefully the last thing we need to tweak ;-)
<mark_weaver>civodul: will do now!
<civodul>it needs to be writable by the 'hydra' user
<mark_weaver>civodul: what are the correct perms and ownership for it?
<civodul>hmm, 777? :-)
<civodul>you can make it finer-grain by using a special group for 'hydra', etc.
<mark_weaver>civodul: okay, I made it 1775 with group hydra
<civodul>cool, thanks
<civodul>"sending 158 store files to"...
<civodul>i'm away for a few hours, but it seems to be making good progress
<mark_weaver>great, thanks!
<jmd>civodul: If I understand that text correctly, the programs are copied from the store to /run/setuid-programs when guix packge --install is run, and the setuid bit applied ?
<mark_weaver>civodul: will it overwrite things that are currently in my store with the same hash?
<civodul>jmd: no, that when installing the whole OS
<civodul>mark_weaver: no, it'll leave them as is
<mark_weaver>s/my store/the store on the build slave/
<mark_weaver>civodul: the emacs packages built by the other mips build machine probably won't work on systems with 64K pages.
<jmd>So a setuid program cannot be installed by the package manager?
<civodul>mark_weaver: oh, could you file it in bug-guix?
<mark_weaver>civodul: the emacs build output ends up depending on the page size of the currently-running kernel on the build machine.
<civodul>or fix it? ;-)
<civodul>ah ok
<civodul>that rings a bell
<mark_weaver>it's because of the unexec.
<civodul>i need to leave now, ttyl
<DusXMT>Excelent, I foundthe problem I was having
<mark_weaver>not sure how to fix it properly. I think that mips build machines should be running with 64K page size.
<mark_weaver>civodul: okay, bye!
<DusXMT>Basically, the guix on my host OS installs the /var/guix directory according to how it's configured (in my case, /usr/local/var), but it should install it into /var, this is a bug I believe
<mark_weaver>ah, that makes sense.
<mark_weaver>I always build guix with "--prefix=" i.e. an empty prefix.
<mark_weaver>but I agree that it should do the right thing in any case. could you send mail about it to ?
<DusXMT>mark_weaver: okay, I'll do
<DusXMT>mark_weaver: okay, email sent (from
<DusXMT>yup, it works perfectly now :)
<mark_weaver>DusXMT: that's good. thanks for diagnosing it!
<DusXMT>now just to set up the bootloader to be aware of my other os, set up networking, and I think I'll have myself a pretty neat operating system from you guys
<davexunit>mark_weaver: are you still in need of an i686 install image?
<DusXMT>I winder, is it safe to compile and install guix from git on a working GNU System setup?
<davexunit>at least I think so.
<DusXMT>Because with the version it ships, it can't successfully do a "guix pull", and if I try to "guix system reconfigure", it wants to download guix 0.6 (the same problem you are having I think)
<davexunit>yeah, I don't know how to actually upgrade the guix that the system uses
<davexunit>haven't made it that far..
<DusXMT>I think "guix system reconfigure" is supposed to do that, but as it is, it would actually downgrade it
<davexunit>you could keep an uninstalled copy of the guix git repo and use ./pre-inst-env to try to reconfigure your system with the latest patches
<davexunit>maybe that would work
<DusXMT>I guess that could work, thanks
<DusXMT>also, one thing I suggest trying, with the USB installation image, download guix from git and install the system with that (eg. with ./pre-inst-env), I installed mine with the guix from git, just make sure you pass --prefix=/ to configure
<mark_weaver>you'd need to first install a development environment, in order to build guix from git.
<DusXMT>hmmm, good point
<mark_weaver>davexunit: are you able to build USB install images on the X60?
<davexunit>mark_weaver: no, I build them on my x220
<mark_weaver>ah, okay.
<davexunit>which is x86_64, but I request and i686 image.
<mark_weaver>it would be good to eliminate the dependency on KVM.
<davexunit>I noticed that it was still a dependency when my /dev/kvm didn't have the proper permissions
<davexunit>I wonder it will take to remove that
<mark_weaver>it might be as simple as removing "-enable-kvm" from guix/build/vm.scm
<mark_weaver>for now I'm playing with guix system init
<mark_weaver>iiuc, -enable-kvm makes qemu faster but is not strictly needed
<davexunit>it would be nice as an optional feature
<davexunit>does kvm have limited architecture support?
<mark_weaver>it requires special hardware support; not all processors have it.
<davexunit>oh yeah, it requires hardware virtualization support.
<davexunit>I had to enable that on my x220 before things would work
<jmd>wget -O - 2> /dev/null | tail -30 | dubya