<zacts>the first thing I'm going to go for is i3wm
<mark_weaver>the reason I don't use pre-built binaries on my Yeeloong is because I consider it to be my (relatively) high-security machine. e.g. it's the only machine that has my private GPG key, and the only machine with the key to get root access to some other machines.
<mark_weaver>toxemicsquire4: phant0mas / ph4nt0mas here on channel is the main person working on it. it's been slow going.
<mark_weaver>part of the problem is that the official releases of hurd and glibc don't even work together. the hurd folks have been focused on debian for so long, things have become dependent on debian-specific patches.
<mark_weaver>we have a 'wip-hurd' branch in the git repo, last updated 4 weeks ago.
<mark_weaver>I guess the one caveat I should mention is that, just like the other fully-free distros, it won't run any hardware that requires non-free drivers or non-free firmware.
<toxemicsquire4>mark_weaver: That's my problem. I have a proprietary wifi card. Sadly. I did buy a free wifi card, but it takes a very long time to ship where I live
<nkar>toxemicsquire4: I mean the tor people seem to argue against using anything except the tor browser, which doesn't use vidalia any more. I guess it's because the browser is the major attack verctor, that's how fbi caught people using tor, for instance.
<nkar>toxemicsquire4: can't you use eth0 for a while?
<nkar>toxemicsquire4: also, if you're new to guix and programming, I'd rather not install guix as a standalone system. at some point, you may want to install something that's not packaged, which you have no idea how to package, and it'll be frustrating.
<nkar>zacts: just add it to gnu/packages/<your package>.scm
<toxemicsquire4>nkar: I actually did install Guix standalone. I loved it. It was very easy. And getting packages through guix package -i was a breeze. It's just that my desktop requires a more "mature" system(Debian) and my laptop is way more "experimental" and I di whatever to it. I would eth0 if I can, but unfortunately, I can't
<nkar>zacts: there may be a way to use a different directory
<mark_weaver>zacts: pass "--no-substitutes" to either guix-daemon or the user command to inhibit downloading binaries.
<mark_weaver>but I can say that one reason we're not using systemd is because the systemd maintainers don't want to support any kernel except linux, and we want to support the hurd.
<toxemicsquire4>mark_weaver: I'll make it simpler: Is dmd supposed to be a dropin replacement for sysvinit or does it want to take over anything that involves networking, logging, etc? Also, does Guile build on HURD yet? Because if it did, porting dmd would be the easiest thing
<mark_weaver>dmd does not want to take over all of that other stuff, no. but it's not a drop-in replacement for anything.
<nkar>hm, mine doesn't show the image, I guess it's built without some library, which is required
<mark_weaver>zacts: this is a good setup if you want to run with your own custom modifications to various packages, because git can handle merging our upstream work into your private branch, or alternatively, rebasing your private work on top of our master branch.
<nkar>I don't have time to fiddle with this, so I'll just find something else
<nkar>so far I've been using gimp, but it's crazy :)
<mark_weaver>trisquel surely has no shortage of lightweight image viewers, but I don't know what's popular these days. 'gthumb' comes to mind, but I don't know if it's still the preferred gnome image viewer or not.
<mark_weaver>toxemicsquire4: ha, you're right! that file needs some updates :)
<mark_weaver>zacts: fwiw, I have my own branch called 'mhw', and I periodically do "git fetch" and "git rebase master" from my private branch.
<nkar>while we're talking about software, mark_weaver, what color theme do you use in emacs?
<mark_weaver>that way, my private commits are always floated to the top of my git history.
<mark_weaver>nkar: I actually use black text on white, which I guess is the default.
<mark_weaver>for most of my computing life, I used white text on black, but when I used the OLPC XO outdoors I found that it didn't work well in sunlight conditions unless I used black text on white.
<toxemicsquire4>mark_weaver: I'm really surprised nobody noticed. I would predict a Guix 1.0 release in about 3rd Q of next year
<mark_weaver>the problem was that the sunlight had to get in to reflect off the back, and that works a lot better when most of the pixels are transparent (white).
<mark_weaver>when almost all the pixels are opaque with only a few pixels for light to get in, the reflection didn't work well at all.
<zacts>mark_weaver: ok I did 'guix package -i nvi' and it's still building everything from source
<mark_weaver>zacts: ah, it sounds like you haven't authorized hydra's key.
<nkar>mark_weaver: too bad, I've been searching for a good dark theme for a long time, but I've always rolled back to the default one. I like how solarized (which also has a light theme) looks on screencasts, but it's too green-ish for my taste. though, I may get back to it at some point.
<mark_weaver>hydra's signing key, that is.. i.e. telling guix-daemon that you trust binaries signed by hydra (our build farm).
<nkar>haha, there's an image viewer called geeqie, guix should make it the default one just because of the name
<mark_weaver>zacts: to enable binary substitutes from hydra, do this as root: guix archive --authorize < hydra.gnu.org.pub
<mark_weaver>hydra.gnu.org.pub is in the top-level guix source directory
<mark_weaver>we do occasionally look at nix packages for ideas on how to solve harder problems, usually with packages that don't cope well with being installed in /gnu/store/... instead of the more typical installation locations, but most of the time I don't look at nix packages.
<mark_weaver>civodul: yeah, I was wondering about --strip-all myself. I'd also be tempted to revert it.
<mark_weaver>civodul`: yeah, I was wondering about --strip-all myself. I'd also be tempted to revert it.
<mark_weaver>civodul`: on my 'armhf' branch, I added a patch to gmp, and now "guix build -K hello" results in a VM overflow while trying to bootstrap. I'm at the point of trying to compile gcc-cross-boot0
<mark_weaver>civodul`: is there a circularity problem introduced by trying to patch gmp?
<mark_weaver>my first guess here is that 'patches' cannot be used in some of the early bootstrap packages, presumably because the patching derivation requires inputs that depend on these bootstrap packages.
<civodul`>mark_weaver: normally in early bootstrap, 'patches' is handled by %boostrap-guile
<civodul`><origin> has a field to specify the guile to use
<mark_weaver>"guix build -e '(@@ (gnu packages commencement) gcc-final'" hits the problem though.
<mark_weaver>civodul`: ah, that's the problem: 'gcc-final' inherits from 'gcc-boot0', but it overrides the inputs, again using (package-source gmp). wrapping *that* with 'bootstrap-origin' fixes the problem.
<mark_weaver>unlike many of the other *-final packages, gcc-final is not wrapped by 'package-with-bootstrap-guile', although it inherits from a package which was wrapped with it.
<mark_weaver>okay, this looks to be going well. I'm now natively building armhf bootstrap tarballs.
<mark_weaver>bah, I spoke too soon. problem compiling glibc-intermediate
<mark_weaver>checking for .preinit_array/.init_array/.fini_array support... ../glibc-2.20/configure: /gnu/store/cb4aacihlv662xm32ba8pv5kw55d7a3h-bootstrap-binaries-0/bin/fgrep: /gnu/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-bash-4.3.30/bin/bash: bad interpreter: No such file or directory
<mark_weaver>civodul`: fgrep in bootstrap-binaries-0 is a shell script, with the following shebang: #!/gnu/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-bash-4.3.30/bin/bash
<mark_weaver>civodul`: what do you think is the problem fix, if anything?
<mark_weaver>civodul: hmm, although both 'patch-shebang' and 'patch-shebangs' seem to assume that executable searched for in the path has the same name. will that be the case for the result of (search-bootstrap-binary "bash" system) ?
<mark_weaver>well, I guess I could have it use the bash from within the binary tarball instead of a previously-existing one.
<civodul>mark_weaver: patch-shebang (singular) takes an optional search path
<civodul>so you could use (list (getcwd)) as the search path here
<mark_weaver>civodul: it would be interesting to know what happens if you remove the "ModulePath" for evdev in the xorg server config. and it would be interesting to see the difference in the xorg server log output between those two cases.
<mark_weaver>I would have hoped that the latest evdev would be as knowledgable about trackpads as the earlier drivers.
<civodul>just looked at the diff of the Xorg logs and i can't see any obvious clue
<civodul>evdev uses "AlpsPS/2 ALPS DualPoint TouchPad", which is probably the right thing (the old Xorg used the 'mouse' driver and didn't seem to know it was a touchpad)