Steps to reproduce the behavior: pyside6 Please run and paste the result. :sweat_smile: I guess it says not found because i have no channels (i use flakes)
This same failure is causing syncplay to fail to install on my system.
yeah thats how i knew lol
To confirm, I can reproduce this issue.
I'm trying to package something which relies on pyside6. Package builds fine on nixos-stable but fails under nixos-unstable due to pyside6 not building.


The , which . I do not have a short reproducer. However, the issue was observed on in a cgo context. The issue can be resolved by applying the following change to : The error should not have occurred. The code under test used to work, and failed after an update of the nixpkgs revision in use from to . n/a The commit range includes the following two commits that touch on : adds to the strip setup-hook adds to the cc-wrapper for response file handling The latter one seems to be the cause of the issue. Similar issues were described in and <!-- 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.
So the wrapper picks up the binary from the system instead of the one from the store because the environment is not pure? This makes the behavior of this and other wrappers unpredictable. Maybe it would be better to make sure that the tools used in the wrapper are actually from its real runtime dependencies in the store?
Yes, that matches my understanding. Yes, that thought crossed my mind, too. However, I saw that there is an , which is then . And this import and seems to be . I don't know the context or reasoning for all this logic and didn't venture there. But, that may very well also be a good solution.
Ah cool! So it basically already works that way. Setting actually enables the import. Your explanation led me to find where this logic was first introduced. The discussion there is very interesting, afaiu we need to restore to its original value so things like linker scripts will still find the intended executables. I think that the commit that introduced the should have it before the path gets restored.
Oh, I see, thanks! I overlooked one negation. That seems like it could solve the issue, too. Perhaps it's easier to just resolve before the is reset and then still invoke it later, since . I had opened that replaces the invocation by a portable one. That approach was easier to test in my use-case without rebuilding the world.


Steps to reproduce the behavior: as such, so that it builds with Airplay 2 support: Strangest thing is that I have 4.1.1 built and working for a while (probably at ) but following a it does not rebuild anymore, even though and hasn't changed, while the only two subsequent commits are and which I'm not too sure how they could relate. <!-- 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.


I have transmission running inside a Nixos container which has been working without issue until I recently updated the system. It now fails to start inside the container, I have tried deleting the container and all its data but the same issue exists when creating a new one. I have also tried creating the path "" on both the host and container but it doesn't seem to care. Steps to reproduce the behavior: Run transmission inside of a container Transmission service starts and runs without issue Service status Here's where I have the container and transmission defined in my config. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Same here, not sure if it's an upstream or nixpkgs issue
For the time being and since it's inside a container anyway I'm overriding the root dir of the systemd unit:
Thanks your fix is working for me!
The problem is that is listed in : Which got introduced in to The original problem was that was not in the chroot. I'd say mounting all of as read-only is going too far, so a better fix would be to just mount and only if is true. It also seems weird to have this logic be part of Transmission, but whatever. So a workaround is: (And I'm not sure why this wasn't a problem for 3 years)
I've stumbled upon this issue as well, and wondering if there is anything we can do about it regarding the Transmission service. I had to disable the following is well, before it played nicely in my setup.
indeed, adding only was one the alternatives suggested in , so we can try your suggestion. IMHO disabling or should not be the default, we could make them use though, would that be enough for you?
This is actually still an issue and it isn't limited to containers. Adding the params that posted, unfortunately, does not work for me ;/


Package name: Latest released version: <!-- Search your package here: --- Current version on the unstable channel: 0.37.1 Current version on the stable/release channel: 0.24.1 <!-- 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 <!-- If the result shows no maintainers, tag the person that last updated the package. -- Note for maintainers: Please tag this issue in your PR.


if a folder is a substring of another folder, we don't delete it even if we have overrideFolders and the substring id got removed from the config. Steps to reproduce the behavior: a folder with id "xxx" a folder with id "yyyzzzxxx"; folder with id "xxx" from config never gets removed folder "xxx" should have been removed after removing it from config <!-- 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.
Thanks for spotting the issue and reporting :) It sounds to me like a issue not being accurate... Maybe only the 1st commit in does the job?
yes, the first commit solves the issue with substring ids. the second commit solves the issue with ids like "hello/world". I tried escaping the id to send a DELETE request but couldn't find out how to correctly escape the / in the id
I'd never imagine someone would do that LOL. What if we'd impose a check in the module that would prevent such ids? Is it even supported upstream?
well it works in the webinterface. so it seems supported? also the default value for the id in our nixos module is the key, which also is the path. I usually do something like so all those ids are broken. as a workaround we could replace all / in the id, but that would break interaction with non nixos setups. PUTing the config seems to not have that issue. Were there any problems with PUTing the config if we want to override folders and devices anyway?
Could you perhaps give more context? I don't understand what kind of a json object is passed to the commands when you do that. I also observed in the below code that "/" are taken care of in a special way? As I in , I don't like how the code diverges in the , and it seems to me it doesn't handle the case where you want to delete a stale folder, and you don't .
yeah the PR sadly isn't complete, I just used it as a test for my local systems where I just override everything. I guess we need to handle individual overrides better, but not sure how. setting wold result in a nixos configuration of when I initially wrote this module this seemed unique enough and like a sane default. I thought about hashing the key for the id, but this would have ended in unnecessary long keys.
I see. I think that using such IDs for folders and devices is very uniqe usage... I tend towards suggesting to take the 1st commit of the PR, and a message when evaluating the script, in case the folders' IDs contain "/", and is true. However, that would not solve your particular, usage. Perhaps we can talk with upstream about it? They are rather responsive from my experience.
that sounds like an idea. I'm busy the next couple of days, but you can cherry pick the first commit from my PR and close it and we will continue with this once we have some better idea how to handle things and we maybe have an answer from upstream?


Project description Colorful, adaptive gemini browser <!-- Describe the project a little: --Metadata homepage URL: source URL: license: gpl3 platforms: linux


If you add enough (minimum number I haven't searched for) settings, then the script of applying these settings via api will not be able to execute completely and curl will generate "CSRF Error" error, this happens because syncthing resets api key after applying a certain number of settings Steps to reproduce the behavior: services.syncthing several devices and options logs of syncthing-init.service, there will be errors syncthing-init.service will execute entirely with no errors and will apply the entire configuration without errors ! I made a vm with the minimal configuration at which the error is reproduced I used nixpkgs commit Config for vm - Steps to reproduce nixpkgs - vm config - vm - vm, login as with password "CSRF Error" and parse error from jq Also during testing I managed to fix this by parsing the api key before each curl call, this helps but looks like a dirty solution <!-- 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.
Hmm indeed we recently changed a few details in the script in: I tried to write a nixos test to test some of these issues, and I experienced numerous other bugs, and I sort of reproduced the issue as well. I Reverted In: And reopened: cc .
I have this issue with (vm config, that i provided, uses this values too) So i dont think reverting will help
Could you try to merge locally and test?
I tested vanila with as patch on top. In both cases, the issue persists
OK. Thanks for the report!
As I said before, getting the api key from config before each curl call solves the problem (an example of this solution is in the patch), but I don't think it's a good solution, probably we should check the result (or/and stdout) of curl, reparsing api key if needed, call curl again, before trying to parse it with jq Patch:
I also found that to add several different devices you need to have different id's, so I tested with four devices with different id's. With my patch, all 4 devices were to correctly and syncthing-init.service ran correctly and without errors
I also found out that during my testings in . You are invited to submit that patch, with better formatting. I am also looking into finding a way to add dummy, but valid devices ID, for testings.
OK I managed to fix the test, regarding checking that the script indeed deletes devices that need to be deleted. I haven't shared it in , because I use there private (sort-of) syncthing's devices' IDs I took from my personal configuration. I'm still looking for a way to generate valid dummy devices IDs. My help request is at syncthing's forum: I also applied a better version of your patch to the (currently draft) . I plan to add many more devices to that test, and maybe do the same for folders. Then I'll also test issue . In the meantime, I'm waiting for a dummy device ID generator.
I managed to create dummy syncthing device IDs and I am using them now in my PR . I saw your PR , and I think we can concentrate our efforts together on my PR at , where I'm currently failing to reproduce your issue, your comments will be appreciated. I am testing your issue without the 2nd commit in my PR (that is identical to your commit at ), and I'm testing that is fixed by reverting commit just for testing (this works :)).


Steps to reproduce the behavior: llpp Works on 22.05 05 probably depends on insecure with:
I don't use this package, but I looked into it because why not I guess It looks like it builds if you bump the AUR patch to the latest one but only if you also include (which fixes a derivation bug but was reverted because other packages in nixpkgs have workarounds that stopped working when the bug was fixed....)
ohh, thanks for looking at this! I build it with that version of mupdf and the aur patch, and it does build fine, but I get a runtime error now if run without arguments . Still, it does seem able to open pdfs now, so it's sort of usable :p
Hmm I don't actually seem to get that error when running it without args I don't actually know how to use this program though
I'll still merge in a bit to fix build for now, but I may have gotten sniped into taking back up again and will hopefully making a staging PR today (because we really should fix that....)
Sorry! :p
Snipe is in now


