“LastPyMile: Identifying the Discrepancy between Sources and Packages”:https://2021.esec-fse.org/details/fse-2021-papers/61/LastPyMile-Identifying-the-Discrepancy-between-Sources-and-Packages

“Our empirical assessment of 2438 popular packages in PyPI with an analysis of around 10M lines of code shows severaldifferences in the wild […]”—certainly rings a bell to anyone who package #Python, Gems, etc. for #Guix.

📢 We’re preparing to rotate #GNU #Guix maintainership responsibilities!https://lists.gnu.org/archive/html/guix-devel/2021-08/msg00009.html 👈🏽

If you’re into #Guix, have a passion for #FreeSoftware, and would like to join as co-maintainer, don’t be shy and get in touch with the maintainer collective!

I did it: I packaged #PyTorch for #Guix! \o/https://git.savannah.gnu.org/cgit/guix.git/commit/?id=dd55ad7ff896a0a099c669ef0b420ae2bcdb4498

It’s a thankless, tedious effort, and it goes against the tide when “pip install torch” just does the job.

But I don’t see how we can build secure, transparent, and reproducible systems without doing that sort of things.

You might remember the JavaScript #packaging dystopia that @cwebber described:https://dustycloud.org/blog/javascript-packaging-dystopia/

You don’t use JavaScript? Worry not! The dystopia has been successfully ported to C++/Python:https://github.com/pytorch/pytorch/tree/master/third_party

@ekaitz_zarraga @janneke @reproducible_builds Bazel is interesting, with similarities with Nix/Guix in how it works.

Unfortuntately, it’s not “bootstrappable”: it cannot be built entirely from source (reason why it’s not in Guix).

Build system best practices: have CMake download the source half of your dependencies, with an option to skip that, in which case it’s up to the user to provide said source. The end result: it’s all bundled together.

https://github.com/google/XNNPACK/blob/master/CMakeLists.txt#L90

👍

#GNU + #Linux #distros

@ekaitz_zarraga A solution that’s been proposed before is a ‘--fhs’ flag to ‘guix environment --container’ that would set up /lib, /bin, and so on.

@ekaitz_zarraga I guess I must not be using “normal software” then. :-)

You mean things like running pre-built binaries that target an FHS distro? That can indeed be as cumbersome as risky, though ‘guix environment --container’ can help.

Just found what I had always been willing to experiment with: International #Scheme! 😏https://github.com/metaphorm/international-scheme/

There are keywords I’ve known for years that I wouldn’t quite know how to translate to my native language (‘unquote-splicing’ anyone?), which is telling…

@ekaitz_zarraga Nope, because streams live in a separate library, with their very own monomorphpic ‘stream-map’. :-)

The very first use of gexps (G-expressions) in #Guix packages, woohoo!https://issues.guix.gnu.org/49025#7

‘guix pack -f deb …’ now creates a .deb archive containing the given packages and their dependencies!https://issues.guix.gnu.org/49149 ☜

Not as nice as handcrafted #Debian packages but still a handy way to transfer #Guix packages to Debian-based distros.

Preparing for the Big Change:https://issues.guix.gnu.org/49169

The fun thing with such a project-wide change is the “meta-linguistic” work it implies to automate change, to devise new idioms, and so on. But it’s also a lot of pressure!

#GNU #Guix

@wilfredh “Almost all printers made in the last ten years should support IPP Everywhere” sounds optimistic to me.

Also, connected printers are roughly computers; IOW, we’re moving drivers from the user’s machine to (proprietary) software running in the printer.

(All that said, I’d love to be optimistic about printer setup. :-))

@alice Actually my $HOME is a mess too, so migrating “completely” will teach me discipline. :-)

So far, half of my dot files were symlinks to a Git repo, and the other half were just dropped there at some point.

I did my first ‘guix home reconfigure’! \o/

I used a minimal config to begin with. I had backed up my config files but I was glad to see ‘guix home’ was careful, created backups, and just behaved nicely.

#GuixHome #Guix

@ekaitz_zarraga @alice @wim_v12e Yes, and I think it’s important to bridge between these two worlds, like ‘guix pack -f docker’ does, for instance.

@alice There’s a growing understanding that “containers” are not helping much in way of reproducibility—Docker images are generally not reproducible to begin with. Growing awareness in both “reproducible science” circles and industry, as in https://lwn.net/Articles/786066/ . I’m full of hope! :-)

Upstream developer refuses to have their code packaged by a downstream distro, #NixOS in this case:https://news.ycombinator.com/item?id=27505277

This is the eternal debate on upstream/downstream bug report handling and QA, though in this case upstream goes to great lengths to make the distro’s life harder. :-/

"Reproducible data processing pipelines":https://guix.gnu.org/en/blog/2021/reproducible-data-processing-pipelines/ 👈

On how we built a #reproducible #BigBlueButton video post-processing pipeline using #Guix as a "deployment-aware makefile".

Think about it next time you feel like plumbing together a makefile and shell snippets!