<mordocai>In my standard environment (so not in a guix enviroment shell) I get http://lpaste.net/151818 when trying to install wine package with --no-substitutes. I have both guile and gnutls installed in my profile. Anyone know the fix?
<calher>pizzaiolo: can't get gtk widgets to stoplooking like win95
<calher>also im trying to get tor to work so i can get on irc with tor
<mordocai>So if i'm sitting at a guix 0.9.0 binary release, I git pull, guix package -i sbcl (with substitutes), how can I then force guix to build sbcl? guix build sbcl doesn't work and guix build sbcl --check apparently doesn't exist.
<davexunit>the gnu-build-system has 2 phases of shebang patching
<mordocai>davexunit: So I believe sbcl's behavior is currently different based on whether I use the hydra substitute or build locally. I have a machine with the substitute and have observed the behavior, what is my easiest path to building sbcl locally so that I can verify behavior? I don't want to change the build script at all.
<mark_weaver>I find that running guix from a git checkout is by far a superior approach, but many people seem to dislike it for reasons I don't understand.
<mark_weaver>mordocai: the problem you're having with (gnutls) is because the source URI is an 'http' URI, so Guix does not include gnutls in the build environment where the download occurs. but in this case, the site redirects you to an 'https' URI, and then gnutls is not available.
<mark_weaver>mordocai: the fix is to change the source URI in the guix code to use https
<mark_weaver>mordocai: I guess they started redirecting to https since we last updated that recipe.
<mark_weaver>mordocai: clone the guix repo, build it, make sure it works by building a package with "./pre-inst-env guix build netcat" or something like that, and then make both ~/.config/guix/latest and ~root/.config/guix/latest symlinks pointing to the top-level directory of the git checkout.
<mark_weaver>mordocai: see the "Building from Git" section of the Guix manual. One important note: pass --localstatedir=/var to Guix's configure, to match the localstatedir of your existing Guix installation.
<mark_weaver>(we use --localstatedir=/var for our binary installer and GuixSD)
<mark_weaver>mordocai: no need to run the right daemon. an old daemon will work with a new guix client.
<mark_weaver>but if you want to run the daemon from the git checkout, just run /path/to/git-checkout/pre-inst-env guix-daemon ...
<mordocai>Yeah, apparently the build --check feature is only in the git checkout's daemon for instance
<mark_weaver>to be honest, I've always thought that "guix pull" was an inferior method. IMO, it's only purpose is to lower the barrier of entry for people who don't want to deal with building from git.
<mark_weaver>(and the only person who has more commits in Guix is Ludovic)
<marusich>At a high level, what does guix pull do? The manual doesn't specify. I know I could dig into the source, but if you can explain it in 20 seconds, I'd be much obliged.
<marusich>I had assumed it managed some git repo somewhere, but I was told that is not the case a few minutes ago.
<mark_weaver>marusich: it downloads the latest guix sources from git (master branch), builds it, and then makes ~/.config/guix/latest a symlink pointing to it (in /gnu/store)
<mark_weaver>actually, it doesn't use git to download, though. it downloads a tarball snapshot of the git repo that is automatically generated by savannah.
<marusich>Had to configure Gmail to allow connections from "less secure devices", tell emacs to use SSL, and spent hours trying to figure out why I was getting "no route to host" only to discover that my home network does not play well with IPv6.
<mark_weaver>for example, right now our "guix" package is fixed at commit c3f29bc928d5900971f65965feaae59e1272a3f7 and will continue to be until we explicitly update it, like any other package.
<marusich>it might be that emamcs uses tls by default, but I wanted to make absolutely sure before letting it send my credentials over the wire. You can force it to use TLS. It seems to use IPv6 for connections by default on GuixSD though, so I was surprised
<marusich>I couldn't figure out for the life of me why netcat could connect just fine to smtp.gmail.com on port 465, but emacs could not. I didn't realize what was going on until I used tcpdump to get a packet capture.
<marusich>But anyway. Now it's working, so that's good. I'll have to hunt down the devices on my network that don't like ipv6 and fix or r eplace them.
<mark_weaver>my home network also have problems with IPv6. my ISP has IPv6 support, but its broken.
<mark_weaver>I work around it for now by doing "sysctl -w net.ipv6.conf.all.disable_ipv6=1" but that's probably not the best approach.
<marusich>So yeah, I think one of the reasons why I was having such a hard time w/email and emacs is because even if I had figured out (for the first time ever) how to set things up correctly, I still would have had to get IPv6 working and know to go tell Google to allow connections from "less secure" devices...so much stuff to configure!
<mark_weaver>(and some packages fail to build from source while that's set, because their tests assume IPv6 support is available)
<marusich>Ah. That would probably work, yeah. I hope I don't have to do that. I'll bet only a few devices in my network are misbehaving. I'm connected directly to my router now, and it works, so it must be something inbetween.
<marusich>Anyways, gonna go mess with that. My battery is dying. See you later!
<yitz_>I'm trying to wrap my head around this, still
<mordocai>calher: Not all of GNU cares about reproducibility
<mordocai>FSF is a social cause not a technical one, after all
<calher>mordocai: what does reproducibility have to do with no #!/usr/bin/env in Guix but yes #!/usr/bin/env in Bash
<yitz_>I think you're confusing a shell and a file system layout
<yitz_>What's the file system layout policy thingy called again?
<mordocai>Who says that /usr/bin/env will be there? For complete reproducibility you should rely on nothing that is not under your control, and guix on a non-GuixSD system can't necessarily control whether or not env is in /usr/bin/
<cehteh>Applications should note that the standard PATH to the shell cannot be assumed to be either /bin/sh or /usr/bin/sh, and should be determined by interrogation of the PATH returned by getconf PATH , ensuring that the returned pathname is an absolute pathname and not a shell built-in.
<Jookia>Yes, but what's the point of a completely GNU one
<mordocai>That seems like a strange question to me. What's the point of anything?
<Jookia>If you start writing a free system as there's no other free systems around and people start making tools that work with it that are also free, why not use those
<Jookia>What could be gained besides having the name 'GNU' on it
<yitz_>Yeah. If that was the goal all along, then everything done would fit nicely with that goal. I never viewed GNU through the perspective of that goal.
<Jookia>If you look at most GNU tools, there are things that seem like duplicates when compared to other tools (Linux/Hurd) but actually further GNU ideas
<yitz_>Don't we already have completely free distros, though? Is there value to having yet one more?
<Jookia>What's GNU going to do to innovate on say, Ardour
<Jookia>There's always value for having more distros
<mordocai>Meh, I find your whole argument silly and unconvincing personally. Why does it have to have a purpose? It's a cool new system with cool new ideas and happens to make it possible to have a completely GNU system.
<yitz_>I didn't say it shouldn't exist or that it's a bad idea. I just said I found it weird
<rekado>"GNU's always seemed like a standard toolset" <-- that's a common misconception.
<rekado>GNU is more than just GCC + bash + coreutils.
<rekado>as far as free distributions go, I found the choice to be rather limited.
<NiAsterisk>is the failing gnunet-gtk still relevant, ie not worked on? I would like to give it another try soon to see if I can spot some corrections I can make
<NiAsterisk>don't you "love" 1 word replies with no reference to your message? I asked if I could do sometime in the first half of this year a short talk "an beginners introduction to guix packaging" for really really beginners, no coding experience whatsoever, first reply I get "Mh, I just just started with Nix/NixOS" .... okay?
<efraim>so... they're learning something else so they're not even interested?
<NiAsterisk>possibly. but it was a proposal/question to one of the hackerspaces in city next to me. I even specifically said that I don't want to get into the projects history and all the technical details other people have given better talks about. Sometimes I want to get my own email server, just for the purpose to have an auto-reply like rms, and it would include a line like "please respond on topic or expect no
<NiAsterisk>response.".. seriously, what's the point of "hey, I like cars I want to talk about this one special really cool car!" random person: "oh, i like ducks."
<NiAsterisk>I wrote an reply where people hopefully don't read things between the lines which aren't there. I dislike pointless discussions of things I did not imply, I can't read everones minds and feelings.
<myglc2>I am finding it difficult to understand and use both "guix pull"
<myglc2>and "git pull"? Last night mark_weaver said "so the git method
<myglc2>is a *lot* faster". So, should I use only "git pull" to simplify
<myglc2>my life? Is there any downside to that? PS: I am running guixSD.
<mark_weaver>myglc2: using git won't *simplify* your life. it is somewhat more complex. but it is more flexible and updates will be faster.
<fhmgufs>mark_weaver: Couldn't there be sth like the gtk-icon-themes derivation when building a profile for gtk themes, too?
<fhmgufs>... creating a store directory which could be set as GTK_DATA_PREFIX?
<NiAsterisk>cool. they recommended me to wait for the call for papers for the annual LaborTage convention at their space.. for a first talk that's a bit bigger and later in the year (autumn), but it gives me more pratice and more time to maybe let my slides and notes be checked for factual errors.
<mark_weaver>fhmgufs: we could, but it would still only unify the themes from a single profile. there would still be the user profile and the system profile.
<myglc2>mark_weaver: You said, 'I've *never* run "guix pull"', and 'to be honest, I've always thought that "guix pull" was an inferior method.' Based on my experience with guixSD, it seems like at least one "guix pull" is required to bootstrap into git.
<mark_weaver>you can build from git using the older packages available in guix before the guix pull.
<myglc2>But how do I get git, I don't think I saw it on the ISO.
<mark_weaver>however, I admit that it might be preferable to do the 'guix pull' first, because maybe hydra no longer has the substitutes for the older versions of packages in guix before the guix pull.
<NiAsterisk>guix package -i after you did guix pull in the installation medium
<wingo>mark_weaver: do you add xf86-video-intel to your packages in your os configuration?
<jchmrt>Hey everyone, when i boot up my laptop running guixsd it ends with the message "root: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY" and drops me into a guile repl. I am not quite sure how to run fsck in the guile repl, does anyone here have any idea?
<mark_weaver>wingo: no. that's irrelevant, because x86-video-intel is in the xorg configuration in gnu/services/xorg.scm
<jchmrt>mark_weaver: there isnt a directory ending in e2sfprogs-1.42.13 in /gnu/store so dirs is evaluated to '() for me. There is however a directory ending in e2fsck-static-1.42.13, should I use that one instead?
<mark_weaver>I wonder how much bigger our initramfs would be if we added readline
<lfam>Does anyone have any ideas about how to rebuild a package (python-2) that is alive in the store, so that I can investigate reproducibility? Can I save the results of `guix build --check` somewhere?
<davexunit>though I'm afraid I don't understand what manolis meant about building a "second stage" of avr-gcc
<lfam>The total size of readline's closure is about 67 MB, but readline itself is only 1.2 MB