IRC channel logs


back to list of logs

<thomasd>Hi, seems like there's a problem with the channel log?
<sneek>Welcome back thomasd, you have 2 messages.
<sneek>thomasd, ozzloy says: yeah! i'm a big fan of steven pinker
<sneek>thomasd, ozzloy says: yeah! i'm a big fan of steven pinker
<civodul>thomasd: yes gnunet_bot had disappeared for a while
<civodul>but it seems to be back up
<civodul>bah, mit-krb5 has a silly test that hangs on i686
<civodul>ACTION tempted to disable it
<efraim>sounds like a similar reason i left python-efl at 1.16
<rekado>eigen also has a broken test on i686.
<civodul>for Eigen it's less surprising (numeric stuff), and it's also less critical (few packages depend on it)
<civodul>new news!
<efraim>apache2 question: if I drop files into /var/www/ it should just work for serving them?
<roelj>civodul: Cool
<z0d>usualy yes
<z0d>but better check virtualhost declarations and DocumentRoot
<z0d>but most default installations use /var/www
<z0d>in the Debian/Ubuntu family, that is
<efraim>on debian, one said root was /var/www, other said root was /var/www/html, so I moved the folder there
<z0d>well, Debian usually puts a default page into the DocRoot
<z0d>so you can check whether it's in /var/www or /var/www/html
<efraim>default page is at /var/www/html/index.html
<efraim>also had a permissions problem, so lots of fun
<efraim>everything is visible now
<civodul>"Could not build a python embedded interpreter" <- (core-updates)
<civodul>does that ring a bell to someone?
<ng0>I ran once more into a reason why I'd like to have guix on my servers soon. as we don't have searx packaged yet, is there some special up-to-date openssl debian-package-repository thing i don't know about? searx just broke because debian.
<sneek>Welcome back ng0, you have 1 message.
<sneek>ng0, pksadiq says: I asked you for the output of "ctypes.util.find_library('m')" just to check if 'libm'-the math library-is found right by guix. Afaik it has nothing to do with or libssl (I saw in patch you sent to mailing list).
<ng0>later tell pkssadiq: oh... thanks for the info. but it fixed something, although not the pyqt4 part, where i'm still stuck.
<ng0>sneek later tell pkssadiq: oh... thanks for the info. but it fixed something, although not the pyqt4 part, where i'm still stuck.
<sneek>Will do.
<ng0>sneek later tell pkssadiq: but it could also been some of my substitutes whic hfixed it
<davexunit>civodul: the new article about system tests is *awesome*
<davexunit>sorry I didn't get a chance to review it yesterday
<davexunit>I'm in the middle of a move and when I'm not at work I'm rarely at the keyboard.
<civodul>davexunit: np!
<civodul>glad you like it ;-)
<civodul>moving is always a chore
<thomasd>There was a discussion about marketingspeak etc few days ago. I think blog posts like these will definitely get people interested in Guix
<davexunit>I would like it if we could re-render these savannah blog posts with some nicer typography and CSS
<thomasd>The html version of the Guix manual at looks really good IMO.
<civodul>we should stop using Savannah for the blog articles, because it's terribly ugly and limited
<civodul>help is definitely welcome!
<davexunit>civodul: if there were more hours in the day...
<AndChat|217856>Thomasd it's unreadable on mobile phones
<AndChat|217856>Did you try to read it on a mobile phone ?
<davexunit>right now I've gotta figure out how to do https downloads with basic auth
<davexunit>civodul: yesterday I started using 'test kitchen' with Chef, which provides something very similar to the new system tests
<civodul>davexunit: do you have a pointer?
<davexunit>and here's the test framework
<rekado>do we have some ... erm... "authority" over the layout and typography on Savannah?
<davexunit>and here are the very first tests I've written for a server running mysql
<davexunit>rekado: I imagine making any changes to savannah will be a difficult task
<rekado>socially difficult?
<ng0>ah. I just remember something. our perl-test-harness needs an update for torsocks iirc.. and the upcoming torsocks-2.2.0 will have some useful changes
<davexunit>civodul: the guixsd test framework is clearly superior, but I think we could use a library of procedures that make testing common things easy.
<rekado>more macros!
<davexunit>you can see from my example code how easy it is to test that a process is listening to a particular port
<thomasd>AndChat|217856: I didn't know that. I'm no html expert, but it looks like it should be possible to make such a layout work on a mobile phone as well?
<davexunit>thomasd: the CSS just needs some tweaks to be "responsive"
<davexunit>I believe we get the CSS from gnulib, so the improvements should be made to gnulib so that every GNU project using it sees the benefit
<ng0>i don't know when it will be released, but is the changelog for the current -rc1 i try to build as 2.1.0 failed.
<civodul>davexunit: looks interesting, though indeed a bit ad hoc from the examples i can see at
<davexunit>civodul: yeah it's totally ad-hoc
<davexunit>what I think we can borrow is the terseness of common tests
<civodul>yes, definitely
<davexunit>you can see how these serverspec tests often boil down to regexp matching strings
<davexunit>we can avoid that :)
<ng0>i think 2.2.0-rc1 has the problems of 2.1.0 fixed. I could build it
<ng0>though the dns test must be patched again i think
<ng0>i don't think we can use this instead of 2.1.0 update of torsocks? it's an rc, not release yet.
<ng0>I applied the current torsocks patch, it builds succesfully with it
<davexunit>civodul: yesterday you said that something in guix does do basic auth correctly, but I can't recall what it was. do you remember?
<davexunit>you referred to some module.
<davexunit>was it (guix http-client)?
<roelj>Sorry to interrupt, I get this when invoking 'guix system vm-image my-config.scm': I don't understand how it can get a kernel panic when it prepares a VM image..
<wingo>roelj: i think that means that `init' exited
<wingo>maybe init threw an error
<civodul>davexunit: yes, exactly
<davexunit>civodul: so, should I alter (guix build download) to use (guix http-client)?
<davexunit>or would it be acceptable to just hack the basic auth code into (guix build download) directly?
<civodul>davexunit: unfortunately it's messier than this :-) there's redundancy between (guix build download) and (guix http-client), but also different things
<civodul>we should merge what's mergeable, and keep the rest separate
<davexunit>that's what I was anticipating
<civodul>i think bavier` looked at it a while back
<civodul>but yeah, we should move the basic auth code to (guix build download)
<davexunit>civodul: so, adding basic auth would only be a few additional lines. large refactor not needed. sound OK?
<davexunit>OK thanks
<civodul>but Someone will have to refactor it eventually :-)
<davexunit>yes, of course.
<davexunit>that sounds like a much larger project because I see so many differences
<civodul>roelj: probably you need a larger image size, see --image-size
<roelj>wingo: Thanks. I guess I'll just start debugging again and see you in another year from now :)
<davexunit>and likely don't see several more subtle differences :)
<civodul>i'm a bit guilty
<wingo>an amusing error to copy-file tho (Success :P)
<ng0>I did sent an pre-release patch of torsocks 2.2.0-rc1 to the list. whoever wants to test it in advance can apply it to their guix master
<davexunit>civodul: changing (guix build download) won't rebuild the world because the derivations are fixed output derivations, correct?
<wingo>davexunit: of course if there is a patch to guile, it might make it into 2.0.12!
<civodul>wingo: i think copy-file has always had troubles getting errno right :-)
<wingo>so, what if we release 2.0.12 tomorrow
<wingo>with a patch to skip invalid .go files
<davexunit>wingo: hmm, well, what do you think about guile's http-get automagically adding an "Authorization" header if the URI has userinfo?
<wingo>oh, that's a guile discussion i guess
<davexunit>guile would need a base64 module at that point.
<davexunit>(it would be nice if guile just came with modules for base32/base64)
<davexunit>(but that's another discussion :)
<wingo>davexunit: no idea... is it always basic authorization? i guess you would have to add another kwarg or something to indicate that it's basic authorization, not digest
<wingo>or whatever that other one that no one uses is
<davexunit>wingo: right
<davexunit>so maybe it doesn't make sense.
<wingo>davexunit: maybe add a #:basic-authorization (user . pw) kwarg, and guile will do the base64 encoding
<davexunit>wingo: I guess I should look at how other languages deal with this
<wingo>ACTION nod
<davexunit>I can't remember how the ruby libraries I use do it
<wingo>by all means build something quick in guix if that's what you want to do, but eventually it should go to guile i think
<davexunit>yeah, it would be nice if Guile had a way to handle it nicely.
<davexunit>yay it works
<jlicht>davexunit: what are you working towards?
<davexunit>jlicht: downloading source code from web servers that use HTTP basic authentication
<davexunit>jlicht: welcome back, will repeat my last message.
<davexunit>jlicht: downloading source code from web servers that use HTTP basic authentication
<jlicht>davexunit: thanks. that sounds like it could be a nice addition to guix
<davexunit>I have a pretty immediate use-case for it for an internal project.
<ng0>. torsocks on/off works wth the torsocks-2.2.0-rc1 i sent, so it's at least functional.
<efraim>ng0: it might just be me but I don't see an attached patch
<ng0>woops. i think it forgot to actually add it >.<
<ng0>i'm still processing from 26k messages down to an amount which is manageable without notmuch
<ng0>will take some time to find the new message
<davexunit>basic auth patch inbound
<davexunit>should hopefully be uncontroversial :)
<bavier`>the new system tests are seriously wicked :)
<lfam>Is anybody able to apply this patch? <>
<ng0>wild. notmuch displays the message, but the other application does not foind it.
<efraim>can't apply it from mutt
<ng0>found the message. I forgot that I set sent messages to auto "read"
<ng0>patch is coming now
<ng0>efraim: sent. though it's no official release yet. tor-dev mail is here, forgot to link to it:
<efraim>i got odrobian (debian) installed on my odroid-c2, next to install guix dependencies to test my aarch64 patches
<efraim>already had to reset once, got bit again by the systemd-230 no-network on boot issue
<efraim>last time my pi rebooted I hooked up a keyboard and no monitor and did it all blind
<davexunit>mthl`: how usable would you say Cuirass is?
<davexunit>my current needs are simple. I need to maintain a list of packages that will be built automatically with a specific version of guix.
<davexunit>I have two versions of Guix I need to build for, and the packages to build with each are different.
<mthl`>davexunit: with some changes that could work.
<davexunit>mthl`: cool :)
<davexunit>for now I might just write a shell script to maintain the package list
<davexunit>then migrate to cuirass later
<mthl`>davexunit: do you just the package to be built for using the substitutes or do you need to access the build logs?
<mthl`>*do you just need
<davexunit>mthl`: for now it's enough to just build things
<davexunit>I fetch substitutes from Hydra for most things and build custom stuff
<davexunit>a glorified mirror
<davexunit>I use 2 versions of the guix client on it
<davexunit>the latest stable release to build a new guix
<davexunit>and then that new guix to build everything else
<mthl`>I need to allow specifying a commit hash in the job spec you could use Cuirass this
<mthl`>*job spec *and* you
<mthl`>*use Cuirass *for* this
<efraim>do we want to expand the build-from-source part of the manual to add distro specific package lists/hints?
<efraim>i needed dpkg-dev on debian in the end
<mthl`>davexunit: modulo probable CLI/API breakages :)
<thomasd>Hi Guix,
<thomasd>I'm packaging a small Guile module (, what's the best way to maek guile compile the source files?
<thomasd>(e.g. a good example in the Guix source I can look at?)
<davexunit>thomasd: looks like that project is missing a build system
<davexunit>the correct answer should be "make"
<davexunit>but "guild compile" is how you compile guile source files
<thomasd>:) it's a very small module (to add some color to the Guile repl), the included Makefile just copies the source to the site-dir
<davexunit>right, which is incomplete. :)
<thomasd>so is build-system-trivial the right choice for that, or gnu-build-system, with all phases disabled?
<davexunit>as you can see.
<davexunit>the correct thing is to fix upstream
<davexunit>the just-get-it-done thing is to modify gnu-build-system
<davexunit>trivial-build-system should almost never be used
<davexunit>gnu-build-system will automatically patch shebangs in shell scripts and other nice things
<thomasd>When you say "fix upstream", do you mean that every project should include a configure script, or would a plain Makefile suffice for simple projects (in which case all phases but "make install" would be disabled)?
<davexunit>thomasd: using GNU autotools would be preferable
<davexunit>a simple makefile often leaves out many details
<davexunit>one often wants to set the installation prefix
<davexunit>or which guile to use when compiling
<myglc2>I'm a little confused re 'guix system vm' vs 'guix vm-image'. Is the only difference that '... vm' provides a script to run the vm?
<janneke>myglc2: the vm-image is self-contained and could be moved to another host
<janneke>vm imports /gnu/store of the host
<myglc2>janneke: Ahh! Thanks!
<janneke>our icecat identifies itself as Windows NT 6.1; is that a feature?
<janneke>"Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Firefox/38.0"
<janneke>to be on the safe side i shoud say: `my icecat'...
<efraim>substitute: warning: TLS 'SERVER NAME' extension not supported
<ijp>janneke: don't even try to understand user agents, it's not worth it
<ijp> the style gets old very quickly, but it's as good an explanation as any
<myglc2>I am on a guix/Debian headless server & when I do 'guix system vm ...' I get GuixSD in QEMU in a X11 window but it hangs at "Please type some random data ..." How do I avoid this?
<bavier`>myglc2: that message is from lsh
<bavier`>we don't have an openssh service yet
<janneke>ijp: i was just confused, thinking a windows user was looking at my web server...turned out it was me!
<myglc2> bavier: Thanks. I need lsh to ssh into these vms, don't I? So do I look at the lsh doc to see if I can make it happy?
<bavier`>myglc2: you can tell lsh-service that you'll initialize the randomness generator yourself
<myglc2> bavier: OK Many thanks!
<rekado>I’m having a weird problem with libreboot and GuixSD.
<rekado>but first I need to make sure everything is as it should be
<rekado>should “lsblk -f” show that my root partition on which GuixSD is installed has a label matching the label in /etc/config.scm?
<rekado>because it doesn’t
<rekado>my /etc/config.scm says that the label is to be “guix-root” yet “lsblk -f” doesn’t show this to me.
<rekado>my problem is that on starting the machine libreboot does not always see my Guix root partition.
<rekado>I tried for 20 minutes without being able to boot.
<rekado>then started again and suddenly I would see two bootable partitions (one with my ancient Fedora on LVM and the other GuixSD)
<rekado>I wonder why this is.
<petter>I have no experience with label, but specifying the partition has been troublefree for me
<rekado>hmm, okay, I’ll just try rebooting. Maybe I’ll find something.
<paroneayea>hey rekado
<rekado>hey paroneayea!
<rekado>I liked your article in the FSF bulletin.
<rekado>(only just received it)
<paroneayea>rekado: :)
<paroneayea>rekado: I should blog about it
<paroneayea>rekado: so I don't know about your setup, but here's mine:
<rekado>yeah, it’s a good topic to think about.
<paroneayea>rekado: btw our conversation at FOSDEM helped inspire it!
<paroneayea>if I get that blogpost out there I'll thank you for that ;)
<paroneayea>yay it's finally on
<civodul>rekado: hmm does Libreboot care about your root partition's label?
<rekado>I really don’t know :-/
<paroneayea>rekado: so, libreboot should look for your boot partition
<rekado>all I know is that *sometimes* the partitions appear and I can get to the next stage (the GuixSD grub), but most of the times I’m just stuck.
<paroneayea>and you can have it load a grub config from there
<rekado>as an additional data point: my disk in an X200 (the spare machine I had for two days) always worked.
<paroneayea>rekado: so, if you symlink on your boot partition:
<rekado>i.e. boot into Libreboot GRUB, then select the partition, boot GuixSD with the GRUB on disk.
<paroneayea>ln -s /boot/grub.cfg /boot/libreboot_grub.cfg
<paroneayea>*might* help
<rekado>I’ll try that, thanks
<rekado>I have /boot/grub/grub.cfg
<rekado>should it be /boot/libreboot_grub.cfg or in /boot/grub/?
<rekado>never mind, I’ll just see for myself
<civodul>rekado: GRUB itself is on the MBR or something equivalent, not on the root partition (at least, not its stage1)
<paroneayea>rekado: /boot/grub/
<civodul>so that sounds more like a hard disk detection failure?
<paroneayea>sorry my mistake
<rekado>paroneayea: ok
<rekado>civodul: yeah, that’s what I was thinking too.
<rekado>but my disk is fine.
<rekado>but it could be that there’s some confusing data on it, given its history
<civodul>yeah, could be many things :-/
<rekado>I haven’t tested suspend to RAM yet; I hope that works. In that case it wouldn’t matter too much.
<rekado>anyway, gotta reboot now. Curious. If you don’t hear from me in the next 20 mins it didn’t improve.
<rekado>I rebooted three times and it worked each time.
<rekado>I no longer have to select a partition.
<rekado>now I just wait for the timeout on the on-chip GRUB and I’m shown the MBR GRUB, which then boots GuixSD.
<rekado>so maybe we should do something like this by default?
<rekado>thanks paroneayea for the hint!
<rekado>ACTION –> zzZz
<civodul>rekado: ISTR mark_weaver wrote that newer Libreboot versions read /boot/grub.cfg directly
<civodul>good night anyway!