nixos / bundlers

The NixOS repository is obsolete!

The NixOS source tree has been merged into the Nixpkgs repository, where it now lives in the nixos subdirectory. Please file NixOS bugs in the Nixpkgs issue tracker using the nixos label.

bundlers's Issues

Standardised main program detection/way to override it

When bundling a derivation, there's no way to set the main program without modifying the derivation. This is an issue for derivations that have multiple binaries (e.g. nixpkgs#mesa-demos), or just any derivation that hasn't been configured. Plus, the main program detection logic being part of the bundler would likely result it in being inconsistent across bundlers.

I'm the maintainer of https://github.com/ralismark/nix-appimage and I already have gotten two issue related to main program detection, due to having to implement an ad-hoc solution:

• ralismark/nix-appimage#1
• ralismark/nix-appimage#2

I'm not sure if this is the right repo for this issue, so let me know if there's a better place for it.

Default bundler doesn't appear to work

$ nix bundle nixpkgs#hello 
error: flake 'github:NixOS/bundlers' does not provide attribute 'bundlers.x86_64-linux.default' or 'defaultBundler.x86_64-linux'

$ nix --version
nix (Nix) 2.9.0pre20220512_d354fc3

Flatpak?

It'd be very nice to be able to repackage graphical apps from nixpkgs into flathub.

Are there any plans or thoughts around this feature?

Incorrect versions in some bundler outputs

It looks like some bundlers are dropping the leading 0. for pre-1.0 versions.

Here it is for a project of mine – the toDEB and toRPM results both say the version is 1.0, while toDockerImage has the correct 0.1.0 version.

$ nix bundle --bundler github:NixOS/bundlers#toDEB
$ nix bundle --bundler github:NixOS/bundlers#toDockerImage
$ nix bundle --bundler github:NixOS/bundlers#toRPM
$ ls *bash-strict-mode*
bash-strict-mode-0.1.0.tar.gz

deb-single-bash-strict-mode/:
.  ..  bash-strict-mode_1.0_amd64.deb

rpm-single-bash-strict-mode/:
.  ..  bash-strict-mode-1.0-1.x86_64.rpm
$ 

nix bundle fails on macos

Describe the bug

When running e.g. nix bundle nixpkgs#hello on aarch64-darwin, it fails with the following error:

error: attribute 'aarch64-darwin' missing

       at /nix/store/1rc10ydlf4c2aphrg2z2dxaaikbggba0-source/flake.nix:12:20:

           11|       nix-bundle = { program, system }: let
           12|         nixpkgs' = nixpkgs.legacyPackages.${system};
             |                    ^
           13|         nix-bundle = import self { nixpkgs = nixpkgs'; };

Steps To Reproduce

1. Use a macOS system with Apple Silicon
2. Enable the nix-command and flakes experimental features
3. Run nix bundle nixpkgs#hello
4. See error

Expected behavior

I would expect a self-extracting zip with the hello command to be created.

nix-env --version output

nix-env (Nix) 2.13.6

Additional context

Trying something like

nix bundle nixpkgs#legacyPackages.x86_64-linux.hello results in the same error. I was originally trying to bundle murmur for linux (using a build server which is set up) from my macOS machine when I ran into this error.

RFC: Simple executable bundlers for macOS and Linux

For simple executables with dynamic libraries, I'd like to propose we offer a no-frills bundler that brings in nearly zero build-time dependencies. This would be very suitable for a CI job, for example.

Here's a project that attempts this: https://github.com/3noch/nix-bundle-exe

It depends on only bash and basic system tools. Unlike nix-bundle, this works on macOS and does not pull in a large Nix closure (arx is a rather hefty thing to build if its not already in your cache!).

The goal of this kind of bundler would not be to handle every possible edge case, but provide a very light-weight option to basic executable packages.

darwin bundlers do not work

x86_64-darwin and aarch64-darwin are listed as "supportedSystems", but the following error is returned:

bundlers/flake.nix

Line 15 in b11f6a6

supportedSystems = [ "x86_64-linux" "x86_64-darwin" "aarch64-linux" "aarch64-darwin" ];

$ nix bundle --bundler github:NixOS/bundlers nixpkgs#hello
error: Package ‘nix-user-chroot-2c52b5f’ in /nix/store/1rc10ydlf4c2aphrg2z2dxaaikbggba0-source/default.nix:49 is not supported on ‘x86_64-darwin’, refusing to evaluate.

       a) For `nixos-rebuild` you can set
         { nixpkgs.config.allowUnsupportedSystem = true; }
       in configuration.nix to override this.

       b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
         { allowUnsupportedSystem = true; }
       to ~/.config/nixpkgs/config.nix.
(use '--show-trace' to show detailed location information)

