For a long time this disconnect happened b/c distros that care about buildability/reproducibility were *disconnected* from new dev environments, which were done in userspace package managers.

But Guix comes with something like a universal virtualenv: "guix environment"! (cotd..)

Lots of people have good reason to run Debian. But now they can use Guix for dev, too!

And what is packageable for Guix tends to be packageable for Debian and vice versa.

Thus this could be a path out from one of the biggest problems user freedom faces: unbuildable software.

So: when are we going to see Guix in Fedora proper? :)

tl;dr: Ship every FOSS project with a "guix.scm" file.

These can be used to set up dev environments with
"guix environment -l guix.scm"

Projects built using Guix as a dev environment are free from the "binary-black-box-container-only" plague, healthier for user freedom!

@cwebber or a `shell.nix` file ;)

Maybe even build it as a reproducible flake.

@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.

@cwebber @schmittlauch That is an unfair representation of a project in which:

> 1696 out of 1699 (99.82%) paths in the minimal installation image are reproducible!

https://r13y.com/

Don't enable nixpkgs.config.allowUnfree when building your thing and you're doing pretty well already.

Some language packaging imports pulls down binary things from their respective package managers as-is, but in racket2nix I build everything from source, and in my Copious Free Time when that's actually upstreamed into nixpkgs, I'll look around to see if other imports can be made to do the same.

In practice most of the things in those repos does come from source, but you have a point that there is no guarantee, especially when it comes to npm and rubygems.

@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.

@cwebber @schmittlauch Right. Yes. You'd have to look at the derivation to see what the input is and how the input becomes output. But I expect the iso is mostly native code, which would be compiled from source.

When I talked to Nix people at guix@FOSDEM two years ago they were very interested in @janneke 's work on the seed, and had branches of nixpkgs in progress that would make use of it. I don't know if any of that made its way into main finally.

My point is that Nix as a community may not be as focused and unified on reproducibility and traceability as Guix is, but there are definitely people in the community that want it, and it's going in that direction more than it isn't.

@notclacke @janneke @schmittlauch Good!

@cwebber @schmittlauch

Interesting! Are binary blobs something guix.scm can safeguard against technically (as opposed to by convention/culture)?

@Sandra @schmittlauch It's convention/culture. Guix takes a firm stance for everything that goes into core.

@cwebber Thank you.

So

@schmittlauch a shell.nix file, sadly, is not as much an assurance of freedom from the “binary-black-box-container-only” plague, sadly

doesn’t necessarily make sense.

Not that I don’t love writing up some Scheme files.

@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

@ryanprior

Well if that is your expiernce I'm willing to give it a second look and try it out. Thanks for that!

@cwebber

@cwebber do you have any links to good examples I could steal of guix.scm files?

@fincham Haunt has a nice example https://git.dthompson.us/haunt.git/tree/guix.scm

@cwebber tyvm!

@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 ;)

@cwebber yeah. this is definitely a huge improvement over anything to do with containers.

@technomancy @cwebber I'm still in denial that containers exist

@technomancy
@cwebber
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.

@technomancy @cwebber
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.

@technomancy @cwebber I wouldn't want to make and distribute software in Fennel if I couldn't simply include Fennel as a nixpkgs or guix dependency. So that's one potential user. =)

@technomancy @cwebber Also, even if the build documentation is short, executable documentation beats exclusively-human-readable documentation every time!

I wouldn't want to install and compile fennel manually on my phone, but if it were one "nix run" away in Nix-on-Droid I would consider that near-zero friction.

@cwebber I'd welcome a guix.scm file upstream in #notmuch, if it wasn't going to bitrot too badly. Previous experience suggests that distro packagers prefer to maintain their own thing, so I don't know who would update it.

@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.

@cwebber You know, like Terminal Phase and other important applications.

@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...

@cwebber You don't have to do everything, you know?

@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 @therealraccoon ... any year now. Just want to get racket2nix upstream first, and I haven't touched it much in the last two years.

Someone on fedi (other than you) contacted me for some guidance re: guix import racket and I offered it, but I never heard from them again. :'(

@therealraccoon @cwebber > 2021-02-12: Soft Freeze (scheduled)

It's tight, but possible! Let's hope someone is chasing this.

@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)

@michel_slm @fedora Guix also has this with /gnu ;)

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 @fedora oh oof. I might need to get a packaging committee exeption then. I think the benefit outweighs the FHS violation.

@cwebber @fedora and... I'm finding none of the Guile bindings are packaged. Luckily they're mostly sensible, apart from ending up with *.go files file tells me are unstripped but strip doesn't know how to handle 😅

#guile
#packaging

@happybeing As @cwebber seems to have been busy, I'll offer the opinion that your post is entirely accurate.

@notclacke @cwebber thanks, I appreciate the feedback and good to know!