Question: sha256 = "09xz06g57wxbacic617pq9c0qb7nly42gif0raplldn5lw964xl2"; revert = true; }) <ins> (fetchpatch { name = "CVE-2021-4145.patch"; url = "https://gitlab.com/qemu-project/qemu/-/commit/66fed30c9cd11854fc878a4eceb507e915d7c9cd.patch"; sha256 = "10za2nag51y4fhc8z7fzw3dfhj37zx8rwg0xcmw5kzmb0gyvvz70"; }) </ins> ] ++ lib.optional nixosTestRunner ./force-uid0-on-9p.patch ++ lib.optionals stdenv.hostPlatform.isMusl [ ./sigrtminmax.patch

, CVSSv3=6.5 (nixos-21.11, nixos-unstable) A NULL pointer dereference issue was found in the block mirror layer of QEMU in versions prior to 6.2.0. The pointer is dereferenced in mirrorwaiton_conflicts() without ensuring that it's not NULL. A malicious unprivileged user within the guest could use this flaw to crash the QEMU process on the host when writing data reaches the threshold of mirroring node. Scanned versions: nixos-21.11: ; nixos-unstable: . Cc Cc
This is fixed on master since we have QEMU 6.2.0. It's not included in 6.1.1 though, so needs to be fixed on stable. Probably after since it'd be a merge conflict.


Question: # Note: fish completion script is not supported. $out/bin/rustup completions bash cargo > "$out/share/bash-completion/completions/cargo" $out/bin/rustup completions zsh cargo >  "$out/share/zsh/site-functions/_cargo" <ins> # add a wrapper script for ld.lld mkdir -p $out/nix-support substituteAll ${../../../../../pkgs/build-support/wrapper-common/utils.bash} $out/nix-support/utils.bash substituteAll ${../../../../../pkgs/build-support/bintools-wrapper/add-flags.sh} $out/nix-support/add-flags.sh substituteAll ${../../../../../pkgs/build-support/bintools-wrapper/add-hardening.sh} $out/nix-support/add-hardening.sh export prog='$PROG' export use_response_file_by_default=0 substituteAll ${../../../../../pkgs/build-support/bintools-wrapper/ld-wrapper.sh} $out/nix-support/ld-wrapper.sh chmod +x $out/nix-support/ld-wrapper.sh </ins> ''; <ins> env = lib.optionalAttrs (pname == "rustup") { inherit (stdenv.cc.bintools) expandResponseParams shell suffixSalt wrapperName coreutils_bin; hardening_unsupported_flags = ""; }; </ins> meta = with lib; { description = "The Rust toolchain installer"; homepage = "https://www.rustup.rs/";

Running a fresh fails, the core message being: Steps to reproduce the behavior: a rust project (or if you already have one) Either the rustup gcc/ld to be patched for NixOS use, or rust to use the system gcc/ld. Please run and paste the result.
Actually, it looks like this is an issue specifically appearing with ; so I'll try to pass the message upstream.
Very specifically, introducing the issue, when it has been decided to switch from the system linker to . I suppose the new binaries should also be elf-patched?
Patching those binaries will make them execute, but they also need the applied so that the binaries they build will also get patched automatically.


Question: let pname = "osu-lazer-bin"; <del> version = "2023.1026.0"; </del> <ins> version = "2023.1114.1"; </ins> name = "${pname}-${version}"; osu-lazer-bin-src = { aarch64-darwin = { url = "https://github.com/ppy/osu/releases/download/${version}/osu.app.Apple.Silicon.zip"; <del> sha256 = "sha256-6IaN189cV/ORP77zrjdcCPwPzNR/W6JmrZXVasCx8MQ="; </del> <ins> sha256 = "sha256-MQkHbodSkAQQpjaBP+Q35afcCrgcie6UoUldc+vjRA0="; </ins> }; x86_64-darwin = { url = "https://github.com/ppy/osu/releases/download/${version}/osu.app.Intel.zip"; <del> sha256 = "sha256-XrlajKT3GLjfj800mULj9iwkF9Bvx9Rlz56K6welq2U="; </del> <ins> sha256 = "sha256-40ylXbn9jV9v+ve1hFwhT5/jhzNfWHjL2WIplVUD2qk="; </ins> }; x86_64-linux = { url = "https://github.com/ppy/osu/releases/download/${version}/osu.AppImage"; <del> sha256 = "sha256-yr7PtBUBE0tB0giAE8aQCNJvxS/tMzlLWpJ3NyosQZk="; </del> <ins> sha256 = "sha256-Q2z2Js0Zc9nvyQNxzLuuV7TcwiNIRo+RMRER6ZYgh74="; </ins> }; }.${stdenv.system} or (throw "${pname}-${version}: ${stdenv.system} is unsupported.");

Package name: osu-lazer-bin Latest released version: <!-- Search your package here: --- Current version on the unstable channel: 2023.1026.0 Current version on the stable/release channel: 2023.511.0 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers Note for maintainers: Please tag this issue in your PR.


Question: ./services/misc/tautulli.nix ./services/misc/tiddlywiki.nix ./services/misc/tp-auto-kbbl.nix <ins> ./services/misc/turn-rs.nix </ins> ./services/misc/tuxclocker.nix ./services/misc/transfer-sh.nix ./services/misc/tzupdate.nix

Project description A pure rust implemented turn server. <!-- Describe the project a little: --Metadata homepage URL: source URL: license: gpl-3.0 platforms: linux, windows Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: runHook postInstall ''; <ins> fixupPhase = '' runHook preFixup wrapProgramShell $out/share/spotify/spotify  ''${gappsWrapperArgs[@]}  ${lib.optionalString (deviceScaleFactor != null) '' --add-flags "--force-device-scale-factor=${toString deviceScaleFactor}"  ''}  --prefix LD_LIBRARY_PATH : "$librarypath"  --prefix PATH : "${gnome.zenity}/bin"  --add-flags "''${NIXOS_OZONE_WL:+''${WAYLAND_DISPLAY:+--enable-features=UseOzonePlatform --ozone-platform=wayland}}" runHook postFixup ''; </ins> meta = meta // { maintainers = with lib.maintainers; [ eelco ftrvxmtrx sheenobu timokau ma27 ]; };

When adding a local directory to spotify client, it always fails due to missing gsettings schema(s) and spotify crashes. This issue is the same as the one from 2021 Works as expected on arch based distros indicating that this an issue with nixpkgs Steps to reproduce the behavior: spotify Settings on Show Local Files ADD A SOURCE button Open a file chooser to select which directory to be . <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I can't actually reproduce the issue, but I do see some inherent packaging issues that I attempted to address. Can you test the linked PR?
I also cannot reproduce the issue. However, I have never actually had local files appear after I have their directories (without crashing).
Yes your PR solves the issue!!! Thanks a lot for the fast reply :) I would really like to learn more about packaging programs for nixpkgs so I can contribute more myself. Do you have any recommendations on how to learn the different options for mkDerivation, the different phases, wrapping programs and libraries, etc.? I feel like the documentation is basically non-existend. If anything comes to mind (including workshops, etc.) feel free to just send me an email (this issue is probably the wrong place to discuss this)


