IRC channel logs
2013-09-19.log
back to list of logs
<mark_weaver>ls | perl -pe 's/^(................................)-(.*)/$2-$1/' | sort <ArneBab_>civodul: and I have a question right away :) <ArneBab_>If that were possible, developers could turn their guix packages into trivial packages (just inherit under new name) by cleanly specifying all their dependencies in their autoconf files. <ArneBab_>if they use autotools, they’ll have a configure.ac anyway. <civodul>ArneBab_: we could have a tool that scans configure.ac and produces a template package definition <civodul>but you wouldn't want to do that at run-time <civodul>it'd just be a helper for people writing package definitions <ArneBab_>why that? I guess that the hash for the sources has to be updated, but otherwise this sounds like duplicated information… <ArneBab_>civodul: couldn’t there be a function to infer information from the sources and then adjust only what’s needed? <civodul>ArneBab_: yes, there could be that thing <civodul>i'm just saying that you don't want it to be done at run time <civodul>that is, you don't want "guix package --list-available" to download 500 tarballs, unpack them, scan their .ac file, etc. <ArneBab_>to make that work, it would need a cache of sorts. <civodul>more generally: a distro cannot be fully dynamic, because there's an "editorial" process, and a "QA" process <ArneBab_>civodul: for Gentoo there are live-ebuilds. They are un-edited and marked as potentially harmful. But they are also very useful if you want to follow a project without having to forgo your distributions features for that. *ArneBab_ just realized, that this same argument holds for a question in #freenet, about freenet-based ebuilds. <civodul>jxself: did you see Karl's message about using info-gnu to promote free distros? <civodul>i sympathize with the idea, but at the same time, i'm somewhat jealous ;-) <civodul>i think we should be receiving more support from the FSF/Boston side of GNU <jxself>Yes, I saw it. Seems a good idea. Being a GNU package means Guix release announcements can already be sent there, yes? <jxself>But I agree with you, but it's RMS you must convince. <ArneBab_>civodul: Where do you think support is lacking? Guix was easy to find, it’s an official GNU package and users can get it easily from the GNU pages. <ArneBab_>civodul: the only thing which hurts a bit is the download speed from hydra <ArneBab_>which could be fixed by creating a push-hook which copies the snapshot to an official FTP site so it would get downloaded from there… <civodul>jxself: yes, i already send announcements there <civodul>ArneBab_: the problem actually lies in Guile's HTTP client... <jxself>arnebab_: Well, it would be nice if Guix could be talked about on gnu.org/distros for one. <ArneBab_>civodul: wget gets 0.5MB/s, so to some degree yes. But with FTP and wget I get up to 1.5MiB/s (and that was still rising) <ArneBab_>jxself: what’s the requirement for being included there? <jxself>There's a whole process for it, ending in the final sign on & approval by FSF staff & RMS <ArneBab_>“A free system distribution should be self-hosting. This means that you must be able to develop and build the system with tools that the system provides you. As a result, a free system distribution cannot include free software that can only be built by using nonfree software.” <jxself>Indeed, although being a GNU package you'd think that it could at least be talked about somewhere even if it's not actually included in the list of distros along with Trisquel, Parabola, etc. <ArneBab_>So it looks like the requirement for guix to get included there is to make it bootable. <jxself>Something like "did you know that the GNU Project's making a distro, or whatever? Want to help? <ArneBab_>Overselling is a danger, because it can cause people to be disappointed - the GNU Hurd was hit quite heavily by that. <jxself>People going "Ohhhhhh.... What's this Linux thing?" in 1992 and running over there probably hurt more. <ArneBab_>There are a host of reasons. The biggest one I see (nowadays), though, is that the promises were huge and couldn’t be kept on the short and medium term. <civodul>jxself: yeah something like "we're working on the distro, join us now" <civodul>the thing is gnu.org seems to be used for different purposes <ArneBab_>Around 2004 there was an additional wave of development on the Hurd. It died with “and now we’re going for R4!” ← never became real, but hurt a lot. <ArneBab_>civodul: I think saying “we’re working on our GNU distro” would alienate other distros, and while guix cannot (mostly) match those others in features, that could hurt more than it helps. <civodul>surely we want to help promote the free distros that are actually usable today <civodul>yet that doesn't mean we should dismiss GNU as a project <civodul>but yeah, let's do our part of the work, and then we'll see ;-) <ArneBab_>civodul: I would assume that guix should have it easy to get there as soon as (a) it can boot itself, and (b) it provides some special feature (currently features of the distros are “fedora”, “simple”, “audio/video”, “debian”, “audio”, “arch/simple”, “small enterprises+education”, “Gentoo+first”). <mark_weaver>I got my old YeeLoong mostly working again with my homegrown N32 system. <civodul>so you want to bootstrap Guix now? :-) <mark_weaver>Yes! Is there a reasonable way to create the Guix bootstrap tarballs from the system I have here, instead of cross compiling from x86_64? <mark_weaver>part of the reason I ask is that to remove Thompson viruses, we need a way to create the bootstrap binaries from a diverse set of possible methods, in such a way that we end up with the same result. <civodul>i need to finish that fixed point thing :-) <mark_weaver>one can gain confidence in the integrity of the bootstrap tarballs by allowing anyone to create them from a diverse set of possible paths. <civodul>well it is possible, but it turned out to be too difficult apparently <mark_weaver>fixed-point is not enough, because it can't get rid of a Thompson virus. <mark_weaver>I hope to post something to guix-devel about this soon. <mark_weaver>do you know about the work done by the Tor folks to create bit-identical deterministic builds of Tor browser? <civodul>grothoff kept telling me how important it is, at the GHM :-) <mark_weaver>I'm on it. it might take me a while, but this will be a priority for me. <civodul>and we're in a good position to do that <mark_weaver>indeed, I think that Nix and Guix are the only ones I know of that are really in a good position to do it, and many people will find that extremely compelling, especially now. <mark_weaver>civodul: what's the theory on how to compute the Nix hash of the bootstrap tarballs? Since GCC depends on itself, it seems to me that you can't achieve fixed-point, because every time you iterate, you get a new hash, or no? <mark_weaver>when we achieve bit-identical deterministic builds, I wonder if it makes sense to change the hash computation algorithm to be derived from the hashes of the built binaries that it depends on. <mark_weaver>something along those lines might allow us to achieve fixed-point of the hashes as well. <civodul>mark_weaver: in make-bootstrap.scm, we clear the residual /nix/store references <mark_weaver>Hmm, okay. I don't understand, but I'll take your word for it until I can look into it further :) <civodul>regarding reference clearing, see 'remove-store-references' in (guix build utils) <mark_weaver>civodul: where did you send the mail? to me personally, or to a list? <civodul>not there yet, we'll have to be patient ;-)