<mark_weaver>if someone wants to port Guix to the XNU kernel, take a look at the "Porting" section of the manual. basically it involves using Guix on an already-supported system to cross-compile a set of bootstrap binaries, and then using those bootstrap binaries on the target system to build a natively-built set of bootstrap binaries, and then going from there and fixing problems as they arise.
<mark_weaver>I don't know off hand how well XNU is supported by GNU libc and the GNU toolchain.
<suitsmeveryfine>lovely, I can't boot the guixsd installer because of a bug in libreboot
<_`_>the biggest problem with trying to support XNU (specifically Apple's XNU) is that whatever route you take (native compilation or cross compilation) it'll have a dependency on the xcode-sdk. That fact in of itself seems to conflict with guix's direction.
<mark_weaver>suitsmeveryfine: do you know it's a bug? booting the GuixSD USB installer from Libreboot must be done differently than for most other USB installers, because GuixSD's installer is not an ISO image.
<suitsmeveryfine>"Search for GRUB configuration (grub.cfg) outside of CBFS from" doesn't work
<mark_weaver>_`_: are you sure? so GNU libc, GCC, and binutils aren't able to target XNU?
<_`_>mark_weaver: they are but you need to build them with xcode-sdk
<_`_>or someone else's prebuilt variants built with xcode-sdk
<_`_>the path to bootstrap is from xcode's clang/llvm
<mark_weaver>suitsmeveryfine: okay. fwiw, even on the X60, I found that GRUB would only sometimes see the USB stick. as I recall, I had to reboot multiple times, try different USB sticks, make sure they were plugged in before booted, or some combination of those things, to get it to work.
<_`_>os x shouldn't be a desired target because of that but just 2c. :>
<suitsmeveryfine>mark_weaver: yes, it's sad that it can be so unreliable. For me, that GRUB entry always work with the latest stable libreboot version but never with the latest unstable ones, with the exact same devices connected.
<mark_weaver>so if someone cares about support for XNU, I think the first step is to add support for XNU to GNU libc and the GNU toolchain.
<_`_>I'd rather see guix on top of potentially nicer systems like illumos kernel. Additionally a guile interface to its resource controllers instead of the java/C silliness they currently have for it would be neat.
<bavier>ugh, trying to fix the ghc package build failures, but now I'm getting an 'unpack failed' with doing 'git push' to core-updates
<bavier>aha, didn't have the remote url configured correctly
<calher>mark_weaver: Wait, remember that Guix has support for the Hurd now.
<mark_weaver>calher: Hurd support is not in the master branch yet.
<mark_weaver>there may be some bits in master, but not enough to actually use it.
<NiAsterisk>ah, i see. I'm not that deep in osx, barely scratched the surface.. I was only exposed to it for some years back in school with macromedia, I might get back to it to say that I have skills with osx on my CV.
<codemac>Getting a weird error running guix on nix, "guix package: error: build failed: derivation ‘/nix/store/678...-guile-bootstrap-2.0.drv’ has incorrect output ‘/gnu/store/d14...-guile-bootstrap-2.0’, should be ‘/nix/store/rzz...-guile-bootstrap-2.0’"
<codemac>is there some different way of hashing I must configure?
<NiAsterisk>some really nice job offers I see have "OSX administration & user experience" in their requirements. It will be another 2-3 years until I can decide on jobs again, but I can work on projects and skills in the meantime
<NiAsterisk>though I wouldn't touch osx otherwise. just "for science"
<codemac>If anyone has a successful "guix on nix" nix package, please let me know :)
<mark_weaver>codemac: to run guix on the nix-daemon with the nix store location /nix/store, you need to build guix from source, and pass --with-store=/nix/store to guix's configure script before building it.
<mark_weaver>and you won't be able to use any of our binary substitutes, so you'll need to build everything from source code.
<mark_weaver>because our binary substitutes are built to use /gnu/store as the store location.
<mark_weaver>alternatively, run guix-daemon side-by-side with nix-daemon, each with their own store.
<mark_weaver>IMO, the latter approach will probably make you happier, because no substitutes means building a *lot* of stuff every time we have a core-updates cycle.
<NiAsterisk>running source-based (like this would be/feel like) systems can be very time consuming.
<Jookia>I wonder how hard it'd be to get a Guix container on Wine using only free software
<mark_weaver>Jookia: what do you mean by a "Guix container on Wine"?
<Jookia>mark_weaver: Something that's bothered me for a while is that we're close to having a fully free development chain for Windows- we can cross compile and we can test executables in Wine. Unfortunately we still don't have a free way of running GNU/Linux on Windows yet, and by free I mean compilable using only free tools and running with only free software. There's some work on getting MSYS2 to play well in Wine which would kind of be w
<xd1le>Jookia: but windows itsef is nonfree ¯\\_(ツ)_/¯
<Jookia>There's many ways to turn people away from free software projects, and most of them I've encountered weren't aggressive
<xd1le>i just came back from a run, so => impulsive commenting
<xd1le>but definitely tell them to reconsider their choice to use windows
<xd1le>i just think it's a waste of time, esp when guix doesn't really have the manpower
<Jookia>I think there's going to be a time and a place when we'll have legacy systems like ReactOS and Wine running a lot of software, and it makes me wonder where Guix will fit in. Maybe it's decades off
<Jookia>But we already see this with things like DOS where we have no free replacements for it
<xd1le>but imo who cares. it's not like there aren't free alternatives to windows
<xd1le>so i guess there can be others, but at this point, there doesn't seem to really be anything else worth supporting
<xd1le>maybe in the future if GNU is dying, guix could adapt
***quigonjinn` is now known as quigonjinn
<NiAsterisk>hi! if I have (services (cons* (lsh-service) (tor-service (config-file "/etc/tor/torrc")) (console-keymap-service "de") %desktop-services)) why does the tor part fail? I also tried it with (tor-service "/path/to/torrc")
<NiAsterisk>I'm just beginning with scheme, so I might misread the part in the manual
<NiAsterisk>it might have to do with my config.scm in general though.. there is one section I am uncertain about.
<NiAsterisk>I'm about to do that, as all my configurations are not on the systems but external. so for understanding and setting up tor to use, I need to understand how file-like object are formed in guix and then change the config.scm of guix accordingly?
<mark_weaver>civodul: NiAsterisk tried (tor-service "/etc/tor/torrc"), and from looking at the manual, I think it's difficult for a non-expert to understand what needs to be done.
<mark_weaver>to be honest, it's not obvious to me what needs to be done either :-/
<NiAsterisk>I guess with the linking to an documented example it would be easier to understand, I got into writing ebuilds and at first gentoo looked very complex to me. given the right explanations one can start exploring
<civodul>agreed, the doc sucks, we should at least add examples
<NiAsterisk>reading the torrc.sample in ~/.guix-profile/etc/tor/ , I could leave DataDir out, but if I would want it, what would be an accurate way to determine the current folder in guix for /gnu/store/$currenttor/var/lib/tor/data ?
<NiAsterisk>btw, what about an wiki where the documentation can refer to for individual examples or more detailed explanations etc?
<NiAsterisk>petter: re: encrypted system (http://sprunge.us/jNUH) one needs a (mapped-device) list entry for every lvm partition as usual, so with an encrypted swap + boot + rootfs it should be adjusted appropriately(just a guess in theorey, I had no encrypted boot + one larger lvm group on every system so far but not guixsd), but I guess that's what libreboot documentation will do.
<NiAsterisk>should've changed the sentence structure, it's intended as a question.
<mark_weaver>fhmgufs: well, for one thing, file lookups in /gnu/store are more efficient this way, and there are a lot of those
<davexunit>fhmgufs: well, it makes the names more regular. retrieving a base32 encoded hash is as easy as taking the first 32 characters of the file name
<fhmgufs>Well, that's true. I think it's not important and it was just a little problem :).
<fhmgufs>Normally I look for files in the shell by typing the first characters and use the autocompletition. That's difficult with these hashs. But hopefully I won't have to look for files in the store so often.
<davexunit>my concern with the store is reaching inode limits.
<davexunit>been the victim of that issue a couple of times, just not with guix... yet.
<mark_weaver>fhmgufs: in practice, that doesn't help much because after a while you end up with several store directories with the same package name.
<mark_weaver>so you end up needing to know the hash regardless of whether it comes first or not.
<davexunit>if you kill it and enable substitutes, you'll keep all of the things that have finished compiling and will get binaries for everything else.
<NiAsterisk_>depending on your system, webkit based installations can take from 3 - 12 hours, what I measured with what I had on gentoo systems with webkit-gtk. depends on what it is actually compiling you have
<mark_weaver>it's not just compiling icecat. it does something roughly similar to what "Cross [GNU/]Linux From Scratch" does, i.e. starting from a small set of bootstrap binaries, compiling a full toolchain, C library, all the other libraries and programs needed to build icecat and all its dependencies, etc.
<petter>suitsmeveryfine, do tell how things work out, including minor details that you do differently
<suitsmeveryfine>great. Will you be around because I'll probably run into some issues?
<NiAsterisk>on my laptops I do wpa_supplicant via commandline, then afterwards I run `dhclient $interfacename` iirc
<petter>suitsmeveryfine, and by the way. The cryptsetup command is something i "borrowed" from the encrypted_parabola tutorial. It's not what i used myself
<petter>suitsmeveryfine, yes, i'll be here the next couple of hours
<suitsmeveryfine>NiAsterix: I ran ifconfig enp1s0 up && dhclient enp1s0 and the system told me that internet connection is up
<wgreenhouse>NiAsterisk: I don't think brave would be a good fit for tails because, even if the client end is free software, it depends on and is only useful with a proprietary network service (their caching web proxy, which is like a MITM between you and all content).
<NiAsterisk>wgreenhouse: okay, to be fair I did not read everything. if I would do it, it would come after trying torbrowser packaging on guix (which has a higher priority for me on my list)
<NiAsterisk>it's an exciting "yay, new software" thing where I might consider checking it out, but I seriously considering it would involve waiting for their ToS and Privacy, which will be released later
<NiAsterisk>I need more data and information to further comment on this browser I guess.
<suitsmeveryfine>petter: after running `cryptsetup luksOpen /dev/<your-luks-partition> guixsd` it's time to create the file system, is it not?
<suitsmeveryfine>the libreboot-parabola guide uses LVM and at this point tells me to run 1) # mkswap /dev/mapper/matrix-swapvol and 2) mkfs.ext4 /dev/mapper/matrix-rootvol
<mark_weaver>petter: the only issue I've noticed (so far) from your HOWTO is that it might not have been clear that the 'target' field of the 'mapped-device' needs to match the /dev/mapper/XXX filename.
<petter>mark_weaver, right. I think this is best handled in the (file-systems ...) part, explanation to "device"
<petter>mark_weaver, do you have any thoughts regarding the (bootloader ...) part?
<mark_weaver>petter: on a GuixSD machine, I don't see any reason to avoid installing GRUB to the MBR. I do it all the time
<mark_weaver>and it has the advantage that the drive would be bootable on a non-Libreboot machine.
<lfam>What should I expect when trying `guix build --rounds`? I did `guix environment hello`, and then `guix build --rounds=2 --no-substitutes hello`, but the compilation only happened once. At least, it seems that way based on the console output.
<davexunit>does anyone know of a known non-reproducible package?
<NiAsterisk>complete blank fresh new system in the install process
<lfam>NiAsterisk: If you didn't do `guix pull` then hydra may no longer have substitutes for the packages referred to on your system. If you are familiar with Debian, `guix pull` is roughly analogous to `apt-get update`
<NiAsterisk>damn. I knew there's something I have to get used to
<lfam>Maybe when we get a more powerful and hydra with more storage we can keep substitutes around longer. This is an annoying issue for new users. Really it should be an instruction in the manual.
<lfam>Can't believe I never did that with root on this system :p
<petter>Regarding the guide i'm not sure where it should start. I see now it starts with keyboard layout and network setup. Personally i think the Libreboot guide should start with preparing the disk. And that good points from suitsmeveryfine before this should rather go on the GuixSD installation manual. What do you guys think?