crackmapexec fails to run on the unstable branch. Full backtrace : Steps to reproduce the behavior: Should be marked as broken for python 3.12 and above due to not being maintained anymore, it should be recommended to use the maintained fork . If applicable, add screenshots to help explain your problem. I may PR a proper fix later if I find time to do so <!-- 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 don't know if removal was the best choice for this tool but maybe has all the features that had so it's alright. It's just that I'm not aware if there are any bugs that are not in that are in but I understand why removal makes sense since later we'll move onto later version of Python such as 3.13 and further more
As is a fork, I guess that the feature set is comparable or even bigger in the meantime. is still available for 24.05 and could still be used after 24.11 with some magic.
I ran into this issue where didn't have it, it is just a minor issue so it's alright on my side, but not sure if there will be any more issues I'll ran into later :


CMake seems to use ps command internally, but looks like CMake in nix on darwin can not find ps command, so it complains with message "sh: ps: command not found." (very many times) Although this does not seem to harm build, it is desirable if this can be solved quite easily by some simple patch.
I found a similar problem report in macports. Shall we include /bin/ps visible in cmake environment in darwin systems?
Is there no way to hard-code the path of into CMake?
isn't actually in .
The relevant code in cmake is I believe. The package on contains the Apple ps. I'll likely get it building as part of my revamp of the darwin stdenv, and if I'm feeling particularly charitable I might even hook it into cmake. In the mean time, I'd probably just leave this alone, since I don't think we're far off from having a sensible darwin stdenv.
We definitely can't use procps on Darwin since it doesn't have /proc. Also, these warnings are not always harmless: MySQL's startup scripts won't work unless it has ps in scope during the build process. Right now the workaround is this
This was fixed as part of the new darwin stdenv.


, CVSSv3=9.8 (nixos-20.09) Scanned versions: nixos-20.09: . Cc


We currently use version and export it to The help page suggests there is version 201 and the file name should be : () The change will also likely need a hwdb file according to: This is apparently required to support cameras that use SCSI tunneling support: cc (maintainer) ( the udev file)
For reference Fedora


Describe the bug , which is depended on by , has been failing to build on both Linux and macOS since / , perhaps since was updated in . of a contemporary build attempt indicate that the immediate problem is that the current version of tokenizers depends on a vendored copy of v0.10.0 of the parkinglot crate, via its cargoDeps dependency. Further research suggests that the -issue reported in the logs was fixed in Amanieu/parkinglot which it looks like is included in v0.10.1 and successors. As a result, I think that someone just needs to refresh tokenizers' (possibly by way of simply updating the package) or, failing that, to try to get it to build with an older version of . (That said, I have yet to test these changes myself, so I don't know if they are truly enough or if additional modifications are required.) To Reproduce Expected behavior The build should succeed. Notify maintainers (also /cc (since this looks like an interaction with and since there is a commit linked to above updating in the scmdiff from the last successful build to the first failing build, per hydra.) Metadata $ nix-shell -p nix-info --run "nix-info -m" system: host os: multi-user?: sandbox: version: channels(...): nixpkgs: Maintainer information:
Thanks for the bug report (still hoping for Hydra notifications some day)! The linked PR should fix this issue. I am also working on some other PRs to make transformers work on Linux/AArch64 and Darwin/x86_64.


I'm told a lot of people favor Paul Phillips' SBT wrapper over vanilla SBT. We probably ought to have a package for it.
Minus the parts where it auto-downloads sbt for you, I expect
Mmm, I don't know. Isn't it kind of important to be able to auto-download the appropriate version of sbt for each project?
Maybe? Seems hard to keep it Nix-flavored though, given that it wants to retrieve unhashed versions from the outside. I guess we could either patch it to call out to nix to download scala and sbt, or we could leave it alone and users can decide whether they care about Nix-like behavior here.


Steps to reproduce the behavior: udocker against the master branch of Nixpkgs () 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.


Steps to reproduce the behavior: from I guess is too new? :) <!-- 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.


This patch is needed to build texlive but the patch can't be downloaded. It doesn't seem to be there in the Arch Linux repo anymore. I found the desired file at a different URL here: We probably need to find/create a reliable place to download this patch?
Probably should just add into nixpkgs instead of fetching it.
another alternative is add the commit rev which seems to have the same hash


Describe the bug on macos fails because it can't find . To Reproduce Steps to reproduce the behavior: lean: leanprover. It bails out with OSX 'readlink' command does not support option '-f', please install 'greadlink'. If you use 'brew', you can install 'greadlink' using 'brew install coreutils' Expected behavior No errors. Additional context This is because leanpkg has an : It can be worked around presently by installing . Options I see for fixing the package: depend on on darwin patch out this check, since (presumably) nix provides the GNU anyway fix this upstream by changing the check to not fail under nix (e.g. by having an explicit check for the argument instead of relying on command name), and pull in the fixed version Metadata system: host os: multi-user?: sandbox: version: channels(rob): nixpkgs:
Sounds most easiest to implement and maintain.


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


Package name: proton-pass Latest released version: 1.22.0 <!-- Search your package here: --- Current version on the unstable channel: 1.20.2 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]:


Package name: adbfs-rootless Latest released version: 2023-03-21 <!-- Search your package here: --- Current version on the unstable channel: 2016-10-02 Current version on the stable/release channel: 2016-10-02 <!-- 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.


Steps to reproduce the behavior: bsddb3 Python312packages Python 3.12 seems to have removed distutils package but it should be inside setuptools module according Sadly this package is a dependency of several Python packages. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- PS: the package has not maintainers. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
If bsddb imports distutils, then it is not compatible with Python 3.12. This is something for upstream to solve, but is unlikely to happen:
So all those packages that depend on this package, like must be labeled as broken?
Scrapy claims to support Python 3.12. Are you sure bsddb3 is still in their dependency chain?
Im not sure about that.
I see this merged PR that probably should solve the issue on scrapy... but about bsddb3, it must be removed from python 3.12 package group...
distutils is used in the test of bsddb3 to get the platform data, we patched this behavior in the following PR
Isn't It better to patch the test to avoid using distutils but still having it run ?


Project description Metadata homepage URL: source URL: license: bsd3 platforms: unix, linux, darwin


Failed to cross compile batctl package for riscv64 using nixpkgs on Ubuntu. Nix is not able to meat the dependency for the package: While the package successfully cross compiles on a NixOS* machine. Steps to reproduce the behavior: nix environment on a Ubuntu machine. and cross compile batctl package for riscv64. Below is the command I am using: attached nix-info not availble on Ubuntu
can you give the version of nix and the revision of nixpkgs (it might be in a file called .git-revision).
is the sandbox enabled, if they're at the same rev
Turns out I couldn't reproduce it because my machine has riscv emulation enabled, the makefile is calling a riscv version of pkg-config. I'm testing a fix to the problem at the moment


I note that the package sets in .[(1)] says [(2)] that the reason to disable "JBIG" is patent concerns, that disabling it removes support for many printers, and that "The patent will expire on April 4, 2012". Given the last, need we still disable this feature? [(1)]: [(2)]:
I don't think so. openSUSE enabled it, too. Other distributions might have done the same, not sure.
A PR that implements this change request would be very welcome. I'd rather not have this issue lying around, though, without someone having committed to actually work on it.


Steps to reproduce the behavior: pkgs.transmission to your environment.systemPackages (or use = true;) build will fail when trying to download a file that does not exist That does not seem to exist (I think, sorry for the @ otherwise) <!-- 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]:


Steps to reproduce the behavior: nix on x86_64-darwin experimental features nix-command and flakes to install nushell v0.75.0 via . Please run and paste the result.
I can confirm the bug, the following PR could resolve it.
that is great news! I am hopeful that can resolve it. I see that you marked this as resolved by . However, this does not seem to have resolved the issue for me. I am still receiving the same error when trying to build :
The ofborg test did pass, see Maybe you have to build it on master? Also, I don't think will help, as the author of that PR.
Hmm, after upgrading nix and updating my nixpkgs-unstable channel, I'm still receiving the same error.
You have to wait for the commit to arrive on nixpkgs-unstable.
Thank you your PR resolved it. the fix is in the nixpkgs-unstable channel. Much appreciated!


, CVSSv3=9.8 (nixos-20.03) Scanned versions: nixos-20.03: . May contain false positives. Cc Cc
See also: , ,


