First of all, I somehow got my hand on the file that lists where it crashed exactly, then looked through it, found the definitions in the namespace explorer. It looked like it was supposed to start some processes and then connect to them, however they exited immediately. I was able to verify this by printing in . is an array of new objects, so I looked up the docs, and it turns out you can specify an OutFile, which specifies where a process should dump its logs (its the 5th parameter of ), so I overrode that to point to some known location. That file contained the following: In was required by the binary, so took care of it. However in they probably changed it to load dynamically using which can't be auto-detected with . I had to use with the normal binary to make it work, but I didn't know what was so I didn't do anything with it. Note: in a new binary named appeared, however I don't know where it's used, so I don't know what I should do with it. Might have to ask around for it.
thanks for taking the time to outline how you came to that conlcusion im sure that will help me in the future. Sorry for forgetting to close this its closed now
Well, the fix isn't merged yet, so I think that this issue staying open was not a problem.
oh sorry I forgot as I used the branch locally and then after many weeks I saw its still opened and somehow was under the assumption that it was merged. Sorry I skipped that


(this is a qt specific test): Loc: [t-(458)] PASS : TofuInfoTest::cleanupTestCase() Totals: 7 passed, 1 failed, 0 skipped, 0 blacklisted, 1047ms This seems to affect master too, but for some reason it's been built successfully once. The aarch64 build started failing when updating qt5 from 5.11 to 5.12 making it the likely root cause: Edit: the cause was expired testing keys: cc maintainer cc as you've been active in keeping plasma/kde up to date lately. ping staging next:
Did you found ? Sounds very similar and should be fixed...
No didn't find that, but yeah, that sure looks exactly like the same issue. I'm guessing the qt issue were never actually fixed: Blame on the test gives no change at least:
And applying the suggested patch does fix the test: diff +++ gpgme-1.10.0/lang/qt/tests/t- -455,7 +455,7 private Q_SLOTS: QVERIFY(result.numSignatures() == 1); auto sig = result.signatures()[0]; QVERIFY(sig.validity() == Signature::Marginal); QVERIFY(sig.validity() == Signature::Marginal sig.validity() == Signature::Unknown); auto stats = ().userID(0).tofuInfo(); QVERIFY(!stats.isNull());
So, what are we want to do? Do you maybe want to comment on the upstream issue?
Hmm, strange, I'm getting the same failure on master (using ), forcing single core does not fix the problem though, so probably not a race condition. I've reported the failure as you suggested:
The cause is most likely qt 5.11 to 5.12 upgrade, as the aarch64 build started failing the test then:
So the keys used in this test expired on 2019-01-06, which explains why we suddenly saw this without any apparent reason. :
Thanks for fixing this and sorry for my late reply... (Edit: And of course also thanks


name: didyoumean current version: 1.1.0 desired version: 1.1.3 maintainers: Version 1.1.3 comes with a man page as well as shell completions for a few shells (bash, zsh, fish, elvish). I'd like to have the script install these. I'm more than willing to do the actual update myself, but I'm very new to Nix, so I'll probably need some guidance, specifically on how to install these completions and the man page, and how to update the hash. Thanks!
To update the hashes, simply set and , and update them as suggested by . Having done it right, you'll haveTo install the man page and the shell completions, setYou may also need to set on some platforms (at least on ?). Before doing this, feel free to make a pull request.
I'm running into some issues trying to test it to ensure it's doing what I want it to. I'm going to the directory with in it and running but I'm running into issues regarding being undefined: Any pointers? I wasn't able to find anything searching through the web
needs to be in the attrset at the top of the file for you to be able to use it.
As explained, we need to add at the top of the file.


When installed through Nix, Bluemail does not create a desktop shortcut in $out/share/applications. The program can only be run through the terminal by default. The program also fails to load unless the --disable-gpu-sandbox option is used. Steps to reproduce the behavior: Bluemail by adding to , and rebuild. for Bluemail in the Application Launcher - not present in terminal - core dumps on gpu process not usable in terminal - bluemail opens with the default wayland icon What currently happens is detailed step-by-step above. What I'd expect to happen is that a desktop icon is created when I rebuild to install bluemail, and that clicking the application from the Application Launcher opens bluemail without a core dump. Installing from NixOS-Unstable Running on Intel UHD Graphics (10th Gen)


Describe the bug SANE does not find the backend To Reproduce Steps to reproduce the behavior: backend to the error Expected behavior SANE loads the airscan backend. Screenshots Listing of symlinks to SANE-Backends: Additional context is missing the version suffix, so SANE does not use the library. The issue has been fixed on upstream master, but no new version has been released yet. Should we just update the package via commit-hash (it's still in early development anyhow), or wait for the next release for updating it? Using in my local nixpkgs fixes the problem. Notify maintainers Metadata Maintainer information:
I will quickly get in touch with the maintainer of to see if he can cut another release for us. It feels important enough to cut a bugfix release ;) thanks for taking the time for writing such a detailed explanation!


Building on Darwin fails. The problem seems very similar to which was solved by —however I do not know how to apply that solution here.
Wasn't this fixed by merging
This issue is fixed, but it broke again recently. Same issue as but we use
Proposed
Fixed by


I had i3pystatus fail to build because of a pytest error with praw on unstable. I tried to bump praw from 6.0.0 to 6.3.1 but it requires a new dep websocket-client that doesn't look packaged thus I ended up ditching it from i3pystatus dependencies. Maybe we should do the same upstream and provide a leaner i3pystatus as it's not a core plugin anyway (and fails ). nix build -f channel:nixos-unstable system: host os: multi-user?: sandbox: version: channels(teto): channels(root): nixpkgs:
CC ? what do you think of removing it from i3pystatus default ?
Agree. A user can add manually by overriding of parameter.
is this still relevant now? or can it be closed?
I just removed praw it from i3pystatus default dependencies but itself still won't build. So it makes sense to keep the issue open even if I have no personal interest in praw.
it was irritating me, so i updated it.


As a fallout of the migration to GHC 9.0.2 got marked as broken, as it failed to build with GHC 9.0.2 and the Stackage LTS 19 package set we now have. It would be necessary to investigate if survived this (i.e. if it still builds) and if not to get it to work again. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --cc
should compile again. The bootstrap is additionally built by Hydra, so only the GHC bundled libraries will need to be compiled (which is an improvement to before at least).


Steps to reproduce the behavior: unstable defined, enable the ollama service with pkg overridden to point at unstable: without show-trace: with --show-trace: Add any other context about the problem here. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hi! Can you confirm your nixpkgs revision has this change incorporated and you're not overriding the package manually?


Describe the bug and failed to build on current master (). (The former depends on the latter.) Build log: To Reproduce Steps to reproduce the behavior: nixpkgs master. (or ) the build error. Expected behavior It builds. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. Maintainer information:


Describe the bug If you open KDE Partition Manager using its file, it tells you that you aren't running it as root, and you won't be able to make any changes with it (rendering the program useless). The only workaround is running (which is probably unintuitive to people with less linux experience) or changing the file (a bad idea when you want Nix to manage your system) To Reproduce Steps to reproduce the behavior: by adding it to your the file (e.g. in KDE, click on the start menu in the bottom left, type in partition manager, and click on the program) Expected behavior Use when clicking the file for a seamless experience Screenshots ! Additional context The message mentions so I tried adding it to by hand, but that did not work. Metadata Maintainer information:
Looks like the package is out of date. This dialogue does not appear to be part of the latest version:
This might work
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .


= 2021.07 does not build successfully on Darwin. A bisect over commits shows this: 2021.10 - - does not work 2021.07 - - does not work 2021.06 - - works 2020.12 - - works Steps to reproduce the behavior: this repo: on Darwin. (I'm on MacOS Big Sur). line 4 from to . . Observe the build failure in the output: For the full log, see .
Caused by Please use to show the files that a working rakudo contains on darwin
Tested on and it works. Thanks!


The script does not (consistently) follow symlinks in the parameter, which it uses to locate the system closure to activate. This breaks when used with , which creates a symlink. When the kernel command line has , the script looks for , which does not exist. ~(Workaround: generationsDir users can pass instead.)~ Update: That doesn't work either. with will fail in strange ways, ultimately stemming from not calling . System should boot successfully when using generationsDir and systemd-initrd together. Symlink resolution was partially addressed in , but only for cases where is a symlink. Booting also fails if the given is a symlink, or if any part of the path to is an absolute symlink (because filesystems are mounted at , not ). I took a stab at fixing this in (), but it does not handle absolute symlinks correctly. Since generationsDir creates absolute symlinks to , this fix alone does not fix compatibility. ( changes those symlinks to relative, and together the PRs fix the compatibility issue.) Ideally, the script should follow symlinks in any part of the param, even if they cross filesystems. One option is to resolve the links inside the chroot. I couldn't figure out a clean way to make this work. (Can we trust that will have the we're looking for? We can't use because we're still trying to establish which system that is.) Another option is to somehow . (At time of writing, this question has no answers.) (guessing based on git log):


Describe the bug To Reproduce Expected behavior The derivation to build an executable called Additional context It fails with also but succeeds with but so 1.3 seems to be a recent addition even though julia is on 1.4 and about to move to 1.5. Notify maintainers Metadata Please run and paste the result.
Same issue here: system: host os: multi-user?: sandbox: version: channels(root): channels(jfelice): nixpkgs: This prevents installing GNU octave on MacOS.
FWIW I was able to work around this issue by creating a to disable the checks in arpack: I was able to build octave successfully with that. I had to hack around a runtime issue finding , will log that as a separate issue.


Describe the bug I'd like to build the python numpy package on an x86 machine for the armv7 architecture. numpy requires liblapack and blas, which require gfortran I already fixed one issue which is that liblapack couldn't find the gfortran compiler (see the overlay below) I'm trying to use the 20.03 release, latest commit. Here's what I'm running exactly: To Reproduce Steps to reproduce the behavior: -build here's the error I get Expected behavior The derivation builds Metadata Please run and paste the result. Maintainer information:
Maybe related to: ?
I'm not getting this in NixOS. It looks like a sandboxing issue. Can you try running this:
Thanks for responding! I launched this build on NixOs using an AMI on EC2 and I get the same result as in the issue report, here are the system details:
A similar issue exists on unstable when building for x86. Currently on: system: host os: multi-user?: sandbox: version: channels(root): channels(swflint): nixpkgs:


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


option was changed to ddclient.domains, but instead of maintaining backwards compatibility the type was changed to a list of strings, which also was not in the release notes, which makes this a bug. I don't see why the type was not simply changed to an or of a string and a list of strings in order to maintain compatibility. Try to upgrade 18.03 with = ""; Any released 18.03 version.
As this breakage already happened, would there be a point in doing a patch for 18.09? (I could provide one, but I don't know, wether it will be merged into a stable branch.)
It would improve the experience for others (if you make it such that it works for both types). I cannot imagine any reason for it not being merged into a stable branch. I wouldn't mind merging it myself, but since I have no rights to do that you would have to wait longer.
hmm it looks like the module is in a weird state anyway. The config file, which is produced at the moment, doesn't look very useful, as all options will be applied to all domains likewise. So only one protocol can be used in nixos at the moment. If I am not mistaken I will need to change that into a config per domain, with a global part.
Your changes would introduce new features and go beyond what is in 18.09. 19.03 would be a good target. Due to the module system people could already use them in . Even then if would be nice if you could keep it backwards compatible. It's probably also relevant to consider whether there is an actual demand for what you are trying to do. For example, I would not be a potential user and most people would likely only use one protocol.
Not a problem, so I will just make the minimal possible change.
This needs to be reopened, because of a failure to build:
I'll take look. Which commit did you use?
Whatever was newest 15 hours ago in the release channel.
Yes, the change wasn't backported to the release branch :(
: Could you please reopen this and merge the change into release-18.09 ?


Project description swc is the "speedy web compiler" fast alternative to tsc, to compile typescript to javascript without type-checking swc is mentioned in a different context in adds 150 MByte to node_modules so it makes sense to factor-out swc to a global package example use: () on a 2x2GHz machine, swc is 10x faster than tsc = 2 minutes vs 20 minutes is a lightweight wrapper (1 MByte or so) but has as peer-dependency, so npm will install both Metadata homepage URL: source URL: license: apl2 platforms: all


The dbeaver package does not build on . Steps to reproduce the behavior: Dbeaver should build <details<summaryTruncated build log</summary<br</details


Upstream ibus-1.5.24 (in nixpkgs) supports gtk4. It will be good if we enable gtk4 support in nixpkgs. I fail to enable it with the following patch.


K3s module example option () is causing a crash because kubelet verbosity can no longer be updated post-initialization k3s does not start with the option "--kubelet-arg=v=4" defined Suggest any other k3s option except this one <!-- 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]:


Building this package twice does not produce the bit-by-bit identical result each time, making it harder to detect CI breaches. You can read more about this at https://reproducible- . Fixing bit-by-bit reproducibility also has additional advantages, such as avoiding hard-to-reproduce bugs, making content-addressed storage more effective and reducing rebuilds in such systems. You can use to analyze the differences in the output of the two builds. To view the build log of the build that produced the artifact in the binary cache: In the context of pip we previously deleted these files,


Current version of rustracer 2.1.22 does not build with latest stable rust (see ). Please update rustracer to the newest version 2.1.27


should have only eliminated the s and removed some of the platform-based (adding new broken/non-buildable attrs), but instead has changed the actual logic. Since that commit, no longer resolves into but into (note the wrong cuda release), later leading to evaluation errors This currently breaks on Steps to reproduce the behavior: We should probably add some tests for the selection logic as well... A clear and concise description of what you expected to happen. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


I have a Samsung M2022W (usb) that works on a raspberrypi using raspbian (2017-11-29-raspbian-stretch-). I had to pick the ML-2160 driver in CUPS 2.2.1 as recommended by On NixOS (cups-2.2.2): [nawal nix-info system: "x8664-linux", multi-user?: yes, version: nix-env (Nix) 1.11.16, channels(nawal): "nixos-17.03-17.03.1082.", channels(root): "nixos-17.09.3149.", nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs If I use services.printing = { enable = true; drivers = [ pkgs.samsungUnifiedLinuxDriver ]; extraConf = '' LogLevel debug ''; extraFilesConf = '' FileDevice yes ''; }; and pick the same driver, I get garbage printed out. I tried to track down the ppd on raspbian, but only found: pi $ grep 2160 /usr/share/cups/drv/splix- ModelName "ML-2160" PCFileName "" and (i.e. it generated the ppd when I installed the printer apparently).


On nixos: [nawal | grep 2160 /nix/store/6f2zx8dl4w0kzgw3wj8f466mvkcgc3dc-samsung-UnifiedLinuxDriver-4.00.39/opt/share/ppd/ML- /nix/store/nmp023llc8fix567f413a5rqbx4sw45g-cups-progs/share/cups/model/ML- Having diffed them, I notice amongst a huge number of differences: [nawal diff /nix/store/nmp023llc8fix567f413a5rqbx4sw45g-cups-progs/share/cups/model/ML- | grep Version < FileVersion: "2.0.0" < PSVersion: "(3010.000) 0" < QPDL QPDLVersion: "3" < *cupsVersion: 2.2 so raspbian is using a version "2.0.0" and "2.2" of something or other, whereas nixos is using a version "1.2" and "1.1" of similar things. I managed to get my printer to work by copying the ppd across, but I don't understand enough of cups (nor now have the inclination to learn) to figure out what's going on or how to make nixos do the right thing (i.e. in a word, print). I thought this might be useful for someone else who wants to pick it up? Happy to hack around the raspbian if you need more info, or try out things if you need me to while the sd card contains raspbian.
Can you find out what package on Raspbian provides the driver? Have you installed proprietary Samsung driver there? If not, can you try removing ? It seems we have latest version of but not the latest of the proprietary driver but you don't seem to use it.
I'll have a look tomorrow evening - how do i use the new splix without upgrading everything to the same commit?
Find out your current commit with (look at the suffix), then clone nixpkgs repository (), checkout current commit (), fetch my changes () and cherry-pick my patch atop your current commit (). Then you can rebuild nixpkgs with .
I can confirm this works.


Thanks for the detailed instructions and for fixing it so quickly! NB: I had to do: (i.e. ) thanks


The tsocks package creates a shell script () that can be used to run a command with set to the tsocks library. However, it is hard-coded to use . It should be changed to use .
Fixed by


The package can't be cross compiled to other architectures, tested: raspberry-pi and aarch-multiplatform Steps to reproduce the behavior: It should be compiled. This doesn't seem to a nix-only problem, but still influenced by nix. Doesn't compile on arm: AIX: Some missing support for aarch64: Doesn't compile via qemu for arm32v7 and arm64v8: The error I'm having doesn't seem to show up anywhere else though. And a few of those threads also post work arounds. There is no maintainer. $ nix-shell -p nix-info --run "nix-info -m" this path will be fetched (0.05 MiB download, 0.28 MiB unpacked): /nix/store/xq77wmzk8d306anyk9rsvl4i4h7ihchw-bash-interactive-4.4-p23-dev copying path '/nix/store/xq77wmzk8d306anyk9rsvl4i4h7ihchw-bash-interactive-4.4-p23-dev' from ''... system: host os: multi-user?: sandbox: version: channels(root): channels(nix): nixpkgs: Maintainer information:
It seems to be that every package that declares in it's is failing to cross compile. If I put it in it fails with another error though: Should I open another, conglomerate, issue for all the other packages?


The latest major version 5.9 of the Linux kernel . Apparently, zstd compressed things decompress much faster and can cut boot times substantially, hence it seems worthwhile for us to support this scheme. Currently we are using bzip2. Unfortunately, I probably won't find time to work on this myself, but thought to open this issue to track progress.
I've [probably] been using it through a xanmod patch, not recently since the 5.9 release though. What I have in my files are and adding to of the kernel derivation
For the initrd image: For me (which might differ from the stock kernel NixOS provides): is already enabled, so set This enables ZSTD compression for initrd. However, which will need to as mentioned above.
I was wondering if zstd should be made a part of stdenv. are all available in stdenv on linux and with slowly becoming more common by being available in the kernel and used by various distribution's packaging it should make sense to include it.
Can this be closed? Did cover it all?
Yes, it did! Closing this issue. Thank you for pointing that out, didn't notice before.


Since PM stumpwm is now up to date but I have an issue in stumpwm module loading. SBCL will return the a package conflict error between packages "CLOSER-COMMON-LISP" and "DYNAMIC-MXINS" Steps to reproduce the behavior: to your stumpwm contrib modules in an appropriate directory a minimal file: reboot using stumpwm or refresh the stumpwm config using command (by default keystrokes are: ) Modules are loaded as expected Results of :
Hm, indeed. And maybe for debugging we should provide access to the «library» version of StumpWM…
We could try building using the Makefile instead of save-lisp-and-die. I did, but then there were problems with missing HOME. Then the problem was that the stumpwm build script seems to want to remember the value of HOME from compile-time on run-time (something like "/build") How did stumpwm work previously in nixpkgs?
Can you try with this?


I've to my . itself works fine: But the man pages are all missing: As far as I can tell, upstream provides them in DocBook format: and also provides a Makefile to build them: so this should hopefully be easily fixable. Steps to reproduce the behavior: . to read a man page for any of the binaries. Man pages should be provided. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thanks for reporting I have opened PR to fix it.


Pretty much all commands just show the "usage" output, regardless if the input is correct or not. For example, outputs: Steps to reproduce the behavior: , , , and many other commands incorrect output I expect to see the correct output, for example should show the current status of all miners.
How did you determine the commands? The printed help page does not list any of those as supported.
I got the commands from the Tracker documentation: You are right that they aren't listed in the help page. I do have manuals with usage for all those commands installed though.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


Project description aw-watcher-window-wayland is a part of ActivityWatch needed to have it working in a Wayland compositor. At the present time, without this, the ActivityWatch package is not working on Wayland environments Metadata homepage URL: source URL: license: MPL-2.0 license platforms: linux


Describe the bug I cannot make a shell with pandas installed. To Reproduce Expected behavior A shell opens and works. Additional context <details<summaryI get this error message:</summary</detailsNotify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(noah): nixpkgs: Maintainer information:


Steps to reproduce the behavior: $ nix build --verbose The interesting thing is that I can build the flask-sqlalchemy package just fine: system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:


I became marked as a maintainer on the package many years ago, but since then I have changed careers and have slowly stopped using nixos as much. I don't currently have git installed (and I don't really remember how to use it) Please remove me from the maintainer list I am in the maintainer list as follows:


Emby uses ffmpeg for transcoding media and for generating thumbnails. Emby fails to find the FFmpeg binary during the setup wizard but can be specified manually if FFmpeg has been installed separately. Add to , browse to , and advance through the wizard. System: 17.03pre92039. (Gorilla) Nix version:nix-env (Nix) 1.11.4 Nixpkgs version: 17.03pre92039.
cc
Funny thing is that I was just watching a movie when I was mentioned on a system without any ffmpeg/ffprobe binary. My system was upgraded from an older version (config was already existing so no check was done by the wizard). I was able to reproduce the issue. Will take a more detailed look at it sometime tomorrow :)


Trying to run an action with azure-cli that requries authentication, az will fail to read the cached authentication token from the token cache: This is due to a version mismatch of . will update the package, I checked that the authentication works afterwards. That's me! Please run and paste the result. ` Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I also experience this issue with , as well as with . Thanks for adding the fix!


Setting to while setting to any non-empty value will cause a build failure because and both attempt to create The correct result would be for the contents of to be written out at the end of , after the stanzas provided by pulseaudio. Somewhat relatedly, the in and in pulseaudio's generated config doesn't make a whole lot of sense. means "override", currently there is nothing for it to override, and we would like user config to override generated config, not the other way around. However, as long as user config is placed in the file after generated config then I don't think the actually makes any difference.
I am having this issue as well. Easily replicated by setting those two options.
Can you make a pull request?
Should be fixed with . If there still is a problem, please reopen this issue.


Describe the bug When printing to Brother MFC-L2700DW printer (with created from a similar model in nixpkgs), CUPS often (but not always) complains about "Impossible to connect to Name or service not known" even though I followed the and enabled . To Reproduce Steps to reproduce the behavior: Brother MFC-L2700DW printer. NixOS as follows: (full configuration ) something to http://localhost:631/printers/BrotherMFC-L2700DWseries and see the "Impossible to connect to Name or service not known" message. Expected behavior The job is sent to the printer and printed. Additional context When the printer cannot be connected, running usually helps and the stuck job gets to the printer. After my investigation, I think that the cause is long delay in mDNS name resolution. By default NixOS uses NSS module, which tries to resolve both IPv4 and IPv6 addresses sequentially. It seems to start with IPv6, which does not resolve to a valid address so after 5s timeout the resolution continues with IPv4. So the address of the printer is returned after slightly more that 5 seconds (can be verified with ), which seems to be too long for CUPS so it gives up and tries again later and the same repeats, because nscd in NixOS does not cache the results. My current solution to the problem is to switch from NSS to with the following in my : I've also tried but it didn't help. The question is whether to make it easier for others. Possible things that come to my mind: Document this at Wiki Extend to provide e.g. option. Enable caching in nscd Something else? Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): channels(wsh): nixpkgs: Maintainer information:
Confirm, I have the same problem (with Xerox WorkCentre). And your workaround fixed it for me too. Thanks!
I wanted to link this issue from the and found that there a comment suggesting that he might have the same problem. does the above workaround make your setup work without restarting cups after booting?


If yes, I'd update your comment, because it's not accurate. The is not needed, because it is pulled in by mentioned on the previous line.
Hi, I'm back and I'll test your workaround soon. About , I thought it should have been pulled, but it wasn't at the time. I vaguely remember triple checking and it wasn't there.
Sorry, I can't test it again. My printer is busted.
OK, thanks for letting me know :-)
Ok, my printer has sudently revived and this solves the issue for me as well.
I marked this as stale due to inactivity. →
Confirming that the issue still exists with current nixos-unstable.
Out of curiosity, is this workaround supposed to break or use outdated softwares? If not, would it make sense to directly apply your workaround by default?
This workaround makes mDNS working only for IPv4. If you are on a IPv6-only network, mDNS won't work for you. On mixed IPv4/IPv6 network, you might not see some devices. That's definitely not what some people want :-) Btw, may be relevant to this problem. I've not read all the comments there, but the keywords seem similar to what I remember when debugging this issue. I think the solution might be to increase or decrease some timeout somewhere, but I'm not sure where. More debugging/analysis is needed.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Same happening here with a Canon MF643C. I found a workaround, but yours seems better. Mine was to manually add the expected on '/etc/hosts' file. This only works if your printer has a fixed ip (like 10.1.2.3). networking.extraHosts = '' 10.1.2.3 '';
I also hit this issue. Given that (I assume) most people are running ipv4, can we not try the v4 exclusive module first, and still fallback to the one that also works with v6, so that it "just works" for this rather common use case? Given, that will slowdown v6 name resolution, but I guess we could also add a big warning in the option.
Looks like this is closed by
Unfortunately, that commit is not sufficient for me.


Current version of CUPS complains with: "No destination host name supplied by cups-browsed for printer "BrotherMFCL2700DWseriesmDNS", is cups-browsed running?" The referenced commit makes my contain the following line: hosts: mymachines mdns4minimal [NOTFOUND=return] files myhostname dns mdns With it, running returns an IPv6 address: fd76:76f3:2dcb:0:3205:5cff:fecb:4509 From the output of it seems that the command first asks for IPv6 address, so the is somehow ignored and the address is returned by at the end of the line. I can ping and connect that address via so I don't know why CUPS cannot print to it. Anyway, if I disable IPv6 in the printer, returns the IPv4 address, but only after the 5 second timeout, which is too long for CUPS. What I need is also at the end of line. I'll ask at and submit a PR to do that if people do not complain.
Please submit a PR.
Uses a direct printer install. Same sort of problems encountered.


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


Describe the bug In order to be able to invoke the command from teleport is using  call. There is a wrapper around to bring into PATH . That means is invoked from without wrapper and the browser page never opens (due to missing ). To Reproduce Steps to reproduce the behavior: Expected behavior The path to the wrapper must be persisted in the Screenshots If applicable, add screenshots to help explain your problem. Additional context Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata Please run and paste the result. Maintainer information:


Inkscape has support for openclipart but it doesn't work in the package provided by nixpkgs. inkscape to File -Import Clip Art... a search term and click the Search button. the in the GUI and in the terminal. NixOS 18.09 and nixpkgs master.
I researched a bit and thought adding glib-networking would fix it. I wrote the following patch, but it doesn't seem to have any effect:
I wonder whether it really is because TLS support is unavailable, or because uses an invalid security certificate?
Good point. Hm, that's weird. I followed that URL () a day or two ago (when I first noticed this) and was redirected to https:// without problems. But now I see the certificate warning in firefox.
I think it may be a packaging bug after all. Look at this grep: The message only appears in the glib tree, in the gdummytlsbackend.c file. No matches from glib-networking, which AFAIK, provides TLS support.
I tried the patch and am getting Probably because the site is down.
is not down for me.
Thank you!


Steps to reproduce the behavior: gmic in a nix shell using the unstable channel Add any other context about the problem here.
Will be fixed by
Thanks! Note that it makes darktable fail to build.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


Describe the bug Building packages that use always try to use all cores, independent of ( argument to nix-build) To Reproduce Run , and observe that it spawns many rustc processes (depending on the amount of available processors). Expected behavior The function should pass as argument to cargo. Additional notes Fixing this will probably cause a rebuild of all rust packages, so should we batch this with other changes to the cargo builder? Notify maintainers
has been merged


For x8664-darwin, aarch64-darwin: build .#EBTKS x8664-darwin: aarch64-darwin:


Package name: ArchiSteamFarm Latest released version: 5.5.2.3 <!-- Search your package here: --- Current version on the unstable channel: 5.5.0.11 Current version on the stable/release channel: 5.4.12.5 <!-- 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]:
It helps if I also open the PR when doing the update


Project description A simple, high performance relay server written in rust. Metadata homepage URL: source URL: license: mit platforms: Linux, darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Describe the bug When calling somebody using Microsoft Teams, it seems that the softwares fallback on ALSA plugin, which makes the audio output butchered (hearing noises when someone's talking, but unable to understand what this person is saying). To Reproduce Steps to reproduce the behavior: teams (require an Office 365 accounts) somebody Expected behavior It should use the PulseAudio backend during calls. Additional context I'm using Sway as my window manager (thus, running on wayland). Notify maintainers Microsoft Teams package maintainer: Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(ely): nixpkgs:
How can one tell it that it falls back to the ALSA plugin? Apart from the butchered sound that is?
Inside Pavucontrol, you see it uses an "ALSA Plugin" as a backend. It shows ALSA only during a call, on the rest of the software it shows as a standard pulseaudio program output.


Package name: astro-language-server Latest released version: 2.14.2 <!-- Search your package here: --- Current version on the unstable channel: 2.10.0 Current version on the stable/release channel: None <!-- 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]:
I'm on it ^^. I've got a working version. Gonna soon open a PR :+1:


Steps to reproduce the behavior: floorp Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hi, Please elaborate - there does not seem to be any actual build failure here. What's the actual error? Are you sure your build machine has enough resources? A browser build is pretty demanding and can take even multiple hours on low-to-mid-end machines. Can you please also post the complete derivation log, as obtained using ?
I have the same problem (with floorp and floorp-unwrapped). Here’s the error: ! That feature was removed in February, so either update the qcms crate to 0.3 or downgrade the rust compiler version (1.76 could work).
is the log in the link not enough ?
Oh, I see, Github just truncated the file in the UI. That's what you get from hosting projects on crappy, proprietary software .. Pointing out the exact error too from the get-go would have been helpful in any case. Anyway - seems it broke with a recent rustc upgrade in nixpkgs. This is already fixed with 11.14.1, as it updates the firefox base source. See .
Okay, I will host my opengist instance for the next time ;) Thanks for your prompt response, waiting for your pr to be merged.
Any ETA on the PR merge?
Floorp is now in version 11.14.1 on unstable.


