<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>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
<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.
<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
<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.
<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
<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
<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>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)
<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>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
<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)
<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
<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
<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.
<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!
<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
<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.