<davexunit>that nix-dev rant about the Nix language reaffirms my belief that using Scheme was a great choice. <goglosh>man nix was a kindof awkward choice for a name <goglosh>I'm used to using *nix to refer to unices <paroneayea>davexunit: ooooooooooh thiss is already a great email <davexunit>basically, the barrier between the Nix language and the Nix tools is upsetting this particular person, and likely others. <rekado>re the locale incompatibility: would it at all be feasible to wrap applications in LOCPATH automatically? <rekado>or doesn't this work because people might have different locales installed and LOCPATH must thus be pointed at some profile's directory? <rekado>"It is a fundamental system misconfiguration issue not to have upgraded the binary locale data from one release [of glibc] to another." -- so, can we hard-code the path to locale data in our libc or wrap applications such that they will use the matching locale data? <phant0mas>we may have an issue with large builds (like gcc) on hurd <phant0mas>darnassus and my native hurd machine may get stuck at random times during the builds <phant0mas>it's a problem with hurd's memory alocation mechanism <civodul>that's weird: Debian routinely rebuilds GCC and even WebKit, i think <civodul>anyway, the good news is that it's not a problem on our side ;-) <civodul>ACTION successfully upgraded his profile to core-updates \\o/ <karhunguixi>Hi. I'm trying to have Tor start during boot (using config.scm and reconfiguring). But alas, i've been unable so far. How do i do it? <karhunguixi>i've tried adding tor to the list of "use-package-modules" and "packages" in "operating-system" <civodul>karhunguixi: did you try using 'tor-service' in the 'services' field? <civodul>this creates a service that automatically starts Tor <karhunguixi>it says "error: source expression failed to match any pattern" when i try to reconfigure, (services tor-service %desktop-services) <civodul>it should read: (services (cons (tor-service) %desktop-services)) <karhunguixi>with this i get, "In procedure module-lookup: Unbound variable: tor-service" <civodul>you need to add (use-service-modules networking) as in the example above <civodul>rekado: could you look into that bio-blastxmlparser patch? ***davi_ is now known as Guest25818
<mark_weaver>civodul: any idea what's happening with build 689440 on hydra? it's been running for almost 24 hours, and the build log is completely empty. I've seen this many times, and in each case just killed the relevant process on hydra to free up the build slot, but this time I left it so you could take a look. <civodul>i see the nix-store process for that one is still running ***Mathnerd314_ is now known as Mathnerd314
<ngz>Hello. Apparently, there's a problem with csound and locales. The former refuses to build without error after a fresh guix pull && guix package -u. <ngz>IIRC it complains about glibc 2.22. <mark_weaver>civodul: the core-updates merge announcement omitted one important thing that the merge brings: substitutes for armhf <mark_weaver>although maybe that deserves a separate message anyway <toothbrush0>Yo! Refresh my memory, what was the incantation to figure out which packages depend a given package P? <ngz>mark_weaver: thank you. Looks like I'm on the "pretty bad" case. <mark_weaver>toothbrush0: well, there's "guix refresh -l <P>", but it's not comprehensive. it sometimes misses some things, and occasionally misses a *lot* of things <mark_weaver>it doesn't know about "implicit" inputs (i.e. inputs that are included by default), nor about packages that inherit from the package you modified. <toothbrush0>Ah. OK, that shouldn't be too serious, because the package i'm hacking (xapian) should only have a few deps. Let's see what it says. <mark_weaver>toothbrush0: yeah, for 'xapian' I'd expect it to work fine <toothbrush0>mark_weaver: it shows mu as a dependency (expected) but doesn't mention notmuch; i thought notmuch also used xapian... <mark_weaver>'patches' depends on 'python-notmuch' which depends on 'notmuch' <mark_weaver>for some reason, which I don't know, the author of "guix refresh -l" thought it would be a good idea to only show you the set of packages that, if rebuilt, would rebuild all the other packages that depend on package P. <mark_weaver>I guess maybe the idea was that those are the packages you need to rebuild to make sure that everything works, or something. <mark_weaver>but I confess that I've found this behavior to be undesirable <toothbrush0>i remember last time i tried to do a similar thing a few months ago it bit me <toothbrush0>although the details escape me in the mists of time. <mark_weaver>I think it's generally agreed that we'd like an improved "guix refresh -l" command, but it's not entirely obvious what approach to take. I'd like a fully precise version that didn't miss anything, but it might be *very* slow. <toothbrush0>mark_weaver: do you know what the rationale is behind adding the "Copyright © 20xx So And So" to the top of files, even for minor modifications? I'm just asking out of curiosity. <toothbrush0>because in Utopia it'd just do a transitive closure on some graph, really quickly. <mark_weaver>well, we don't normaly have the entire graph, and computing it takes a long time. <mark_weaver>regarding the copyright notices, I don't have a very strong argument, but here are some thoughts: <mark_weaver>if someone adds some code, it's good for them to add their name to the GPLv3+ copyright notice so that it's clear that they intended to release their code under the GPLv3+. <civodul>mark_weaver: re armhf substitutes, right! <mark_weaver>and, I think it's good for the list at the top of the file to reflect the actual set of authors, and not just some subset, both to give the new author recognition, but also, in the case that bad code is added, to not have the existing authors' reputation harmed by the appearance that they wrote the bad code. <mark_weaver>and finally, to me is seems to plainly be a matter of correctness to include the full set of copyright owners at the top of the file. <civodul>it's about copyright holders, not authors, although in practice it's usually the same <mark_weaver>and if you add a legally significant amount of code to a file, you *are* a copyright owner of the new file by default <Mathnerd314>why did /nix/store get renamed to /gnu/store? it seems like a deliberate incompatibility <mark_weaver>Mathnerd314: being incompatible was certainly not the intent of that change, but there's not much compatibility to be gained anyway. the actual packages in Guix are completely different from Nix, right down to the bootstrap packages. <mark_weaver>if you want to run Nix and Guix on the same system, you can have /gnu and /nix on the same system <mark_weaver>and remind people that this is the GNU system, especially since most people just seem to call it "Linux" <Mathnerd314>well, if people say they are running Linux, it expands to "running the Linux kernel", which is techinically correct <mark_weaver>in people's minds, they think of "Linux" as being the system as a whole, which is a mistake. <mark_weaver>anyway, we seem to have approximately 0 users who run both Nix and Guix packages side by side on the same system <mark_weaver>so it's not exactly a case we're motivated to optimize <mark_weaver>guix-daemon has already diverged quite a bit from nix-daemon, and it's likely that before long we'll replace it entirely with one written guile <Mathnerd314>"marketing reasons". I guess it is just a deliberate incompatibility <mark_weaver>and it seems to me rather hostile to accuse us of malicious intent without a shred of evidence. <mark_weaver>the systems are already completely different from the ground up, as in *zero* cross-references between nix and guix store items. <Mathnerd314>mark_weaver: I didn't say it was malicious, only that it was deliberate. i.e., a patch changing it back to /nix/store is unlikely to be accepted <mark_weaver>you said more than that it was "deliberate". you said it was "a deliberate incompatibility", which I interpret as suggesting that incompatibility was our reason for the change.