, CVSSv3=9.8 (nixos-20.03, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-unstable: . May contain false positives. Cc Cc
See also:


, CVSSv3=7.5 (nixos-20.03, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-unstable: . May contain false positives. Cc Cc


, CVSSv3=9.8 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.0 (nixos-20.03) CVSSv3=5.5 (nixos-20.03) CVSSv3=5.5 (nixos-20.03) CVSSv3=5.5 (nixos-20.03) CVSSv3=5.5 (nixos-20.03) Scanned versions: nixos-20.03: . May contain false positives. Cc Cc
See also: ,


, CVSSv3=9.8 (nixos-19.09, nixos-unstable) CVSSv3=7.5 (nixos-19.09, nixos-unstable) CVSSv3=7.5 (nixos-19.09, nixos-unstable) Scanned versions: nixos-19.09: ; nixos-unstable: . May contain false positives.
See also:


, CVSSv3=9.8 (nixos-19.09, nixos-unstable) CVSSv3=7.5 (nixos-19.09, nixos-unstable) CVSSv3=7.5 (nixos-19.09, nixos-unstable) Scanned versions: nixos-19.09: ; nixos-unstable: . May contain false positives.


, CVSSv3=9.8 (nixos-20.03) CVSSv3=9.8 (nixos-20.03) CVSSv3=9.8 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=5.9 (nixos-20.03) CVSSv3=5.5 (nixos-20.03) CVSSv3=5.3 (nixos-20.03) Scanned versions: nixos-20.03: . May contain false positives.
See also:


, CVSSv3=9.8 (nixos-19.09) CVSSv3=9.8 (nixos-19.09) CVSSv3=9.8 (nixos-19.09) CVSSv3=7.5 (nixos-19.09) CVSSv3=7.5 (nixos-19.09) CVSSv3=7.5 (nixos-19.09) CVSSv3=7.5 (nixos-19.09) CVSSv3=7.5 (nixos-19.09, nixos-unstable) CVSSv3=7.5 (nixos-19.09, nixos-unstable) CVSSv3=7.5 (nixos-19.09) CVSSv3=5.9 (nixos-19.09) CVSSv3=5.5 (nixos-19.09) CVSSv3=5.3 (nixos-19.09, nixos-unstable) Scanned versions: nixos-19.09: ; nixos-unstable: . May contain false positives.
See also:
30.1 is also the default version in 20.03 ATM.


I can't figure out which are the problematic lines! 5 and 9 do not seem to be any valid lines considering the error descriptions, or they're the lines in the expanded output(??) - I don't get it. I hope it wasn't something I did here: this /etc/nixos/nixpkgs/ git pull (this was last: ) sudo -i nixos-rebuild switch --fallback System: (Flounder) Nix version: nix-env (Nix) 1.11.2 Nixpkgs version: ""


Describe the bug Slicing fails on latest Cura (4.3). When trying to slice any model the slicing progress bar will get stuck at about ~20%. I tried various printer presets and the problem persists. From looking at the logs it seems like that CuraEngine is unable to get a value for 'machineheatedbuildvolume', which was To Reproduce Steps to reproduce the behavior: any printer preset any model Slice Cura log relevant parts to the problem seem to be aditional information it seems like , from the nix package, indeed is missing the new setting. For comparison the upstream definition. Metadata Maintainer information:


name: flutter current version: 2.5.1 desired version: 2.8.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.
done on


Project description PreviewQt is a simple application for previewing all kinds of files, based on Qt/QML, published as open-source and completely free. Metadata homepage URL: source URL: license: gpl2+ platforms: linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Input methods based on do not work as of , at least on my machine as it is now. Upstream, I think the change comes from , which made start using . Other IBus input methods still work (mozc, hangul, Anthy). It feels as if this should have an easy solution amounting to “do what worked for other packages using ”, but I can't work out what it is that they do that makes them work. It's also believable that from is not being run. 1) 2) Switch to an -base input method (example: from ). Then, the input method is not changed, and the rest of the output is: Alternatively: 1) 2) Try to open the preferences for an -based input method. No preferences are shown. The following error message is printed. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
So, adding to stops the error message, but preference dialogs still do not show and all of the problems with actually using remain.
How did you install and activate the input method? i18n.inputMethod.enabled = "ibus"; = with ; [ table ]; does not seem to be enough.
Change to (ibus-table acts like a framework within a framework, and provides some actual input methods using it). Then, use -Input Method -Add -More... -Others -IPA-X-SAMPA (and maybe another to see the switching behaviour). Then, switch using the key combination from the preferences (I forget what the default is; maybe Ctrl-space). Expected behaviour from IPA-X-SAMPA includes ↦ and ↦ .
Have you managed to reproduce this problem?
I can confirm your observations in Maybe this could be the culprit:
I've found what appears to be a solution, but it's in some sense weird. Looking at other input methods, they seem to use rather than . Replacing the latter with the former on seems to fix the issue. I have no idea, though, why isn't broken on other platforms. is the new package description.


Describe the bug pciutils is using a really old file which doesn't include any definitions for AMD Radeon 6800 XT cards. When running you get the following output If you get a newer version of the file from https://pci- which update-pciids script in package normally updates (but is disabled in nix package). You get the following: Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(wil): nixpkgs: Maintainer information:
Should also mention when running strace on lspci it reads the file from /nix/store/464020m9r6mhsivgp9v1bhkyzz5pa0gq-pciutils- and not from hwdata like I originally thought.
Would it make sense to make lspci depend on hwdata and then use from hwdata? cc'ing (who is listed as shadow maintainer of pciutils)
Hmm, makes sense. Except that seems to be in significantly more closures than , so depending on the extra 6+ MB of other data seems significant. Perhaps make put it into a separate output? Or could just copy it as a quick work-around (that's free for people with )
Oh, we can't "just" make multi-output, as it's a fixed-output derivation, but we could fake it through multiple derivations. Maybe just the work-around for simplicity then?
I think the work-around is actually pretty sensible. I'll prepare a pull request :-) Update: Did so, . Once both and are merged, our issue should be resolved.
Thanks for fixing that :). I tried your two updates on my machine and it appears to be resolved. Closing the issue out. Now we just wait for this to get into unstable :).


See We should probably remove some of the Eclipse versions we have as we seem to be carrying lots of them. If there are objections to removing, we should at the very least clean up this area.
you can probably close this one now?


In is installed if it exists, and the install siliently continues if it doesn't exist. In the service the script is executed unconditionally, even if the script doesn't exist. That breaks suspend with the 465 beta driver, because there the script does not exist. I think we should [ ] fail loudly if it doesn't exist (so that if you close the laptop and put it in a bag, it doesn't catch fire) [ ] figure out where the script went / what the replacement is. CC
I will look into this in an hour or two, have a thing to do soon.


Steps to reproduce the behavior: -rebuild of NixOS with GNOME Known workaround: reverting ( ) Please run and paste the result.
Opened an issue but unsure about what is going on / how to fix other than reverting that commit. I don't know that much nix :C
does fix the issue for you?
It does, thanks for the fix. :3


<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on github to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: texlive- current version: 2.9.1 desired version: 2.10.1 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
Can you tell a bit about your use case?
I knew I forgot something! :smile: I'm using emacs + org-mode, and am using the =unicode-math= package with =stix2-otf= along with lualatex. In order to preview equations, the pipeline goes /However/, =dvisvgm= 2.9.1 doesn't understand the extended font data that lualatex emits (see the comments in ), and so produces corrupt output images. This was fixed in 2.10.1, which was recently released and pushed to CTAN.


Describe the bug It is not possible to delete files in atom. To Reproduce Steps to reproduce the behavior: to delete a file Expected behavior This action should not result in an error. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
gvfs-trash has been removed for a few years () after several years of deprecation period. For the atom issue, this is likely a duplicate of
Ah thank you for this, I will update the title and description accordingly
You can try installing globally. That contains command, which is ’s successor and most programs support it. Not sure about Atom though.


Project description HTTP, HTTP2, HTTPS, Websocket debugging proxy Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin


The application is crashing when trying to open a file Steps to reproduce the behavior: to open a repository application crashes Supposed to open a file exploer Using KDE Plasma 5 under wayland <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.
I’m running Gnome 45 under Wayland and the « Open a Repository » feature is working fine. I’ll give a look with KDE Plasma 5 when I have some time.
same here
As in it it works or it does not?
not work kde + wayland


Describe the bug The file has this function: Since this is called for every dependency, we get quadratic complexity. This may cause a non-trivial slowdown - building digikam I noticed it takes a few seconds just to get to , but there might be other causes. It also causes huge amounts of debug output when you add a to (about 600 MB for digikam). We should use an associative array for this like stdenv does (see ). Notify maintainers
We also need to do this in the setup hook for paths seen by .
I marked this as stale due to inactivity. →
Not stale.
Fixed in .


