I use enabled. I also have a web server service that specifies: Because my web server is a bit long to start, the timeout and its systemd unit fails. To Reproduce Use the following example module: Expected behavior The acme systemd units created by  should wait that nginx is started before starting. Metadata Maintainer information:
Should adding to what is already to  fix the issue?
Making a note that has the same code and presumably the same issue so any fix on should likely be ported to .
Thank you for the issue and reproducer. I'll have a closer look at this today
what exactly do you mean by "timeout" here by the way. could you provide some journal logs of this failure? I can try reproduce when I'm home, but maybe the logs are enough to understand what is going wrong
I mean "Timeout during connect (likely firewall problem)" in the logs below. Note that the hostname, email and domain have been redacted. Also notice the long time between and . nginx was not started when the Let's Encrypt tried to retrieve the challenge:
I'm scared that won't work. The lack of here is very deliberate pulls in (Through and ) to create fake certs, as nginx crashes hard when certificate paths aren't present. We want to start up before the acme challenge is initiated, as nginx is responsible for serving the director to complete it. If starts before nginx, it will always fail. It's all a bit mind-boggling and the dependencies are a bit complicated. I wish it was a bit more simpler too. However; isn't what we want here instead? We want to guarentee that is running before the certificate request is fired off. So adding a to might work? I'll see if that fixes it..
Absolutely, that is what I meant but I wrote it wrongly.
Should we go for the solution proposed?
Yep. I have a PR in the works on my machine. I'll try to get it out this week


When trying to use rocprofv2: This might have something to do with some predefined paths in Steps to reproduce the behavior: an executable with hipcc it with rocprofv2 <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.
I need to do some work with . need to make a patch that strips. I need to fix itself. I wonder if it's because I'm stripping out the test directories? Also yes, it looks like you're right. You can fix that by prepending too, so I'm not entirely sure it'll work. Try setting `. You may just be able to run it from that as well.
I don't think that removing hsa-amd-aqlprofile-bin is a good idea, because without it, it loses performance counters support. I think there should at least be a rocprof derivation with aqlprofile.
My bad, I forgot to add that the patch is optional.
Right. Could you tell me your test environment and the source of the hip executable (or just some stub) so I can replicate this? I've never actually used rocprofiler.
You can try this, it just prints 10 numbers, it can be compiled with hipcc without any flag. I am using a radeon rx6600m(gfx1032).
see


Steps to reproduce the behavior: odin If you run the resulting binary through you'll see this strange backtrace: I think it has to do with the version of the C++ standard library that is getting linked. Adding and to the and updating the file to explicitly link allows it to run without segfaulting. (But thats just a workaround I'm using). EDIT: During more testing with the built binary, it also doesn't use the correct linker, which can cause problems if you are linking with Objective-C code/frameworks (not sure if this is a problem with how Odin is packaged with nix, or if its a problem that the Odin devs need to solve). Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: Note: Was fixed by
macOS Odin support is kinda scuffed anyway with any deviation from what's expected. do you have the code for your workaround somewhere? then i can see if i can patch it in
I'm using for my project. It doesn't have any switching based on OS, and my override probably isn't necessary either. Honestly, the is probably the only thing needed to stop the seg faulting.
updating to llvm17 is not a bad idea either


When using an option with , the type description references the nested type's name instead of its description. This can lead to type descriptions like "function that evaluates to a(n) functionTo". Nix expression to reproduce: Reproduction in NixOS: The Nix expr should print something like "function that evaluates to a(n) function that evaluates to a(n) string". The command should print a type description like "function that evaluates to a(n) list of packages".


Project description A VSCode extension that integrates Vue features with TypeScript features Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Project description Convert bibtex file to yaml which typst needed. <!-- Describe the project a little: --Metadata homepage URL: source URL: license: mit, apache platforms: unix, linux, darwin, ...


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


Project description Upgrade 389-ds-base Apparenty its new 1.4.4.4 release is a bit different. Metadata homepage URL: source URL:
I marked this as stale due to inactivity. →


I'm trying to build octave with QT5 and with GUI (of course, when I try to build it with GUI, right?). Unfortunately, after the build: Apply this patch: and then system: host os: multi-user?: sandbox: version: channels(m): nixpkgs:
I just noticed that I do not even get the GUI feature when building octave from nixpkgs (neither nor has a GUI).
Pinging: touched the package recently, is the maintainer of the package.
I’ll try to have a look when I have some time. I’ll let you know what I can achieve.
Here is what the configure script says:
yes, I got that and I fixed it. See for my attempt to build with Qt5 (which succeeds, but starting octave with gui fails - see PR).


libxls, one of the optional dependencies for sc-im has 6 open CVEs for arbitrary code execution, which were reported on github 5 months ago and the issue hasn't even been responded to. I think this dependency should be made optional and probably should not be included by default. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Project description A modification of the Mesa Vulkan overlay. Including GUI improvements, temperature reporting, and logging capabilities. Metadata homepage URL: source URL: license: gpl3 platforms: linux
I tried myself at this and have a working package now for NUR based on But I haven't yet figured out how to create a 32 and 64-bit version. Depending on the game both are necessary. To just get a 32bit version I currently just use: instead of just
It might make sense to just build the 32bit and 64bit packages separately and then merge them together in a wrapper.
okay I did something similar, though not with a wrapper which is probably a little hackish I am not sure: but this allows me now to use mangohud with 64 and 32 bit applications
That seems like a reasonable solution, although it is a little bit hackish. I'm running into a similar issue with , and it's not really clear what the best approach is. recommended keeping the two builds separate for vkBasalt. However, to ensure we can install both builds we would have to do extra patching, and use separate names for the 32bit and 64bit build. Users might also expect to have both builds in one package like on other distros. I'm leaning towards something like this or like what I've done in my .
was just released but that changed quite a few things around. instead of using two different binaries it now uses  to decide where the 32/64bit libaries are, but it seems to me that this always expands to 'lib' on NixOS This is what I have so far. Having to ignore collisions is also not really that cool. Well having a running 0.4.1 version would be nice enough, just thought I write about this somewhere
The commit in question:
I marked this as stale due to inactivity. →
Still important to me.


blackbox-2.0.0 fails to build with test failures. Steps to reproduce the behavior: -env -i blackbox blackbox builds Please run and paste the result.
Don't really know why this would fail on darwin
fails on aarch64-linux but for a different reason


Project description Whisper is a general-purpose speech recognition model. It is trained on a large dataset of diverse audio and is also a multi-task model that can perform multilingual speech recognition as well as speech translation and language identification. Metadata homepage URL: source URL: license: mit platforms: all
PTAL.


For some reason, rasdaemon doesn't work. dmesg: systemctl: Steps to reproduce the behavior: rasdaemon should work. Unfortunately, ras-mc-ctl doesn't check if the daemon is working so it took me some time to discover that the daemon actually doesn't work. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
perhaps some build-time hardening is messing with it?
Looks like the latest tagged version is broken on AMD because it doesn't include Now I'm running from the latest commit and it works fine
oh, thanks for finding a solution! i'll open a PR with that patch in a few hours unless you beat me to it :)
adds that patch


is meant to show the current timezone. It doesn't. (I have some reason to believe that this is connected to Steam game failures, but still working on that. In any case...) Set time.timeZone to anything other than UTC. Rebuild your system. Run The output will be in UTC, with no timezone shown: lists only UTC. System: 17.03pre92039. (Gorilla) Nix version: nix-env (Nix) 1.11.4 Nixpkgs version: 17.03pre92039.
I think this is because of this line: We can patch this to not check prefix, but still wouldn't work. For discoverability of timezones we can add to and look for them in but I'm not sure this is a good idea.
See ,


Describe the bug To Reproduce Steps to reproduce the behavior: Expected behavior no fail Additional context it seem to be fixed upstream, but no new release it made yet Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:


When used through the command line, complains about imports and fails. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I've opened but haven't had the time to test it quite yet. If you get around to it before me feel free to merge it
I suggest another fix in


Describe the bug I cannot install anything that depends on splinter (such as searx), as it doesn't seem cached and fails to build To Reproduce Steps to reproduce the behavior: Additional context this was on nixos-unstable ()


