@schmittlauch a shell.nix file, sadly, is not as much an assurance of freedom from the "binary-black-box-container-only" plague, sadly, as Nix ships plenty of software from binaries only.
@cwebber Does guix manage to build Signal desktop from source?
I once tried to build it myself but failed; even Gentoo just unpacks the Debian package :(
Apart from that: Yes, but then these are usually proprietary and marked as such.
I'm a bit jealous at guix for having a smaller bootstrapping base though.
@notclacke @schmittlauch Just to be sure, this looks like reproducible as in, you get the same result running the same package. If I can tell correctly, the metric they're using would list the npm packages as "reproducible" if they both unpack the binaries the same way as their inputs, since this command doesn't seem to track whether or not the package *is* fully built from source?
But glad to see it.
@Sandra @schmittlauch Some conversation happened afterwards; the impression I have now is that Nix's core is not as much focused on "building from source", so some packages you get might actually just be binaries only... but other participants in this thread have shown that's improving after I made my original post. So there's a lot of room for optimism there.
@cwebber (Wow, so easy to miss things here on Fedi. Thank you for your patience re that.)
I got confused; your position would make sense if it was “What do I choose, NixOS vs Guix” but since you said in the context of Debian: “Ship every FOSS project with a “guix.scm” file” and that doesn’t necessarily do anything that a shell.nix file wouldn’t do.
Again, not that Scheme isn’t a nicer language, it is.
@cwebber I love the idea of Guix and I came really close to using it. Honestly though when I heard that none foss orijects would be strictly forbidden from inclusion from their package manager, however, I dropped the whole idea. I do recognize that 3rd parties can of course maintain their own repositories for that, but it concerns me as I doubt the tools will be there to make that easy and I highly doubt there will be well maintained repositories of that type.
I still love the idea of Guix though and maybe ill get lucky and someone will fork it who is a bit more liberal in those regards.
I also think its a good reason not to include a guix file, as it locks you into an ecosystem that is committed to certain limitations up front.
@freemo @cwebber hey there! Some info you might find helpful. The tools for independently hosting your own Guix packages and extensions get lots of love and there are already a number of well-maintained outside forks, including mine. Forking Guix is easy. I wrote recently about how its design intentionally frees users from dependence on upstream maintainers and provide an inclusive mechanism for all business models & licenses: https://www.ryanprior.com/posts/what-is-guix-really/#headline-10
@cwebber I've been thinking about this for Fennel, right now the build dependencies are: make, a c compiler, curl, tar, and xz. if we added a git submodule for Lua itself it would just be the first two. I wonder at that point whether there'd be much benefit to adding a guix build?
@technomancy Maybe it's less useful than in some others, but it's at least helpful because then your contributors don't have to figure any of that out, they just run a command that figures it out for them.
@cwebber but like... are there any potential contributors (or heck even potential users) that don't already have make, gcc, and curl? it's already one "make" command away.
@technomancy Quite possibly true for your case :)
Most people aren't working with that level of minimalism ;)
With packages being built in their isolated environments I don't have gcc or make in my user profile, and with packages linking directly to their dependencies I don't have curl installed either. Beyond providing a hacking environment a guix.scm file also makes it easy to build packages while hacking on them.
I updated and tweaked fennel in #Guix a bit and created a guix.scm file. I was able to use it to cross-build to a bunch of different architectures, although some of them only worked with luajit. Possibly something misconfigured with our lua packages. https://git.sr.ht/~efraim/fennel/tree/guix.scm/item/guix.scm `guix build -f guix.scm` for the host architecture, `guix build -f guix.scm --target=aarch64-linux-gnu` for aarch64.
@cwebber I'm not a developer, but I hope this makes it into Debian Bullseye because it might open up hassle-free access to newer software if needed.
@therealraccoon Hehe, yep. So I'm directly not in compliance. :)
I do consider it a red flag, and a red flag is hovering above my head.
I've been hopeful that someone else would do the Racket-packages-in-Guix work; maybe eventually I'll have to try to take over it...
@therealraccoon I'm also incapable of doing everything. ;)
It's part of why I'm hoping someone else will take it over. I've even offered to pay a few people to get it done... it nonetheless hasn't happened yet.
@cwebber I ran as #Guix on #Debian as Debian in Guix (debootstrap in chroot). And the latter is way more useful, for stuff which isn't (yet or ever will be) packaged for Guix. The former is kinda useful too, for when I need to run several versions or clean builds of something and can't or don't want to install Guix System on that machine.
Also Debian is terribly unstable. And packaging for it is a nightmare. While Guix often does things which I just can't comprehend, e.g. downloading something when I remove packages, or re-downloading it after `gc` (if that's needed somewhere, then it isn't a garbage and shouldn't have been collected). Guix's store also mysteriously grows over time beyond any reasonable limits, so that even `pull` and `upgrade` for all users and `system reconfigure` and `gc --delete-generatons` doesn't solve it.
@michel_slm @fedora I dunno what the process was personally! But you can probably figure it out by reading https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964284
@cwebber @fedora the file locations look sane - https://packages.debian.org/sid/amd64/guix/filelist
Nix basically uses /nix for their store (binary cache) and... Fedora hates that, and looks like they had a point since Nix ended up having to futz around because newer macOS made top-level directories not writeable even by root :p
(they had to have a weird mount point that redirects somewhere else)
It's not hardcoded, you can technically change it IIRC, but in practice that's what all builds are made for so you're left recompiling everything yourself.
Not sure what they did... a few options were mentioned in the past but I don't have time to look.
@cwebber very interesting Christopher. I posted about your thread on the Safe Dev forum below. If you have time, can you sanity check my interpretation of what this means? No worries if you are too busy.
Depending on what user means here. If it means sophisticated IT people, agreed.
If it means a 15 year old pupil, grandmas or normal users, we should tell them what Guix means before and teach Linux.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!