<!-- 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: materia-kde-theme <!-- 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: desired version: <!-- 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.


Package name: snipaste Latest released version: 2.9.2-Beta <!-- Search your package here: --- Current version on the unstable channel: 2.9-Beta2 Current version on the stable/release channel: n/a <!-- 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]:


tests pass, while tests fail with: Official Hydra sees the same thing: with their Travis setup. (That is a build of a recent commit, but I still see the same failures after pointing at a checkout of ) Does anyone have any ideas? With nixpkgs master,
See scrapinghub/dateparser, scrapinghub/dateparser and scrapinghub/dateparser.
As long as this problem remains, the best thing to do is using for affected application. Switching to should be done in commits that don't change anything else and that reference this issue in their commit message so that they can easily be reverted. Simply skipping the tests does not make much sense since these are real incompatibilities.


Project description is an audio processing program with an interactive mode. Also has a LADSPA frontend. Metadata homepage URL: source URL: license: isc platforms: linux


Describe the bug fails on Darwin. To Reproduce Steps to reproduce the behavior: Expected behavior Package builds Additional context Error log: <details<summaryError log</summary</detailsMetadata Please run and paste the result. host os: multi-user?: sandbox: version: channels(yl): nixpkgs: Maintainer information: Possibly related to
On the master branch, I removed the derivation from the nix store with and I built it without substitutes; failed with the same message. This is not caused by , but help me discover it due to the update of the requests python package.
maintainer:
I don't have a way to test on joblib for darwin so this is why I didn't have input on this PR. Is there an easy way to test nixpkgs on darwin? Hackintosh via kvm?
There is that works with some tweaking but I wouldn't describe it as easy. Another option is to ask @ GrahamcOfBorg to do the builds on the PR if there are not too many iterations to do.


The nixopsUnstable version is not set correctly. It should show the version. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --


The symlinking between the multiple outputs of seems to prevent it from installing. I was looking to install it to have the dig command available. - System: 17.03pre94050. (Gorilla) Nix version: nix-env (Nix) 1.11.4 Nixpkgs version: "17.03pre94050."
11.4 still doesn't contain :-( How could we have that as default in 16.09? I consider it quite an important feature for + multiple outputs. would you be against porting that PR to 1.11.5 and making that default in 16.09 and master?
+1 for a 1.11.5 Nix release in general :)
Since this seems to be an issue for multiple packages, I am raising the severity on here.
Looks like the same kind of issue as So +1 for Nix 1.11.5 on NixOS 16.09, if that's what it takes to fix this.
ping again about nix-1.11.5 (my comment above).


Describe the bug When I try to preview videos like .mp4 or webm in Nautilus using Sushi, it says "Your GStreamer installation is missing a plug-in". To Reproduce Steps to reproduce the behavior: NixOS with Gnome3 desktop space on a video file in Nautilus Additional context It's possible that there's some configuration in my homedir that makes it break, since I have the same homedir that I had under other Linux installs, not sure how to find it however. outputs Notify maintainers maybe? Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(wmertens): channels(root): nixpkgs: Maintainer information:
Would need to add here, I think.
that makes sense - it seems like I would like the bad and the ugly too. How about a nixpkgs configuration setting that decides which plugin sets to load, and having plugins-base include them? That should make it backwards-compatible.
Most of them depend on base so that would be a dependency cycle. Also we would need to move the wrappers into a separate derivation or we would have to rebuild everything. Alternately, you can set environment variable (I believe some NixOS module does that). Not a fan but it should work provided some ABI break does not sneak in.
I marked this as stale due to inactivity. →
Still a problem
I marked this as stale due to inactivity. →
if sushi is not a dependent of any package then why would we have to rebuild everything? What do you mean by everything? Perhaps until a separate wrapper derivation is composed we can add a configuration option to the nixos module that would add these gstreamer to it if needed. Also, doesn't work at all for me nowadays, I think since Gnome 41.
I was replying to Wout’s question above regarding a general solution pulling extra plug-ins into gst-plugins-base. For now, I would be fine with adding everything unconditionally to sushi as mentioned in I must have forgotten to test it during the update when I removed libmusicbrainz but forgot to add libsoup: Could you try


When using filters, look for them in and co. Instead it should look for it in for example. Setting the environment variable can work around that issue: . But it would be nice to have it work out of the box. Result: System: 17.03.1556. (Gorilla)


Xpra supports forwarding invocations from the server to the client. The Xpra client defaults to hardcoding as the command to invoke on the client, which does not exist in NixOS. This bug does not impact hosts other than NixOS. Steps to reproduce the behavior: somehow. The Xpra client should invoke the local . N/A. This could be fixed by setting the open command to just , but it might match the intent better to change it to something like perhaps. Presumably, the point of doing it this way is to avoid any other copies of that might appear on the , e.g. Xpra's own. I suppose we can't really rely on to exist: even if we could on NixOS, we can't on other Linux distributions running Nix, where might make more sense. It seems to me that the best compromise, then, is to hardcode a path to copy of and users can override this using the option if needed. The open command that Xpra uses is configurable on the client-side, but the default is set as a platform-specific variable. On Linux, it is set in . Because there are separate values for both Windows and Darwin hosts, patching the value to shouldn't ever break them (but of course it should still be a Linux-specific patch, otherwise it unnecessarily brings into the closure.) Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Julia 1.5 is out, see: and we don't have it packaged. More over, see how defines our other Julias: Several issues: is pointing to a TLS version which is old IMO. Certainly there are breaking changes seen in , but since Nixpkgs is a somewhat rolling release distro, are we going to keep these older versions and default to them for ever? I've once tried to reach for the community to hear if there's a strict policy regarding such scenarios, but Anyway, I'd like to propose a change that will keep only the LTS version and the latest - currently 1.4, and perhaps make the attribute , point to the latest. Any thoughts from maintainers or users? cc
Also, now I noticed all of our Julias fail to build, e.g:
I agree. And the 1.5 release candidates are out, so this will become the latest version in the near future. Last time I looked, the package built the same deps for all versions, including 0.7. In versions 1.0 and later, there are actually fewer dependencies (e.g. arpack and fftw have been dropped), so the package should be cleaned up to not include these unnecessary libraries in the build. I also think the default version should be the latest version (i.e., unless somebody explicitly installs julia-1-lts, they should get the latest).
OK I'm glad I have your support. I'll let this issue stay open for a while and hopefully I'll be able to take care of this a month or so from now.
cc
Back when Julia tests were not so messed up, I think there was often 1 previous version. I guess with 1.3 needing overriding to no tests, it is fine to just have julia-1-lts and Julia 1.4 as julia once Julia 1.4 gets built fine with some tests.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Haven't had a lot of time to work on julia in nixpkgs, so just posting this as a FYI.


We used multiple versions of julia at work, but we use a custom derivation, similar to this: We also do not run the tests, but in general it has been working great. Previously we also used the binary builds patched with patchelf, as there were some differences in the structure of the results of the vanilla binary build provided by julia and what we got when building from source. We gave up on using 'system' libraries, and build the releases that julia provides, as julia is very specific in the versions for its dependencies (LLVM patches mostly).
I tried to use that tarball in order to write a derivation from scratch. Here's my attempt: It fails with: Naturally I didn't further attempt to add curl or wget to the inputs, as that would fail in a sandbox as well. I've opened an issue upstream: complaining that that tarball doesn't really contain all dependencies.
I ran with sandbox enabled, and the expression I linked with works for me. So I think it is fine to just add curl to the deps, as with the full tarball, it isn't actually used.
There is another approach to avoid running tests: using precompiled binary. I tried downloading the 1.4.2 binary from and then afterward ran on the binary, then I got a running Julia interpreter just like that.
We did the same for a while using code similar to this: Unfortunately, we actually sometimes need to patch Julia, so we switched to the julia expressions from source, that I posted earlier.
Thanks that expression works well thanks to . I'm testing it now.
OK so after a long build, I got a working Julia derivation with these references: And this closure size: Which I must say it is satisfying. The question is, is this how we'd want it to be built? Using all of their dependencies and practically non of ours? Some of their dependencies are required to be patched, according to and they also specify that using the OS' libraries is not officially supported? Anyway I'd happy to get help on deciding this.
does this lead to Julia tests passing? I think for every dependency they patch, it is OK to just use their patched version. I guess it could be nice to use a separate build unpatched (but using the exact same version sounds like a likely restriction), but whatever dependency does not work right away can be switched to bundled.