Contributors working on improving the nixpkgs manual would be redirected to the . This section is not up-to-date with all the syntax features supported by , forcing contributors to look for use examples over the whole manual. The same markdown syntax is used to write and generate the NixOS manual. However, this manual does not make any mention of the supported syntax. This makes it hard to contribute to the NixOS manual with relative isolation from the nixpkgs manual. Update in Nixpkgs manual to include reference material and examples on all the syntax features supported by . Link in Nixos manual for completion. [x] remove references to in the . : [x] remove references to in the . [x] add a redirecting to the syntax section in . [x] add reference to lack of support for [x] add reference to support [x] add reference to support [x] add reference to support [x] add reference to support [x] add reference to support [x] add reference to support [x] add reference to support [x] add reference to support () () )


grub fails with nixos-rebuild switch -I nixpkgs=/home/lethal/nixpkgs
The issue title here is highly uninformative, which is why I didn't find this when checking for duplicates. :P


I'm reporting this for a friend of mine who wanted to install NixOS and ran into this issue. I hope that's okay. The problem is: fails if you have in your host's kernel config (which, I think, is reasonable if you're compiling it yourself and don't need swap). I took a cursory look into and saw that it reads from . This fails, apparently, because the file doesn't exist on systems without swap support. Can this be easily fixed by assuming there are no swap devices if the file cannot be found?
I'd say already assume this, but don't handle it gracefully.


Describe the bug On current nixos-unstable Scipy fails to build with a segmentation fault during testing: To Reproduce Steps to reproduce the behavior: the following as Expected behavior Should not segfault during test. Additional context SciPY seems to build just fine on current 20.03 release. Notify maintainers cc , Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(ente): nixpkgs:
Also fails with
Particular stacktrace is:
I believe the fix is contained in: and upstream tracking issue is: and Debian issue:
Opened to bump openblas to a version with that fix
fixes this for me - can you confirm?
builds for me
Works, thanks!
This still affects . Is there a simple fix we can backports (either in nixpkgs, or here locally)?
Backport openblas updates:
Thanks, I’ll try that. Would such a backport be eligible to go to ?
I don't really do backports, but since it fixes something known to be broken I assume it would be fine.
Pull request should target not .


ArmCord's wrapper seems unable to launch under Wayland, always chooses to launch under Steps to reproduce the behavior: sure and are properly set: Armcord: . ... 's on XWayland (as shown by ). I expect it to launch with Wayland instead of XWayland. Custom wrapper: Test case: Log output: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
probably need makeShellWrapper instead of makeBinaryWrapper in the package
Thanks for jumping on a PR will review this evening.


Project description Fragments is a modern, responsive and graphical Gnome bittorrent client Metadata homepage URL: source URL: license: gpl3 platforms: linux The new version of Fragments depends on libutp which hopefully gets merged soon. I've opened a pull request for it . for Fragments.
We have transmission and torrential. Maybe that's something for you.
That's true but Fragments is a really neat, easy and modern looking torrent client. It has an adaptive interface which would also work quite well on mobile devices, for example NixOS mobile :+1:


I'm trying to use GZDoom, but the Vulkan backend isn't working. No errors, but it will silently fall back to OpenGL. Apparently this is the case if GZDoom can't find the correct Vulkan drivers. I have a Radeon RX 5700 XT, so my GPU definitely supports Vulkan. Steps to reproduce the behavior: basic without any mods <kbdesc</kbdthen <kbd~</kbdAt the end of its loading it should say what renderer it is using This is a screenshot of it running with Vulkan from someone else's system: ! This is a screenshot of what it looks like when it's using OpenGL: ! Note the lines. GZDoom uses Vulkan Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


The pan-0.139 package builds without gpg2, and as a result it produces a segmentation fault: The steps to reproduce happen to be the example from the "Managing Build Environments" section of the Nix guide:
I can reproduce, investigating. Update is available (139 -144) so exploring that as well.
Hi, thanks!


Building this package twice does not produce the bit-by-bit identical result each time, making it harder to detect CI breaches. You can read more about this at https://reproducible- . nix-build '<nixpkgs' -A ... --check --keep-failed You can use to analyze the differences in the output of the two builds. To view the build log of the build that produced the artifact in the binary cache: nix-store --read-log $(nix-instantiate '<nixpkgs' -A ...) Seems to be a file ordering issue while generating : vs
Looks like this list is generated with the standard Ruby function, which in 2.x leaves the sorting up to the filesystem, but from 3.x onwards itself. So perhaps we should just update to Ruby 3.x. In general 2.7 is in mode, so it will only receive security updates and we should probably plan to move things to 3.x


The version of pillow rmfuse uses is vulnerable to CVE-2022-.
Since rmfuse is packaged using poetry2nix you are basically the only one willing to update it or its dependencies. That's problematic given that you don't do so even two weeks after being notified of a vulnerability.
I don't think interacting in this way is very constructive. There are different points of view regarding packaging Python packages, that's it. That an issue like this does not get picked up is not strange, people are typically busy. If you like to I suppose you could add the CVE to the expression. Whether the CVE can be considered a security issue in case of rmfuse should be considered as well.
Why not? I'm just articulating a problem with the way rmfuse is packaged right now that is obviously an actual problem. It's not technical though, just organizational.


vkBasalt is a Vulkan post processing layer to enhance the visual graphics of games. Metadata homepage URL: source URL: license: zlib platforms: linux
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .


default: cc Until then, just edit manually.
Remember you can do this too: = [ "/ip4/0.0.0.0/tcp/4001" "/ip6/::/tcp/4001" ]; It seems reasonable to have this default, however, since the nixos module has no way of getting the daemon to reset options when the user removes an explicit option from Incidentally, some config needs special handling, since it can't be set without re-initializing the leveldb, etc. I don't like the idea of having to duplicate every default setting into a , but I guess there's no other way until the ipfs devs make the daemon's config less stateful. I would prefer they move this type of runtime config into command-line args whose absence indicates that defaults should be used. Perhaps we should file that upstream.


The script should report all sources used to build a package. It currently lacks support for patches? If we run find-tarballs on nethack, we should find the patch defined in nethack named we should get the url to download in the output, along with its name, hash and type.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I found why patches are skipped, they have "postFetch" attribute that has to be run to obtain the same file expected by nix. By applying this diff, patches are included in the result, but they won't have the expected checksum before applying postFetch on it. I don't know how to apply postFetch on the result right now.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


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


is built without X11 support on darwin because the Meson build file disables it. The GTK build system was changed to Meson by , and it removed the configure flags that enabled X11 on darwin: But the file of GTK3 disables X11 support on darwin, and : should provide X11 support on darwin. I was trying to fix on darwin and I found that is marked as broken () because of a missing GKT/X11 header. It seems that it is the same problem that motivated to change Vim to use "gtk2" (same missing header ). Maintainer information:
In that case I'd probably take the discussion upstream.
It was disabled in 3.24.9 by commit , without much explanation. But that commit never landed into master and GTK 4.x does build with X11 support as I understand ( and ).


Describe the bug peek fails to build on macOS To Reproduce Clone then Notify maintainers Log
I marked this as stale due to inactivity. →
sadly its not supported though getting keybinder3 to compile would be good
I marked this as stale due to inactivity. →


Describe the bug seems to be unused in NixOS. Instead it seems to be a duplicate of . When greping for the option, only references of the later are found. Metadata Maintainer information:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


Neovide fails to install via Steps to reproduce the behavior: up a terminal (currently I'm on aarch64-darwin, but I think this should be reproducible on different platforms) (or use home-manager/nix-darwin/nixOS) for it to give the mentioned error Neovide should install and run as expected <img width="1398" alt="image" src="https://user-"(text form) Might be a result of this: Please run and paste the result. Maintainer information:
Can you try this?


The meson build doesn't compile the schemas, opting to do it instead in a package shell script. Unfortunately it seems that compiling the schemas aren't enough to make all the extensions work. In particular at least and still won't work (seems to fix though). With the schemas installed Tweaks simply complains that the extension is incorrectly installed. complains about lacking any typelib file for . I'm not sure how well these extensions worked before 3.28, but a report on irc indicated that at least worked before. cc Run Tweaks on nixos-unstable, try to enable eg. the extension under or . Running a schema fix on top of system: host os: multi-user?: sandbox: version: channels(hed): channels(root): nixpkgs:
The extension works for me when I manually change the directory structure to: As for the , I removed from dependencies so that might explain this failure. The extension should probably be fixed like .
You're able to switch switch themes in in Tweaks? Might be something wrong on my end. I'll submit a PR fixing the schemas at least.
Testing out a fix for .
Hmm, I can enable it but the theme switching does not work. I seems to require the extension schemas in when running Tweaks. Maybe it got picked up from global for bash users, but the option was always disabled for me with fish.
We might want to add as a dependency to Tweaks so that it could work for non-bash users. Then we will need to fix the schemas: the schemas in and find a hack similar to to add the schemas path to the extension. like the following to put the schemas where extensions can find them and add symlink for Tweaks. same thing as the second point but accomplished by patching files.
Your suggested fix worked for at least :) I went with basically adding the code from to to fix the schema problem. Generating the directory structure you quoted above seems the most sane and keeping with upstream. Tested things out in a vm with bash, and didn't seem to work there either. So not sure if the problem is non bash. Anyway, adding to fixes , so I think that's appropriate. I should've got everything now, will submit a PR :)
I think it only works in bash and globally installed packages or something.


