<Emas>can some one check the sum of the file git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz , i wanna check to see if the problem i get is because the file is corrupted <mark_weaver>sha256sum master.tar.gz => 4f44450e4348166b0e161094d25144ded86c2651a51ab863e5f0092b9b7a7171 <mark_weaver>NiAsterisk: for setting the keymap on the text consoles, there's 'console-keymap-service' <mark_weaver>it's documented as taking a FILE, but the string you pass it can be any argument that you would pass to 'loadkeys' <NiAsterisk>oh, goood :) so it would be defined in (services) like (console-keymap-service "de") for example? <mark_weaver>yes, assuming that "loadkeys de" does the right thing. <mark_weaver>sha256sum master.tar.gz => 4f44450e4348166b0e161094d25144ded86c2651a51ab863e5f0092b9b7a7171 <Emas>guix pull prints out "unexpected end of file", but that was because the file i download is corrupt <NiAsterisk>mark_weaver: oh. it's there in the manual, i must have read many times over it but never read the part where it says console-keymap-service file ... happens. <lfam>The manual says "see the (guix build-system gnu) module for a complete list" of implicit dependencies pulled in by the gnu-build-system. I'm having trouble finding the list in there. Has it changed? <Jookia>The lack of being able to debug build scripts is something I'm finding a serious problem on. I've been toying with the idea of making one but I'm not sure where to begin <davexunit>Jookia: okay, let's set some things straight here. <davexunit>you cannot possibly have an interactive session in the build container because it's inherently nondeterministic. <davexunit>if something isn't building, you can use 'guix build -K' to keep the failed build directory in $TMPDIR <Jookia>What if I want to inspect a build that didn't fail at a certain point? <Jookia>For development purposes, not building purposes <davexunit>I use 'guix build -S foo' to get source code, and 'guix environment foo' to create the necessary environment for building <Jookia>So I'd have to read the builder scripts for whatever package I'm building to find out the exact arguments and patches? <davexunit>maybe we could write a tool that runs the generated build script <lfam>davexunit: Do you think it's necessary to do `guix environment foo --pure` instead? <lfam>I need to try --container ;) <Jookia>Within NixOS usually you can run an interactive shell and see what the build actually does in its phases- It's messy but it works. With Guix I have no way aside from reading the source to step through a build's phases, and as I'm human I'm sure I'd miss something if I'm debugging a bunch of build failures that take a long time and have pages of flags to add that I'd have to translate from Lisp to command line <davexunit>not all guix build systems have a concept of phases <Jookia>This is true, but there's seemingly imperative Guile builder source code which would be nice to step through <Jookia>Looking the builder for the coreutils source, debugging would require breakpoints which would be tricky on things like loops "(every apply-patch" <davexunit>Jookia: sure, you could use guile's debugger <Jookia>Is there a tutorial for using the debugger with an existing file, setting breakpoints, etc? The manual seems to only use it with the REPL <davexunit>since it's an interactive tool, the REPL is the best place. <davexunit>a hypothetical 'guix debug' command could automatically create the REPL <Jookia>I had to prettify the builder to make it so I could break at a source location easily, maybe it could do that too? <Jookia>it would hypothetically do that too* <davexunit>Jookia: I don't know if this is the right approach <davexunit>I think this would be a good discussion for the mailing list so ludo can weigh in <Jookia>:\\ It's hard since I'm on a low-spec machine doing local builds, should I bring it up in guix-help or devel-guix? <lfam>Yeah, I can imagine debugging a coreutils build failure is pretty painful. It's not amenable to "iterative" debugging if the build process takes a long time. <mog>davexunit, you ready for tomorrow? <mog>days are a mystery to me <davexunit>finishing slides, figuring out demos, and figuring out how to record it. <codemac>Running nixos on a box makes me miss s-expressions :P <Jookia>Can anyone reproduce that 'EDITOR= guix edit coreutils' causes a weird error like +143 ? <iyzsong>Jookia: yes, when EDITOR is "", the command is "+XXX <file>". so we need a fallback editor :) <Jookia>iyzsong: Shouldn't EDITOR= fallback to emacs, like when you `unset EDITOR`? <iyzsong>Jookia: well, EDITOR= guile -c '(when (getenv "EDITOR") (display "!"))' does print '!', so an empty env is not same as an unseted env in Guile. <Jookia>Does it display ! when you run it without EDITOR= but instead unset EDITOR previously? <Jookia>Well, setting EDITOR= breaks guix and it feels like a bug. Maybe the contents of EDITOR should be checked to not be empty <efraim>i went down the rabbit hole of libvpx again <efraim>that's the total of grep define-public -c? <efraim>I always say "about" since we have a couple that are exported and not define-public, and I'm willing to compromise on counting ones that have been broken for a while <efraim>gst-plugins-* saw an update 3 weeks ago, so hopefully with that updated it should build with an updated libvpx <civodul>efraim: that "guix package -A | wc -l" <caolanm>does anyone use libreboot + guix with disk encryption? I had some difficulty yesterday getting an encrypted guix system to boot <caolanm>it installed to the encrypted partitions fine, and I added mapped-devices to my guix system configuration - I also kept an unencrypted /boot to try and make things easier <caolanm>anyway, if anyone has notes on how they set this up I'd appreciate the info <Jookia>caolanm: I'm currently toying with Guix and I plan to get it set up on my T400 with full disk encryption using LUKS with LVM inside. From what I know you'd need to edit the initramfs to init LVM I think? Unsure <caolanm>Jookia: one problem is that guix doesn't currently support LVM <Jookia>caolanm: It doesn't, but I'd guess you could just hardcode in some LVM support and use block devices <caolanm>I imagine just doing an encrypted home partition an unencrypted root would be much easier? <Jookia>caolanm: Not sure- Would you like me to message you if I get a full disk encryption setup on my laptop working with LVM? I'd probably post it to the mailing list. An unencrypted /boot would work fine I guess. <caolanm>Jookia: yes, I'd love to hear about it <caolanm>I'll make sure I'm on the mailing list <caolanm>Jookia: I assume this would be posted to the help-guix list? <rekado_>found it faster to build boost from source than to wait for the substitute to download <NiAsterisk>how much in donations are still needed for new servers (iirc hydra in vserver was the bottleneck?)? I've been trying to configure a new system and don't want to build derivations from source, so I've been repeating system init before I went to bed and now afterwards. occasionally I get more than 5 packages^^ <efraim>still down the libvpx rabbit hole, now working on gstream and its plugins <efraim>this patch set looks like it's going to be as long as some of the python chains I end up with <efraim>gst-plugins-ugly=good, gst-plugins-good, gst-libav=bad <efraim>if I fix those two then hopefully I've reached the end ***piyo```` is now known as piyo
<rekado_>one popular bioinfo project finally clarified their license, so I can move it from my private repo to Guix upstream! <rekado_>they used to have a stray LICENSE file containing the old artistic license, but recently they removed it and clarified that the project uses the boost license. <civodul>it's good that you took the time to discuss it with them! <rekado_>it wasn't a result of me speaking to them. Someone else did and they replied. (When I wrote them an email I was ignored.) <rekado_>but anyway, it's great that there is one project less that uses the old artistic license. <rekado_>there are quite a few bioinfo projects that use the artistic license; it's usually by those people who have a background in Perl. <rekado_>I should prod a couple of them again to see if they would consider changing the license to the clarified artistic license. <civodul>rekado_: good outcome anyway, and it shows how network effects play on license choices in "apolitical" circles <civodul>lfam: the contents of the .git subdir may vary from one checkout to another <civodul>i don't know if this has any effect on this <civodul>but why is .git/ needed in the first place? <davexunit>many pieces of software are only buildable from the git repo <davexunit>almost all Ruby gems do this, but we've found ways around it. <civodul>ACTION tends to forget about terrible situations :-) <davexunit>many people have no idea that their "releases" (auto-generated github tarballs) are unbuildable. <civodul>unrelated, but did you know that hydra.gnu.org receives 5G/day and sends 15G/day? <civodul>or we use networking inefficiently :-) <civodul>kmicu: how does Nixpkgs handle that? <davexunit>civodul: in the case of ruby, they just use .gem archives as-is, IIRC. <kmicu>civodul: It is ugly, but I don’t need to touch Ruby/Rails so I can avoid it ;). That’s also a reason why I have no idea how Bundler infra is solved in Nixpkgs. I guess they modify ‘.git’ to make it deterministic, but alas, ‘git ls-files’ is still in use. <davexunit>so kmicu isn't having trouble with packaging ruby software? <civodul>good idea; simple, and good enough for 'git ls-files' <civodul>davexunit: kmicu doesn't have any problems ;-), i was just asking them if they had tips <lfam>In that case, the build process errors out if it can't get the version from some part of the git metadata. I didn't investigate too much yet and it's not necessary in this case except for debugging. But I remember there was a conversation with some useful info. I think Joey Hess weighed in with some solutions from git-annex <lfam>I have to go. I'll check the logs later! <kmicu>Ruby infra is in flux in Nixpkgs. There is more than one solution available. I cannot give you more info, b/c it’s not my area. I always skip any Ruby related stuff like Bundler/Gemfile.lock/Bundix https://github.com/cstrahan/bundix <davexunit>now I need to get all of my demonstration material sorted and attempt to throw together a way to do a live recording. <NiAsterisk>your CA cert fails with gnurl and wget here on my guixsd. I'll open it on the debian computer <mark_weaver>NiAsterisk: iirc, davexunit, like me, refuses to give money to the CA racket, so uses self-signed certs instead. <davexunit>NiAsterisk: I use a Let's Encrypt signed cert <NiAsterisk>though there's letsencrypt now. I had the same issues in the past and ran my own CA. <mark_weaver>I've been waiting for letsencrypt, although I guess it's now usable so now I'm just procrastinating :) <mark_weaver>davexunit: oh, interesting. I would have thought nss-certs would accept that. <davexunit>you cert chain must not have the necessary information to count Let's Encrypt as a trusted source.l <NiAsterisk>davexunit: than it is weird i can't download it here. hm <davexunit>hovering the mouse over it should reveal "Verified by: Let's Encrypt" <NiAsterisk>i just wanted to point it out, to see where the mistake was :) <NiAsterisk>maybe guix' wget does not have letsencrypt, or the nss does not have letsencrypt? <mark_weaver>NiAsterisk: On my system at least, I use the same trust store database from both IceCat and wget. It's all based on the NSS trust store from Mozilla. <civodul>you would think tokenizing a string is routine <NiAsterisk>if there was a bitmessage chan (and I would get to complete packaging pybitmessage for guixsd before publishing it optionally), would it be an option to publish it on the projects website? I just created the chan, not advertising it as official but more as a means for communication for those who prefer bitmessage. I'll be able to put it online for display of the name + BM-ID in the news few weeks. <NiAsterisk>distributed, end to end encrypted, email-like communcation <NiAsterisk>civodul: there are 2 versions of the official client atm, Bitmessage/PyBitmessage and one which gets soon (no idea when) merged into the first one, which is located at mailchuck/PyBitmessage (feature wise way ahead of Bitmessage upstream) <fhmgufs>How far is GuixSD away from ARM support? <NiAsterisk>it's one of the essentials I am working to package at slow speed :) <rekado_>I don't understand the claim bitmessage makes that addresses cannot be spoofed because the address is the hash of a public key. <rekado_>fhmgufs: Guix (the package manager) can already be used on top of another GNU/Linux distibution on ARM. I don't know if someone is currently working on bringing GuixSD to ARM. <fhmgufs>But using GuixSD on ARM shouldn't be different to using it on x86, right? <fhmgufs>So it's just a problem of the packages' support for ARM. <fhmgufs>But as I got to know it's working now on ARM. <mark_weaver>fhmgufs: to get GuixSD on ARM, we mainly need: a suitable kernel+config for the supported ARM device(s) and GRUB for ARM. <rekado_>GuixSD uses GRUB, so we'd need GRUB on ARM, too. <NiAsterisk>my understanding so far is, that it is a software which has good parts which can later be combined into features software running in gnunet can offer. the obvious practical usage for me is that it does not rely on email servers. it has not been audited yet, but I guess it has good potential, as it can (people with more insight into networking and messaging said and analyzed so) scale better than bitcoin. you <NiAsterisk>could use tor for initial setup and usage, but it's kinda very slow when you repeatedly hit exits which lock ports you are trying (my experience). <fhmgufs>My question was about basic packages that still don't work on ARM. <fhmgufs>Please wait, I'll rejoin in a minute. <fhmgufs>I just would like to know if there are other required packages except from the dmd in 0.9.0 that make it impossible to build a system on ARM. Running it is another question (bootloader, kernel ...). <mark_weaver>fhmgufs: for the most part, our armhf part looks fairly good. the key packages that are failing to build on armhf now are: dmd, gst-plugins-base, mozjs, and r <mark_weaver>well, probably you don't care about that. it's a statistics package <fhmgufs>So, when dmd works (shepherd works) it'll be ok. <mark_weaver>gst-plugins-base means that anything based on gstreamer won't work, including icecat <mark_weaver>so it depends on what you want to use the system for <mark_weaver>but yeah, for the most part our armhf port is in fairly good shape. <fhmgufs>And what's the problem with linux-libre? <mark_weaver>well, there's a lot more diversity in ARM systems. The one I personally own requires extra patches and a custom kernel config. <mark_weaver>right now, our linux-libre packages are based on the idea that there's just one kernel config that runs on every system. <fhmgufs>But if I install kernel and bootloader manually, it would work with the next release (updated shepherd). <mark_weaver>Debian has an ARM kernel that works on a large set of systems. someone needs to look into what's needed to enable that. <mark_weaver>preferably someone with an ARM system that such a kernel works on. I don't have one. <mark_weaver>well, I've never tried to use GuixSD with a kernel that was built outside of Guix. I guess it could be done but it's not what I think of as "GuixSD". <efraim>re: guixsd on arm- I was thinking of kexec so I could have uboot+kernel to start and then kexec boot to use linux-libre, but kexec was only introduced in 3.17 <NiAsterisk>the build process of cmake, the duration of it during guix init system on this old netbook reminds me of how I did not run gentoo on it for long. <mark_weaver>NiAsterisk: you shouldn't need to build cmake. did you enable binary substitutes? <NiAsterisk>init failed so many times that at some point init process decided to start compiling on its own <NiAsterisk>connection to hydra was bad but I refused to use substitutes, this just happened because who knows why <bavier>I've recently had a lot of dropped connections from hydra too <mark_weaver>NiAsterisk: hydra is overloaded, in need of a hardware replacement, but it's still usually better to keep retrying the downloads than to build everything from source. <NiAsterisk>i did retry for 8 hours i guess. i'Ll give it another shot <roelj>How is the process of getting new hardware coming along? <NiAsterisk>which is why I asked, how much in donations are needed? I don't have much myself, but can donate occasionally. <francis7>paron_remote, hi. can you bisect linux for me? <francis7>on your debian install, since I know guix is awkward to hack to run custom built stuff <francis7>paron_remote, we need to bisect between linux 4.2 and 4.4 on the x200 with libreboot, where the assumption is that the epoch issue is present with later kernels, but gone once reverting back to previous kernels <francis7>we need to know (from upstream kernel.org linux git repo) which commit introduced the issue <francis7>I'd do it myself, but I don't have time, though this is very important <francis7>(the paste above is for reference only. don't do anything it says on that paste.debian.net link yet. We just need to know what commit in linux introduced or otherwise exposed the issue) <francis7>we think it's a coreboot bug, exposed by a change/fix in linux. the bisect of linux will help us confirm that <francis7>mark_weaver, it's important, because dates of 1970 break TLS certs and all kinds of things (including many build systems) <mark_weaver>given that it's thought to be a coreboot bug and a patch is already available for coreboot that makes the problem go away? <francis7>according to that paste, if indeed this is a coreboot issue, that paste says you still need to run a util afterwards to reset a byte from 0x32 to 0x20 <francis7>I'm only interested right now in bisecting linux <francis7>bisects are usually fast (binary search method) so shouldn't be too problematic.. <NiAsterisk>if I did build it before, where is the working-folder I need to delete to prevent it from building? <francis7>paron_remote, btw, this is only a request :) <NiAsterisk>rephrasing my last sentence, what is the name or extension of the file/folder *cmake* I need to delete to prevent a continuing buil dfrom source once guix init system hits cmake <bavier>what does it mean if '(getpw (getuid))' errors with "In procedure getpw: entry not found"? <davexunit>bavier: that get the user account information for the current user <caolanm>how would I enable the gpm-service in my system configuration? <caolanm>bit confused how to include services outside of the base/desktop sets <fhmgufs>Which machines are used to build the ARM substitutes? <mark_weaver>(and we have two more Novena's which we need to set up and add to the build farm) <mark_weaver>fhmgufs: well, the build hung for one hour without producing any output <mark_weaver>well, to be honest I'm not sure. maybe that build step just takes a very long time. <efraim>how long does the build take on mips? <mark_weaver>fhmgufs: if you have your own ARM box to try the build on, you could pass --max-silent-time=14400 to 'guix build' <fhmgufs>Yes, I could just leave it on over night. <mark_weaver>caolanm: write something like (services (cons* (gpm-service-type) %base-services)) <fhmgufs>Well, on mips64el it fails at the same point. <mark_weaver>section 7.2.1 of the guix manual (Using the Configuration System) shows an example. <fhmgufs>And the whole build time is about one hour longer. <mark_weaver>fhmgufs: I suppose there's a good chance that it just takes more than an hour <fhmgufs>By the way: is there a better way to look for the build results on hydra than this webapp? <fhmgufs>Where I can specify my search: for example only ARM or only timed out (return 100) builds. <mark_weaver>iirc, our emacs interface now includes a way to browse build results from hydra, but I haven't looked at it yet. <mark_weaver>you can see only arm builds in the evaluation pages by typing ".armhf-linux" in the "Search jobs by name" box. <mark_weaver>NiAsterisk: see the "Emacs Interface" section in the guix manual. <fhmgufs>mark_weaver: thanks, I didn't know that. <mark_weaver>and there's little section on "Hydra" in there now too <mark_weaver>fhmgufs: I don't think there's a way to search for failed builds based on whether they timed out. <fhmgufs>mark_weaver: was just an example, but would be good (since hydra can report the return value it could provide an option to filter by it) <mark_weaver>it's mostly written in perl, and I haven't written perl in over 20 years. I'd prefer to leave it behind :) <davexunit>would be nice to hear what you have in mind for a new design <mark_weaver>I don't yet have a new design in mind, I only know that the current design has far too much of the work being done on the central master machine, and it's not scalable. <davexunit>I have never dealt with hydra so I'm just curious to know about the problems <mark_weaver>I'm also not happy with the fact that every machine in the build farm needs to trust every other machine in the build farm. <mark_weaver>as for the web interface, I think I'd be inclined to statically generate the most commonly accessed pages. <davexunit>the web interface could also live on another machine, if that helped things. <fhmgufs>It would be cool if there was a kind of substitute exchange protocol extending hydra to all the users machines. <fhmgufs>So that if one user builds a package another user or a substutute server can use the output. <mark_weaver>fhmgufs: the plan is to use gnunet for decentralized distribution of binary substitutes <mark_weaver>fhmgufs: you should be aware that by using a substitute, you are placing a lot of trust on the provider of that substitute <fhmgufs>But if the packages are reproducable? <davexunit>how does one decide if a package is reproducible? <fhmgufs>There must be a mechanism which makes the user sure a package was build by guix build. <davexunit>the issue is: what kind of consensus is needed in a distrubuted system for it to be able to say "package X has hash Y" <mark_weaver>three people doing the build on a particular kernel could agree on the hash, and then a fourth using a different kernel gets a different output. <mark_weaver>or: three malicious folks claim that "package X has output hash Y" to create a false consensus. <fhmgufs>But I thought if the output is different, the package gets another hash. <mark_weaver>fhmgufs: well, it depends on what hash you're talking about. <mark_weaver>the hash that's in the name of the output directory is just the hash of the derivation and inputs. <bavier>fhmgufs might be thinking of fixed-output derivations <mark_weaver>but of course it would be useful for people to generate hashes of the outputs and digitally sign statements that "derivation X generates outputs with hash Y" <fhmgufs>Maybe it is possible to only be able to substitute packages if at least to independent users got the same result? <mark_weaver>fhmgufs: how do you know whether two users are independent? <davexunit>fhmgufs: what if those 2 machines were colluding to spread a poisoned binary? <mark_weaver>it could be one person pretending to be two different people, or two malicious people working together. <davexunit>I think that the web of trust that mark_weaver is alluding to would be important <davexunit>"do X% of the people I trust agree on this?" <mark_weaver>the best solution I can think of right now is this: users can digitally sign machine-readable declarations that "derivation X generates outputs with hashes Y1, Y2, ..." <NiAsterisk>gnunet has the option / plans to (i'm still reading up on huge parts of the whitepapers) to flag bad nodes in some way, whereever this function is, could be useful I guess? <mark_weaver>and we have an automated system for collecting these signed declarations, similar to how GPG keyservers collect signatures on people's keys. <mark_weaver>and then, before downloading a substitute, you could see what signatures are available that authenticate the outputs. <mark_weaver>and decide who's signatures to place your trust in, based on reputation. <NiAsterisk>i think it would be best if potential threat models are listed and then decide what's the way to do it with the least damage? <mark_weaver>you could configure guix to only download substitutes which have been authenticated by the set of users whom you choose to trust. <fhmgufs>Wait, you're speaking of a central substitute server. <NiAsterisk>which is okay for when you know some people, but what if you are just starting out and need lazy defaults which should just work? <NiAsterisk>and this reminds me of the WoT model which is not that optimal. <mark_weaver>fhmgufs: not necessarily. these signed declarations could be stored in a DHT <fhmgufs>What I was thinking of was a kind of peer-to-peer principle between the users. <mark_weaver>there are many options for how to distribute the signed declarations. NNTP is another option. or friends could just exchange them directly. <fhmgufs>If I'm whinking about it a central substitute server is still the best option. <davexunit>we'd like for users to not have to trust us. <NiAsterisk>but a move towards a distributed net without a single trusted authority provides a different perspective <fhmgufs>Users could rebuild things locally, create an output hash and these hashs could be collected to verify the hydra build results. <NiAsterisk>fhmgufs: there could still be individual, bigger servers for just building, it doesn't mean that it's just running on users daily used devices. <mark_weaver>it's also worth mentioning that it's not sufficient to trust someone's intent. one must also trust their competence to create an unhackable system. and given the capabilities of the NSA and other hackers, I'm not sure that I trust *anyone* that much. <fhmgufs>But if users don't trust substitute providers they can build there packages themselves. <mark_weaver>quite frankly, between having to worry about machines being modified in shipping, colo's being infiltrated or coerced, etc, I don't know how to defend against these threats. <NiAsterisk>right now, hydra could be censored in some places. the distributed solution I see with gnunet is that you get more flexibility, routing, and you don't have to care about opinions of ISP etc. <mark_weaver>the only solution that gives me any hope is to create a decentralized framework where all it takes is one person who manages to have a machine that hasn't been hacked to detect problems. <fhmgufs>But would such a network be usable for a normal user wanting to install a package in no time? <davexunit>fhmgufs: sure, look how fast bittorrent can be. <NiAsterisk>at the time when gnunet is in use (next few years will show some changes), I bet it will if the application for distribution is easy enough <mark_weaver>well, there could be a central build farm for efficiency, and a decentralized system to verify that the central build farm is producing authentic outputs. <NiAsterisk>or a number of n build farms being part of the distributed net, plus the users <petter>davexunit, i was looking through your presentation and noticed you list "Encrypted root" on slide 69 "Future". Unless i'm misunderstanding this is already possible, i'm running a fully encrypted GuixSD installation right now <NiAsterisk>how did you manage to do this with full disk encryption? I thought it wasn't possible? <davexunit>petter: I really thought you could encrypt everything *except* root <fhmgufs>davexunit: Where can I view your slides? <NiAsterisk>petter: I would be interested in how this is done in config.scm , a lack of fde is the only thing some people I know complain about <mark_weaver>petter: iirc, you've done this on both Libreboot machines and non-Libreboot machines? <davexunit>comments and errata welcome on the above PDF <davexunit>I will tweak it a bit more before I present tomorrow, but it's basically done. <petter>mark_weaver, this is my Libreboot. I've also installed GuixSD at work, but i actually don't remember right what i ended up with there <petter>I'm pretty sure i just left /boot unencrypted <mark_weaver>petter: okay. without Libreboot, I suspect there might be additional complications, due to GRUB being located on the hard disk. <alezost>davexunit: wget on this pdf gives me: "ERROR: The certificate of ‘git.dthompson.us’ is not trusted." What can I do about it? <NiAsterisk>petter: did you just setup cryptsetup as usual, opened them, and then when you define the file-systems in config.scm you chose "crypt" as type? <alezost>davexunit: how can I turn ssl verification off for a wget run? <fhmgufs>Has Volswagen in the US such a bad image that you put its sign next to the NSA's? <davexunit>but yes, they don't have a good image among the tech crowd <fhmgufs>In Germany we have forgotten about Volkswagen now, I think. <davexunit>reproducible-builds.org uses the VW scandal as an example <fhmgufs>Not Volkswagen but it's software failures. <davexunit>if builds were reproducible, the EPA could verify that the software running in the car is not what they claimed, provided they could build from source themselves. <fhmgufs>I would like to compile it in my car. <davexunit>no, but you could picture a legal situation where the EPA is allowed to inspect code. <alezost>davexunit: page 66 is fun :-) (1 user) <davexunit>alezost: hehe I thought it was funny so I threw it in there <efraim>100% commit rate increase over the past 12 months <fhmgufs>Well, if you wouldn't have to log in there I had rated it, too. <NiAsterisk>petter: mapped devices is automagically detected and set with guixsd (like with dracut on gentoo) or does it use the same mapped devices used when setting up guixsd for the first time? i'll eventually figure it out myself, I'll redo some systems <davexunit>good news! "Solving the Deployment Crisis with GNU Guix" has been accepted for LibrePlanet! <petter>NiAsterisk, i don't fully understand your question, and i don't know dracut. But if it helps, I'm pretty sure i can change the target name in mapped-device, and similarly in 'device "/dev/mapper/newname"', reconfigure, and it would work. <NiAsterisk>names have too much, they are not being changed by some internal function of guixsd, that's the short version of explaining dracut and my question. dracut is for generating an initramfs in gentoo, one of the choices. <petter>the names themselves are not magic, i just made it up, and i'm pretty sure i used a different name during installation <petter>so yeah, as long as they are equal <francis7>someone here mentioned earlier about encryption including /boot/ on guixsd <francis7>petter, would you be interested in writing a guide like those linked above, but for guixsd? <petter>francis7, i could do that sure. But i wouldn't be able to verify <petter>ok, i'll put together the steps after a best effort approach <francis7>petter, even some instructions emailed to libreboot@nongnu.org (libreboot mailing list) would be just as good <francis7>then we in the libreboot project can fill in the gaps <efraim>what did I miss while escaping this: "fail_unless\\\\ \\\\(GST_MESSAGE_TYPE\\\\ \\\\(msg\\\\)\\\\ ==\\\\ GST_MESSAGE_EOS\\\\);" <mark_weaver>petter: I would be grateful if you wrote such a guide. I would be willing to test the guide myself :) <petter>mark_weaver, it's basically just the config.scm that is special as far as i can tell now <mark_weaver>efraim: for a regexp in substitute*? the spaces don't need to be escaped <efraim>i'll try that, see how it works in another 15 minutes <efraim>right now it's not catching the line <mark_weaver>efraim: or just run 'substitute*' from the guile repl on a test file <mark_weaver>I think the parens are the only thing there that needs to be escaped <efraim>i escaped spaces in the previous one <efraim>if I have (lambda _ (substitute* ....) (substitute* ...)) should I switch it to lambda* ? <mark_weaver>efraim: only if you need to refer to 'inputs' or 'outputs' or similar <paroneayea>francis7: I'm now noticing that I occasionally (randomly!) get dropped into rescue mode even in debian, and I see something in the logs saying "your computer doesn't have a working bios and your hardware clock isn't working" or the like. I'm guessing it's also related to that coreboot bug! <paroneayea>also I'm only a couple hours into being at the office for the Stripe Open Source (sic) Retreat and I've already gotten two people super excited about Guix <civodul>paroneayea: so you've just started the retreat? <mark_weaver>civodul: hmm, looks like someone aborted thousands of core-updates jobs recently (in the last hour). any idea who did that? <civodul>mark_weaver: not me; could it be ae? <civodul>i can imagine it's a very different style ;-) <mark_weaver>civodul: we may need a way to configure max-silent-time for hydra jobs. <mark_weaver>it appears likely that on armhf and mips64el, lilypond remains silent for more than an hour while generating its documentation. <mark_weaver>both the armhf and mips64el lilypond jobs timeout after an hour of silence while running a program that generates the lilypond book <civodul>we could always set that in 'properties'? <civodul>that's pretty adhoc, but it should be OK if it's rare enough, WDYT? <mark_weaver>civodul: right, we made a way to set the timeout in properties, but in this case we need to set the max-silent-time <mark_weaver>I don't know what to add to 'package->alist' in build-aux/hydra/gnu-system.scm <mark_weaver>'timeout' is the total length of time that a job can run, whether silent or not. <mark_weaver>but in this case, we may need to increase the maximum time that silence is permitted before the build is presumed hung. <civodul>well yeah, we need to adapt that 'timeout' thing <petter>are the example configurations located under /etc/configuration in the installation image easily available somewhere? <civodul>petter: yes, under gnu/system/examples <petter>civodul, ah, there they are. Thanks! <petter>is it important if (mapped-devices...) comes before (file-systems...) in the configuration? Does order matter? <efraim>mark_weaver: not escaping the spaces worked, but I commented out too much and the test failed anyway due to timeout. on to replacing the inside logic with 1==1 <civodul>petter: however, it's important to use the same device name in the file system; like if the mapped device target is "home", then "/dev/mapper/home" must appear literally in the file system source <petter>civodul, if you're wondering, i'm jotting down the steps for a fully encrypted GuixSD for the Libreboot site <petter>suitsmeveryfine, Great! I will write down what i think is necessary, but i won't be able to test it, so there may be issues. <petter>anyone have a suggestion how to formulate something like: Add this block of code in your operating-system XXX (mapped-devices...) <petter>i don't know what (operating-system..) etc. are called <bavier>petter: I think the terminology is: 'mapped-devices' is a "field" of the 'operating-system' record. <civodul>yes, or "'operating-system' declaration" <mark_weaver>I wish I knew who aborted most of the core-updates jobs, and why. <petter>"Add this field to your operating-system record/declaration (mapped-devices...)" <mark_weaver>I have a suspicion that they may have aborted the jobs for an earlier evaluation, and not realized that it also aborts the unchanged jobs in later evaluations. <mark_weaver>because several hundred of the jobs in the latest evaluation were not aborted <petter>suitsmeveryfine, right. I was thinking the same thing. I'm not sure if i would know where to put this code if i read this in 2 weeks <petter>because i'm not familiar with the terminology <suitsmeveryfine>the most important thing is to get a working guide that we can follow until the end <mark_weaver>petter: I'd be glad to review it and fix it to use proper terminology. <petter>mark_weaver, Great! I'll worry less about this side of it then <civodul>so now we need to make that appear on the web site <petter>ACTION takes 8.231 push-ups to celebrate <civodul>thanks to everyone who gave, now we have a bit of pressure to handle that successfully :-) <calher>civodul: I don't believe you, but awesome if you did. <Gamayun>civodul: What was roughly the goalpost for the buildfarm again? <paroneayea>davexunit: I guess now that we know that our guix talk got accepted we need to think about coordinating it ;) <davexunit>paroneayea: yes, we can coordinate after that! <civodul>Gamayun: we were aiming for roughly ~5000 to buy the new front-end <civodul>and then extra money can be used maybe for hosting, and otherwise for additional build machines <civodul>a_e: mark_weaver & i were wondering if you had canceled core-updates job earlier today? :-) <a_e>Yes. I thought it would stop only those of the corresponding git commit and not of later commits. Restarting did not work because hydra was overloaded. <mark_weaver>a_e: I have an SQL query to cancel pending builds in a given jobset that aren't part of a given evaluation. <civodul>mark_weaver: i had to restart hydra-server, so i suspect this query is no longer pending, is it? <a_e>mark_weaver: That sounds useful. <civodul>mark_weaver: ah sorry, i misunderstood <civodul>anyway, everything seems to be ok now <civodul>mark_weaver: the evaluator is not currently running, we can restart it once the load has dropped <mark_weaver>okay, I'll cancel the outdated jobs and then restart the jobs in the newest evaluation. <a_e>I suppose my restarting the jobs was already effective, but that it somehow killed the web server. <a_e>Maybe you could still try to run your SQL query (although I suppose that all jobs running now are also part of the latest evaluation). <mark_weaver>I ran it, and found that there were no outdated builds queued. <Gamayun>civodul: Nice! Well, hopefully there's a beer for you as well in there. ;) <mark_weaver>heh, that's a slippery slope. I think we better buy our own beers to celebrate, and use this money only for build machines :) <calher>Why does Guile's (sxml simple) module put everything in (*TOP*)? <calher>You'd think <foo>bar</foo> would become (foo bar). <mark_weaver>normally XML documents have multiple top-level items, e.g. processing instructions, comments, and elements. <civodul>Gamayun: yeah we'll have a beer, but buy it on our own :-) <petter>it's a little messy, but i'm tired and shall go to sleep now. If you have any comments i'll read them tomorrow <codemac>question - anyone here run guix with nix-daemon? <civodul>codemac: not me, but that should work <mark_weaver>but Guix does not use any components at all from the host system when building things. it starts with bootstrap binaries and goes from there. <mark_weaver>we provide bootstrap binaries for x86_64-linux, i686-linux, mips64el-linux, armhf-linux, and work is in progress on i686-hurd as well. <mark_weaver>but Guix is not intended for building stuff on top of arbitrary systems and their libraries. We are building the GNU system, and if it were ported to XNU, it would be using GNU libc, GCC, binutils, etc, on top of XNU.