reading the upstream documentation for the tool this was based upon, it seems this is expected, just not documented here?

similarly, toDockerImage succeeds, but packs a mach-o binary into into a docker image: (nixpkgs#pkgsCross.musl64.hello works as expected)

$ nix bundle --bundler github:NixOS/bundlers#toDockerImage nixpkgs#hello --verbose
$ docker load < hello-2.12.1.tar.gz
78fcfc116447: Loading layer [==================================================>]  655.4kB/655.4kB
0d5cb48ad5d9: Loading layer [==================================================>]  1.085MB/1.085MB
88746dbbf806: Loading layer [==================================================>]  112.6kB/112.6kB
37ac77f97851: Loading layer [==================================================>]   2.14MB/2.14MB
c186ef70529c: Loading layer [==================================================>]  19.51MB/19.51MB
7b033f88ff6d: Loading layer [==================================================>]  4.833MB/4.833MB
881c3383a4c5: Loading layer [==================================================>]  1.208MB/1.208MB
770296159cae: Loading layer [==================================================>]  1.884MB/1.884MB
f40b9120a89c: Loading layer [==================================================>]  1.976MB/1.976MB
dee763386703: Loading layer [==================================================>]  153.6kB/153.6kB
a75b5721a144: Loading layer [==================================================>]  1.741MB/1.741MB
b6c1c599d6d2: Loading layer [==================================================>]  245.8kB/245.8kB
962272f441a3: Loading layer [==================================================>]  184.3kB/184.3kB
a2136da04750: Loading layer [==================================================>]  1.106MB/1.106MB
bad5e5760d0b: Loading layer [==================================================>]   42.4MB/42.4MB
384935350f01: Loading layer [==================================================>]  614.4kB/614.4kB
585453de14b2: Loading layer [==================================================>]  1.372MB/1.372MB
cf30a0d06dfa: Loading layer [==================================================>]  3.666MB/3.666MB
065694f29ee1: Loading layer [==================================================>]  81.92kB/81.92kB
1ab22814d143: Loading layer [==================================================>]  10.24kB/10.24kB
Loaded image: hello-2.12.1:latest
$ docker run hello-2.12.1:latest hello
exec /bin/hello: exec format error

this will be made moot if #2 is fixed.

nix bundle broken on busybox because of wrong tar flags

I'm trying to use a binary created by running

nix bundle nixpkgs#pkgsi686Linux.curl

on a minimal buildroot image (:sweat_smile:), but get this error:

tar: invalid option -- j
BusyBox v1.31.1 (2020-07-17 17:53:41 CDT) multi-call binary.

Usage: tar c|x|t [-hvokO] [-f TARFILE] [-C DIR] [-T FILE] [-X FILE] [--exclude PATTERN]... [FILE]...

And on the next invocation:

../run: line 1: ./nix/store/yigc12h43pdv2mn3cfb3k0xw3rsfdb8a-startup: not found

Reproduce guix pack -RR

Provide a flake "bundler" recovering the approach described in https://hpc.guix.info/blog/2020/05/faster-relocatable-packs-with-fakechroot/:

• fakechroot for filesystem access: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/aux-files/run-in-namespace.c,
• rtld audit for dynamic loading: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/aux-files/pack-audit.c.

Doing cross-compiled bundles?

Is it possible to bundle e.g. a .deb package for aarch64 system when compiling from an x86 system?

I'm testing with a very basic cmake c++ hello world, but it seems to me that, even if nix-build or nix build -f default.nix do produce aarch64 binaries (i checked with the file command), if i try doing nix bundle -f default.nix --bundler github:NixOS/bundlers#toDEB, i end up with a .deb file for amd64.

toDEB silently creates broken output for data packages

to replicate: nix bundle --bundler bundlers#toDEB nixpkgs#hunspellDicts.tok

this creates a broken symlink in bin/ and also doesn't include the actual data files.

Resulting binaries are not binary-reproducible

I've submitted a fix to the dependency: matthewbauer/nix-bundle#103 .

RPM reinstall leaves behind old /nix/store paths

When building a bundle (e.g. nix bundle --bundler github:NixOS/bundlers#toRPM nixpkgs-stable#hello), installing it and then reinstalling it with a new version (e.g. nix bundle --bundler github:NixOS/bundlers#toRPM nixpkgs-unstable#hello), the reinstall leaves behind old files (e.g. /nix/store/$HASH-zstd-$VERSION).

Note

I am reinstalling with sudo rpm -ivh --reinstall /path/to/prog.rpm.

Current workarounds

Before reinstalling an RPM built with nix bundle remove all files associated with it (sudo dnf remove $RPM_NAME), then install it.

Proposed solution

I have no idea how RPMs work, but I'd expect there to be a way to specify that when it reinstalls it should delete old files(?).