I would not rely on it since I consider it an ugly impurity. I would prefer the first solution since it will be the cleanest and could be possibly automated in the future, but number two is fine too.


flameshot has two backends, one that works in KDE, and one that works in wlroots-based compositors, but the flag USEWAYLANDGRIM must be set in order to enable it. Steps to reproduce the behavior: to use flameshot in wlroots-based compositor like sway It works [nix-shell:~]$ env XDGCURRENTDESKTOP=sway XDGSESSIONDESKTOP=sway QTQPAPLATFORM=wayland flameshot gui flameshot: error: Unable to capture screen flameshot: error: Unable to capture screen Wayland does not support QWindow::requestActivate() flameshot: info: Screenshot aborted. Add any other context about the problem here. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The flag upstream:
It turns out that this flag is not yet available in a release. To use it, I created the following package override: and now flameshot works! For home-manager I also the following:
Not sure I'd call this a bug if there's no release with this code, though it seems like it will be some time before the next release:
I can confirm that the overlay above works for me. There's a small caveat: should be available in the PATH, otherwise the setup will be a little more janky.
Whether or not there's a release, it's still a bug. There were more attempts to fix this 2-3 years back, but as you can read in that linked issue, the authors are currently not working on updates. Since there's no official release, it might not make sense to issue an interim package update, but as long as I have my working flameshot, I'm happy. I just wanted to share this with others who run into the same problem
I hadn't noticed that... I've just updated buildInputs (to add grim) and removed grim from my default home-manager environment... I think that should take care of it, but I'll test to be sure.
After using for awhile, I can confirm. You need to add grim into your environment in order for this to work consistently.
I can't seem to get that to work on GNOME see
Yes, grim is for wlroots-based compositors, not mutter.
Unrelated to this issue then?


-Krey, make a new issue?
Sure, but I don't know if upstream even supports mutter; doesn't seem like it based on , , etc.
For context it's currently broken, but it worked with the fix in until recently, so thought it was relevant to this.


crashes as is fails to find the path Steps to reproduce the behavior: shows some info 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:


Describe the bug doesn't work, either on or . It works on and I have a bisect running at the moment (on some slow hardware, so the results might take some time). It fails with this log: To Reproduce Metadata Maintainer information:
The first bad commit could be any of: jfsutils: fix build with glibc=2.28 ppp: fix build with glibc=2.28 oathToolkit: fix build with glibc=2.28 postfix: fix build w/glibc 2.30 libffi: only run tests on musl targets stdenv: rebuild aarch64 bootstrap files with gcc8 expect: remove hack for aarch64 build expect: fix aarch64 build seasocks: fix build w/glibc-2.30 bzip2: fix aarch64 build xnbd: fix build w/glibc-2.30 glibc: remove outdated patches rr: 5.2.0 -5.3.0, fix build w/glibc-2.30 diod: fix build w/glibc-2.30 libunistring: disable tests distrho: fix build w/glibc-2.30 glibc: depend on libidn2 (and libunistring, transitively) stdenv bootstrap: disable dejagnu tests gcal: fix build w/glibc-2.30 sharutils: fix build with glibc=2.28 drbd: fix build w/glibc-2.30 gnum4: fix build with glibc=2.28 xen48: fix build w/glibc-2.30 gnulib: - mono: fix build w/glibc-2.30 glibc: 2.27 -2.30 foundationdb61: fix build w/glibc-2.30 spaceFM: fix build w/glibc-2.30 cpython: fetch darwin- to nixpkgs xen48-{light,


slim}: fix build bootstrap-files: bump WIP Merge branch 'staging' into glibc230 Ignoring 'fix build with glibc' commits libffi: only run tests on musl targets stdenv: rebuild aarch64 bootstrap files with gcc8 expect: remove hack for aarch64 build expect: fix aarch64 build bzip2: fix aarch64 build glibc: remove outdated patches libunistring: disable tests glibc: depend on libidn2 (and libunistring, transitively) stdenv bootstrap: disable dejagnu tests gnulib: - glibc: 2.27 -2.30 cpython: fetch darwin- to nixpkgs xen48-{light,slim}: fix build bootstrap-files: bump WIP Merge branch 'staging' into glibc230
stdenv bootstrapping of 32-bit ARMs is (hopefully) being fixed right now:
Thanks for the hard work


I don't use at all, but I'm getting this error when I'm trying to rebuild my flakes (same happens when I run ) and also I don't really use it or install it Steps to reproduce the behavior: or Expect or to work fine I ran before running <!-- 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.
By grepping through nixpkgs, depends on by default. (see ). However, abook is only lists linux as supported (Im not sure if this this is just nixpkgs or abook in general) Up until , lbdb has not depended on abook by default. Perhaps a mistake was made while refactoring. In the meantime, you can just override the package.


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


The Linux stdenv sets But that flag is specific to GNU strip, and LLVM's strip will fail if passed it. Conveniently, we silence all errors from stripping, so this has gone unnoticed until now: I noticed this while trying to fix . One of the reasons it doesn't work is that it has in , and strip should be removing that reference but isn't. What I'm not sure about here is the best way to fix this. There's nothing platform-specific about this option, so it shouldn't live in the Linux stdenv. (Other platforms like NetBSD use GNU binutils by default.) Ideally it would be a conditional in the strip setup hook, but we don't really have a bash equivalent to . So where (in Nix) should we check this and set the variable? cc
With what we have at the moment, I can only think of hacky workarounds like checking if ends in . However such an approach (and even checking ) is actually incorrect: and don't have to be matched, e. g. with as linker and GNU bintools is quite common actually. Looking at prior art in nixpkgs, I'm quite convinced that the cleanest solution for now would be to bite the bullet and extend to also wrap . In fact, we already seem to have a strip wrapper for darwin.
Hmm, I don't like the idea of globally adding a flag only to remove it again in a wrapper. Another idea I had was to do this in the definition of make- — the hardening flags are precedent for doing manipulation of environment variables for setup hooks in there. We could add an isGNU attribute to the possible values of , and use that? I don't much like this idea either, but I like it better than adding the flag globally and then wrapping to remove it. What do you think?
Since this flag is unconditionally in general, I think we can just remove it from the linux hook and instead add it in the binutils-wrapper. This should also solve the issue of this being binutils-specific and not linux-specific AIUI.
Oh, you mean wrap GNU binutils' strip to add this flag? That sounds fine to me.
If I understand correctly this is now done:


Describe the bug There are reasons to want a system, that has no user that can log in by SSH or with their password, for example in a declarative container To Reproduce Steps to reproduce the behavior: up a minimal declarative container asserts that I will be locked out from the system and refuses to build the configuration with Expected behavior nix generates me a container that I can log in with , or maybe I don't want to log into it at all (because it's a disposable VM or something of the like). I think there should be a check whether the generated system is a container and an additional "I know what I'm doing" override for other cases. I'll create a PR once we agreed on what's best. Maintainer information: Code causing the problem: mentioning since you the check.
Is it an option to set a randomly-generated (the hash itself would be generated, not obtained by honestly hashing a password)? Recovering the password from such a hash is probably harder than a lot of other attack vectors. But an override «doLockOutEveryone» sounds fine.
Setting a password would certainly be a possibility, but somewhat (for lack of a better word) really lame. Having slept a night over it, I propose , that disables all the assertions at the bottom. I can see scenarios where two users with the same uid could be wanted. I want my unixoid to always give me enough rope to shoot myself in the leg.
What about not enabling ssh and disabling the getty? It should completely lock anyone out, unless I am missing something. Take a look at the profile.
In case of a nixos declaratively defined nixos container, you are not logged out because the root system(d) can generate a root shell without any authentication, which is why I consider this a bug. Having to "fool" the assertion to actually lock oneself out is another matter, I could live with that but I don't think it's nice behavior.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this.


Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
This is still an issue.
I marked this as stale due to inactivity. →
Fixed via