I think it did, I've set and the build passed but I haven't inspected the log much, but here it is: Currently produces this log but there's no PR yet as I think there are many makeFlags that should probably be set as well. If anyone feels confident to open a PR with this feel free to ping me for a review. I agree with the idea, but what's bothering me is that it's not absolutely clear what versions are patched and which are not - the docs vs what's actually found in is not totally inline. Also, it seems that some of the patches are old, and were suggested upstream (to the libraries) but they weren't merged there for some reason. I'm still investigating, See My current target is to decide what libraries to use our version vs their version, with the preference to use our version, in order to hopefully reduce closure size due to sharing shared libraries. The idea is to decide this by checking whether the libraries have included the patch Julia suggests, and then whether the library's maintainer has released a new version that includes Julia's maintainers' patch, and whether we ship that new version.
does this lead to Julia tests passing? I think this log is cut short before the interesting part…
I've uploaded it here:
Hmmm. Reading the log does not convince me the tests were run… Pity.
Since 1.5 was just released, the title should probably be updated to be 1.5.
Downside with the patching approach, is users lose the ability to compile against MKL, which has HUGE performance increase (last I saw showed that MKL was ~4x faster at matrix multiplication!!). Would need to also package JuliaPro to get MKL. Of course, anything working nothing working, although would be a shame to lose compilation options.
Says
Thanks garrison, I saw that, but I have a feeling it won't play nicely with Nix...although if we go patching route, perhaps could do that during buildPhase
Are you concerned about specifically or all packages that use BinaryBuilder? There are a lot of them. More on this at
As I understand binary builder, that all happens in userspace, but modifies , which is in /nix/store
The installation instructions for do not seem to require root. My guess is that it stores the modified sysimage somewhere in .


Am I wrong?
I just tried it with Julia 1.4 installed with Nix, and as I suspected fails to build due to
We need to have a interface - that would support building binary packages, and make the interpreter aware of them. I wish I was a bit more motivated to do this, but upstream disappoints me regarding the humble task of compiling Julia as is, with the right selection of a few system dependencies - no response at all at & . I'm also dis-motivated to explore this aspect, since their build system is of plain makefiles, and they keep patches of dependencies from so long ago, without documenting whether they are needed / used or not...
Nix behind It is a shame to see julia's support in NixOS languish. It seems pretty clear to me that upstream is only interested in supporting the configuration obtained by cloning their repository and typing on a stock Linux distribution. I understand their perspective in many ways, as having julia and all of its packages "just work" requires a lot of care, and building with unsupported configurations is very likely to result in brokenness somewhere in the package ecosystem if not in julia itself. Julia is a bit special in this regard because of its emphasis on performance and also its need to support interfaces to other languages/frameworks that often have weird requirements. I have found that typically, there is very good reason for these patches, even though at times they may not be documented except in git and github history. (Admittedly, I am less involved in upstream than I used to be.)
I think Julia team initially evaluated Nix as their binary distributor () but decided against it—there was a discussion somewhere but can’t find it. IIRC lack of Windows / desire to tie into native pkg management systems were factors. Julia’s does a pretty great job, and uses a solver to properly resolve dependency versions based on constraints. I’ve been incredibly frustrated by the withPackages pattern, at least in python. I constantly run into problems due to nixpkgs ignoring version constraints. There are some other nice advantages to nix of course: binary dependencies are shared across language ecosystems for example, and there are lots of supremely annoying packages (I’m looking at you CUDA...) that Nix makes delightfully easy to install, use, and maintain parallel versions.


But until Nixpkgs supports multiple versions across the board, and has a solver baked in, I’m honestly not sure Nix brings enough advantages to bail on Edit: I think the approach done by poetry2nix and Mach-nix are the way to go for Julia packages + nix. yarn2nix is another shining example. I would love to see a solution in this vein—didn’t mean to douse any enthusiasm for people interested in helping improve the Julia situation on NixOS :)
Maybe it is worth to reaching out to Julia Computing folks at to get their attention on ?
We'd probably need to put this information in our attribute sets, just like our Python packages know what deps they need. Hmm that's a bit surprising to hear as the Python ecosystem seems most well organized. Have you ever encountered a real bug with a mismatched version of a dependency with a specific version specified in a package's ? IIRC fails if a version is used and it's not exactly what's available. If you've ever felt there's a certain python package of a certain version missing, have you considered contributing it? Even if not, was it too hard to override it? What do you mean "across the board"? That might be much more harder then it sounds, due to the constraints of Nix it self when being evaluated everytime you run and friends, see It's not a question of whether Nix brings an advantage or not, it's a question of whether there are any Julia packages that are built at other distros imperatively with a , and this produces (or even worse, downloads) shared objects or executables into (not in ), linked to Julia or other Nix deps that do reside in . If the answer is yes, than every Nix user will experience breakage after Julia is updated in his - not necessarily if it's a version bump of Julia, it could be a mere rebuild of Julia by hydra. Yea Mach-nix is an awesome idea well implemented ( thanks for the inspiration :heart:). I've also reached a similar conclusion at . However, this is my opinion for Rust and Go, and I tend to think that for a small ecosystem like Julia, perhaps it'll be too much - it shouldn't be that hard to manage all of these pacakges like Python is managed in Nixpkgs.
I opened
Frequently.


Especially with Scipy, matplotlib, bokeh, sklearn, tensorflow, pytorch, etc... Often, nixpkgs used to have it until it was updated. Except in very rare circumstances, we do not keep more than one version of a python package around. I have no interest wasting time working around bugs that authors tried to spare me by specifying precise versions. It seems a sort of cognitive dissonance in our next community that we all care so deeply about reproducible builds, but for convenience often disregard the officially supported dependencies. As a result, there are often subtle bugs in software on NixOS that do not appear on other platforms. (Eg x11vnc crashes, shared memory problems, etc). Nix supports crazy high specificity in versioning, well we past semantic versioning down the the bit in many cases. And yet in nixpkgs, by convention, we remove the old version anytime we update. It’s understandable that Hydra cannot build everything, but it’s always bothered me that I have to pin nixpkgs if I want a build to stay functional over 1+ years. is mostly declarative. Of course, Julia is constantly re-compiling code, and until there is true support for precompilation, I don’t see how it’s possible to use nix store. This is due to multiple dispatch. Suppose I wrote a library to do an efficient k-nearest-neighbor query using some fancy free structure. Perhaps the core algorithms simply require a function for your types. When you write this new function, Julia has to compile all the code in the k-nearest neighbor library for this new type. Thus, it is not possible right now to compile a package on its own as the core pattern in Julia involves extending the function of other packages via multiple dispatch. You can only compile a package in context of the code that is running. Therefore, the Nix store approach is not appropriate. See
I see. You are talking about "authors" of Nixpkgs' expressions? I'm still a bit perplexed, as I earlier said, and correct me if I'm wrong: should fail if is used in , and the exact version is not available. Sometimes (), we do hardcode such version requirement changes in our expressions, but hopefully that's done only when it's justified.


I agree (maybe a bit ). Generally I think, every dep's version related issue should be handled by someone like you, who's familiar with python packages you use. I'd at least (open PRs) to fix the issues I encounter :). I see. I guess the situation is more complex than I thought, but I don't think I'd be able to form a strong opinion until I'll get a Julia interpreter from an expression I'm satisfied with. Thanks for the link :).
Unfortunately, this pattern is done constantly (including in my own contributions!). The problem is that, except an extremely rare cases like tensorflow, nixpkgs does not allow multiple versions of same python package to co-exist. Every time we update a package, we remove the previous version from nixpkgs. Confounding this issue, we often disable tests because sometimes the effort is just too high when developers bake in assumptions that aren’t compatible with the Nix ethos (for some reason this seems to happen more with tests then source code...). The most frequent cause of failure is the code needs to download something to run the test. (I’ve tried to lobby in the past that the test phase should be permitted to have Internet access as long as it doesn’t modify /nix/store, but I digress). In any case, the end result is that using a python package on Nix typically means you aren’t using the exact dependencies that upstream declared, and you’re more likely to have a package that despite having changes in dependencies has never had the test run. Thus, amazingly, I’ve had more luck with Julia packages working on NixOS than Python when all other binaries are present in environment.
I don't think there's a strong policy in our Python ecosystem against multiple versions of packages - if this is what upstream recommends. Anyway, the whole topic is out of scope for this issue. Feel free to open a new issue and cc me and who's working hard to ship a 20.09 release.
Yes, sorry getting a little off topic here. I mainly mention it to suggest that our efforts in Julia that start from scratch Can learn from these issues. I’m not too familiar with the new binary builder, but was quite nice in that it would first search for libraries before attempting to install.


