Describe the bug On NixOS 20.09 and unstable, is not in the search path, even though it is installed with the php package. To Reproduce Steps to reproduce the behavior: [example from 20.09 system] Expected behavior [example from 20.03 system] Additional context Debugging with reveals that on 20.09, php is searching in , then , which fails. On 20.03, it searches in , then , which succeeds. On 20.09 and unstable, php74 and php73 both fail. On 20.03, php73 (the default) works, but php74 fails, but I believe it fails for a different reason. This line is new since release-20.03. At first glance, it seems as though is resolving to null here, but I'm not sure what to replace it with: Notify maintainers Metadata Maintainer information:
Thanks for reporting this issue! Your guess was right on spot and it was a really simple fix it seems :slightlysmilingface: As you may have seen: Right after 20.03 branched off we started a big refactoring of the PHP ecosystem. So bugs and issues was to be expected :slightlysmilingface:


I'm using the example of which renders correctly in firefox (the text in that section matches the image), but not in chromium (I see some placeholder boxes) my font configuration is exactly that given in I'm running nixos-unstable. I don't have flash enabled, or any other modifications to the default chromium package. From a bit of research, I've found that it might be the case that chromium restricts access to system fonts in some way, as a privacy aid - possibly that is to blame. Note: this occurs without any addons (running chromium as )


Describe the bug When cinnamon is started either via gdm or in a . Sometimes the desktop icons do load Always a window spawns telling me that I'm in fallback mode no taskbar, no window decorations (hence I think no compositor & window manager) To Reproduce Here I'm kind of unsure: I deleted all nemo and cinnamon folder in $HOME, .config and .local/share. Still this occurs on all of my machines. IIRC this first happen when accidentally starting a "virtual keyboard" app cinnamon "Virtual keyboard" cinnamon components crash instantly, the and the behavior is reproducible on further attempts of starting cinnamon Expected behavior Cinnamon starts and is usable Additional context Booting into an old generation did not fix this, however, I'm quite unsure what could be the cause of it. This is some log which I could create by running cinnamon from a . I'm not sure whether this is related to the issue or not. relevant : Output captured (the log is over 2000 lines long, this is from the very end and might be the issue): Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(wucke13): nixpkgs: Maintainer information:
I will say that it does start in lightdm. IIRC upstream uses slick greeter and lightdm, so maybe it's just broken for that dm.
it is broken when started on as well, and it used to work in gdm just a day a go as well. Thinking more of the problem, what else can break the startup of cinnamon if all of these are empty/removed: + + + ? There must be something in my $HOME which alters the startup procedure of cinnamon to break (otherwise it wouldn't work for you?!) but what can it be? Edit: I now gathered a more meaningful error: Edit 2: Found the remaining part thing: dconf. After renaming , cinnamon starts just fine. Holy moly. Running "Virtual keyboard" from the cinnamon menu breaks it immediately, though.
Which package provides gio for ? We'd need to add that to buildInputs then the error should be fixed
That is . Be sure to on the source code to always run a to see what namespaces are imported. From there you track where those typelibs come from to determine the dependencies that belong in
Any updates on this?
It would need to be tested if the issue still persists.
The bug is still persistent. system: host os: multi-user?: sandbox: version: channels(root): channels(wucke13): nixpkgs:
The bug is still present in 21.05: system: host os: multi-user?: sandbox: version: channels(root): channels(wucke13): nixpkgs:
The main problem I have is that I have no idea where to even start debugging the segfault, as it seems to be part of native code
Any chances upstream has some idea? Not sure how to get in touch with them without making it seem like "We have a problem and you shall fix it".
I ran and I found that it is missing , just install it and the bug will disappear. I think this package is a must or we have a security-issue here
I can confirm installing caribou fixes the issue. I haven't really looked into it yet, the related line is likely at And I managed to SIGSEGV gjs-console (cjs-console) in a shell with: I search for the output , and found this So I do and the SIGSEGV is gone. So I guess caribou is needed for this case.


, CVSSv3=8.8 (nixos-20.03, nixos-20.09, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-20.09: ; nixos-unstable: . Cc


With NixOS 15.09 I get this error running LilyPond: I can work around this (clumsily) by using an old version of in LilyPond's . This differs by not including . This seems to be related to Changing apparently can break some users of as well as those of .
cc
Hmm, perhaps we should add or some similar option to handle these cases easily?
It's better to set in most cases, which I just did in and .


Describe the bug defines the CMake path. The environment variable is included in this, and addons like SDL2mixer append themselves to this path. However, that same file also defines an target, which does not include in its include directories. See for an example of an issue caused by this. To Reproduce Steps to reproduce the behavior: to build an application relying on SDL2::SDL2 adding SDL2mixer to the include path, such as Expected behavior 's should include the environment variable, just like . Screenshots N/A Additional context N/A Notify maintainers (SDL2), (SDL2mixer) Metadata Maintainer information:


Experienced on gnome3.38 which is currently on master. alacritty 0.5.0 isn't functional at all. 0.6.0rc-1 is. Should we update in order to make our packages set functional? Or should we wait for a real, no rc release upstream?
you should update yourself in the maintainers list - I had to go to to see who is .
Is this a wayland issue on gnome?
Yes.
Sound fine to me.
Thanks for pointing this out. As much as I want to see my first username long gone, the change was not worth it :)


Updated using I though most of the packages have moved on to openblas, what is pulling in this package? How would I find out?
A few packages still reference it. should show what derivations use it directly, from those you have instantiated.


Describe the bug option is not working To Reproduce Steps to reproduce the behavior: service and its option in . Add as well for testing. In my case I used something similar to the password read bit is set, for the test generation: (eventually) inspect logs with in a separate terminal a mail The command might return And you might find an error similar to this in your logs Tested on 19.09 and 20.09, on different machines with three different SMTP hosts, various passwords, with and without special characters. As explicitly warn in the doc Path to a file that contains the password used for SMTP auth. The file should not contain a trailing newline, if the password does not contain one. This file should be readable by the users that need to execute ssmtp. I ensured that the password do not contains a leading space or carriage return. Expected behavior should work just as well as its former obsolete attribute. Additional context eventually check again my password in the store: which is yet followed by the character . It's obviously a control character and I cannot find a definition of its meaning. The very same command (original pass file) won't return the . following configuration works, with of course the exact same password as provided in the password file. Which is obviously not the expected setup. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Make sure that it doesn't have a trailing either. Editors like vim tend to insert one by default.
I can confirm.
Is this still a problem?
I haven't been able to validate the response using or alternative editors.
Use to avoid the trailing newline. To check whether there's one, use ; with this command, newlines are displayed as .


Seems like nmap changed the licence with the 7.90 release from GPL-2 to NPSL (Nmap public source licence). NPSL is "based" on GPL but adds some nasty things such as: Which conflicts with the freedom 0: Discussions about this: Debian: Gentoo: Upstream: The actual license file: They also seem to bundle a GPL library, and their license doesn't seem to be GPL compatible. So we should probably add this new license at least. NPSL looks non-free to me. Non-free is a good default until FSF or anyone has looked at it. We can always follow suit with what Debian does as well.
Another option would be to revert to 7.80 for now. The new license seems to be a legal minefield even if you're ok with closed source.
Yeah while looking at the issue in the train I thought of the same as well, will do that now.
I just read the release annoncement for 7.90: Just to see if the license change was mentioned there. Which it is: Do I read this right they weren't really GPLv2 to begin with and just clarified that? That's like a major thing...
First of all I just realized that I merged the original PR, so I really have to apologize for missing that license thing back then! cc in case you currently have time and energy for that, would you mind taking a look at the issue? I'm pretty sure that you have way more knowledge and insights about that kind of licensing issue than we have :). Is there any kind of statement from OSI or FSF yet? Also, I'm wondering if other distros that are even more focused on free software than we are (such as Guix) have e.g. started a new fork that we may want to use as well.
More details from the changelog: I must say that I'm not sure if it's worth to roll the package back since it actually haven't seemed to change really. It just was weird to begin with and just now got a name on the weirdness.
It's not just a new name, apparently they also new requirements in 7.90:
I don't think we should revert it either. Add the new license and mark it unfree until this is clarified.
Oof.... that's actually another reason for reverting.
I'm in favor of marking as nonfree until the FSF or some other authoritative organisation decides otherwise.
Either revert, or mark as non-free. Or, revert and add the new, non-free, version next to it.
The nmap update has already been reverted. Let's wait what upstream and the legal teams of debian/fedora say. See also the upstream issue
Fedora's stance
That's the old license (until version 7.80). This issue is about the new license (in version 7.90).
Fedora the new licence to the bad list and marked it as "not acceptable for use in Fedora" due to being incompatible to the open source definition
So, now there's an update here that we may want to act on: To quote the post: This means that 7.91 is now available under the same license as 7.80 is. The license that 7.80 uses is still a "bad license" because it's still a custom license. But it's a license that we and other distributions have considered good because it was assumed to be GPLv2. So I'm thinking that we could upgrade to 7.91 by now, because it's still not good, but it's not worse than before except we are aware of it now. Then we just hope that they do some good re-licensing in a future release.
Merged which removed nmap-unfree. This issue is done for now. Thanks everyone.


This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I opened a PR here: Thanks in advance for reviewing :-)