Package name: gnuradio Latest released version: 3.10.8.0 <!-- Search your package here: --- Current version on the unstable channel: 3.10.7.0 Current version on the stable/release channel:3.10.7.0 Notify maintainers Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Tnx. Update is proposed at


Project description From the project page: A tool to sign PDF files with Linux support. Why There appears to be a lack of applications that run on Linux and allow for attaching free-hand signatures to PDF files in a good way. (Non-)alternatives include: Xournal and Xournal++: Allows free-hand annotations but not saving those for later use. Allows inserting images and .pdf files but will rasterize them rather than retain the vector graphics, resulting in lower quality. LibreOffice Draw: Allows inserting images and .pdf files but will rasterize them rather than retain the vector graphics, resulting in lower quality. Okular: Allows free-hand annotations but not saving those for later use. Allows inserting custom saved stamps, but these will not be visible in other PDF readers. Evince: Allows certain kinds of annotations, but nothing that can look like a free-hand signature. pdftk, Ghostscript, and other command-line tools: Allows superimposing .pdf files, but not interactively selecting where. Metadata homepage URL: source URL: license: MIT platforms: linux
Working on it


, (nixos-19.03) (nixos-19.03) (nixos-19.03) (nixos-19.03) (nixos-19.03) Scanned versions: nixos-19.03: . May contain false positives.
See also
Can be fixed by bumping the debian patchseries we pull from -6 to -11. Already fixed by the -6 debian patchseries. Fixed, indirectly, by the patches for CVE-2014-9638 and CVE-2014-9639 (above). This CVE was a fulldisclosure publication, so it didn't get triaged and fixed... But it is fixed. Conclusion: we can close this bug by pulling in the new debian patch series from 1.4.0-11 (up from 1.4.0-6). Sending PRs.