See this issue for some context: Note that a core Julia dev gave a pretty great endorsement on Nix (albeit back in 2014): I think it might be most productive to do this development outside of nixpkgs, and do it in Julia to hook in with nixpkgs as needed. That way users could seamlessly use Pkg in Julia. I’d love to and have it just work instead of the current hack that I wrote that a lot of people seem to be using ()
Short summary of the Discourse thread: for LLVM and libuv it is essential to use the patches/forks. For other packages it is probably unnecessary to use the exact version specified by upstream.
Thanks for being there with me :). I think I'm gonna work on this once we are through with , to avoid merge conflicts.
TIL Guix manages to package Julia 1.4.1: What's interesting, is that they but they build it with Julia's LLVM patches fetched from the internet - they don't rely on Julia's build system to build it's own LLVM. For similar dependencies which the real system's version can't be used, they do the same. I think we should try to copy this approach.
FWIW I did that in Fedora originally, but I stopped. Since LLVM makes breaking releases very quickly, you'll probably want to move to a new version that Julia doesn't support quite soon.
Maybe I don't understand, but why should I move to an LLVM version that julia doesn't support? Also, aren't the and versions don't introduce breaking changes between minor releases? We could stick to since that's what Guix does and I think Julia uses this version as a base too.
I don't really know how NixOS works, hence the "FWIW". If you used versioned LLVM packages and keep older major versions then it's probably OK.
Just offering a user perspective: Julia provides a package manager that provides mostly reproducible (in a practical/scientific reproducibility sense rather than a bit-identical sense) environments easily from manifests. Increasingly, these environments are isolated from the host OS by binary packages for dependencies being served by Julia. I don't want Nix to manage dependencies that can handle for me: Julia already handles those excellently and conveniently. I just want Nix to handle the (usually few) system dependencies.


What I would like as a NixOS user is for Nix to provide me with a working Julia 1.5 derivation that provides: julia, a FHS wrapper or something providing compatible versions of the few things that Julia's binary packages need (just libc, libstdc++, libgfortran; I think. ). When I say "compatible", I mean that these libraries should work with the binaries and with the julia binary provided by Nix. Not all Julia packages are BinaryBuilder-ised yet, so I'd also want an easy way to specify that I want compatible versions of other packages installed (e.g. Qt, cairo, etc). For packages that need python, I don't know if I'd like Julia or Nix to handle installing and managing that. The simplest approach would be to tell Julia to do it (there is pretty good support in Julia for distributing isolated environments of python + packages + dependencies; better than in , imo). I don't know how doable any of that is in Nix, just describing what a good outcome would look like to me.
I think this is quite doable. I would propose that we add a new package, , that is a "batteries included" build that contains system libraries for all common Julia packages. Would this approach work for BinaryBuilder? I haven't used this yet. If not, we could fall back to a FHSuserenv, but I'm reluctant to do so if at all avoidable as there are outstanding nix bugs () that create seg faults in some heavy data processing workflows.
I think that is a good proposal and I think it will work with BinaryBuilder packages (e.g. SDL2_jll). In any case, some approach that works with BinaryBuilder packages should be found because those are a critical part of the Julia environment now :) Some important packages (e.g. GR) still want to build and install their own software dynamically, and that doesn't work well in Nix, but most of those can plausibly move to the BinaryBuilder system (PR for GR ), so I think letting those be broken would be tolerable (and a big improvement over the status quo of Julia on nix). Perhaps we can get something working quickly by just patchelf'ing the official Julia builds for now? (I don't understand how all of this stuff works!)


Is there anything presently blocking just getting julia 1.5 into nixpkgs? I don't care about ecosystem working with nixpkgs, just a good ol' fashioned julia install.
yes, see
If you just want Julia and don't mind about binary packages breaking you can just download Julia from the official site and patchelf it. On Sun, 4 Oct 2020, 09:32 Tyler Benster, <:
On the there was also the idea floated to patch to patchelf dynamically loaded binary dependencies.
Guix has a Julia package and it works quite well. Perhaps some ideas can be borrowed from there: It'd be really useful to get Julia working on Nix. It's the only big outstanding thing that doesn't work and prevents me from migrating some servers in my organization.
I tried to copy their expressions in and it doesn't work yet, but there's also another seemingly working attempt by at .
So, do we want anything else now that 1.5.3 is packaged (:greenheart: ? I think we: 't need clean up the expressions a bit - not use the file if it's not shared. I did (2) along with the julia_10 fix in As for (1) I will need a bit of feedback.
I guess some people like me still use julia_13 via test-disabling overrides, so a bit of time after 1.5 reaches channels for smooth transition could make sense?
Maybe backport 1.5 to 20.09?
OK so I disabled the tests for julia13 in and made the default there as well. All merged pull requests referenced here should be backported.


Project description Client for authenticating to services using a German ID Metadata homepage URL: source URL: license: EUPL platforms: unix, linux, darwin, win32


Synergy crashes without an X Display available, but the autostart option attempts to start synergy regardless of whether login is graphical or TTY. It would probably make more sense to spawn this after
(triage) status?
In case this is still relevant - would it make sense for those to run as user services instead to take advantage of recent changes merged in
I think this is probably still relevant, and I think your suggestion is probably a good one, . With this config: out of the box, I get the following: But if I kill the service and start the synergyc command manually as my unprivileged desktop user, it works just fine:


was looking to resume my work on espanso's (which has been somewhat impeded by ), and now I find that espanso no longer builds at all. As those issues haven't gotten much attention thought I'd reach out to to see if anyone can at least confirm (as my understanding is that the reproducibility on darwin can't be quite as good as NixOS -- especially when one ). Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thank you so much for the quick fix! I keep running into these issues on darwin, I really want / need to learn more so I can contribute back! Unfortunately I'm still getting a build error, which looks to be a sandbox issue: This seems to fix the issue: Could you take a look and if appropriate merge? Many thanks!


Rendering a project in Kdenlive with default rendering settings leads to the following error: Steps to reproduce the behavior: ( is the latest revision of at the moment of writing this) any clip to the timeline (for example, drag in an image) "Render..." "Render to File" You might need to use as your desktop manager to reproduce this issue. There is claiming that this crash doesn't happen on Plasma 6. I am using Plasma 5, but I am currently unable to verify if Plasma 6 would fix this issue (Plasma 6 is broken for me for unrelated reasons). Render should succeed. See issue for the previous instance of this problem. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Are you using the kdenlive matching to your desktop? Edit: nope, you are using the plasma 6 package. You want to use plasma5Packages.kdenlive.
is plasma6? Wow, that's quite a foot gun. Shouldn't it be called ? Also, fails with the same error.
It really should not matter, and will (once is entirely gone) be whatever versions upstream ships.
it seems that the problem either wasn't fixed or has resurfaced again? I was able to reproduce the exact same error with and (where is the latest revision of at the moment of writing this)
Please try again after the staging-next merge (which should make its way to unstable in a few hours).
I will. Could you explain why staging-next is relevant in this case, though? I am just curious. I checked using and in the github UI directly, and it seems that the changes from should be already present in revision .
staging-next reshuffles protobuf versions again.
I wasn't sure which staging-next merge you were originally talking about, so I tried the same thing with commits (current nixos-unstable), (current staging-next) and (current master) and I am still getting the same error. Can you reopen this issue, or should I open a new one?
Hm. Actually, I think that I figured out, what the problem is. It seems that actually saves some paths in .


For example, my had the following lines: Deleting the line fixes the issue, but then adds it back again with the new path, so it will almost certainly eventually break again. I am honestly not sure, why does do this, but we should probably either patch this behavior or report it upstream.
That sounds very wrong because you have defaults from two different kdenlive versions in there.
I can tell you that I've never touched prior to this debugging session. I didn't even know it existed. Those lines seem to be automatically populated on demand. Most likely, these lines were simply generated at different times, and so they picked up different paths to the "current" version of . Also, the fact that these paths are different from each other is mostly irrelevant in this case. The real problem is that they are cached once and aren't updated when a different version of is used.


Describe the bug fails to build on current master To Reproduce Steps to reproduce the behavior: a checkout of the current nixpkgs master Expected behavior Build succeeds Screenshots <details<summaryNot a screenshot, but build output </summary<p</p</detailsAdditional context The kind of error (not including a needed header) seems to be an upstream bug for me. Metadata Please run and paste the result. Maintainer information:
Fixed by upstream in See my PR


On an apple silicon: $ nix-env -iA I thought was supposed to add support for macos. <!-- 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.
Why don't you ping
I don't own a mac currently and I don't use the package, can't help you unfortunately.


Opensnitch requires system- file to be placed under /etc/opensnitchd/system- to be able to enable its System rules/Firewall settings to be active and changeable. Steps to reproduce the behavior: to OpenSnitch Statistics to the button on the left navigation window just right of Rules/System Rules. cannot change the firewall settings there. the service complains about it. Being able to access that windows' setting. These screenshot shows the corrected version of the window. ! ! Can be solved temporarily with the nixos config below (the file can be found in opensnitch github repo): <!-- 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.
Explain this line to me My hardware wouldn't be "asus" how do I find the directory for that?
the latest change to the opensnitch module (in unstable) has again a change for deploying the system- file, see the file comes from the opensnitch package and is linked to /etc/openstnichd/system- configuring this file is currently not supported. what would your use case be?


Project description ! Metadata homepage URL: source URL: license: gpl3 platforms: linux
FTR: This requires an update of .
I marked this as stale due to inactivity. →


Maybe it's a problem with the ? Don't seem so. I can also not download it manually with curl: (i get a 0 byte file) But i can download it using a browser from the website. But the hash is also different: So they prevent us from downloading the file using something else than their website. Maybe the referer is not enough now? system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:


Describe the bug Test  is broken on Master To Reproduce Steps to reproduce the behavior: Expected behavior For the test to pass Additional context I've bisected the problem to this commit:
Thank you for opening this :sparkles:
In that case let's it.
That is weird. How does depend on rsyslog?
This test is kind of flaky, there's some chance I incorrectly bisected it?
I'm bisecting again starting at
going to plug :grin: At a glance I don't see rysyslog having any relation, and likely if the tests are flakey enough bisecting can't give reliable results.
I didn't use that tool because I was bisecting by running the test thrice and only if all fail considering it a bad commit :P
cc. maybe add a flag to :P
That kind of unforseen usecase is exactly why nix-bisect is not just a tool, but a library ;) So you could write your own bisect script in python (a much more pleasant experience than doing so in bash). I may add that feature to the CLI at some poing though, since its probably a pretty common usecase. would probably be a better name, since we really want a minimum number of tries. Feel free to file an issue against :)
I tried bisecting again, but I think this result is also nonsense:
Core of the issue seems to be this:
I don't know – locally I'm getting this :arrow_up: error even on which (I tried several times).
Careful (manual) bisect lead me to a surprising result: I'll try a few more experiments now. Many my steps failed for other reasons (e.g. libselinux not building), so I suspect that's where you were led astray. I did 2-3 attempts on every step to be surer, but I found no non-determinism on my machine.
I had quite a few steps where the first attempt at building failed, but the second one succeeded, I was bisecting manually with this:
I re-confirmed that reverting that commit atop master () fixes the test for me. (Still no idea why so far.)
cc for the linux config change
Narrowed down just to the kernel option. I don't know... maybe the JIT has some bad interaction with the VM.


