IRC channel logs

<civodul>Hello Guix!

<amz3>héllo ^^'

<amz3>ark, libreboot doesn't to have detected my libreboot_grub.cfg

<civodul>amz3: you have an X200?

<amz3>X60

<amz3>X60s

<civodul>ok, nice

<amz3>anyone has package for qtile please ? #lazy

<amz3>all the dependencies are met, but there is no package for it

<amz3>please :))

<amz3>ACTION packaging

<civodul>amz3: go ahead :-)

<civodul>mark_weaver: we have this coreutils test failure on ARM: http://hydra.gnu.org/build/668859/nixlog/15/raw

<civodul>mark_weaver: what kernel is running? it might be a kernel-specific inotify issue

<civodul>3.19.5-00082-gc34755f

<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>since fixing that, things got much better.

<mark_weaver>ACTION looks

<civodul>oh, ok

<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>hmm

<mark_weaver>hydra-slave1 is now using the same kernel that I've had such good success with on armhf with current 'master'.

<civodul>ok

<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>civodul: done

<mark_weaver>(just now)

<mark_weaver>I'm going to have to go afk for a while soon..

<civodul>thanks

<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...

<civodul>np!

<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.

<civodul>FSVO "interesting" ;-)

<civodul>ACTION tries a rebuild

<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.

<civodul>oh

<mark_weaver>iirc, in that case, the second build attempt failed and the third one succeeded.

<civodul>could be non-deterministic then

<mark_weaver>yeah, I think so.

<mark_weaver>those failures were for /gnu/store/mxivs3mdwnl5121cy9q73dz4klis6nq4-coreutils-8.24.drv with output /gnu/store/00l77xqh7ahyka4s7h7c8lmh22lklb7a-coreutils-8.24

<mark_weaver>(both the same derivation)

<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>woow :-)

<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.

<sneek>davexunit, civodul says: http://runc.io/ <-- kinda like 'guix container' (not as good, though)

<davexunit>civodul: runc is the new name of docker's libcontainer, basically.

<davexunit>but not controlled entirely by docker.

<mark_weaver>davexunit: I suspect it's not too hard.

<civodul>or its command-line interface no?

<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.

<civodul>heh

<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.

<mark_weaver>(maybe from the serial port?)

<davexunit>mark_weaver: oh cool.

<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>s/before/prefer/

<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?

<civodul>mark_weaver: do we perform these?!

<civodul>hmm dunno

<mark_weaver>civodul: oh, well, I thought it would be good to have the logs available on hydra for coreutils

<civodul>yeah

<civodul>well there's http://hydra.gnu.org/build/668859/nixlog/15/raw

<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>civodul: okay, as you wish :)

<mark_weaver>obviously it would be nice to get to the bottom of this.

<mark_weaver>okay, I have to go afk. ttyl!

<civodul>ttyl!

<civodul>of course it passed this times :-/

<civodul>but i stopped it before completion

<davexunit>iyzsong: nice xfce patch!

<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>via http://git.savannah.gnu.org/cgit/guile-lib.git/tree/src/term/ansi-color.scm

<civodul>any takers? :-)

<davexunit>civodul: where do you envision such colors?

<civodul>'guix package' could highlight actions it's taking, like "The following packages will be installed", etc.

<davexunit>ah, cool.

<civodul>'guix build' could use different colors for the '@' messages from the daemon, for lines matching "error:", things like that

<davexunit>that would indeed be nice

<davexunit>make users happier

<civodul>it seems to be one of these things one must have

<civodul>like a nice web site and a progress bar ;-)

<civodul>and it's certainly more comfortable

<davexunit>yeah a little polish like this works well.

<davexunit>iyzsong: that antialiasing tweak is nice!

<davexunit>I reconfigured and rebooted and things look nicer

<davexunit>small guix and scheme mention here: http://www.phoronix.com/scan.php?page=news_item&px=Debian-GNU-Hurd-2015-State

<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 :)

<mark_weaver>(but agree that colors are reasonable by default)

<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

<amz3>to understand

<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>alternatif: what were those modules?

<davexunit>I think it would be reasonable to include them in the default initrd

<alternatif>pata_atiixp and pata_acpi