Question: inherit pname; version = "2.0.1"; <del> outputs = [ "bin" "out" "dev" "doc" "man" ]; </del> <ins> outputs = [ "out" "lib" "dev" "doc" "man" ]; </ins> src = fetchFromGitLab { domain = "salsa.debian.org";

uses two actions and do get necessary authorization via . but these actions are not properly registed, leading to error: (It can be verified that these actions don't exist by using ) This breaks and . I tried both pcsclite 1.9.5 and 2.0.1 ending up with the same error. Steps to reproduce the behavior: and in , configure your smartcard (yubikey) to use yubikey error There actions are registered correctly and usable. Please run and paste the result. I'm using flakes (no channels). Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
correct description of your effect, i am not able to use my yubikey with gpg.
This can be solved by
this works, thanks! but this is really unintuitive, given that is already adding the package to : I am leaving this open as I believe a proper fix should be provided in the module itself.
Same issue here. It was working approx. last Dec. I don't have a specific commit hash. Adding to works for me.
Looks like a regression in () - is implying to me that polkit actions get included in the output, however: isn't included, which explains why adding to fixes the issue. Solution ideas: Add to . Not sure about this one? seems to also contain some libraries that probably don't need to be installed. Install polkit actions to instead of . IMO this one makes the most sense, especially as it seems to have been the previous behaviour before this change.
I was bitten by this when attempting to update over the weekend as well. In my case it prevented login because I use smartcards for user login which made debugging difficult due to the number of reboots required. I tend to agree with that going back to having the polkit actions file in the output instead of makes the most sense. That will mean that of the pcsc module will again result in the polkit action file being to the system configuration.
Cc: ()
I also think the location should be fine, the files are also there.
I ran into this issue when I couldn't access my yubikey anymore via pcsc for commits. The above solution worked for me.


Question: inherit pname; version = "2.0.1"; <del> outputs = [ "bin" "out" "dev" "doc" "man" ]; </del> <ins> outputs = [ "out" "lib" "dev" "doc" "man" ]; </ins> src = fetchFromGitLab { domain = "salsa.debian.org";

I'm going to add some comments for SEO so this is easier to find
I think you have found the right culprit that caused the issue, but I suppose the issue has more to do with the itself, where it only includes if . This has been rectified in from what it seems. For now the proper solution seems to enabling polkit with .
I think that makes more sense based on the existing file structure but maybe we just switch bin to out, so it is the default and move the libs to lib instead of being in out.
I've created to make the outputs a lot more expected by moving the udev file and the systemd service to the out output and the libraries to the lib output: I didn't test it yet, so it is still in draft. If someone could verify that it doesn't break security keys again, that would be great and then please undraft it, otherwise I do it in the evening.
I do not think I can fully test this due to the amount of rebuilds, so please chime in for reviews and find the one mistake I might have done (which I hope I didn't)
Tried to build but it fails on my machine:
I've xdist to dulwich here . Let me see if we can just disable some tests as a speed up from 66s to 9s is quite good.
This should be a lot better with . I did a lot of rebuilds locally on a low and high core machine and didn't encounter any failures anymore.
This was fixed in , works fine for me.


Question: # Relative paths. "BINDIR=/bin" "PERLDIR=/share/perl5" <del> "MODSDIR=/lib/" </del> <ins> "MODSDIR=/nonexistent" # AMC will test for that dir before # defaulting to the "portable" strategy, so this test *must* fail. </ins> "TEXDIR=/tex/latex/" # what texlive.combine expects "TEXDOCDIR=/share/doc/texmf/" # TODO where to put this? "MAN1DIR=/share/man/man1"

The auto-multiple-choice program does not start, on NixOS 22.11 : Steps to reproduce the behavior: auto-multiple-choice auto-multiple-choice that it's not really working A clear and concise description of what you expected to happen.
I'm trying to reproduce, without success so far. Did you install AMC from , or through nix-env/nix-shell? (I'm rebuilding my system without the global AMC to test those cases, but it triggered a full Emacs recompilation which will take some time)
I installed it using nix-env. I'll try with the systemPackage option later today. I'm using wayland with sway.
I don't think that's the issue there (also I have the very same setup, on unstable though). This message means that the program can't find the perl source module of its gui component, which indicates an installation/path issue.
I really can't reproduce, sorry. Please let me know how things go with . Does exist?
Yup, it exists : After switching with the system version, I get the same error. After updating the channels () and rebuilding () I still get the same error.
Is there a /lib/ directory at your FS root?
Yup, there is, it contains a subdirectory (modules) which is empty. Deleting it makes auto-multiple-choice work as expected.
Ok, I believe that's the root issue, but I'm not sure how to fix this. If it's fully empty besides subdirs, you should just delete it.
Does that mean that auto-multiple-choice is also broken on non nixos installations ?
No, because on those, the Perl modules AMC needs are on the global , or , or whatever. The NixOS package, OTOH, is a self-contained, so-called "portable" build where everything (libs, executables, doc…) lives in a single directory. Your issue comes from the fact that AMC tries to detect such a portable build by first looking for a global , then defaulting to dir iff the former doesn't exist: I think I can solve this by just changing the default lib dir, please don't close the issue.
will fix this.
reverted the "fix" to that issue, because it broke everything else (my fault). For the time being you need to make sure there's no on your system for AMC to work.
No problem, good luck with that !


Question: <ins> diff --git i/widgets/settings/settingsdialog.cpp w/widgets/settings/settingsdialog.cpp index 4deff1f..16845b5 100644 --- i/widgets/settings/settingsdialog.cpp +++ w/widgets/settings/settingsdialog.cpp @@ -802,7 +802,7 @@ bool setAutostartEnabled(bool enabled) desktopFile.write("[Desktop Entry]n" "Name=" APP_NAME "n" "Exec=""); -        desktopFile.write(qEnvironmentVariable("APPIMAGE", QCoreApplication::applicationFilePath()).toUtf8().data()); +        desktopFile.write(qEnvironmentVariable("APPIMAGE", EXEC_NIX_PATH).toUtf8().data()); desktopFile.write("" qt-widgets-gui --single-instancenComment=" APP_DESCRIPTION "n" "Icon=" PROJECT_NAME "n" "Type=Applicationn" </ins>

The tray icon appears, but he according window shows: Steps to reproduce the behavior: syncthingtray (through home.packages in home-manager in my case) on the tray icon The proper GUI with shiny buttons and stuff
Didn't have time to do actual digging yet, but seems like it's actually a matter of launching it / nixos weirdness rather then the package itself at fault: if I run manually from the terminal it actually works as expected. if I have it launched by plasma's autostart it sits in the tray failed with the message above. if I have it launched as user systemd service through the according home-manager option, it fails to launch because it can not find the tray altogether (probably launched before plasma is ready). So the question is, why is it different when launched from autostart... The message shows the right path in after all... (Disclaimer: total nixos noob here. Maybe it's obvious for a more experienced user...)
I'd investigate this by comparing the environment of your terminal to the environment of autostart's file - try to override the line to something like:
Oh I see what's the problem.. the file generates is pointing in to the unwrapped executable.. This needs to be patched locally in nixpkgs!
That would explain it. What do you mean by "patched locally"?
I mean this:
you are invited to test the fix for your issue in .
I'm really sorry it took me forever to actually test it - had issues with the system I use it on. Anyway, the desktop file wasn't my issue either - I didn't realize the thing in tray is not the autostarted desktop file / syncthingtray process, but the plasmoid which is apparently a completely different beast running within the plasmashell process rather then a separate one. It appears automatically in tray unless I use syncthingtray with and can not be removed from there through plasma controls. Launching the process actually creates a second icon, which behaves properly.
I'm not sure I followed.. Does it work if you set ? has landed in so the environment issue fixed there should affect you somehow I think. Feel free to reopen the issue.
No, the plasmoid is what fails. The plasmoid seems to be launched in a different way, independent from the desktop file.


Question: <ins> diff --git i/widgets/settings/settingsdialog.cpp w/widgets/settings/settingsdialog.cpp index 4deff1f..16845b5 100644 --- i/widgets/settings/settingsdialog.cpp +++ w/widgets/settings/settingsdialog.cpp @@ -802,7 +802,7 @@ bool setAutostartEnabled(bool enabled) desktopFile.write("[Desktop Entry]n" "Name=" APP_NAME "n" "Exec=""); -        desktopFile.write(qEnvironmentVariable("APPIMAGE", QCoreApplication::applicationFilePath()).toUtf8().data()); +        desktopFile.write(qEnvironmentVariable("APPIMAGE", EXEC_NIX_PATH).toUtf8().data()); desktopFile.write("" qt-widgets-gui --single-instancenComment=" APP_DESCRIPTION "n" "Icon=" PROJECT_NAME "n" "Type=Applicationn" </ins>

Whenever I include syncthingtray in the home manager with (which is default), the plasmoid appears in tray on next login - but no process exists. It seems to run as part of plasmashell instead and is not in the autostart at this point. Autostart seems to be a different way to start it as an alternative to the plasmoid stuff, the plasmoid is however what is running by default with the current syncthingtray package. Doesn't seem like I have permissions to reopen it in place.
According to the initially reported issue description it is indeed the Plasmoid that's causing problems here. On Plasma the Plasmoid is supposedly the preferred UI. So the goal should be to fix it. If you nevertheless want to use the executable instead you can do that of course as well. Then you can simply disable the Plasmoid by removing it from all panels/screen as usual. If the Plasmoid is shown as part of Plasma's system tray Plasmoid, you can disable it via the settings of the system tray Plasmoid. To fix the actual issue of the Plasmoid: Supposedly a file is missing in the package. The full list of files to be contained by the package should currently look like this: Of course the exact paths depend on your install prefix and paths of your Qt and Plasma installation. Maybe something is not missing but installed to the wrong directory. Did the Plasmoid (not the stand-alone executable) ever work with your packaging? If it did then I'd try to compare the last working package with the first bad.
Note that an override for the executable path (via a CMake option that then sets a define which is used if present like in your patch) could be upstreamed.
I was thinking about it just today, since usually you'd want it to be the permanent symlink and not the path (to the wrapped executable) that might be removed after a garbage collection.. Let's continue this discussion in
What is the status on this?


Question: <ins> diff --git i/widgets/settings/settingsdialog.cpp w/widgets/settings/settingsdialog.cpp index 4deff1f..16845b5 100644 --- i/widgets/settings/settingsdialog.cpp +++ w/widgets/settings/settingsdialog.cpp @@ -802,7 +802,7 @@ bool setAutostartEnabled(bool enabled) desktopFile.write("[Desktop Entry]n" "Name=" APP_NAME "n" "Exec=""); -        desktopFile.write(qEnvironmentVariable("APPIMAGE", QCoreApplication::applicationFilePath()).toUtf8().data()); +        desktopFile.write(qEnvironmentVariable("APPIMAGE", EXEC_NIX_PATH).toUtf8().data()); desktopFile.write("" qt-widgets-gui --single-instancenComment=" APP_DESCRIPTION "n" "Icon=" PROJECT_NAME "n" "Type=Applicationn" </ins>

I'm still encountering this issue on my machine
I'm not sure what more could I do here.. I will report here after comment that there are no much differences between the files installed by our package and what should be installed: <details<summary<codediff our- upstream-</code</summary</details
Is this a problem affecting all NixOS users or is it just reproducible in the setup of a few people. For debugging it might help to start with the env variable set.
I'd only compare the packaging with how other Plasmoids for NixOS are packaged. Maybe there actually needs to be a difference compared to my "upstream packaging".
I don't experience this issue, here on Gnome, naturally. Other packages in Nixpkgs, like , and also put files in , according to .
Yes, you would obviously need to start a Plasma session to reproduce the issue. (Or just launch or in another session. I suppose will work in any X11 session and in any X11 or Wayland session.) Maybe it makes more sense if the users that actually use Plasma would do further debugging on their side, though. By the way, how do you use Syncthing Tray under GNOME? Last time I've checked whether it works there was no general support for system tray icons at all and issues like suggest that GNOME has no generic system tray icon support at all right now. If there are any workarounds those might be worth documenting under and could be extended with a remark to the workaround section.
As a note, I'm a pretty new NixOS user, but I switched yesterday to the unstable channel, and syncthingtray is working completely fine now.
Using .
Thanks for the report. I wonder what was the problem... I'll close this in the meantime, unless someone from the stable channels will give a detailed bug report.


Question: <ins> # pkgs.dockerTools {#sec-pkgs-dockerTools} `pkgs.dockerTools` is a set of functions for creating and manipulating Docker images according to the [ Docker Image Specification v1.2.0 ](https://github.com/moby/moby/blob/master/image/spec/v1.2.md#docker-image-specification-v120). Docker itself is not used to perform any of the operations done by these functions. ## buildImage {#ssec-pkgs-dockerTools-buildImage} This function is analogous to the `docker build` command, in that it can be used to build a Docker-compatible repository tarball containing a single image with one or multiple layers. As such, the result is suitable for being loaded in Docker with `docker load`. The parameters of `buildImage` with relative example values are described below: []{#ex-dockerTools-buildImage} []{#ex-dockerTools-buildImage-runAsRoot} ```nix buildImage { name = "redis"; tag = "latest"; fromImage = someBaseImage; fromImageName = null; fromImageTag = "latest"; contents = pkgs.redis; runAsRoot = '' #!${pkgs.runtimeShell} mkdir -p /data ''; config = { Cmd = [ "/bin/redis-server" ]; WorkingDir = "/data"; Volumes = { "/data" = { }; }; }; } ``` The above example will build a Docker image `redis/latest` from the given base image. Loading and running this image in Docker results in `redis-server` being started automatically. - `name` specifies the name of the resulting image. This is the only required argument for `buildImage`. - `tag` specifies the tag of the resulting image. By default it's `null`, which indicates that the nix output hash will be used as tag. - `fromImage` is the repository tarball containing the base image. It must be a valid Docker image, such as exported by `docker save`. By default it's `null`, which can be seen as equivalent to `FROM scratch` of a `Dockerfile`. - `fromImageName` can be used to further specify the base image within the repository, in case it contains multiple images. By default it's `null`, in which case `buildImage` will peek the first image available in the repository. - `fromImageTag` can be used to further specify the tag of the base image within the repository, in case an image contains multiple tags. By default it's `null`, in which case `buildImage` will peek the first tag available for the base image. - `contents` is a derivation that will be copied in the new layer of the resulting image. This can be similarly seen as `ADD contents/ /` in a `Dockerfile`. By default it's `null`. - `runAsRoot` is a bash script that will run as root in an environment that overlays the existing layers of the base image with the new resulting layer, including the previously copied `contents` derivation. This can be similarly seen as `RUN ...` in a `Dockerfile`. > **_NOTE:_** Using this parameter requires the `kvm` device to be available. - `config` is used to specify the configuration of the containers that will be started off the built image in Docker. The available options are listed in the [ Docker Image Specification v1.2.0 ](https://github.com/moby/moby/blob/master/image/spec/v1.2.md#image-json-field-descriptions). After the new layer has been created, its closure (to which `contents`, `config` and `runAsRoot` contribute) will be copied in the layer itself. Only new dependencies that are not already in the existing layers will be copied. At the end of the process, only one new single layer will be produced and added to the resulting image. The resulting repository will only list the single image `image/tag`. In the case of [the `buildImage` example](#ex-dockerTools-buildImage) it would be `redis/latest`. It is possible to inspect the arguments with which an image was built using its `buildArgs` attribute. > **_NOTE:_** If you see errors similar to `getProtocolByName: does not exist (no such protocol name: tcp)` you may need to add `pkgs.iana-etc` to `contents`. > **_NOTE:_** If you see errors similar to `Error_Protocol ("certificate has unknown CA",True,UnknownCa)` you may need to add `pkgs.cacert` to `contents`. By default `buildImage` will use a static date of one second past the UNIX Epoch. This allows `buildImage` to produce binary reproducible images. When listing images with `docker images`, the newly created images will be listed like this: ```ShellSession $ docker images REPOSITORY   TAG      IMAGE ID       CREATED        SIZE hello        latest   08c791c7846e   48 years ago   25.2MB ``` You can break binary reproducibility but have a sorted, meaningful `CREATED` column by setting `created` to `now`. ```nix pkgs.dockerTools.buildImage { name = "hello"; tag = "latest"; created = "now"; contents = pkgs.hello; config.Cmd = [ "/bin/hello" ]; } ``` and now the Docker CLI will display a reasonable date and sort the images as expected: ```ShellSession $ docker images REPOSITORY   TAG      IMAGE ID       CREATED              SIZE hello        latest   de2bf4786de6   About a minute ago   25.2MB ``` however, the produced images will not be binary reproducible. ## buildLayeredImage {#ssec-pkgs-dockerTools-buildLayeredImage} Create a Docker image with many of the store paths being on their own layer to improve sharing between images. The image is realized into the Nix store as a gzipped tarball. Depending on the intended usage, many users might prefer to use `streamLayeredImage` instead, which this function uses internally. `name` : The name of the resulting image. `tag` _optional_ : Tag of the generated image. *Default:* the output path's hash `contents` _optional_ : Top level paths in the container. Either a single derivation, or a list of derivations. *Default:* `[]` `config` _optional_ : Run-time configuration of the container. A full list of the options are available at in the [ Docker Image Specification v1.2.0 ](https://github.com/moby/moby/blob/master/image/spec/v1.2.md#image-json-field-descriptions). *Default:* `{}` `created` _optional_ : Date and time the layers were created. Follows the same `now` exception supported by `buildImage`. *Default:* `1970-01-01T00:00:01Z` `maxLayers` _optional_ : Maximum number of layers to create. *Default:* `100` *Maximum:* `125` `extraCommands` _optional_ : Shell commands to run while building the final layer, without access to most of the layer contents. Changes to this layer are "on top" of all the other layers, so can create additional directories and files. ### Behavior of `contents` in the final image {#dockerTools-buildLayeredImage-arg-contents} Each path directly listed in `contents` will have a symlink in the root of the image. For example: ```nix pkgs.dockerTools.buildLayeredImage { name = "hello"; contents = [ pkgs.hello ]; } ``` will create symlinks for all the paths in the `hello` package: ```ShellSession /bin/hello -> /nix/store/h1zb1padqbbb7jicsvkmrym3r6snphxg-hello-2.10/bin/hello /share/info/hello.info -> /nix/store/h1zb1padqbbb7jicsvkmrym3r6snphxg-hello-2.10/share/info/hello.info /share/locale/bg/LC_MESSAGES/hello.mo -> /nix/store/h1zb1padqbbb7jicsvkmrym3r6snphxg-hello-2.10/share/locale/bg/LC_MESSAGES/hello.mo ``` ### Automatic inclusion of `config` references {#dockerTools-buildLayeredImage-arg-config} The closure of `config` is automatically included in the closure of the final image. This allows you to make very simple Docker images with very little code. This container will start up and run `hello`: ```nix pkgs.dockerTools.buildLayeredImage { name = "hello"; config.Cmd = [ "${pkgs.hello}/bin/hello" ]; } ``` ### Adjusting `maxLayers` {#dockerTools-buildLayeredImage-arg-maxLayers} Increasing the `maxLayers` increases the number of layers which have a chance to be shared between different images. Modern Docker installations support up to 128 layers, however older versions support as few as 42. If the produced image will not be extended by other Docker builds, it is safe to set `maxLayers` to `128`. However it will be impossible to extend the image further. The first (`maxLayers-2`) most "popular" paths will have their own individual layers, then layer #`maxLayers-1` will contain all the remaining "unpopular" paths, and finally layer #`maxLayers` will contain the Image configuration. Docker's Layers are not inherently ordered, they are content-addressable and are not explicitly layered until they are composed in to an Image. ## streamLayeredImage {#ssec-pkgs-dockerTools-streamLayeredImage} Builds a script which, when run, will stream an uncompressed tarball of a Docker image to stdout. The arguments to this function are as for `buildLayeredImage`. This method of constructing an image does not realize the image into the Nix store, so it saves on IO and disk/cache space, particularly with large images. The image produced by running the output script can be piped directly into `docker load`, to load it into the local docker daemon: ```ShellSession $(nix-build) | docker load ``` Alternatively, the image be piped via `gzip` into `skopeo`, e.g. to copy it into a registry: ```ShellSession $(nix-build) | gzip --fast | skopeo copy docker-archive:/dev/stdin docker://some_docker_registry/myimage:tag ``` ## pullImage {#ssec-pkgs-dockerTools-fetchFromRegistry} This function is analogous to the `docker pull` command, in that it can be used to pull a Docker image from a Docker registry. By default [Docker Hub](https://hub.docker.com/) is used to pull images. Its parameters are described in the example below: ```nix pullImage { imageName = "nixos/nix"; imageDigest = "sha256:20d9485b25ecfd89204e843a962c1bd70e9cc6858d65d7f5fadc340246e2116b"; finalImageName = "nix"; finalImageTag = "1.11"; sha256 = "0mqjy3zq2v6rrhizgb9nvhczl87lcfphq9601wcprdika2jz7qh8"; os = "linux"; arch = "x86_64"; } ``` - `imageName` specifies the name of the image to be downloaded, which can also include the registry namespace (e.g. `nixos`). This argument is required. - `imageDigest` specifies the digest of the image to be downloaded. This argument is required. - `finalImageName`, if specified, this is the name of the image to be created. Note it is never used to fetch the image since we prefer to rely on the immutable digest ID. By default it's equal to `imageName`. - `finalImageTag`, if specified, this is the tag of the image to be created. Note it is never used to fetch the image since we prefer to rely on the immutable digest ID. By default it's `latest`. - `sha256` is the checksum of the whole fetched image. This argument is required. - `os`, if specified, is the operating system of the fetched image. By default it's `linux`. - `arch`, if specified, is the cpu architecture of the fetched image. By default it's `x86_64`. `nix-prefetch-docker` command can be used to get required image parameters: ```ShellSession $ nix run nixpkgs.nix-prefetch-docker -c nix-prefetch-docker --image-name mysql --image-tag 5 ``` Since a given `imageName` may transparently refer to a manifest list of images which support multiple architectures and/or operating systems, you can supply the `--os` and `--arch` arguments to specify exactly which image you want. By default it will match the OS and architecture of the host the command is run on. ```ShellSession $ nix-prefetch-docker --image-name mysql --image-tag 5 --arch x86_64 --os linux ``` Desired image name and tag can be set using `--final-image-name` and `--final-image-tag` arguments: ```ShellSession $ nix-prefetch-docker --image-name mysql --image-tag 5 --final-image-name eu.gcr.io/my-project/mysql --final-image-tag prod ``` ## exportImage {#ssec-pkgs-dockerTools-exportImage} This function is analogous to the `docker export` command, in that it can be used to flatten a Docker image that contains multiple layers. It is in fact the result of the merge of all the layers of the image. As such, the result is suitable for being imported in Docker with `docker import`. > **_NOTE:_** Using this function requires the `kvm` device to be available. The parameters of `exportImage` are the following: ```nix exportImage { fromImage = someLayeredImage; fromImageName = null; fromImageTag = null; name = someLayeredImage.name; } ``` The parameters relative to the base image have the same synopsis as described in [buildImage](#ssec-pkgs-dockerTools-buildImage), except that `fromImage` is the only required argument in this case. The `name` argument is the name of the derivation output, which defaults to `fromImage.name`. ## shadowSetup {#ssec-pkgs-dockerTools-shadowSetup} This constant string is a helper for setting up the base files for managing users and groups, only if such files don't exist already. It is suitable for being used in a [`buildImage` `runAsRoot`](#ex-dockerTools-buildImage-runAsRoot) script for cases like in the example below: ```nix buildImage { name = "shadow-basic"; runAsRoot = '' #!${pkgs.runtimeShell} ${shadowSetup} groupadd -r redis useradd -r -g redis redis mkdir /data chown redis:redis /data ''; } ``` Creating base files like `/etc/passwd` or `/etc/login.defs` is necessary for shadow-utils to manipulate users and groups. </ins>

This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.
Hi I'd like to work in this issue. First one with documentation so I will probably need to understand a few things first.
Thanks, let us know if you need help!
Hi thanks for picking this up. Are you still working on this? If you're stuck, you could create a draft PR so someone can help, or if you've changed your mind that's also ok.
Hi Sorry for late reply. I worked a little bit, on and off during the holidays, I do not finished yet, I had some problems during the build of the documentation, but from what I read (pandoc output) I made some mistakes during the file conversion. For now, I didn't commit, It's on my personal computer only. As the week is a little difficult, I'll see if I finish it at the weekend. (Maybe I should have asked for this issue just now, just see 14 days ago and I was like "What ?! That was 2 weeks ago ?!" LOL) Thanks for asking!
Hi I followed your suggestion to create a draft PR, at the moment I'm stuck in two things, the first is how to create a note and the second reference errors during the build of the documentation. For the first, pandoc created notes with the following formats: , in this case I should use the default way to create notes in markdown (using ) or wrap this in docbook way? If I remove the references that generate the error below, I can verify that using the markdown format, this note is styled differently from the rest of the documentation. And for the build errors, here is log: For this I tried per but build fails with same error. Any help is appreciated.


Question: "-X gitlab.com/olaris/olaris-server/helpers.Version=${version}" ]; <del> vendorHash = "sha256-xWywDgw0LzJhPtVK0aGgT0TTanejJ39ZmGc50A3d68U="; </del> <ins> vendorHash = "sha256-bw8zvDGFBci9bELsxAD0otpNocBnO8aAcgyohLZ3Mv0="; </ins> <del> nativeBuildInputs = [ installShellFiles ]; </del> <ins> nativeBuildInputs = [ installShellFiles makeWrapper ]; </ins> # integration tests require network access doCheck = false;

Olaris server requires ffmpeg to be available and raises an error when it can't be found: Steps to reproduce the behavior: olaris-server a library. The software runs correctly. There are two main ways to fix this: the software to use the full path to the ffmpeg dependency (ideally upstream). the program to add ffmpeg to its path. Please run and paste the result.
In fact it looks like it needs a custom image as it passes arguments that only exist on the modified version.
Actually it looks like the fork is no longer required: But this doesn't seem to be released yet. But probably is still a better option than packaging the custom ffmpeg.
yep, this looks like an easy fix EDIT: I was keen to try building the ffmpeg fork so that we can stick to a released version, however that proved prohibitively difficult, so tip of the default branch it is
no action required, but note the way I used in the pr and commit, means this issue would have autoclosed when the change merged
That is what happened.
sorry, I only saw this issue's update and assumed that you manually closed it; I assume most people involved in nixpkgs prs do not have merge perms, and github really needs to work on their ux. terribly sorry for the hassle, and assuming you were a more novice user.
No worries, GitHub really doesn't make it clear.


Question: - [go-camo](https://github.com/cactus/go-camo), a secure image proxy server. Available as [services.go-camo](#opt-services.go-camo.enable). <ins> - [Monado](https://monado.freedesktop.org/), an open source XR runtime. Available as [services.monado](#opt-services.monado.enable). </ins> - [Clevis](https://github.com/latchset/clevis), a pluggable framework for automated decryption, used to unlock encrypted devices in initrd. Available as [boot.initrd.clevis.enable](#opt-boot.initrd.clevis.enable). - [TuxClocker](https://github.com/Lurkki14/tuxclocker), a hardware control and monitoring program. Available as [programs.tuxclocker](#opt-programs.tuxclocker.enable).

The [monado] package doesn't install the udev rules generated by the [xr-hardware util] from the Monado project. Install the package and check the lack of udev rules in It was expected for the udev rules to be installted with the package. The udev rules are needed as some hmd's have some strange and specific permissions. Maybe instead of adding this to the package, monado could turn into an option like . <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: [monado]: [xr-hardware util]:
Trying packaging the udev rules similar to how . [brscan4]:
I was working on a Monado NixOS module. Perhaps I can deal with udev rules there. See


Question: bridge-utils = callPackage ../os-specific/linux/bridge-utils { }; <del> busybox = callPackage ../os-specific/linux/busybox { }; </del> <ins> busybox = callPackage ../os-specific/linux/busybox { # Fixes libunwind from being dynamically linked to a static binary. stdenv = if (stdenv.targetPlatform.useLLVM or false) then overrideCC stdenv buildPackages.llvmPackages.clangNoLibcxx else stdenv; }; </ins> busybox-sandbox-shell = callPackage ../os-specific/linux/busybox/sandbox-shell.nix { # musl roadmap has RISC-V support projected for 1.1.20 busybox = if !stdenv.hostPlatform.isRiscV && !stdenv.hostPlatform.isLoongArch64 && stdenv.hostPlatform.libc != "bionic"

Steps to reproduce the behavior: Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This looks to me like the compiler wrapper isn't respecting and/or , and it's inappropriately passing the libunwind shared object. I don't have immediate time to investigate further but did discover this minimal reproducer:
looks the same as which is due to (search path prefers .so files with ). i agree that passing in libunwind unconditionally seems not good. if one builds libcxx with the linker script at will result in but we don't so we add unconditionally. it is not clear to me why c code needs libunwind.


Question: tryExec = "itch"; icon = "itch"; desktopName = "itch"; <del> mimeTypes = [ "x-scheme-handler/itchio" "x-scheme-handler/itch" ]; </del> <ins> mimeTypes = [ "x-scheme-handler/itchio" "x-scheme-handler/itch" ]; </ins> comment = "Install and play itch.io games easily"; categories = [ "Game" ]; })

Package name: itch Latest released version: 26.1.3 Current version on the unstable channel: 26.1.3 Current version on the stable/release channel: 26.1.3 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- The current version is broken since butler is marked broken Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The latest version on seems to be 26.1.3 which is used in the package.
There is 26.1.5 as a source code , but current package uses binaryBytecode


Question: optionalString config.security.pam.enableEcryptfs '' session optional ${pkgs.ecryptfs}/lib/security/pam_ecryptfs.so '' + <ins> optionalString config.security.pam.enableFscrypt '' # Work around https://github.com/systemd/systemd/issues/8598 # Skips the pam_fscrypt module for systemd-user sessions which do not have a password # anyways. # See also https://github.com/google/fscrypt/issues/95 session [success=1 default=ignore] pam_succeed_if.so service = systemd-user session optional ${pkgs.fscrypt-experimental}/lib/security/pam_fscrypt.so '' + </ins> optionalString cfg.pamMount '' session optional ${pkgs.pam_mount}/lib/security/pam_mount.so disable_interactive '' +

I would like to use to encrypt my home directory. is already packaged (as , for some reason) What's missing is the PAM setup (). Given that exists for EcryptFS, I would like to request support for via the option, or something similar. I am aware that EcryptFS is available, to achieve the same goals, however it seems to be considered deprecated by other distributions (, ) and has some which I am not comfortable with.
This is just to say hi and to share that I too am interested in this feature
I marked this as stale due to inactivity. →


Question: }; nativeBuildInputs = [ python3 dune_3 makeWrapper ]; <del> buildInputs = [ poppler_utils ] ++ (with ocamlPackages; [ oseq spelll notty nottui lwd cmdliner domainslib digestif yojson eio_main containers-data timedesc ]); </del> <ins> buildInputs = with ocamlPackages; [ oseq spelll notty nottui lwd cmdliner domainslib digestif yojson eio_main containers-data timedesc ]; </ins> postInstall = '' # docfd needs pdftotext from popler_utils to allow pdf search <del> wrapProgram $out/bin/docfd --prefix PATH : "${lib.getBin poppler_utils}/bin/" </del> <ins> # also fzf for "docfd ?" usage wrapProgram $out/bin/docfd --prefix PATH : "${lib.makeBinPath [ poppler_utils fzf ]}" </ins> ''; meta = with lib; { description = "TUI multiline fuzzy document finder"; longDescription = '' <del> Interactive grep, but word/token/phrase based rather than regex and line based, so you can search across multiple lines (simlar to Recoll but TUI). Aims to provide a good UX via text editor and PDF viewer integration. When opening a text file, Docfd opens file at first line of search result. If PDF, then Docfd opens file at first page of the search result and starts a text search of the most unique word of the matched phrase within the same page. Main intended use case: navigating directories of notes and PDFs. </del> <ins> TUI multiline fuzzy document finder. Think interactive grep for both text files and PDFs, but word/token based instead of regex and line based, so you can search across lines easily. Docfd aims to provide good UX via integration with common text editors and PDF viewers, so you can jump directly to a search result with a single key press. </ins> ''; homepage = "https://github.com/darrenldl/docfd"; license = licenses.mit;

needs in it's path to be able to use the fuzzy file picker, e.g. produces file picker should open <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: stdenv.mkDerivation rec { pkgname = "conkeror"; <del> version = "1.0pre-20160130"; </del> <ins> version = "1.0.3"; </ins> name = "${pkgname}-${version}"; src = fetchgit { url = git://repo.or.cz/conkeror.git; <del> rev = "3e4732cd0d15aa70121fe0a0403103b777c964bf"; sha256 = "1299b1kdfd2vip3w02jzvj2i8scjpsvpx19d2c8ms2pizz7xxmp4"; </del> <ins> rev = "refs/tags/${version}"; sha256 = "06fhfk8km3gd1lc19543zn0c71zfbn8wsalinvm1dbgi724f52pd"; </ins> }; buildInputs = [ unzip makeWrapper ];

I bumped the version in which fixed the problem for me. Can you confirm?
confirm: Fix the issue. (your changes not in unstable yet). Thank you!


Question: in python3Packages.buildPythonApplication rec { pname = "bottles"; <del> version = "2022.5.28-trento-3"; </del> <ins> version = "2022.10.14.1"; </ins> src = fetchFromGitHub { owner = "bottlesdevs"; repo = pname; rev = version; <del> sha256 = "sha256-KIDLRqDLFTsVAczRpTchnUtKJfVHqbYzf8MhIR5UdYY="; </del> <ins> sha256 = "sha256-FO91GSGlc2f3TSLrlmRDPi5p933/Y16tdEpX4RcKhL0="; </ins> }; <ins> patches = [ ./vulkan_icd.patch ]; </ins> postPatch = '' chmod +x build-aux/meson/postinstall.py patchShebangs build-aux/meson/postinstall.py <del> substituteInPlace src/backend/wine/winecommand.py  </del> <ins> substituteInPlace bottles/backend/wine/winecommand.py  </ins> --replace  <del> 'self.__get_runner()'  '(lambda r: (f"${steam-run}/bin/steam-run {r}", r)[r == "wine" or r == "wine64"])(self.__get_runner())' ''; </del> <ins> "command = f"{runner} {command}""  "command = f"{''' if runner == 'wine' or runner == 'wine64' else '${steam-run}/bin/steam-run '}{runner} {command}""  --replace  "command = f"{_picked['entry_point']} {command}""  "command = f"${steam-run}/bin/steam-run {_picked['entry_point']} {command}"" ''; </ins> nativeBuildInputs = [ <ins> blueprint-compiler </ins> meson ninja pkg-config <del> wrapGAppsHook gettext </del> <ins> wrapGAppsHook4 gtk4 # gtk4-update-icon-cache </ins> appstream-glib desktop-file-utils ]; buildInputs = [ <del> gdk-pixbuf glib gobject-introspection gsettings-desktop-schemas gspell gtk3 gtksourceview4 libhandy libnotify webkitgtk gnome.adwaita-icon-theme </del> <ins> librsvg gtk4 gtksourceview5 libadwaita </ins> ]; propagatedBuildInputs = with python3Packages; [ pyyaml <del> pytoml </del> requests <del> pycairo </del> pygobject3 <del> lxml dbus-python gst-python liblarch </del> patool markdown <ins> fvs pefile urllib3 chardet certifi idna pillow orjson icoextract </ins> ] ++ [ <del> steam-run xdg-utils pciutils </del> cabextract <del> wine freetype </del> p7zip <del> gamemode # programs.gamemode.enable </del> <ins> xdpyinfo imagemagick procps gamescope </ins> mangohud <ins> vmtouch wine </ins> ]; format = "other"; <del> strictDeps = false; # broken with gobject-introspection setup hook, see https://github.com/NixOS/nixpkgs/issues/56943 </del> dontWrapGApps = true; # prevent double wrapping preFixup = ''

Vulkan/dxvk doesnt work on bottles. Vulkan is working correctly on my laptop as vkcube, vulkaninfo and the game im trying to run on bottles (that i ran thru wineWowPackages.staging + dxvk install from the official archive file) run perfectly. Steps to reproduce the behavior: bottles a bottle for gaming a game. the "directx error" pop up. Also, the dxvk log files say that the "VKKHRsurface" extension failed to load. DXVK/Vulkan should work on bottles. ! Please run and paste the result.
Having the exact same Issue on 22.11pre393800. (Raccoon)
If fails then there is a driver issue. Vulkan wont be able to draw anything to screen without it. When it occurs in proton issues it's usually a missing 32bit Vulkan library. Tho there can ofc probably be other causes
update: using the system wine doesn't fix dxvk either. only running thru the command line does. As i said, running it thru wine on the terminal does work, so something in the bottles thing is not working right.
I found the cause: these hardcoded paths right there: With this extra lines in , Vulkan will work on Bottles: I'm not sure if this is the best way to solve it, though. Tested only on a 64-bit bottle (I don't know if 32-bit bottles need to also link ). .
!!! nice find!


Question: in python3Packages.buildPythonApplication rec { pname = "bottles"; <del> version = "2022.5.28-trento-3"; </del> <ins> version = "2022.10.14.1"; </ins> src = fetchFromGitHub { owner = "bottlesdevs"; repo = pname; rev = version; <del> sha256 = "sha256-KIDLRqDLFTsVAczRpTchnUtKJfVHqbYzf8MhIR5UdYY="; </del> <ins> sha256 = "sha256-FO91GSGlc2f3TSLrlmRDPi5p933/Y16tdEpX4RcKhL0="; </ins> }; <ins> patches = [ ./vulkan_icd.patch ]; </ins> postPatch = '' chmod +x build-aux/meson/postinstall.py patchShebangs build-aux/meson/postinstall.py <del> substituteInPlace src/backend/wine/winecommand.py  </del> <ins> substituteInPlace bottles/backend/wine/winecommand.py  </ins> --replace  <del> 'self.__get_runner()'  '(lambda r: (f"${steam-run}/bin/steam-run {r}", r)[r == "wine" or r == "wine64"])(self.__get_runner())' ''; </del> <ins> "command = f"{runner} {command}""  "command = f"{''' if runner == 'wine' or runner == 'wine64' else '${steam-run}/bin/steam-run '}{runner} {command}""  --replace  "command = f"{_picked['entry_point']} {command}""  "command = f"${steam-run}/bin/steam-run {_picked['entry_point']} {command}"" ''; </ins> nativeBuildInputs = [ <ins> blueprint-compiler </ins> meson ninja pkg-config <del> wrapGAppsHook gettext </del> <ins> wrapGAppsHook4 gtk4 # gtk4-update-icon-cache </ins> appstream-glib desktop-file-utils ]; buildInputs = [ <del> gdk-pixbuf glib gobject-introspection gsettings-desktop-schemas gspell gtk3 gtksourceview4 libhandy libnotify webkitgtk gnome.adwaita-icon-theme </del> <ins> librsvg gtk4 gtksourceview5 libadwaita </ins> ]; propagatedBuildInputs = with python3Packages; [ pyyaml <del> pytoml </del> requests <del> pycairo </del> pygobject3 <del> lxml dbus-python gst-python liblarch </del> patool markdown <ins> fvs pefile urllib3 chardet certifi idna pillow orjson icoextract </ins> ] ++ [ <del> steam-run xdg-utils pciutils </del> cabextract <del> wine freetype </del> p7zip <del> gamemode # programs.gamemode.enable </del> <ins> xdpyinfo imagemagick procps gamescope </ins> mangohud <ins> vmtouch wine </ins> ]; format = "other"; <del> strictDeps = false; # broken with gobject-introspection setup hook, see https://github.com/NixOS/nixpkgs/issues/56943 </del> dontWrapGApps = true; # prevent double wrapping preFixup = ''

<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: bottles <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 2022.5.28-trento-3 desired version: 2022.7.14-brescia-1 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
While automatic update using was removed by in you need to wait while we will "get auto updates from r-rynatm"
That not true. I removed the over complicated updater in which wasn't necessary at all. Since r-ryantm also uses nix-update there was also no need to replace it. That's wrong. You can always create an update PR yourself by running ` or by manually update the package and create a PR with that. r-ryantm goes through all packages so it can sometimes take a few days until the update PR is created. Also nix-update is very lightweight with minimal dependencies, so there is not really a reason to not use it. It also does not require any kind of token or authentication.
Bottles the version released after the one currently present in nixpkgs, was released on June 13. Over one month has passed, so something about the auto-updater isn't working.
The latest r-ryantm log is here . Not sure why that is not working like it should.
I guess a update script is needed for this case :disappointed: Since the package is using , it HAS a fallback update script , so nixpkgs-update is no longer trying to figure out the latest version itself but just run the script.


Question: in python3Packages.buildPythonApplication rec { pname = "bottles"; <del> version = "2022.5.28-trento-3"; </del> <ins> version = "2022.10.14.1"; </ins> src = fetchFromGitHub { owner = "bottlesdevs"; repo = pname; rev = version; <del> sha256 = "sha256-KIDLRqDLFTsVAczRpTchnUtKJfVHqbYzf8MhIR5UdYY="; </del> <ins> sha256 = "sha256-FO91GSGlc2f3TSLrlmRDPi5p933/Y16tdEpX4RcKhL0="; </ins> }; <ins> patches = [ ./vulkan_icd.patch ]; </ins> postPatch = '' chmod +x build-aux/meson/postinstall.py patchShebangs build-aux/meson/postinstall.py <del> substituteInPlace src/backend/wine/winecommand.py  </del> <ins> substituteInPlace bottles/backend/wine/winecommand.py  </ins> --replace  <del> 'self.__get_runner()'  '(lambda r: (f"${steam-run}/bin/steam-run {r}", r)[r == "wine" or r == "wine64"])(self.__get_runner())' ''; </del> <ins> "command = f"{runner} {command}""  "command = f"{''' if runner == 'wine' or runner == 'wine64' else '${steam-run}/bin/steam-run '}{runner} {command}""  --replace  "command = f"{_picked['entry_point']} {command}""  "command = f"${steam-run}/bin/steam-run {_picked['entry_point']} {command}"" ''; </ins> nativeBuildInputs = [ <ins> blueprint-compiler </ins> meson ninja pkg-config <del> wrapGAppsHook gettext </del> <ins> wrapGAppsHook4 gtk4 # gtk4-update-icon-cache </ins> appstream-glib desktop-file-utils ]; buildInputs = [ <del> gdk-pixbuf glib gobject-introspection gsettings-desktop-schemas gspell gtk3 gtksourceview4 libhandy libnotify webkitgtk gnome.adwaita-icon-theme </del> <ins> librsvg gtk4 gtksourceview5 libadwaita </ins> ]; propagatedBuildInputs = with python3Packages; [ pyyaml <del> pytoml </del> requests <del> pycairo </del> pygobject3 <del> lxml dbus-python gst-python liblarch </del> patool markdown <ins> fvs pefile urllib3 chardet certifi idna pillow orjson icoextract </ins> ] ++ [ <del> steam-run xdg-utils pciutils </del> cabextract <del> wine freetype </del> p7zip <del> gamemode # programs.gamemode.enable </del> <ins> xdpyinfo imagemagick procps gamescope </ins> mangohud <ins> vmtouch wine </ins> ]; format = "other"; <del> strictDeps = false; # broken with gobject-introspection setup hook, see https://github.com/NixOS/nixpkgs/issues/56943 </del> dontWrapGApps = true; # prevent double wrapping preFixup = ''

However seems like cannot handle the version , so it will fail at You may just try Repology gets software latest version from various Linux distributions that ships this app, so since AUR and OpenMandriva have 2022.6.14 (no suffix) the latest version is 2022.6.14. Looks like there is also an related report in Note that nixpkgs-update does not really tries to bump package in this way because it has an fallback update script.


Question: # we create wrapper for the binaries in the different packages postBuild = '' <del> . "${makeWrapper}/nix-support/setup-hook" # get access to lua functions . ${lua}/nix-support/setup-hook </del> if [ -L "$out/bin" ]; then unlink "$out/bin" fi

Describe the bug Building neovim doesn't work anymore. To Reproduce Checkout master branch, commit (latest as of now), then build: Expected behavior Building neovim should succeed.
The failing code is (...-stdenv-linux/setup: line 320):
Having the same issue when updating my system.
Ping I think this has something to do with the recent stdenv changes. Do you know how to fix it?
This is from which breaks this manual sourcing of setup hooks I say this is a good thing! We should make those proper dependencies. I will fix shortly.
I have a similar issue in stdenv-linux/setup /nix/store/fiaj00zrmb7dynd2q9xmcrh5rn0mjwj0-stdenv-linux/setup: line 97: $'r': command not found builder for '/nix/store/frqmqjyg649bkqivqhzq041fxbfvsikw-cockpit-' failed with exit code 127
Thanks!


Question: <ins> { config, lib, pkgs, ... }: with lib; { meta = { maintainers = teams.pantheon.members; }; ###### interface options = { programs.pantheon-tweaks.enable = mkEnableOption "Pantheon Tweaks, an unofficial system settings panel for Pantheon"; }; ###### implementation config = mkIf config.programs.pantheon-tweaks.enable { services.xserver.desktopManager.pantheon.extraSwitchboardPlugs = [ pkgs.pantheon-tweaks ]; }; } </ins>

Project description Pantheon Tweaks is a Switchboard plug allowing users to somewhat tweak Pantheon (elementary OS's DE) settings of the more hidden kind, not normally available from Switchboard. As NixOS has Pantheon packaged, it might be of use in Nixpkgs. Metadata homepage URL: source URL: license: platforms: same as Pantheon Depending on Pantheon version currently in Nixpkgs, the predecessor elementary-tweaks, also GPLv3, might be of more use:
As I maintain Pantheon in NixOS, I approve of this being packaged in the future, but not , because it's archived and IIRC I denied that .
Then we should probably do it once Pantheon in NixOS advances to whatever version elementary OS 6 Odin will have - this'll probably happen once elementary OS 6 will get released.
Ah yes, the repo says "Pantheon Tweaks is currently only supported on elementary OS Odin" :+1:
Did some initial work for this (), would you like to try that? Will need Pantheon 6 () and following line in your NixOS configuration file: Update: I will move this out from the pantheon namespace when creating the PR due to reasons below.
Did some initial work for this great! would you like to try that? of course works great. only the force darkmode did not work in minder program. haven't tested more... ! ! maybe it could be enabled by an option like ? So it's consistent with other options like .
Tested 1.13.1 on both elementary OS (installed via appcenter) and NixOS (btw minder in Nixpkgs seems out-of-date, just opened a PR: ), I guess this should be an issue to minder, as minder is trying to read information from of granite (, ), so it should respect settings from switchboard-plug-pantheon-shell, while what pantheon-tweaks does is (I guess) setting under you gtk config file and I am not sure how handle this. You can check this with: ! I am not sure as this is not an official part of Pantheon. I guess it should be okay to do this.
I am not sure as this is not an official part of Pantheon.


Question: <ins> { config, lib, pkgs, ... }: with lib; { meta = { maintainers = teams.pantheon.members; }; ###### interface options = { programs.pantheon-tweaks.enable = mkEnableOption "Pantheon Tweaks, an unofficial system settings panel for Pantheon"; }; ###### implementation config = mkIf config.programs.pantheon-tweaks.enable { services.xserver.desktopManager.pantheon.extraSwitchboardPlugs = [ pkgs.pantheon-tweaks ]; }; } </ins>

yes, that is a concern, but we can make that clear in the description do you think it is acceptable to enable a third-party component (e.g. pantheon-tweaks) with an option like if we clarify that it is third-party in the description, which is for example displayed at the or in the documentation?
I would not recommend packaging this tweaks app. It regularly breaks since it references gsettings that aren't considered API. That's just my personal opinion though I'm not familiar with NixOS options or what that means so I can't really offer an opinion there
thanks for your opinion! the program exists and people want to use it and we at nixos want to empower users to do what they want, even if the choices could be considered bad, like installing proprietary software. that's why it's considered for advanced users. you are responsible for the choices you make and you can end up with a broken system, but it's easy to roll back to a working state. experimenting is encouraged So i think it's fine for us to offer the package, but we can clarify that "it's not recommended by elementary because it regularly breaks". I'm not familiar with NixOS options or what that means so I can't really offer an opinion there i try to explain quickly: on nixos the whole system is configured by one (or multiple) config. file. as a consequence is read-only if you want to use pantheon, you add this line to the config: that sets up pantheon with default settings. there are options to change those default, like to remove default apps you don't need... so the question here is, all current options with in the name relate to official pantheon software, but would relate to third party software, which is not visible from the name. so it might not be 100% clear all the time so my suggestion is to clarify it at least in the description of the option that it is third-party and not recommended the concern is that it could devaluate you branding like the name "pantheon"
ah okay yeah. If possible then it would great if that was not namespaced with actual parts of pantheon and instead namespaced the way you would hand extensions or apps if there's no special convention for extensions. Thanks!
i suggest then


Question: catalogue = callPackage ../development/python-modules/catalogue { }; <ins> catboost = callPackage ../development/python-modules/catboost { }; </ins> cbeams = callPackage ../misc/cbeams { }; cbor2 = callPackage ../development/python-modules/cbor2 { };

Would be a very useful package to have for ML Enthusiasts Project description Machine Learning Catboost Library Metadata CatBoost is a high-performance open source library for gradient boosting on decision trees homepage URL: source URL: license: Apache License 2.0 platforms: Linux installation instructions: Please let me know if I should stop tagging you in random issues and it bothers you (sorry, i'll stop), but I thought this might be of interest to you since you are very involved in tensorflow.
taggining maintainers of xgboost and lightgbm. Wondering if you could look into compiling catboost too?
I use tensorflow at work, which is why I care :). But I'm not a data-scientist
understood, thank you. GPU support for catboost would also be very welcome.
Looks like they have a non standard install script. But definitely doable. Sadly I don't think I have time in the near future but would be happy to point you in the right direction to get stared with a PR
both eyes wide open - i'll try to start this w/e, any pointers very welcome, thank you.
Currently failing to build on nix, although the file clearly exists.
- maybe it's easier if you create a work-in-progress pull request so other people can check? Two things that stand out are: looks like something is being downloaded during the build process. This won't work with sandboxing because there won't be a working network. builds should be isolated, i.e. access to should be rewritten to the local build directory, not (probably hardcoded somewhere in the build scripts). Packaging for nix can be quite fiddly - I think might be a good example for fetching complex dependencies + build script patches.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .


Question: <del> { stdenv, buildPythonPackage, fetchPypi, substituteAll, isPy3k, geos, gdal, pytz, withGdal ? false }: buildPythonPackage rec { pname = "Django"; version = "2.0.10"; disabled = !isPy3k; src = fetchPypi { inherit pname version; sha256 = "0292a7ad7d8ffc9cfc6a77f043d2e81f5bbc360c0c4a1686e130ef3432437d23"; }; patches = stdenv.lib.optionals withGdal [ (substituteAll { src = ./1.10-gis-libs.template.patch; geos = geos; gdal = gdal; extension = stdenv.hostPlatform.extensions.sharedLibrary; }) ]; # patch only $out/bin to avoid problems with starter templates (see #3134) postFixup = '' wrapPythonProgramsIn $out/bin "$out $pythonPath" ''; propagatedBuildInputs = [ pytz ]; # too complicated to setup doCheck = false; meta = with stdenv.lib; { description = "A high-level Python Web framework"; homepage = https://www.djangoproject.com/; license = licenses.bsd3; maintainers = with maintainers; [ georgewhewell ]; }; } </del>

According to , Django 2.0 will reach EOL in April 2019, i.e. just after the release of 19.03. Better not include it in the first place. cc
agreed. For 19.03 we will only support 1.11 and 2.1 (and probably port 2.2 when it gets available).


Question: buildGo117Module rec { pname = "dstp"; <del> version = "0.3.0"; </del> <ins> version = "0.4.0"; </ins> src = fetchFromGitHub { owner = "ycd"; repo = pname; rev = "v${version}"; <del> sha256 = "1pxzaz2a261lsnbdbr9km1214a4jzq2wgkdfvf9g966gsa4nqfl6"; </del> <ins> sha256 = "sha256-YvuUgHHa8Egk+bbSI0SH0i3YrKWRbzjAckNG32RBRXw="; </ins> }; <del> vendorSha256 = "1n1kx4zcskndikjl44vwmckr6x5cv6cacwdwfwjjsf6aqgagpld8"; </del> <ins> vendorSha256 = "sha256-qNH71MPKOC0ld7xxppjZrHSTJ6t8E0LljM1OzT7pM9g="; </ins> # Tests require network connection, but is not allowed by nix doCheck = false;

<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on github to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: dstp <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 0.3.0 desired version: 0.4.0 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: I'd love to update the package myself without annoying you :) If there is a documentation about how to upgrade packages, i'd love to learn it and try my best next time, thanks in advance!
For simple version updates, I update the version number and to get the new hash I run (in the nixpkgs top directory): For go packages, we also have to update the hash, that one is tricky, and what I do is to try to build the package. That will fail, but it gives us the new hash, I don't know a better way. There is also a bot () creating PR for those simple version updates. It uses repology to find the latest version:
Awesome, thanks!


Question: wantedBy = [ "multi-user.target" ]; wants = [ "keys.target" ]; <del> after = [ "network.target" "fs.target" "postgresql.service" "keys.target" ]; </del> <ins> after = [ "network.target" "fs.target" "keys.target" ]; </ins> path = [ httpd pkgs.coreutils pkgs.gnugrep ]

I set up a brand new NixOS system with nothing but . After switching to the new configuration, I ran and was surprised to find in there in a and state. I poked around and it turns out that our module refers to in its section: It sort of makes sense, because presumably you want your webserver to spin up after your database, but it feels kinda icky to give completely unrelated (in principle) services dependencies on one another, especially when some of them might not even be on your system. I suppose we could make that entry conditional on , but I'm not sure what the pros and cons of that are.
Yes, I'd think it would better be conditional. Units should get reloaded on system switch IIRC, before starting new services, so I see no danger in that.
I think, this link should be broken unconditionally. In my scenario apache-httpd is used solely for SVN web interface, and while I have running Postgresql instance, they are orthogonal (postgresql is acompanied by tomcat container/nginx pair)
Perhaps, yeah. It also appears to depend on , which I think is a nixops-ism.


Question: stdenv.mkDerivation rec { name = "root-${version}"; <del> version = "6.09.02"; </del> <ins> version = "6.10.00"; </ins> src = fetchurl { url = "https://root.cern.ch/download/root_v${version}.source.tar.gz"; <del> sha256 = "0fc6b0l7bw66cyckxs4ikvyzcv1zlfx88205jx153smdhih0jj2k"; </del> <ins> sha256 = "1rxqcpqf1b3sxig5xbh3mkvarhg9lgj2f0gv0j48klfw8kgfwlsp"; </ins> }; buildInputs = [ cmake pcre pkgconfig python2 zlib libxml2 lzma gsl ]

I have a system without Command Line Tools or XCode and nix'es cmake can't find headers and tries to pick up system frameworks. Try to build this: On my system I get: System: Darwin Nix version: nix-env (Nix) 1.11.9 Nixpkgs version: 17.09pre-git () Sandboxing enabled: no
Related to


Question: nlopt lp_solve colpack <del> ] ++ lib.optionals pythonSupport (with python2Packages; [ python numpy ]) </del> <ins> ] ++ lib.optionals pythonSupport (with python3Packages; [ python numpy ]) </ins> ++ lib.optional opencvSupport opencv; cmakeFlags = let

Using Shogun as a for another CMake-based project fails because the dependent project cannot properly find the shogun library (via its installed cmake files). Steps to reproduce the behavior: to build a derivation based on shogun files are wrong Everything builds correctly I am trying to build the following derivation However I get an error at the build generation step: This indicates that shogun CMake files are not in the right place and/or are pointing towards the wrong paths.
I fixed the issue with shogun. When installing the configuration files, CMake calculates the prefix to the installed library based on the output directory, instead of the default , and I missed it when I split the derivation into multiple outputs. I wonder why it's not a more widespread issue, only a few derivations patch it. But that derivation still doesn't build: This is in macOS, though. Maybe it works on Linux.
Thanks, is the fix committed yet? The other error is unrelated and I can fix it.
I'm working on the PR.


Question: <ins> Fix a following build error: In file included from ../../3rdparty/chromium/device/bluetooth/bluetooth_remote_gatt_characteristic_mac.mm:7: ../../3rdparty/chromium/base/bind.h:59:3: error: static_assert failed "Bound argument |i| of type |Arg| cannot be forwarded as |Unwrapped| to the bound functor, which declares it as |Param|." static_assert( ^ ../../3rdparty/chromium/base/bind.h:91:7: note: in instantiation of template class 'base::internal::AssertConstructible<1, long, long, const long &, NSError *>' requested here : AssertConstructible<Ns, Args, std::decay_t<Args>, Unwrapped, Params>... { ^ ../../3rdparty/chromium/base/bind.h:213:27: note: in instantiation of template class 'base::internal::AssertBindArgsValidity<std::__1::integer_sequence<unsigned long, 0, 1>, base::internal::TypeList<base::WeakPtr<device::BluetoothRemoteGattCharacteristicMac>, long>, base::internal::TypeList<device::BluetoothRemoteGattCharacteristicMac *, const long &>, base::internal::TypeList<device::BluetoothRemoteGattCharacteristicMac *, NSError *> >' requested here static_assert(internal::AssertBindArgsValidity< ^ ../../3rdparty/chromium/base/bind.h:242:16: note: in instantiation of function template specialization 'base::BindRepeating<void (device::BluetoothRemoteGattCharacteristicMac::*)(NSError *), base::WeakPtr<device::BluetoothRemoteGattCharacteristicMac>, long>' requested here return base::BindRepeating(std::forward<Functor>(functor), ^ ../../3rdparty/chromium/device/bluetooth/bluetooth_remote_gatt_characteristic_mac.mm:211:15: note: in instantiation of function template specialization 'base::Bind<void (device::BluetoothRemoteGattCharacteristicMac::*)(NSError *), base::WeakPtr<device::BluetoothRemoteGattCharacteristicMac>, long>' requested here base::Bind(&BluetoothRemoteGattCharacteristicMac::DidWriteValue, ^ Resurrected from https://github.com/NixOS/nixpkgs/blob/ddcf01bca6c7a7a7f096bec836a1e6a707ad473d/pkgs/development/libraries/qt-5/5.11/qtwebengine-clang-fix.patch because the same problem is present in 5.12 when compiling on macOS. --- a/src/3rdparty/chromium/device/bluetooth/bluetooth_remote_gatt_characteristic_mac.mm +++ b/src/3rdparty/chromium/device/bluetooth/bluetooth_remote_gatt_characteristic_mac.mm @@ -209,7 +209,7 @@ void BluetoothRemoteGattCharacteristicMac::WriteRemoteCharacteristic( base::ThreadTaskRunnerHandle::Get()->PostTask( FROM_HERE, base::Bind(&BluetoothRemoteGattCharacteristicMac::DidWriteValue, -                   weak_ptr_factory_.GetWeakPtr(), nil)); +                   weak_ptr_factory_.GetWeakPtr(), nullptr)); } } </ins>

The component of the derivation fails to compile on MacOS. But in two ways, and I can't tell what causes one or the other to trigger. On command: On command: the channel compilation failure Compiles.
It has been broken for a while now for different reasons. Maintaining it for darwin is a lot of work and nobody has stepped up to do that. Also, this is a duplicate of
By the way, what is your use case for ?
We're building a desktop version of mobile application and we need for our in-app browser with Ethereum support.


Question: <ins> Fix a following build error: In file included from ../../3rdparty/chromium/device/bluetooth/bluetooth_remote_gatt_characteristic_mac.mm:7: ../../3rdparty/chromium/base/bind.h:59:3: error: static_assert failed "Bound argument |i| of type |Arg| cannot be forwarded as |Unwrapped| to the bound functor, which declares it as |Param|." static_assert( ^ ../../3rdparty/chromium/base/bind.h:91:7: note: in instantiation of template class 'base::internal::AssertConstructible<1, long, long, const long &, NSError *>' requested here : AssertConstructible<Ns, Args, std::decay_t<Args>, Unwrapped, Params>... { ^ ../../3rdparty/chromium/base/bind.h:213:27: note: in instantiation of template class 'base::internal::AssertBindArgsValidity<std::__1::integer_sequence<unsigned long, 0, 1>, base::internal::TypeList<base::WeakPtr<device::BluetoothRemoteGattCharacteristicMac>, long>, base::internal::TypeList<device::BluetoothRemoteGattCharacteristicMac *, const long &>, base::internal::TypeList<device::BluetoothRemoteGattCharacteristicMac *, NSError *> >' requested here static_assert(internal::AssertBindArgsValidity< ^ ../../3rdparty/chromium/base/bind.h:242:16: note: in instantiation of function template specialization 'base::BindRepeating<void (device::BluetoothRemoteGattCharacteristicMac::*)(NSError *), base::WeakPtr<device::BluetoothRemoteGattCharacteristicMac>, long>' requested here return base::BindRepeating(std::forward<Functor>(functor), ^ ../../3rdparty/chromium/device/bluetooth/bluetooth_remote_gatt_characteristic_mac.mm:211:15: note: in instantiation of function template specialization 'base::Bind<void (device::BluetoothRemoteGattCharacteristicMac::*)(NSError *), base::WeakPtr<device::BluetoothRemoteGattCharacteristicMac>, long>' requested here base::Bind(&BluetoothRemoteGattCharacteristicMac::DidWriteValue, ^ Resurrected from https://github.com/NixOS/nixpkgs/blob/ddcf01bca6c7a7a7f096bec836a1e6a707ad473d/pkgs/development/libraries/qt-5/5.11/qtwebengine-clang-fix.patch because the same problem is present in 5.12 when compiling on macOS. --- a/src/3rdparty/chromium/device/bluetooth/bluetooth_remote_gatt_characteristic_mac.mm +++ b/src/3rdparty/chromium/device/bluetooth/bluetooth_remote_gatt_characteristic_mac.mm @@ -209,7 +209,7 @@ void BluetoothRemoteGattCharacteristicMac::WriteRemoteCharacteristic( base::ThreadTaskRunnerHandle::Get()->PostTask( FROM_HERE, base::Bind(&BluetoothRemoteGattCharacteristicMac::DidWriteValue, -                   weak_ptr_factory_.GetWeakPtr(), nil)); +                   weak_ptr_factory_.GetWeakPtr(), nullptr)); } } </ins>

Full log: Error message: That's the result I get from my macOS remote builder. When I run the build on my desktop Mac, it builds fine and uses the impure SDK from my Catalina install (10.15.1): However, the local build displays this warning repeatedly: I assume this is related to the macOS patches and hopefully gives some clue as to why it's broken.
qtbase builds fine on hydra: qtwebengine fails:
Those links point to the same thing. Anyway, strictly speaking I'm trying to build , but it's failing in .
Can you explain what do you mean? How are you using ?
It's a dependency of . edit: sorry, I see what you mean now. is a dependency of . I was confused by the message from the build saying that QT would be installed in .
Sure, depends on . Realistically, your best bet for now is to just use anki from an old version of nixpkgs. You see, doesn't have a darwin maintainer. I think, I was the last person to fix it around last January. The problem is that it's hard to keep up with all the updates. Every "minor" Qt version bump brings serious breaking changes for on darwin (like they might not even support our version of SDK anymore...). To make things worse we port all those bumps to the stable branch, so it quickly breaks there too.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
Still important to me, many qt apps are broken on darwin due to this one.


Question: rustPlatform.buildRustPackage rec { pname = "lapce"; <del> version = "0.0.10"; </del> <ins> version = "0.0.12"; </ins> src = fetchFromGitHub { owner = "lapce"; repo = pname; rev = "v${version}"; <del> sha256 = "tOVFm4DFQurFU4DtpPwxXQLbTGCZnrV1FfYKtvkRxRE="; </del> <ins> sha256 = "sha256-ZFQjQ5+G0b0Fgg3+du/drt+62rC/TCNR5MIdJXAkTrE="; </ins> }; <del> cargoPatches = [ ./fix-version.patch ]; cargoSha256 = "BwB3KgmI5XnZ5uHv6f+kGKBzpyxPWcoKvF7qw90eorI="; </del> <ins> cargoSha256 = "sha256-sMTootPsenaWzLLFImo6HWC1pcm2uFupPhVWsUJp1Ak="; </ins> nativeBuildInputs = [ cmake

<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: lapce <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 0.0.10 desired version: 0.0.12 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Maybe it will fix the crash:
can you create a pull request?
I am using changes in local build. it is working fine


Question: <del> { mkDerivation, lib, fetchurl, qtbase, qttools, qmake }: </del> <ins> { mkDerivation, lib, fetchurl, qtbase, qtsvg, qttools, qmake }: </ins> let inherit (lib) getDev; in

on Hydra: cc
Since it's been building for me, checked if I was sitting on any changes and while the commit message doesn't indicate that it fixes anything (eep), it does seem to fix this issue: Don't remember enough details to justify it fully offhand (again d'oh for not writing it down at the time hehe) but hopefully this helps work towards a suitable resolution :).
Naturally this breaks in as well.
Yep, broken for me too. Haven't had time to tinker yet.
I have the same problem, but the commit mentioned fixes it for me.
So are we just waiting for this commit to be in the unstable channels?


Question: <del> { stdenv, fetchFromGitHub, qtbase, qtx11extras, qmake, pkgconfig, boost }: </del> <ins> { lib, mkDerivation, fetchFromGitHub, qtbase, qtx11extras, qmake, pkgconfig, boost }: </ins> <del> stdenv.mkDerivation { </del> <ins> mkDerivation { </ins> name = "twmn-git-2018-10-01"; src = fetchFromGitHub {

twmnd does not launch because qt5 library path is missing. Install the twmn package and run twmnd. twmnd works when I manually set the LDLIBRARYPATH to <qtbase/lib. System: NixOS 16.09.931. Nix version: 1.11.4 Nixpkgs version:16.09.931.
I noticed the same or similar thing when trying to run twmnd as a systemd user service. It just SIGABRTs: I could reproduce with Although works fine... So clearly there is some impurity in my local environment which is making twmnd work "by accident?" Possibly related?:


Question: , fetchFromGitHub }: <del> python3.pkgs.buildPythonApplication rec { </del> <ins> let python = python3.override { # FlexGet doesn't support transmission-rpc>=5 yet # https://github.com/NixOS/nixpkgs/issues/258504 packageOverrides = self: super: { transmission-rpc = super.transmission-rpc.overridePythonAttrs (old: rec { version = "4.3.1"; src = fetchPypi { pname = "transmission_rpc"; inherit version; hash = "sha256-Kh2eARIfM6MuXu7RjPPVhvPZ+bs0AXkA4qUCbfu5hHU="; }; doCheck = false; }); }; }; in python.pkgs.buildPythonApplication rec { </ins> pname = "flexget"; version = "3.9.10"; format = "pyproject";

When flexget starts up, it crashes with this error: . The version of transmission-rpc in nixpkgs is currently 7.x.x. Steps to reproduce the behavior: a flexget config that uses transmission. . Flexget runs normally. (transmission-rpc) (flexget) Please run and paste the result.
Upstream flexget has some discussion about upgrading to transmission-rpc v7:
Workaround: the last transmission-rpc 4 version in nixpkgs to transmission-rpc-4.nix: it to an overlay


Question: sed -i 's,/etc/protocols,${iana-etc}/etc/protocols,' src/net/lookup_unix.go '' + lib.optionalString stdenv.isLinux '' <del> sed -i 's,/usr/share/zoneinfo/,${tzdata}/share/zoneinfo/,' src/time/zoneinfo_unix.go </del> <ins> # prepend the nix path to the zoneinfo files but also leave the original value for static binaries # that run outside a nix server sed -i 's,"/usr/share/zoneinfo/,"${tzdata}/share/zoneinfo/",nt&,' src/time/zoneinfo_unix.go </ins> # Find the loader dynamically LOADER="$(find ${lib.getLib libc}/lib -name ld-linux* | head -n 1)"

A Go program compiled using nix-shell returns an error when running on a separate server and trying to load a timezone file. file with: $nix-shell $<inside shellgo build $exit $ ./app # name of the app you just created 2019/01/25 20:04:58 All went well: America/NewYork Now copy this file to another computer #./app 2019/01/26 01:01:34 could not load new york locationopen /nix/store/0596k27r6pacyx4jp1bcn8zqyjhji52l-go- no such file or directory The error includes the zip name due to internal reasons the Go team has, but the real problem is that nix replaced with I would be more than happy to send a Pull Request if you agree with the proposed solution of prepending instead of replacing. $ nix-shell -p nix-info --run "nix-info -m" these paths will be fetched (0.00 MiB download, 0.00 MiB unpacked): /nix/store/dzvh4f6ihkwg44mmf2awxg564k1s8khg-nix-info copying path '/nix/store/dzvh4f6ihkwg44mmf2awxg564k1s8khg-nix-info' from ''... system: host os: multi-user?: sandbox: version: channels(diego): nixpkgs: version is nixos-unstable-2019-01-22 The file replaces the path that the go runtime looks for the timezone information. Original Go code is: But nix changes the first entry, for This works fine if you end up running your go application in the same nix env you compiled it, but when you deploy your go program to a separate server, the path, that can look like isn't present on the separate server and then the lookup fails. is a very common path in Linux distributions. A better way to solve this would be to prepend the nix only path, as the first entry, and then keep and the other entries as they are in the original go source code. The benefits are that those who compile and run in the same nix environment will use the nix path, but those who deploy somewhere else won't have to do any extra work.


Question: sed -i 's,/etc/protocols,${iana-etc}/etc/protocols,' src/net/lookup_unix.go '' + lib.optionalString stdenv.isLinux '' <del> sed -i 's,/usr/share/zoneinfo/,${tzdata}/share/zoneinfo/,' src/time/zoneinfo_unix.go </del> <ins> # prepend the nix path to the zoneinfo files but also leave the original value for static binaries # that run outside a nix server sed -i 's,"/usr/share/zoneinfo/,"${tzdata}/share/zoneinfo/",nt&,' src/time/zoneinfo_unix.go </ins> # Find the loader dynamically LOADER="$(find ${lib.getLib libc}/lib -name ld-linux* | head -n 1)"

I doubt anyone ever considered support for non-Nix and therefore I will mark it also as . I'll leave it open for now as maybe it can be supported (I doubt it).
would you accept a PR with my proposed solution? It won't hurt nix deployments but will help a use case of building a go program in nix but deploying outside of nix.
cross referencing a thread on the mailing list about this ticket/issue so both conversations are linked.
Your explanation and proposed solution seem to be very reasonable to me. I suggest that you submit a PR.


Question: assert "Failed to connect" not in status,  "Failed to connect to the daemon" <ins> with subtest("Daemon can be configured imperatively"): imperative.wait_for_unit("wpa_supplicant-wlan1.service") imperative.wait_until_succeeds("wpa_cli -i wlan1 status") imperative.succeed("wpa_cli -i wlan1 add_network") imperative.succeed("wpa_cli -i wlan1 set_network 0 ssid '"nixos-test"'") imperative.succeed("wpa_cli -i wlan1 set_network 0 psk '"reproducibility"'") imperative.succeed("wpa_cli -i wlan1 save_config") imperative.succeed("grep -q nixos-test /etc/wpa_supplicant.conf") </ins> machineSae.wait_for_unit("hostapd.service") machineSae.copy_from_vm("/run/hostapd/wlan0.hostapd.conf") with subtest("Daemon can connect to the SAE access point using SAE"):

After installing a fresh system with the following configuration: the file is not created, hence wpasupplicant fails to start with the following error: nixpkgs
I don't know the logic of , but I think you're supposed to provide the file yourself. I guess it could be ed if wpa_supplicant fails without one.
You can do
That probably wouldn't work due to permissions. EDIT: wpa_supplicant is still running as root, so it should work.
Fixed in


Question: version = "8.0.0"; src = fetchurl { <del> url = "https://web.archive.org/web/20211130172544/https://tetr.io/about/desktop/builds/TETR.IO%20Setup.deb"; </del> <ins> url = "https://web.archive.org/web/20211228025517if_/https://tetr.io/about/desktop/builds/TETR.IO%20Setup.deb"; </ins> name = "tetrio-desktop.deb"; sha256 = "1nlblfhrph4cw8rpic9icrs78mzrxyskl7ggyy2i8bk9i07i21xf"; };

Trying to install tetrio fails (see screenshots) Steps to reproduce the behavior: tetrio-desktop from nixpkgs-unstable (I did it using a flake) The package should install with no errors. ! <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.
Oops, it looks like I accidentally used a non-direct download link for the source. It also looks like audio is broken, so I'll start a PR soon.


Question: libPath = lib.makeLibraryPath [ alsa-lib cups <ins> libpulseaudio </ins> libX11 libXScrnSaver libXtst


Question: <ins> diff --git a/src/Settings/ThemeSettings.vala b/src/Settings/ThemeSettings.vala index 589121b..8e9c81e 100644 --- a/src/Settings/ThemeSettings.vala +++ b/src/Settings/ThemeSettings.vala @@ -29,7 +29,7 @@ public class PantheonTweaks.ThemeSettings { var themes = new Gee.ArrayList<string> (); string[] dirs = { -            "/usr/share/" + path + "/", +            "/run/current-system/sw/share/" + path + "/", Environment.get_home_dir () + "/." + path + "/", Environment.get_home_dir () + "/.local/share/" + path + "/"}; </ins>

Project description Pantheon Tweaks is a Switchboard plug allowing users to somewhat tweak Pantheon (elementary OS's DE) settings of the more hidden kind, not normally available from Switchboard. As NixOS has Pantheon packaged, it might be of use in Nixpkgs. Metadata homepage URL: source URL: license: platforms: same as Pantheon Depending on Pantheon version currently in Nixpkgs, the predecessor elementary-tweaks, also GPLv3, might be of more use:
As I maintain Pantheon in NixOS, I approve of this being packaged in the future, but not , because it's archived and IIRC I denied that .
Then we should probably do it once Pantheon in NixOS advances to whatever version elementary OS 6 Odin will have - this'll probably happen once elementary OS 6 will get released.
Ah yes, the repo says "Pantheon Tweaks is currently only supported on elementary OS Odin" :+1:
Did some initial work for this (), would you like to try that? Will need Pantheon 6 () and following line in your NixOS configuration file: Update: I will move this out from the pantheon namespace when creating the PR due to reasons below.
Did some initial work for this great! would you like to try that? of course works great. only the force darkmode did not work in minder program. haven't tested more... ! ! maybe it could be enabled by an option like ? So it's consistent with other options like .
Tested 1.13.1 on both elementary OS (installed via appcenter) and NixOS (btw minder in Nixpkgs seems out-of-date, just opened a PR: ), I guess this should be an issue to minder, as minder is trying to read information from of granite (, ), so it should respect settings from switchboard-plug-pantheon-shell, while what pantheon-tweaks does is (I guess) setting under you gtk config file and I am not sure how handle this. You can check this with: ! I am not sure as this is not an official part of Pantheon. I guess it should be okay to do this.
I am not sure as this is not an official part of Pantheon.


Question: <ins> diff --git a/src/Settings/ThemeSettings.vala b/src/Settings/ThemeSettings.vala index 589121b..8e9c81e 100644 --- a/src/Settings/ThemeSettings.vala +++ b/src/Settings/ThemeSettings.vala @@ -29,7 +29,7 @@ public class PantheonTweaks.ThemeSettings { var themes = new Gee.ArrayList<string> (); string[] dirs = { -            "/usr/share/" + path + "/", +            "/run/current-system/sw/share/" + path + "/", Environment.get_home_dir () + "/." + path + "/", Environment.get_home_dir () + "/.local/share/" + path + "/"}; </ins>

yes, that is a concern, but we can make that clear in the description do you think it is acceptable to enable a third-party component (e.g. pantheon-tweaks) with an option like if we clarify that it is third-party in the description, which is for example displayed at the or in the documentation?
I would not recommend packaging this tweaks app. It regularly breaks since it references gsettings that aren't considered API. That's just my personal opinion though I'm not familiar with NixOS options or what that means so I can't really offer an opinion there
thanks for your opinion! the program exists and people want to use it and we at nixos want to empower users to do what they want, even if the choices could be considered bad, like installing proprietary software. that's why it's considered for advanced users. you are responsible for the choices you make and you can end up with a broken system, but it's easy to roll back to a working state. experimenting is encouraged So i think it's fine for us to offer the package, but we can clarify that "it's not recommended by elementary because it regularly breaks". I'm not familiar with NixOS options or what that means so I can't really offer an opinion there i try to explain quickly: on nixos the whole system is configured by one (or multiple) config. file. as a consequence is read-only if you want to use pantheon, you add this line to the config: that sets up pantheon with default settings. there are options to change those default, like to remove default apps you don't need... so the question here is, all current options with in the name relate to official pantheon software, but would relate to third party software, which is not visible from the name. so it might not be 100% clear all the time so my suggestion is to clarify it at least in the description of the option that it is third-party and not recommended the concern is that it could devaluate you branding like the name "pantheon"
ah okay yeah. If possible then it would great if that was not namespaced with actual parts of pantheon and instead namespaced the way you would hand extensions or apps if there's no special convention for extensions. Thanks!
i suggest then


Question: <ins> { stdenv, lib, pkg-config, fetchFromGitHub, xorg, libdrm, SDL2, }: stdenv.mkDerivation (finalAttrs: { pname = "switchres"; version = "2.2.1"; src = fetchFromGitHub { owner = "antonioginer"; repo = "switchres"; rev = "refs/tags/v${finalAttrs.version}"; hash = "sha256-/21RcpumWYNBPck7gpH6krwC3Thz/rKDPgeJblN2BDA="; }; nativeBuildInputs = [ pkg-config ]; buildInputs = [ xorg.libXrandr xorg.xorgproto libdrm SDL2 ]; patchPhase = '' runHook preHook substituteInPlace ./custom_video_xrandr.cpp  --replace-fail libX11.so ${xorg.libX11}/lib/libX11.so  --replace-fail libXrandr.so ${xorg.libXrandr}/lib/libXrandr.so substituteInPlace ./custom_video_drmkms.cpp  --replace-fail libdrm.so ${libdrm}/lib/libdrm.so  runHook postHook ''; env = { PREFIX = "$(out)"; }; preInstall = '' install -Dm755 switchres $out/bin/switchres ''; meta = { description = "Modeline generation engine for emulation"; homepage = "https://github.com/antonioginer/switchres"; changelog = "https://github.com/antonioginer/switchres/releases/tag/v${finalAttrs.version}"; license = lib.licenses.gpl2Only; mainProgram = "switchres"; maintainers = with lib.maintainers; [ bot-wxt1221 ]; platforms = lib.platforms.linux; }; }) </ins>

Project description <!-- Describe the project a little: --Switchres is a modeline generation engine for emulation. Its purpose is on-the-fly creation of fully customized video modes that accurately reproduce those of the emulated systems. Based on a monitor profile, it will provide the best video mode for a given width, height, and refresh rate. Switchres features the most versatile modeline generation ever, ranging from 15-kHz low resolutions up to modern 8K, with full geometry control, smart scaling, refresh scaling, mode rotation, aspect ratio correction and much more. Metadata homepage URL: source URL: license: GPL-2.0+ platforms: linux, windows P.S. Switchres is used in RetroArch so there might be something to reference from there. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: <ins> { fetchFromGitHub, buildGoModule, buildLua, lib, }: let version = "1.6.1"; src = fetchFromGitHub { owner = "tnychn"; repo = "mpv-discord"; rev = "v${version}"; hash = "sha256-P1UaXGboOiqrXapfLzJI6IT3esNtflkQkcNXt4Umukc="; }; core = buildGoModule { name = "mpv-discord-core"; inherit version; src = "${src}/mpv-discord"; vendorHash = "sha256-xe1jyWFQUD+Z4qBAVQ0SBY0gdxmi5XG9t29n3f/WKDs="; }; in buildLua { pname = "mpv-discord"; inherit version src; scriptPath = "scripts/discord.lua"; postInstall = '' substituteInPlace $out/share/mpv/scripts/discord.lua  --replace-fail 'binary_path = ""' 'binary_path = "${core}/bin/mpv-discord"' ''; meta = { description = "Cross-platform Discord Rich Presence integration for mpv with no external dependencies"; homepage = "https://github.com/tnychn/mpv-discord"; license = lib.licenses.mit; platforms = lib.platforms.all; maintainers = with lib.maintainers; [ bddvlpr ]; }; } </ins>

Project description A cross-platform Discord Rich Presence integration for mpv with no external dependencies. (MPV Userscript) Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin, windows
I've already but haven't PR'ed this to nixpkgs yet. Will probably do this when I get home from vacation next week.