For now I suppose I'll push a revert of that single option, unless someone suggests a better idea very soon.
Sounds good to me


I enabled budgie: = true; I opened Budgie Desktop Settings. ! The font is "None", which is wrong. I expect a font be set. I am on a (neraly) freshly installed NixOS. It would be nice if a "Reset to default" button would be there (or some NixOS "magic" for configuring Budgie), but I did not found anything at Default fonts are listed at


The license listed for is incorrect. It has been re-licensed upstream: name: current version: desired version: n/a maintainers: Please tag this issue in your PR.
Fix in (which also updates the package)


Describe the bug To Reproduce Steps to reproduce the behavior: ... ... ... Expected behavior A clear and concise description of what you expected to happen. Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. 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:


Project description Mathematical modelling software Metadata homepage URL: source URL: license: gpl2 platforms: cross-platform
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 .
I marked this as stale due to inactivity. →


NixOS unstable is affected by on Wayland. Steps to reproduce the behavior: signal-desktop on Wayland. No crash. Add any other context about the problem here. Please run and paste the result.
I am also getting a crash every once in a while on startup. Starting it again works so far and it seems stable after that. Don't know what to do about that.
I've fixed this locally by using the following overlay:
Apparently, Signal beta works again on Wayland.
Just adding a data point. Having Wayland disabled actually caused more bugs for me. Re-enabling Wayland via 's overlay helped fix my compositor crashing whenever I clicked on certain UI like "preferences" in the "file" menu. Currently running: with set to and have the following env variables set:


I just discovered and i can't use it on NixOS Pulling image seems good Trying to run image fail because it try to mount some specials folders The : Trying without mounting folder fail because it can't find Start a shell with still fail because it can't find Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(pinage404): channels(root): nixpkgs:
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 .
It could still be important.
I marked this as stale due to inactivity. →


Describe the bug While the configuration contains no settings related to LVM, is launched during boot, and so on, and the "lvm2-activation-generator: lvmconfig failed" message is logged in the journal. Expected behavior At least, does not produce error messages. It might be better if the service is not activated if the system does not use LVM at all. Additional context may or may not be relevant. Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(omasanori): nixpkgs: Maintainer information:
cc
I'll try to find some time to look into this, as I might be responsible for this.
I got this error when running in the console. It just froze, didn't reboot. Hitting enter put me back into the shell. Doing shutdown -h now worked. Very strange ..
I strongly suspect that your freeze was not caused by this warning message.
Yeah, so this was most likely caused by , which combined with the rest of leads to systemd being aware of lvm2 things. lvm2 was already in and for anything that's not a container, before this, but now it's also in . As for why this happens, it looks like it's , which fails when does not return what it expects. Since we do not install the default lvm config, it fails like so: The easiest solution to this is probably to install the default config file to . There is a problem with that though. If we use , we cannot use anymore to append any settings. We also cannot "copy" the defaults into e.g. with , because that would be import from derivation. So the remaining option is to simply set some default settings, which also kind of sucks, because then we need to track upstream on those, but it's probably our best option. If you have any other/better ideas, I'd gladly go for those, but if nobody does, I'll go with specifying some defaults, in a few days.
+1 to importing upstream defaults as it seems the safest option if it tracks upstream properly, even though it will certainly increase the maintenance cost.
I also would just create a default configuration if it is not possible to disable lvm2-activation-generator somehow if lvm is not used.
Detecting if lvm is used sadly isn't trivial.


For filesystems (in ) we can just look at the and enable the respective kernel modules and tools, but how would that be done for lvm?
Maybe it would be possible to fix/patch(&upstream) the generator?
lvm seems to have its default hard coded so we don't need to copy over the whole file. To fix the loading error I just an almost empty configuration to make the warning go away:


The pkg-config file in pkg looks like this: The and variables are empty. The keyword is also empty. As a result, the flags returned by pkg-config are wrong and checking the version does not work. Note the empty and and that the package version is actually 3.0.1, i.e. = 3.0.0. and should point to the correct directories in the and outputs of the pkg.


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


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


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


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


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


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


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


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


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


In executing ibus-setup-hangul, got this error message: .nix -rebuild switch ibus-setup-hangul in a shell System: NixOS 17.03.1584. (Gorilla) Nix version: 1.11.11 Nixpkgs version: 17.03.1584. Sandboxing enabled: build-use-sandbox = false
Might be due to . What was the reason to remove from dependencies?
I think that was because I noticed that it is propagated from some other package, but looking at this now it doesn't seem to be the case. I'll investigate this today!
This seems more deep than I thought. The bug is two-fold: script is not patched as needed for Python scripts; should be propagated from . However, only its output is propagated, so it's not as a Python library. I can fix the first one but not sure what to do about the second -- maybe we should change behaviour of this propagation in some way.
The same problem appears with anthy, and directly adding the same pyEnv to buildInputs like did in ibus definitely fixes the build fails (tested with both anthy and hangul), but the python environment isn't propagated by itself.