Describe the bug I need to list the out paths of cross compiled packages beforehand which causes an eval error. To Reproduce Steps to reproduce the behavior: Expected behavior List all out paths like `. Additional context I need this feature for nixpkgs-review when cross compiling. 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(user): nixpkgs: Maintainer information:
I think its because of the lack of splicing for perl-packages. Note however, that when that is fixed, other package sets will fail with the same issue. cc
Probably multiple issues. Have seen that problem with building xwayland for aarch64 too. Removing makeWrapper helps but probably breaks it :(. But the deps don't cross-build anyway so never got that far for now. Was thinking about opening an issue but got caught up trying to find the issue -- to no avail. Not currently at my machine, might post it later.
I marked this as stale due to inactivity. →
still important to me
Fix in


Steps to reproduce the behavior: for the pipewire package, e.g.: building it This can be fixed by either making sure that flag controls the Meson option in addtion to the , or by exposing a new option to control the directly. ping let me know which of the options above you guys prefer and I can open up a PR to fix as well. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Can we just remove that option instead?
Sorry do you mean set the to always be false or completely remove the as an option? Because I prefer the abilitiy to turn as many unnecessary dependencies as practically possible on my system (better stability and security).
Remove the option, yes, because we can't realistically maintain the exponential explosion of possible flag combinations.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I made two PRs: and Feel free to pick whichever PR looks better to you
arg removed in
How much maintenance burden does this actually cause? IMO the package options are one of Nixpkgs strengths (one of the things that attracted me, after I stopped working on Homebrew because package options started to be removed entirely), and they're critical for people working on systems where size matters.
To expand a bit, I don't think that package maintainers should generally be expected to support all combinations of options, but I also don't think they should block people who want to from doing so. Just having the flags there shouldn't cause any problems for package maintainers that don't want to maintain the flags, and it's fine IMO to respond to issues about flags not working by asking people to adopt the flag and send a patch.
No one's blocking people from overriding. It's just a bad idea to have some flags we haven't even looked at in months and pretend we support them by including them in the expression. Or in other words, keeping the flags is shipping broken code if people don't maintain them.
The enableSystemd flag had clearly been looked at recently, because there was a commit from me fixing it, and yet it was removed anyway.


Describe the bug throws an error when attempting to generate the musicbrainz disc id: Notify maintainers recently updated the package in listed as maintainer Maintainer information:


Describe the bug My server uses an encrypted filesystem /data that I have to mount manually after reboot. Gitolite is configured to use /data/gitolite. I have configured gitolite-init to only run once /data is mounted. Mounting of /data always fails, as gitolite uses to generate directories and thus the mountpoint is not empty. Manual cleanup is required every time. Expected behavior Gitolite should create its directories in gitolite-init.service. Additional context systemd-tmpfiles-setup.service runs before the system is fully initialized, so I cannot delay that service. 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(root): nixpkgs: Maintainer information:
I'll try to address this in the next few days.


<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: dt-schema <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 2022.1 desired version: 2022.12 <!-- 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.
A new version is out: Should I just update this and my PR to make use of this new version?


Project description Tile World 2 Metadata homepage URL: source URL: license: gpl2+ platforms: linux


Hi, i need to use open-zwave as a dependency for a build, but the version built in the Nix package is a specific fork for supporting home-assistant, which does not work for my package build due to linking errors. I will happily contribute a new package, but I'm not sure how to proceed, with regards to how it would fit in with this package, or if indeed the best way would be to modify this package to use the upstream repo. Pinging people who have maintained the package, apologies for the noise!
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
We should replace the package with an official version and make use the fork.


Describe the bug Tensorflow binary builds don't work on mac os. (neither do the source build, but that's a separate issue) To Reproduce $ nix-build '<nixpkgs' --show-trace -A python37Packages.tensorflow-bin_2 this derivation will be built: /nix/store/cc5p6r864smaf5mm8bqb9dbp6d7jkb3x-python3.7-tensorflow- building '/nix/store/cc5p6r864smaf5mm8bqb9dbp6d7jkb3x-python3.7-tensorflow-'... Sourcing python-recompile-bytecode- Sourcing python-remove-tests-dir-hook Sourcing python-catch-conflicts- Sourcing python-remove-bin-bytecode- Sourcing wheel setup hook Using wheelUnpackPhase Sourcing pip-install-hook Using pipInstallPhase Sourcing python-imports-check- Using pythonImportsCheckPhase Sourcing python-namespaces-hook unpacking sources Executing wheelUnpackPhase Finished executing wheelUnpackPhase patching sources configuring /private/tmp/nix-build-python3.7-tensorflow- /private/tmp/nix-build-python3.7-tensorflow- Unpacking to: unpacked/tensorflow-2.1.0...OK substitute(): ERROR: file '--replace' does not exist error: --- Error
--------------------------------------------------------------------------- nix-build builder for '/nix/store/cc5p6r864smaf5mm8bqb9dbp6d7jkb3x-python3.7-tensorflow-' failed with exit code 1 host os: multi-user?: sandbox: version: channels(noah): nixpkgs: yaml attribute: module:


Describe the bug tensorflow-bin_2 wants gast-3.2.0 due to but gast has been updated to 3.3.0 so tensorflow refuses to install: To Reproduce Notify maintainers Metadata Maintainer information:
There are also other dependencies that fail the version checks: scipy==1.4.1 and tensorflow-estimator<2.2.0,=2.1.0rc0.
This compiles i'll test it, any feedback appreciated
Got some issues
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Related .
It looks like fixes this.


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


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


It would be nice if we are able to have , in the same way we have , and the other completion siblings. I know it's easy to just and store in , but doing that we have to allow the user in question to write to that location (I don't really know the repercussions of any) and really defeats the purpose, somehow, of Nix Packages.
as the modules (at least for bash and zsh) are fairly advanced it shouldn't be too hard. I'll try to have a look at it tonight %)
Hi, I installed on Arch Linux , but whenever I go into any Gradle-based project it doesn't work – as it works in macOS when I install it using Brew. It just doesn't discover, nor auto-completes any of the (currently available) tasks. Maybe it's not getting sourced into the shell? I do have also installed, not sure if that's an impediment (or not):
I actually confirmed that the package is doing its job, however it can be possible that I screwed something up (e.g. something in my system config made it work). I don't think that I'll have sufficient time to look at this tonight, by I'll definetely keep this in mind and have a deeper look at this as soon as I have time to.
I rechecked with the following vm config (which is basically the same as the settings I posted in my commit message): It seems to work perfectly fine with , however the validation breaks with (didn't test this, mostly use as it's easier to type :sweat_smile:) It shouldn't be too hard to fix this, I'll ping you when it's done.
For me, even if I try to use alone, when I hit (auto-complete) on the shell (), it does auto-complete what I have in the directory, which is fine, but I guess at some point the script(s) should take over the "normal" shell auto-completion.
I'm fairly confused, are you sure that it's not caused by something else? I tested it with a VM from master and inside and work perfectly fine: What I suspect now is that it could be caused by your user profile. I'm not sure if actually pulls completion scripts from . Would you mind checking this with a VM or by adding to in your ?
Hi I'm using Arch Linux and the Bash shell.


I searched within my "home" directory for this file: and I couldn't find any. I did find a , but couldn't find on it. My Bash shell is the one that comes by default with Arch Linux. I did the same on a virtual machine with Ubuntu . Let me know if you want more info.
Ah good to know! I've been testing on NixOS, usually which defines the system's entire state. But I'm fairly certain that this is related to living in , please give me som etime to investigate, but this sounds like a bug in the bash packages themselves...
It might be a bug because right now that I'm on it, I should also have auto-completion for Git commands (due to the fact that I have ), and it doesn't work either. I even to , but still, nothing going on there: Thanks for the effort!
I see... Unfortunately I don't use the user profile for this so I might lack the required knowledge. I'd recommend to look for related tickets (or open a new one) as I'm fairly certain now that this is related to the integration of into .


The gitlab service does rotate its log files which has potential of filling up the partition. Steps to reproduce the behavior: something that causes a lot of logs to be written. the partition runs full. Rotation of the logs similar to <!-- 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:


Describe the bug Upstream intel-vaapi-driver removed the --enable-drm ./configure option. It is now turned on by default. Happened in commit To Reproduce Steps to reproduce the behavior: the package and read through compile log Additional context This is a warning, package builds just fine despite this. Metadata Please run and paste the result. Maintainer information: (I don't know if I am dealing with attribute or module. I think attribute, but just to cover all bases.)
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .


Proprietary HTML5 videos break the whole site Workaround is to disable . Steps to reproduce the behavior: Vivaldi package with the package in your Configuration (home-manager) YouTube YouTube should display and the video should play. !
I hit this issue myself yesterday as well. I had reported it to Vivaldi before I realized it was indeed an outdated chromium-ffmpeg dependency. See . I wrote a PR at to fix this. For a quick fix, here's the code I have in my overlay to work around this straight away:
I just saw it. Thanks a lot! I will close this issue now as you already created an issue for discussion.


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


Steps to reproduce the behavior: Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


When starting a VM I get the following error:
Thanks; this is indeed same issue. I am closing this one.


fails with the vdirsyncer version from nixos-unstable. it works if I install vdirsyncer with pip. Output of :
Which do you get via ? Is it the old 0.16 branch or the new 0.17 one (which was mostly rewritten in rust)? We have the latest git version of 0.17 in nixpkgs. Unfortunately, so it might be some time before this bug is fixed.
outputs this:
Same problem here. Was there any reason to go for an alpha release except for the issue referenced in ? If not, a downgrade to 0.16.7 should be fine, since the original bug is still open and probably won't be fixed for a while without anyone maintaining vdirsyncer.
There are , so I'd rather not downgrade. I'd be happy with a package for the 0.16 branch though.
That'd be great! I haven't looked into packaging yet, so it would take some time if I tried. Would you mind helping out?
I just opened a PR. It’s my first time contributing to , so I hope it’s up to snuff.


There is a hash mismatch for kstars in nixpkgs-unstable Steps to reproduce the behavior: Add any other context about the problem here. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Last updated by
As was spotted during the PR review , the ref is a branch not a tag.
The source of the problem is (also mentionned in a comment) a typo in the name of the latest version of kstars files (). There's now a 3.7.0 version out. So I'll suggest a new PR with this version, using the official source


, CVSSv3=9.8 (nixos-20.03) Scanned versions: nixos-20.03: . May contain false positives.
merged - closing


Steps to reproduce the behavior: ferium cc thanks! <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Project description A scanner informing the technologies and headers a website uses. Metadata homepage URL: source URL: license: GPL-2.0 platforms: Agnostic (Darwin, Linux, Windows) See also:
I was able to build it, check it here
Thanks!


Project description Metadata homepage URL: source URL: license: BSD-3-Clause license platforms: linux The version compatible with NixOS 23.11 is 1.3.3. Below is the code for this Python package, which might be useful: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
please test edit: i tried to add a quippy command to test this, but the new nix cli doesn't construct python environments like the old cli did, and the old cli can't trivially use github pull as input...


Element v1.11.0 updated to Electron 19, so we need this packaged in Nixpkgs: <!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 18.1.0 desired version: 19.0.7 <!-- 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.
When I run the script tries to download which does not exist. Do you know where to get the electron headers?
PR that brings electron19 but does not provide electron19 headers:
I believe that states that they migrated storage. So, I think the new url would be
Great find, thanks! Updated PR to include this change and electron_19 now provides the headers.
electrum_19 to master via - feel free to update your package


Installing causes large dependencies such as and to be pulled in at run-time Steps to reproduce the behavior: that some of the large dependencies such as are pulled in. I'd expect and to be build-time dependencies, and as such shouldn't be needed at run-time The additional dependencies are being pulled in due to , which itself should be a build dependency. FWIW, declares as a make* dependency Please run and paste the result.
not the maintainer for -qt ( is), but I took a quick look at it nevertheless and it seems that gets to in the invocation for even if it is moved to . Unfortunately I don't know enough about the Qt ecosystem to tell why this is the case.
I think that the issue lies in qttools itself, for some reason after , qttools depends on clang and llvm at runtime This doesn't seem to be the case on and
qttools provides a qt plugin so wrapQtAppsHook will add to ‘QTPLUGINPATH’ automaticallyUnfortunately, the packaging of qttools is not subdivided, all output is almost in one packagethis leads to the addition of unnecessary runtime dependencies. ( Actually even may not be needed is required by and , lupdate seems to be just a optional feature dependency on clangbut is not feasiblewe have to recompile to disable this feature Splitting into multiple packages should be a better solutionqdoc/lupdate are often used to generate documentation/translations, almost no packages runtime depends on them This pr should solve the problem of qalculate-qt but this may cause some packages fail to find lupdate. it‘s not an elegant solution
I think it's easier to add a flag to qttools, and only use that variant for building the docs.
should be , set can prevent qttools from being recognized as a runtime dependency the pull request to disable clang-based c++ parser by default
If that helps, maybe is no longer necessary?
For this issue, yes But not sure if there is a package need qttools (qt plugin ) as runtime dependency
I checked all packages that depends on qttools, and found that most if not all of them have a runtime reference on qttools due to it being in . So this problem is actually widespread, we can have the workaround in for now.


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


For example: If this is called with instead of , it will fail to produce a output. This causes an assertion of the form: Unfortunately, doesn't keep the build directory around, making the source of the problem difficult to debug.
This is more of an issue for Thanks for reporting though!
Whoops! Is there an easy way to move it?
Not that I know of, sorry.
Fixed, thanks!


migrated from python branch issue tracker
I'm closing this as it seems no longer relevant. From what I could find, python-virtinst is "CLI tools for building virtual machines using libvirt". But it is now merged with virtmanager: <-- contains one single file named MERGEDWITHVIRTMANAGER


Our can no longer link executables. For example: This issue is present in current versions of . Compiling and linking works fine with an older revision, say . It looks like this might be related to some change in binutils, maybe?
This is probably from
Yes, it is. came to the same conclusion.
This probably is GHC bug though. Things like gmp and libiconv get their paths hardcoded so this isn't a problem. I would expect the same treatment for elfutils. should provide a arg.
/cc
I guess now I know why there's a patch in branch.
I'll reopen the PR fixing the linking issues.
I opened while we wait on upstream fix.
Which one, from
Yes, although it doesn't help. See
Yes, it would have surprised me a bit if it helped against that symptom -- my patch fixes that DWARF-enabling is skipped completely.
I'm surprised this worked for you back then and now there are linking errors.


Steps to reproduce the behavior:  nixos-unstable Noticed when setting and rebuilding <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
You won't get a reply if you leave that empty.
I'm having the same issue I didn't notice when it happened, but I also have sambaFull
Same error whit the package .
This seems related to
That turned out not to be the issue. The actual error: In colour so that one can actually make sense of C++ error messages: ! One potential problem here: This is because of having: Switching to : Builds Removing entirely (which swiches to ): Fails on new related errors (see below) Removing and : Fails because Ceph requires lua = 5.3 and nixpkgs's default is still 5.2: CMake saysCould NOT find Lua (missing: LUAINCLUDEDIR) (Required is at least version "5.3")` Build failure with : <details</detailsI noticed Arch . But we can just use to fix the build.
PR for the


