IRC channel logs


back to list of 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?
<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:
<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>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>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>civodul: done
<mark_weaver>(just now)
<mark_weaver>I'm going to have to go afk for a while soon..
<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.
<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.
<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: <-- 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.
<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>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>well there's
<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>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>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:
<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.
<amz3>nice to know
<francis7>amz3, check the notes about guix on
<francis7>amz3, and check the notes about booting it on
<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>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 :)
<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>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
<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
<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?
<davexunit>that's what I use
<civodul>so it seems like gnome-icon-theme lacks some icons or something, no?
<davexunit>switched to adwaita and it works
<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>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.
<mechanical>Sorry about that.
<davexunit>no worries.
<mechanical>Good luck with Guix and all that.
<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>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'
<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!