When installing a PWA using the Floorp browser (experimental toggle in settings), the installed desktop file uses /usr/bin/floorp as the path for the browser to run said PWA. Steps to reproduce the behavior: Floorp experimental PWAs in settings a PWA, e.g. Github or Excalidraw the newly spawned PWA window to launch the same PWA from your DE's application launcher The PWA opens. ! , using flakes, installed via <!-- 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]:
Thanks for reporting! As well as the upstream report! I can look into it what we can do as I get time. But as I'm the only maintainer for Floorp and currently pretty much out of time due to university and $dayjob, I cannot promise any timeline unfortunately. But happy to review patches, of course, if you'd like to fix it yourself. Can you provide such a generated file for further investigation?
sure, one such generated desktop file with the example of excalidraw can be found (github doesn't allow for drag and drop of .desktop files)
Hello! I don't have experience maintaining and modifying large packages like Firefox (floorp), and I currently don't have much free time. However, I've discovered how floorp generates the .desktop file for PWA applications: Maybe it will be helpful to you.
Thanks, that is indeed helpful! Should be relatively easy patchable by us then, from the looks of it.
upstream has and now it will use the path it was in at the time of creating the PWA. It may not be too big of an issue if what they say about fixing it in the next version is true but now the patching will probably fail.


Panel applets are being picked up from environment variable in and a completely hardcoded path in . First, we will need to patch the latter manager to use an environment variable as well. Second, we will need to do something similar to what . Or better, create  derivation. Originally posted by in
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
I'd like to tackle this, do you have any pointers? We need to get it to pick up at least right?


broke with the new Darwin stdenv changes. See log file here: This is a bit odd because Homebrew doesn't appear to be doing anything special to compile it:
I think we can use llvm 6 here to fix this. It is weird homebrew doesn’t hit this though. I wonder if the SDKs are still on libcxx 6?


blender to import a gltf model get a huge error, but no model and will be fixed with blender 3.5. But as that is probably still a few months away, I would actually quite like to continue using blender on nix until then. system: host os: multi-user?: sandbox: version: channels(root): channels(betalars): nixpkgs:


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


inadyn enabled via doesn't cache the discovered IP address. Therefore every time the service runs it forces an update with the DDNS provider. Enable inadyn service, e.g.: Review the service logs and observe that it forces an update with the DDNS provider every time it runs, even when the IP address is the same. Notice the cache directory is empty. With the above config there should be a file created after the first run with the IP address as contents. When the service runs again at the specified interval and the IP address is the same, it should not update the DDNS provider. N/A The relevant service definition is: According to the env var is the absolute path defined by , so it is not . Therefore the command line is setting inadyn's cache directory configuration to , which doesn't exist, and it silently ignores the missing directory. should then be: Manually overriding is working for me. <!-- 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]:
thanks for the investigation, this sounds right to me! Would you mind opening a PR doing the proposed change, and link it from here? Happy to take a look :+1:
Thanks for the report. I won't be able to make a PR for a couple of days so it would be great if could. I think this should also be backported to 24.05.


fails to run most basic commands when installed via nix, due to an error seemingly related to it's vendoring of some dependencies. On a NixOS machine or Darwin with Nix installed, run: <details<summaryPEXVERBOSE=9 nix shell -c pex</summary</detailsA pex-managed python repl should open, same behavior as in a venv. For comparision: <details<summarynix shell nixpkgs#python3 -c sh -c "python -m venv ./venv; ./venv/bin/pip install pex; ./venv/bin/pex"</summary</detailsthe site-packages path where pex lies is in the /nix/store, so read-only. however, the the vendored dependencies are included in the closure; exists and includes attrs, pip, etc. maybe could help us interpret the error and/or how to debug this efficiently? :) some simple commands such as do work. same commands run fine in a venv on the same machines using the same python intepreter. same symptoms on NixOS and when installed via nixpkgs unstable on darwin. the tempdir path mentioned in the error message is writeable, but non existent or cleaned up. the alternative script/entrypoint shows similar symptoms: <details<summaryPEX_VERBOSE=9 nix shell -c pex3 lock create requests</summary</detailsHope you don't mind the pings (maintainer) (done multiple recent updates) (pex developer)
NixOS is pretty exotic in my world. Can you confirm that I can use a container to emulate this? I assume I can, but just to check. I'll be back at a keyboard August 3rd to repro, but I expect the workaround for now is to set PEX_ROOT somewhere writable. Pex does try to detect the default is unwritable and fall back to tmp, but perhaps all these measures are foiled in this environment.
wow, that was fast! :) Should be able to emulate in a container or almost anywhere you can get a recent nix with flakes enabled running. Let me know if can assist you with that!


