Describe the bug The package that there was a directory in go's tools repo. Unfortunately, this directory was removed on commit  Not sure when the binary stopped being shipped in nixpkgs. To Reproduce Steps to reproduce the behavior: latest version of the the directory of the output from the derivation and assert the command is no longer there /a Expected behavior The gopls command should be available, it's a crucial binary, as it is used for lsp support Notify maintainers Metadata Please run and paste the result. Maintainer information:
is now available in package. This was changed in
Uhm, silly me, didn't check there was an independent package now. Would you say it is a good idea to update the referenced comment in this ticket? I can volunteer to update the comment.
Yes, I think so. Let's add a reference to this issue as well.
Created the PR: Apologies for the delay


Project description Epson Scan 2 is a scanning utility for epson printers and scanners. Metadata homepage URL: source URL: license: platforms: linux
I spent some time on this, but probably packaging epsonscan2 isn't worth the effort. My findings: build is quite tricky, as the sources contain some amount of tweaks (overrides) to standard cmake variables for build/install paths, and some install commands don't use , non-free software plugin is required for network scanning: sources of epsonscan2 are hard-coded to search the plugin in same path as is the installation path of epsonscan2, which doesn't play nice the immutability, the scanner might be supported already by My all-in-one printer is EcoTank L3160, which isn't listed in , but is similar to EcoTank L3150. And, all that was need is the following config: Terminal output:
I've managed to get this working on PR . As you said, building is a complete pain and required a fair bit of patching. It would be great if other Epson scanner owners could test this!
Works for me with Epson L3150 with wifi connection and non free plugins.


ssh-dss was deprecated in 2015. Server support was removed in 17.03. It might be time to remove them client-side, and also from examples.
cc me as openssh maintainer to look at this later
Probably fixed by update
This is still being set through the NixOS option default.


Project description amdgputop is tool that display AMD GPU utilization, like or . The tool displays information gathered from performance counters (GRBM, GRBM2, CPSTAT), sensors, fdinfo, and AMDGPU driver. Presumably it wouldn't depend on as does, and it's written in that one language. :lobster: Metadata homepage URL: source URL: license: mit platforms: linux


fails to find libcdparanoia and flac at runtime. This is a regression from , and appears to be more or less the same issue, except for Plasma 6. Steps to reproduce the behavior: to rip a CD with K3b It works, and lists Flac as a supported format. If applicable, add screenshots to help explain your problem. The fix from should still apply in some form? Manually adding flac to and libcdparanoia to works around the problem. also (maintainer for Plasma 5 K3b) Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Please test


In the dotnet section of the nixpkgs manual, However, the behavior is actually the same if is unset or : all executables are installed. The behavior is expected if is a non-empty list. First, package a dotnet module like this: <details</summary</detailsThen, build the package, and look at the dir : As can be seen, some executables (actually, all of them) are installed despite that . If change to , the result is expected: According to the manual, the expected behavior when is that is empty or nonexist. In the definition of , the phase has something like this: Seems that an empty list is falsy here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --- system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Can reproduce
The code is actually which means , then this results in the string and the alternative code path is executed. What I don't see is why would be either in this case...
After debugging it appears that this is being caused by these lines The if condition for does not succeed, as it is empty, so it goes onto the block. Now is iterating over each path given by and spitting out any executable seen in , then it gets wrapped by
It is expected that every executable is wrapped in the block (the behavior when is unset). Something should be modified so that it enters the block instead of the block when is an empty list. Oh yes, I guess I need a pair of glasses (maybe just copy and paste next time). If is unset or null in the shell script when it is an empty list in the nix, I guess the actual problem may be in the definition of ? An empty list becomes null somehow when did the substitution, it seems. I have not debugged it, though.


Errors with: This error has already been fixed in by (See also MultiMC/MultiMC5.) MultiMC successfully builds if you set the version to develop: Attempt to build MultiMC. Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Would also be fixed by (Edit: only the CMake errors, include patches are probably still necessary)
Probably best to just patch the release. I'll see if I can do anything about this. I need to fix the desktop file anyway.
Patching doesn't work, and calling the commit directly results in this. Not sure what to do. If someone does fix this, please include in to fix the desktop file.
I managed to fix it by using the unstable version, but I'm not sure if that's the right approach. I can make a pull request with that if you'd like.
It should be fine, just note that it's a temporary workaround until MultiMC increments a release, since IIRC stable packages aren't generally supposed to be using non-stable repos.


in secret management was redone for bookstack. Now I can't place a mail password as secret. It's also appended with : Please run and paste the result.
Oh, sorry about that. I can't see any obvious culprit in the code and I really don't know where came from. Can you paste the service script as it's been rendered? Can you paste a configuration that reproduces this?
Oh, I suppose this could happen if the mail password file path is a superset of the app key file path. Is that the case?
I've submitted a fix for you to test: . I hope it solves this issue.


Describe the bug executing terminates with an error. This didn't happen with idris2 Version 0.3. To Reproduce See above and below. Expected behavior The REPL should successfully start and present its own prompt Additional context Notify maintainers Metadata system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
Could you try setting ? In particular, they should be set here:
The library paths mismatch.
Hey, your seems to be empty. :O This is what my recent install () looks like:
huh, why does it seems empty, it clearly contains stuff?
Ah sorry, I misread the columns then.
Can you compile and run execs?
suggestion:
when I manually adjust the library paths to include the version, it works:
Run with
Will apply, though I am now concerned about the different behavior in NixOS, so maybe I am getting the libs from somewhere else DX


Rebooting a NixOS instance on ec2 does not resize the root volume even though Created one of the amazon ec2 instances: nixos-17.03.885.-x86_64-hvm-ebs Resize the ebs volume associated with the instance using the aws console. Reboot the instance. View to see that nothing has changed view Find this in the error logs: System: (Hummingbird) Nix version: nix-env (Nix) 1.11.11 Nixpkgs version: "17.03.885." Sandboxing enabled: build-use-sandbox = false


