# IRC channel logs

## 2016-12-21.log

back to list of logs

***jonsger1 is now known as jonsger
<lfam>Gah, this bug report is 6 years old: https://bugzilla.mozilla.org/show_bug.cgi?id=609734
<lfam>This breaks the test suite over and over again!
<lfam>And it also means we can't build NSS at all with older revisions of Guix
<lfam>Or, from older revisions of Guix
<bavier2>would disabling the test make sense?
<lfam>I suspect it means we can't build NSS even with the current revision
<bavier2>our does it test security critical code that's not tested elsewhere
<lfam>That or cherry-picking the upstream fix
<lfam>The "fix" which is just updating the cert
<lfam>GnuTLS takes care to avoid this problem in their test suite
<lfam>I think it's a real problem that old NSS certificate sets can't be replicated without fiddling with the test suite
<bavier2>a test timebomb
<lfam>We only noticed it when GnuTLS forgot to apply their time-fudger to a new test
<lfam>But with NSS, I guess we have to deal with it on a regular basis
<lfam>I wonder what the other distros do.
<lfam>There are other problems in the armhf build, however.
<lfam>[ FAILED ] DamageYDatagram/TlsDamageDHYTest.DamageClientY/13, where GetParam() = ("DTLS", 771, 0, false)
<lfam>[ FAILED ] LimitCBC12/TlsCipherLimitTest.WriteLimit/2, where GetParam() = ("TLS", 771, 49187)
<lfam>This test suite takes ~11 hours on our hardware
<lfam>I wonder if I can rent some 32-bit ARM cloud computing hardware
<lfam>Something much faster than our Novenas and Wandboards
<buenouanq>lfam: hold out till may and buy a bunch of those libre tea things
<lfam>buenouanq: EOMA68? That project is awesome but it won't be faster than the machines in our build farm. I'm interested in some server hardware
<lfam>And it won't help me tonight :)
<buenouanq>yeah, but if you had \\it{a bunch} of them...
<lfam>It could work if the NSS test suite can be parallelized effectively
<lfam>I actually have a machine using the same hardware as the EOMA68, but it's offline for now
<lfam>I decided I don't want to run any machines on SD cards anymore. It's too unreliable
<buenouanq>I'm really so excited for those. I sure hope they get the RYF cert.
<buenouanq>and I'll want to put GuixSD on them of course, so hopefully we'll have the needed ARM support by then
<lfam>buenouanq: I think that booting GuixSD on those machines will be pretty similar to the Cubieboard 2, the Olimex A20 boards, and lots of the other Allwinner A20 boards, which are really common.
<lfam>Feel free to jump in :)
<efraim>Scaleway has arm servers but they dont have neon support iirc so we dont support them
<lfam>efraim: Do you know machine they are using?
<lfam>It seems it would have to be a slow machine for 3 euro per month on bare metal
<lfam>BTW, how is the aarch64 port coming along?
<efraim>I wish I could remember which one it is
<efraim>I've come across some bug that causes phase 2 of gcc-final to fail that I'm debugging now
<efraim>Hopefully after that it should be very quick, I've been keeping my patches clean and rebased on core-updates
<efraim>The same bug has been plaguing me for 4.9.4, 5.4.0 and I tried it with 6.2.0 and the same
<lfam>Discussion on hacker news says the scaleway servers are the marvell MV78460
<lfam>Indeed, we can't build the current version of NSS either
<lfam>I'll look into cherry-picking the upstream patch
<efraim>would it be easier to set the time to the release-date's time?
<lfam>efraim: What do you mean?
<efraim>assumably the certificates weren't expired when they made the tarball, so lets set the date during the testing phase to be the release date
<lfam>Can we do that?
<efraim>maybe
<lfam>Gah, the NSS mercurial repo has a different layout than the tarball, so the patch doesn't apply
<efraim>I see DATE=$(date -u '+%Y%m%d%H%M%SZ' in nss/tests/chains.sh, nss/cert/cert.sh and something similar in tests/qa_stage <efraim>and tests/run_niscc.sh <lfam>Does it use that DATE to judge if the test certs are expired? <lfam>I wonder how it uses it in 'nss/cert/cert.sh'. That doesn't sound like test-only code <efraim>sorry, nss/tests/cert/cert.sh <efraim>i only grepped in tests <lfam>I'm testing a build on x86_64 with the upstream fix, based on these patches: http://paste.lisp.org/+764E <lfam>Interesting how Git formatted the patch <lfam>There is plenty of non-binary data in the new patch file <baconicsynergy>bavier: guix pull doesn't have a --fallback option :o <lfam>baconicsynergy: Try restarting the guix-daemon with --substitute-urls=httsp://hydra.gnu.org <lfam>Be sure to undo it afterwards. We need users to prefer using the mirror by defaults because hydra.gnu.org can't handle the load <lfam>Of course 'httsp' is a typo <baconicsynergy>thanks! i'll report back in a sec <baconicsynergy>um, which is the default mirror again? <baconicsynergy>study study study <baconicsynergy>i got dis <baconicsynergy>How can I check the currently used substitute urls? <lfam>baconicsynergy: The default is https://mirror.hydra.gnu.org (set in nix/config.h). If you change it, you can see it in on the command line with ps aux or a similar tool <baconicsynergy>oh dear. it seems i have multiple guix-daemon instances with different arguments ._. <lfam>Are you sure they aren't children of the main process? <baconicsynergy>there is one child process of the one i created, but I guess I forgot to kill the old default guix-daemon that was running prior <baconicsynergy>I assumed invoking it would kill the old one... hmmm <baconicsynergy>"guix pull" is currently using the newer one, so things should be okay :) <baconicsynergy>i shoudl be able to safely kill the old one <lfam>It's always "safe" to kill the daemon. The worst that could happen is you have to restart some builds <baconicsynergy>It respawned...... <baconicsynergy>should i kill it via herd? <lfam>Yes, if that's how you started it <baconicsynergy>It started automatically <lfam>Are you stopping and starting it in order to change the substitute-urls argument? <lfam>Hm, I'd instead modify my OS configuration and reconfigure. <lfam>For example http://paste.lisp.org/+764U <baconicsynergy>this is just for the live media :0 <baconicsynergy>I guess the right question for me to ask is, what's the proper way to restart the guix-daemon? <baconicsynergy>The manual just states to run it as root, but it makes more sense to me to control it via herd <baconicsynergy>since the default one is controlled via herd <baconicsynergy>Sorry if I'm not making any sense :p <lfam>It runs as root when started by herd <lfam>Where in the manual does it say to run it as root? <lfam>That documents how to use Guix on a foreign distro. It doesn't apply directly to GuixSD <baconicsynergy>ooooooh <lfam>GuixSD is documented specifically in section 7 GNU Distribution <baconicsynergy>oh dear <lfam>The rest of the manual is useful on GuixSD but it's not specific to GuixSD <baconicsynergy>I'm still pretty confused :? <lfam>About how to restart the guix-daemon with changed arguments on GuixSD/ <baconicsynergy>yes :) <baconicsynergy>just on the live media <lfam>You could try herd disable guix-daemon && herd stop guix-daemon && guix-daemon --substitute-urls=$URLS
<baconicsynergy>That's what I did! cool
<baconicsynergy>Wouldn't guix-daemon not be controlled by herd, then?
<baconicsynergy>guix-daemon is running, but herd status doesn't list it
<baconicsynergy>it just says the default guix-daemon that was running before is currently "stopped"
<lfam>Yeah, in this case you're controlling it on the console
<baconicsynergy>That's no problem at all, as long as it'll work :)
<baconicsynergy>It would feel cleaner to modify the default guix-daemon in place without tampering with the config
<baconicsynergy>trying to start guix-daemon with additional arguments fails
<lfam>I wouldn't do this once you've installed GuixSD. Then, you should edit the OS configuration and reconfigure. But that sounds annoying on the live media
<baconicsynergy>via herd
<baconicsynergy>For sure, thanks for the word of advice and for all the help!
<lfam>It works for me, I'm not sure why it's failing for you
<baconicsynergy>I tried running "herd start guix-daemon *arguments*" but it spit out a warning
<lfam>It's just guix-daemon --substitute-urls=URLS
<lfam>No herd start
<baconicsynergy>gotcha
<baconicsynergy>i think i understand now
<lfam>You're not using herd for this. You're just running the daemon directly, like any other command-line program
<lfam>It will block on the console; you should be able to use another TTY to keep using the computer
<baconicsynergy>I just ran it as a background process
<baconicsynergy>This is fun :)
<lfam>:)
<baconicsynergy>Time to make some coffee and stretch while this is running
<jmd>Morning civodul
<civodul>'lo Guix!
<rekado_>I’ll cherry-pick it, change guix-devel to point at that commit, then build the mips and armhf tarballs.
<civodul>yay!
<civodul>rekado_: i can spawn the mips & arm builds on hydra once you've cherry-picked the thing, if you want
<rekado_>civodul: thank you. I just pushed the cherry-picked commit to version-0.12.0; commit is b291b3271a025dfe41e1a7fdfadd393373b0128d.
<rekado_>should I wait with pushing the guix-devel update?
<civodul>rekado_: you can update guix-devel to refer to the current tip of version-0.12.0 now
<civodul>rekado_: i've started the two builds!
<civodul>yw!
<civodul>in the meantime you can update https://www.gnu.org/software/guix/manual/ with gendocs.sh, if you have time for that
<civodul>:-)
<civodul>rekado_: if you have the news entry for gnu.org/s/guix/news as well?
<civodul>with ~5 highlights
<rekado_>is cvs update really supposed to take *that* long?
<rekado_>it’s stuck at cvs update: Updating static/base/img
<civodul>sometimes you have to C-c it and re-run it :-)
<civodul>damn it
<civodul>hmm, dunno
<civodul>sometimes it's just as fast to do a checkout ;-)
<civodul>but maybe there's nothing to update anyway
<rekado_>there seems to be a mistake in the website code
<rekado_>it says “As of version 0.12.0, the Guix System Distribution <a href="/software/guix/manual/html_node/System-Installation.html">can be installed</a> on an i686 or x86_64 machine…”
<rekado_>I’ll take a look at this.
<civodul>shouldn't increase?
<civodul>the version number is specified in (www shared) IIRC
<rekado_>I would expect the sentence to refer to the first version that could be installed on the specified architectures.
<rekado_>“As of version 0.12.0 …” sounds like previous versions didn’t support installation on these architectures.
<civodul>build succeeded on arm, but failed on mips (tests/syscalls.scm)
<civodul>i'm rebuilding with -K, we'll see if it's deterministic or not
<civodul>grr
<ng0>Hi, new curl was released, I'm now preparing the gnurl release. I thought it would be tomorrow.
<civodul>this Dec. 3rd build already had the test failure so i suspect we're screwed: https://hydra.gnu.org/build/1660977
<ng0>bugfix and cve release, too
<renick>I can't finish installation with download speed of 8kB when perform the sentence "guix system init /mnt/etc/config.scm /mnt".
<civodul>renick: are you installing from 0.11.0?
<renick>civodul: Yes
<civodul>my advice would be to use the 0.12.0 image from alpha.gnu.org, which is about to be announced
<civodul>that one has "substitutes" (binaries) available
<civodul>things should work better, overall
<civodul>the mips issue must have been introduced by 67e5f3b71d87d0a0e444df2e039c458629708cd4
<ng0>I mean I will work on it once I have resolved the ssl problem here -.-
<ng0>I removed all envrionment variables and only use what's in my profile (sourced), but it's back
<ng0>so maybe I should work in an ad-hoc environment today
<ng0>ah, $HOME/.guix-profile/etc/profile doesn't include the SSL_ ones <rekado_>civodul: I cannot build /gnu/store/r2gjvbidq8w4fiiijmb86w7y4qzcrr52-module-import for armhf; should there be a substitute on hydra? <ng0>there's only export GIT_SSL_CAINFO="${GUIX_PROFILE:-/gnu/store/v2y8538qx8nccfvaxl1p489ma8y0z785-profile}/etc/ssl/certs/ca-certificates.crt${GIT_SSL_CAINFO:+:}$GIT_SSL_CAINFO"
<ng0>shouldn't .guix-profile/etc/profile include the other SSL variables aswell?
<renick>civodul: how long shall I wait for 0.12.0?
<civodul>rekado_: i think you forgot to commit the images under manual/html_node/images
<civodul>like (let ((sock (socket AF_INET SOCK_STREAM 0))
<civodul> (catch 'system-error
<civodul> (lambda ()
<civodul> (delete-network-route sock destination))
<civodul> (lambda args
<civodul> (close-port sock)
<civodul> (memv (system-error-errno args) (list EPERM EACCES)))))
<civodul>err
<civodul>sorry
<renick>civodul: I just need it in Virtualbox guest OS , so only i686 architecture is okay.
<civodul>cool
<civodul>right, but these are the old ones :-)
<civodul>i updated the dot files recently
<ng0>how do I make alsa-plugins:pulseaudio available in config.scm? or anything other than :out ?
<ng0>with ,(alsa-plugins:pulseaudio) ?
<ng0>nope. hm
<civodul>ACTION goes for lunch
<renick>rekado: Can I directly install guix binary into VirtualBox ?
<ng0>are you trying to install guix or GuixSD?
<renick>ng0: I already installed GuixSD, I also wanna try install guix.
<ng0>if you installed GuixSD, you have guix
<renick>ng0: Sorry, i havn't finished to install GuixSD, I begin to download version 0.12.0 of GuixSD image already.
<renick>ng0: right.
<ng0>for virtualbox it's a bit different than just qemu but should be that hard to adjust according to your needs, but we can't provide help for virtualbox.
<ng0>I don't know why I installed it twice, globally and locally
<renick>ng0: Good luck!
<ng0>s/should be that/shouldn't be that/
<rekado_>civodul: I can see no difference between the images on the online manual and the image files generated today on my laptop using gendocs.
<ng0>ACTION wonders wether they are creating the longest thread of this year with the pagure dependencies
<ng0>91 messages including the bug which counts into my message view on it
<ng0>anyone doing the curl update? otherwise I can do curl after I'm finished with gnurl
***Piece_Maker is now known as Acou_Bass
<ng0>hm... grey area license question: I add a guix.scm to gnurl, as far as I understand it I must give it the same license as curl/gnurl and call it an "appendum to gnurl", right? I'm asking here as I guess more people with knowledge in licenses are around than in #gnunet :)
<civodul>davexunit, mark_weaver: is there a way we can forcefully disable user name spaces?
<ng0>anyway, I add an disclaimer that I'm not a fountain of wisdom when it comes to licenses and people shall contact me if it's wrong, i think i'm all good with that
<civodul>davexunit, mark_weaver: hydra-slave0 has /proc/self/ns/user but (clone (logior CLONE_NEWUSER CLONE_NEWNS SIGCHLD)) fails with EPERM, which was not the case before i think
<civodul>so the 'pivot-root' test fails
<rekado_>civodul: yes, I’ve seen the commit and the image files were in fact updated (timestamps show they were generated today).
<rekado_>is there anything else I need to do to ensure they are generated?
<rekado_>the images I see in the online manual are the pretty ones with more colours.
<civodul>rekado_: oh right, everything's ok, probably just a caching issue in my browser
<ng0>when I do ./buildconf the shebangs are not altered or adjusted to what's locally, it's just a thing of the build environment of guix, right? this is the first release I do only on GuixSD
<civodul>oh, IceCat has this "reader view" feature when viewing the manual
<civodul>looks interesting
<civodul>small book icon in the URL bar
<rekado_>I still cannot build the armhf binary tarball.
<rekado_>building path(s) /gnu/store/r2gjvbidq8w4fiiijmb86w7y4qzcrr52-module-import'
<rekado_>a armhf-linux' is required to build /gnu/store/15lg8nqcy3m1bapsgll2ndxfjfnav1wd-module-import.drv', but I am a x86_64-linux'
<rekado_>do I just need to wait for a substitute to become available?
<ng0>I get some /gnu/store paths in autom4te.cache folder, and ltmain.sh is also with a /gnu/store shebang to /bin/sh :/
<ng0>so I guess I'll release without the configure stuff
<rekado_>ng0: aren’t you using “make dist” to create tarballs?
<ng0>it was pretty manual so far
<rekado_>if you’re using autoconf and automake you can create pretty tarballs with just “make dist”.
<rekado_>don’t know why there would be a /gnu/store shebang.
<ng0>with ./buildconf which is like ./bootstrap, configure etc get generated
<ng0>which was part of the steps I haven't automated
<civodul>rekado_: for arm that's because the tarball i showed is the one without grafts; the grafted one is coming
<civodul>rekado_: for mips, i think i'll just turn off tests since 'pivot-root' is the only test failure, and it's harmless, kernel-dependent, and just annoying at this point
<civodul>thoughts?
<rekado_>civodul: turn off this single test or all of them?
<civodul>all
<civodul>it's the only one that fails
<civodul>next time we'll do better, but for today, that sounds more reasonable
<civodul>ACTION thinks some more
<civodul>if mark_weaver were around we could turn off user ns explicitly
<rekado_>joshuagl: it does work for me
<joshuagl>huh. I see the i686 file in the directory listing, but no 0.12 x86_64 file
<joshuagl>maybe my local mirror isn't updated yet?
<civodul>i think it just appeared :-)
<joshuagl>oh hey look, there it is!
<ng0>ah, I did not use make dist so far because there's no roffit in guix which would be needed by make distcheck
<ng0>is there a replacement? otherwise I'll just package it
<civodul>rekado_: does "make guix-tarball.armhf-linux.tar.xz" work now? if it doesn't maybe you'll need "sudo rm -rf /var/guix/substitute/cache"
<civodul>the result should be /gnu/store/g10vmbxg50kbcj9h88mjjc81gq59is03-guix-0.12.0-2.b291
<rekado_>civodul: I got /gnu/store/g10vmbxg50kbcj9h88mjjc81gq59is03-guix-0.12.0-2.b291, but it then tries to build /gnu/store/wig3v1xi2qsf47qjqvhlbri78fgv9x4x-ca-certificate-bundle
<civodul>bah
<djLeGit>hello guix
<ng0>where does "ps2pdf" come from?
<ng0>ghostscript?
<ng0>yes
***jz is now known as Guest60360
<efraim>qemu 2.8.0 is finally released
<efraim>time to spend the time compiling trying to figure out all the CVEs it covers :/
<rekado_>I’m running the daemon with hydra as the only substitute url
<civodul>not the mirror?
<rekado_>yes, I switched to just hydra today to get the new substitutes quicker
<civodul>lemme see
<civodul>rekado_: from the tip of version-0.12.0, "make guix-binary.mips64el-linux.tar.xz" gives you /gnu/store/vidn1mrrfvijbjdshg4k3wa8wg5ln01h-guix-tarball.tar.xz
<civodul>i swear!
<civodul>:-)
<ng0>rekado_: I'm almost at the point where make dist works. I just need to figure out one problem which is the resulting name
<ng0>it helps a bit, but artifacts of one shebang remains, but that's for packagers to fix or complain about
<ng0>I'm pretty sure I could just replace that /gnu/store/.../bin/sh with just /bin/sh again
<ng0>I think upstream curl no longer uses make dist. the file which gets in the version has curl 7.12.something in it
<jmd>ACTION Finally managed to build a disk-image with the installer included!
<paroneayea> (kernel-arguments '("modprobe.blacklist=kvm_intel")) ; also ",kvm"?
<paroneayea>nm the also ",kvm" comment :)
<paroneayea>it'll make vm things not crash your computer :)
<paroneayea>but go very slowly :)
<ng0>oh. there's maketgz. well then
<paroneayea>since it'll do it in software
<paroneayea>but hey, it won't try the buggy microcode stuff :)
<efraim>it turns out s390x uses HOST_CC and not CC, back to the start of compiling
<ng0>yeah I have to come up with some guix-and-others maketgz changes. I'll stick to half-manual release now
<rekado_>civodul: now I’m only waiting for substitutes for armhf
<civodul>rekado_: from version-0.12.0^, "make guix-binary.armhf-linux.tar.xz" gives you /gnu/store/v5qknxb1g3gdl2hjkvqn864z6f0iiv5c-guix-tarball.tar.xz
<civodul>upload these two things and you're done!
<civodul>:-)
<ng0>should I add the CVEs this time to the commit of gnurl update in guix?
<ng0>I think I need 20 more minutes and I can send the patches
<lfam>ng0: If gnurl is also vulnerable, then yes
<nliadm>I think I found the issue I was having with weechat
<nliadm>there's a flag in weechat to set where the ca-file is
<nliadm>I think it's set where the bundle will be on a guix-sd system
<nliadm>which means if you're using guix's weechat hosted on another distro, you just have to know to set it :/
<lfam>nliadm: Is it a compilation flag?
<lfam>nliadm: Okay, how do you know there's a flag for it? :)
<rekado_>civodul: Should I send the announcement and add the news item to https://www.gnu.org/software/guix/news/ tomorrow morning?
<nliadm>I installed my distro's wecchat, configured it, then uninstalled and installed guix's and everything works now. The setting is mentioned in the weechat troubleshooting for gnutls
<lfam>nliadm: I see some things here: https://weechat.org/files/doc/weechat_faq.en.html#irc_ssl_connection
<lfam>nliadm: Can you try the first one, "/set weechat.network.gnutls_ca_file [...]"
<nliadm>yeah, that's what I did, and now things work
<lfam>Okay, that's great :)
<nliadm>I don't know what it was set to fresh out of the box, but it wasn't right for a hosted guix
<nliadm>I don't know how to tell the user they may have to mess with that
<lfam>They may just have to read the weechat manual themselves ;)
<ng0>lfam: also
<ng0>" Attention! We will release a patch update within a few days to fix a serious security problem found in curl 7.52.0. You may consider holding off until then. "
<lfam>ng0: Hm, interesting!
<ng0>but I already have gnurl released so I send the update to guix
<lfam>ng0: Source of that quote?
<ng0>difficult to miss
<civodul>rekado_: i'd say do it now; supposedly it's the right time for people in the Americas
<civodul>and prolly you want to be done ;-)
<civodul>but as you prefer!
<ng0>ah
<lfam>Well... if the curl project recommends we don't update, I guess the new vulnerability must be worse than the fixed vulnerability, this one: https://curl.haxx.se/docs/adv_20161221A.html
<lfam>The other two bugs appear to be limited to Windows CE
<lfam>I'll revert
<civodul>we can/should do a 'staging' branch during the coming weeks
<ng0>I.. I don#t know. I copy the quote for gnunet.org, but as you are not supposed to use gnurl on its own, I *think* it's safe to version bump, I do some more changes in the package definition for guix
<jmd>civodul: There is already a staging branch.
<lfam>ng0: It's up to you. Without any information about this new bug, it's hard to know the best course of action
<ng0>also yes, unknown bugs...
<civodul>jmd: right! well "we" should make sure it's frozen in a week and merged in two weeks
<jmd>civodul: Sounds like a plan.
<civodul>i say "we" because i won't be here to take care of that :-)
<lfam>So, we freeze it on December 28?
<civodul>something like that
<lfam>Okey-dokey
<civodul>or even earlier, since it's already been around for some time
<lfam>Alright, I'll check how much time has elapsed since the previous merge and take the holidays into account
<jmd>I suggest that both "staging" and "core-update" have different names.
<civodul>naming is important
<civodul>ttyl!
<jmd>... so important that he dissapears!
<lfam>jmd: Perhaps not that urgent :)
<ng0>lfam: I've sent the patch to include gnurl update, it's up to guix wether this version should be included or left out. I think security bugs are always present, and their fix comes in a few days, so with not much information at hand I don't think it'll be high risk
<lfam>It's true, there are always more bugs to find. It's unusual for the curl maintainers to ask people to not update, however. I think the new bug must be very severe
<ng0>additionally I update the package definition, maybe it applies without the update
<ng0>*upodated
<lfam>I wonder if anyone else tried updating QEMU to 2.8.0? It fails to build for me :/
<lfam>Somewhere, make tries to invoke cc instead of gcc, but I can't figure out where it's doing this!
<lfam>Ah, scrolling up farther, it also fails to find flex and bison
<ng0>anyway I'm done for today and I hope they won't do the security release on the weekend.
<rekado_>so… how do we change the topic here in IRC from “0.12.0 is in the works!” to “Guix 0.12.0 has been released!”…?
<davexunit>with the /topic command
<davexunit>you need to be an op
<wingo>/msg ChanServ op #guix
<davexunit>yeah that!
<wingo>^ command to op yourself if you're in the ops list, iirc
<wingo>how do yall change your time zone? i used to use gnome's chooser thing but i think that doesn't work
<wingo>for when you travel
<wingo>it's a very home-for-the-holidays question :)
<davexunit>hmm, haven't tried doing that.
<davexunit>a not-so-convenient way would be to change timezone in your config.scm and reconfigure
<lfam>76 contributors to 0.12.0!
<davexunit>nice!
<kyamashita>Wow!
<rekado>wingo: looks like my nick is not in the ops list.
<davexunit>oh darn I just realized I never pushed my mesa patch
<davexunit>next release I guess!
<rekado>let’s make the next release sooner
<davexunit>I couldn't figure out what was up with the staging branch
<davexunit>and then forgot about the patch...
<wingo>ACTION neither
<lfam>davexunit: Here is the release strategy: http://lists.gnu.org/archive/html/guix-devel/2016-10/msg00933.html
<lfam>Go ahead and push your patch wherever appropriate, before you forget again :)
<lfam>rekado: We could even try for 2.5 months!
<davexunit>lfam: do I just push the patch right to staging?
<davexunit>I can't tell if the branch is in the right state.
<lfam>davexunit: I'd go ahead and push. We can handle merging master into it later
***bhenc_ is now known as bhenc
<davexunit>okay
<lfam>You can try the merge if you want, but I mostly don't want your patch to be forgotten :)
<davexunit>thanks :)
<davexunit>it's a good patch ;)
<davexunit>let's nouveau (and perhaps other) users have OpenGL 3.3+
<lfam>Cool, it should be on master in a couple weeks :)
<davexunit>I'll push real soon, one I confirm that it builds on staging.
<rekado>davexunit: could we also add llvm to the inputs and then build more software renderers?
<davexunit>rekado: is that all that is needed?
<rekado>davexunit: the configure flags also need changing: http://paste.lisp.org/display/334601
<davexunit>lfam, rekado: I pushed the floating point texture patch
<davexunit>while we're rebuilding everything that uses mesa, might as well tackle this, too!
<davexunit>toss that patch on top of what I just pushed to staging and give it a go
<efraim>for the qemu update, how serious are we about naming all the CVEs?
<efraim>did we have any plans to use a/several torrents to make distributing the files less burdensome on alpha.gnu.org?
<rekado>wow, the epiphany dependency graph is huge! I dare you to run “guix graph -b d3js epiphany > graph.html”
<rekado>I think that’s not fair. It includes mesa, xorg-server, webkitgtk…
<efraim>rhythmbox has gnupg and gnupg@2.0 in its graph
***jz is now known as Guest35153
<rekado>hmm, “haunt build” on the website generates URLs without the “/software/guix” prefix.
<efraim>flac is already in `guix size abcde' but isn't in its path, I think I'll add it and add it to the wrap phase
***jonsger1 is now known as jonsger
<jmd>If 0.12.0 has been released, why do we not have a guix-0.12.0 package in gnu/packags/package-management.scm ?
***civodul changes topic to 'GNU Guix | https://gnu.org/s/guix/ | 0.12.0 is out! https://gnu.org/software/guix/news/gnu-guix-and-guixsd-0120-released.html | videos: https://gnu.org/s/guix/help/#talks | bugs: https://debbugs.gnu.org/cgi/pkgreport.cgi?pkg=guix | patches: http://patchwork.sourceware.org/project/guix/list/ | paste: http://paste.lisp.org | log: https://gnunet.org/bot/log/guix'
<civodul>i just wanted to say congrats to rekado! \\o/
<bavier2>thanks rekado for all the release work!
<buenouanq>so now will guix pulling move me up to .12 or must I reinstall GuixSD from scratch?
<nckx>Thanks to everyone who contributed to version 0.12, especially rekado. Seriously.
***jonsger1 is now known as jonsger
<Gamayun>Congratulations! :)
<civodul>e-party time!
<civodul>buenouanq: no need to reinstall, 'guix pull' will do
<buenouanq>awesome
<buenouanq>and thank you all for all the wonderful things you do
<buenouanq>happy solstice everyone!
***jz is now known as Guest57748
<baconicsynergy>hurray for the new guixsd update!
<baconicsynergy>and the hurd too :) it really is christmas
***jz is now known as Guest12199
<buenouanq>all we need now to top it all off is gnunet@0.10.2