This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.


Describe the bug Milkytracker is missing a menu entry to launch the application Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --


We should replace the discontinued source with the more active fork . wrecker/stern hasn't received any commits since 2019. The maintainer of stern doesn't work at wercker anymore, and it seems no one else there is maintaining it (wercker/stern). The community has since moved to stern/stern with improvements to the original source. Project description Multi pod and container log tailing for Kubernetes Metadata homepage URL: source URL: license: Apache-2.0 platforms: unix


Describe the bug spacefm segfaults on start with the following output: invoke spacefm on the command line Expected behavior an up and running GUI program Screenshots see error message above Additional context I noticed that there is no It makes no difference whether spacefm is installed via nix-env or Notify maintainers Metadata** $ nix-shell -p nix-info --run "nix-info -m" system: host os: multi-user?: sandbox: version: channels(root): channels(oo): nixpkgs:
I bisected this crash down to Perhaps the package needs to be updated to support the newer version of gtk3?
Hi. I cannot reproduce the crash with (current master). How about you?
Yep, that same binary segfaults for me. I'm on
still crashing with the same error message. Then out of curiosity I ran . The backtrace of the main thread has: 0x0000000000000000 in ?? () 0x00007fa6931c3ceb in ghashtablelookup () from /nix/store/hnk0s558k2h4v8abjzagagflvw1l0cb2-glib-2.66.4/lib/libglib- 0x00007fa69375c50c in gdkx11windowlookupfordisplay () from /nix/store/8pidhwid3ww58wlq705irf48c01dr0hv-gtk+3-3.24.24/lib/libgdk-3.so.0 0x0000000000499915 in getdesktopindex (win=win at main-window.c:4179 0x000000000049bfd1 in fmmainwindowgetoncurrentdesktop () at main-window.c:4225 0x0000000000496343 in handleparsedcommandlineargs () at main.c:1143 0x0000000000421808 in main (argc=<optimized out, argv=<optimized out) at main.c:1526 and now I am wondering about as I am running Wayland and sway. I don't know if it's relevant though.
Does it help if you run spacefm with the environment variable set? BTW, I am using X11.
Seems this a known bug:
GDKBACKEND=wayland does not help. Found an even older bug report from 2015: Question: this is an upstream known bug. Should I close this issue? (I don't know what the protocol is in this case)
I am not sure. Maybe we can at least improve something here? Change the description to call out that this does not work with wayland for example? Patch it that it fails gracefully with an explanatory message when not run under X11? Then, it seems the project is also not really maintained anymore. Maybe it's time to let it go?
Another idea: a wayland display driver (is this the right wording?) should fall back to x11 support via xwayland if an application cannot run under wayland natively. SpaceFM is a x11 only application, could you try to use and see if it makes a difference?
it actually runs with GDK_BACKEND=x11! Thanks for the suggestion.
I have created a PR to make x11 the only backend that is used.


Describe the bug (and, therefore, pretty much any package) fails to build on armv6l. To Reproduce Steps to reproduce the behavior: an armv6l machine. (I actually used an aarch64 Raspberry Pi 4B.) Additional context The segfault comes from , which is invoked by the Linux kernel build system. Here's a minimal C program that segfaults, when compiled with the from : A git bisect reveals that the faulty commit is (). Notify maintainers maintainer of binutils (since that's what seems to be the culprit here) author of Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(gaelan): channels(root): nixpkgs: Maintainer information:
I guess that this patch should only be enabled on armv7l then. Truthfully that PR was just changes proposed/written by others and someone else is probably more qualified wrt binutils to say what the correct thing to do would be.
I don't think it's an armv6l vs. armv7l thing: fails in the same way. There's a possibility that the issue is that I'm trying to build on a Pi 4, which is actually a 64-bit machine, with a 64-bit kernel. To test this, I copied the linux-headers closure, and all of its deps, to a Pi 0 W (which is actually armv6l), and got the same bug. It is still possible that the issue arises due to the Pi 4 miscompiling one of the dependences. I'm doing a full build on the Pi 0 to rule this out, but of course that could take a while.
Alright, also fails when building from scratch on a Pi 0. At this point, I'm pretty sure this patch just breaks building anything natively on aarch32.
Thanks for the testing I'm not sure what's more important, cross compiling to arm32 or native compiling! Hopefully can shed some light here.
What a mess! I guess the patch fixes some relocations breaks others. If we could make minimal programs for both that would be nice, but that's a lot of work.
Ah I see already minimized in , and we can cross-reference Jessica's patch on this issue too. So maybe once we minimize this issue we'll have enough combinations to try that it shouldn't be so bad.
I have this problem on armv7l as well, on the novena board. 5.9.8 headers required for building nix fail.
I'm running into the exact same issue using arm emulation via on my x64 machine.
IIRC GHC was the only package affected by the bug in my NixOS closure when I had it running on an armv7 machine back in 2019 and it was also happening on native builds; had nothing to do with musl or cross. Couldn't we just make a special binutils with the patch for GHC and the (at worst) handful of other programs which need it?
Hello everyone, I'm trying to make use of the recent changes. Here what I've done: I'm using the nix installer from . I guess this should actually not be needed any more as we now have for this merged . Using my Pi4 with 32bit kernel: pi $ uname -a Linux raspberrypi 5.10.17-v7l+ SMP Fri Apr 30 13:20:47 BST 2021 armv7l GNU/Linux on the unstable channel (should not be relevant) and on current running: now passes. W-h-o-o . However, compiling our friendly greeting: results in the following segfault: Seems like this PR has not been all to fix the broken target. Anyone aware of the issue here and how to continue? Happy to update the official Wiki as soon as I've things working ... also including the hydra tarball. Thanks!
try cherry-picking commit from
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Thanks . That definitely helped but failing at stage4 now: Hmm, looks like the OS killed it? - maybe OOM? I guess there is a way to reduce memory load by reducing the number of parallel jobs? Do we know the minimal config right now?
I had no issues building the entire system (with a few tweaks) on armv7l virtual machine with 4 cores and 4G of RAM. You can try building with . Do you use NixOS? If not, is nix installed in multi-user mode?
Yes, OOM often produces exactly this "killed" log line.
Also make sure you have zram swap (perhaps even with zstd) if you're running into OOM issues. It's free additional RAM space.
Hitting the exact same bug when cross-compiling to armv7l now, in packages that have PIC disabled (zfs)


Describe the bug There may be something flaky about the python3{789} build. It's been going on and off on hydra. I can't reliably reproduce the failures seen on hydra locally when building from the exact same commits that failed on hydra, but I have observed the same failure at least once on my machine. ! Expected behavior dask should build cleanly. Notify maintainers Metadata


Describe the bug Just lost on two different NixOS machine my Signal Desktop history because of this faulty update... I don't know, probably doesn't make sense for people to downgrade who are already upgraded but for others it dataloss To Reproduce Steps to reproduce the behavior: Signal Desktop Signal Desktop you to delete db, if you interact in a wrong way it will delete your data Notify maintainers ( and
Sorry to hear that. I recently lost my history too... It's really frustrating! Yeah, unfortunately I don't think there's anything we can do about it (as downstream package maintainers). AFAIK the source of the bug is still unknown, it doesn't seem to affect all users, and all releases have a limited lifetime ("expire" 90 days after the release, see my comment in ). Thanks for saying that! This really bothered me too... I just didn't say anything because I was too angry to keep it nice enough. (I raged a bit here but after I realized that one cannot even import old backups I had to take a break.)
I just got hit by a similar issue by moving from Archlinux (encrypted database) to NixOS (non encrypted database). After many things, the easiest fix to ensure proper functionalities IMHO is installing: This will disable tracker3 and prevent SQLite to be loaded in the process which will replace SQLCipher and cause the SQLite3 API to be the original one (i.e. non-encrypted) and cause many issues down the road I guess. That might not fix everything though :upsidedownface: Opened a PR:
FYI, in case anyone has feedback/suggestions: We might merge soon and it should cause another "Database startup error: Error: SQLITE_NOTADB: file is not a database" error (which is really unfortunate but not easily avoidable).
Heads-up: I've just merged to hopefully resolve this once and for all and the Python wrapper script should take care of the database re-encryption when launching Signal-Desktop as usual but the user experience isn't that great and you probably want to backup first in case the script fails unexpectedly.
Thank you, I just upgraded Signal on my computer and the re-encryption did work as intended


Carry over discussion from IRC #nixos-dev and . Inspired by the doc change in recommending top-level usage of over , we want to reduce confusion for newcomers and unnecessary complexity by making the canonical way to access the Nix library. We may still want to keep to not break external code, and place a or similar at its definition site. There are over files where occurs at least once. Beyond splitting this change across multiple PRs, in what ways can the change be automated? Pinging
In the short term, we could add this check in ofbrorg and , and update any examples in the documentation to reduce new usage of .
Don't forget things like and .
Ah. So 45K occurrences across 11.8K files.
toplevel is done
the xorg dep generator also doesn’t put it in its output anymore
trewide rewrite in
doc changes in
Graph of occurrences over time:
Nice! What scripts did you use to generate it?
There's a source code link now :)
Found another large source of s. Fixing cabal2nix should remove around 24k occurrences in .
Status report
Just found out that counts stuff like as well, so
Is it ok to rewrite to ?
That's the lib output of , so no.
an easy way to find out is to evaluate both in
Subfolders of with <10 changes needed in PR
Around + replacements out of 30k+ are concentrated in - should be trivial to regenerate the file with the new desired contents.
I'm working on it but it's a bit more complicated than I anticipated.
What problems are you running into?
Part of code generation of cabal2nix is in an external dependency, so I had to open two PRs. The dependency is itself on Hackage, so we may have to wait until the change propagates to Stackage LTS and then Nixpkgs, unless peti will use an override or something: I'm not familiar with the cabal2nix workflow.
I think the haskell-updates are mostly done from a local checkout of cabal2nix, so it depends mostly on what version peter is using. You can also probably just ask him, he is generally available for such things on his .
could you help here?
The Haskell infrastructure has switched to the new style with commit . It will land in this Friday. I have also updated the generator code and released new versions to Hackage, so I guess the Haskell infrastructure can be considered done.
Thank you
More accurate regex: (the one above captures stuff like
When is merged, this will be the result Three Nix files remain that use directly.
The last usages of it can be found by commenting out where it is inherited in .
I just got this warning while doing a , but it doesn't give me any info as to which derivations are at fault. Is there any way we could improve the message to identify culprits?
With , you should get a hard error which will allow you to use . Or you can update Nixpkgs, since it has been removed in


, CVSSv3=7.5 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc


, CVSSv3=7.5 (nixos-20.09, nixos-unstable) CVSSv3=7.5 (nixos-20.09, nixos-unstable) CVSSv3=5.3 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: .


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


, CVSSv3=6.1 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc


Describe the bug I believe the source for the package might no longer be valid: Accessing it in the browser shows a 404, and the home page -- -- appears to just be a portal for serving sponsored links. The Wayback Machine shows that the has not been archived since February 2020, and also get the same 404. There was a in Septermber 2020, but I'm unsure if this was the cause. Thanks! To Reproduce Steps to reproduce the behavior: . Expected behavior Installation should not hang, and the font should be installed. Screenshots Additional context appears to be an alternative to Helvetica, so I'm unsure how important this package is. But I figured this error should be documented. As far as I can tell, is the only package using , so if this domain is indeed no longer usable then nothing else should be impacted. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
but the link is also dead: so i would ask there where the font is available and if it is freely licensed now. it was also licensed by adobe at some point it seem to ba available from several shady websites, like but that's clearly illegal and shouldn't be packaged in nixpkgs freely licensed alternatives are: (Nimbus Sans)
I marked this as stale due to inactivity. →
Could the helvetica-neue-lt-std package be removed or at least generate a better error than a 404 when it tries to download the font? I ran into this error while doing a nixos-install so it took a while to find the specific package that was causing my build to fail.
Thank you


Describe the bug ! was something changed about the exported package list? Expected behavior same number of packages or even more Additional context we used to have the most packages, but now AUR is on top again
Maybe is part of this.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Might also be a redefinition of a "project" on the repology side, i.e. duplicates that weren't detected before. Projects != Packages. Do we know the revisions of before and after? We could check whether anything went missing from in the tarball because that's the source of Repology's data.
Well it must've happened on January 16th so we could use one commit from the 15th and 17th and see if there are suspicious changes in the that json file in between. Using we can pick a merge commit from the 15th e.g. and one from the 17th e.g.
We need to know the state of the unstable channel on those dates, it's days or sometimes even weeks behind master. Don't really have time for this right now but is probably what we need.
Well it must've happened on January 16th It did appear in Repology on 16. January, but our channel take some time after a commit was done. So i would check like the 9. Jan.. There was a successful channel evaluation on 2021-01-07. Channel evaluation: () packages file: () () () Latest unstable channel evaluation: () So the number of packages decreased by 8,990 between 2021-01-07 () and 2021-01-16 (). There was this change of emacsPackages to on 2021-01-13 () And it's indeed the emacs packages that are missing on 2021-01-16! ! Number of : Number of packages that are in but not in : Full list: For example . It does not exist in packages-2021-02- It does exist today in the search: But not on Repology: We should really be consistent here. The packages that nix can install from nixpkgs channel, and Repology should be identical!
, and so on were moved to their respective interpreters as & in Partly this is to fix the asymmetry of not having package sets available for the packages. The old names now only exists as aliases which probably explains why they have disappeared from Repology. I think this opens up a question regarding if we should remove from . We've tried this before and it makes tools like a lot slower since these package sets are pretty massive. Maybe we should only expose for the default Emacs package but not for the rest? That way we also don't count every package in the sets N times (where N is the number of distinct Emacs packages).
I think such tools should show packages only once, even when they exist for different interpreters like emacs26 and emacs27. But it should be obvious that you can use both. The raw package list should still contain all i guess, so tools like repology get all nixpkgs has to offer. But that is a big topic and it's about UX. For example in the search. Now it looks like this: ! But this would be less cluttered and more user friendly: ! (I opened an issue for that ) Same in .
The bug is probably here: did update the set names here too but I don't think sub-attributes work in that construct.
Nice catch! I've attempted to conjure up a fix in but it needs more testing before I'm comfortable merging.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Status: rPackages is fixed See for example "tidytidbits" on or . In the package set list is also emacs27, but i don't find any packages. When i search for random packages that existed before, like "pony-mode" i don't find it now in search or repology. The name does exist in which is not found in github search, probably because the file is too big. On repology you find only 1 emacs package in nixpkgs! So the package set emacs27 is still missing from .


<!-- 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: radvd <!-- 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: 2.18 desired version: 2.19 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.


Describe the bug dmd keeps references to boostrap compiler. To Reproduce Steps to reproduce the behavior: Expected behavior dmd has no references to boostrap compiler Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(symphorien): nixpkgs: Maintainer information: Note: to prevent future regressions, it would be nice to add to the derivation ()
I marked this as stale due to inactivity. →
Still an issue
I marked this as stale due to inactivity. →


Describe the bug The build of the RPI4 image has been broken for a few weeks now. See: The module closure fails to build with: CC Maintainer information:
Caused by See
For the time being, there is no quick way to work around the issue. From the list of available modules, most are needed. We'd need to be able to filter out a module from the list, which AFAIK for lists is impossible with NixOS modules. So uh... annoyingly it'll have to stay this way until some resolution of the overall issue :/... An alternative, but quite intrusive, would be to split the aarch64 profile into an "aarch64 base profile", from which the normal aarch64 and the raspberry pi 4 profiles inherit. Though I don't really like the approach since the raspberry pi 4 profile is, overall, a temporary measure for a somewhat popular and hard-to-work-with platform. It might be more worthwhile , in the long run, to take a final look at 5.10/5.11 mainline and if it is enough to allow a user to bootstrap themselves finally.
couldn't we allow missing kernel modules when generating images at least?
The interface/abstraction for is lacking. The fact it's a list, and lists are really hard to manipulate once set in NixOS modules makes this basically a hard task. I guess augmenting with a (default true) would help. But really what would be required is to tell per module whether it is needed, and allow overriding data. So needs to somehow allow setting "yes/no/optional" per-module, in an ideal world.
Quick idea but what about adding a or something like that and then use setminus as the required kernel modules? Edit: or yeah depending on how it would work using a dictionary?
Using an attrset for availableKernelModules would be the solution. But that breaks existing use cases by default, probably. There might be something coming to handle this issue ; But this is a hard problem to solve correctly AFAIUI. I wouldn't like having the bad abstraction any more than the current breakage that I don't like.
I suggest then to revert the commit that broke this until we have a better abstraction.
I've merged that fixes this issue. Once it you can . You can build it on nixpkgs master using .
I don't think it solved this issue. works around the issue by removing the raspberry pi 4 board-specific image. With merged, the modules are still to the raspberry pi 4 board-specific image, even if they're not present in the kernel build. In fact, there may be more failures! It ends up adding more modules present in mainline, absent from the vendor-specific kernel build.
recommends using the generic image anyway, so that's why I considered it fixed.
Ah sorry, I pre-emptively edited this page. And I'm splitting hair right now because technically the issue is still going on. But really it's all but merged-and-solved.
It appears to still be broken. Booting the latest image from Hydra ( ) results in the image being unable to find /nix/.../init, and failing to continue booting from there.
I've booted the same image and it works. What steps did you take? Mine are:
I performed the same steps, except the last one where I instead used GNOME Disks to write the disk image to the SD card. I don't have a way to reproduce it currently, since the Raspberry Pi 4 I was testing it on, has since been formatted with a different OS to be used in a production system tomorrow. I'll see if I can get my hands on another RPi 4B and perform the same steps again. edit With an exception that I used unzstd instead.
Same, unzip was a typo.
I've gotten my hands on one now for a few minutes, and it appears to be getting an error like: It prints this continually, until I press a key, and are presented with the option to reboot or continue. Continuing kernel panics, and reboot, well, reboots it.
The SD card used is the NOOBs SD card, but overwritten using the command as above, but with the device replaced.
Booting with the same SD card using Ubuntu Server 64bit OS or Ubuntu Core works fine.
It sounds like it "works" up until stage-1, where the kernel is somehow unable to work with the SD card. It might be a combination of that is causing the issue. Do you have other brands SD cards, or same brand but (probably) different batches? It would be helpful to know whether "Ubuntu Server 64bit OS" and "Ubuntu Core" are using the mainline kernel or not. The driver differences might exacerbate issues on marginal hardware.
The underlying issue is now invalid with being merged. I invite you to open an issue, linking to this issue, for your particular problem. It seems you have some kind of hardware-specific issue at first glance.
Thanks, i will test it with other SD cards as well. It appears to only happen with this distribution, but it could certainly still be related to the hardware.
It is likely the other distributions are using the vendor kernel, and that the driver differs in a way where only mainline has a specific issue. Using the "latest kernel" variant of the image may also be something to look into.
I've tried the latest kernel variant as well, but I'll create a new issue with more details once I've collected more information.
I am trying to build NixOS for the raspberry Pi 4 and ran into the same error that started this thread. FWIW, I'm seeing this on nixpkgs and on as well. Would it be prudent to re-open this ticket or file a fresh issue?
please open a new issue and ping this issue with the specific problem you're observing detailed. Please detail what you are attempting to do (e.g. whether it's booting through SD or USB), and as much information as you can. Note that there is a known issue (totally unrelated to this one) about USB boot, ().


Stressful Application Test (or stressapptest, its unix name) is a memory interface test. It tries to maximize randomized traffic to memory from processor and I/O, with the intent of creating a realistic high load situation in order to test the existing hardware devices in a computer. It has been used at Google for some time [...] In my experience it's an absolute monster in finding random memory errors that don't show up over weeks of real world usage. Until ECC is commonplace, running this software is necessary. Metadata source URL: license: Apache 2.0 platforms: linux
could you please give a try?
worked no problem, thanks a lot!


Describe the bug When i try to import a config file, i get an error: When i copy the exact same text in , it does work. The file does exist and i can read it, even with the caddy user! So this seem to be a bug. To Reproduce Steps to reproduce the behavior: ... ... ... Expected behavior A clear and concise description of what you expected to happen. Additional context Add any other context about the problem here. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Without knowing anything about my first guess would be this: Is it possible this command is evaluating your configuration? If so, the issue is that the command is being run sandboxed so has no access outside the sandbox to your file. Build time commands can be tough.
That would make sense. So NixOS brakes the import feature.
Out of curiosity can you please paste your relevant config?
what exactly do you want to see? For a workaround, i just copied everything into the NixOS option: But in some cases, it's nice to have the webserver config. together with the website sourcecode:
Thanks for posting. The context helps. I think this is what you want:
It could make sense to add an off-by-default option to opt-out build-time configuration check.
Given my above solution, I'm not sure what value it would offer in this scenario. What scenario did you have in mind Can this config file hold secrets maybe?
Then you don't have to use such a workaround on NixOS and can just use it as described in it's documentation. There can be secrets in it, but i don't see how that's relevant here:
Hi, module maintainer here. I was the person who made the original PR for adapting s for Caddy 2, and I had no idea about the directive at the time. The motivation was to generate TLS settings from the module options and merge them with JSON-ified . Please use as suggested for now, and I'll see how I can make this easier in the future.
I marked this as stale due to inactivity. →


Describe the bug While building the minimal installation iso without using the cache, building smartmontools on fails with: Indeed looking at it looks like the URL should be and indeed produces 11n54ycsy512q4linczzj1x3dyj0q4zvh928rq3lqnkg9jh0kbiv This was in and seemed fine at that point.
the difference between the cached and the downloaded file is:


Describe the bug A clear and concise description of what the bug is. To Reproduce build e.g. or Notify maintainers Metadata Please run and paste the result. Maintainer information:
I marked this as stale due to inactivity. →
pkgsCross.aarch64-multiplatform.perlPackages.PkgConfig still fails with the same error on
Had a quick look: Seems like PkgConfig depends on File::Glob::bsdglob during build (which uses miniperl). Maybe adding a for wrapping to in perl-cross is the way to go? PS: I'm not sure if this is the correct approach, not very familiar with cross compilation. Any ideas on how to fix?
considering the failure in the here actually comes from a failing , so a simple fix might be this: This has allowed me to cross-build on x86_64-linux: I'll post a PR shortly for your review :muscle:
As a follow up, the resulting / scripts seem to work: (I have multiarch exec via and enabled BTW)


, CVSSv3=7.5 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc
See also:
CVE details indicate that is vulnerable until version (included), which is the version we have in . Version seems to be the latest available: .
I'm actually wondering why this issue was created. We have thrift 0.13 in both unstable and 20.09. Closing and debugging my code...
I think the issue was rightfully created: it says INCLUDED!


, CVSSv3=7.5 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc
See also:


Project description Flawfinder is a simple program that scans C/C++ source code and reports potential security flaws. It can be a useful tool for examining software for vulnerabilities, and it can also serve as a simple introduction to static source code analysis tools more generally. It is designed to be easy to install and use. Flawfinder supports the Common Weakness Enumeration (CWE) and is officially CWE-Compatible. Metadata homepage URL: source URL: license: gpl2 platforms: unix, linux, darwin
could you please test Thanks
Works for me on NixOS. I wrote a simple c program that it found the vuln in: where it gave:


Describe the bug I switched from to on KDE. But the audio control tray icon is gone. Media keys don't work either. Note that can adjust audio volume and switching devices without issue. Audio output is also fine. Not sure it's an issue from KDE or pipewire side. Here is my configuration: and are both running. The latter one has some error but still running as well. To Reproduce Steps to reproduce the behavior: X11 and KDE. sound configuration above. , log out and re-log in. audio icon in system tray is gone. Media keys don't work any more. Expected behavior Audio control from KDE and media keys all work. Screenshots ! Additional context Also mentioned in <!-- 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:
I believe the solution is just to have and installed, so you can install them manually for now and that should work.
I switched to pipewire some time ago and subsequently forgot all about it (things just worked) and I haven't had the tray icon disappear at any point. I cannot comment on media keys. Keyboard doesn't have them.
After adding and into , and a reboot. The tray icon appears in a wired state. There are two forever-muted icon shown. One prompts the original "Audio Volume" window, but shows . Though the audio plays well. ! Another prompts a small window shows several volume slider. The "Master" has no effect, but per-application control works. (Another strange thing. When opening this window, any shortcut of KDE doesn't work anymore, including my screenshot key and ) ! Pressing any media key including toggle mute, increase and decrease volume keys, always shows a "Audio Muted" tip.
Note that doesn't work anymore after updating to current nixos-unstable . It shows "Establishing connection to PulseAudio. Please Wait..." forever, while are just running fine. Not sure if it is caused by the pipewire version bump
Sidenote: should be removed from your config, according to . I think it enables ALSA. Kind of annoying, but similar to how should be false if using .
Tried but it made no difference.
Works fine for me on current unstable with and installed through home-manager. I have the pipewire setup in .
I'm using pure pulseaudio facing the same problem. After installing kmix and plasma-pa, I also get two audio icons and the other situations like the picture. I believe one of the is for the original plasma which is muted and the other is from kmix. By the way, I'm on an old laptop and the media key is not working until I installed kmix.
Sorry for necroposting. Any updates on this? I have this problem too.


Describe the bug fava does not build on master since the merge of staging-next in : To Reproduce Steps to reproduce the behavior: -env -f ~/code/nixpkgs -iA fava Notify maintainers hi


Project description The recoll package exposes a python API. It'd be awesome to have a package for that. Metadata homepage URL: related: source URL: Main package already exists - platforms: unix


Describe the bug Upon enabling docker via sysctl.d is not updated to allow IP forwarding which is required by containers to communicate with outside world. To Reproduce Steps to reproduce the behavior: This will get up and running with set to which in my understanding is set by the itself. to re-apply system-wide sysctl settings and check By now your bridge-mode docker containers lost connectivity. Expected behavior I expect to override relevant values. Something like this: Additional context I discovered this problem when applying other sysctl values on a running system without a reboot. Notify maintainers Metadata
Hi, I stumbled into the same issue. I had to manually run to regain container internet access.


name: current version: desired version: latest version: maintainers: Please tag this issue in your PR.
You'll have to package pydeck as well
Here's my hack to get things working: And WIP:
I can PR this for you if you accept maintaining the dependency.
ping


Describe the bug Postgres already exists as a nix package () bundled with some packages (). Postgres itself has built-in support for Python, but it needs to be enabled during the build process () via the configure flag. The current implementation of postgres in nix does not enable python support, and it also doesn't seem to perform any detection whether python support should be offered. There is already some form of conditional feature support (for example via the attribute. It could be possible to add a attribute that enables python. My knowledge of nix is clearly lacking in this regard, but I hope the idea makes sense. To Reproduce Steps to reproduce the behavior: via then use to initialize and start a server instance psql to enter the postgres instance 'create extension plpython3u;' ! Expected behavior The ability to enable the plpython3u extension. Screenshots This is a screenshot of the current configureFlags of postgres (). Somehow it should be possible to get into this list. ! Additional context I am trying to get a nix-shell working that has a postgresql12 with python support. I am not trying to get a working configuration in NixOS. It should be possible to use to explicitly add support for plpython. I am still exploring this possibility. Others have done something similar for other postgres extensions (). There is a nix pill that describes how to override packages here () and here (). However, it looks like this can get complicated (). More examples of overriding can be found here: Another approach for overriding packages is via overlays (). By including support for python in the derivation itself, it may be easier for new users to get started. attempted to add support for multicorn (), which is implemented using python (), but this doesn't use plpython3u, and is thus not directly related to this issue. Just mentioning it here for others that are trying to figure out how to get python in their database backend. The author of the following article shows how to configure postgres using : I can imagine a solution that may look like this: . Another possibility, is to have something like (see etc.). Notify maintainers Can you recommend a way to get plpython3u enabled in the nix build of postgres? Metadata Please run and paste the result. Maintainer information:
The following extract seems to work so far:
I marked this as stale due to inactivity. →
I'm interested in using this but not sure when I'd be able to pick it up.


Describe the bug Library is not found when linking on macos. To Reproduce Execute resulting in following output: Expected behavior Deno builds without errors on macos. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(suraj): nixpkgs: Maintainer information:


Describe the bug For sandboxed builds on my mac, any python tests which ultimately import will fail with this error: To Reproduce Somewhat tricky to reproduce since it only affects downstream dependees, and a recent commit disabled the dask tests, hiding this issue. See for an example. Additional context Dask.dataframes infers an optimal chunk size using a package to get the amount of available memory and CPUs. This non-determinism breaks the build. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --cc Metadata This is not valid since I am building from master of nixpkgs. system: host os: multi-user?: sandbox: version: channels(noah): nixpkgs: Maintainer information:
That's a clear upstream bug; apparently their value is not given.


, CVSSv3=8.8 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc
See also:


, CVSSv3=2.7 (nixos-unstable) Scanned versions: nixos-unstable: . Cc


Describe the bug Trying to run a nautilus-python extension (syncstate-) fails with ImportError: could not import gobject (error was: ModuleNotFoundError("No module named 'gi'")) To Reproduce gnome3 and install nextcloud-client nautilus from terminal with something like Expected behavior python should find gi. Additional context I think it is part of pygobject3 which is in buildInputs therefore I think it is a problem of a wrong NIXPYTHONPATH Notify maintainers Metadata system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
I am not sure if it ever worked. The shared module links against pygobject but that still does not have to mean the gi module will be available on Python side. Maybe we need something like the following: At least until we have .
Yes this works, thank you!
hmmm I just tried with the new nautilus-python, but the nautilus python extensions still fail due to missing gi. Is there a reason that you tried to load gi in nautilus-python and not add the prefix arg as in your comment?
Did you make sure is updated? It worked for me with gsconnect extension. I chose that method because pygobject is really nautilus-python dependency, not nautilus one.
nevermind it works now (also with nextcloud), I forgot the in the overlay where I overwrote the package from master. Thanks for fixing it!


<!-- 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: ghc <!-- 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: 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.
Today I tried to install , but it failed at downloading : complained about hash mismatch. It seems like URL has changed.
I used the following overlay as a workaround:
Should work with .


nixosTests.blockbook-frontend fails to build Discovered in Refs Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Maintainer information:
cc
Tests are "fine". It's the main that's causing the issues (failing to build) and it was not working for some time now (as I've discovered also ). I did some initial debugging and broke the . I've notified upstream but I guess there's little I can do about it so it either gets fixed or we should remove the package altogether.
Hm, I suggest we mark blockbook as broken for the time being:


Describe the bug nextcloud default nginx config did not include the ` config see: but expires is set in Expected behavior no expires, the cache option causes problems with the usage of Deck


Describe the bug The phosh lockscreen will accept any pin. To Reproduce Steps to reproduce the behavior: phosh screen with 1 even if it isn't your pin! Expected behavior Probably use the numeric password of the user Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Solution The PAM configuration seems to be at fault. I can't PAM my way out of a paper bag, but I tried one attempt: Why ? Here's why: That doesn't explain the issue. Only a plausible fix. With this, only the user password is accepted. We should get someone who understand PAM to look at this. Metadata Ran on top of . Maintainer information:
Uh, so the problem is that does not exist, so there are no requirements enforced? Or what does our pam file for phosh look like? The better approach would likely be to add here:
Sorry, I probably misexplained a bit here: we're not using the manjaro pam bit at all. So I suspect those are not good at all. When using the manjaro bit verbatim, you just can't unlock! I guess adding to that list you linked to could do it too? If the other snippet is removed.
Ouch, that pam file is not testing for anything meaningful, so it shouldn't come as a surprise. Login works if you are not root. pamnologin is a PAM module that prevents users from logging into the system when /etc/nologin exists is designed to succeed or fail authentication based on characteristics of the account belonging to the user being authenticated. pamsecuretty is a PAM module that allows root logins only if the user is logging in on a "secure" tty, (Quoting from their individual manpages) Because we have no pam.d file.


Describe the bug json-glib seems to be a new transitive dependency of tracker/gtk, which the Paradox launcher needs. Somehow it isn't being pulled into the Steam container. To Reproduce Steps to reproduce the behavior: Steam a Paradox game (eg. Stellaris) to start the game Expected behavior Instead of the launcher working as usual, it doesn't launch at all. Launching it directly yields the following error: Additional context Adding json-glib to steam's fhs wrapper libraries is sufficient to start the launcher, but should it be propagated by gtk implicitly? 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:
which game? I tried eu4 and CK3 and both launch fine
Stellaris. Funny that it seems to work with the others, I suppose it could be something specific to my system?
Unlikely, steam games run in a bubblewrap sandbox, so your host system doesn't matter much.


It used to be possible to build (it is possible on 20.09), but these days it fails with: I’ll try to bisect it…
Bisecting points to by Nathan, do you have a hunch?
Cargoculting what I saw in the GHC code, trying this right now:
Seems to work, fix in
There appear to be multiple linker bugs affecting at least Rust and GHC with Musl . Both bfd or gold had issues, gold seems a little worse. I would suggest trying lld, it may fix it.
lld with gcc is currently not supported and I think last time I tried we can't build OCaml and all its dependencies with clang+lld fully yet…
The second commit of ("match leading/trailing arguments") should fix this
That's great news!
Fixed by


, CVSSv3=7.8 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc Cc
09 is still vulnerable
NixOS 20.09 is EOL, so this issue isn't actionable anymore.


, CVSSv3=7.5 (nixos-20.09, nixos-unstable) CVSSv3=7.5 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc Cc


Describe the bug fails to build on master/release-21.05. The build failure ( is not found anymore by cmake) appeared with the update of from 2.9.10 to 2.9.12. Addressing CC


Describe the bug The rhdf5 library does not work on latest release. To Reproduce Expected behavior A shell with R and rhdf5. Additional context Instead I get: Notify maintainers Metadata Maintainer information:
"6.topic: rust" should be removed, this is an R package, not Rust.
This was fixed in


Describe the bug I believe the auto-cpufreq daemon should start on boot if enabled. To Reproduce auto-cpufreq daemon: . the system. . auto-cpufreq as dead/inactive. Expected behavior auto-cpufreq service should be started on boot. Additional context I was using the unstable service in 20.09 and it worked as expected. In 21.05 stable, the service starts dead/inactive and my system is very slow. I manually start the service and I'm back to the NixOS I know and love. I was able to fix this by adding the following to my configuration: Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(pnelson): channels(root): nixpkgs: Maintainer information:
Sorry for being late, should fix this.
I have the exact same issue now, on 23.11.
Same here, also facing this problem on 23.11...
Thought this might be caused due to some false overwrites in the module config, so I decided to try out rewriting the systemd service. Doesn't work either...
For others who might still be hitting this, I thought I was too. When checking the logs I saw that power-profiles-daemon was starting up, causing auto-cpufreq to shut down. I fixed this by adding: From looking at this code, and be kind with me here since I'm a nix beginner, it is .  I think the best action would be to add an assertion to give users a prompt like with tlp. If this looks correct I can open a PR for it


As reported on we need some patches: In particular: gnome-settings-daemon needs bluetoothd needs cc
At least for g-s-d we're already on 40.0.1, which seems to have the fix? Both commits referenced (!232, !234) are there, but maybe I'm misreading. Not sure if we want to address bluetoothd with , but regardless I have a commit ready.
Above is no longer necessary with 5.60. I'll open a bump for that instead.


Describe the bug The current downloads 2 patches, both of them 404. I realized this when I tried to build my system from scratch without substitors. To Reproduce a system that somehow depends on mercurial (not exactly sure if this is reproducible with just or similar, this was also on a content addressed machine, and reproducing the issue in a more isolated way would require another toolchain bootstrap which takes several days) the system from scratch using see errors like this: Expected behavior mercurial builds without errors Screenshots See log output from reproduction. Also ing the URLs as in the derivation linked in the description result in 404. Additional context The exact commit the system was build from is nixos/nixpkgs/, though as the same path URLs are used in nixos/nixpkgs/master, this is probably only partially relevant. Notify maintainers cc Metadata nix shell nixpkgs#nix-info --option trusted-substituters -c nix-info -m system: host os: multi-user?: sandbox: version: channels(nmelzer): nixpkgs: Maintainer information:


Describe the bug I'm on a mission to get (and thence ) compiling on M1 Macs, and having fixed , the next stumbling block is 4.1.1. Sadly, the build fails with , presumably related to . To Reproduce Steps to reproduce the behavior: Expected behavior A clear and concise description of what you expected to happen. Screenshots Additional context This works fine when built for x8664 on the same machine. 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 system: host os: multi-user?: sandbox: version: channels(steve): nixpkgs: Maintainer information:
Submitted PR which disables Fortran support for OpenMPI on aarch64-darwin. Would that fix the issue for you or do you require Fortran?
This seems to be the build failure:
I actually have no idea if I require Fortran. I mean, presumably it's enabled for some reason, so I'm a little wary of disabling it on only one platform/arch combination: that feels like an atypical workaround.
To reproduce: I wonder if the gcc maintainers can offer any insight?
seems to hint at the stack-protector hardening, so perhaps something like could work around that? (no idea what's the real cause though, and I have no Darwin machine at hand)
You were right! Sent a PR in


This tracks the conversion of from DocBook to CommonMark per . here that you intend to work on this. (Please also post if you stop working on this.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections in the NixOS and Nixpkgs manual for inspiration. the CommonMark back to DocBook xml with: from nixpkgs root dir with: a preview server with: your work at on steps 5-9. it looks good, commit both the new file and the generated file, submit a PR and reference this issue.


has two forms of input for the field. and . I personally use the latter as it is the output of and better than having cleartext passphrases. (This also works with a random AES key - so long that it is shared) The current implementation lacks the distinction and only works with passphrases. I believe this should be .


Project description
I marked this as stale due to inactivity. →
ping! Is this still an issue?
has been The command still does not have documentation in the Nixpkgs manual.
Is satisfying? Could use approval to get merged.
It's a good step, but it doesn't (yet?) tell me what the options are.
Now it does.


Project description Emote is a modern emoji picker for Linux rocket. Written in GTK3, Emote is lightweight and stays out of your way. Metadata homepage URL: source URL: license: gpl3 platforms: linux


Looks like it is missing python3Packages.setuptools...
works for me - please provide output from
fixes that, but then you will be running into
I have informed the author of archivy, and he's looking into it.
This is because in the version requirements are loosened and an incompatible new version of flask is used to run archivy. Removing this change to the version constraints for flask would fix the problem.


gPodder crashes and dumps core when trying to import an OPML file: Steps to reproduce the behavior: "Subscriptions -Import from OPML file" the crash I'm using KDE Plasma, not Gnome as a desktop, in case that's related to GSettings discovery. gdb backtrace from the coredump: <!-- 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. Maintainer information:
This crash does not appear in the flatpak verision of gPodder, so I assume it is related to our Nix packaging.
Looks like something on my system sets the right environment variable to prevent this crash: I tried to add dconf, gsettings-desktop-schemas and hicolor-icon-theme but nothing seems to be picked up by the . Maybe has a better idea? The crash only happens when I do with nix-shell.
That would be schemas from gtk3 if it crashes on trying to open file chooser.
Yeah but gtk3 is already in so something is off here with
If it is Python package, it needs strictDeps false
indeed fixes this issue, see PR
This is quite a footgun, can we disable from somehow?


See the : the options aren't declared by any file (it's actually , but that's stripped at some point). I think this is most likely because they are declared inside a : but I don't know the module system well enough to troubleshoot this. This was causing the unstable channel import to because of an which should be fixed by This is an issue of the module system, so pinging
fixes this, thanks for the report!


This project is no longer activily maintained! there is a spiritual successor, so maybe package that instead cc maintainer
I marked this as stale due to inactivity. →


NixOS's wrappers for gcc also apply for gcj, which is a Java compiler. The wrappers add the flag to gcj's command line, however the Java language does not have a preprocessor, and means a different thing for gcj. This means that gcj cannot compile anything. Another issue is that gcj links to zlib by default, but does not pull zlib into the environment. This means that, even if the former issue is silenced with , compilation still wouldn't work.
A similar problem for gfortran:
I marked this as stale due to inactivity. →


<!-- 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: <!-- 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: 4.6.3 desired version: 4.11.2 <!-- 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.


After enabling the GNUnet service with , it prints a lot of errors at startup: Additionally, attempting to stop the deamon with reveals that it is apparently not even running: Please run and paste the result.


When adding to and running , emacs 25 builds and fails with 4 unexpected TRAMP mode test errors: The full output contains null bytes and weird control characters that don't let me paste this into a gist easily. Is that part of the test or indicative of the problem? cc
ok... i think this will contain the build output? again if i open it in emacs there are lots of control characters. had to zip so github wouldn't complain.
I disabled for emacs25pre, for now, on my system. I hope this will be resolved upstream before next release ...
It's quite possible that tramp-related tests fail because there is no proper networking support in the build chroot, i.e. it's not possible to resolve host names or service names. Another source of trouble could be the lack of an UTF-8 capable locale in our default build environment. Anyhow, it would be really good to report those errors upstream to make sure that the next Emacs release has them fixed in one way or another.
I've been working with the Tramp author for the past several days about these failures, and we've identified that the problem is somewhere in the environment that the tests are presented with, but we don't yet know what exactly. I'm still digging into it.


I tried updating it, but no luck. I think the new glibc 2.23 is the reason for configure fail: I've only been able to find arch having the same issue, no patch yet. cc
This is strange. I do reproduce the build problem, but when I compile the configure test and run it myself, it succeeds (and measures bytes). (Of course I do compile it with the stdenv from 16.03.)
Comments on note a workaround.
Temporary workaround on arch:
Fixed then?
FYI the fix to Xen build system is committed. See ;a=commit;h=


I want to use the TTS Mimic on a Debian 11. After installation, I Tried reading a text. Cli usage give me an "alsa lib error". Steps to reproduce the behavior: -env -iA -t "hello world" A clear and concise description of what you expected to happen. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. Please run and paste the result. Maintainer information:
works perfectly on NixOS 21.05. Can you elaborate more about your sound setup? While geared toward NixOS, this thread might give useful information to debug further: Also try running ALSA tools or CLI audio applications natively from Debian and via to observe any differences in behaviour.
The above works for me too on NixOS, at least. I'm not familiar with how ALSA and PulseAudio in nixpkgs integrate with non-NixOS systems; perhaps a thread on Discourse might be of more help.
I was able to reproduce your issue on Ubuntu 20.04. It seems this is . A few workarounds are mentioned in the linked issue.
It seems mimic just needs a proper wrapper: should give you some output.
Ok, I found a solution with inspiration. alsa-lib-1.2.4 doesn't containt but if i installed alsaPlugin (nix-build -A alsaPlugins '<nixpkgs'), this works for me : However, not really user friendly.


Project description A cross-platform TUI database management tool written in Rust Metadata homepage URL: source URL: license: mit platforms: unix


After upgrading to Firefox 92 on NixOS unstable, anything that requires a menu or a tooltip in the browser (hamburger menu, right click context menus, tooltips on tabs, etc.) stopped working. The menu itself isn't rendered, the whole UI freezes and sometimes the cursor changes to a hand, indicating a clickable button, but nothing happens when clicking where the button should be. Clicking outside the area where the menu should appear restores Firefox to a usable state, until another menu button is pressed. Steps to reproduce the behavior: Firefox the hamburger menu button on the top right corner The main settings menu for Firefox should appear. The hamburger button remains in a "clicked" state and the entire UI freezes, the mouse cursor might change to a hand, but no menu is rendered. Running Firefox on Sway with and Maintainer information:
I can reproduce this too, but I don't think it's NixOS' fault; we ought to report this upstream to sway and Firefox.
You can manually apply this patch to firefox to fix the issue: I'm testing that now.
~You should be able to use this overlay to work around the issue for now:~ This partially fixes it
Alright, this overlay fully fixes the issues while we wait on a new release: I'm going to make a PR adding this to our pkg for now.
The two patches applied, menus and form overlays are visible again and the freezing is gone. Thank you
Unfortunately, it seems the fix has not worked for me. It may be due to using the home-manager module; however, I have overriden its to use the patched version and the only noticeable difference is that now a tiny vertical line appears where the context menus should be. The freezing caused by it and the fact that the menu itself is still unusable are still present, though.
There were multiple similar bugs, perhaps?
As a data point: I'm running Firefox 92.0 with the above mentioned patches on Sway on NixOS unstable and everything works great.
Do you happen to use the home-manager module or do you run Firefox as a regular system package? That may be a differentiating factor and may point towards an issue with my home-manager configuration instead.
Through home-manager.
I have tried to add your method of explicitly wrapping the package and yet, the same behavior remains, unfortunately:
I wonder if this could differ based on GPU model. (different rendering code paths on driver side)
Interesting. It is working for me on amdgpu, but I saw the issue yesterday on an i915 gpu, didn't investigate much, whether the patch already made it onto the unstable channel.
Yes, it is in already but not in yet.
I have tested this on amdgpu, nouveau, and i915 without problems. I'm wondering whether is actually using the patched version? Try to clone the repo, do and see if it works correctly. Alternatively, this should give you a firefox with the patch so you can make sure:
Ah, I managed to reproduce it on i915 now. It's not immediate for me, after a bit the menus seem to break. Amazing.
Maybe we also need this GTK patch:
Also worth trying:
Interestingly, the firefox-unwrapped package in my system has a different hash, namely . Compiling from the nixpkgs repo as you suggested does give me the version with the hash as you stated, and this version does behave correctly in regards to the menus. Something really strange is happening with my system updates then. Adding to this, I only got the version with the "black vertical line" as I described above (I attached a screenshot for reference) after I garbage collected a few generations of testing, which really shouldn't happen if I'm understanding the way nix works correctly. In any case, this is not an issue related to the Firefox package itself. !
I successfully have this working with firefox from mozilla's pkgs.
So I was able to fix this by removing the package from my home-manager config and adding it to my nixos-config. Not sure if this helps anyone here debug the issue, but it's worth a look. EDIT: Well, menus are fixed. Tooltips are still messed up.
I've been running Firefox out of a local nixpkgs build but I haven't tried messing around with the system config yet since then, I'll try your suggestion. One thing of note is that some sites' dropdown boxes are still broken, even with the patches, while everything else has been working fine.
I don't know what exactly is wrong but I am getting the random flickers on Firefox 93 as well. Has anybody found a solution?
I still get this issue sometimes. It's odd because it's very hit-or-miss for me; restarting Firefox often fixes it, and restarting it again results in it being "broken" again. The same thing happened for a long time with the screenshot tool in Firefox: sometimes it works, sometimes it doesn't, and restarting Firefox sometimes "toggles" if it does or doesn't work. I haven't been able to debug any further, though.
I haven't experienced this issue anymore since Firefox 93; both the Bugzilla issue and the GTK merge request report this issue as fixed, does anyone else still have this problem?
Can you share your exact config related to Firefox so that I can try it? Last time I checked I still had the same problems in 93.
In , add to the list of packages. Then, in : EDIT: shouldn't make a difference, but for completeness' sake, I also have this in :
Thanks! Do you use any environment variables such as ?
I actually didn't use that, but maybe I should. is set by using the package.
Oh no. The flickers are still here for me with the following config.
That is troubling... might it be a GPU-related issue?
I marked this as stale due to inactivity. →
I think this can be closed as it has been fixed for me since 94 or something.


Currently we have two expressions that both build the kernel, whose only interface differences are in whether or not the .config is generated or provided. These builds should be merged with the two different interfaces simply being two ways to call the same underlying function, reducing code duplication and allowing the generic kernel builds to benefit from the IMO better structure of the newer manual kernel builds.
+1 on getting rid of duplication What is the "better structure"?
Structure may have been the wrong word, but the manual kernel build uses multiple outputs (suboptimally currently, which was part of the problem with the old PR) and uses the official kernel build system for building and installing, while the generic one (last I checked) had a manually maintained shell script to handle the install and parts of the build.
Fixed by


Practical consequence: with (this log snippet is cleaner thanks to ) I checked that it really is the patch by applying Some bugs are discussed in the upstream ML thread: I'm not sure about the best approach for us so far; the rebuild amounts complicate this. Perhaps just temporarily fixup the kernel build and get a properly fixed cpio with the next iteration? I expect that three to five upstream commits will be needed; maybe just the whole diff since the last release.
I think we should just fix this in master; the channel isn't going to advance anyway, and I'd rather not ship a known-buggy version of by fixing just the cpio used by the kernel. Is that reasonable?
Maybe the current channel version with public code-execution exploit (linked above) is a worse bug than this, but I don't know how commonly this bug manifests. ( channel has advanced, by the way)


fails to build as There is an invasive change that fixed it in newer version: . But maybe it's a good time to remove old version? Maintainer information:
Started with commit
Is there a reason to still keep Ardour 5.x in nixpkgs? Edit: The reads: Is that still the case ?
Yes it is, but I'm not sure it's worth the effort to fix Ardour 5.
I prepared a PR which drops ardour_5 if we decide to go this way:


insync-v3 server doesn't seem to start. See that there is no insync process running. Please run and paste the result.
I believe this is caused by the Insync binaries expecting specific versions of some system libraries like glib. A similar problem has been reported on the Insync forums by a few Gentoo users. See and Since Insync releases are pegged to Ubuntu/Debian/Fedora releases, I'm not sure there's a good fix for this. Fortunately, I was able to get insync v3 working in a nix-shell environment that is pinned to an earlier commit of nixpkgs (). I uploaded a reproducible flake here: The system icon shows up as a red circle, and native Wayland support doesn't work, but it seems fully functional other than that.
Using nixpkgs pinned at , I've been able to successfully run insync version (the version currently in nixpkgs) and version (latest available version). This suggests that there was an update elsewhere in nixpkgs that wasn't backwards-compatible with insync. Pinning nixpkgs works for now, but it's not a long-term fix. Maybe we can try to identify which libraries need to be pinned and explicitly pin those? Or maybe use binaries targeting a distribution which is more up-to-date?
I've noticed this as well a while ago, and even figured out what the issue was, but was too lazy to report it until now. Sorry about that. When you run it should tell you why it can't start. In my case it had some issues harfbuzz, which most likely comes from the upgrate to version 3 . Harfbuzz removed some functions that were not officially documented, but are used by qt webview, which is why it fails. I think this is going to be fixed automatically at some point with either an insync update or an update of qt webview in nixpkgs. But until then, your best bet is to use insync from an older nixpkgs commit. It might even be a better idea to completely remove insync from nixpkgs and providing it as a flake, that has a working nixpkgs version pinned to it.
For me just produces :(
Hi how can I test this pinned version? Thanks!
Any fix for this? insync start --no-daemon Traceback (most recent call last): File "", line 19, in <moduleFile "site-", line 829, in call File "site-", line 782, in main File "site-", line 1259, in invoke File "site-", line 1066, in invoke File "site-", line 610, in invoke File "", line 87, in start File "/usr/local/lib/python3.7/site-", line 627, in execmodule File "", line 11, in <moduleFile "/usr/local/lib/python3.7/site-", line 627, in execmodule File "", line 7, in <moduleImportError: /nix/store/41ms51yaqhqwfp83z8dms55g4abfzihp-insync- version `GLIBCXX3.4.29' not found (required by /nix/store/z8hz4nlh48niad995hs4w33wwryc3lkr-qtbase-) [2847] Failed to execute script insync
I'm afraid it has been a while since I used Insync because I couldn't find a fix for this type of issue. Instead I have been using which is
I reached out to insync back when I made my last post and begged them to look into the issue. I offered to pay for a fix. I was told it was to the developer backlog. I've switched to using .
Yeah, it is frustrating that the Insync developers don't seem to be interested in providing a distro-agnostic version of their product. A flatpak or appimage distribution of insync seems like it should be an obvious win for them, but they haven't committed to anything. Here's hoping; I liked using Insync when I was able to.
are you achieving continuous (real-time) sync with those tools? Neither of the two tools supports that by itself , . If you're achieving it by using the tool as part of a more elaborate solution, would you mind sharing how you're doing that?
I wrote an overlay to pass by the error 403 of url down and I get it installed. But doesn't open yet The error:
Update about . It worked when i pinned a rev from github. To fix the broken URL I created an overlay to override the version and URL of current version on nixpkgs.
I am trying to fix it for the latest insync binary... But it doesn't work, it crashes, badly If I don't do these: Insync will crash with: Something about GLIBC_2.36, while nixos is still at glibc 2.35. But it shouldn't be a issue, otherwise insync would only work for distro that is glibc 2.35... Hope it gives some hints, if anyone wants to continue from here, feel free!
I made build and insync-v3 run again, but it would need to patch two more python packages... to continued.
Update from , the package should be resuscitated soon, coming to unstable and hopefully in time for 23.05!
thank you for persevering on this and getting insync working again!
thanks for this package! Could you also please add the .desktop file and icons? The base insync package has them but they are not to the wrapper package and are not currently user visible. Thanks again!
Also the insync binary is currently named insync-${version}. Can you please strip the version from the binary name? Otherwise the desktop file won't work. Thanks!
No problems. I will look into these!
Might have the desktop files solved.


"Source" link in search result on for Poetry package is pointing to poetry2nix source code instead of poetry. Steps to reproduce the behavior: on "Source" link in "poetry" package. This will point you to instead of When clicking on "Source" link in "poetry" package search results I want to get to "poetry" source code If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Maintainer information:
This is really a bigger issue in how source code locations are extracted and it isn't unique to Poetry/Poetry2nix. The root cause is related to how is extracted: In this case is resolved to where Poetry2nix inherits descriptions from /. You can explicitly pass to which I just implemented in :
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


is "no longer maintained" or distributed, and the releases are unavailable: <!-- 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. Maintainer information:
A closed source substituting another one? Well, it can be fixed by aliasing them to a failure.


I would like to do this myself, but I'm getting some errors. I fixed the version fetching in , but now I am a bit stuck: No change to the actual package file is seen. I was able to work out that those errors are coming from inside but that's as far as I got. <!-- 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: bluejeans-gui <!-- 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: 2.23.0.39 desired version: 2.24.0.89 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: (tagging because just merged my bluejeans version fetch PR ()) and (tagging because seems to have committed to the package recently) Please tag this issue in your PR.
this is why it fails:
something like this will work:
Oh! I thought the I saw when checking was from something else. Thanks.
Thanks for picking this up!
First step:
looks like my work paid off and the bots are taking it the rest of the way


To make sure that we are on the same page: Kernel: (run ) 4.5.0 System: (NixOS: , Ubuntu/Fedora: , ...) (Flounder) Nix version: (run ) 1.11.2 Nixpkgs version: (run ) During testing of I managed to get at least two different hashes for . After some discussion with it seems that this derivation can produce non-deterministic output. Hashes of outputs are always the same. They are not. Build several times.
How would one work around that? It basically means the system cannot be rebuild :cry:
cc
You can work around it by updating SHA checksum in the affected package locally.
:confused: Is there any documentation you could point me too. I know how I would to it for packages that I install as a user: out nixpkgs repo the last commit that build for unstable on hydra that out the exa's file 5 run But I think it's also possible to override it in a nix expression, like the one in , since I installed it as a systems package. The thing is that all ressources I find either explain how to do it for that they link to
I changed my to include that: but to no avail :confused:
Sadly we don't have a mechanism to override (it needs to be supported). However, you can rebuild your whole NixOS from a modified repository:
Another way to do it is to call patched nixpkgs from your :
Thanks for your help! I really appreciate it. I tried your last suggestions, but that leads to: It looks like some network hick up, but I tried it multiple times and I opened the github repository from the same machine and it loads fine. Maybe it has something to do with this line: ?
Hm, unfortunately I have no idea what's going on -- you've fixed the hash, so it seems like another problem in .
Still thanks for the help. I learned a lot!
depends on a git repository in which doesn't work with
maybe fetchcargo could take an argument to pin git-based dependencies on a certain commit?
I can confirm that this is still an issue when building : through AUR/exa-git. cc
Are there any updates on this issue, please?
Should be fixed.


To reproduce: set to rebuild system with two users that don't have uid specified rebuild system by specifying uid of the first user to match the generated uid of the second user They will now share the uid. Expected behavior: error should be raised cc
this also happens if you force the uid for 1 user, and dont set the uid at all on another, i need to force the uid on every user to avoid collisions
your issue should be fixed in , I'm still verifying if my problem is covered :)
There might be some other edge cases, but now this issue yields:


RStudio () fails to build from nixpkgs master with a 404 on downloading sources. Steps to reproduce the behavior: <!-- 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. Maintainer information:


<!-- 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: chirp (chirp-daily) <!-- 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: desired version: <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: None (!) - I can probably volunteer to keep this up to date? The last PR was submitted by though. Please tag this issue in your PR.


A URL like generates the following error log: Steps to reproduce the behavior: to download a file that has been uploaded Should download the file Are you seeing this problem on your non-beta versions of Discourse? It looks like maybe the X-Accel-Mapping isn't applying and then the request to download a file is getting fed back into Rails.
I've confirmed this is also an issue on Discourse 2.7.5 for NixOS.
This can be fixed with: However, I think this is probably a bad fix as is, because you might be able to trick discourse into serving arbitrary files in the /nix store. Two possible solutions: Discourse so it serves files with paths like /run/discourse instead a much more specific location regex in nginx to mitigate the issue I noted above Do you have any other ideas?
This works and should be safer:
My hunch is that it's both safer and cleaner to patch Discourse. If I follow the code correctly, I believe this is what would need to be changed to just return : There is already a match in place in the nginx config, so nothing more should be necessary.
That's the same place I followed the code to, so that is probably correct. I'll look into patching it.


When trying to build the swift package, it inevitably fails at the same point in two of my machines. In particular, it seems to fail at the following point (): Steps to reproduce the behavior: the following a long time for it to ultimately fail with the above message. I expect the swift package to successfully build. I have not tried to build it using any other method than the way outlined in <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Maintainer information:
It looks like swift is using a bundled llvm source tree, so we will have to apply the patch from
Out of curiosity do you know if there is a version of nixpkgs that contains a Swift package I could possibly build? Or is it somehow dependant on how my system is configured?
Certainly, that patch was only needed since bumping our userspace linux headers from 5.12 to 5.14, so I would expect any commit before that would work. According to Hydra, () was the most recent success.


To make sure that we are on the same page: Kernel: (run ) Linux lapole 3.18.25 -NixOS SMP Thu Jan 1 00:00:01 UTC 1970 x8664 GNU/Linux System: (NixOS: , Ubuntu/Fedora: , ...) 15.09.952. (Dingo) Nix version: (run ) nix-env (Nix) 1.10 Nixpkgs version: (run ) 16.03pre75806. I installed zsh-5.2 from nixpkgs channel to get away from a 5.0.8 bug. After I changed my login-shell to 5.2, ssh logins were no longer functional. Ie. PATH wasn't fully initialized. Reverting to 5.0.8 fixed the problem. I'm not sure why there's a difference between regular login shells and ssh though. Running yields: For 5.0.8 I get the expected /nix/store/... path instead of the strange $out path. The line with $out seems wrong.. Checking the commit log I find Dropping into nix-shell for zsh-5.2, setting and manually running I get: So it seems to me that variables in is not expanded leading to zprofile not being run. It could be something else of course (not everything seems to add up without more investigating), but the $out thing seems wrong either way.
cc
This is fixed by the merge of . Cherry-picked to .


<!-- 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: broot <!-- 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: 1.6.2 desired version: 1.6.6 <!-- 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.


My hydra instance started to report hash mismatches in rust packages (agate, ion, nushell, ox, ripgrep) (I'm cross-compiling to aarch64-multiplatform). It appears that the commit introduced this. See also the associated PR: Steps to reproduce the behavior: nixpkgs @ (just building the attribute would be enough) all deps... mismatch for cargo dependencies. No hash mismatch. I don't understand why the linked change would cause this. Maybe you know why this happens? Please run and paste the result. Maintainer information:
Huh, this is really interesting, I'm going to revert that change for now.
Reverting has fixed this. Hopefully the right solution can be found :).
Would you have time to test a re-do of the original PR? I think I know how to get it to work correctly.


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


Building tree-sitter grammars on MacOS results in a fatal error with the post-installation fixup stage due to differences in how is invoked on MacOS. The error reported is: Steps to reproduce the behavior: or with any other tree-sitter grammar. the fatal error in the post-installation fixup phase where it reports that no files are specified for . The grammar should build and execute the fixup phase without errors. This error does not occur on non-MacOS platforms. I reproduced the error on MacOS 12.0.1. I suspect this error was introduced with this commit but I'm not 100% sure.
Some discussion:
I can also replicate this with on macOS 12.0.1.


When is installed with , works fine. When is installed with , then prints an error message. When installing with , I get this log: So, it might be that git-with-svn-2.6.3 is fine but not . System: NixOS: = () Nix: = Nixpkgs version: () /cc
I think you have nixpkgs and nixos channel. One might be coming from root. So on one channel it works, on the other it doesn't.
This is a bug in the Perl bindings generated as a part of our Subversion build. The library depends on , but it has no RPATH set that allows it to find library. Curiously enough, is the only dependency with that problem: other library like are found properly using a full path into the Nix store. Cc: and
and it was working fine in :
As I said, this as nothing to do with Git. It's that provides broken Perl bindings.
Ran into same problem. git bisect log of checking ldd /nix/store/-subversion-1.9.3/lib/perl5/siteperl//x8664-linux-thread- follows. there's some big binutils related changes in the middle yet.


The Haskell package build fails due to missing C library. I assume it just needs a dependency on . The describes how to add non-Haskell dependencies to a Stack build, but what if I'm not using Stack? The build fails, outputting:


MySQL python binding is broken in 16.03 channel. Is seems to be OK in master. Apparently, is the commit in master that fixed that issue. If it is OK, I’d like to cherrry pick that commit into the branch (this will imply a massive re-downloads from the cache for the users). System: Nix version: Nixpkgs version: cc
any objections for a full rebuild of 16.03? (Maybe there's a workaround for this bug)
The error in seems related to this.
Cherry-picked to 16.03