(contact info in profile) Many environment variables like and are different when run via nix (symlinks to /nix/store), but "~/" and other filesystems are not namespaced or sandboxed in any way here. is writable by my user. I've tried with PEXROOT set, but that didn't incfluence the output. Going to have another look tomorrow, but it's quite late already here in CEST.
I don't think notifications are sent for linked issues; think I found a fix in Thanks to for pointing me into the right direction
Ok, this works perfectly fine in nixos (N.B.: I 1st used the vanilla image which is not sandboxed and everything worked fine; so I went through a bit of extra effort below to enable sandboxing in the image and prove it out to see if the sandboxing behavior was relevant to repro): So I'll try to repro using .
Ok, after following the multi-user install instructions for the command here: and enabling flakes, etc - I do repro: So, for someone with knowledge of nixos vs nix shell vs flakes, this would presumably mean something. I'll continue to dig in my shell to see what's up.
Alright, Pex 2.1.141 should fix. Please let me know either way
Sandboxed builds do not work inside Docker as we can't create required namespaces from an unprivileged container.
I've tested a build against your tag and that works just fine on NixOS (with sandboxing enabled).
Ok, great. I used in addition to mounting in that custom nix config.


Steps to reproduce the behavior: -rebuild test on settings.datadir = "/mnt/garage0"; resolves fine Tested on nixos24.05 but code of the module is unchanged in nixos_unstable. I'm using flakes as well Please run and paste the result.
Looks like doesn't apply, maybe should tinker a bit on my own
It looks like the option type was adjusted, but not the other code in the module that checks that value. Shouldn't be too hard to fix.


