*davexunit notices that guix 0.6 build has been failing on hydra for a long time <davexunit>the i686 build, that is. no wonder I can't install it <jxself>A new machine for Hydra is needed. <jxself>More RAM, more disk space, more CPU horsepower, etc. <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 <davexunit>I had screw around with grub on this machine to boot from the right partition, but it booted <davexunit>"In procedure network-interface-flags: No such device ***jxself_ is now known as jxself
<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? <civodul>sneek: later tell SideEffffECt please bring up the determinism issue to guix-devel@gnu.org <bavier`>is there any form of ngettext for two numeric values? <civodul>bavier`: good question, i don't think so <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 <DusXMT>In the GNU System, where is the dynamic linker? (ld.so) <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/ld.so.1 <mark_weaver>try this: readelf -l ~/.guix-profile/bin/ls | grep 'interpreter' <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 ld.so, 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. <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 pressed Page Up repeatedly until he found it <mark_weaver>DusXMT: when you say "the system starts behaving like if I deleted ld.so", 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. <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>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... <DusXMT>is that a kernel module? Or some sort of configuration? <DusXMT>mmm. Are you installing the system from 0.6, or the dev version? (I'm certain the latter, just making sure) <davexunit>it's exactly as in the manual in the installation section <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 ld.so disappears, the entire glibc directory in the store disappears <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) <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>which instructions are you following, and how are you deviating from them? <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 :-/ <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 <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. <mark_weaver>I'd like to test i686 installation on my X60. is there a recent precompiled image somewhere? <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... <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. <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>my machine here at the FSF doesn't pull down mail to my worcester.edu address. <DusXMT>When installing the system, is it okay to use substitites from hydra? <davexunit>civodul: thanks so much. I didn't think to check that commit, I made a bad assumption. <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 ;-) <civodul>it needs to be writable by the 'hydra' user <mark_weaver>civodul: what are the correct perms and ownership for it? <civodul>you can make it finer-grain by using a special group for 'hydra', etc. <civodul>i'm away for a few hours, but it seems to be making good progress <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>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. <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. <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>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 bug-guix@gnu.org ? <DusXMT>mark_weaver: okay, email sent (from merkur32@gmail.com) <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? <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 <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 <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. <mark_weaver>davexunit: are you able to build USB install images on the X60? <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 <mark_weaver>it might be as simple as removing "-enable-kvm" from guix/build/vm.scm <mark_weaver>iiuc, -enable-kvm makes qemu faster but is not strictly needed <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 