Steps to reproduce the behavior: ocf-resource-agents. Relevant: () Looks like a GCC update deprecated , which is used by ocf-resource-agents. This also causes the pacemaker build to fail, due to the circular dependency. system: host os: multi-user?: sandbox: version: nixpkgs: (I'm using commit ) Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I fixed it in my flake for pcs / pacemaker here:


Project description Fprintd replacement which allows you to have your own backend as a standalone service. Metadata homepage URL: source URL: license: GPL2 platforms: linux


Describe the bug Libvirt usually handles virtual network devices, interfaces, bridges and also the DHCP range. This seems to be broken. To Reproduce Steps to reproduce the behavior: a VM connected to the default network 't get an IP Expected behavior DHCP is working Screenshots If applicable, add screenshots to help explain your problem. Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Likely fixed by If you are fine with rebuilding libvirt your could use this locally. Alternatively if this is your home computer and you are in a safe network you could temporarily set to disable your whole system's firewall but this is not recommended. Edit: Rebuliding should be really quick (on a decent laptop)
Thanks - looks right. I will try to use the overlay first.
I think it's related... When I try to start a VM using Gnome-boxes or Virtual-manager with VM using bridge this error happens:
have you updated to the latest nixos-unstable version? This issue itself should be fixed and you should probably create a new issue if your problem persists.
it's still happening, even with the last version.
then you should probably create a new issue as I don't think it's the same issue. It may still be related so maybe reference this issue. There wasn't an error with the original issue I think


Describe the bug results in the following error on : Seems like the writer expects to be executed in a stdenv environment to find instead of knowing the path to it. To Reproduce Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- (rust maintainers)
This should work as long as GHC is proper dep, because libiconv is propagated.
This should be independent of GHC entirely: only relation to GHC is probably that I mistook the error for one coming from GHC initially, but this is not the case ( doesn't allow building the writers individually what confused me).
I'm facing this issue trying to build from on macOS Big Sur. (wasmer is a dependency of FastAPI, which is the package I'm actually interested in) <details<summaryLogs:</summary</details
I think adding to could also help there.
Fix here:


Project description Turtle is a graphical interface for version control intended to run on gnome and nautilus. Currently these dialogs are implemented: commit, add, stage, unstage, revert, resolve sync (pull+push), pull, push checkout, create branch init, clone remotes, submodules log, diff settings and about Metadata homepage URL: source URL: license: gpl3+ platforms: linux


The last fzf update in nixos-unstable breaks certain bash-completions, for example git. This happens since Then try bash completion for git. My looks like this <details</detailsThe regular bash completions for git should work. As a fix I found this old issue in fzf To test this, I tried simply replacing with an edited version that puts the fzf eval after the bash completions code (and before the alias declarations). This fixes the issue. However, I am not sure how to solve this cleanly in NixOS. The bash completion code is inserted using but I don't know how to enforce ordering so that the fzf eval happens after the completions. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thanks for the report, I started a PR super-seeded by fixing this issue. As what I found this issue was already there previously but as most people didn't had the full integration enabled it didn't triggered the issue.
Is there any progress on this? Solution PRs seem to have been closed?
The fix already got merged and will be soon on unstable - otherwise you might cherry-pick/overlay it.
Cool, so we can close this presumably?
I looked at this in master and now we're basically back to how the fzf module was previously, right? So then it should still be an issue when enabling .
Alright, so now I'm just gonna try my luck with a PR. It definitely works for me and makes a difference.


of repo is a branch, not a tag, and there were a few commits to that branch since then. At the moment fresh fetching of source is broken because of wrong : it should be now . should probably be pointed to a specific commit, not a branch? Originally posted by in


The laptop screen freezes with the current contents (systemd startup messages) at the point starts. Nothing else visible happens. I can switch VT's back to text consoles, switching back to VT7 again just freezes the display. All the normal processes seem to be running, but they don't draw anything. I'm using gnome and wayland. Updated to today's () Booted previous system generation, was working again. With some excellent help on Matrix from I have confirmed that: building from previous branch revision () and switching (no reboot) makes gdm work again. building from current revision () with also works. building from the previous revision with that line fails to evaluate, because the multi-version package change isn't there yet. So / are clearly implicated. K900 suggested raising this as an upstream Mesa bug. I had some issues registering there, but may try again later and will add a link here in case system: host os: multi-user?: sandbox: version: channels(root): channels(dan): nixpkgs: bits of relevant config: note that the displaylink driver is not in use (no device connected) at this point, it's all on the internal display only. Hardware is a Dell XPS 13 9360


If gdm is enabled with Gnome enabled, gdm will crash and not load into the login screen after logout or reboot. This is due to gdm using wayland as the default. Once wayland is disabled in gdm, the login works. Steps to reproduce the behavior: channel nixos-unstable, "sudo nixos-rebuild switch upgrade-all" with Gnome enabled and gdm enabled in will hang at the gdm check point. gdm wayland in and the reboot works but with Wayland not working. Reboot into gdm with Wayland <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
I just hit the same issue. After updating to latest nixos-unstable, the boot hangs just before login screen I think this is related to , at least the workaround posted there worked for me also
Would be relevant with a machine without AMD graphics and without KDE? As, I am running Intel's build in graphics and using Gnome. Also, I did find a "workaround" by disabling wayland in gdm then nixos-unstable will boot.
I managed to work around this issue with on GNOME Wayland. Graphic card: Intel Xe Graphics (TGL GT2)
Totally worked! Thanks and ! Should I leave this open as this is a bug or a new config that needs to be applied to 23.05?


Describe the bug A clear and concise description of what the bug is. Rambox apps cause rambox to crash when attempting to upload a file. It gives the message: To Reproduce Steps to reproduce the behavior: rambox rambox in terminal any app that has file upload functionality (I tested Google Messages, Element, and Slack) to upload file Expected behavior Rambox apps should be able to upload files from filesystem Additional context I've seen from browsing other issues that this has been solved before for riot-desktop at first by adding gsettings schema to the package wrapper but currently fixed by using in electron. However, for some reason this did not fix the issue in Rambox. 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. these paths will be fetched (0.05 MiB download, 0.28 MiB unpacked): /nix/store/d43v6bx7r6fcaq3fbbfd5mwh1f5s7rmg-bash-interactive-4.4-p23-dev copying path '/nix/store/d43v6bx7r6fcaq3fbbfd5mwh1f5s7rmg-bash-interactive-4.4-p23-dev' from ''... system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Add wrapGAppsHook to


, CVSSv3=9.8 (nixos-20.03, nixos-unstable) CVSSv3=7.5 (nixos-20.03, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-unstable: . May contain false positives.
needs 1.3.2 for CVE-2016- needs 1.3.1 for CVE-2016-3092


After enable HBase module , and rebuild. The service unit cannot start, it says JVM option not exists. Steps to reproduce the behavior: HBase by adding config . , it should be failed. shows VM option is Unrecognized. I found the same issues on the StackOverFlow, it seems jre 15 dropped the option: I fixes this by adding this line, but it should be fixed in module. I can do the fixes PR if you want. Maintainer information:
go for it. I'm also not maintaining this anymore, so may be best to also remove from .


Project description This project is used by programmers looking to explore the Rust programming language and learn more about it while doing exercises. These exercises are meant to get you comfortable with the language itself and its features. Metadata homepage URL: source URL: license: MIT platforms: MacOS, Linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Interesting package request. But does it make sense given that you need to modify the rustling files in order to use it? I personally used the that's included in the project. which I think are removed in the new release :(
Take a look at . The maintainer of rustlings explained why the was removed.
TL;DR: All required files are embedded in the binary now. The exercises are dumped on initialization. I am the new author. If you need any help, don't hesitate to ping me. Note that a new version was published yesterday.


I'm using Nix 1.9 on OS X 10.10.4 (Yosemite) with the package. It installs without issues, but when I try to use the tool I get this error: I'm using the unstable channel:
Hrm, I get (also Nix 1.9 and OS X 10.10.4) It seems to be an issue with the shebang in as seems to work just fine. I don't see anything obviously wrong with though... (PS hi long time no see :)
I just hit this issue too. Weirdly, just running from different shells would give different errors (I use fish normally, so it's always an early suspect around problems like this). I would get an error like got from , and an error like from . When I change my to this: Everything works, and in all shells the same way. Is this a valid fix? (By "works", I mean I get , but maybe that's a separate issue, or due to a lack of familiarity with Elixir/Erlang...)
Nice catch. Doing will generate a new app skeleton if everything is working as it should.
Turns out I just forgot to put the at the end of my fixed version, so no args were getting through :P Is what I mentioned above an acceptable fix? If so, I can submit a PR.


I have installed sage thorough the nix package manager and it is the only thing I use nix for so it is entirely possible I am doing something stupid and wrong. I have the latest from here build When I try to get to the index for all entries which is located on my computer, I get a page with very few entries (see the screenshot) below ! While I expect something more like Compare /nix/store/r77k14kq9iw92w32bd9sny7d98dbrq32-sagedoc-9.6/share/doc/sage/html/en/reference/genindex- and A full fledged index. I want to use to generate a docset which I can then search following the answer here I can build a docset after copying the reference directory to somewhere I have write access to. However when I try to search there are almost no results and I think this might be responsible. Please run and paste the result.
I'm not very involved in sage maintenance these days, I mostly contribute by reviewing and PRs every now and then. They are probably better qualified to help you :) Maybe we should drop me from the maintainers list, or at least change the order to reflect reality?
Sorry for the bother then! I was actually going by the information here which looked outdated but I didn't have any better idea.
Thanks for the report! Will take a look today.
Thanks a lot!
No bother :) Thanks for the pointer, I have updated the maintainer information there.


I have an EPSON DS-530 scanner, that I can't use to scan anymore. Prior to upgrading to NixOS 22.05, it worked perfectly fine. Steps to reproduce the behavior: scanning as follows: a sheet of paper in the scanner and scan it using utsushi, scanimage, simple-scan, xscan, … scanner pulls the paper through, but this does not result in a scanned document with any of the programs I tested. The (probably) relevant lines of the full log output (see below) are: The page is scanned successfully. The symptoms look exactly like those described in . The full debug output is as follows: <details<summaryLog</summary</details
I just noticed that utsushi reports version 0.65.0, which doesn't match the supposed version 3.65.0 in the channel. Though it seems kinda plausible to me that utsushi just reports major version 0, as the rest matches?
Trying to debug this further by scanning with , I got the following lines of output: The line () looked suspicious to me. I attempted to narrow this down further using strace: Interestingly, this refers to a file called , that supposedly should exist in the / package's directory, but doesn't as the strace indicates. The only reference to this that I could find is in the . If not provided with a different engine as a command line parameter, it should just use tesseract. This in turn led me to in the utsushi codebase, which calls the filter. I stopped my investigation there for now. Maybe can give more context, as they came up in many of my searches regarding this.
can you try adding to and see if that works? It looks like calls out to and expects to have it in , so probably falls back to ?
can you check if fixes this?
Thank you but unfortunately this didn't help. I'm still seeing references to in the where I suspect that I should see references to tesseract instead. It would be sufficient for me to deactivate all the postprocessing that happens, but this doesn't seem intended feature in utsushi :/
As I had amassed quite a backlog of documents to scan, I started a nix shell with the utsushi version I used previously, using the following command: This works.


However, this is only a workaround, as this means that I need to use the interface for scanning, which is somewhat cumbersome to use and this also pulls in a lot of old packages via the dependencies. I'd be happy to try out anything at this point.
Hey, I started looking into this again and noticed that in you switched the sources from the to the repository on gitlab. I'm wondering what the reason for this was. Do you remember?
I think back than the maintainer of utsushi suggested this. Imagescan just tries to mirror the driver as it is release by epson, while utsushi contains community maintained patches, but unfortunately no clear versioning scheme.
I just bisected the changes and it turns out that is indeed the commit at which utsushi stops working for me.
That is unfortunate. Maybe we should offer both utsushi and imagescan as packages, than the user can choose.
This could be a solution. I am not sure yet, whether the problem may also stem from one of the patches introduced or the command removed in that commit. As I am getting a error, I think it possible that the problem may be related to the imagick (or a similar) dependency.
It turns out, that this problem had a . Adding the following line back to the derivation makes utsushi work again. PR adds it back to the derivation and fixes scanning on my machine.


Describe the bug After upgrading to nixos-20.03 and enabling pulseaudio support I started experiencing the "Gah! tab crashed" error too often, to the point that browsing sites with certain types of embedded media (mostly audio/video) instantly triggers the error (e.g browsing ). While troubleshooting this I also noticed that opening crashes not the tab but the browser. On the console I can see: This crash is present with default options (i.e. and ). In addition, after several crashes Tor asks to start in "Safe mode". I'm not sure what safe mode disables but it allows opening without crashing and/or triggering the segfault. This seems to hint at some interaction with external libraries and my assumption that this is somehow related to pulseaudio. To Reproduce Steps to reproduce the behavior: the URL will crash Notify maintainers Metadata The following expression was used to enable and : and installed with .
Can you try with override ?
This helps. On a quick test I didn't see any "Gah! Tab crashed" error and works fine.
It should be off by default then, it used to work :(
Could this be triggered by a missing or mismatched library? I also only started noticing this after enabling pulseaudio system-wide. If this helps diagnosing the issue...
I think it's simply because the firefox jemalloc is incompatible with the hardened allocator. firefox has to be built with for that to work. I wonder why this appears to have worked before; maybe the tbb build has changed. Relevant mailing list thread here (fair warning: it turns into a not-so-productive exchange after a few messages):
I think that at this point it'd be appropriate to revert the commit that hardened alloc support, with a note as to why, maybe opening an issue to track work (if anyone cares) to make hardened malloc work with tbb/firefox.
I'm not into the differences/advantages of each allocator. In this case I have the user hat on and unless there's a critical aspect of relevance I'm happy to trade that in favour of a functional browser.


Unstable Bitwig doesn't know where libpipewire- is when attempting to load the Pipewire audio device. Console error !


Project description A cross platform front-end GUI of the popular youtube-dl written in wxPython. This makes the awesome commandline tool usable for more people! Most repositories use the package name youtube-dl-gui, so i recommend to use it tool. Schould be quiet easy to package. Metadata homepage URL: source URL: license: The Unlicense platforms: unix, linux, darwin, ... (Python)
Sadly the project is not maintained anymore and has issues. We shouldn't add it.
There is an active fork:


The systemd initrd (or stage1) does not work with a volatile root when there are 9p mounts present. A result of this is that VMs built with nixos/qemu-vm do not work when disabling the (and thus running on a tmpfs) and using the systemd initrd. Create a test that sets these options: The test should work just like the test works in who has identified the root cause (an ordering issue where the tmpfs is mounted before the 9p infrastructure is up) and found a hack around this behaviour.
I this to the board because it will require a test when it is fixed.
As a side note, we should consider using to implement volatile root with systemd stage 1.
As far as I can tell we could only do this if we mounted under .
So this works probabilistically. Sometimes it succeeds, and sometimes it fails with for one of the 9p file systems.
Ok this patch seems to fix it Which begs the question... why does it ever work, with or without volatile root? EDIT: Oh I bet it's a race condition caused by not depending on . In order for to appear, virtio modules need to have already been loaded. So, because gets mounted first, and needs to wait for to appear, that means virtio modules are definitely already loaded before any children of are mounted. And indeed, switching from to just does the trick as well.


When opted in to the latest Steam Beta (version ) starting Steam fails with the error Looking at the log output, it looks like it fails to load : Steps to reproduce the behavior: into Steam Beta steam Steam runs ! stdout when running : Please run and paste the result.
i'm able to reproduce this as well
In case anyone experiences this and wants a temporary workaround, you can opt out of the Steam Beta by running
I think this might be due to a change in nixpkgs rather than steam, since this works for me on: But it breaks for me when I update to:
Building with running with and using the bad commit is part of cc
Please test .


Specs-nvim does not work in Neovim 0.10 and the author has not updated the upstream version. The derivation should point to the updated fork instead: Steps to reproduce the behavior: specs-nvim with Neovim 0.10 specs-nvim errors Should I have used the out-of-date packaging report issue template instead? Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
no pb for me. Feel free to submit a PR. Pinging as he might know better.
What does no pb mean? I'll make a PR
I guess that it means "go for it, let's switch to the fork".


To make sure that we are on the same page: When I run ledger-autosync, it complains about a missing module. I expect it to run It prints:
Let me know if there is any other information you would like me to provide.
cc maintainer (btw, nlewo, your nick in is wrong)


crashes, even when installed into the system. Steps to reproduce the behavior: shell "nixpkgs#gnome-frog" -c frog Program doesn’t crash Please run and paste the result.
Interestingly, I was able to build and run the app in commit (I also rebuild it with just to double check). ! Though, it does fail to build and run in recent revisions (at least in ). It needs to apply to be able to build. Running it however gives me the following error: Not exactly familiar with GTK development but I'll see what I can do. Thank you for reporting!
Running it on my end gives me another error:
frog+main+Application' doesn't support property gobject-introspectionbuildInputsnativeBuildInputswrapGAppsHookGITYPELIB_PATH`, resulting in typelibs being picked up from the environment.
Thank you for the explanation, . Simply putting into did build and run the app (at least in the recent commits).