this commit makes my NVIDIA GeForce RTX 3090 no longer visible to ollama: needs to be revisited, or add optional flag to disable hardening (which i don't really need since I dont expose ollama over internet). when running through systemd: when running :
Can you check , and try adding these strings, prefixed with to ? For me on NixOS 24.05 they show and the module currently allows the following device types:
Just upgraded to the unstable module and package and things are still looking fine. The only nvidia related config I have is
, will try later when I get back home. Not sure if related but I'm on nvidia as the newer versions are broken in one way or another (wayland/performance regressions/pytorch issues).
You can also try nuking the DevicePolicy altogether if the suggestions above do not work: = { DeviceAllow = lib.mkForce [ ]; DevicePolicy = lib.mkForce "auto"; };
was the missing piece: +
--------+ |-----------------------------------------+----------------------+----------------------+ +-----------------------------------------+----------------------+----------------------+
thanks for your support!
Feel free to send a PR to add it to the module. Thanks for looking into this!
some additional findings, nvidia device group names are definitely driver version dependent, this is what I get on 555 ( is gone):


Electron is a security-critical component for several desktop applications and we shouldn't be keeping EOL versions around. Please remove all versions older than 18 if possible. The latest version is 21. via cc
There are at least 14 packages that require Electron < 18, should we drop them as well? Isn't it better to just mark Electron < 18 packages as insecure via ?
That is a start, ideally we could move those packages off older Electron versions, but I don't know how feasible that is.


After the recent update of nixos-23.05 from to (which included , updating Firefox from 119.0.1 to 120.0) Firefox started crashing, apparently when WebGL gets used. Steps to reproduce the behavior: 120.0 with a clean profile. a crash. Some crash reports: https://crash- https://crash- These crash reports point to , which shows a matching backtrace: The underlying problem might be somewhat different though, because the offending option is not present in any Hydra build logs ( is present though). system: host os: multi-user?: sandbox: version: nixpkgs:
You can disable WebGL temporarily while the bug is being fixed. about:config webgl.disabled set to true
also works without crashing even with WebGL enabled.
Hydra build log: This is the same root cause as described in (originally for Ubuntu Firefox Beta PPA for 18.04 LTS). This is caused by building in such a way that and (and ) embed and export their own version of the code from libstdc++ (in particular ) instead of using dynamic linking to call into the code that is exported by . It is unsafe to do that because of the flag that is used to compile these binaries, and starting with Firefox 120 that results in a WebGL crash. For the Ubuntu Firefox Beta PPA this was caused by compiling with but we do not understand why this situation occurs for the NixOS 23.05 build at the moment. But it does occur (see screenshot below). <img width="399" alt="Commands showing that indeed firefox, and all export std::locale::Sinitialize with this build" src=""If someone knows how to ensure that and (and ) do not embed and export code for , that should fix the crash (we should not see a for when using on these binaries, in fact we should not see it at all because this function is internal to the implementation).
Also apparently the problem is specific to the branch:
Comparing the “good” build log () with the “bad” one () shows the difference in clang versions (and the extra option for the build, which uses clang-15): And the difference is indeed in the compiler behavior.


Using the test file from the Mozilla bug report: With the new compiler from : With the old compiler from : Apparently the important difference here is that the compiler from passes the option to , and the directory contains , therefore the linker uses the definitions from the shared library as intended. However, the compiler from passes the option, which refers to a nonexistent directory ( actually exists, and there is the symlink, but these directories are not mentioned in the parameters), therefore the linker does not see and uses only from , so the resulting shared library contains copies of all libstdc++ functions, which breaks things when is also specified. So apparently the real problem is that in the branch uses wrong library paths for the GCC libraries.
I'm currently building with the following patch, thanks to trofi. This approach fails, as it overrwrites all previously accumulated flags. This was apparently fixed on master in
This will most likely be resolved through , but I'm still testing a solution that would be more localized to firefox and thus arrive quicker.
The workaround is part of the latest release-23.05 evaluation. You can follow its progress here:


, CVSSv3=9.8 (nixos-20.03, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-unstable: . May contain false positives.
merged
Need to keep open for 20.09
Merged to 20.09 too. Closing.


Describe the bug /dev/fuse isn't user read/writable To Reproduce Expected behavior Additional context I've been testing with and : Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
After further testing, I found that reverting fixes the issue. I'm guessing that this new file needs to be installed somewhere. CCing maintainers of systemd:
There are even more tmpfiles configs that we're not using. I'll check what applies to us and prepare a PR.
It would be cool if there was a test for the permissions.
I have the same issue with /dev/fuse for can't mount remote sshfs as user only as root la /dev/fuse 10.6s crw------- 1 root root 10, 229 Sep 23 14:36 /dev/fuse ~sshfs user ~/sshfs/ fuse: failed to open /dev/fuse: Permission denied Any fix we can expect soon?
Seems permissions is associated with systemd /etc/static/systemd/system/kmod-static-nodes.service
apparently that broke permissions for me, which are needed for
Strangely, on my 19.09 system does have 666 permission, despite containing a line .
I think the permission is automatically set to 666 by udev rules when the fuse module is loaded.
In my system on 19.09pre channel I have this issue manifesting in kbfsmount failing with a permission error. crw------- 1 root root 10, 229 Sep 23 21:48 /dev/fuse


is currently using this command creates the temporary directory inside the current working directory instead of in . This can cause the generated directory to be included in the final package, as I'm assuming accidentally picked it up. I encountered this while working on and The temporary directory is not included in the output use use (output is of the format ) note: this isn't really used across nixpkgs use something else <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Steps to reproduce the behavior: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hydra can reproduce:
I tracked down the potential source of this failure, and am working on a fix. These builds take 30 minutes for me though, so it's slow going.
Please see for a fix. Testing appreciated.
Thanks for the quick patch. EDIT: My way of installing to profile didn't pull the fix, I'll see if I can figure out a way to do it properly using the pr review package
Builds and runs... seg faults as soon as I load a model, but that's an AMD driver thing (whole WM crashes)... Ship it :laughing:
I did see some segfaults, but was able to restart and get it to load on my 6700xt. “Glad” to know it’s known and common.
Nice! Thanks for this - excited to see it roll into unstable soon. Ollama seems to always have some issue - is there a "working group" that has some focus on this program and nix? Anyway, thanks again!
The problems with crashing aren't nix problems, they're crappy amd driver issues. It doesn't crash if you don't load models close to the max vram available... obviously it shouldn't crash if you do, but amd... so yeah


Steps to reproduce the behavior: cmus on current (). Full logs: I haven't updated in a while, so I'm not sure where this failure starts. Nothing has changed in the cmus package; it must be a change in dependencies. system: host os: multi-user?: sandbox: version: channels(root): channels(jamesw): nixpkgs:
cmus started failing somewhere between (good) and (bad). I don't have the hundreds of gigabytes of RAM that would allow me to do a bisection between those, so I'll leave that to someone else.
Manually going through it suggests as a possible culprit. I have no idea what that commit does, though, yet.
the issue is bump of ffmpeg to 6, i am about to push a fix


Project description DevSpace is an open-source developer tool for Kubernetes that lets you develop and deploy cloud-native software faster. Metadata homepage URL: source URL: license: apache2 platforms: linux, darwin


Steps to reproduce the behavior: nixpkgs electrum was recently updated 4.3.1 -4.3.2: previously built fine on nixpkgs 2022-09-28 () <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --<!-- attempting ti bisect, but on a slow machine, and it looks like there's miscellaneous failures over this duration so not sure it'll bisect cleanly: --
bisected to: good: bad: that's the staging-next merge though, so a lot of surface area. however, we appear to address a very similar build failure over in pkgs/development/python- by doing: i'm not sure how to test this same patch on electrum since it doesn't have any file.
oh just kidding, Electrum just places its in a different location. the patch below fixes the build when applied to master, and the application starts but i didn't test any functionality that i know touches protobuf. not sure how concerned i should be about overriding a pinned dep (i'm not a python dev):
Fix in


A clear and concise description of what the bug is. Steps to reproduce the behavior: build github:nixos/nixpkgs/nixos-unstable#legacyPackages.x86_64- Nix builds the derivation. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Maintainer information:


Possibly a regression after CC <!-- 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]:
Log The clue is in this log line Odd that we'd be copying something to a derivation ending in , right? Let's investigate further. is one of the CUDA redistributables, so I know it's built by the manifest builder. Looking it over, we can see the relevant portion of the : Well, that looks about right, but what is it actually rendered as when building? Uh oh. Yeah, that's right -- we're missing a newline character! Turns out using the multiline string literal doesn't mean we get a leading newline character (which makes sense given that we concatenate them everywhere and we're not drowning in empty lines). With just a small patch Our is what we would expect: And the resulting build contains our binaries! More generally, the problem likely caused the last, non-, output to disappear.
Will be
I suppose it wouldn't be unfair to say that this is an instance of the "we've stringified our data and failed to parse it again" issue?
I think that’s fair to say. As I view it, the actual build is always done by a bash script. We can either write it entirely in bash, or template it (like we do currently). Both come with tradeoffs. In my opinion, the boost we get in expressivity from lifting some parts of the build up into Nix expressions (so we can use attribute sets and functions in the library) outweigh the cost of making sure we’re producing well-formed bash. Although, that does fall apart sometimes (like here, where we were missing a new line). I’ve not tried to rewrite the install phase as a static bash script which leverages structured attributes, but I do wonder if it would have been as easy to debug? At least with the approach of using Nix as a templating language for bash we can use nix eval on the install phase to see the result. thoughts?
Yea we can also use to peek at the attributes that would go into the JSON, and then maybe there's less bash to read


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


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 tag:
Looks like another gcc11 issue. would you mind taking a look?


First release in three years. <!-- 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: 1.6.4 desired version: 1.8.0 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
cc who might be able to help with building the extension from source


Describe the bug It seems you can't disable GDM's auto suspend behaviour. Disable has no effect. To Reproduce laptop will auto suspend after timeout Expected behavior Suppress auto suspend. Additional context Follow up from Notify maintainers Metadata
I'm on Wayland if that matters.
I believe it only touches the dconf profile in gdm, and sets these settings You probably still have those set in your actual session. See the OP of for more details.
Though I could be misremembering things
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Not sure if it will work yet, but I ran these commands to make my settings match the autosuspend = false settings:
After making these changes, it still suspended. Then I killed , and since it has restarted it has not auto suspended. I'm not sure if this is the simplest thing, but what worked for me was: set , rebuild NixOS Kill so it restarts
returns nothing for me on unstable. I have set to false and it still suspends. (I not 100% sure this is caused by gdm).
Well, it started auto-suspending for me again, even with the above settings.
I'm trying this now:
Seems to be working!
In my case it was xorg, not gdm at all. I disabled screensaver and autosuspend with:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Wow, it's 2023, and this still appears to be the solution To clarify I actually did the suggestion in here, which has an additional line
I vote to reopen this. The fix is easy to configure, but difficult to understand.
It seems like "don't suspend my system, i'm running this as a server" should just be a single config option


Describe the bug The unifi controller has dropped a present in my : Seeing as Unifi support has asked me about "temp", the "device tab", and my network topology, I'm not holding out on getting a good answer as to what it's doing. Short of that, I'd like to prevent it from having any access anywhere except a single temp, non-executable location managed by systemd.
I marked this as stale due to inactivity. →


When the service starts, the following message is printed to the logs: sshguard[]: sshg-fw-ipset: Could not initialize firewall Blocking does not actually work. Blocked hosts can still initialize ssh connections. Default sshguard config. system: host os: multi-user?: sandbox: version: channels(root): channels(XXXX): nixpkgs:
It seems like that is due to ipsets being created of different types than intended. I'm not sure where it's getting created with that though: # ipset -L Name: sshguard4 Type: hash:ip Revision: 4 Header: family inet hashsize 1024 maxelem Size in memory: 88 References: 1 Number of entries: 0 Members: Name: sshguard6 Type: hash:ip Revision: 4 Header: family inet6 hashsize 1024 maxelem Size in memory: 104 References: 2 Number of entries: 0 Members: Whereas the script intends to create types which is why it returns with an error. I do not see where in the sshguard is type of ipset getting created. I came across though.


firefox package is missing its icon in the KDE4 menu whatever its called today.
Any update on this issue? Is it a license problem?
Try firefoxWrapper.


Nixos build error when using a MQTT sensor, following . being the channel. The corresponding line seems to have been removed in : which is the commit for the update to . Maybe the code has changed and the python script no longer recognises sensors correctly ? system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
The configuration you listed above does not yield an evaluation error. I have verified that by building it myself. You must have specified somewhere else.
I don't have any other mention of in my config, although I have also configured an external mqtt brocker with which might change the evaluation. I can confirm that when I remove the sensor config, the evaluation error goes away, which is why I didn't think I needed to include the brocker config. Those are the only mention of in my config I promise! Still it's strange that the line was removed from no ?
I've just noticed now that I have forgotten in my config... Here is the actual pieces of relevant config:
That's the default. No need to include it. After all, I was able to reproduce your error by building NixOS from the stable channel. My bad. It's caused by the following line: which will use the from the stable package. However, if I set I get which I still have to investigate.
I really have no idea what's going on. The way I test this is by having a file with the following content: and a checkout of the branch with the following diff at : When building the configuration I get What's strange is that there is no error when points to the branch with the diff applied. Maybe or have a clue.
I am happy you could reproduce this! Still, I don't see any line for in the (but I see it in the ), which I think it will lead to problems when it will be merged, no ? What I still find strange, is that the referred file in my original error is from ... Is this making any sense ?
Yes, this makes sense: The module is taking the list of from the stable channel and passing those used in your config to the package from the unstable channel, which obviously can't find the component since it's no longer in .
Ok, thank you for your explanations, I understand where the error comes from now !


I did some digging around to know why the line has disappeared from the with the update. This is what I found out: on the home-assistant repository, the code for the mqtt sensor was moved from the to between and this means that the is now in the When I define a mqtt sensor in my nixos config, will the nixos module be able to do the conversion from to (I don't fully understand the code in the nixos module, especially the code) ?
Not yet. I will implement that once I was able to solve the stack overflow issue.
The problem should be solved once you upgrade your system since is now in the channel. Can you please try again?
I can confirm that I don't have the build error anymore, thank you ! However, the home-assistant environment is missing component dependencies. Same as stated previously, home-assistant code has been refactored, but config is the same, which means that dependencies are not found. For example, I have declared in config, but dependencies are at the key.
Adjusting the code for is on my TODO list. For now, please override the package's .
Ok, at the moment, I am using manual config because I am testing home-assistant, using and the automation editor, so I have manually set the . Do you think we could add a package (something like ) which would have all possible dependencies (the idea being that I would also be built by hydra) - a little like the docker/distro image that distributes ?
Sure, no problem. However, I suscpect that will often not build due to some Python packages not building. Do you want to make a PR or should I do it?
I can surely try, but I am not sure how I should proceed : I define a new option for package that populates to all packages referenced in should I call the package with all packages referenced in (in a new file next to ), and call it in a new in . Which option do you think is best ?
I guess the first option comes close to the best one. However, please don't use for that but directly add the packages to . Maybe we could also add a few lines to to add a list of all packages to so that we don't go through all components to generate that list.


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


, CVSSv3=5.5 (nixos-20.03, nixos-20.09, nixos-unstable) CVSSv3=5.5 (nixos-20.03, nixos-20.09, nixos-unstable) CVSSv3=5.5 (nixos-20.03, nixos-20.09, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-20.09: ; nixos-unstable: . Cc
CVE-2020- doesn't seem to have a patch yet. The rest (for all mentioned branches) is going to be addressed in .


Package name: matrix-synapse Latest released version: v1.113.0 <!-- Search your package here: --- Current version on the unstable channel: 1.112.0 Current version on the stable/release channel: 1.112.0 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Minor cosmetic issue: when using kpcli, the prompt shown to the user says ".kpcli-wrapped:/" instead of the usual "kpcli:/". system: host os: multi-user?: sandbox: version: channels(delroth): channels(root): nixpkgs:
Usually this can be fixed with the --argv0 flag:
kpcli uses wrapProgram which already sets --argv0 correctly AFAICT. Looks like this is a kpcli specific problem:
OK, I understand the reason why --argv0 did not work now. Since this is an interpreted script, we are indeed setting Perl's argv[0] to the right value, but within Perl 0) - Sent to just wrap the script manually and thus control the basename of the wrapped script.
Fixed in


Describe the bug clones each submodule in sequence instead of in parallel, which is unnecessarily slow for repos that have a lot of submodules (such as which has 64 direct submodules). At first I thought this was because git's setting defaults to , but it turns out doesn't even use that, it instead recursively clones the submodules by hand. it looks like you this 10 years ago; is there any reason we can't just use today? I don't know why it doesn't just use git's built-in submodule handling, doing so would make fixing this trivial. Parallelizing the manual clone loop seems a lot more complicated (especially because of the problem of mixed output). To Reproduce Steps to reproduce the behavior: from scratch. (Edit: was recently updated to not use submodules anymore. This can be reproduced using an older version) Expected behavior It should clone the repo in a reasonable amount of time. Notify maintainers Last few changes to were and Metadata system: host os: multi-user?: sandbox: version: channels(lily): nixpkgs: Maintainer information:
I marked this as stale due to inactivity. →
See
Simplified in


Steps to reproduce the behavior: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Relevant issue on the upstream repository:


Project description A system for automatically configuring mutt and isync with a simple interface and safe passwords Metadata homepage URL: source URL: license: gpl3 platforms: unix, linux, darwin


Project description Journalist is an RSS aggregator that can sync subscriptions and read/unread items across multiple clients without requiring a special client-side integration. Clients can use Journalist by simply subscribing to its personalized RSS feed. Metadata homepage URL: source URL: license: gpl3 platforms: linux, darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
please test


Creating fixes this. Remove and restart . system: host os: multi-user?: sandbox: version: channels(michael): channels(root): nixpkgs:
Maybe we need to add something to the systemd service to ensure this is created?
See


See also Steps to reproduce the behavior: This is such as basic cross-compilation that I wonder whether something is wrong in my setup. However, the errors are surprising, because I thought most packages were cross-compilation aware enough to not run host binaries on the build platform. Please run and paste the result.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
was mentioned as a possible fix.
I can confirm that fixes this issue.


, (nixos-19.09, nixos-unstable) Scanned versions: nixos-19.09: ; nixos-unstable: . May contain false positives.
No upstream release so far. Applying will probably be OK, but I don't feel confident enough to do that "backport".
I do :-)


I used Genymotion for a long time on macOS but with Virtualbox. I switch to Linux/nixOS about 5 months ago and was pleasantly surprised to read Genymotion now supported the QEMU engine. Alas, myself and a few other of my friends were never able to get Genymotion to work using QEMU, which is the preferred Hypervisor. I've tried to source some help at but to no avail. Steps to reproduce the behavior: a running working QEMU installation. Presumably with at least 1 functional VM too Genymotion Genymotion, ensure QEMU is selected as the Hypervisor a random Android device, add it and run it. 'll first get a 'can't start virtual device' error trying to start the Android device again gives a 'Another QEMU process appears to be using the same resources' error I'd expect Genymotion to start the Android device using QEMU, naturally If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: ! !
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
! !
Duplicate of . Does the workaround in work for you?
I'm not really sure this is a duplicate but that's up to you. I'm not a coder so had no idea what to do with that old 'work-around' either. I had a colleague who kindly looked at it, spent some time, and turned it in to a flake which can be found at And now the broken Genymotion functions great with QEMU. Perhaps the flake code can help in fixing the package. Thanks for the pointer to the old work-around


Steps to reproduce the behavior: ... ... ... A clear and concise description of what you expected to happen. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.
Hey have you ever made Genymotion work under Wayland ? For instance, on any other distribution ? I'm not sure the support for Wayland has dropped quite officially for Genymotion or I might be wrong, maybe there is no need since it's a QT based graphic interface and platform plugins do exist for Wayland nowadays. EDIT: To add more information, on ArchLinux, here is what I'm getting as an error you might want to share your exact genymotion logs I'm running Sway and I have the following env variables set : QTQPAPLATFORMTHEME="qt5ct" QTQPAPLATFORM=wayland #QTWAYLANDFORCEDPI=physical #QTWAYLANDDISABLEWINDOWDECORATION=1 XDGSESSIONTYPE=wayland XDGSESSIONDESKTOP=sway XDGCURRENTDESKTOP=sway
Okay so I made it work on my end but I'm not under NixOS/not using Genymotion installed from Nix, try
I have run with , but still get error. and this is the QT relate envs and this is XDG relate envs
Could you give a try and use every single platform listed here :
Also please share your genymotion logs, there might be more to the error in there And finally, please let us know your exact Desktop Environnement, Wayland is being used, I suppose.
One more thing, could you retry using xcb as a platform after having installed in the environnement ? EDIT : Also set So to sum up run :
I am using wayland + plasma, so I think the dependencies is ok and this is
This may not fix your issue, but try it with this : ! EDIT: Also are you running with an Nvidia GPU or not Wayland ? If yes, you should try everything related as well.


EDIT2: I've found this so I believe it should work, but something may be wrong, I may need to look at the Nix definition of the package and compare with the way it is packaged for ArchLinux and see if there is anything that could explain what's going on. ! There could be also issues regarding Wayland + Plasma : If you could try another desktop environment, maybe Sway if possible, if you cannot, I will give this a try in a VM under the latest NixOS when I have some time.
See this commit too this maybe a fix, that you don't have yet, maybe you have it already because it's been backported.
Could you please the run of the command ? And uploads the logs to a GitHub Gist. If you can't or are busy, let me know, I'll try to reproduce inside a VM and investigate.
This is the log
I know what causes this problem, because I have different qt version, so I have to add to , and it works for me, thanks for your patience and help
Should I make a PR?
Hm I'm not familiar with the process but I believe you should make a PR if you can or maybe let's tag the maintainer of Genymotion here ? I believe it is
Let's wait a week or 2, if he answers back and can make the PR then you can wait to close this issue once the PR gets merged.
Still relevant. Genymotion tries to load some Qt plugins from nixpkgs and fails for whatever reason. I was able to workaround it by doing . used to work before too but is failing now (and it's unclear why, since its effects are similar to , I guess genymotion still picks something from env vars besides plugins)
Hi! I'm there is seems no this issue on unstable, but I've found another one - Can't start virtual device: qemu libpixmin not found. Here is log: Should I create another issue?
That's weird, I believe you should open a new issue yes however I'm not sure if including as a dependency in the derivation of might fix your issue : Running outputs :
as the maintainer of genymotion's package in Nixpkgs any advice/idea, what's going wrong ?
Seems like you were trying to launch genymotion with qemu instead of virtualbox.


A while ago I managed to make qemu version working (at least on my machine) by adding some bloaty dependencies: I didn't test it on latest unstable, but you could give it a shot. It also workarounds that Qt issue via in wrapper.


Describe the bug The static build of is broken. To Reproduce Steps to reproduce the behavior: Expected behavior It builds. Screenshots See log output. Additional context In the version was bumped but the patch was not adjusted. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- (+ author of ?) Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:


Project description Tana is an outliner, a note-taking application that sits between Roam Research and Notion. It's a great up and coming productivity platform, with a unique feature called Supertags. Supertags are basically templates you can graft on to tags. They currently have a deb and a RPM, but as it's a closed source application, the source is not available. Metadata homepage URL: source URL: license: Proprietary platforms: Linux (Deb and RPM), windows, mac Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I have it working locally, need to clean up some stuff and then will create the PR! I still have to figure out the license they're using (for the metadata)
That's amazing! I'm so happy thank you so much!


icoutils' extresso missing perl dependencies. install pkgs.icoutils and execute "extresso" in shell. This works(): NixOS 16.03


Steps to reproduce the behavior: oh-my-posh package as part of a system flake on nixos-unstable branch broke today, however most recent working commit I have found is: which is obviously confusing package author says not their issue, but also says the package is out of date as they are on 19.5.2 and the package is on 18.26.1 My system config is: Dont judge im kinda new I havent worked on secrets yet so I just dont have any secrets in it
Looks like an update PR is in progress that'll probably fix it:


In latest version of Adw-gtk3, window title bar on Electron-based app be weird transparent Steps to reproduce the behavior: Adw-gtk3 to latest version (from Nixpkgs) it as usual Electron based app title bar be weird transparent It looks as usual I show screenshots from my installed Electron-based apps, VS Code & YouTube Music by th-ch ! ! I haven't idea sources of this bugs <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Based on upstream issue, it needs GTK 4.16 for v5.4 version. I wish it can solved soon as possible
This for Gnome 47 needs to merge first.
!
Maybe we could just revert and update it again once GNOME 47 is merged?
I override it on my configurations and it works properly


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


Can someone else try it and see if it works on their system too? If so, it may help to figure out the proper solution.
I tried it and it actually rebuilds without error the first time too. Hopefully that helps you or someone else figure out a permanent fix! Many thanks.
From my side the issue seems to be be fixed with the merged fixes. So I will close the issue.
If anyone wants to track the merger of the fix :


the following configuration: guests are started to confirm VM should have automatically started guests marked to start on boot start Guests marked to boot on startup should start doesn't seem to do what it says
Not stale
The problem is that libvirtd is socket-activated on NixOS which it isn't out of the box.


RStudio is missing most of the text from its UI (see screenshots), the text one being displayed is in the top menu bar. Icons are displayed correctly though. or to the environment (for example ) The main interface starts in a new window with version information in the left pane, environment information in the top-right pane, and filesystem overview (with file and folder names and not only a logo to represent them) What I observe: ! Expected (here taken from archlinux's rstudio package) : !
Confirmed, fixed on my side, thank you!
I also have this issue and the PR does not solve it... Please let me know what information I can provide to help you in debugging.
Please just forget about it : my pinned version was not building the new version that you packaged. Thank you for your help !


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


When I set in , the rebuild fails as is no longer a valid option. Steps to reproduce the behavior: thrown: The option definition /nix/store/bfg7xzgvbhxhs7vnl7lynaxmjhmvc4j0-' no longer has any effect; please remove it. See the 16.09 release notes for more information. should not fail. - - Please run and paste the result.
Having had a look at that module (), IMO it should just be removed. ? really?
The module in general looks outdated and incomplete. I share the opinion of either dropping it or actually correcting and finishing it.
Other question is when you look at the history they removed lsh 7 years ago because it was unmaintained, but then the commit got reverted later?
This module doesn't make sense at all. GNU stuff and non-GNU ones usually can't fully replace each other, and it's up to the users to decide which one to use.


Please add rust-gdbgui to in the post install script of rustup. rust-gdbgui was recently to the list of proxied tools in rustup. However, the change that's now present in latest master of rustup is not yet part of a tagged release. I'm assuming that updates to a package are only done to tagged releases? I'm also not sure how disruptive updating the is. So, I think this issue cannot be resolved until the next release of rustup. name: rustup current version: 1.24.2 desired version: 1.24.3 (not yet released) maintainers: Please tag this issue in your PR.
Can you make a pull request? We should wait for a release so.
Sure. I'll make a PR on the next rustup release.
I marked this as stale due to inactivity. →
See pr


Project description Dr. Robotnik's Ring Racers is a kart racing video game originally based on the 3D Sonic the Hedgehog fangame , itself based on a modified version of . Metadata homepage URL: source URL: or license: gpl2+ platforms: linux cc (this is kart v2) Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Done. Test it out and let me know if you encounter any issues :+1:


and fail in this fashion: This seems to have started to happen in December of last year (see ). This effectively means that using the avr toolchain in nixpkgs means re-compiling gcc on every channel update. Not sure what is causing the log size, unfortunately there's no special hydra meta attr to change the log limit. cc Maintainer information:
From doing local rebuilds of this package and noting how much output it gives, the long logs are from echoing back the compiler commands from make when compiling all of the soft float routines for each different AVR chip. It started dumping all this output when we moved from GCC 9 to GCC 10. Looking at the logs prior to that version bump, make must have been quiet because I see no compiler commands getting echoed back. Is it possible to add something like here?
may be worth a try:


Project description Oculante's vision is to be a fast, unobtrusive, portable image viewer with wide image format support, offering image analysis and basic editing tools. Metadata homepage URL: source URL: license: MIT platforms: cross


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


On NixOS 21.05, when setting , I could see the result of this settings by running: Since NixOS 21.11 however, altought the masquerade works, I cannot see anything with iptables commands: As discussed on the Discourse topic , I suspect this is linked to the following change in NixOS 21.11 (PR ): Steps to reproduce the behavior: an interface with on a system running NixOS 21.11 the lack of information about the IP masquerade The IP masquerade should be visible like in NixOS 21.05:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Actually, this is due to systemd since v248 preferring to use nftables if available, see Systemd does not use the iptables binaries and but a separate library that creates iptables rules directly without translation to nft by iptables-nft. So even without using the legacy iptables tools, these rules in nftables by networkd would not be visible. Other services that need to add firewall rules like libvirtd, docker or podman are likely getting proper nftables support soon and users still using iptables will run into the same issues. Since we are not the only distribution dealing with this, this should either be solved in systemd (can rules be generated that are compatible to and can be parsed by iptables-nft?) or in iptables-nft by displaying a warning that other nftables rules are active. The only related problem remaining in NixOS is that since our module is heavily based around iptables, our users assume NixOS is using iptables when in fact it is using nftables with iptables compatibility. cc
This particular issue is also giving me issues running docker on NixOS 21.11 in WSL2 on Windows 10. It requires iptables and the docker service fails to start due to docker trying to issue iptables a command and the nftables reply throws docker as an error. Same configuration using systemd v247 via 21.05 works fine
What you're seeing is directly caused by and has nothing to with this issue since the problem described here is that not all active rules are visible. Are we even supporting WSL officially?


You might want to open a separate issue for this if you're interested in seeing support or getting this fixed. We would need to detect if nftables support is available and use the correct iptables package everywhere. Not sure if it's worth it, though.
this seems to also cause problems when upgrading systems from before the nftables bump. In my case, these were fixed after a reboot, but it's still a pretty annoying thing, for which we probably should at least make sure there's a release note entry. cc
Hmmh, I'm also a bit baffled about how to interpret defaulting to false. ~It seems and are mutually exclusive, but since we now configure nftables in other places, the firewall module is just broken?~
It seems only supports defining all rules exclusively, which doesn't play very nicely together with other things invoking iptables, or managing rules by themselves (like networkd , libvirt and other programs invoking iptables). Maybe that module needs a bit of a re-vamp - with merged we might want to configure most of what the module was doing, except managing the ruleset by default. However, that's a bit offtopic from the original issue.
you should see nftable tables when invoking , which is where systemd keeps its nft rules. iptables rules configured with the command are in . I think this is mostly a matter of updating the release notes, and raising awareness, that nftables is used, the command is only managing some tables in the nft system, and that there's more rules than what you can see with . I'll try to come up with a PR updating the release notes in that regard. It might not be possible to translate some nftable rules to a iptables syntax - I'm not sure if logging a warning breaks backwards compat with some tools relying on iptables output…
I improved the docs in , PTAL. Fixing the nftables module, and using less iptables in the firewall module should probably be left to another PR.
I opened to track the nftables NixOS module improvements.


git package includes which defines functions for shell prompt customization like . Even though the file is included it's not sourced by default and doesn't make the functions available. Steps to reproduce the behavior: package system-wide. one of the functions provided: the file manually: function becomes available: shell function being available out of the box when package installed. Making the prompt functions available when bash completions are enabled seem to have been the original intention of . However one might also argue that the functions should not be sourced by default if someone doesn't use git prompt customisations provided. It could be placed behind an option but I'm not sure it's worth the hassle. cc
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I'm not a maintainer or expert, but I read your linked Discourse thread and your ticket because it sounded interesting. Great analysis and writeup. My interpretation is that was never intended to be sourced automatically when completions are enabled, for two reasons. First, inside of : which is an instruction to source it explicitly. Second, the for says: which leads me to believe that was created so that it can be used independently from bash completion. Prior to its creation, it might have been available automatically as a consequence of completion scripts being loaded eagerly, but that was accidental.
Thanks for digging deeper into this, Theodore! I agree with your conclusion: it does look like the prompt script wasn't intended to be sourced automatically. I think the best way to approach this in NixOS would be to have a option that would enable sourcing of the file.
I think something like this sounds reasonable. I'm sorry I can't help with it right now, because I haven't set up NixOS yet. (I'm just using nix on my Mac right now.)
No worries, thanks for your help so far :) I might eventually give it a shot myself.


The package fails to build because of missing test dependencies: system: host os: multi-user?: sandbox: version: channels(z0028sn): nixpkgs:
I jailbroke it and the the tests fail anyway. So it should be set to . succeeds.
The problem is that the release tarball on Hackage is incomplete, i.e. the required file appears to be missing. This should be reported upstream () so that they can release a fixed version. Ping:
This should be fixed in 0.6.1, which I just uploaded to Hackage. Please tell me (probably on a pure-zlib ticket?) if you have any further problems.


Describe the bug While Nixpkgs provides version 2018-12-14, there are some fixes landed since then. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
can please check using with a local chekout of nixpkgs?
Yes, I will. Thank you for your prompt response!
I did and tried some commands. It seems to work fine and the store size does not grow significantly. Is there anything else to test?


Describe the bug AppImages assume that the gmp library is present on the system, but appimage-run does not include gmp. To Reproduce Steps to reproduce the behavior: +x the appimage Expected behavior The app should run. Additional context I believe it is because of this commit: I fixed it on my end with: 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 marked this as stale due to inactivity. →
not stale
Also affected:
as pointed out by t-paul, appimage specifically assumes GMP is provided by the system


Describe the bug Building fails with the following messages: Note that points to which updates . To Reproduce Steps to reproduce the behavior: Expected behavior The package is built successfully. Notify maintainers (gfan, cddlib), (cddlib) Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(omasanori): nixpkgs: Maintainer information:
cddlib put its .h file in <hash-cddlib-0.94l/include/cddlib/ rather than the old version of the library placing it .h headers in the root. <hash-cddlib-0.94j/include/ So options are get upstream to #include "cddlib/setoper.h" (and the rest of the directly pathed includes) Patch it in the derivation Take a look at the library is being why it differs from 0.94j to 0.94l ...... and see if can be symlinked (botched). not sure why it's subpathing these .h file now?
v0.94k header files are now installed to PREFIX/include/cddlib to avoid clashes with other libraries. configuration file for pkg-config : assuming cddlib installed in <prefixknown to pkg-config, "pkg-config --cflags cddlib" etc will work. (Otherwise, one would need PKGCONFIGPATH=<prefix/lib/pkgconfig). this is the source of the breakage. this probably breaks everything that uses this library.... lovely! So, options are fix it gfan upstream, or patch it in nix?????? has a 41 length thread, where the developers are trying to workout how not to break any application that uses this library and which distro's they want to break.
Thank you for your survey, The long-term solution would be fixing gfan upstream, given that this is not Nix-specific. The current Makefile assumes that, if cddlib headers are prefixed, the prefix is instead of . A variable to change the prefix will help every package maintainer IMHO. However, adding a patch to gfan just altering with into nixpkg may be fine for now. I will try to address it next week but feel free to make a PR if it is urgent for anyone.


Cannot run the git tests because is broken. Steps to reproduce the behavior: The build should work, the git tests should run and pass Please run and paste the result.


Try building
Just ran into the same problem when updating my system flake. For bisecting purposes, nixpkgs was my previous (working) configuration. EDIT: bisection in progress, have to do some large builds now:
Excerpt from : which seems to be the change that breaks , so we probably need to file an upstream issue.
As a workaround, something like this should work:
Note that the downgrade would undo some security fixes; see PR ... which is also why we backported this problem to 22.05.
I see...I'll wait to re-enable qtile then
Depending on how much value you place on the failing test, something like this worked for me: Modifying the package in a general overlay triggered huge rebuilds for me, so I've just replaced it inside my derivation, which is what pulls in in my system configuration.
How would you modify the package with a general overlay? Something like this didn't work for me:
This global overlay works for me, without annoying rebuilds: Note, I'm using and this is imported in . I don't know if you can use it without modifications otherwise.
I have a similar setup, I have (minus the let bindings I have in my config): So I don't see the difference between our configs...
Somehow, the overlay proposed by worked. This reaches about the limits of my Nix knowledge, but maybe is required instead of simply ? Is the only difference I can notice.


Steps to reproduce the behavior: on fails (see ) Happened within CI when building () Will do. Please run and paste the result. Don't know how to run this on the failing CI machine. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Whenever is used with vivaldi to set it's binary path into a session variable for example, it produces a big warning stating that the attribute is missing and it will default to package name. a library function that needs the attribute like lib.getExe the vivaldi package as below: rebuild the config: the build process a big warning will appear stating the following: , Do the hint stated in the warning and use it like:


Awesome Spectral JSON/YAML linter with OpenAPI/AsyncAPI support Spectral is a flexible object linter with out of the box support for OpenAPI v2 and v3, JSON Schema, and AsyncAPI. MIT
Should be trivial to package using .


Describe the bug There is no AWS AMI for NixOS 20.03 To Reproduce Steps to reproduce the behavior: Check or Try find it in AWS AMI console Expected behavior 03 is created and uploaded to AWS
CC I think knows how to do this part.
Yep, I have no idea how to do this for NixOS, so I'd need someone in the know with AWS AMI for 20.03. This actually was one of my concerns for 20.03.
I know how to build the release AMI and put it on a personal AWS S3 bucket (I'm using one now for my NixOps AWS cluster), but do not have the permissions to upload it on the official account. about 2 months ago I followed this process, which you can use if you're looking to unblock yourself: then follow these instructions to upload using : Then on NixOps you set to your custom AMI. You can also use this to bake in pkgs to the AMI so there's less startup time if you know you'll be downloading specific things on provisioning startup otherwise.


Describe the bug rspamd for aarch64 can't find luajit and fails to build. To Reproduce At the moment of writing, the latest unstable seems to be . Expected behavior Build succeeds Screenshots n/a Additional context Hydra build log: Notify maintainers Metadata Maintainer information:
I managed to pinpoint the issue to the commit , where rspamd was updated from 2.5 to 2.6. Build log: It looks like rspamd is trying to find LuaJIT, but it's only available in builds. Probable fix would be disabling LuaJIT support in CMake flags.
Sorry, looks like I broke it in PR . I didn't notice the failure, probably because it showed as a grey dot instead of a red cross :x:: I'm not sure why that is, perhaps because it has both a build failure in the output (same one as you see), AND an evaluation failure


<!-- 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: sumneko-lua-language-server <!-- 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: 3.2.3 desired version: 3.4.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.


Steps to reproduce the behavior: textadept (10.8) The error is in building Scintilla <!-- 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.


Hi. So I'm running KDE and whenever I try to launch the AnyDesk application, I get the notification: Launching AnyDesk (Failed) Could not find the program '/nix/store/a1cic900s29g1hfwv731cm3bsgni7p9i-AnyDesk.desktop/bin/anydesk' I have to run from the terminal to open AnyDesk. Please run and paste the result. Content of /run/current-system/sw/share/applications/AnyDesk.desktop: However, that Nix store path only has the desktop file and no binaries. The AnyDesk binary is in .


Steps to reproduce the behavior: on darwin aarch64 see Since neomutt is broken on darwin-aarch64. See the CI output: Tangent: is it normal that a failing CI build wasn't marked as a failed check, but rather just ignored? <!-- 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.
Broken on Darwin x86-64 as well.
seems to work — I can't tell whether they are running the tests, though, or not. Here are the failing tests.
Looking at the latest comment on the already closed issue here: This issue could use some love. Neomutt is broken on MacOS and it looks like it's the derivation, not upstream.
I can't install neomutt on MacOS with home-manager too
The failing tests were disabled upstream in . I tried simply upgrading to HEAD with the following patch, and the succeeded (darwin-aarch64):
( That's a different bug which you should probably raise separately.)
Unfortunately, the latest fix didn't work for my Intel Mac, some tests are failing for me. I tested using because I didn't know how to do overrides from the CLI
Yes, the failure on should be a separate bug (and could probably be fixed by putting into ).


Project description describe the project a little is a highly configurable dashboard for Neovim. It's an alternative to Metadata homepage URL: source URL: license: MIT platforms: Anything that can run Neovim, I would assume


When I click on any program in latte-dock, nothing happens. If I run in a terminal, I get these warnings:
I figured out the issue is that latte-dock code fails to detect the version of plasma desktop. For that they parse the output of . I made a dirty test with hardcoded value in and which works around the issue. What is the correct solution to have latte-dock detect the version of plasma? Does it not have access to plasmashell path? Also I noticed that the command results in a segfault. Is that an issue?
See for more discussion. Would you mind describing how to trigger the issue for a person (such as me) who doesn't use plasma shell nor latte dock and so is unaware of (a) how the thing is supposed to work (b) how to set it up?
Sure. the latte-dock package latte-dock. There will be a in the nix store path/share/applications that should appear in your application launcher. For more verbosity, run will see the default layout for latte-dock appear at the bottom of the screen ! By default it has in my case Firefox, Dolphin, and a clock widget. I don't know if it will show your default browser and file manager instead. will auto-hide if a windows covers its area. app that you open should also appear there (eg. a terminal emulator) on an icon of an app that is not already open should open a new instance on an icon of an app that is already open should show that windows if there is only one. If there are more than one, it should show an option to chose the window. At point 6 or 7 in NixOS currently nothing happens and we get in the log which is due to in latte-dock (see )
Curious. I can't reproduce this. Could you try cleaning latte-dock qml cache () and trying again? [aroun plasmashell -v plasmashell 5.26.4 Segmentation fault (core dumped) Can't reproduce this either with Plasma 5.27.
When running , the issue is still happening for me. The segfault also happens for me in plasma 5.27 on NixOS unstable (inside a VM). !


Which DE are you using? Maybe this happens only in KDE plasma?
NixOS Unstable () with KDE and Radeon graphics. Ok, this seems like a plasma bug, though very weird. Can you provide a stack trace? Here's the short instruction: Install gdb in your system cp . chmod u+w ./plasmashell open plasmashell in your text editor, scroll to the last line, add gdb into it so that it looks like this: (the hash might be different) run You'll be presented with the gdb repl. Run commands and . If you get a segfault, run . Copy the stack trace and paste it here. Also, having your VM would help.
Thank you for the instructions.
Oh sorry.. i forgot to ask you to run in gdb if you get a segfault. That was actually supposed to give you the stack trace. Updated the instruction above. But from the looks of it, there's something wrong with d-bus in your system and this is a plasma bug, not a latte-dock or nix bug. The best course of action for you would be to create an issue in KDE bug tracker and attack system info, stack trace, and other relevant data.
Here is the bt Ok I will try to create an issue in the KDE bug tracker. Are you saying that latte-dock works perfectly well on NixOS on your side, in the current state? Can you share your nix config? EDIT: How do I install debug symbols on NixOS?
Are you saying that latte-dock works perfectly well on NixOS on your side, in the current state? Can you share your nix config? It's pretty generic. I have latte-dock in and KDE installed as per wiki: This has worked with Radeon, Nvidia, and Intel graphics. EDIT: How do I install debug symbols on NixOS? This might be tricky. Here are a couple of relevant links. I haven't tried this myself, mind you. P.S. I use X11 only. Scrolled through this thread and didn't find any mentions of whether you test this with Xorg or Wayland.


My config is pretty generic too, especially in the VM, I installed NixOS with KDE Plasma, latte-dock in system packages and not much more. I actually switched channel to unstable to try with plasma 5.27, but apart from that I'm basically on default nix config. I did slightly more configuration on my main NixOS install, 22.11, but get same behavior in both cases. Debug symbols seems painful on NixOS. Unsure if I will do that now. Thank you for the help. I use X11 too.
Ok, so after reading the suggested , I enabled and followed the instructions of the option I have and The part for plasma-workspace seems to work fine, but the one for qt5 givers this:
To reproduce the bug described in this issue, a simple way is this: the official NixOS virtualbox ova from (22.11.2939. at the date of writing this) it in VirtualBox the vm konsole will segfault will run latte-dock and you will see that clicking on items in the dock does nothing
I also tried to update the vm to unstable still segfaults, only that the version shown is 5.27.2 still nothing happens when clicking on items in the dock
Again, this seems like a Plasma bug, possibly due to VirtualBox video drivers or something.


Package name: Latest released version: 0.1.39 <!-- Search your package here: --- Current version on the unstable channel: 0.1.38 Current version on the stable/release channel: 0.1.28 <!-- 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 (sorry!) Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Describe the bug Size of aarch64 sd_image has suddenly blown up a lot. whereas on commit it was To Reproduce Hydra: - - This blocks the channel ATM.
It seems this is caused by my PR here: We switched to , but does not erase the original file, while does. I created PR which hopefully fixes this by passing to .


Steps to reproduce the behavior: the package Offending line Seems to me like the darwin framework is missing Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Posted a PR to fix this:


The beta derivation depends on a pre-built deb package that no longer exists.
CC: (I don't have the ability to assign this)
Hey I just needed the fix for myself and therefore figured I could as well push it. Hope you don't mind.
I don't mind at all! Thank you for doing that.


When trying to install Ocenaudio, the installation fails due to a sha256 hash mismatch. Steps to reproduce the behavior: ocenaudio to my NixOS config I expected the program to be installed. <!-- 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:
looks like aur has the same problem this should be reported upstream.


Package name: lightningcss Latest released version: 1.24.1 <!-- Search your package here: --- Current version on the unstable channel: 1.22.0 Current version on the stable/release channel: 1.24.0 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers myself, <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Despite being a minor version bump, an entire dependency chain was for NAPI which I think has something to do with WASM which fails the test in Nix. See lightningcss’s open bug on their Microsoft GitHub proprietary issue tracker @ As a non-Rust developer, I have no idea what this error is supposed to mean with its Cargo package management. Hopefully their maintainer will eventually have a look. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: [^1] or offering a non-proprietary, non-US-corporate-controlled mirror for this free software project. I wish to delete this Microsoft account in the future, but I need more projects like this to support alternative methods to send patches & contribute.
Build error when updating:
Personally I’ve stuck with version 1.23.0 since 1.24.0 had a regression for system colors. The upstream maintainer seems to be too busy with other stuff to look into issues.
should fix it for further releases. For this particular 1.24.1 release, I a patch to automatically patch the source, see
great work!


Describe the bug See https://nix- The particular cases that fail are I believe rust was updated recently (was that in the release?). It doesn't appear upstream has made a release recently, so perhaps if this report is forwarded to them they can direct us to which patches could fix the test failures etc. cc
According to and bug reports, this seems like a ulimit issue. An interesting workaround for hydra could be using , as suggested in but it's certainly isn't necessary on my machine because I've tested the build and it passed it.
sounds like it would make an already long checkPhase longer :rofl: How about we try ?
We can try this indeed. The question is, what are the default limits of a build user on hydra? Are we sure this might make a difference?
I noticed you've marked sequoia as broken in . Even if a package fails to build on hydra butt doesn't fail locally, does it mean we mark it as broken in its ? Doesn't sound right to me..
That's was the motivation for the issue being opened. If we bump in preCheck and unmark it as broken I think we should be good. ofborg can serve as testing perhaps similar to hydra.
The point is, that we haven't even tried playing with these settings. I would have tried doing it my self but since I know nothing nor I have any effect on Hydra's deployment etc., I wouldn't even know how to test it. What bothers me is the fact it was marked as broken without any attempts by someone with more influence then me to debug it's failure to build only on hydra. Are we even sure this wasn't a failure that happened only once?
Should we close this issue with the PR?
No, it's still failing , at least for hydra, it runs out of file handles
A bit off-topic maybe but I generated a Nix expression for sequoia using , as build times for sequoia where around hours for me. It works now like a charm, as every crate got its own derivation. It can be found here, as a flake: Maybe repackaging with could be an option?
This may be an option, but unpleasant as the generated deps file usually is 1-10k+ of generated noise.


(for local building, this works great)
Yeah, that noise is a bummer. Sometimes I dream of having all of packaged the way we do it with , but I guess that would blow up Nixpkgs indefinitely. But maybe someday when Nix flakes are ready? …
I'm not sure I have enough time to have a good view on this. What's most important about specifically, is the fact we use upstream's to install many other files that should be part of the package's output - files such as libraries, ZSH/Bash completion files and headers. So I'm not sure how will this go together with the approach.
If anyone is interested in a sequoia flake which is built incrementally (vs. everything built in a single derivation), I try to maintain one here:
sequoia , but it hasn't tried 0.16.0 yet - .
Yep, we need to fix it for python 38 though


The 'select file' dialog works fine, but I cant actually open or edit anything. Steps to reproduce the behavior: Either: via the GUI, then a design or a design via the command line: A edit window with a preview should appear. Please run and paste the result.
Judging by the error message, this might be as simple as compiling with wayland in the deps like ?
Omg it worked! Can I leave it with the maintainers or do you want me to file a PR?
If you submit the PR yourself then you automatically get ownership/credit for your work :-)


Project description Continuation (rebranding) of Hanazono font (nixpkg: hanazono). Supports a lot more Unicode glyphs (141,457 glyphs, mostly CJK). English README: Metadata homepage URL: source URL: license: CC0 platforms: N/A (TTF binary) Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


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


This is the content of on my system: It has set to , which does not exist. This path should point to the include directory of vulkan-headers package. Also, the package contain headers that include headers from vulkan-headers package. Should the pc file for glfw3 add vulkan-headers to the include path? Metadata system: host os: multi-user?: sandbox: version: channels(saga): nixpkgs:
Ping (Vulkan maintainer), I'm seeing when building anything depending on vulkan-loader using pkgconfig.
Thanks for the ping! Drafted Please confirm that this solves the problem.


Reported via email by a Nix user without a GitHub account. Build fines. In the attempt to build GNU octave for aarch64 darwin. Maintainer information:
I would suggest opening an issue but I guess that's not an option.
Perhaps, but it seems peculiar that the user "is not able to compile a simple test program" - as if there's a bug in our compiler . Related issues: Perhaps the user should try this edit to Nixpkgs: So even on Darwin the compiler that will be used will be gcc, to play nicely with gfortran.
The suggestion to use is good; I think couldn't possibly work otherwise. Beyond that, I have no idea.
But doesn't it work on x86_64 Darwin?
perhaps you could help us - does arpack and/or octave build currently on x8664 Darwin?
Any news here? This also affects other derivations (e.g. openspecfun). arpack does build on x86_64-darwin.
This issue should be renamed "gfortran broken on aarch64-darwin", as it is not specific to arpack:
See – but we should really fix this in gfortran, rather than requiring every derivation to copy/paste the line.
cc To summarize, we should set: In stdenv somehow.. Perhaps this should go here:
We probably don't want to globally disable stack protector support, though; this only affects gfortran. Seems like we'd want to have the cc-wrapper for gfortran (on aarch64-darwin) to never inject the options, either through a option, or in the cc- script itself. Actually fixing whatever goes wrong in the toolchain would be preferable, of course.
Here's a proposal:


Project description "Linux/macOS media player based on GStreamer and GTK" gstreamer rust Metadata homepage URL: source URL: license: MIT platforms: linux
I tried to package glide and it's building successfully but the timestamps and the progress bar at the bottom aren't working. My progress is at if someone else is willing to look into it but I'm not sure how to debug this.
Nice, thanks Sadly, I think you made it further than me: heh
I couldn't really find anything about
I pulled your branch but it doesn't launch for me. Just the .
Stuck here I think maybe updating the registry would help, but I'd better waiting for the next release if possible...


Project description So basically it is a simple ssh config manager. Metadata homepage URL: source URL: license: Apache-2.0 platforms:


pivy fails to build due to being unable to find some files Steps to reproduce the behavior: try to build pivy from nixpkgs HEAD


Describe the bug Since the recent commit ( ledger fails to build on Darwin. To Reproduce or similar. Additional context Add any other context about the problem here. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(steve): channels(root): nixpkgs: Maintainer information:
if you don't need python. do you mind trying to build it with it off?
the error you're seeing is that a header from package isn't able to be found. I don't have a darwin machine to see why these two are different
Thanks. I don't need to work around it particularly, more interested in identifying a fix. I think the issue is that it's somehow picking up the system python: so probably some of the handling is broken, and indeed there are a few suspicious portions in the output I pasted, e.g. and subsequently:
I got the same cmake warnings, upstream needs to update some of their files. I'm not familiar enough with nix-darwin to have it NOT pull in system python


Steps to reproduce the behavior: package 'grapejuice' Fixed by adding to propagatedBuildInputs Please run and paste the result.


Describe the bug A clear and concise description of what the bug is. mitmproxy tests broken on unstable. To Reproduce Steps to reproduce the behavior: nix-env -iA nixos-unstable.mitmproxy Additional context Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
thank you for submitting this, ill get it fixed


The version of AWSCLI in master is 1.32.58. This version requires botocore==1.34.58, however the version of botocore in master is 1.34.87 AWSCli botocore pin: This started happening after changing my to Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This should be fixed by , which syncs botocore, awscli, and boto3.


Using with and any packages depending on results in the following error: However, packages not depending on work fine, as does running on packages depending on and entering the manually. Steps to reproduce the behavior: the following flake: and that fails while succeeds. To be dropped in a with packages depending on . <!-- 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.
While I could reproduce your case with nixos-22.05, on master, in both cases, I get dropped to a python shell, not a hy shell. Here is a version of your flake that overrides the so that you land in a hy repl. But I think it would be better to put this into eventually.
I'd done that with , but hadn't thought to do it with ; it works! Thanks! Should one of us submit a pull request?
Or perhaps would want to?
Not really, if you want to open a PR I can review/merge.
Sorry, the instructions for contributing are a little confusing to me; could someone give me a summary of steps I need to take?
Also, I just realized I don't know how to merge this with ...
And my own problem was fixed after changing the way the flake apps were made; thanks for all the help!


On the , quite a few jobs are failing because libomxil-bellagio fails to build (, for an example). cc (as the package maintainer)
Copy-paste from IRC (for the record)


I'm not really sure why this would happen or how to go about dealing with this. Any tips?
(triage) still a problem?
Unsure, I don't use nix on my mac anymore.
This was a coreutil, right? If so, it’s probably fixed by now.
Probably safe to assume so.
I'm actually hitting the same thing right now.


Describe the bug Trying to run mutagen results in an error: The mutagen- which is supposed to have binaries for different platforms is missing. To Reproduce mutagen a mutagen session Metadata system: host os: multi-user?: sandbox: version: channels(alex): channels(root): nixpkgs: Maintainer information:
Hey, author of Mutagen here, super excited to see a Nix package for it! I just thought I'd mention that the bundle currently needs to be placed in the same directory as the executable itself. This is something I've been meaning to improve for a while now (by allowing it to be put in a directory), but I haven't had a chance to implement it yet, mostly because it's a little tricky to get right with package managers like Homebrew that symlink binaries into a different target location. I'm not very familiar with Nix, but I'm sure that it would prefer to avoid having this tarball in the directory. So I'm happy to push ahead on trying to support the -based layout if that's helpful here (or perhaps something more general if NixOS prefers a different layout).
cc
A quick update: Mutagen v0.11.2 and later support looking for the bundle in a directory (assuming a Filesystem Hierarchy Standard layout), so a layout of the form: should now work (in addition to the option of installing the bundle directly alongside the executable). This also works in a -style setup where the binary is symlinked into a larger directory.
Thanks! Is the available for direct download?
The bundle ships as part of the official releases (e.g. in the ). It needs to be kept in sync with the version of the binary being installed, but it should work just fine with a binary built locally, so long as the versions are the same (to the patch level). The bundle can also be built locally, but doing so requires running a custom script inside the Mutagen source tree that performs the necessary cross-compilation (this bundle is a collection of cross-compiled binaries that get injected to remote systems to facilitate file synchronization and network forwarding). I'm not sure the best way of handling that in the context of the NixOS packaging system. Perhaps there are some custom hooks available?


At the moment, this script doesn't have a flag for building just this bundle (it will only be built as part of a full set of release bundles for all platforms), though I suppose such a flag could be . One of the downsides of doing the cross-compilation locally on Linux (or any non-macOS system) is that the C FFI bindings needed for efficient filesystem watching on macOS won't be available, so file synchronization between NixOS systems and macOS systems will suffer. That might not be a huge loss, though. This is why the Homebrew packages just use the official pre-built release bundles as their "source code." It's a bit non-idiomatic, but it saves on local build times and allows for cross-compiled binaries with C FFI support. Of course, I totally understand if that doesn't work with the NixOS package philosophy, in which case just building the bundle locally is probably the best bet.
As a reference point, here's what the Mutagen Homebrew formula looks like:
I agree, setting up the cross-compilation would not be trivial so the nix derivation must download the prebuilt agents binaries from somewhere while still being able to build the agent on the platform it is running on. I see three possibilities: (No changes on the mutagen side). Nix derivation downloads the full mutagen release and extracts . the version number to the and add it to the downloads. The nix derivation would just download it. the individual downloads for the agents similarly to for all the platforms and have the nix derivation create the itself. That way it would be very easy to even parametrize it to only download the agents the user wants and the nix derivation would supply the binary for the platform it is running on.
All three options are reasonable ideas, though I would prefer to avoid (3) since it would significantly increase the number of assets attached to each GitHub release (which is probably already too high). The individual agent binaries for linux/amd64 that you mentioned are sort of a special case for some experimental container integration features, so I'd prefer to avoid expanding them to every platform.


I also don't know if many users want to go through the trouble of filtering the remote platform support that they want, though if that's something users are interested in then I'm certainly willing to try to support that.<sup1</supOption (2) is possible without too much effort, though I don't think it adds much value over option (1). Additionally, if option (1) is already going to be used to download the release bundle, it might as well just pull the binary out of the release bundle as well and save the complexity of a local build. In any case, the current package should have the build of removed since it won't really be of any use. Let me know if option (1) will work and if there's anything I can do to help. <sup1</supI think a better long-term solution is to provide two download variants: a "full" agent bundle that includes all platforms and a "slim" agent bundle that just includes commonly used platforms. P.S. Thanks for helping to support this!
Given the usual problems with pre-compiled binaries, reading the discussion above I thought we might have another problem : nixos needing its own agent in mutagen- But to my surprise, the amd64 binaries work on nixos without the need to patch the ELF interpreter or anything else, it seems that everything is self-contained with no external dependencies. So why not make a binary installation directly?
I can open a brand new issue about this, but wanted to get a quick check from you about a problem I'm having with this. I'm getting the following when extracting an agent: The libexec path appears to be appended to the directory for some reason. I don't know if this is an issue w/ nixpkgs or mutagen but would be happy to help track it down and (maybe) fix it. So, it looks like the file is there, but the search path is treating the absolute path for as if it was relative to the path. I suspect it has to do with the liberal usage of symlinks in nix tripping something up. I'm just too new to golang and nix to have any idea how to fix this.
Hey I believe this is fixed in Mutagen (thanks to who reported it in mutagen-io/mutagen and fixed it in mutagen-io/mutagen).


It looks like the corresponding NixOS package needs to be updated — we're currently at Mutagen v0.16.4. If you want to open a NixOS/nixpkgs PR for that, that's probably the way to go. Feel free to @ mention me in that PR, otherwise I'll see if I can find some time to open it during this week.
Thanks for the information. :) I spent some time yesterday trying to get my local system running on Mutagen 0.16.4. I got it working in terms of correctly locating the agents, but I noted in the PR that it isn't working for docker containers because Mutagen running as root does not seem to be able to find Docker installed via nix. I'm happy to move any additional discussion to .


I never really noticed this until today, but apparently the discord task bar icon (if you have one, I am on KDE) is supposed to have a notification badge, I have included a screenshot. The discord task bar icon should include a badge for the number of unread notifications ! Today I was setting up a system for someone else who was new to Linux, I installed Discord via flatpak, and then they asked me about the badge (since it is present on Windows but not on the ). From a little searching, it seems that Discord needs to ba available in the system, so on Kubuntu this was fixed by doing . Since is already in , it might just be a matter of adding it to the ?
Huh. I don't think I ever knew one was supposed to be there either. I see an unread indicator (red circle in the top corner, no number), so that works fine, but I don't think I've ever seen a number. Assuming that would be all it would take, sounds like a pretty simple PR that would be a good addition.
I have made a clone of and it does seem that all that was need was to add the library to . I found it to be a bit ugly myself since I had over 1000 unread notifications, and it seems disabling it is only possible outside the application. On for example, you have to go to and tick off "Show notification badges". Running the current from afterwords does not remove the badges, it only freezes them in place, as in marking notifications as read will not update the number, so this is also cached somewhere outside , meaning this couldn't be a toggleable functionality via an .


Recently variety stops working on NixOS. Pictures are downloaded well but the wallpaper can't be changed and can only be set in system setting. That's because of the hardcoded shebang which is taken from on the first installation. So when the bash is updated the script can't find it. It should be set as something like . Not sure if this is a nixos bug. Steps to reproduce the behavior: variety bash It works after the bash update. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
IIRC now we use . I am patching it now.


When attempting to add a Vim plugin, fails. It updates without error. I believe previous developers have this feature enabled in their system/user Nix configuration.


We should mention in nixos manual Chapter 6 that options can be dicovered with and It will help newbs learn how to discover packages more easily. As a new user, I was sticking everything I wanted inside of the array, and I didn't not realize that is a better route to take because it configures many things automatically. For example, results in also being installed as well as features enabled, while writing does not. This will be helpful to new users.
This issue has been mentioned on NixOS Discourse. There might be relevant details there: