IRC channel logs
2015-09-09.log
back to list of logs
<amz3>ark, libreboot doesn't to have detected my libreboot_grub.cfg <amz3>anyone has package for qtile please ? #lazy <amz3>all the dependencies are met, but there is no package for it <civodul>mark_weaver: what kernel is running? it might be a kernel-specific inotify issue <mark_weaver>civodul: we had both 'gawk' and 'tar' test failures, and those indeed turned out to be caused by a kernel issue: lack of CONFIG_DEVPTS_MULTIPLE_INSTANCES <mark_weaver>ah, this coreutils test failure is the same test that failed on MIPS, iirc. <civodul>here the test checks whether 'tail' notices file removals via inotify <civodul>it looks as though 'tail' did not receive the IN_DELETE_SELF event <mark_weaver>hydra-slave1 is now using the same kernel that I've had such good success with on armhf with current 'master'. <civodul>would be nice to try to do the same as the test and run it in strace <civodul>i see that strace is not installed there and installing it would build the world <civodul>maybe we should get it from the host distro for now? <mark_weaver>the same failure *did* happen on MIPS, while building coreutils-minimal <mark_weaver>I saved the failure log and restarted some builds. maybe it worked on the second try <mark_weaver>civodul: see ^^. the failure was for /gnu/store/wxln1pscniimchnznaxkq00k1zmbsfbh-coreutils-minimal-8.24.drv with output <mark_weaver>... sorry, if the output directory is in the log, I'm failing to find it easily... <mark_weaver>oh, output /gnu/store/2bf8w77izn024hsmhvirz0r7hhmlwjcj-coreutils-minimal-8.24 <civodul>the one i'm looking at is /gnu/store/h1cf9c701h2xx5la7zw0mp7rxrlzabwm-coreutils-8.24.drv <mark_weaver>it's interesting that the same failure happens on both armhf and mips. <mark_weaver>also, I have failure logs of the same failure happening before on MIPS, on June 28. twice in a row, about 5 hours apart. <mark_weaver>iirc, in that case, the second build attempt failed and the third one succeeded. <mark_weaver>those failures were for /gnu/store/mxivs3mdwnl5121cy9q73dz4klis6nq4-coreutils-8.24.drv with output /gnu/store/00l77xqh7ahyka4s7h7c8lmh22lklb7a-coreutils-8.24 <mark_weaver>this single Novena board, running with only 2 cores instead of its 4 (for lack of a fan) is building faster than both of the Loongson 3A machines together. <civodul>still, 300s to run coreutils' configure <davexunit>mark_weaver: is there any somewhat easy way to install a fan on the novena? I don't have my board in front of me. <sneek>Welcome back davexunit, you have 1 message. <davexunit>civodul: runc is the new name of docker's libcontainer, basically. <davexunit>civodul: I submitted a documentation patch to libcontainer awhile ago and they told me to send all future patches to runc <civodul>but yeah, i got the impression that it's a politico-commercial thing <mark_weaver>also, apparently they've added a kernel feature that throttles in software to prevent overheating. might be sufficient. <mark_weaver>but I haven't built the kernel with that feature yet. <mark_weaver>of course, for a build slave, it would be better to just add a fan. <mark_weaver>ACTION tries restarting the coreutils build on armhf, after saving the failed log <mark_weaver>davexunit: iirc, there's info in one of the novena forums about getting power for a fan from one of the connectors on the board. <davexunit>yeah that would be a nice addition to the setup to prevent overheating <mark_weaver>as a laptop, I'd probably before to run without a fan, but a build slave should run as fast as possible. <mark_weaver>civodul: on MIPS, all the cross-builds for mips64el fail due to a failure linking glibc-cross: /tmp/nix-build-glibc-cross-mips64el-linux-gnuabi64-2.22.drv-0/build/libc_pic.a: error adding symbols: Archive has no index; run ranlib to add one <civodul>mark_weaver: i'm already rerunning the failed build on hydra-slave1 <mark_weaver>civodul: is that the same failure that happens on i686? should we add armhf to the same logic that prevents cross-builds from i686 to mips64el? <mark_weaver>civodul: oh, well, I thought it would be good to have the logs available on hydra for coreutils <mark_weaver>so I try to avoid building things outside of hydra on any build slave <civodul>i avoid that too, but in this case i'm just restarting a failed build in the hope it will fail again :-) <mark_weaver>obviously it would be nice to get to the bottom of this. <amz3>is there anybody who installed guixsd on an X60s with libreboot, I can't get libreboot grub to boot on guixsd grub.. <civodul>unrelated, but i think we need colors now! <civodul>'guix package' could highlight actions it's taking, like "The following packages will be installed", etc. <civodul>'guix build' could use different colors for the '@' messages from the daemon, for lines matching "error:", things like that <civodul>it seems to be one of these things one must have <civodul>like a nice web site and a progress bar ;-) <davexunit>I reconfigured and rebooted and things look nicer <mark_weaver>amz3: I run GuixSD on Libreboot machines (both X60 and X200) <mark_weaver>you need to make /boot/grub/libreboot_grub.cfg be a symlink to grub.cfg <mark_weaver>and then, with the default grub.cfg that's burned into Libreboot, the default menu item will load GuixSD's grub configuration. <mark_weaver>civodul: regarding colors: I request a way to turn it off :) <alternatif>I think initrd should be added to the bare-bone default configuration. <mark_weaver>alternatif: I'm not sure what you mean, but we always use an initrd in GuixSD. we literally don't support *not* using an initrd in GuixSD <mark_weaver>(if you don't specify an 'initrd' field, it has a sensible default) <amz3>thx mark, but mine doesn't. I need to reflash <amz3>before that I need to inspect the rom <alternatif>I am talking about the 'waiting for root to appear' message thrown by dmd. I solved that by declaring the initrd field explicitly in my OS configuration file, because i was missing some ata modules in the default initrd image. <davexunit>I think it would be reasonable to include them in the default initrd <davexunit>mark_weaver, civodul: what do you think about adding the above modules to the default initrd? <mark_weaver>davexunit: afaict, they are already there by default. in fact, I had to take steps to remove them for MIPS, since they aren't available on MIPS. <mark_weaver>see 'linux-modules' in 'base-initrd' in gnu/system/linux-initrd.scm <mark_weaver>according to the git history, they were added by default on November 13, 2014 <amz3>I don't know, it's glubglub x60s, I bought 9month ago <amz3>I asked on libreboot, someone told me to inspect the rom <mark_weaver>francis7: I suspect in this case, he already installed GuixSD, and it's just a matter of whether his grub.cfg looks for libreboot_grub.cfg <francis7>actually, ignor me. that grub_cbfs.html link is fine <francis7>mark_otaris, if he has an X60 from gluglug, then he probably has an old version of libreboot that doesn't check for libreboot_grub.cfg <francis7>amz3, update to the latest version of libreboot and then try again. <mark_weaver>francis7: amz3 might be using a version of libreboot from before libreboot_grub.cfg was added <amz3>I don't have "load config from usb0", I edit the hdd entry to boot usb <mark_weaver>amz3: yes, I think that will fix the problem. do not be afraid :) <francis7>If your X60 is from gluglug/minifree and you haven't updated libreboot yet, then you most likely have libreboot version 20141015 <mark_weaver>I flashed my X60 many times, and never had a problem <francis7>That version had issues booting the guix installers. <francis7>update to version 20150518 and you should be fine <amz3>ok thx I'm reading preparing the procedure <mark_weaver>I remember being a little nervous about flashing my machine the first time, but especially if you use libreboot's pre-built release images, they are well tested before release. <francis7>and if you do brick it (there's a 0.8% chance that you will), note that I'm the gluglug/minifree owner and main libreboot developer. <francis7>since you bought it from gluglug/minifree, that means I'll fix it for you if you brick it <amz3>it won't happen, I'm confident ;) <francis7>I've accepted returns before, to unbrick customers laptops after they bricked them. very rarely <francis7>because I try to make sure that the chance of the customer/user bricking their laptop is below 1% <francis7>even in the absolutely worst case scenario, you'll be fine. <mark_weaver>francis7: do you still offer both vesa and text-mode images for X60? <francis7>I re-added it recently, not sure if that was before or after 20150518 <mark_weaver>amz3: if there's a choice, I recommend using the vesa images, because those are the ones I've been using and can verify that they work with GuixSD and other systems I've tried. <francis7>the text-mode images are only needed for memtest86 really <francis7>and even then, you could use it on a serial console if you wanted <francis7>amz3, yes, use the images with vesafb in the file name <francis7>those ones have a GNU playing a flute in them <francis7>(or on the next release, it has the libreboot logo) <amz3>I'll report back later, because I got to go <amz3>reallly thanks for the help <sprang>some of my apps display generic image icons instead of the expected image for buttons... for example it's happening with the pulse audio panel item in xfce4 <sprang>anyone else experience that? I get a lot of conflicting icon cache messages when I install/update things... arbitrarily choosing the wrong one? <sprang>well, glad it's not just me then :) <sprang>would an alternate theme potentially provide the right icon? <davexunit>I don't know how to "inspect" that widget to see which icon it looks for <civodul>sprang: pavucontrol has all the "right" icons for me <civodul>i have adwaita-icon-theme in my profile <sprang>civodul: installing adwaita-icon-theme resolved the issue <civodul>sprang: before that you had gnome-icone-theme? <civodul>so it seems like gnome-icon-theme lacks some icons or something, no? <civodul>another thing we should at least document <sprang>I didn't even have to explicitly switch, just had to install it <civodul>yes because installing it rebuilds the icon theme cache <mechanical>I was going to tell mark_weaver this, but I've stopped with getting GuixSD running on mips64el. I got bored with it and I'm half the potential userbase that would be interested. I was just coming by to let you know. It seemed rude to do otherwise. <amz3>I managed to upate libreboot and it works as expected so I boot directly into guixsd <amz3>I made a package for libusb-compat-0.1 <amz3>which was required for libreboot flash tool <amz3>I will send it later to the ml <amz3>the libreboot tools are another issue to tackle <francis7>No harm in helping. Ask him what you can do. <francis7>I still pronounce it goo-ix in my head, even though I know it's pronounced geeks. <efraim>ffmpeg 2.8 was released. is there enough that depends on that for it to be pushed to core-updates instead of master? <civodul>efraim: "guix refresh -l ffmpeg" says it's 11 packages, so it's fine to update in master <davexunit>I think a tool that took a package name + a version and returned the sha256sum for the source for that version would be useful <davexunit>but we lose the string-append or whatever that creates the source record <civodul>instead of string-append, we could use a hypothetical url-append <civodul>which would be pretty much like 'list' <civodul>such that we would retain the URL construction info <civodul>but really, we need to generalize 'guix refresh' <efraim>civodul: thanks, I forgot about that command <codemac>for these generated .pod etc files - shouldn't we see them like any other compiled artifact? The perl packages would be inputs, and then .pod files would be some packaging output? <civodul>the problem is when there are two or more Perl packages in a profile <civodul>they all provide a .pod file, leading to a collision <codemac>but I thought the .pod file is generated right? <codemac>shouldn't we see that like we see compilation? (input + input + input) => output? <codemac>What I'm trying to say is I thought .pod files were generated from the set of things currently installed, similar to info directory files? or am I just completely mistaken <civodul>ah no, they are not generated from the set of installed packages