Ffmpeg 6.1 supports vulkan video, but it is not enabled in the default version of ffmpeg, it is only enabled in ffmpeg-full. The default version of ffmpeg should support vulkan video so that applications like mpv can use it. Arch enables vulkan by . Vulkan video already works with amd GPUs using ffmpeg-full with this command: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This seems reasonable. I'm in favor.
EDIT: Error on my end, skip reading this. Hm, your command doesn't work for me on Mesa 23.3.3: Another aspect to consider is closure size.
If you haven't tried already, can you try with something in h264? Vulkan video currently only supports h264, h265 and av1(experminental), and only if you gpu supports them.
Indeed it's h.265, let me try h.264. This looks like a generic VK issue though.
As suspected, this happens on h.264 too.
Do you have multiple GPUs in your system except the amd one perhaps? This chooses the first one arbitrarily.
Same error for all.
Then I am not sure about what's causing it, that's the exact same error I receive when using ffmpeg 6.1 instead of ffmpeg-full 6.1.
Uhhh about that... So and that commit didn't seem to have been pulled into this brain thingy of mine... It works as expected with ffmpeg-full.


Project description Formatter for typst. Metadata homepage URL: source URL: license: mit, bsd, gpl2+ , ... platforms: unix, linux, darwin, ...
There is no CLI:
Looks like the author use .
looks like it is still a WIP in
what do you mean wrong default branch? Hi there, I wasn't sure there was interest for a cli, I'll merge the cli in a few days, want a ping then?
I merged my change, it should be good to package!
has renamed the project from typst-fmt to typstfmt in