only returns the hostname, even when both and are set. Steps to reproduce the behavior: and . . should return the FQDN defined by and . The breakage happens when is used, which is now the default in NixOS after Stopping causes to return the correct value. reproduces the issue. It broke at , which is when became enabled by default. It's still broken on which is at time of writing. Possibly related issues:
This seems to happen because the resolution flow (when nscd is running) looks like: calls , which uses the nodename (), which is the short hostname then calls , which invokes the nss machinery gets the request and processes the request according to the NSS rules; on my NixOS system this is (from systemd) doesn't match (from systemd) does match, and returns a synthesized record; systemd internally determines the hostname for this using only the nodename, so unless the nodename is already the FQDN then we fail here, and it does this before checking /etc/hosts. I wonder if we can fix this by patching out the support in systemd-resolved for looking up the nodename, which will make it fall back to the result from /etc/hosts instead; on NixOS we can (probably) always assume that /etc/hosts will actually have the correct system hostname in it.
No, this is most likely We wanted to polish that PR in the next days, and once merged, bump our nixpkgs pin (and resurrect the upstreaming attempts). If you want, can you check if using nsncd from this PR fixes the problem for you?
Ah, actually, I think I'm just talking out of my ass. systemd-resolved seems to be able to cope with this properly when I query it over DNS, so it probably isn't to blame.
tests fail at that PR. Setting gets a successful build, which then passes the test in , but it fails on the test.
This is a pretty weird behavior. What's (likely) failing here is the IPv6 resolution of . The test does pass on some NixOS setup, like my desktop (and the Ubuntu CI) but does fail on my laptop. I'm still not sure what's happening, is present in . There's something wrong with some NixOS setup, it'd be nice to fix that as well. By any chance, did you disable systemd-resolved? Thanks for the heads up wrt. . I'll have a look today.
The behavior I described is from the Nix build environment. I used the nixpkgs derivation for nsncd and updated the source to the PR.


Another security release for Exim: 4.96.2. See CC maintainers:
Part of the report also concerns libspf2. (For some reason, it has been filed against Exim instead...) The patch(es) should probably be cherry-picked as well onto helsinki-systems/libspf2 (the fork that we're using).


Ditto. I have noticed this accidentially whily working at . Nixpkgs version: (run ) cc
You can puts secrets in an additionnal initrd readable by root only, and use See
There is more generic option now, . We probably want to merge those.


Package name: mautrix-googlechat Latest released version: 0.5.1 <!-- Search your package here: --- Current version on the unstable channel: 0.5.0 Current version on the stable/release channel: 0.5.0 Notify maintainers Note for maintainers: Please tag this issue in your PR.
Thanks


introduced a deprecation warning for the option. Upon following the warning and moving all options out of the option and removing it, the build fails with the following error: Steps to reproduce the behavior: the service without using the option the configuration Build succeeds. As a temporary workaround, I tried setting to an empty set but then borgmatic fails to parse the config file. <!-- 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.


Attempting to upgrade to kernel v6.5.x results in the arm64 prl-tools package (18.3.0-) failing to compile. Steps to reproduce the behavior: NixOS in a Parallels VM from kernel version v6.4.x to v6.5.x nixos-rebuild to complete without error Using allows an upgrade to succeed with no tools installed. Attempting an upgrade with the unstable version of (19.0.0-) results in a similar build error. Please run and paste the result.
Just noticed a new DMG is available with Linux 6.5 mentioned in the : Not sure how to patch locally to test this.
I've already opened for that.


Steps to reproduce the behavior: , or anything depending on it (my failure specifically was triggered by udiskie). Looks like the exact same issue that is being reported in Hydra, on the same hash: Seems similar to reports that it was generated with cython 0.29.3. Unfortunately also seems to be archived and a cursory check does not seem to show a fork floating around.
Related:
Update: I was able to rebuild udiskie successfully by changing its build input (and all respective downstream references) to , so I'm guessing this might have only surfaced now with the recent cut to python 3.11 (maybe ?)
Another comment looks like . I'm guessing we could do the same here.


Package name: cardinal Latest released version: 23.10 Current version on the unstable channel: 23.09 Current version on the stable/release channel: 22.12 Notify maintainers Note for maintainers: Please tag this issue in your PR.


Vesktop opens up to a white screen. It cannot update from tray to latest version. I tried completely removing config files from Vencord but it doesn't change anything. Running Vesktop with flag --disable-gpu makes the Vesktop stuck at loading Steps to reproduce the behavior: Vesktop Launching Vesktop should open up the app normally ! Kernel: 6.5.7-xanmod1 Gpu: AMD (mesa 23.1.7)
vencorddesktop command doesn't output any logs. When doing update from the gui, it doesn't show anything. Only time it shows something is when i try updating from tray icon. The output is the following:
This is a problem with Vencord. It is currently broken with the curren versions of Discord (including the web app) We have to wait for upstream to fix these issues and release a new version of vencord
Alright, thank you for the fast response! Cheers
I encountered the same issue, and can confirm it is fixed when the system version of vencord is 1.6.0.


So, whenever I open Player, it starts installing Roblox, finishes, and does nothing. Even when launched from the website, starts installing, finishes, and most likely just exits. Logs show nothing important. However, when trying open Studio, the error saying " not found". Steps to reproduce the behavior: the grapejuice package (just write grapejuice in the with pkgs section) wine-wayland package (not sure if it is required, however I did) Grapejuice (I used rofi (drun), but I suppose $ would work) the message box that pops out (from wine), press "Install" to install the wine-mono thingy press the Open RobloxPlayer button, or go into Player, Initialize and Install Roblox, the behavior is the same Roblox installing and doing nothing... I expected RobloxPlayer to actually open, not install and exit... <!-- --
This is already tracked in issue


I'm trying to use from nixpkgs on my laptop and use remote builders (buildbarn). This fails due to patches that are applied in nixpkgs. Vanilla Bazel has a hardcoded fallback path for bash () . This has the downside of not producing a working fallback for (bash from nixpkgs will default initialize as ). The workaround for this is to default initialize the path variables somewhere else. Currently, this is done . This works fine for local execution, since this is where this function is called. However, this function is never called for remote execution (it is a hack to override things for the local execution environment only). So when using Bazel from nixpkgs locally and enabling remote execution, the shell is set to a bash from nixpkgs during the analysis phase but the variable is explicitly left unset by many actions, leading to the PATH in bash being and resulting in errors when executing tools in a script. I think there are two possible solutions: when using remote execution, do not replace the hardcoded (this is probably not a great fix since it only works for FHS executors) instead of replacing with a regular bash from nixpkgs, add a little helper script that adds shell utils to . This way, any shell rule created by bazel has a minimal set of tools. use when turning on remote execution. This has the downside of only working when the remote builder has a shell in that path. See this for a detailed reproducer: Using bazel from nixpkgs should work with remote execution. Using this version of bazel with remote execution is becoming more viable due to <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- [^1]: [^2]:
got reverted, I'll reopen it.
Could we also remove the related patch here -, or is it still needed for some reason ?
To the best of my understanding, it should be sufficient to use a prepared bash (with tools in the PATH) and remove the patch you mentioned. Probably still a good idea to test this in practice!


Building the python 3 protobuf package fails for me on macOS. Digging in (by launching ), the cause seems to be that calls instead of . The call above fails, but the same call works after replacing by . Similarly, works fine. That in turn matters because of in the / wrappers, because the system include path is missing in the case. System: mac OS 10.12.5 Nix version: nix-env (Nix) 1.11.8 Nixpkgs version: "17.09pre108299." Sandboxing enabled: grep: No such file or directory :) When digging in, I used a checkout of nixpkgs with hash , but it seems to make no difference.
seems related.
uses Python on Darwin and might help here.
I've had a look at the python setup tools: The relevant line is (rather: appears to be, I haven't tested this) which causes C++ source files to be compile with . Not sure whether this is the right or wrong thing to do... I see two reasonable ways to fix this bug, in a more principled way than : python distutils to compile C++ files using nixpkg to treat like with respect to and friends If 1. is the right thing to do, it might still be nice to work around the bug in another way for now.
I've also been bitten by this problem once: The core problem is that setuptools pretty much ignores the difference between CC and CXX. This however is not a problem on a standard mac xcode installation, as both and link the C++ standard library there. However our nix-clang does not link against the C++ standard library (and probably should not) and that's why you will encounter this problem every once in a while when dealing with darwin and c++ python extensions. I'm not an expert on the darwin-stdenv, so I wouldn't know how to fix this in a way that does not require hacking our ways around that problem. To hack around this problem you simply have to grep the pythonPackages for . There are a few packages that use a workaround that involves adding to the C-compile flags: See e.g. here:
However our nix-clang does not link against the C++ standard library (and probably should not) and that's why you will encounter this problem every once in a while when dealing with darwin and c++ python extensions. any clue how to solve this issue?
The problem does not seem all-too widespread, but there are a few instances:
Any reason we can't just change to use ? Seems like it would work on Linux just fine, and fix a bunch of other stuff.
I knew this was an issue in general (), but assumed the problem was something more complicated.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


Project description Gruvbox Plus icon pack for Linux desktops based on Gruvbox color theme. Metadata homepage URL: source URL: license: GPL-3.0 platforms: linux


Currently we build with support for . Sonnet typically looks in for dictionaries That means it won't be able to find any dictionaries and thus spellchecking won't work.
Is this still a problem? It seems that hunspell paths are not hardcoded in hunspelldict.h anymore: But they are still hardcoded in
Yes, this is still a problem. It seems like we should disable hunspell and use aspell, which is configured correctly in NixOS.
I marked this as stale due to inactivity. →
I marked this with "good first bug" because I think we need only to change to depend on , and do some testing.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


Lily and I talked about this in Matrix, this is the requested issue. Basically it all narrows down to this package lock: Steps to reproduce the behavior: it it hangs forever lock it works It should either give an error or just work. If it helps narrowing the npm version down, the package- was created in September of 2020 and was last changed in September of 2021.
To clarify a bit, this isn't something specific to older lockfiles, it just looks like there is a version spec format that our fetcher does not currently support, but probably should