If I install , then I get version , which causes problems with Tiller image pulls. Alternatively, if I try to pull a specific version like this: Then I get this build failure:


TEXMF defines the order in which files are read in The idea is that TEXMFSYSVAR and TEXMFCONFIG files take precedence over files distributed with TEXMFDIST, so there is a way for the user to override configuration files. Our lists: This seems all fine, except that our derivation also makes TEXMFLOCAL point to TEXMFDIST as well, and this destroys override-ability. My suggestion is to use a separate and empty $out/share/texmf-local for TEXMFLOCAL.
Could you please provide an example of the override that doesn't work?
I dropped my customization here: It boils down to adding a custom package (minionpro availble for my ) and running: in postBuild.
I investigated your override. I see that you sneak the original , then add your font to it and regenerate the mappings which go to share/texmf-var. At the same time our texlive setup just reuses prebuilt maps provided by (for pdftex), individual font packages and others and those are installed into share/texmf which happens to be also pointed by TEXMFLOCAL. I also now discover that the line does nothing for us. Your change makes sense to me. Makes me wonder if we could do better. For example, not deleting should not hurt anything. I could not find any way to automatically scan for new entries for The Gentoo documentation mentions [1] concatenating it from /etc/texmf/updmap.d. [1]
First of all thank you for taking such a careful look at my code snippet. I really appreciate it! First, yes, I sneak out and later sneak back in. I do think that there are no adverse side-effects from not deleting in texlive.combine. I will submit a PR to remove it. This will minimize my postBuild override to just: That looks much cleaner :) As there is no real "hooks" functionality in our texlive package derivation, it seems to be a good idea to optimistically merge (by concatenation) separate snippets. I will file a separate issue to discuss this.
Thank you!


Project description Halloy is an open-source IRC client written in Rust, with the Iced GUI library. It aims to provide a simple and fast client for Mac, Windows, and Linux platforms. Metadata homepage URL: source URL: license: GPL-3.0 platforms: unix, linux, darwin


Project description An open source implementation of the Tailscale control server Metadata homepage URL: source URL: license: bsd platforms: linux


Describe the bug To Reproduce Steps to reproduce the behavior: ... ... ... Expected behavior A clear and concise description of what you expected to happen. Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Notify maintainers and edited it last Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
I really have no idea, contains it, even bumping gnunet-gtk to be the same release version still doesn't fix it.
Have you tried applying


Describe the bug hides clang arguments in a "response file" by default if is true, but ccache does not support this and responds with "no input files" instead. Additional context The following workaround can be used to disable response files in a result , fixing the issue: Notify maintainers Maintainer information:
I've run into this issue as well. Edit: my bad, that doesn't work; we need the env var to be set before the outer layer of stdenv wrapper machinery runs. By the time we're in the ccache wrapper it's too late. It's also not clear to me if this is a bug in or intended behavior (I was not able to find an issue for it upstream) but it's definitely reproducible:


I tried to build a package with debug symbols today and failed. NixOS wiki and nixpkgs repository comments say the following should work: Please run and paste the result.
It worked in Aug 2018: Bisected down to breakage at : Looks like it stems from the fact that does not expose anymore, only . /cc
Woah. master and both work for me with nix stable.
That's surprising. Here is my attempt at current master checkout: I tried removing and seeing the same failure. I wonder why it works for you. Might be a different stdenv?
Does it mean and are the same object?
i can reproduce
I can also reproduce with stable Nix (2.3.14):
Hmm, the issue is that / slaps the on after is defined, closing over the old . In Smalltalk paralance, this would be an issue of insufficiently "late binding".
Still reproducible on current master ()
I ran into this.
Bump, ran into this while updating the Nixpkgs pin on a project of mine.
There should be a test for this :)
Gonna spend next hour or two trying to fix this.
Things that are also missing:
So, this function is not executed on passed through stdenv. Not yet sure why.
Yeah, I've fixed it (thanks, for being there :heart:)
Post-mortem: always read threads. Solution was kinda already provided in , but I delved right in without knowing that)
atleast you now know more about stdenv :slightlysmilingface:
How is the PR looking? I've been waiting on this for a couple of weeks to debug an intermittent crash I'm having with xfce4-sesion :)


Steps to reproduce the behavior: Happens on intel darwin. Please run and paste the result.
The .so dependency should be fixed up:


Steps to reproduce the behavior: msbuild Trying to build msbuild on a mac fails. <!-- 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.


