***jonsger1 is now known as jonsger
<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 <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 <lfam>Except for read-only filesystems <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. <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>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 <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 <lfam>Interesting how Git formatted the patch <lfam>There is plenty of non-binary data in the new patch file <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 <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>"guix pull" is currently using the newer one, so things should be okay :) <lfam>It's always "safe" to kill the daemon. The worst that could happen is you have to restart some builds <lfam>Yes, if that's how you started it <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. <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 <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 <lfam>GuixSD is documented specifically in section 7 GNU Distribution <lfam>The rest of the manual is useful on GuixSD but it's not specific to GuixSD <lfam>About how to restart the guix-daemon with changed arguments on GuixSD/ <lfam>You could try `herd disable guix-daemon && herd stop guix-daemon && guix-daemon --substitute-urls=$URLS` <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>It would feel cleaner to modify the default guix-daemon in place without tampering with the config <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 <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>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 <rekado_>I’ll cherry-pick it, change guix-devel to point at that commit, then build the mips and armhf tarballs. <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 <rekado_>pushed as 7aa8785c4153a87e2e5d0697ad349ebc8e3b8500 <civodul>rekado_: i've started the two builds! <rekado_>(I already prepared the announcement text) <civodul>rekado_: if you have the news entry for gnu.org/s/guix/news as well? <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>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_>the version number 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. <civodul>i think it's meant to refer to the latest version no? <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 <ng0>Hi, new curl was released, I'm now preparing the gnurl release. I thought it would be tomorrow. <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? <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>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? <rekado_>renick: see ftp://alpha.gnu.org/gnu/guix/ <civodul>rekado_: the substitute ins't ready yet <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> (destination (make-socket-address AF_INET INADDR_ANY 0))) <civodul> (delete-network-route sock destination)) <civodul> (memv (system-error-errno args) (list EPERM EACCES))))) <renick>civodul: I just need it in Virtualbox guest OS , so only i686 architecture is okay. <rekado_>civodul: I see two images on this page. <civodul>right, but these are the old ones :-) <ng0>how do I make alsa-plugins:pulseaudio available in config.scm? or anything other than :out ? <ng0>with ,(alsa-plugins:pulseaudio) ? <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 <ng0>your problem read like you are just about to install the SD <renick>ng0: Sorry, i havn't finished to install GuixSD, I begin to download version 0.12.0 of GuixSD image already. <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>oh... I had to downgrade nss-certs in my profile. <ng0>I don't know why I installed it twice, globally and locally <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
<civodul>rekado_: there was commit aaee461b9d5fb85fc1a548877dc7eea3dd4fbf50 <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 <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 <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 <rekado_>civodul: turn off this single test or all of them? <civodul>next time we'll do better, but for today, that sounds more reasonable <joshuagl>hello guix! the 0.12.0 x86_64 download link doesn't work: ftp://alpha.gnu.org/gnu/guix/guixsd-usb-install-0.12.0.x86_64-linux.xz <civodul>if mark_weaver were around we could turn off user ns explicitly <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? <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 <ng0>where does "ps2pdf" come from? ***jz is now known as Guest60360
<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 <rekado_>yes, I switched to just hydra today to get the new substitutes quicker <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 <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>rekado_: do you have this set in your guix system config? <paroneayea> (kernel-arguments '("modprobe.blacklist=kvm_intel")) ; also ",kvm"? <ng0>oh. there's maketgz. well then <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: guix-binary-0.12.0.mips64el-linux.tar.xz was built successfully! <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! <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 :/ <rekado_>civodul: the last tarball has been uploaded! <lfam>nliadm: Is it a compilation flag? <lfam>nliadm: Okay, how do you know there's a flag for it? :) <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: Can you try the first one, "/set weechat.network.gnutls_ca_file [...]" <nliadm>yeah, that's what I did, and now things work <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>" 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. " <ng0>but I already have gnurl released so I send the update to guix <lfam>ng0: Source of that quote? <civodul>rekado_: i'd say do it now; supposedly it's the right time for people in the Americas <lfam>ng0: Only hard to miss if you are downloading the tarball :) I just read the changelog after seeing our package update. <lfam>The other two bugs appear to be limited to Windows CE <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>well gnurl release is already out there, I just checked the download page about curl after I released it <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>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. <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 <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!”…? <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>it's a very home-for-the-holidays question :) <davexunit>a not-so-convenient way would be to change timezone in your config.scm and reconfigure <lfam>76 contributors to 0.12.0! <rekado>wingo: looks like my nick is not in the ops list. <davexunit>oh darn I just realized I never pushed my mesa patch <rekado>let’s make the next release sooner <davexunit>I couldn't figure out what was up with the staging branch <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
<lfam>You can try the merge if you want, but I mostly don't want your patch to be forgotten :) <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>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
<civodul>buenouanq: no need to reinstall, 'guix pull' will do <buenouanq>and thank you all for all the wonderful things you do ***jz is now known as Guest57748
***jz is now known as Guest12199
<buenouanq>all we need now to top it all off is gnunet@0.10.2