Package name: gdtoolkit Latest released version: 4.1.0 <!-- Search your package here: --- Current version on the unstable channel: 3.3.1 Current version on the stable/release channel: 3.3.1 <!-- 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 It's a bit of an odd situation because both Godot 3 and 4 are in use, so maybe this one should be renamed to gdtoolkit3 or the opposite for the time being. Haven't had any success yet trying to override the package on my own. <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR.


Package name: gitea Latest released version: 1.21.1 () <!-- Search your package here: --- Current version on the unstable channel: 1.20.5 Current version on the stable/release channel: 1.19.4 <!-- 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: <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR.
thanks. I've created:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


ssh2john produce error while trying to process ssh key Steps to reproduce the behavior: john in any way - ssh key with password - KALI: Please run and paste the result.
This seems like an upstream issue. See
This issue 2 years long! Can we bundle older python with john or apply workaround stated in mentioned issue?
In the meantime, I believe you should be able to work around this by overriding the python version locally:


Package name: handbrake Latest released version: 1.7.3 Current version on the unstable channel: 1.6.1 Current version on the stable/release channel: 1.6.1 Notify maintainers Note for maintainers: Please tag this issue in your PR.
Revised to 1.7.2 release
Revised to 1.7.3


Hi there I installed but the driver is not available on CUPS; the printer (Brother HL-1223WE) is detected correctly. My system is on . Steps to reproduce the behavior: to to add the printer on CUPS.
Submitted a with a fix for this issue.