<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

<mark_weaver>alternatif: ^^

<mark_weaver>so I'm not sure what's going on.

<mark_weaver>amz3: what version of libreboot are you using?

<amz3>I don't know, it's glubglub x60s, I bought 9month ago

<amz3>no more than that

<amz3>more than one year

<mark_weaver>hmm, it might be too old to have that feature

<francis7>amz3, it's gluglug, not glubglub

<amz3>I asked on libreboot, someone told me to inspect the rom

<francis7>Also, it renamed to minifree. http://minifree.org/

<amz3>nice to know

<francis7>amz3, check the notes about guix on http://libreboot.org/docs/gnulinux/grub_boot_installer.html

<francis7>amz3, and check the notes about booting it on http://libreboot.org/docs/gnulinux/grub_cbfs.html

<francis7>uh

<francis7>ignore that last link

<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

<francis7> http://libreboot.org/download/

<francis7> http://libreboot.org/docs/install/index.html#flashrom

<francis7>amz3, ^

<amz3>I don't have "load config from usb0", I edit the hdd entry to boot usb

<francis7>mark_weaver, I type faster than you ;)

<mark_weaver>heh :)

<francis7>ACTION blames his dvorak layout

<francis7>amz3, update libreboot

<francis7>version 20150518 is the latest version.

<mark_weaver>amz3: yes, I think that will fix the problem. do not be afraid :)

<amz3>:)

<francis7>If your X60 is from gluglug/minifree and you haven't updated libreboot yet, then you most likely have libreboot version 20141015

<francis7>that's ancient

<mark_weaver>I flashed my X60 many times, and never had a problem

<francis7>(gluglug stopped selling X60 ages ago)

<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

<francis7>it's pretty easy

<francis7>I'm sure you'll be fine.

<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>The track record so far is very good.

<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 think so.

<francis7>Not sure about 20150518

<francis7>I re-added it recently, not sure if that was before or after 20150518

<francis7>(re-added text mode images)

<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>ok

<amz3>I'll report back later, because I got to go

<amz3>reallly thanks for the help

<mark_weaver>np!

<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

<davexunit>sprang: same

<davexunit>I use the gnome icon theme

<davexunit>and no sound icon

<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>I see it in pavucontrol too

<sprang>well, glad it's not just me then :)

<sprang>would an alternate theme potentially provide the right icon?

<davexunit>some other icon theme maybe

<davexunit>I don't know how to "inspect" that widget to see which icon it looks for

<davexunit>if I knew that much, I could debug further

<mechanical>mark_weaver

<civodul>sprang: pavucontrol has all the "right" icons for me

<civodul>i have adwaita-icon-theme in my profile

<civodul>in the same profile as pavucontrol

<sprang>civodul: installing adwaita-icon-theme resolved the issue

<civodul>sprang: before that you had gnome-icone-theme?

<civodul>*gnome-icon-theme

<davexunit>that's what I use

<civodul>so it seems like gnome-icon-theme lacks some icons or something, no?

<davexunit>yeah

<davexunit>switched to adwaita and it works

<civodul>weird

<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

<sprang>ah

<mechanical>Hey davexunit.

<davexunit>hey mechanical

<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.

<davexunit>okay.

<mechanical>Sorry about that.

<davexunit>no worries.

<mechanical>Good luck with Guix and all that.

<davexunit>thanks!

<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

<davexunit>awesome :)

<amz3>thx :)

<amz3>the libreboot tools are another issue to tackle

<francis7>mark_weaver can help you with that.

<amz3>I mean, to package

<francis7>amz3, mark_weaver was/is doing that.

<amz3>ah ok

<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.

<francis7>have to break that habit

<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>ACTION needs to update node

<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

<davexunit>so I have to build the URL myself

<civodul>yeah

<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

<davexunit>yeah that might work

<civodul>but really, we need to generalize 'guix refresh'

<davexunit>yes

<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>yes, we do see them

<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?

<civodul>you mean in build logs?

<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

<codemac>I don't do much perl, I apologize

<civodul>ah no, they are not generated from the set of installed packages

<civodul>anyways, good night/day!

IRC channel logs

2015-09-09.log