Describe the bug when a root-owned process dumps core (eg recent sshd, due to a known bug) and coredumps are enabled, systemd-coredump warns (but proceeds successfully). To Reproduce Steps to reproduce the behavior: systemd coredumps enabled a SIGABRT to any root-owned process (eg by running ) Expected behavior coredumps succeeds with proper privsep Screenshots Additional context Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Can you reproduce this with a simple c binary you interactively run as root user?
yes, as root does it. amended the original post addendum: if you want a minimal C example that causes it:
still happening regularly due to a bug in openssh (race conditions in process shutdown can cause seccomp filters to trigger)
I am also observing this problem, both sshd dumping core and the systemd-coredump error when it happens. I can also reproduce it with as root.
I can confirm I see the log messages: I looked at . It seems systemd-coredump wants to drop privileges to a user (but falls back to root if it can't find it). suggests we should create it (like we create one for ). I opened , which does that.


When I ran , it failed to build my configuration because dependencies couldn't be built. Relevant sections from and : Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(root): channels(user): nixpkgs:
a full log might be helpful
Sorry, forgot to attach the log. Here it is:
It seems needs to be cherry-picked there...
I've created a pull request for this:
Fixed by


(the .0 version has a bug that breaks ) <!-- 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: matrix-nio <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 0.18.0 desired version: 0.18.1 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.


RTS/game with programming on simplified C Metadata version: 1.3 homepage URL: source URL: license: GPLv3 platforms: GNU/Linux, Windows, IOS


Project description Python 3 bindings of the , library for managing BTRFS file systems. This binding is part of the project. Metadata homepage URL: source URL: license: lgpl2Only platforms: linux (I'm not sure if it works on BSD or Mac)
I marked this as stale due to inactivity. →
See


Project description Gorm is Golang ORM for SQL databases. Gen Tool is a single binary without dependencies can be used to generate structs from database. Metadata homepage URL: source URL: license: mit platforms: all? Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


When attempting to create a volume on a physical node pool parted is not found. Steps to reproduce the behavior: Create a physical disk node pool. Attempt to create a volume using that node pool. In this case I have created a node pool called and I am attempting to create a volume called Volume is created normally. If applicable, add screenshots to help explain your problem. I have tried to add parted manually using and overriding the package in the libvirtd module: but this did not fix the issue.
That won't work, it seems like we need to wrap to include in its . I'll take a look.
You most likely need to add it to in because libvirtd will probably call it.


I sometimes create a qemu VM in libvirt in "session mode", meaning that the libvirt daemon is running as my non-root user, and the system-wide libvirtd does not need to be running (). This VM has a network bridge, which libvirt apparently creates by calling , which in turn uses . The problem is that doesn't get fully populated until the system libvirtd gets started. Previously, in nixpkgs (from February), this wasn't noticeable because libvirtd.service was WantedBy libvirt-guests.service (which is WantedBy multi-), so libvirtd would always be started on boot to populate that directory. Now, with , this is no longer the case, and libvirtd.service does not get started (presumably, if libvirt-guests.service actually needed to start a VM, then libvirtd.service would be socket-activated, but for me this is not the case). As a result, doesn't get populated and my session-mode libvirt can't find . python: The VM's XML file defines a network bridge, which is why gets involved. the following output: The libvirt user session should be usable without first starting the system-wide libvirtd. If you start (and optionally stop) the system libvirtd.service before following the steps to reproduce, everything works fine, because the directory gets populated. Probably, should be put somewhere else, where session-mode daemons can use it without needing to have previously started system-mode libvirtd. (The same may be true of other stuff in too.) libvirt maintainers: Okay, but I'm using flakes and that channel looks old. See relevant commit hashes above.
Oof, happy to find this, it would have taken me a long time to figure out I needed to run first. Can't the sudo wrapper point to the file in the nix store?


It is possible to use Plasma’s native file dialogues in Firefox 64 to open or save a file. Currently this feature is not working in NixOS, and it seems to me some small changes would need to be made to derivation in order to enable it. I propose we include this option together with as a Firefox option in NixOS (see also: ). I followed the explanation on how to enable this feature as it was published on : Firefox (64 is current stable) from a terminal emulator But it produces the following error: system: host os: multi-user?: sandbox: version: channels(root): channels(hook): nixpkgs:
You'll probably have to do something like this to expose the dbus service:
Where? In:
It needs to go into a nixos module or your .


Directory renaming is now out of scope This directory is also being used as the way to get access to the host machines gpu drivers. I think it's another source of confusion for many users to have to add so that they can get a vulkan game / cuda workload / opencl workload to work. I think we should deprecate this prior to the 21.11 release, and fully move it to something like or something more representative of the desired affect. This was done in cc EDIT: roadmap (2.5 years later... lol): addOpenGLRunpath -addDriverRunpath Init addDriverRunpath: Deprecate : -autoAddDriverRunpath Init autoAddDriverRunpath: Deprecate cudaPackages.autoAdd{OpenGLRunpathHook,DriverRunpath}: NixOS Module changes: TODO
For the transition period ( NixOS 21.11), I think keeping the old would help alleviate a lot of the pain, would just like to get the ball rolling away from using explicitly
I agree. Also, on a related note, having to specify your graphics driver at the xserver level in the module system feels wrong to me. I'm still not exactly sure how it maps given names to driver packages either.
I propose two changes: move -- make a symlink to for backwards compatibility of existing derivations -- add a
potential future work as well: -- Until 21.11 EOL, have it add both and , to avoid system vs package invariance
I'm also kind of wondering whether is just another fallacy in naming, and we should really be exposing something like, would be even more appropriate, as other hardware-accelerated devices such as tpus, fpga's, and others would also likely need to import "libraries which are determined by the system, and need to be available at runtime".
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Should we, in addition, consider using a libc-versioned directory? Motivated by
Decided to rename this issue since renaming the underlying path was deemed too risky for potential breakages.
Could you provide some context as to why? My naive assumption was that we'd have a new path but: have both new and legacy path to rpath via the hook; new path preferred provide a legacy symlink pointing at the new path in NixOS which would be quite trivial.


TBH, I'm not sure how much value there is to migrating the filesystem path (unless we splay the paths further to increase granularity). I suspect what users see in practice is the nixos option path
For the NixOS module change, I came up with these terms: acceleration API = an API standard which intends to provide hardware-assisted compute acceleration such as OpenGL, Vulkan or CUDA driver = userspace library component which implements one or more hardware-based acceleration APIs The usage of the NixOS options API would then look a little like this: Individual drivers would also have a option which is a package selector for the specific package to use aswell as driver-specific settings. (More on the package selector data type when I have a more concrete implementation but it'd allow setting 64/32 bit using a single value.) Each acceleration API would have a option which is an attrset with driver names as keys and package selectors as values. These could then be overridden indivually. The intention behind this is to enable use-cases where e.g. different versions of the same driver are required for different APIs or a specific driver must be disabled for one API but enabled in all others. All enabling a driver would do would be to insert the driver's package into the options of all APIs that it implements. Additionally, accel APIs have a option if the API supports setting one and of course API-specific knobs. Here's an example of how a non-trivial driver config could look like: It's currently not possible to know which implements which driver and all drivers are thrown into the same directory but the NixOS API drafted above requires this information for fine-grained control, so we will have to define an interface here. I've been thinking of defining the output to contain all driver bits and subdivide it into driver subdirs like this vulkan/... cuda/... opengl/... Alternatively, I had thought of using multiple outputs; one for each driver. I kinda like that approach more as it generally strikes me as cleaner and has the potential to reduce closure size ( is ~200M) but am not sure about potential naming conflicts or other downsides of those. In light of this, I'd also like to propose to split the global lib dirs into accel API subdirs for clean separation. Though as said, the NixOS options are a lot more critical to UX and therefore the first steps.


Global path name and other changes are almost entirely tangential and could happen independantly but I'd appreciate if they came after the NixOS options changes such that we can let the knowledge we gained from the NixOS options influence their design. Anyhow, that's my current draft. Let me know what you think.
My naive assumption was that we'd have a new path but: That was my initial take as well, but there's community projects like nixGL and others who likely have hard coded the path. And there's a potential that we could never fully remove it without breaking someone
Forgive my ignorance, but wouldn't it be ok to make those kinda breaking changes by deprecating in one release and then removing one or two releases later? Surely nixos isn't promising to never change paths because someone might be using the old location? EDIT:I don't mean to imply we shouldn't consider non-breaking options where possible
nixGL only sets the LDLIBRARYPATH? Although in all probability we must break someone's workflow... Fun fact: cudaPackages don't ship the driver (except for for jetsons). All the relevant stuff comes with nvidia_x11 or with the datacenter driver. Interesting. Would we somehow have to filter the glvnd/opencl loader/vulkan loader configs that come with the drivers to enforce that the declarative configuration be implemented?
nixGL appears to be actively maintained. I don't think we need to worry about breaking it as they can simply adapt. Also, we could simply keep providing the old path in both NixOS and binaries with a preference for the new path and that should work out fine. Oh, okay. I'll leave it to you CUDA people to figure that out. I will only be lifting drivers to this interface on a best-effort basis and the rest will keep using their legacy interface with a minor implementation change. Though if you forsee possible issues you could have mapping your driver to this interface, let me know so that we can design the interface better from the start. That or simply write our own. Though I'll only be adding the option where it is feasible; currently, I only know that Vulkan has sane mechanisms for this. Some issues I still need to think about:How to handle drivers that only support 64 bit?


Will have to filter that somehow How to handle APIs that can only have a single exclusive driver? Only have a option on the API, rather than ? Have but only install the default driver?
I think NixGL doesn't care about , it probably just exports an ?
The original protest against renaming the path: I feel more strongly about the NixOS options being intuitive than the implementation consistent.
I think was more concerned with it being placed under rather than some other directory in because is very much NixOS-specific while the current is not.
I believe I got all of the packages. Once merged, I should be able to deprecate
This thread is over my head, but I would like to check it , , and need the same? All three have GPU or CUDA support options.
This is more about deprecating usage of the term , as it's a bit of a misnomer. I don't see usage of the legacy OpenGL helpers in those packages.
Talked to , we concluded that we can close this ticket and have a more "NixOS options" specific ticket to represent that work.
Going to do one last pass on documentation to ensure all references have been updated. I'll close this ticket after that sweep
I wonder if needs an update. I'm not offering a PR because I'm out of context. Arrived here from a warning in nixos-rebuild. And I'm still wondering how this is being triggered [still investigating].
Arrived here from a warning in nixos-rebuild. And I'm still wondering how this is being triggered [still investigating]. It should come from the toplevel scope now, so it should never need to default to pulling them out of cudaPackages. I can update the nix expression though.


Project description udev rules to make supported controllers available with user-grade permissions Metadata homepage URL: source URL: license: mit platforms: linux


Currently it's only possible to configure kanata by specifying specific parts one at a time. It's not possible to read a configuration from a file and use that instead of the specific parts. I use HomeManager to manage the kanata configuration file and because it's also used for Windows this is the most platform neutral way for me without duplicating parts of the configuration. As a workaround I did it like this for now: But clearly that is not ideal. What I would want is to just keep the 'readFile' and uncomment the 'defcfg' part from the configuration file ()
I created to address this issue. Could you help test it?
Thanks a lot for the fast solution! I tested it with my config and it works without any issues.


Project description A lightweight cross-platform build utility based on Lua Metadata homepage URL: source URL: license: asl20 platforms: unix


Package name: jextract (jextract-unstable) Current version on the unstable channel: 2023-11-27 Current version on the stable/release channel: n/a As of today the current release build is (see ) It would be nice for the nixpkgs version to be based on JDK 22 -- which contains the final non-preview release of Java Foreign Function & Memory API (aka "Panama") There are significant changes to that users will want before building/launching projects that use Panama. See: I am wiling to contribute but before we can do this we'll need to build with JDK 22 (see Issue )
It would be great if we could update to be based on JDK 22 :+1: , and we should also keep the current JDK 21 package as a new name (perhaps ?) at the same time, as some downstreams still depend on it and JDK 21 is a LTS version.
So should the first step be to rename the existing package? And leave as JDK 21-based (with a warning, maybe) and then do a separate PR to upgrade to JDK 21?
Update: There is a PR for JDK 22:
I can open a PR to update jextract after gets merged. Considering the significant API changes between JDK 21 and 22, and the fact that jextract itself produces very differnt code if you have to use JDK21 (see ) , is there really value in keeping a jextract version compatible with JDK21?
Awesome! I'm going to test on macOS/aarch64 this weekend, so that will help get it merged. wrote: as some downstreams still depend on it and JDK 21 is a LTS version. JDK 21 is LTS, but Panama (Foreign Functions & Memory API) is a "preview feature" which makes it really hard to build anything real with it (i.e. publish JARs for use by other projects. I even had problems with a Gradle multi-module build). I migrated my project to 22 a few weeks ago and am not looking back (which meant I had to stop using Nix as a source for temporarily.) But, I don't see any harm in renaming the existing to and starting a new one. And we certainly don't want to unnecessarily break anyone's dependencies.


And now that Panama/FF&M is final, I'm hoping it will be possible to use jextract 22 to build headers for JDK 23+. Newer versions of jextract might offer improvements, but headers generated for JDK 22 should work wth JDK 23+ (I don't know what guarantees the JDK makes for that, but this seems a reasonable conclusion given a stable API.)
Nice to hear that, and thanks for your work! IMO, I think it's worth. The point is that JDK 21 is a LTS version, some downstreams prefer to use a LTS version of JDK to develop their projects. For them, if we don't keep JDK 21's , this will be unavailable to them unless they give up on choosing LTS and do some extra effort - porting their project to a newer version of JDK.
I agree. But I also strongly encourage new projects to start with JDK 22 and existing projects to migrate as quickly as possible. Having to make sure "preview mode" is set in the compiler and at runtime can cause various problems with tools and the output of the latest is significantly improved. In general, it's much better to be using a non-LTS JDK with a non-preview feature than and LTS JDK with a preview feature. I migrated my project recently and wish I had migrated to JDK 22 much earlier.
PR has been merged. I gave it a quick test on macOS/aarch64 and it seems to be working. (I used it to build which uses JDK 22 and Panama via Gradle's Java toolchains)


Invoking is producing the following error message: is part of the package so it's just failing to locate it. I'm running on NixOS Unstable.
I believe this issue has been fixed and can be closed:


Travis has been giving build failures because of this: commit seems to be at fault here.. The reason I didn't just fix this this bug and push upstream is because there are two different ways to approach this and I'm not sure which the best course of action is. a) jfsrec removal was intentional, remove all references to jfsrec b) restore jfsrec Here is a listing of all current things pointing to jfsrec:
The jfsrec commit has already been reverted.
thanks for the info


nixos/modules/services/x11/display- has code to load ~/.Xdefaults, but not ~/.Xresources, even though ~/.Xdefaults is the deprecated version of ~/.Xresources


In its builder, there's a command saying "Need libgcc until the llvm compiler-rt library is complete". It's from in 2011, so I'm inclined to think it's out of date and that the dependency on gcc is spurious. Is that true?
For context from #llvm on oftc:
covers , covers , the only thing I'm not sure about is the C runtime files (e.g. ), none of those packages seem to come with them (but maybe clang does it another way)
Actually some of the files come from glibc, but these ones come with gcc: crtprec32.o crtendS.o crtbeginS.o crtfastmath.o crtprec64.o crtbeginT.o crtprec80.o crtbegin.o crtend.o
This story is quite old, is this still true?
Closing because no reaction.


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


There is a bug in the latest release of quickemu (present in nixpkgs), that sends invalid flags to qemu and thus doesn't work for MacOS (maybe others too). The fix I was planning to PR was to simply move the src to point to the most current revision. I wasn't 100% sure if that was something that I should do however, given it would set the precedent that we follow revisions for this package instead of the version tag, which may add maintenance burden. Just wanted opinions before I made a PR, would it be acceptable to bump the revision temporarily to avoid this issue? It's niche but its real and could affect users of this package. Steps to reproduce the behavior: Pops open a Qemu window with the appropriate screens. Fails with a strange "macos-ventura/macos- file not found", but it is related to the bugged release. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Don't know of any official policy on this. My opinion: If it's a single commit that fixes the issue, you can add a patch. If it's spread out over multiple commits, use current unstable, but that may introduce other unknown regressions and breaking changes. And in any case we'd go back to the release tag on the next release.
Patching sounds like a good idea, hopefully it is just one commit. Though honestly from personal testing the newest release worked perfectly fine (I tested via an override).


is non-deterministic if given both and . Here are a couple runs back-to-back: However, when I make this and :
Interestingly, itself is deterministic, despite being non-deterministic (at least from the command line). This is pretty curious.
Perhaps environment variables come into play? Does the shell script take care to clear the environment like a nix build does?
So, I tried diffing two of the outputs: That looks an awful lot like part of my git hooks that automatically generate tags. Sure enough: I'm of the opinion that we should override in the package, to prevent these kinds of problems. Thoughts?
Seems like those scripts in general should almost completely clear out your environment
Yeah, I don't know how much to get rid of, considering that someone may want to get the hash of their private repos or something.


This issue is mainly a note to myself since the upgrade won't be trivial and will need a lot of testing. Protontricks is now using the Pressure Vessel runtime, so I have to refactor my patches with steam-run to account for this. <!-- 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: protontricks <!-- 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.4.4 desired version: 1.5.0 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: myself


<!-- 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: desired version: <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: are you already working on it? if not i can do it
I have some exams to take tomorrow, so maybe I cannot open a PR in 17 hours. Feel free to open one if you have done the update.
I just wanted to make sure you haven't started to work on it, so we don't do duplicate work. I wish you great success with the exams!
Just also have a try on this, fails with . Actually I have no idea what happened so I just opened , downstream workaround should be something like , actually this seems to work, builds and launches. <img src="https://user-" width=50%Also I noticed that we maybe need in , haven't tested yet.
downstream workaround should be something like , actually this seems to work, builds and launches. i don't understand what it does, but it works Also I noticed that we maybe need in , haven't tested yet. I noticed before that the indicators do not work. I'll try it.


Isolates parallelEach doesn't work Steps to reproduce the behavior: run nix develop with then run: dyalog then in the dyalog repl type ⎕DL isolate.llEach (1 2 3) returning like its the case when using the .deb on lets say a debian host strace log reveals a lot of lines like which does not happen on a debian host when I install dyalog 19 via dpkg -i I have also tested this on a debian host that has nix installed and installed dyalog via nix instead of dpkg but I run into the same issue making me believe there is something wrong with the drv system: "x86_64-linux", multi-user?: yes, version: nix-env (Nix) 2.18.2, nixpkgs: /etc/channels/nixpkgs (I ran it against the current (1 hour ago) nixpkgs master/unstable branches) as in I pulled these 2 about 1 hour ago
I'll see what I can do about this. In the meantime, could you change the issue title to start with ?
sure
Phew, finally found it! The issue was with the class, which auto-crashed when created. I redirected its output to a file, and it turns out that because I didn't patch to require it wasn't able to load it, thus erroring out.
This is awesome, thanks for the incredibly fast response/fix time. I suspected it was something like this I initially thought that maybe some of the libraries weren't copied over since the nix expression is a little pickier than just cp *.so $out/lib but upon fixing that nothing change really. Usually knowing when to apply patchelf is quite clear as software will let you know if a library is missing so throwing ldd against it generally gives some pretty good insight. Though if you'd like sharing this information, would you mind telling me how you found out? Was it just intuition or did you use some sort of tool to debug it to come to the conclusion that this may be the issue. As i couldn't really get hold of logs making any sense when I tried it. This would be quite interesting to me as I most likely will get to fix more dyalog stuff in the future.