Package name: vcv-rack Latest released version: 2.4.1 Current version on the unstable channel: 2.4.0 Current version on the stable/release channel: 2.3.0 Notify maintainers Note for maintainers: Please tag this issue in your PR. Priorities Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
may be trying something with so I'll wait a bit
Honestly I have no idea what vcv-rack is, I just looked for a package I can update to test out a new feature for `nix-update. If you can, take this from from, feel free to update it.
Not sure if I'll have time in the next few weeks, so this is free to pick


Building on macOS fails in the test phase, since the path to the nix-daemon's socket is longer than the maximum 108 characters. This is a combination of macOS (long TMPDIR set to the build directory). I'm not really sure whether this is more of a nixpkgs or a nix issue. The problem can be worked around by setting TMPDIR=/tmp manually, but it seems to me that that should not be required... Compare nix commit , which removed a workaround for this limitation. System: Darwin 16.6.0 Nix version: 1.11.11 (building nix-1.12pre5413_b4b1f452) Nixpkgs version: master as of 2017-07-04 Sandboxing enabled: no


Project description 'cp' and 'mv' utilities with progress bar patches The utilize it (flag -r) to show cp, mv progress. Advanced Copy is a mod for the GNU cp and GNU mv tools which adds a progress bar and provides some info on what's going on. It was written by Florian Zwicke and released under the GPL. This repository exists because the website appears to be dead. You can still find it via the . More info: Metadata homepage URL: source URL: license: GPL platforms: unix, linux Priorities Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The after running the in the advcpmv repo would be and need the binary with name and for the flag -r to work. So symlink and to and respectively.
It is a patch against coreutils, basically?
Yes
On a hand, it can simply be treated as a , or even better, a NUR-like overlay. On the other hand, coreutils is a core (pun not intended) package for Nixpkgs, a dependency for things from fetchers to stdenvs. Modifying it has the potential to be a mass-rebuiding mess. Indeed, patches for coreutils should be "vendored". Let's try.
Sorry I am so new to Nix and NixOS (2 weeks usage), I don't even know it would mess things up. I don't know much about , isn't it just permanently modify and in place? I have learned something about writing a derivation this week, and here is the .nix file I am using and work just fine for me:
Nix is source-based - it builds the binaries (and artifacts in general) from the sources. Think like picking Archlinux but from the PKGBUILDS. Despite being source-based, Nix can rely on local and remote binary caches to speedup the building. Certainly, when a package source is updated, its old entry in the cache is invalidated and the new version is put in its place. For an application like, say, Zsnes emulator, it affects only Zsnes. On the other, for a library like, say, SDL, its update invalidates SDL and everything that uses SDL - zsnes, bochs, frets-on-fire, dosbox, mednafen... the list is huge. And it applies to everything, from the core utilities like coreutils to desktops like XFCE. provides a better visual analogy.
Thanks for explaining it to me. I think it would be better not touching those basic packages.
I have tried this and it worked: Now I am thinking if it's better to put this in my (future) NUR overlay or in the main Nixpkgs.
I think that this issue should stay open because it is not necessary to edit the coreutils packaged in nix. One can just make another package that only includes advcpmv commands like arch does:
The problem is that advcpmv is a patch that modifies only cp and mv, while coreutils has a truckload of extra commands. It can cause conflicts with existing packages.
I just tried to rebuild my config(was working before), got: What's the suggested resolution here?
From this it seems like, the only way out is to not use this package anymore? It's an dependency to some nnn file browser feature. I'll look for alternatives for it.
Two weeks ago . If you are interested in keeping advcpmv - and receiving because "it will break the world" in a future update of Coreutils -, feel free to pick it.


Project description OpenJDK 22 was released on 19-MAR-2024. The OpenJDK project has been releasing Early Access (EA) binaries for many months now. It would be nice to be able to install OpenJDK 22 as a Nix package and also to begin development of dependent Nix packages (e.g. ) Metadata homepage URL: source URL: (update: is open now) license: GPL with Classpath Exception platforms: unix, linux, darwin, others I'm fairly new to Nix (but loving it so far) so I'm not 100% sure this whether this should be a "new package request" (as Nix keeps multiple versions of OpenJDK available as different packages) or a "package update request" (since jdk22 is an updated version of jdk21.) If I need to change this or anything else in the issue please let me know and I will try to fix it.


As of today, this search yields 3 items for Corretto. The "Source"-buttons for some of them point to OpenJDK even though the package is Corretto. Corretto has been and is based on the corresponding OpenJDK version (using ). At a first glance, the the usage of looks like the issue. However, when searching for , the "Source"-button for correctly points to eventhough the latter also uses .
Transferred to nixpkgs as nixos-search just uses , which is determined by in . I am not sure what is going on here exactly, but note that does seem to have the correct position.
:arrow_up: I left some context in the mentioned above. I realize that the actual problem is , i.e. the OpenJDK derivations define their and these get inherited then.


Steps to reproduce the behavior: type: I have none. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Context: caused because last supported version for 3.0.0 is llvm 15: Should be easy enough to fix, thanks for reporting.


Maybe related to build from master branch - Hope you don't mind the ping, sorry if you do Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I can't reproduce this. What does give for you?
My bad in naming the PR, the package does build but the man output of it points to broken symlink I am building on master branch, commit system x86_64-linux.
With some trial and error I was able to pin point the commit which broke it That was merged in See here my build log


It looks like , so the program crashes on every run. See . No crash. system: host os: multi-user?: sandbox: version: channels(root): channels(username): nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Apparmour service doesn't reload correctly after a system switch. Steps to reproduce the behavior: anything in config with apparmor enabled nixos-rebuild switch error of apparmor service failing to restart No error, apparmor starting as it should Here my service log: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I'm encountering the exact same error here.
Same issue here
Same for the issues after . However do a after that just fine.
Someone once told me that the state of AA in NixOS wasn't great. But I don't know first hand. Could be wrong. I lack any knowledge at all to even figure out the root cause of the issue. :/
AA seems to work fine in general. Just the service restart after a nixos-rebuild doesn't work.
Tested just now on nixos-23.11. AppArmor service restarts without any issues after nixos-rebuild. I think this issue is resolved.
Reopening this issue as unresolved. Currently on 24.05.. and this issue seems to be persisting after a nixos-rebuild: reloading the following units: apparmor.service, dbus.service Job for apparmor.service failed. See "systemctl status apparmor.service" and "journalctl -xeu apparmor.service" for details.
I did some more investigation on this. I have one system with a custom apparmor profile and another system with no profiles. On the system I have with a custom apparmor profile, nixos-rebuild works fine. On the other system without any apparmor profiles, nixos-rebuild fails with the message in this bug report. After nixos-rebuild, journalctl reports: In I tried running "sudo aa-remove-unknown" from zsh: The error message matches what is in the system log. I think this may be related to the aa-remove-unknown step.
As a workaround, adding this to appears to work: After this, the first nixos-rebuild switch will still cause the issue (because the profile is not installed yet). But on the second and subsequent nixos-rebuilds, there is no error message on my system. Can someone else try it and see if it works on their system too? If so, it may help to figure out the proper solution.
I tried it and it actually rebuilds without error the first time too. Hopefully that helps you or someone else figure out a permanent fix! Many thanks.
From my side the issue seems to be be fixed with the merged fixes. So I will close the issue.
If anyone wants to track the merger of the fix :


Steps to reproduce the behavior: obs-studio Please run and paste the result.
Couple things: 23.05 will be EOL soon, just a heads up the rev as specified in your "host os" line of the output, it pulls from the cache. I can only assume you're using a different rev or some override/overlay. Even rebuilding from that rev in my case produces no errors. Can you provide a config to reproduce?
My config is here: I am not using any override/overlay, afaik...
Setting is causing some massive rebuilds on your end and likely causing the breakage here. That's also why it couldn't just fetch from the binary cache. Try without this line.
Though FWIW, I'll see if I can get the build working with , it probably shouldn't just break.


Mathematica fails to start. .... System: NixOS: 17.03.1517. (Gorilla) Nix version: 1.11.11 Nixpkgs version: 17.03.1517. Sandboxing enabled: no
Similar issue in .


Package name: Latest released version: 5.1.1 <!-- Search your package here: --- Current version on the unstable channel: 5.0.3 Current version on the stable/release channel: 5.0.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! --- 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]:
Version 5.1.0 fixed compatibility of this extension with PHP 8.3, so the current version 5.0.3 is unusable with PHP 8.3. It outputs these build warnings/errors
Could you please provide the PR to update this? I think it's a matter of changing 2 lines. Actually, creating the PR would have been faster than creating this issue :)


They apparently fixed the issue where the cursor wouldn’t show up in new tabs. Needs backport to 23.11. Thanks! Package name: vte Latest released version: 0.74.2 Current version on the unstable channel: 0.74.1 Current version on the stable/release channel: 0.74.1 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]:


Add vulkan-tools-lunarg to a devshell and see that the only executable it provides is vkvia. It should also at least build and provice vkconfig Steps to reproduce the behavior: vulkan-tools-lunarg to a devshell to execute vkconfig to debug your vulkan application that it is not found in your path I expected vkconfig to be built and included in the vulkan-tools-lunarg derivation


The file seems to be randomly edited by committers who feel like doing so, thereby ignoring data protection laws governing some regions where our contributors come from (e.g. , , as of before the force-push) guidelines our community gave to itself (e.g. , ). Having our community guidelines ignored at random lets NixOS look unprofessional and can scare away contributors and supporters. Having data protection laws ignored might even lead to expensive liabilities for the NixOS foundation, meaning that the money would be missing when paying for servers or incentivizing contributors. Therefore, there should be some QA when editing that file. A straightforward suggestion regarding this would be to install one or more maintainers for that file itself. These would have to review any PRs touching it before merging would be allowed. The maintainers should provide evidence that they are aware of laws governing personal data in the different jurisdictions we work with, and aware of our community guidelines. commits happening where laws and/or community guidelines are being ignored Not applicable.
Hi, on GitHub and more specifically the nixpkgs repo we almost exclusively handle the technical side of things, so keeping moderation and foundation related discussions low would be greatly appreciated (yes there is some exceptions). We have for general commmunity disscusion. I generally understand your issue, and I'm fearly certian that the foundation takes gdpr serious, and if you actually want to send a gdpr deletion request send it to one of the listed contact methods on If you have a problem with the way someone in a nix* project bevhaves then please message one of the mods privatley or report it in the matrix room. Please keep in mind that Nix, NixOS, Nixpkgs and almost any other Project under the foundations hat are community first Projects and most people particpating do so in there spare time. And that the way you are currently behaving comes across quite childish. And you might also want to note that your github handle, even if we don't track it in the maintainers file, still ends up in the git history anyways because github puts it in the commit messages of pr merges, so not having it in the list basically doesn't matter. The point aobut Lack of QA for changes to maintainers/maintainer- might be valid and if you want to persue the issue I would suggest you do a discourse post to raise awrness and try to convince one or two well-known community mebers to put them selfs as code owners for the file.
Let's please keep this scoped towards only discussing a QA process for the maintainers file, and not go into other points of disagreement from the issues that sparked this discussion. Proposal in .
Seems like the default mechanisms for maintainers who get pinged on file changes won't work well here. Most commits are probably contributors adding themselves to the file. If we assume that the TOFU model works for these, only exceptional commits would have to be checked manually, thereby reducing the workload. But this would require a smarter ...
Well, the maintainer list is currently maintained in code, so the platform where the repository resides should be an appropriate place to discuss how that's done. Of course, one might argue that this is a mistake in the first place considering the unclear situation regarding how to comply with the GDPR with such a setup. If we go that route, then yes, maintenance of the list should also be discussed somewhere else.


I'm working on upgrading our work repository to 23.11 and am running into an issue building a docker image with . There derivation is: This works with nix 22.05, but fails with nix 23.11 with the following error: Steps to reproduce the behavior: nix 23.11, try to build the above image The image builds and we can set ownership of files in the image n/a n/a Please run and paste the result. Also, we are running branch: , commit
I tested this a bit. I can change the permissions on the directory as long as I don't reference the unknown user .
Are you sure you were actually able to chown before hand or was chown simply ignored? It shouldn't be possible in the build sandbox regardless of what tools you preload.
As you can see here the chown becomes a no-op: If you would suggest to delete those chown commands, they do not have any effect. We replaced fakeroot and proot with just proot, since proot also can set the uid/gid to root and the combination was breaking things. You can still prepend fakeroot manually but except if you rely on third-party scripts to run without errors.
Ah okay, the idea was to try to ensure the files were owned by the UID that our CI user (outside of the container) uses, so that any file modifications done to volume mounts wouldn't make the files unreadable by CI. It's possible it wasn't actually needed and/or is vestigial. I guess it's a new version of chown that's causing the issue in 23.11? Thanks for the feedback!
No. We dropped fakechroot when proot already is enabled as it was causing issues. The chown program was still the same.
in is included as an example in :
It doesn't seem like the is actually a no-op, either, in previous versions. We wind up with permissions issues in CI when we remove the calls, and we're struggling to figure out a way to ensure the directories within the container have the expected user IDs in order to be compatible with bind-mounting volumes as the CI user.
If you are able to change filesystem owner/groups without having root, I would like to know how because that sounds like a kernel security vulnerability to me. If you do need to chown, you have to do this at container start.
I'm not sure I follow. Previously, we were able to use within the docker build process to set the ownership of directories within the resulting container image. That was useful, because we could set the UID of necessary directories to the UID of the CI user. For reference, this is essentially the derivation we are working with: On Nix 22.05, this works, and the results look as you'd expect after running & then running bash on the container: For 23.11, this is the full build output with the error: <details<summaryError Output</summary<pre nix log /nix/store/in5pqapmv1h5q94n4sj961aw5z101vqy-replication-customisation- | cat /nix/store/ffrva7icr8ws2d51955jy302icgmr80s-util-linux-2.39.2-bin/bin: login: /nix/store/8d4v7wcr31xh2zh6kcyxnd94r0n8byy6-shadow-4.14.2/bin/login kill: coreutils chfn: /nix/store/8d4v7wcr31xh2zh6kcyxnd94r0n8byy6-shadow-4.14.2/bin/chfn nologin: /nix/store/8d4v7wcr31xh2zh6kcyxnd94r0n8byy6-shadow-4.14.2/bin/nologin chsh: /nix/store/8d4v7wcr31xh2zh6kcyxnd94r0n8byy6-shadow-4.14.2/bin/chsh +++ mkdir -p tmp src cargo +++ mkdir -p usr/bin +++ ln -s /nix/store/m38gwq0w8w7qyjn9s00balyp7cv3m5p9-coreutils-9.3/bin/env usr/bin/env +++ mkdir -p etc +++ touch etc/group proot warning: can't sanitize binding "/sys/": No such file or directory proot warning: can't sanitize binding "/nix/store/q8494z25m447skzy6l4ccyw84nqfcnja-replication-customisation-": No such file or directory ++ export PATH=/nix/store/8d4v7wcr31xh2zh6kcyxnd94r0n8byy6-shadow-4.14.2/bin:/nix/store/rvdryxhd9zw6zz7fwwxi6ma55qnblpi8-fakeroot-1.29/bin:/nix/store/811m6jpxyxzhff2wy27xx5r81bqs1dzk-proot-5.4.0/bin:/nix/store/h3ayxf5dk1gdf3s5716fh1ys815qxxag-patchelf-0.15.0/bin:/nix/store/m38gwq0w8w7qyjn9s00balyp7cv3m5p9-coreutils-9.3/bin:/nix/store/01znf87kiw5xx1dj0f7djrnrbg84ij28-findutils-4.9.0/bin:/nix/store/vq4vmndw555m7ld2bi6pq8kr348qvb6a-diffutils-3.10/bin:/nix/store/rwa7qyds01qzxvq7zq3kgnkrzzpw4s66-gnused-4.9/bin:/nix/store/n062zcsmfl9gfp6vfkcg0asb8jjwmy5i-gnugrep-3.11/bin:/nix/store/4v7m4yx07b3anmbznfhihjc8xiizyna9-gawk-5.2.2/bin:/nix/store/mi3pm67ps7c7k11aqki9182ygzg8j503-gnutar-1.35/bin:/nix/store/5c0ancqnpi0cf1h49mv13w68a950s9z0-gzip-1.13/bin:/nix/store/q5cv7r1sh3s4niyq7vm6h1j74394naxs-bzip2-1.0.8-bin/bin:/nix/store/bh7sbl99ygfvw9w96936nrhw46jmcmqq-gnumake-4.4.1/bin:/nix/store/7dpxg7ki7g8ynkdwcqf493p2x8divb4i-bash-5.2-p15/bin:/nix/store/mbh9gx43gsc5av019vsdkazbyiic3f0f-patch-2.7.6/bin:/nix/store/3q6fnwcm677l1q60vkhcf9m1gxhv83jm-xz-5.4.4-bin/bin:/nix/store/a5s2dmba16pw8l52f496gw0b7nli7mbn-file-5.45/bin ++ PATH=/nix/store/8d4v7wcr31xh2zh6kcyxnd94r0n8byy6-shadow-4.14.2/bin:/nix/store/rvdryxhd9zw6zz7fwwxi6ma55qnblpi8-fakeroot-1.29/bin:/nix/store/811m6jpxyxzhff2wy27xx5r81bqs1dzk-proot-5.4.0/bin:/nix/store/h3ayxf5dk1gdf3s5716fh1ys815qxxag-patchelf-0.15.0/bin:/nix/store/m38gwq0w8w7qyjn9s00balyp7cv3m5p9-coreutils-9.3/bin:/nix/store/01znf87kiw5xx1dj0f7djrnrbg84ij28-findutils-4.9.0/bin:/nix/store/vq4vmndw555m7ld2bi6pq8kr348qvb6a-diffutils-3.10/bin:/nix/store/rwa7qyds01qzxvq7zq3kgnkrzzpw4s66-gnused-4.9/bin:/nix/store/n062zcsmfl9gfp6vfkcg0asb8jjwmy5i-gnugrep-3.11/bin:/nix/store/4v7m4yx07b3anmbznfhihjc8xiizyna9-gawk-5.2.2/bin:/nix/store/mi3pm67ps7c7k11aqki9182ygzg8j503-gnutar-1.35/bin:/nix/store/5c0ancqnpi0cf1h49mv13w68a950s9z0-gzip-1.13/bin:/nix/store/q5cv7r1sh3s4niyq7vm6h1j74394naxs-bzip2-1.0.8-bin/bin:/nix/store/bh7sbl99ygfvw9w96936nrhw46jmcmqq-gnumake-4.4.1/bin:/nix/store/7dpxg7ki7g8ynkdwcqf493p2x8divb4i-bash-5.2-p15/bin:/nix/store/mbh9gx43gsc5av019vsdkazbyiic3f0f-patch-2.7.6/bin:/nix/store/3q6fnwcm677l1q60vkhcf9m1gxhv83jm-xz-5.4.4-bin/bin:/nix/store/a5s2dmba16pw8l52f496gw0b7nli7mbn-file-5.45/bin ++ mkdir -p /etc/pam.d ++ [[ ! -f /etc/passwd ]] ++ echo root:x:0:0::/root:/nix/store/7dpxg7ki7g8ynkdwcqf493p2x8divb4i-bash-5.2-p15/bin/bash ++ echo 'root:!x:::::::' ++ [[ ! -f /etc/group ]] ++ [[ ! -f /etc/pam.d/other ]] ++ cat ++ [[ ! -f ]] ++ echo nixbld:x:999: ++ echo root:x:0: +++ seq 1 10 ++ for n in $(seq 1 10) +++ command -v nologin ++ useradd -c 'Nix build user 1' -d /var/empty -g nixbld -G nixbld -M -N -r -s /nix/store/8d4v7wcr31xh2zh6kcyxnd94r0n8byy6-shadow-4.14.2/bin/nologin nixbld1 ++ for n in $(seq 1 10) +++ command -v nologin ++ useradd -c 'Nix build user 2' -d /var/empty -g nixbld -G nixbld -M -N -r -s /nix/store/8d4v7wcr31xh2zh6kcyxnd94r0n8byy6-shadow-4.14.2/bin/nologin nixbld2 ++ for n in $(seq 1 10) +++ command -v nologin ++ useradd -c 'Nix build user 3' -d /var/empty -g nixbld -G nixbld -M -N -r -s /nix/store/8d4v7wcr31xh2zh6kcyxnd94r0n8byy6-shadow-4.14.2/bin/nologin nixbld3 ++ for n in $(seq 1 10) +++ command -v nologin ++ useradd -c 'Nix build user 4' -d /var/empty -g nixbld -G nixbld -M -N -r -s /nix/store/8d4v7wcr31xh2zh6kcyxnd94r0n8byy6-shadow-4.14.2/bin/nologin nixbld4 ++ for n in $(seq 1 10) +++ command -v nologin ++ useradd -c 'Nix build user 5' -d /var/empty -g nixbld -G nixbld -M -N -r -s /nix/store/8d4v7wcr31xh2zh6kcyxnd94r0n8byy6-shadow-4.14.2/bin/nologin nixbld5 ++ for n in $(seq 1 10) +++ command -v nologin ++ useradd -c 'Nix build user 6' -d /var/empty -g nixbld -G nixbld -M -N -r -s /nix/store/8d4v7wcr31xh2zh6kcyxnd94r0n8byy6-shadow-4.14.2/bin/nologin nixbld6 ++ for n in $(seq 1 10) +++ command -v nologin ++ useradd -c 'Nix build user 7' -d /var/empty -g nixbld -G nixbld -M -N -r -s /nix/store/8d4v7wcr31xh2zh6kcyxnd94r0n8byy6-shadow-4.14.2/bin/nologin nixbld7 ++ for n in $(seq 1 10) +++ command -v nologin ++ useradd -c 'Nix build user 8' -d /var/empty -g nixbld -G nixbld -M -N -r -s /nix/store/8d4v7wcr31xh2zh6kcyxnd94r0n8byy6-shadow-4.14.2/bin/nologin nixbld8 ++ for n in $(seq 1 10) +++ command -v nologin ++ useradd -c 'Nix build user 9' -d /var/empty -g nixbld -G nixbld -M -N -r -s /nix/store/8d4v7wcr31xh2zh6kcyxnd94r0n8byy6-shadow-4.14.2/bin/nologin nixbld9 ++ for n in $(seq 1 10) +++ command -v nologin ++ useradd -c 'Nix build user 10' -d /var/empty -g nixbld -G nixbld -M -N -r -s /nix/store/8d4v7wcr31xh2zh6kcyxnd94r0n8byy6-shadow-4.14.2/bin/nologin nixbld10 ++ mkdir -p /home ++ useradd -c 'ci user' --home-dir /home/ci --uid 1001 --groups nixbld,root --create-home ci Creating mailbox file: No such file or directory ++ cat /etc/group nixbld:x:999:nixbld1,nixbld2,nixbld3,nixbld4,nixbld5,nixbld6,nixbld7,nixbld8,nixbld9,nixbld10,ci root:x:0:ci ci:!:1001: ++ chown -R 1001:root /src chown: changing ownership of '/src': Invalid argument exitHandler exitCode=1 set +e '[' -n '' ']' (( 1 != 0 )) runHook failureHook local hookName=failureHook shift local 'hooksSlice=failureHooks[ local hook for hook in "callImplicitHook 0 {!hooksSlice+"${!hooksSlice}"} eval 'callImplicitHook 0 failureHook' declare -F 'callImplicitHook 0 failureHook' eval 'callImplicitHook 0 failureHook' ++ callImplicitHook 0 failureHook ++ local def=0 ++ local hookName=failureHook ++ declare -F failureHook ++ type -p failureHook ++ '[' -n '' ']' ++ return 0 return 0 '[' -n '' ']' return 1 </pre</detailsIf I remove the chowns, everything in the container is owned by root, as you'd expect, but this leads to various issues in our CI process with bind-mounted directories. Is there no way to change the ownership of directories during the container build process?
Looks like I misunderstood how fakeroot works. It records those permissions between different programs and can replace them for the tar program:
Just adding the state of the directories when running the above without the chowns in 23.11. Note that the CI user doesn't even wind up owning its home directory created by . The user does exist, and I can things interactively in this bash shell as root. However, we don't run the container as root during the CI build for a few reasons, including that it needs to run postgres, which won't run as root.
This might be a better fix than: Feel free to open a pull request if it fixes your use case.
I'll pull down nixpkgs and give this a shot, thanks!
That does indeed seem to fix it! I'll open an MR now
Created , still cloning stuff to run the review suite locally


Steps to reproduce the behavior: stig I got this when switching from 23.05 to 23.11 system: host os: multi-user?: sandbox: version: channels(root): channels(ao): nixpkgs:
Thanks for the report, this is supposed to be fixed in . I will wait for Darwin CI to be green there and merge it. Ping me if I forget. Follow that PR at:
Great, thanks!


Steps to reproduce the behavior: cryptowatch-desktop download url redirects to a blog Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
As of September the 30th 2023, Cryptowatch was sunset and users were advised to use their parent companies offering Kraken Pro. I'll create a pull request to remove cryptowatch from nixpkgs as there aren't any archives available that contain it that are reliable


While working on some documentation on Nixpkgs, I noticed that there doesn't seem to be a convention for showing shell commands and their outputs. prepends to the command prompt, and output as a normal, not-indented line. adds a comment above the command prompt showing what the output is. uses two different code blocks, one with the command, the other with the output. Additionally, there are other code blocks to show expressions and their result inside the nix repl: prepends to the (error) output. And prepends to the output. Note that the proposal below was written just to have some starting proposal, but not much thought has been given to other alternatives yet. My current proposal is to adopt the following convention: For shell commands and outputs, prepend to any lines that are part of the command, and put outputs in their own lines as-is. If the command has line continuations, don't prepend , but add some indentation to keep it from looking like an output. For example: For nix repl expressions, prepend to any lines part of an expression, and put outputs in their own lines as-is. <!-- make sure this issue is not redundant or obsolete --- [x] checked [latest Nixpkgs manual] ([source][nixpkgs-source]) and [latest NixOS manual] ([source][nixos-source]) [x] checked [open documentation issues] for possible duplicates [x] checked [open documentation pull requests] for possible solutions [latest Nixpkgs manual]: [latest NixOS manual]: [nixpkgs-source]: [nixos-source]: [open documentation issues]: [open documentation pull requests]: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Talked about this in the docs team meeting, I think this is a good idea! If you make a PR to describe this convention in the I could review/merge it. I guess very generally, the convention is to use the format as you'd see it in the REPL.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


Project description A tool to help efficiently focus windows in Sway inspired by i3-easyfocus: basically you press a key and hints ("q", "w", ...) popup on the titlebars, you can then press "q" to focus the window matching the "q" key. Metadata homepage URL: source URL: license: mit platforms: linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


DaVinci Resolve Studio is missing a entry for application launchers Steps to reproduce the behavior: should contain a entry for application launchers If applicable, add screenshots to help explain your problem. Add any other context about the problem here. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
See


New version of the invidious module gives an error on old system state versions with the following message: Config option doesn’t seem to exist and doesn’t do anything when set. Manually setting gets config to build, but service still doesn’t start with permission error, even after running the suggested reassign command: database seems to be correctly owned by the user: Steps to reproduce the behavior: invidious with local database on system state before 24.05: an error message, try to perform suggested fix. Find out that the suggested setting doesn’t exist and use instead: as suggested by the error message. to start . permission error. Service should successfully start after applying suggested fixes. Error message shouldn’t refer to non-existent options. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The correct configuration should look like this if your state version is before 24.05: Looks like there is a mistake in the error message ( and are both specified and only the former is correct). Can you please try again with set to ?
Yes, I’ve tried this (steps 2+ of reproduction). I’ve mistakenly wrote in my initial issue, sorry, I’ve tried setting . It gets config to build, but it doesn’t start with the error described in the first post. I’ll amend the issue text now.
Can you show us the output of
Sure! I see the problem now. I’ve tried to run the command without selecting the database first. After running it with database selected, service starts successfully. Thanks!
Super. Can you please look at the PR and tell me if the improved language would have solved your issue?
Yeah, thanks, that would’ve been clear!


labwc-tweaks failes to start no matter what I do I get this error message if I try to open it in terminal: Error opening file: No such file or directory Run labwc-tweaks in the terminal labwc-tweaks starting Please run and paste the result. these 4 paths will be fetched (0.03 MiB download, 0.17 MiB unpacked): /nix/store/1alqjnr40dsk7cl15l5sn5y2zdxidc1v-binutils-wrapper-2.40 /nix/store/4dr83a4wn25zkb5pvsq2y3q3v586jzs9-expand-response-params /nix/store/90h6k8ylkgn81k10190v5c9ldyjpzgl9-gcc-wrapper-12.3.0 /nix/store/wr08yanv2bjrphhi5aai12hf2qz5kvic-stdenv-linux copying path '/nix/store/4dr83a4wn25zkb5pvsq2y3q3v586jzs9-expand-response-params' from ''... copying path '/nix/store/1alqjnr40dsk7cl15l5sn5y2zdxidc1v-binutils-wrapper-2.40' from ''... copying path '/nix/store/90h6k8ylkgn81k10190v5c9ldyjpzgl9-gcc-wrapper-12.3.0' from ''... copying path '/nix/store/wr08yanv2bjrphhi5aai12hf2qz5kvic-stdenv-linux' from ''... system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The issue might be related to this hard coded path: it seems like that xkeyboard_config provides this file
Until recently the keyboard related files were available in . Fixed in


Project description Command line program which provides a suite of tools to create shopping lists and maintain recipes. Metadata homepage URL: source URL: license: mit platforms: linux, darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
A nix-shell script here () which provides a decent starting point. cc


Package name: solana-cli Latest released version: 1.16.27 <!-- Search your package here: --- Current version on the unstable channel: 1.14.23 Current version on the stable/release channel: 1.14.23 <!-- 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 <!-- 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]:
Hello I was able make the building script work so solana-cli is updated to 1.16.27 expect solana has bug in a which doesn't let me compile. The issue was already reported back back in 22 november 2023: solana-labs/solana So until is fixed I can't do anything more, as soon as it is fixed I will post my pr
Thanks , did you manage to build it for the current version? () On the master of nixpkgs I couldn't even build the existing version of Solana due a rocksdb issue I also found this commit on homebrew PRs. Seems like they patched this part in order to make the build work:
Hello I didn't test it and I don't think I need since I made it able to compile 1.16.27 I appreciate the citation, with the patch used by them I was able to fix it, appreciate your help


Optipng crashes with a segmentation fault on current as of . points to the library used to throw/catch exceptions. relevant source: Automatic points to being the first bad revision. However, I don't have enough knowledge of this piece of nix to understand why it causes optipng to fail in the . System: nixos-master Nix version: 1.11.11 Nixpkgs version: Sandboxing enabled: yes CC
Reading into the causing commit's comments made me try which seems to work around the issue. However, I'm hesitant to commit this as a fix without understanding the issue here.
So some packages use the C compiler instead of linker directly to link. Nixpkgs's cc-wrapper is aware of this, for example, with separate and environment variables. Classic make builtin rules however only have , , , and , so then either in a configure script or make itself they seem to default to , but manually specifying breaks this. Manually specifying , however, avoids that pitfall, and, unlike , will also work for cross compilation.
Here's a blurb from optipng's script: If I understand your comment, it looks like optipng's build system is doing precisely what you describe: So when isn't set, it defaults to configuring the such that it uses as the linker, and I suppose the theory is that they depend on behavior available when invoking through e.g. (though I don't know precisely what that may be). It would seem reasonable take the (on a per package basis) approach as a solution. I think this can safely be considered a bug in the upstream packages' build systems.
Probably the use of to pass actual ld flags, e.g. .
I implemented the workaround in . Feel free to reopen this if you don't think the fix to be adequate.


I would absolutely love for somebody to package up :)
will attempt to reserve some time to give it a try in the next days :-)
I created a first working version which compiles on my machine ( ): Unfortunately I had to use an older revision since the latest revisions require language features from Rust 1.19 and I'll have to bump it in nixpkgs before using the latest revision, after that I'll open a PR :-)
btw do we want to add an option which allows to change the coreutils pkg from to ? Something like and every module should start start using .
I had contemplated using a package override and just make equal to . Not sure how well that would work out... This may be something where is one of the few qualified to chime in.
Please don't introduce this as a NixOS option. This rewrite is not compatible with the GNU coreutils. This will certainly break NixOS. The package override will break lots of packages and will trigger a full rebuild anyway. Packaging these for testing is fine. :+1:
Could you just wrap this into a PR then? I will certainly test this and create some aliases to replace the GNU tools (in the user environment)
sorry for the delay at first. I'm aware of this. I just proposed an approach to switch the package just for system-wide testing purposes. This is actually the better approach. Furthermore this is something anyone can do locally, so shouldn't have concers with it as it shouldn't affect code in for now :-) I'll certainly do. However we have to wait for since the latest revisions of require Rust 1.19 (I'm currenty using an older revision from July 2017 locally). I checked out this change tried to compile uutils-coreutils against the new Rust compiler, but it cargo builds seem to fail ()
Ah, of course. Let's wait for then.
after has been merged it should be possible to finally implement this. Will open a PR in th next days...


Steps to reproduce the behavior: curaengine This was on an update yesterday to . Please run and paste the result.
I opened a PR yesterday:


Steps to reproduce the behavior: with latest master branch is building with the older version of (2.5), because it can't build with the latest version (see: ). Build of started to fail after recent update to version . Notify Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


Using more-or-less the default configuration for (with ), the list of results is printed twice whenever running . For example: Steps to reproduce the behavior: the module like so: the job with some file name that exists on the system Matching files should each be printed once. The issue is fixed if I unset the environment variable. plocate deliberately reads from both and the hard coded default path, even if they are the same: The comment claims that this is also the behavior of mlocate, but I do not have an mlocate database installed and haven't wanted to change my running system to use mlocate. It looks like recently started being set in NixOS in . Please run and paste the result.
Sounds to me like an upstream issue. Can you write a mail to the upstream maintainer? ;a=blob;f=README;h=;hb=HEAD#l40
Sure, I have done so. I'll follow up when I get a response.
The plocate maintainer says they do not consider this to be a bug in plocate, and is intentional behavior. Rather than setting the environment variable, could we just make a wrapper script for that uses the NixOS-configured dbpath, if we don't want to re-build itself when the path is changed?
I would be personally fine to just drop support for a custom place for the db. If people really want to have it somewhere else they could symlink it. Then we don't need a wrapper or to worry about the env.
I can confirm the behaviour with .
Could we just take out the variable setting? It isn't needed for or , and just causes this annoying behaviour. If it's needed for , maybe the setting could be made conditional. It would be nice to get something done about it sooner rather than later. This issue has been open for 4 months now.
Please take a look at
I've reviewed the PR and it LGTM. Thanks for doing this! It will be great to have this fixed.


A recent update broke building sysdig on release-17.03 branch. Nixpkgs version:
Does newer versions of sysdig solve the problem?
Fixed in
Thanks!


Package name: Tribler Latest released version: <!-- Search your package here: --- Current version on the unstable channel: 7.13.0 Current version on the stable/release channel: 7.11.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 <!-- If the result shows no maintainers, tag the person that last updated the package. -- Note for maintainers: Please tag this issue in your PR. This may Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Project description <!-- Describe the project a little: --Tools to manipulate pdf files. Metadata homepage URL: source URL: license: mit, bsd, gpl2+ , ... platforms: unix, linux, darwin, ... Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I'll see what I can do, should be good practice working with Gradle apps
Thank you Tom, much appreciated, best of luck.
By the way, I have pretty much succeeded in packaging it, and it seemed to run fine. Just forgot about it a little. The only issue with the package currently is that jar files are created non-deterministically by default (timestamps are not set to a fixed time). After using the fixup hook made for this situation (unzip and rezip the jar file) springboot doesn't recognise its files anymore, which is really weird. So it stayed non-deterministic. So I have two options: A) use the non-deterministic package or B) use the prebuilt jar from GitHub. The latter one is much less complex to work with.
See if this helps you.. or this discussion from the top (concerning java apps)...
Thanks for the pointers, though the second thing linked is my own post :) I finally managed to figure out how to fix the jar timestamps, so I'll open a PR adding the package
Thank you for your help . Much appreciated.. sorry for the delay. had a rough week last and it spilled into this one. Looking forward to using stirling-pdf on nixos.


When creating a dev shell with + , the resulting environment cannot use CUDA with . Steps to reproduce the behavior: a Note that I am using the commit from nixos-23.11, which is the latest at this moment. However, I have tried the commit from a month ago and the problem was there as well. , run with the above flake. and Note that it reports is found, but does not seem to have CUDA enabled. The above can be found . It is expected that and run with CUDA and GPU appears in the device list. I am running this on my NixOS machine with a Nvidia GPU, where nvidia-driver is properly installed. I am also an intensive user and it works perfectly. Also I vaguely remember such combination works correctly a few months ago. I am not particularly sure about the maintainers so I might be wrong. Based on 's commit history and meta I am goingt to and Please run and paste the result.
Let me know if I can provide more useful information. Any suggestion on how I can continue debugging this would also be very helpful. Thanks in advance!
hmm interesting... ooc what gpu are you trying to use? have you confirmed that the cuda capabilities specified in your flake are compatible with your gpu?
Also please gist the outputs of demonstrating which implementation of jaxlib ends up being loaded, and whether a search for is attempted
On this machine it is a 3060 Ti. I have been using on this machine, with the samilar dev Shell, so I can confirm the cuda capabilities specified should work.
Thanks. Let me put the stderr log here: The log is very huge. I tried to search for and it did not come back with anything. I am trying to see how is loaded from it.
I think it is trying to load from , but I am not sure whether it is the GPU-enabled one or not. I tend to think the above is the GPU-enabled because if I specify in the dev shell, it loads instead.
Also just to confirm: what's the output of ? Sometimes multiple jaxlib versions can get pulled in as transitive dependencies (though they shouldn't if everything is packaged correctly). Then python can end up loading jaxlib-without-cuda instead of jaxlib-with-cuda depending on the ordering in PYTHONPATH. From the looks of your flake this shouldn't be the case, but I'm guessing that this is a reproduction distilled from a more complex flake/project?
Yes this is distilled from a real world flake. It seems that in my dev shell is not set. However, running produces: I looked into the of the : Apparently there is only one being pulled in here.
Ok yeah that looks fine.. hmm
Btw, I tried two more things the capabilities constraint - still the same this on a 3090 machine, a 3080 machine and a 4090 machine. All of them produce exactly the same behavior.
Attempting to repro this but currently blocked on
Interesting. I had an attempt to run my nix-based ML project on an Ubuntu machine but wasn't able to get the nix dev shell to recognize the GPU a while ago. Have been using NixOS for development since then ...
Oh yeah it definitely works... mostly. This is the first real issue I've had with nixGL haha
Will give it a try! Meanwhile, I can try out any thoughts/ideas you might have to debug. Thanks!
Yeah my hope upon getting a repro is to bisect nixpkgs commits to find a known-good commit and then hopefully isolate the issue in a commit range. If you're feeling up to the task it would be quite useful! This would be a great use case for GPU-enabled tests and some CI infrastructure. tl;dr is that build has been green for a while but at some point it stopped actually using/recognizing GPUs.
Got it. This looks like something I can try. It would probably take a while as I'd imagine CUDA will be built again and again.
Let me try to build from a few commits on to start with.
Tried from about 3 months ago. Got different behavior: An older version has similar issue:
Also confirmed that can reproduce the probem: Similarly, from 2023-12-01 can reproduce the issue:
The above seems to suggest that, it is likely that in the past 3 months would not work with CUDA.
I found the a successful commit on : Please note that this is not a commit from and I believe it is using CUDA 11.7
Nice! Well I guess we have a (rough) commit window now to bisect on. Btw, I'm curious: does work any better for you on master? We don't have a CUDA alias for that one, so you'll need to set
Let me try that. My understanding is that is about downloading the pre-built binary (wheel) and patch it, while is about spinning up to build the wheel by ourselves And for end users of , they should behave pretty much the same. Is my understanding correct? Thanks!
Tried . Seeing the following error:
Digged a little bit into this. On the successful branch 23.05 with CUDA 11.7: while on the failed branch 23.11, This seems to suggest that the we have in this case is not enabled for cuda support.
Yes, that's exactly right! Nice find! Huh, very weird. We're building with all the GPU/CUDA flags turned on AFAIK. Also, it's surprising to me that jaxlib-bin isn't working on your system since upstream builds that and we make only minor modifications
I checked their and found that there is a bazel flag called . Don't know what it is (maybe related to ?), but 's does not have it. I tried to add it and (more specifically, the inside it) cannot build any more. Sorry if I did not make it clear. can be successfully built on my system. The problem is similar to , as it cannot be used with CUDA. It just prompts a different error.
More on . Although it can successfully create the "client", will report not being able to find cuda drivers: This is on 23.11. The on has been upgraded to , which has the same problem of not being able to find CUDA:
Tracing the code and I realized that the problem is that this line , which in turn calls in failed for . Based on , I think the <versionhere should be . And it turns out that we already have for , which contains . Scratching my head again now ...
Yup, totally with you there. Now if jaxlib-bin didn't build successfully that'd be an easier fix... Debugging with jaxlib-bin can be convenient since it offers "known-good" binaries to work with. Hmm, ok this is where output ought to point the way. But looking through the logs you posted earlier it, I'm not able to find the string anywhere... Would you mind posting the logs for the version? OOC how did you come to conclude that <versionis the failing lookup? It's a perfectly sensible conclusion since just about every CUDA package ever has to load it, but just curious re your methodology.
Ah sorry I should have provided more information here. So my journey starts with the error: and this quickly leads to the code in tensorflow: This means that the call to failed. This particular function can be found at , which is essentially . The function is , which is basically a call to , which in turn is just a call to of the here. Reading the above functions, we can see that the offending filename is in the format of . I could not figure out the because it is actually defined , which is in turn injected from . Because I had the impression that I was using , so I believe the version here is . This turned out to be wrong, see below. Thanks a lot for the suggestion! I tried the following Which produces log: Turns out that it is actually looking for . However, it is looking for ! Below are the selected part of the above log: I then went back to check for the : , and apparently it is downloading the prebuilt binary that is tagged with . Note that points to Cuda 11.8. I might be wrong, but is prebuilt binary tagged with supposed to work with CUDA 11 as well? The logic that finds and loads the files definitely is not compatible with CUDA 11.
For as long as tf is 2.13: We should add the comment. It's possible that jaxlib and tf actually come with different version constraints, I haven't checked. I guess one then has to pass it ( specifically) . Looks like jaxlib is trying to take over a part of the dynamic linker's job instead of just using DT_NEEDED and naturally this doesn't play out smoothly. They probably wanted to defer loading or something
I am trying adding an overlay like this: Seems that is now working. I am not sure whether this will have bad implications though. Yeah they might have some reason to defer it.
There is one problem though, if I have the following overlay: is ok, but will fail to build because of test failures. See the log: Note that all the failures seem to be related to: I suspect this is jax tests that should run on CUDA but incorrectly ran on cpu - but I am not sure.
At this moment, with the help of and (Thanks!), I think I might have a solution to this. TLTR: We can now use (version 0.4.23) on , if you apply an overlay to point to . NOTE: usually you will also need alongside . It works on , but you will have to disable the unit tests and import test. See below in "what is still unclear". Detailed explanation: download a prebuilt binary, which defers loading of at runtime via dynamically. prebuilt binary is built against , meaning that will look for . , there is another check to make sure that the CUDA version is exactly (i.e. 12.1 and 12.0 will not work). , uses , which is designed for . The current needs instead of . However, if your environment does not require , just point to and everything should work out. with fixed above, I cannot build unless all the tests are disabled. It does not seem to affect the actual usage of because the test failure is specifically about not finding GPU-version of during test. This should be fixable but I am not sure how at this moment. we want to be able to use instead of to have more flexibility. The current build of seems to produce a library that does not have CUDA support. This remains a mystery and needs further investigation.
I propose that we template the "cudaXX" strings in based on the version of the inputted / instead of hardcoding. That will prevent this kind of issue in the future. It's worth noting that upstream releases builds for both cuda11 and cuda12, so we're in luck there. Unfortunately I'm of minimal use in terms of submitting PRs until is resolved. This reminds me that we should also migrate jaxlib-bin to use the redist packages at some point. Fixing the source build will be its own adventure. I suspect we're just missing some kind of flag that changed in upstream's build process.
Sounds good. Still, for the upstream releases, cuda11 = cuda 11.8, cuda12 = cuda 12.2. The minor version is still important here and should be checked. Agree. It probably requires setting a development environment and build incrementally with to investigate. Blindly update flag and build the whole package again from scratch is quite inefficient ...
Sorry but I was not able to find the build for . I saw the ones under , but not under . Are they the same?
Search for "cuda11/jaxlib-0.4.23" and you'll find them. This link seems to be outdated, or at least not actively maintained by upstream. We should prob update the comment to point to instead.
I saw you're using that with Ubuntu? Did you try nixglhost?
oooh no i hadn't heard of nixglhost before... i'll give that a shot!
With that I was able to find the one for CUDA 11 (cudnn 8.6) and it worked out with this overlay: Need some advice on how to fix on . Based on suggestion, I am thinking about the version of cuda, assert on 11.8 / 12.2 will be set to if cuda is 11.8, or if cuda is 12.2 the file based on the above version Does that make sense?
Yup, exactly what I was thinking! Though I have a sneaking suspicion that CUDA versions outside of 11.8 / 12.2 might work. Sometimes they'll attempt to and then try , and so forth. So we should try seeing if other CUDA versions work too.
Thanks! I tried 12.0 and it won't work for prebuilt binary originally built against 12.2.
Ah ok maybe not then... damn EDIT: the JAX folks claim that this ought to be possible:
I still don't understand (and haven't got around to verify myself) whether is functional, and why do we keep focusing on instead?
is not functional, which is the original report of this issue: can be built However, the built (more specifically, ), was not able to work with CUDA. It seems that the problem is is actually not "withCuda". There might be some flags to be set during bazel build, but I was not able to find the reason. We then turn to as an alternative because we need a working at this moment. Turns out that has a different issue, but is easier to fix.
I also read about that, but my experiment wasn't successful, for example, it will panic about JAX being built with but the current CUDA version is
Looking at for https://hercules- I see no mention of () Is it intentional we add to but not to the following? (again, I've no idea what I'm talking about)
Similar here, I am not that familiar with jax's bazel code. Would like to provide some information here. with CUDA 11.7 works, and at that time looks pretty much the same:
It seems that the version of cudnn is not a requirement. Binary built with 8.6 can work with 8.9 at runtime.
Well, there's definitely a bug in here somewhere. It is def possible that this is part of it. I'm guessing that upstream changed their build flags and we completed a version upgrade without realizing since we don't have a means to run GPU-enabled tests in CI/nixpkgs-review yet. is included in as a means to reduce the number of possible hashes that we have to record. The fetch is a superset of the CPU-only fetch, so we combine them for simplicity. is really handy in these situations where the source build is either broken or not on a version that the user wants. The source build is really quite unwieldy unfortunately. (Similar but not quite as bad as the tensorflow situation.)
I am working on the fix for . Not sure what is the best way to test it though. I am thinking about: the fix in a branch a that points to that branch with CUDA 11 and 12 on 3.9 through 3.12
Another approach, IMHO a little easier but totally up to you: Then you can run this for , , etc and and . That way you can run/test locally without committing changes.
The PR is created at
I am closing this as at least the version is fixed now. Thanks a lot for the help
Fixing the *-bin version is great, but let's keep this open until the source version is fixed as well
FWIW, the Guix version (there is only a source version) is here: It works fine with CUDA. The definition of the CUDA-less version that it references is here: Maybe there's an obvious difference somewhere in the arguments.
Ok I think I've found the culprit. Somewhere along the way we removed from and/or . Oops! Working on a fix now... Currently blocked on AFAICT we do not package CUB and it is not provided in any of the cudaPackages that I've consulted thus far. If anyone has any ideas on the best way to proceed, do let me know!
Pretty sure it's part of , and we also used to distribute it as part of nvidia-thrust which we deleted
Ah, thanks for the tip ! I wasn't able to find or : Perhaps it has a different attribute name? Assuming a typo, I checked nccl which is already a dependency of jaxlib, but to no avail: Perhaps I'm missing something? Btw, draft PR started here:
Oop, found , but not finding that header file sadly:
Not ""?
Adding seemed to solve the problem, despite the difference in filenames. Not sure exactly what kind of wizardry they're doing to adjust header names, but it seems happy for now.
Looking at your issue upstream, I think the names match?
Oop, yeah you're right. I was confusing that with something else
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
If you're using NixOS is there a platform wide config to always have the cuda libraries enabled?
I'm trying to compile jax using the commit , which appears to have closed this issue. When I tried to run jax on CUDA using this commit, I would need to compile jaxlib from scratch. During the compilation, I get a hash mismatch error in a library that is compiling. I even tried to use a later commit to get the following output: This is my And this is my (for the newer commit):
This seems like a support question, you're more likely to find help on NixOS Discourse or Matrix. But the answer is and this will trigger a lot of rebuilds Interesting, this might be a reproducibility issue with the way we fetch bazel dependencies, in which case this deserves a separate issue


Can't start virtual device: qemu libpixmin not found. Steps to reproduce the behavior: Genymotion any Android device it An android VM is started Here is log: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Package name: Latest released version: 0.3.4 <!-- Search your package here: --- Current version on the unstable channel: 0.2.0 Current version on the stable/release channel: 0.2.0 Notify maintainers 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 repo has moved to .
Working on a PR now.
Getting errors with having Git dependencies. I need to find the hash of the new file, but Nix isn't giving it to me when I provide a fake hash.
I can't get a hash, so I'm stopping for now. If anyone else wants to pick it up, it would be appreciated.


There is a license violation in the package. The package contains the code for under the old MAME license which is non-commercial and incompatible with the GPL code in the rest of the program. I tried to notify upstream, but that didn't seem to go well...
Hello! It seems that upstream actually an option to disable in version of . , from my testing, gives me an error when I try to run it. You can find more info in this . So, i think merging the pull request linked to this issue is the best option right now.


Steps to reproduce the behavior: angband macOS Sonoma 14.3 Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
could you include entire build log?
It works now. THANKS DEVS!


Package name: gitqlient Latest released version: 1.6.2 Current version on the unstable channel: 1.5.0 Current version on the stable/release channel: 1.5.0 Notify maintainers Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Project description "28Kb, small memory footprint, single binary that run list of commands in parallel and waits for their termination" Metadata homepage URL: https://await- source URL: license: mit platforms: linux, darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


fails to build on aarch64-darwin due to failing tests due to a sandbox issue. See also: Tests should pass, allowing the package build to succeed. none listed for pytest-django specifically, for django in general Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
In a case like this, would disabling these tests be appropriate? They seem to only need access to -- is that permissible in a sandboxed build?
Future self: this was fixed by adding , which seems to currently have zero mentions in the nixpkgs manual (or the nixos manual) or Defined in nix: It adds to the sandbox-exec call.


Project description Metadata homepage URL: source URL: license: bsd3 platforms: unix, linux, darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Steps to reproduce the behavior: the following : the flake: cc Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Oddly enough, (the original PR ) actually fails as well. Result of run on x86_64-linux <details<summary1 package failed to build:</summary<ul<licemu</li</ul</details


Unable to launch gplates on NixOS. A shared object file appears to be missing. Steps to reproduce the behavior: : gplates is expected to launch and be usable. N/A N/A No listed maintainers on Nix Packages but was the last to touch the source for this application. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Probably adding to and/or adding to might help, but I'm too tired to debug tonight. I'll look into it in the next few days.
Thank you, I was reading about the first option you suggested being a potential fix. I'll see if I can wrap my head around doing it on my own as well this week, though I don't have a lot of experience contributing to projects likes this.


Hardening gives old Clang flags that it cannot handle and fails. A same problem, I imagine, would arise with old GCC versions. A possible solution is to list somewhere what hardening methods are supported and use the list when deciding what hardening to apply. For example: a file : an error. Nixpkgs version: (run ) Sandboxing enabled: (run ) yes


In the NixOS gitlab module, the fleet of Gitlab component services is strongly coupled to the (local) postgresql and – via sidekiq – to Redis. On a systemd unit dependency level, this happens via a relationship and causes the other services to be stopped and (re)started when just one of them is instructed to do so. Unfortunately, there can be several edge cases where the system ends up with not all of the components being in the desired state (mostly up). Steps to reproduce the behavior: This issue is a subtle race condition, so I choose to describe the general problematic setup instead of trying to engineer a reproducer: I've encountered a situation where both and where restarted (stop and start) at system switch time due to changed configuration. This triggered Gitlab to be stopped as well. Unfortunately the service(s) was in its startup (Activating) phase and stayed inactive. The expectation is that Gitlab comes back after the dependency restart. Instead of continuing to tune the strongly-tied, evermore complex inter-service dependencies I propose to decouple postgresql and redis from the rest of the gitlab services. I'll open a WIP pr on this. <!-- 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]:
Here's my proposal on reducing the coupling between DBs and the rest of gitlab, currently with failing tests unfortunately:


Steps to reproduce the behavior: /run/current-system/bin/switch-to-configuration test Does not crash system/systemd This can be reproduced using this test in sops-nix: Edit to have this change <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Related to
It seems like it's reusing the same loop device when mounting the new overlay...


Package name: Latest released version: 2.27.0 <!-- Search your package here: --- Current version on the unstable channel: 2.21.0 Current version on the stable/release channel: 2.21.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 <!-- 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]:


Mentioned in , the bcc package can also be used as from python. This currently doesn't seem to work? If applicable, add screenshots to help explain your problem. Add any other context about the problem here. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
bcc doesn't depend on kernel anymore, so the second half of the comment you linked at isn't required and we can just move the package & add a compat alias. Technically you should already be able to use bcc as by magic'ing the correct site path, but I agree it's better to move it - patch welcome!


Project description GitButler is a git client that lets you work on multiple branches at the same time. It allows you to quickly organize file changes into separate branches while still having them applied to your working directory. You can then push branches individually to your remote, or directly create pull requests. In a nutshell, it's a more flexible version of git add -p and git rebase -i, allowing you to efficiently multitask across branches. Metadata homepage URL: source URL: license: FSL-1.0-MIT platforms: linux, darwin
is also a Tauri app so the packaging is likely similar:
I'll work on this over the weekend, unless anyone has already started?
I don't think building from source is gonna be easy, precisely as we don't have done yet and this project uses pnpm workspaces. You can however wrap the Appimage though.
I've made Still draft. It does start the application, but clicking buttons results in problems on my system :sweatsmile: For a quick run: Update: it's now mostly working. The signin/login still gives an error and it's still unclear why. Also, I don't think I'll use gitbutler regularly atm, so it might be best if someone else wants to volunteer as maintainer of this package :sweatsmile:
I have made a PR that builds from source and has no issues with logging in (that just needed ).
Is this request open to contributions?
Would be best to wait for a while, if that PR goes abandoned, you can ask the author if it's okay to open another


libstudxml is a streaming XML pull parser and streaming XML serializer implementation for modern, standard C++. It has an API that we believe should have already been in Boost or even in the C++ standard library.


Package name: curl-impersonate Latest released version: 0.6.0 <!-- Search your package here: --- Current version on the unstable channel: 0.5.4 Current version on the stable/release channel: 0.5.4 <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Package name: Flutter Latest released version: 3.19.0 <!-- Search your package here: --- Current version on the unstable channel: 3.16.7 Current version on the stable/release channel: 3.13.8 <!-- 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 <!-- 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]: