IRC channel logs

2016-01-12.log

back to list of logs

<civodul>lfam: it's still useful
<civodul>relatively little has changed, except for the renaming i just pushed
<lfam>Okay, I wasn't sure how much the new service API related or did not relate to changes in dmd itself. I'm trying to get started defining services. The path is definitely not as clear as getting started defining packages.
<civodul>ah yes, could be
<civodul>the part of the service API in GuixSD that is tied to the Shepherd is dmd services
<civodul> https://www.gnu.org/software/guix/manual/html_node/dmd-Services.html
<civodul>but really only the 'start' and 'stop' fields depend on dmd's API
<civodul>ACTION -> zZz
<civodul>good night/day!
<toyo>how can i run guix in a vm, i'm trying to but can't
<NiAsterisk>sorry for being slow with gnunet-gtk (and the rest on my list). I've had some computers to fix, some systems to redo and still some servers to move and think about design for some other thing etc etc.. so horribly slow everything that I am looking into time management now with serious interest for the first time in my life. when I have time issues solved I will be able to work on those packages.
<lfam>toyo: What did you try so far?
<toyo>i'v tried booting as a harddisk, but i get this: waiting for partition 'gnu-disk-image' to appear..
<lfam>toyo: Did you try the `guix system vm` or `guix system vm-image` commands? They make it easy to use GuixSD in QEMU
<toyo>the thing is that i don't get a root shell, i get something like "scheme@(guile-user) [1]
<lfam>How did you invoke QEMU? There is some info here: http://lists.gnu.org/archive/html/guix-devel/2016-01/msg00406.html
<lfam>I'm trying to improve the documentation of this feature
<lfam>You want to look at the one under "This appears to be the minimum QEMU invocation that works:"
<lfam>And adapt it to your system's architecture, and probably give it more RAM if you have it to spare
<lfam>Those instructions apply to `guix system vm-image`. I'm not sure `guix system disk-image` because I haven't tried that yet
<lfam>Yessssss I have a working espeak :)
<francis7>mark_weaver, can you (and also inform others of this) check what it says on https://libreboot.org/faq/#epochfail
<francis7>Quote: "This seems to be an issue in Linux kernel version 4.3 and higher, though it may also affect older releases. We know that it does not affect Linux kernel version 3.13 (the one used in Trisquel 7, which many libreboot developers and users use). A bisect of the upstream linux kernel Git repository is in order, so that we can find out which commit introduced this issue."
<francis7>Can you try said bisect?
<francis7>If not, can you talk to a few others and suggest the same?
<francis7>I ask, since you use Libreboot on a system that is affected
<francis7>We need to know which kernel commit caused this, as a necessary prerequisite for a fix upstream (kernel.org)
<lfam>francis7: You might also try emailing 22274@debbugs.gnu.org. That is the bug tracker for our related bug: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22274
<francis7>sent
<francis7>paroneayea, ^
<civodul>Hello Guix!
<marusich>Hey there. Hey civodul, do you use GuixSD?
<civodul>yes of course
<civodul>:-)
<marusich>Do you have email working?
<marusich>Like, from emacs etc.
<civodul>yes
<civodul>i use smtpmail in Emacs
<marusich>I have spent hours trying to figure out how to get it to work, but I think I am missing something.
<marusich>Ah, I see, so you have an SMPT server somewhere and emacs just connects to that, huh.
<marusich>SMTP*
<civodul>right
<civodul>it's easier and always works
<marusich>I see. Maybe I should just find an email service provider that gives me that...
<marusich>I use gmail right now for various reasons, and they do not provide such an interface. I think they did in the past, but not any more
<civodul>oh, i see
<marusich>I have often worked on systems where a program like mail (e.g., mailutils' mail program) "just works"
<taylan>Gmail offers SMTP
<marusich>I was surprised to find that mail did not "just work" for me here in GuixSD
<marusich>which is fine; I don't mind getting my hands dirty
<marusich>I was just curious to know how you were doing email, since I seem to be doing it wrong
<civodul>ideally we'd have postfix or something running as a daemon
<marusich>taylan, I have followed some guides I found online, and I recall getting an error from Gmail's seservers along the lines of "we have disabled this service, sorry"
<civodul>i think wingo looked into MTAs and such a few weeks ago
<marusich>civodul, yeah, but even then, wouldn't the MTA have to send the email somewhere?
<civodul>right
<taylan>marusich: well I just sent an email with Gmail SMTP so I know it works somehow...
<marusich>I sent an email about it to the list a month or so ago, but I have not had time to dive into it in earnest. I thought I'd try again tonight, and I thought I might be able to get away without setting up a full-fledged MTA.
<marusich>taylan, curious. Maybe I should look harder into that.
<taylan>in my authinfo.gpg I have: machine smtp.gmail.com login scrubbed@gmail.com port 587 password scrubbed
<taylan>and: machine imap.gmail.com login scrubbed@gmail.com port imaps password scrubbed
<marusich>is authinfo.gpg the same one mentioned here? http://www.emacswiki.org/emacs/GnusAuthinfo
<marusich>also, civodul, on an unrelated note, i have often wondered: what is that scissors cut and paste thing you often use in email lists? Is it some kind of emacs feature? I know git uses scissors in that fashion, but you seem to have some ability to use it for quoting text that I wish I could also do :)
<marusich>the thing that looks like ---8<---
<taylan>marusich: yes it's that. (one can also export the environment variable AUTHINFO to point to a file in a different place than the ones listed there.)
<marusich>taylan, can I expect that to only work for Gnus in emacs?
<marusich>er, for gnus
<marusich>I am not familiar with it so I don't know if it's part of emacs orn ot
<taylan>I don't know if other mail clients than Gnus use it, but I don't think it's really Gnus-specific
<taylan>though googling "authinfo file" makes that EmacsWiki page appear at the top on Google :\\
<taylan>well, the file format is "netrc"
<marusich>OK, well, at least I know it's possible, then.
<marusich>I need to go sleep, but I'll see if I can use the info you've given me to get it working. It would be nice to be able to send email from within GuixSD.
<marusich>Thank you for the help
<taylan>happy to help
<alezost>marusich: these "--8<-[...]" things are created when you select a region and press "C-c M-m" on it during writing a mail ("M-x compose-mail" which is on "C-x m" by default)
<marusich>Neat. I'll try that, once I get my email setup working!
<alezost>marusich: sending mails with Gmail works for me on GuixSD. I use the same settings as taylan
<marusich>You also use Gnus?
<alezost>yes
<marusich>I see
<civodul>marusich: the scissors come from message-mark-inserted-region (C-c M-m)
<civodul>oh alezost already replied
<civodul>hello alezost!
<alezost>civodul: hi
<alezost>I mean "Hi! :-)"
<civodul>heheh
<civodul>alezost: did i tell you that M-x guix-hydra is awesome?
***Digitteknohippie is now known as Digit
<alezost>civodul: thanks! :) I think it would be also good to list evaluations, but hydra does not provide an API for this currently
<taylan>how do I go on about debugging an .sh test failure? specifically, guix-environment.sh, and specifically when running distcheck from an out-of-tree build.
<taylan>or at least get a log file or so, so I can make a useful bug report...
<lfam>Something like `sh -x guix-environment.sh`?
<taylan>lfam: indeed, but I figure it's called in a special environment by make check?
<lfam>Oh. I would like for a place in the Makefile to insert the `-x` parameter where the shell is invoked
<lfam>I'm sure there's a better way
<taylan>ah, found a log file digging around
<taylan>and it already contains -x output it seems
<ziz15>hello,could someone tell me how i can make the raw img into a bootable iso i would like to try the os inside vbox and i cant find i way to do so.Thanks
<taylan>strange location: $builddir/guix-0.9.1/_build/sub/test-suite.log. distcheck is funny.
<lfam>ziz15: Do you mean the installer image from the web site or the vm image you make with `guix system vm-image`?
<ziz15>lfam: the installer image from the web site
<lfam>ziz15: Did you know there is a built-in VM creator you can use with `guix system vm-image`? It creates qemu images
<ziz15>lfam: no i didnt know..I help on how to maybe?
<lfam>As far as the installer image, it is bootable. I don't know how to make it work in VirtualBox, but it boots on bare metal if you use `dd` to put it on some device like a USB drive. But it's just an installer image, very bare bones
<ziz15>lfam: i know how to burn it with dd in a usb stick my problem is i cant make it into a bootable iso
<ziz15>lfam: i can make it just an iso but not bootable
<lfam>I don't know, it boots just fine for me once I tell the machine to boot from the USB drive
<lfam>Are you selecting the USB drive as the device to boot from?
<ziz15>lfam: i think you dont understand what i want..i dont want to boot the os from a usb but inside a virtuabox..but thanks for your help
<lfam>ziz15: Sorry I can't help more. If you google how to use virtualbox with a live usb image, you will figure it out
<lfam>It's a very common use for virtualbox
<ziz15>lfam: Thanks
<lfam>ziz15: Here's a guide to installing the Debian live ISO in Virtual Box. I imagine the same steps will work for the GuixSD installer: http://www.brianlinkletter.com/installing-debian-linux-in-a-virtualbox-virtual-machine/
<rekado>R-3.2.3 fails on ARM because of ... a typo?
<rekado> http://hydra.gnu.org/build/921724/nixlog/1/raw
<rekado>"logical vectors are black and white" vs "locigal vectors are black and white"
<rekado>nah, that's probably not it. I see the same message for mips, but it doesn't abort.
<rekado>so, the log doesn't tell us what really went wrong and caused the tests to fail.
<rekado>"Error: testing 'stats' failed" and "Execution halted".
<rekado>not much to go by
<rekado>found some software that links with GLPK but is released under a proprietary license.
<rekado>is this legal considering that GLPK is under GPLv3+?
<rekado>GLPK is optional here; alternatively, they link with the proprietary CPLEX.
<civodul>rekado: i've seen that before too
<civodul>anything linked against GPLK needs to be GPLv3+
<civodul>OTOH, if it's an optional dep, it's probably a gray area
<civodul>well, not so gray to me, but with a bit of bad faith, one could argue
<rekado>I suspect they'd just remove the ability to link with GPLK.
<rekado>I'll open a bug report later.
<davexunit>holy cow... installing texlive for the first time
<davexunit>texlive-texmf-2015 (3.62GiB installed)
<efraim>just saw the mail popup for guix bug 22274 and read "bug#22274: epicfail" instead of "bug#22274 epochfail"
<efraim>that's why I normally build it
<efraim>source is 'only' 1.7GiB and takes me ~20 minutes
<civodul>davexunit: be patient! ;-)
<davexunit>letting it download while I work
<davexunit>starting to put together my presentation for next week
<civodul>cool
<davexunit>I have a bunch of loose notes thrown about, trying to figure out a good way to organize them.
<civodul>i usually start from random notes taken in an org file
<civodul>that makes it easy to move things around etc.
<davexunit>the rough idea is to discuss what I feel are the big problems with status quo package/configuration management tools, and then explain how Guix fixes each problem, giving quick live demos where I can.
<civodul>sounds like a plan
<efraim>they're tagging go-1.5.3 tomorrow(?), I feel a bit silly working on making go-1.5.2 build
<civodul>hopefully that won't be lost!
<efraim>I assume it'll just be a drop in replacement
<karhunguixi>on a general note, isn't it desirable to have as many versions as possible of a package?
<karhunguixi>so you can emulate another environment, f.ex. customerA's server setup
<efraim>one down side is bugs/security issues in unmaintained versions
<davexunit>karhunguixi: in general, we don't want to maintain versions that no packages are actually using.
<davexunit>the repository would grow out of control if we kept every version of everything.
<karhunguixi>ok
<davexunit>the nice thing about Guix is that it's really easy to create variants of other packages.
<davexunit>every time I need an old version of something for my personal usage, it's typically been quite easy to write the recipe I need by inheriting from the up-to-date package object in Guix.
<efraim>nix packages and bsd ports are great for tips for packaging
<efraim>@ build-succeeded /gnu/store/sqgb0p6ysxl58nw4vmi5l98b2slsbab0-go-1.5.2.drv -
<civodul>efraim: congrats!
<efraim>next step is to figure out a go-build-system
<karhunguixi>do you have go-1.4 as a requiremet for go-1.5?
<efraim>yeah
<efraim>I gave up for now on building gccgo-5
<davexunit>efraim: can go do dynamic linking?
<davexunit>we would really like this.
<karhunguixi>i think dynamic linking has just been made possible
<davexunit>static linking is the norm in Go, and that is the worst thing ever.
<efraim>I don't actually know anything about go, but I think it's all static linking
<davexunit>yeah, that makes me wonder how much we really want a Go package.
<davexunit>civodul: what do we about languages where static linking is *the* way to do things?
<karhunguixi>"For the amd64 architecture only, the compiler has a new option, -dynlink, that assists dynamic linking by supporting references to Go symbols defined in external shared libraries." -- https://golang.org/doc/go1.5
<davexunit>amd64 only :/
<davexunit>so that feature isn't widely spread enough for it to work for us.
<davexunit>someone on HN once said "Go is a bold step backwards"
<davexunit>this is a perfect example of that
<civodul>indeed, this is a very surprising choice
<karhunguixi>I do development in Go and i would appreciate this package
<civodul>yes
<civodul>i think it's OK for us to provide packages of Go software, even if they are statically linked
<civodul>after all, there's nothing we can do about it
<davexunit>okay
<civodul>"not our fault"
<davexunit>yeah
<davexunit>makes sense
<civodul>efraim: does your Go package bootstrap from GCC 4.9?
<efraim>yeah
<efraim>well, from gccgo-4.9
<civodul>right
<civodul>nice work
<efraim>it would probably also build from gccgo-4.8
<civodul>IIUC Nixpkgs bootstraps Go 1.5 from Go 1.4, which seems to be bootstrapped from C
<efraim>go-1.5 came out to 258MiB, go-1.4 to 142MiB, I should probably try to separate out some outputs
<efraim>they have cgo enabled, I don't have that part yet
<civodul>ok
<efraim>it keeps on wanting to link to libgcc_s.so.1
<karhunguixi>the Go compiler tool chain was translated from C to Go in 1.5
<taylan>Rust too is young enough that it should be possible to bootstrap from C, though it's been ported to Rust a while ago.
<rekado>solfege needs the BROWSER environment variable to be set to some browser. It's bad that I had to read the documentation for a Python library it uses to learn that.
<rekado>there is no good way to let the user know after installation that they should set this variable, right?
<civodul>rekado: unfortunately no
<civodul>that would be worth a bug report upstream, though
<mark_weaver>civodul: our perl is ancient, and that's making it difficult to apply a fix for CVE-2015-8607
<mark_weaver>the oldest version that debian backported for is 5.20, and we're on 5.16
<mark_weaver>the newest version is 5.22.1
<mark_weaver>the update is not entirely straightforward because our existing patches don't apply cleanly to the new version
<mark_weaver>specifically perl-no-sys-dirs.patch
<mark_weaver>I looked at the new version of that patch in nixpkgs, but it introduces references to $sysroot and I'm not sure if it's right for us or not.
<mark_weaver>if you could take a look I'd be grateful
<mark_weaver>obviously this is for core-updates
<mark_weaver>I also looked at backporting the CVE fix to perl 5.16.1, but that's also non-obvious to me. the relevant code has changed radically.
<mark_weaver>the new nixpkgs no-sys-dirs patch is here: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/interpreters/perl/5.22/no-sys-dirs.patch
<mark_weaver>oh, wait, it's not actually introducing references to $sysroot. I must have been confused by looking at a diff of a diff.
<mark_weaver>I'll try again...
<mark_weaver>bah, perl-module-pluggable-search.patch doesn't apply either, and that entire module doesn't even seem to exist anymore, or has been renamed.
<rgrau>hi, are the hydra keys packaged with guixsd distribution? Can't find them anywhere. maybe I'm not supposed to use susbstitutes to build the distro for the first time. but just asking
<mark_weaver>rgrau: in the source tree, it's hydra.gnu.org.pub in the top-level of the source tree.
<mark_weaver>or /run/current-system/profile/share/guix/hydra.gnu.org.pub on a GuixSD system.
<mark_weaver>civodul: oh, nevermind, I see that perl has been updated already in core-updates. sorry for the noise.
***aeva` is now known as aeva
<aeva>hi - is anyone here who is running guixsd on a machine that uses an intel gma 4500mhd for graphics (eg, a thinkpad x200)? Performance seems ok for some tens of minutes before it utterly tanks until reboot (eg, 40fps for a while on a complex demo, and then crawls at about 6fps). This smells like a regression somewhere, but I'm not sure what to try to roll back or to what version, and I am having trouble finding current information on
<aeva>the chip and its drivers.
<efraim>so I just learned that python-3.5 came out 3 months ago
<mark_weaver>aeva: I ran GuixSD on a Libreboot X200, but alas my X200 developed a hardware problem, so I can't test now, but I guess that linux-libre is the thing to roll back.
<karhunguixi>i'm running a X200 right now (unsure about graphics), let me know if i can be of assistance
<mark_weaver>I never noticed the specific problem you're describing, but recent kernels have caused an issue with my X60 where I sometimes need to reboot in order to play videos. maybe it's related.
<mark_weaver>the error indicates that some resource cannot be allocated, and I guess maybe it's resources in the graphics accelerator that cannot be allocated.
<aeva>I've heard the sentiments expressed with running gnome3, but I'm running windowmaker. Particularly, open this http://mgrl.midnightsisters.org/demos/light/ in a browser that is set up for webgl (icecat works for me, might need to enable webgl in about:config)
<mark_weaver>I've tested icecat with webgl, and it seems to work for me without having to enable anything.
<mark_weaver>the only default blocker I know of would be librejs blocking javascript that's not marked as free.
<aeva>oh for fuck's sake lol
<aeva>the demo is free software
<aeva>anyways
<aeva>if you run it shortly after boot, it should run at about 40fps, and then the frame rate will tank to about 6 after a span of time that is in the magnitude of 10 minutes
<aeva>and performance won't recover until reboot
<mark_weaver>when I loade that page, i get: "deferred.frag failed to build. See javascript console for details."
<aeva>basically, my hopes for this machine was that it'll be a thing I can use to show off my free software games on a free software system to the other free software people lol, so this is pretty bad
<aeva>weird. try this one instead http://mgrl.midnightsisters.org/demos/particles
<mark_weaver>GuixSD on an X200 always had fairly good graphics acceleration for me.
<aeva>what was the version of linux-libre before your x200 broke?
<aeva>like I said, this smells like a regression :/
<mark_weaver>probably 4.2.x
<mark_weaver>we haven't updated mesa in a fairly long time, so my guess is that the kernel is the culprit.
<mark_weaver>we haven't updated X in a fairly long time either.
<aeva>I see :) well, thanks - I have a starting point now at least
<karhunguixi>i'm running the light demo currently, and it's been at 30-36 FPS for 3-4 minutes, then it dropped to 7 FPS
<aeva>yup! thats the problem!
<aeva>and it won't recover either?
<karhunguixi>right, just verifying
<aeva>yes :D
<karhunguixi>no, it's been exactly at 7 FPS for 2 minutes now
<aeva>the above is enthusiasm that this is reproducable
<mark_weaver>so, you could just revert the following commits to get back to linux-libre-4.2.6: 6b0d24b17cee1e4d0697c6ebf57be0a5cfb1075e 8ae95578a7a88554afe9b3bfa03881ee3206485b 7534370435e40b11b0b254753d63d2c27cc9a9a5
<mark_weaver>aeva: have you verified that the problem doesn't exist in linux-libre-4.2.x?
<mark_weaver>oh, sorry, I misunderstood what you wrote.
<davexunit>aeva: have you also ruled out that the problem isn't with your application?
<davexunit>for example, you could try running another program that uses OpenGL such as Minetest
<aeva>paron_remote reports that gnome3 has the exact same problem
<davexunit>okay
<aeva>and the problem doesn't occur in m.grl when ran on other machines
<davexunit>that's evidence enough for me
<aeva>:)
<aeva>would be cool if I could get this working in time for libre planet :D. I don't think I'll have time to tinker with the laptop in the next day or so, but I'll try rolling back the kernel before the week is out
<mark_weaver>on my X60, I'm getting less than 1 FPS on that program :-(
<davexunit>wow
<mark_weaver>if there's any display of the FPS, I'm not seeing it, but it's taking more than a second between updates.
<mark_weaver>this with linux-libre-4.4
<karhunguixi>current FPS is shown in top left corner
<mark_weaver>I saw that while it was loading, but never saw it again after I started seeing dark sky and snow
<rekado>I also only saw the FPS in the top left corner while it was loading.
<rekado>(on X200S)
<aeva>XD
<mark_weaver>hmm, but my machine has gotten into the bad state where I can't play videos either.
<karhunguixi>that particle demo took my X200 to its knees
<rekado>I haven't run the thing for longer than 1 minute, though (because I still need to do things)
<mark_weaver>the error as reported by mplayer is: X11 error: BadAlloc (insufficient resources for operation)
<aeva>x200 represents my "minimum spec", wherein I am aiming to try for games and demos written in m.grl to hopefully run at 30fps
<mark_weaver>and I've found that I need to reboot to fix this problem, which I guess was introduced in linux-libre-4.3
<aeva>interesting!
<mark_weaver>or possibly 4.2, I'm not sure
<aeva>I bet that is related
<mark_weaver>yeah
<mark_weaver>if we determine that new kernels are causing these problems, I will roll back our linux-libre to the latest supported release that doesn't have the problem.
<aeva>+1
<karhunguixi>for what it's worth, i haven't had any problems playing videos
<aeva>I haven't tried video playback yet
<mark_weaver>I'll try rolling my machine back to 4.1.x, which is the newest branch that's still supported upstream.
<mark_weaver>(and that doesn't show the video problem on the X60)
<aeva>hm, so different kernel, but another friend reported that she experiences the same regression on her x200 running trisquel - 3.13.0-74-generic #118+7.0trisquel2
<civodul>lfam: what's the status of the 17-patch Python series you posted recently?
<civodul>well, Monday 4th
<mark_weaver>aeva: bah, that's discouraging :-(
<civodul>mark_weaver, bavier: re Boost, i noticed that the whole branch is built now, so i wonder if we shouldn't simply merge it and leave MIPS investigation for later; thoughts?
<mark_weaver>civodul: okay
<bavier>civodul: sounds okay to me
<mark_weaver>aeva: well, if we can find an old supported kernel branch that doesn't have the problem, I'll add it to guix
<lfam>civodul: The CalDAV / CardDAV thing? There are a couple of minor issues I was hoping would clear up soon. I'll check on them now
<aeva>I'm starting to worry that this isn't a regression so much as it was never really tested well to begin with
<mark_weaver>aeva: I ran gnome-shell on my X200 for a long time with Debian and never saw the problem.
<mark_weaver>and celestia also.
<aeva>I'm wondering if it is specific to render textures now
<aeva>since gnome3 and the light demo both make use of that
<aeva>so if that is the case, then the particle demo would be able to run indefinitely without problem
<mark_weaver>I guess I was probably running linux-3.2 at that time
<mark_weaver>anyway, I have to go afk.
<aeva>alrighty
<lfam>Did anyone have any more ideas about the issue with python-2 libraries that aren't auto-translated by (package-with-python2)? http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22013
<civodul>bavier: do you want to do it, or should it do it?
<civodul>lfam: yes, the python/caldav things; i was just wondering if they were stuck waiting for review
<lfam>I was wondering about the python-2 issue in general, but I don't see it as blocking the *dav stuff. I was actually waiting for the pypi-uri ".zip" fix to go in. I just used applied it to the relevant patch.
<bavier>civodul: my repository is tied up with a build right now, so you can do it, if that's fine with you
<civodul>ok!
<bavier>well, I could learn git too, I guess :/
<rekado>the guix website looks a little funny with the two bars above the menu
<rekado>is the note about GuixSD being beta software really necessary when visiting the home page?
<rekado>couldn't it be an inline note on the download page instead?
<civodul>bavier, mark_weaver: pushed!
<civodul>bavier: i noticed there's a 'coroutine2' component depending on 'context', so i added --without-coroutine2 on MIPS, just in case
<bavier>civodul: I see, that might be the thing
<civodul>rekado: initially, when Felipe was designing the fancy web site, people were concerned that this could be taken as a serious project, hence the blue bar :-)
<civodul>mark_weaver: i'm considering merging master into core-updates and building it all; thoughts?
<rekado>oh, this is pretty: http://www.freeasinfreedom.be/
<bavier>I was just reading semver.org, is that roughly what we're following in guix?
<civodul>i think so, roughly
<civodul>rekado: indeed
<rekado>"Please consider donating for the holidays!" <--- spring festival begins on the 8th of February.
<rekado>are there any other big holidays soon after that? Or should we drop the "for the holidays"?
<davexunit>drop it
<bavier>it might be time to drop it
<rekado>well, easter is in March or May...
<civodul>rekado: we should check the list of holidays worldwide before dropping it
<civodul>we never know
<civodul>which reminds me, we still don't have access to the CiviCRM thing that would allow us to know the balance :-/
<civodul>OK, holidays are over
<civodul>rekado: i'm fine with putting the "this is beta" warning on the download page
<civodul>would you like to submit a patch?
<civodul>(that's what you get for making proposals ;-))
<karhunguixi>So, how has the donation fest been so far?
<civodul>i'm waiting for the exact figure, but i haven't received any donation notification over the last few days
<Gamayun>ACTION just donated the other day
<civodul>cool, thanks Gamayun :-)
<civodul>i hope to post an update soon
<civodul>and maybe put the current status on the web site
<Gamayun>Now I expect the number of guix packages to overtake debian in the next year :P
<Gamayun>jk
<civodul>:-)
<karhunguixi>Good. Hopefully there's enough to update hydra.
<civodul>yeah
<civodul>soon at 3000 packages: https://www.gnu.org/software/guix/packages/
<karhunguixi>Are you surprised one way or the other, or has it been around what you expected?
<civodul>honestly, i didn't really know what to expect
<civodul>covering the machine's expense (say 4000-5000) seemed doable
<rekado>civodul: I can prepare a patch. Maybe tonight, maybe later (building cross-compiler again).
<civodul>but i had no real experience
<civodul>rekado: ok!
<civodul>sorry to trick you into another batch of rebuilds...
<rekado>if only the SVN checkout didn't take so very, very long...
<bavier>civodul: I think turning coroutine2 off for mips should be enough. The 'boostdep' tool lists only those two as users of the context lib
<bavier>and `bootstrap --without-libraries=context` doesn't propagate dependencies, so manually disabling dependents is the only way it seems
<civodul>bavier: ok, thanks for checking
<lfam>Trying to build something, I get "Unable to initialize GTK+, is DISPLAY set properly?"
<lfam>I'm not sure why it's trying to initialize GTK+ with a real display while building. Any thoughts?
<civodul>to run tests?
<civodul>sneek: later tell davexunit i'm sure you'll like this one: https://github.com/lukasmartinelli/hadolint :-)
<sneek>Will do.
<lfam>I guess it must be doing that. It's definitely still in the build phase but I suppose the build system could lack the separation between the phases
<mark_weaver>civodul: sure, merging master into core-updates and building sounds good
<civodul>mark_weaver: ok, thanks
<civodul>i just noticed you fixed the Perl CVE, cool
<davexunit>hehehe something funny just happened to me on HN
<sneek>Welcome back davexunit, you have 1 message.
<sneek>davexunit, civodul says: i'm sure you'll like this one: https://github.com/lukasmartinelli/hadolint :-)
<davexunit> https://news.ycombinator.com/item?id=10890547
<davexunit>the user "omni" and I both independently posted the *exact same* URL to demonstrate why we think Chef is over-engineered
<davexunit>civodul: I got a kick out of that
<davexunit>DSLs are out of control
<davexunit>I'm currently arguing with Ansible users about how terrible YAML is
<davexunit>getting responses like "I don't want a full programming language" and "that would be dangerous"
<davexunit>full thread https://news.ycombinator.com/item?id=10887464
<davexunit>good times
<davexunit>having something like this for Guix would be cool: http://prakhar.me/docker-curriculum/
<civodul>seems you're having fun on HN :-)
<civodul>docker-curriculum is behind CloudFar
<civodul>+e
<karhunguixi>ach, all these captchas :(
<civodul>yeah
<karhunguixi>which are hosted by google, which must be granted access (i use RequestPolicy)
<civodul>bah, so much hostility towards privacy-conscious users
<karhunguixi>They say there's a lot of bad behaviour coming from Tor exit node IPs, and these IPs get a high threat score
<NiAsterisk>i wish I could make the non-exit tor relays i run exit nodes..
<karhunguixi>What would the benefit of this be?
<NiAsterisk>none, just a change of service and more fun with people trying to get inside or complaining possibly.
<karhunguixi>heh ;)
<NiAsterisk>in general all serve the same network, so it's just a perspective.
<lfam>The build chroot is not supposed to have a working X environment, correct?
<rekado>lfam: not unless you add it.
<lfam>Any examples of how to add it?
<rekado>lfam: take a look at gtksourceview.
<lfam>Okay, thanks
<paron_remote>francis7: ah yeah
<paron_remote>I saw your submission
<paron_remote>whoo
<paron_remote>thx