The build attribute of the last state of the package contains a expression to substitute tool names with its Nix packages. The scrip substitutes with the git package, which includes and similar regex used in the script. Script : Packaged script in my nix store: Steps to reproduce the behavior: the package and inspect its output The regex keys aren't substituted by the git binaries store location. <!-- 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]:


In the pre-start script for , we symlink the template from the nix store into : However, if changes are made to CUPS via the GUI -- for example, enabling network access -- this symlink is overwritten with a plain file. And it contains a line with paths into the nix store. This effectively freezes some version of the cups binaries into this config file, which is no longer managed by nix. As a result, CUPS can break, e.g. when deletes the referenced store paths. For me, this meant nothing would print, and I started seeing this error in : Manually editing to update the store paths on the line (while the systemd service was stopped) got printing working again for me. I guess we could make the pre-start script do this (with a sed or something), but that seems kind of hacky ... cc commit seems especially relevant here. System: Nix version: Nixpkgs version:
Hm, maybe the right approach is to make just put in the template, and then have it also ensure that points to the correct location in the nix store? Then CUPS can write whatever other changes it wants to its config file, while the nix expression continues to have control over the "final destination" of the path ... ?
I think we want Nix to take priority here because that's what would be expected of declarative configuration and what's already done in other places. So as a quick fix towards this we can force replacement by symlinks. This should also be documented. However, we can leave some option (like currently exists for users) that reverses this and instead makes just insert and other required options. The best of both worlds, of course, would be to split the configuration into generated by Nix and values changed in CUPS on top but I doubt this can be implemented. Thoughts?
For the record, I had the same problem in OctoPrint service. It was solved by writing a small piece of software for updating YAML trees (like in Nix) and making "patch" current configuration with Nix-overridden values. Works perfectly but it would be much more difficult in CUPS ( is some kind of ad-hoc mix between XML and custom plain format).
Yeah, I don't see any directive on the manpage for .


:-( Overwriting the config file on every restart of might lead to confusion if folks are trying to use the GUI to get things configured the way they want. In particular, when I made changes in the GUI to enable remote access, it modified some of the stanzas that're currently hard-coded in at So I'm not sure how I would preserve that under this approach. (I tried to just set via , but that wasn't enough -- I don't really understand why ...)
Its man page says: ... but a bit of googling didn't turn up any pre-existing programs designed to read / write that format. (Maybe there is something buried in apache , who knows?)
There is But then you need to write Perl, which might not be an improvement.


This configuration: If you poke around in the configuration I linked, you should see that I disable NetworkManager and use a static configuration for my main NIC. I can't think of anything special in my config or with this machine that would affect my usage of Wireguard, but I'm also new to using Wireguard. I'm currently on nixpkgs with a few of my own commits on top of . Please run and paste the results.
It doesn't seem happy when already exists... I have done two things, both of which were necessary, to resolve this: the link manually () sure the path to the private key exists (if not, you get a different failure in the journal, with failing). (It's possible that fixing the private key path and rebooting would have been sufficient). I'm leaving this open for two reasons: user should receive a better error message in both cases. that we're in NixOS, we should assume full control of the interface and just re-configure it, instead of failing in the setup script.
I ran into this issue after trying to debug my wireguard setup. My setup is essentialy identical and I get the same error message. Running the start script that is causing the error results in this output. The offending 2 lines are .
I had to go one step further than deleting the interface. I needed to stop the via then redeploy configuration. But this solved it for me. Nixos should handle this much more gracefully.
I had to remove the routes with etc.
The command is . You can build it in your conf as pre-setup command, but it has the nasty side effect that it possible interferes with other connections.
I am still running into this issue.


branch to nixos-unstable to your with
Bisect has identified (specifically ) as the source of this failure in nixpkgs, cc See also upstream issue
If you're using a flake, this is how I was able to mitigate this until it's fixed. I rolled back the changes from in a branch on my fork, and used it as an overlay for the affected packages like this: This is how you would add them to your overlay: Ofc, depending on how you do stuff, you'll have to fiddle with it a bit to get it to work. I found this helpful:
The fix is now on the nixos-unstable branch, but I still cannot build my system after updating, with the same build failure for opencolorio. Is this expected?
Probably not, since and both build on Hydra.
Oh thank you, this is very bizarre. I will ask on the forum what's going on
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


fails to build in because of a hash mismatch Here's a log showing it: I noticed this when built a PR for 20.09. It appears that the same package builds fine on . cc


Describe the bug VIber package in nixpkgs repo is broken/outdated. Getting this errors when trying to install it: To Reproduce Steps to reproduce the behavior: to install viber via config file/nix-env. Expected behavior Successful viber installation. Metadata system: host os: multi-user?: sandbox: version: nixpkgs:
have the same issue
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .


Describe the bug When installing viber, the download step won't complete because the package has an incorrect sha256. My nixos version is 19.03.. (Koi) To Reproduce Steps to reproduce the behavior: Ensure that you can install non-free packages: a) For you can set { = true; } in to override this. b) For , , or any other Nix command you can add { allowUnfree = true; } to then: Expected behavior Viber should install Screenshots Additional context Add any other context about the problem here. Metadata Please run and paste the result. Maintainer information:
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
This is still reproducible. Is there an archive of Viber versions anywhere so we can pin Viber versions or do we have to constantly play catch-up with them?
I have the same issue, but in my case the SHA got is different:
I marked this as stale due to inactivity. →


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


On with , the tests fails with the following error: Steps to reproduce the behavior: -shell -p python3Packages.scikitimage The tests run without errors. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- system: host os: multi-user?: sandbox: version: channels(smaret): nixpkgs:


Project description Raze is a fork of Build engine games backed by GZDoom tech and combines Duke Nukem 3D, Blood, Redneck Rampage, Shadow Warrior and Exhumed/Powerslave in a single package. It is also capable of playing Nam and WW2 GI. Metadata homepage URL: source URL: wiki URL: license: non-build code: , build engine & tools: platforms: linux The build instructions should be the same as for gzdoom, so I want to notify the maintainer of gzdoom if he/she is interested in this. Also I want to notify the maintainer of eduke32 because this project could more or less replace eduke32(?)
I can take a look, but my current schedule is pretty full. maybe at the end of the year? But if someone else is happy to do it, feel free and ping me on the PR
Might take a look next week. EDuke32 replacement probably won't do, because iirc HRP runs only on it etc.
Thank both of you to possibly have a look into this. I think you're right. But I see that three projects: Enhanced Resource Pack Fixes for Duke Nukem 3D Duke!Zone II Fixed Release of the got raze support, already. Possibly HRP will follow sometime...


We got theses reports of Kubo panicing on startup due to probably an empty field This is a bug in our software however I belive this is also a bug in: Because a Kubo daemon without an API listener is borderline useless, your choice to change to a unix socket () makes sense however I think some default got lost and now it is set to . Given I am not a Nix user myself I got help from to fill in the template, thx :heart:. Steps to reproduce the behavior: to notice it's failing with a panic. After installation Kubo daemon should start and the RPC should be usable by a permissioned user. Please run and paste the result.
/cc (I forgot to fill it in the template and I don't belive GH pings peoples from edits)
Weird that it works on my machine and in the NixOS tests. One of the NixOS tests only has and options set. does quite a lot but I didn't see anything obvious why this should affect the API settings. But maybe it does make a difference and maybe I specified some additional option on my machine makes it also work there. I'll try to reproduce it with just the enable option set in the next couple days. On one machine shows that the field is set to and yet Kubo starts without a problem and can be seen in the log. According to a comment at the top of, , "Enabling this [socket file] will completely override any API listeners configured in your config.". NixOS enables this socket file and overrides with (which is ) plus whatever the user has set in . What I don't know is how systemd communicates this information to Kubo but this seems to work. So in conclusion, I would think that setting the field to in the Kubo config doesn't matter because is enabled, which should override this and specify a socket for the API.
Thx I wasn't aware we even had this feature (or that you could use systemd to configure application sockets in the first place). We have a simple incorrect assumption which is panicking since kubo is configured without listeners. However this is fed by which tries to load as you linked. So if you have a but use something like it should work (AFAIT).


I can't test experimentally that feeding the API through systemd works right now, I'll report later, but it seems to me that the like config is not applied somehow.
I was able to reproduce the problem. Maybe I just need to order the unit after the two socket units. I'll take a closer look in the following days when I have some more time.
This happened to me too on first installation, the reason was that systemd couldn’t bind port 8080 because it is already in use by another service, then started Kubo anyways. So my theory is that Kubo checks if there was a socket made available by systemd and if there was none falls back to trying to read the listen address from the config (which is then null) and then panics in the observed way. For anyone else affected by this, run and check if both sockets were correctly bound when Kubo crashes in this way.
I created , which should fix this.


Bug description nixos-build switch produces a build error due to firebird-2.5.7.-0 while firebird is not explicitly mentioned anywhere in the file... To Reproduce -channel --update -build switch error message a few apps from file hoping that one of them would be asking for firebird to be installed behind the scene at no avail... Expected behavior A clean error free build. Screenshot ... making all in engines/ccgost... g++ -DREENTRANT -I. -I../common -I../common -I./unicode -I./.. -DREENTRANT -DHAVECONFIGH -DULAYOUTIMPLEMENTATION -O -c -DPIC -fPIC -o HebrewLigatureData.o make[2]: Entering directory '/build/openssl-1.0.2u/engines/ccgost' gcc -I../../include -fPIC -DOPENSSLPIC -DOPENSSLTHREADS -DREENTRANT -DDSODLFCN -DHAVEDLFCNH -m64 -DLENDIAN -O3 -Wall -DOPENSSLIA32SSE2 -DOPENSSLBNASMMONT -DOPENSSLBNASMMONT5 -DOPENSSLBNASMGF2m -DRC4ASM -DSHA1ASM -DSHA256ASM -DSHA512ASM -DMD5ASM -DAESASM -DVPAESASM -DBSAESASM -DWHIRLPOOLASM -DGHASHASM -DECPNISTZ256ASM -c -o egosterr.o egosterr.c g++ -DREENTRANT -I. -I../common -I../common -I./unicode -I./.. -DREENTRANT -DHAVECONFIGH -DULAYOUTIMPLEMENTATION -O -c -DPIC -fPIC -o HebrewShaping.o g++ -DREENTRANT -I. -I./common -I./common -I./unicode -I./. -DREENTRANT -DHAVECONFIGH -DULAYOUTIMPLEMENTATION -O -c -DPIC -fPIC -o IndicClassTables.o gcc -I./.


/include -fPIC -DOPENSSLPIC -DOPENSSLTHREADS -DREENTRANT -DDSODLFCN -DHAVEDLFCNH -m64 -DLENDIAN -O3 -Wall -DOPENSSLIA32SSE2 -DOPENSSLBNASMMONT -DOPENSSLBNASMMONT5 -DOPENSSLBNASMGF2m -DRC4ASM -DSHA1ASM -DSHA256ASM -DSHA512ASM -DMD5ASM -DAESASM -DVPAESASM -DBSAESASM -DWHIRLPOOLASM -DGHASHASM -DECPNISTZ256ASM -c -o gost2001keyx.o gost2001keyx.c error: narrowing conversion of '' from 'unsigned int' to 'icu30::IndicClassTable::ScriptFlags' {aka 'int'} [-Wnarrowing] 229 | static const IndicClassTable teluClassTable = {0x0C00, 0x0C6F, 3, TELUSCRIPTFLAGS, teluCharClasses, teluSplitTable}; | ^ error: narrowing conversion of '' from 'unsigned int' to 'icu30::IndicClassTable::ScriptFlags' {aka 'int'} [-Wnarrowing] 231 | static const IndicClassTable kndaClassTable = {0x0C80, 0x0CEF, 4, KNDASCRIPTFLAGS, kndaCharClasses, kndaSplitTable}; | ^ make[4]: [./config/mh-linux:43: IndicClassTables.o] Error 1 make[4]: Leaving directory '/build/Firebird-2.5.7.-0/extern/icu/source/layout' make[3]: [Makefile:98: all-recursive] Error 2 make[3]: Leaving directory '/build/Firebird-2.5.7.-0/extern/icu/source' make[2]: [ libicu] Error 2 make[2]: Leaving directory '/build/Firebird-2.5.7.-0/gen' make[1]: [Makefile:193: externallibraries] Error 2 make[1]: Leaving directory '/build/Firebird-2.5.7.


-0/gen' make: [Makefile:6: firebird] Error 2 builder for '/nix/store/589jgyzjbbn6zl870qswm80pi4xh8ffq-firebird-2.5.7.-0.drv' failed with exit code 2 building '/nix/store/f5v53hni9pnldx4l0v4svxv0ibl62ir3-tor-browser-linux64-9.0.9en-'. cannot build derivation '/nix/store/c1wpclz112ssp5ki6m546llszn144bq8-wt-': 1 dependencies couldn't be built cannot build derivation '/nix/store/8izfzp2k51zz3385cq14ffd31l2c8bwg-fileshelter-': 1 dependencies couldn't be built cannot build derivation '/nix/store/wi7fzbgmwj9rrzm48mlcsvw51lymmcz8-system-': 1 dependencies couldn't be built building '/nix/store/75r17sql3df7jq3azd76w9fjw6870wm6-'. building '/nix/store/0zq0cb92k0w72ri9jb2zd65gzpnhx6fv-udev-'. building '/nix/store/jqc775s8a0m6r6qhwcfssjdya326s6z0-unit-NetworkManager-'. building '/nix/store/bvg0a7ah4bd77s86f16rq7jsl7sh3nxy-unit-NetworkManager-wait-'. building '/nix/store/vbnnzk9kdx828c8vi3pqcjayrf1ja43n-unit-'. building '/nix/store/df1ffd22pbca5x7ya5mwa8prm40mg54p-unit-alsa-'.


cannot build derivation '/nix/store/4375h9w8pmppld22s4jb6ag05riw87vg-xsession-': 1 dependencies couldn't be built cannot build derivation '/nix/store/gi689m2ph1avv6n2svvlzr5d2v2xm4p1-nixos-system-bx26-': 1 dependencies couldn't be built error: build of '/nix/store/gi689m2ph1avv6n2svvlzr5d2v2xm4p1-nixos-system-bx26-' failed Notify Weber <marco-<!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata* system: host os: multi-user?: sandbox: version: channels(root): channels(k): nixpkgs:
This is pulled in as an indirect dependency of via .
I marked this as stale due to inactivity. →


Versioned QML import paths introduced in will lead to broken kde applications. Issues include visual glitches, disabled mouse scroll, and potentially other functional problems. A temporary workaround exists, but a proper fix is needed. Steps to reproduce the behavior: your nixpkgs to leatest version. a KDE application that uses Kirigami (e.g., KDE Systemsettings). broken behavior (visual glitches, scroll issues). with . (this partly undoes changes) expected behavior. KDE applications run normally without any visual or functional issues. Start application normally: ! ! Start application with : ! Qt related configuration of my system: Although Kvantum is installed, disable it won't fix this issue. Same problem also occurs under breeze theme. <!-- 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]:
Can you post the values of and in the environment you're running it from? Also, does this still happen if running with those variables unset?
Here is my environment. <details</detailsThis still occurs when running with .
Can you run it with and post the log?
As requested, I've attached the relevant logs for analysis: ,captured with , captured with The initial attempt with didn't produce desired logging output. Therefore, I ran it again with the additional setting.
Does it work if you add and to ?
It works. QML components render normally now, under both Breeze and Kvantum themes .
I also encountered this issue. Adding and to alone didn't fix it for me. I needed to set as well for it to work.


Steps to reproduce the behavior: librewolf from nixpkgs master Add any other context about the problem here. Please run and paste the result.
I have the exact same issue but my machine is a little slower :|. Also this means (not just Git ) is now broken.
I also reproduced this on master.
I think it's related to . I'm guessing the crash reporter symbols aren't generated because we disable the crash reporter. Running some tests to confirm.
is the first broken commit on master.
I'm going to close this. The PR by fixes the problem.


Describe the bug fails to build on armv7. It compiles, but then fails one test, making the derivation fail. To Reproduce on armv7. Expected behavior The build completes successfully, passing all tests (except for tests known to be broken). Screenshots Additional context I'm currently trying this on , but with reverted because of . I'm using '<nixpkgs/nixos' since I have a few options set to minimize build times and I'd prefer not bootstrapping from gcc/binutils/etc just to see llvm fail later, but if you insist I can try building it with a clean config. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Note that that is showing the nixpkgs version for my currently running system. I'm trying to build it for a newer version of nixpkgs, listed above. llvm11 failing is currently blocking me from upgrading since I need borgbackup and it has a transitive dependency on llvm11 now (through the Python cryptography module and rust). Maintainer information:


Project description <!-- Describe the project a little: --Metadata homepage URL: source URL: license: platforms: darwin


Project description Volume control applet for Pipewire, written in Rust. <!-- Describe the project a little: --Metadata homepage URL: source URL: license: mit, bsd, gpl2+ , ... platforms: unix, linux, darwin, ...


Darktable can make use of OpenCL, but the nix package apparently isn't set up properly to allow this. Run : system: host os: multi-user?: sandbox: version: channels(root): channels(lukas): nixpkgs: OpenCL is set up properly on my system: cc darktable maintainers:
I'd been meaning to fix this for myself for awhile. Should be good now, pending review.
Thanks!
Sorry to revive this, but I am still having this problem in dartable 2.4.4 using intel OpenCL Neo driver. Should ti be already solved? Or the fix is still not present in 2.4.4? Thanks
Disregard (at least partially) my last comment. I was using the snap version in Ubuntu 18.10. Using the deb, OpenCl works. Where should I submit the bug for the snap version?


Project description A very small, very simple, yet very secure encryption tool. Metadata homepage URL: source URL: license: gpl3 platforms: unix, linux, darwin, windows


Steps to reproduce the behavior: diffutils-3.10-riscv64-linux i had suspended the system halfway through the build, and suspected that might have caused an issue, so i ran the build again and got the same result <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I can't reproduce this failure on RISC-V hardware. With , the following command runs just fine: Could this be an issue with the emulator you're using or a result of ?
The following command also builds for me. Relevant excerpt of the logs: Could you try running this in your build environment to see whether it's an issue with your emulator or build machine? If it builds, could you improve the reproducing instructions you've given?
I ran that command on a seperate x86 machine and recieved the same build failure
I have successfully reproduced the issue by emulating RISC-V on an x86 machine. So this could be caused by a QEMU bug. I suggest you update the title to make it clear that it only happens with binfmt emulation.
Ok i edited the title
i'm curious why the gnugrep pr was merged, but not this one ? given that confirmed this build failure, but not the other one ?
The other one just got the attention of a committer a bit earlier


was recently updated to use LLVM 4.0, which is rather good news for my use cases. Can we update our version to use this? It also seems they now so perhaps we should switch to using that as well? (maintainer)--LMK your thoughts and if you want to tackle it or want me to (I'd probably get to it this weekend). Thanks!
I'm pretty busy these days but if you're interested in updating it feel free :+1:
Sure thing! Although actually we'll need to actually add LLVM 4.0 first, forgot that wasn't in-tree yet :innocent:. Maybe I'll give that a go as well :+1: (cc )


Describe the bug is broken in latest master To Reproduce Steps to reproduce the behavior: -build -A lieer cc
I reverted locally, and got it to build again - so it's definitely some incompatibility with the openssl we pass in.
that commit is from 4 years ago, I wonder why it's making an appearance now
This error seems to be present since (more specifically ), so is probably mostly unrelated to it.


Incus fails to find when launching a VM. (There is no problem launching a container.) It exits with the error message: Lines 1815-1824 of in the looks for it at or in the path. I think it means that there is a fixup that isn't being done. Steps to reproduce the behavior: (The specific image doesn't seem to matter.) while the VM is created... It exits with the error message above. that is installed at just not being found. Launching a VM should work as expected without the error message. <!-- 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]:
While that path does appear to be hardcoded in Incus, I'm not able to recreate the error on my zfs storage pool. Can you provide more information about your storage setup, including the output of
Never mind I see the problem. Will take some time to get this reviewed, backported, and available to 23.11


Steps to reproduce the behavior: xdg-desktop-portal-hyprland-1.3.3 This issue only recently occurred upon updating to the latest revision. My entire nix config is . <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I suspect this is fixed by For some reason has a pkg-config that defines that it has a non-existent include directory, which cmake then later chokes on since it declares it has a dependency on as a package, not a tool.
Indeed. I'm cooking up a PR for this.


It looks like Qt has broken support for SDK 10.10 in their latest release. Here is the log: Any ideas on how we can fix this?
fixes this.
We should probably keep this open tho, we can't keep using


When tries to create a volume of type=block, it cannot be created due to the occurrence of . This is because is not registered in . Steps to reproduce the behavior: Create block type volume. If you check nixpkgs for lxd 5.20, you can see other package dependencies that are not present in incus. For example with lvm, this is expected to severely impact the lvm backend. (Currently, it cannot be confirmed because there is no lvm drive.) Can we change it in the same way as lxd? <!-- 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]:
Opened a PR to fix. Sorry about that. Not sure why I dropped these...


The original author of gitless has not committed any code to it since 2021, and the version currently in nixpkgs errors out when trying to do anything useful with it. has forked and continued to develop it though: Package name: gitless Latest released version: 0.9.17 Current version on the unstable channel: 0.8.8 Current version on the stable/release channel: 0.8.8 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 for the tag! I'm glad that gitless can live on past the initial MIT research that was conducted. Although it's been a while since I've updated gitless, it has been very useful for my day to day work and I'm committed to fixing bugs in a timely manner.
Sure! I rediscovered gitless (and your fork) on the back of a recent Slack discussion with folks from about the best way to make version control as accessible as possible for newcomers in the research community.


Version V1.3.0.4373 of mwprocapture (the Linux driver for the Magewell Pro Capture family) FTBFS when building against Linux 6.8 or newer. Steps to reproduce the behavior: Add to your Nix configuration. Add to your Nix configuration. Magewell has provided a revised driver update to address this issue. I am working on a pull request for nixpkgs. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Steps to reproduce the behavior: sysdig Add any other context about the problem here. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Can't repro on master () and the error isn't in the log output, can you provide additional info?
Hey, thanks for the response - checking again - it only happens if for me if I enable the sysdig-option in my config not building the sysdig-package - maybe this helps to reproduce and depends on the used kernel-version? I've uploaded the full build log:
Thanks, seems this is the error:
I guess this is already fixed upstream in the drivers () but needs to be to nixpkgs to fix 6.10-kernel builds.
fixes it for me
~Ah 0.38.1 - got released somehow oversaw it should check first if that includes the fix~ 38.1 does not include a driver-bump


Build of failed on x86_64-linux as of . This is currently breaking . python39Packages.tensorflow-datasets maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tags:


Describe the bug When adding to the NixOS configuration the udev rules do not get installed. To Reproduce Steps to reproduce the behavior: mixxx with a DJ controller plugged in. controller is not recognized by mixxx Expected behavior The udev rules are in the correct folder i.e. or and therefore the udev service does not recognizes them. Additional context The fix in worked for me after a little modification (the rules file got renamed). Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Originally, mixxx did the right thing = install udev files to - see Later they changed the behaviour and they install to - see Sigh.


The package with that are automatically fetched carry no license. ` cc
Poking upstream does not seem to yield anything. They did indicate they wouldn't support this use case, so what are you expecting from them?
I talked to the authors of wp4nix and they are happy for new contributions. It would be nice if the wp4nix script would somehow handle license informations, for example by manually defining them. Not quite sure yet how to implement it
If we don't know the licenses to these packages we honestly cannot keep them around. For example, it is absolutely unclear, whether we have a license to even redistribute them. Of course upstream will take patches, but they're not exactly in the same boat we are. I think your attitude towards the whole licensing situation around wp4nix/nc4nix and its resulting packages is alarming.
As written : Fixing this for Wordpress packages and themes (wp4nix) and Nextcloud apps (nc4nix) in a foreseeable time exceeds my skills and competence. Therefore I would like to offer to add a flag to these package sets and remove them for the next release 23.11 if it's not resolved by then.
Couldn't we mark them as unfree so they don't get cached on hydra but people can still use them if they want? Unfortunately it seems like the wordpress plugins repository doesn't seem to provide the license information in an easy manner. And I don't know whether it is stored somewhere else or can even be extracted from the derivation without import-from-derivation.
Actuallly we seem to be safe in theory. claims
In an ideal world, that would hold true, but it is up to the user and distributor to validate the final outcome. I therefore think this situation remains unresolved.


System: (macOS 10.11.6) Nix version: nix-env (Nix) 1.11.2 Nixpkgs version: 16.09pre-git
may fix this problem for you, though you may also wind up needing something like to get a functional set of go commands on darwin.


Project description cameractrls is a UI for v4l camera settings, like pan/tilt/... on fancy Logitech cameras. Metadata homepage URL: source URL: license: MIT platforms: Linux
Here's a prototype:
I'm using this successfully with the latest version,
Is there any progress with this request?
Please test my PR I don't have the device.
Tbh, I would like to, but I don't know how to test a custom package...
For new CLI: Or
I executed and then nothing happened... I can also not find cameractrls
Check your current directory, there's a symlink to store, and the executable is in
I only tested the gui app and it seems to work fine!
Thanks! What about the others executables? Have you tested all the functionality of the app?
I can only test the the GUI, because I don't know how to use the CLI program. But the GUI is working fine, afaict.


When enabling freshrss and rebuilding, no freshrss systemd service is started. Steps to reproduce the behavior: (as well other requirements for minimal config) (with , for me) The only freshrss units are and . to in browser. Unable to connect. A service with (or something?) is created and runs automatically. The http server is accessible from a browser. I initially tried running in a container, but running on the host OS had the same result Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Freshrss doesn't run as a systemd service. It runs under php-fpm. The associated systemd service is . This is then exposed via nginx. I believe the default nginx configuration will expose freshrss on port 80, so http://localhost may work for your current configuration. The used by nginx for freshrss is . My guess is you'll need to configure it. If you want to access freshrss via "http://localhost:8080" you could use a config like:
Sorry I never responded to this! This worked, thank you.
i guess we can close this then? please report back if i am wrong.
I do agree with qyriad that this could be explicitly documented better, but I don't have any further issue to specifically track
any specific location where you want this documented? where would you look something like this up?
I would probably put in the description of the option.


The NodeJS 12 release goes end-of-life on 2022-04-30, which needs handling before the next release. Worst case we update like in .


Should there be an ability to specify UDP port forwarding in the nat module? It would necessitate an extra property in the forwarding list specification, like .
Has done this!


Project description  Selectdefaultapplication is a very simple GUI application that lets you define default applications on Linux in a sane way. Basically it just loads all installed applications by reading their .desktop files, reads the MimeType fields to see what it supports, and updates with what the user wants. Not all desktop environments provide such a tool, prompting for an agnostic tool. Metadata homepage URL: source URL: license: gpl2 platforms: linux Additional info: AUR package:
You can try using this in an overlay, use .
Seems to work!


Linux Kernel 4.7.3 seems broken, as my laptops keyboard doesn't work. experienced by the arch community too: update, reboot - 4.6 and 4.7.2 work, 4.7.3 doesn't nixos-version: (Gorilla) nix-env --version: nix-env (Nix) 1.11.4 nix-instantiate --eval github/nixpkgs -A lib.nixpkgsVersion: ""
Same issue with kernel 4.4.20 (lts). I can no longer enter my cryptsetup password. The reason is that i8042 is no longer integrated in initramfs, I suppose because of: Update: To fix this issue I had to add it to
Thanks, created a quick fix with your solution, which should fix it for everyone


Building this package twice does not produce the bit-by-bit identical result each time, making it harder to detect CI breaches. You can read more about this at https://reproducible- . nix-build '<nixpkgs' -A --check --keep-failed You can use to analyze the differences in the output of the two builds. To view the build log of the build that produced the artifact in the binary cache: nix-store --read-log $(nix-instantiate '<nixpkgs' -A ) Tested on nixpkgs
PR was merged and made it to nixos-unstable, so this should be fixed


Filing this issue to track related actions in nixpkgs. Feel free to send questions my way and/or contribute via comments in this issue! A buffer overflow in which allows a malicious actor to potentially get code execution in software that displays a specially crafted image file. This impacts pretty much all web browsers, as well as other software which might process or display untrusted images (image editing software, email clients, chat clients, social media clients, etc.). Chrome has rated this vulnerability as critical severity and has indicated that they have evidence some actors are already exploiting it in the wild. This vulnerability was very shortly referred to as CVE-2023-5129, but that second CVE for the same vulnerability has since been withdrawn. Firefox and Chromium are not vulnerable anymore as of 2023-09-16 in and . Direct dependents of the system are also not vulnerable anymore. Some applications bundle their own version of libwebp instead of using the system version (including some other web browsers in nixpkgs: Brave, Tor Browser, etc.). Each of these need to be updated separately by nixpkgs maintainers. See below for a list of all the known applications that need an update and their status. Review/merge any nixpkgs PR that you see pending in the task list below. Help figure out a course of action for . Report your findings and suggested course of action in a comment here, and I'll update the sheet and the task list below. If you have an idea of how to fix/address the vulnerability in any of the packages listed in the task list below, don't hesitate to post a comment here and send pull requests! Feel free to cc me on PRs so I can make sure they're tracked and they don't get lost.[x] libwebp is updated in staging-next (unstable: , 23.05: ) [x] This will make it to master via - said likely this weekend. [x] We need to merge staging-23.05 to release-23.05. That should also finish this week: [x] electron is also vulnerable. Upstream is making new releases on all their supported branches to include the patch. [x] electron 26 bumped in master (). [x] electron 25 bumped in master (). [x] electron 24 bumped in master ().


[x] electron 22 bumped in master (). [x] electron 26 bumped in 23.05 (). [x] electron 25 bumped in 23.05 (). [x] electron 24 bumped in 23.05 (). [x] electron 22 bumped in 23.05 (). [ ] We should figure out what else might be vendoring libwebp. Not sure if there's tooling for this? List of derivations to investigate further and possibly patch: [x] High risk stuff (mail clients, IM clients, web browsers) [x] armcord [x] caprine-bin (, ) [x] discord (, ) [x] Darwin version: / [x] fluffychat () [x] gitter (, ) [x] mailspring [x] mattermost-desktop ( / ) [x] mautrix-whatsapp ( / 23.05 ) [x] microsoft-edge ( / ) [x] mullvad-browser ( / ) [x] palemoon-bin (, ) [x] rocketchat-desktop ( / ) [x] signal-desktop (, ) [x] signal-desktop-beta ( / ) [x] slack ( / ) [x] threema-desktop (embedded electron not used) [x] tor-browser-bundle-bin ( / ) [x] tutanota-desktop ( / ) [ ] Libs that other stuff might depend on [x] flutter [x] libcef ( / ) [x] opencv ( / ) [x] qt5.qtimageformats ( / ) [ ] qtwebengine (darwin only, maybe?) [x] smooth ( / ) [x] darktable () [x] golden-cheetah-bin: ships a vulnerable prebuilt libwebp (cc: [ ] koreader: ships a vulnerable prebuilt libwebp (cc: [x] libreoffice () [ ] localsend: ships a vulnerable prebuilt libwebp (cc: [ ] obs-studio () [ ] rigsofrods-bin (ships a vulnerable prebuilt libwebp (cc: [x] Anything Rust that depends (transitively or not) on libwebp-sys2 < v0.1.8 libwebp-sys2 might silently decide to build its vendored version, if it can't find system libwebp or if the crate feature is enabled.


[x] () [x] catppuccin-catwalk () [x] Anything Rust that depends (transitively or not) on libwebp-sys < v0.9.3 Linking against system webp is intentionally not supported: [x] oculante [ ] .NET software that uses SkiaSharp. Upstream has yet to release a fixed version. () [ ] avalonia-ilspy [ ] BeatSaberModManager [ ] denaro [ ] galaxy-buds-client [ ] jellyfin [ ] mission-planner [ ] mqttmultimeter [ ] opentracker [ ] openutau [ ] ryujinx [ ] scarab [ ] wasabiwallet [ ] Go software linking with (, ) - broken down per vulnerable lib [ ] (unmaintained, likely never getting patched - action should be getting upstream to migrate away) [x] hydron ( / ) [x] mautrix-whatsapp () [ ] () [ ] hugo [ ] Godot related derivations: these should be unvendored (capability already exists in the build system). [ ] godot4 [ ] godot3 [ ] godot3-server [ ] godot3-headless [ ] godot3-export-templates Built using Godot [ ] lorien [ ] oh-my-git [ ] Electron apps where we ship upstream binaries instead of using nixpkgs electron Best course of action: upstream should update to electron = 26.2.1, = 25.8.1, = 24.8.3, or = 22.3.24 and tag a new release [ ] atom [ ] hakuneko [ ] hyper [ ] indigenous-desktop [ ] joplin-desktop [ ] keeweb (unmaintained, mark as insecure?) [ ] keybase-gui [ ] insomnia [ ] mullvad-vpn [ ] simplenoteFor derivations that vendor a vulnerable libwebp, priority list of preferred action to take: De-vendor libwebp and use the version from nixpkgs. (Difficult/impossible for binary provenance derivations.) Update to a new version from upstream that has a more recent libwebp patched for the vulnerability (TODO: how to check?) Mark as at some point if upstream can't be convinced to make a new release.


List of all software in nixpkgs known to contain libwebp:
is now out
i think one way you could check for vendored webp is with nix-locate, searching for , for example darktable might be vulnerable : possibly also koreader the full output
Thanks, that's indeed useful! I think the most common case though would be bundling the code and linking statically with the lib, which wouldn't necessarily be found by this - but maybe I'm just too pessimistic :) EDIT: the ones you found to the tracking in the issue's first comment so we don't lose track of it.
darktable: links with libwebp, the is an internal plugin and is not a vendored version.
koreader: binary provenance, ships a vulnerable prebuilt libwebp (cc:
localsend: binary provenance, ships a vulnerable prebuilt libwebp (cc:
golden-cheetah-bin: binary provenance, ships a vulnerable prebuilt libwebp (cc:
libreoffice sources file lists a libwebp- (or libwebp- for libreoffice-still)
, vendor libwebp via the rust crate libwebp-sys2
Ugh, and good luck finding all the things that end up transitively depending on that crate I guess. I suggested they file a GHSA so dependabot can go and do its thing, but it might still take a while to trickle down through dependents. Anyway, libwebp-sys2 version 0.1.8 looks like it's fixed.
There's also and I can't seem to find the vendored code by grepping for strings in the binaries. Would need further checking, but I'm tempted to say libreoffice is fine?
The libwebp-sys2 crate also will link against the system libwebp if it is found. I'm currently compiling a list of rust packages that use libwebp-sys2.
But since it transparently falls back to the vendored source, I'm going to assume most Rust programs in nixpkgs haven't bothered declaring libwebp (and pkg-config?) as buildInputs... But at least that might give us a lever to patch without requiring an upstream cargo deps bump?


the application has enabled the libwebp-sys2 'static' feature, then it will skip looking for the system one and build its own
Unsure how to deal with the libwebp-sys2 things, which would still be vulnerable for cross-compiling and pkgsStatic. Opened an upstream issue:
Hi! Sorry for just popping in randomly, are there any publicly available workarounds for this issue currently? I'm on , but it seems like firefox nor others have gotten their version bump on that branch.
Not really, and as noted in this issue's description relying on the browser's version number is misleading here (because nixpkgs doesn't use the vendored libwebp, so what matters is the version of the libwebp dependency). If someone wants to write instructions using I'll gladly add those to the issue description for future reference.
On the branch we're only missing a few thousand builds per platform right now, so I'd hope for to update tomorrow.
From the : So looks like this one is fine. I'd remove the vendored download to prevent confusion, but looks like this is automatically generated...
staging-next was merged to master, so users on nixos-unstable should have their browsers patched on the next channel bump.
Fixes for Tor Browser & Mullvad Browser:
Hi! I use the branch specifically in my flake, any ETA on when that branch will get the update pushed?
Depends on how fast stuff ends up rebuilding, I'd expect within 1-2 days at the latest. It's all in automation's hands at this point, unless there's somehow a breakage we didn't notice. You can switch to which already has it (but might require you to do more rebuilds from source), or follow for the status of the fix.
I think I might channel-switch for a bit for this fix, thanks for the help!