We need to standardize and document this. The current contents in nixpkgs manual seems obsolete (section 4.2). I suggest at least these should be standardized: preference for usage of <codelib.licenses.*</codeinstead of the choice from some strings, meta.licenses semantics (any license at your choice, or different parts under different licenses?).
:+1:
I'd go for a documentation changes with pull request and point people to read that.
Is someone working on this? Would be good to get into (which also will presumably have with its new way of handling attributes)
First bullet is addressed in . For more complicated cases when it's not all one single license, I don't know how deep should we go. Choice from multiple licenses is probably the most common and using nix lists for that is suggestive, but it occasionally happens that multiple licenses need to be complied to at once (different files/parts under different licenses) or even more complex combinations. I don't see any possibility of "smooth extension" in such directions.
Solutions I encountered: Debian has per-file license granularity , and offers some RDF-based solution.
what's missing here?
I see the first bullet was fixed in . Attribute is still unspecified, but IMHO describing the licensing precisely in all cases is out of the scope of nixpkgs.
BTW, thanks for the notification. I forget to pass through old open issues.


Describe the bug libbladeRF fails to build on the nixos-unstable channel and latest master: Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Cannot reproduce this in master. I am on . Was this fixed in ?
I have just tried on , here is a full log:
Can also confirm that the build fails on .
This appears to me a genuine error in the source. Live bladerf1.c:841 (and also bladerf2.c:283) reference , but it should be . With , we stop the build on purpose. Luckily the typo is not of further consequence, since both values are numerically the same (both zero). I will try to report this to upstream.
Oh nice, this has already been fixed in upstream master (in from last May to be precise), but there isn't yet a new release containing a fix. I'll prepare a pull request cherrypicking this patch. Be aware though that I cannot test libbladeRF (in fact I don't even know what it is about :-)).
maybe also add . This options is meant for development where there is control over the compiler, but in nixpkgs we want to update gcc without breaking half the packages due to warnings.
I see, thank you for the suggestion! Generally I'm in favor of , but your argument is quite reasonable. I'll force-push in a second.


After installing a fresh system with the following configuration: the file is not created, hence wpasupplicant fails to start with the following error: nixpkgs
I don't know the logic of , but I think you're supposed to provide the file yourself. I guess it could be ed if wpa_supplicant fails without one.
You can do
That probably wouldn't work due to permissions. EDIT: wpa_supplicant is still running as root, so it should work.
Fixed in


When I try and install the package it fails because the installation procedure iterates over all the test-short executable's dependencies and is unable to locate the required It seems this dependency comes from the test-short binary being linked against the that comes with . This has a record that says it is This results in test-short requiring the library The only provides a though, so the installation then explodes when it tries to loop over the dependencies of the binary it just created and finds it can't find It is not clear to me if this would be considered an issue with or . Two possibly fixes are to for before , or a step to to provide the symlink. Try and install package System: Nix version: Nixpkgs version: Sandboxing enabled:
I decided to give the latest unstable a try as well. It dies during the as it cannot find at all anymore. Looking through the source it looks like the recent commit stripped out all together. I guess that makes (1) above the correct solution.
forgot to CC relevant people on this issue with (should be an easy fix -- just add to the )


<!-- 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: minio <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 2022-05-08 desired version: 2022-07-15 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.


When flexget starts up, it crashes with this error: . The version of transmission-rpc in nixpkgs is currently 7.x.x. Steps to reproduce the behavior: a flexget config that uses transmission. . Flexget runs normally. (transmission-rpc) (flexget) Please run and paste the result.
Upstream flexget has some discussion about upgrading to transmission-rpc v7:
Workaround: the last transmission-rpc 4 version in nixpkgs to transmission-rpc-4.nix: it to an overlay


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


I ran gimp from terminal and noticed that it prints out following warnings: I don't see anything clearly broken in the UI, but just thought that probably this is some issue that could be fixed. Run Gimp from a terminal. Please run and paste the results.
Oh, and in case it makes a difference, I'm not running GNOME but i3+none.
Try installing , GTK 2 is weird.
Thanks for the suggestion. I still get the warnings: I also noticed it warns about interpreters. Maybe those should be fixed too? I have some issues with one plugin, not sure if that interpreter issue is related to that.
Yeah, you would need to install it globally, so that GTK can find it under . Alternately, adding it to env var should also work.
Thanks, that fixed the theme issue! So maybe that should be as a propagated build input for gimp? The interpreter warnings are still there. Should I open another issue for those?
Propagating will not do anything. You would need to add it to the wrapper is citrix does.
Yeah, please open a new issue for the interpreters.
Thanks! I made a pull request. Seems to fix the issue.


The NixOS manual's section on Emacs has a . It states which is at the very least misleading and potentially confusing since the docbook migration. Either remove these references to the manual being in docbook, or remove the section in its entirety, since (with the completion of the docbook migration) it seems unclear what relevance xml editing in emacs has to NixOS at all, and people interested in the topic will presumably look to other resources elsewhere (e.g. ). (I'd open a PR for either, but am unsure which one to prefer, hence this issue) <!-- make sure this issue is not redundant or obsolete --- [x] checked [latest Nixpkgs manual] ([source][nixpkgs-source]) and [latest NixOS manual] ([source][nixos-source]) [x] checked [open documentation issues] for possible duplicates [x] checked [open documentation pull requests] for possible solutions [latest Nixpkgs manual]: [latest NixOS manual]: [nixpkgs-source]: [nixos-source]: [open documentation issues]: [open documentation pull requests]:


Package name: Latest released version: 5.2.0 Current version on the unstable channel: 5.2.0 Current version on the stable/release channel: 5.2.0 Notify maintainers Note for maintainers: Please tag this issue in your PR.
Pending on


The latest heisenbridge version doesn't build on nixpkgs-unstable (). Steps to reproduce the behavior: error: This repro's on darwin and on linux, using this nixpkgs revision. I believe this may be due to , where mautrix was bumped to version 0.11.3, but heisenbridge requires 0.10.x. build success. Please run and paste the result. Maintainer information:
The requirement is adjusted in heisenbridge 1.7.0:


I noticed my locatedb hasn't been updated in ~34 days. The is failing. Here's the full output: And for some reason, some of the log lines are missing from that, so here's the systemctl status output for that service: Relevant lines:
I can't find any trace of (with a ), at least on master and the latest unstable channel. What service do you mean?
Argh, sorry, I read it (notice ). Sorry, sleepy.
has problems on my unstable NixOS system too:
I confirm the problem
I have the same problem and see this in systemd's journal: The systemd service seems to have been defined like this: So it seems that is not being correctly specified.
This is what I wanted to write: However, this is still not fixed: returns (after a call to (which has exit status 0)) So, this is not fixed in 16.03. Please reopen. If is not meant to be callable as root, then should be a wrapper of some kind which would say However, I think pretty much anyone with some Linux experience wants to be able to easily build a new index when they want and has historically been the UI/API to do that. Changing that, if that was the intention, is a rather ill-conceived idea.
So, is this supposed to be working? I am still getting the same error.
This issue was about the systemd service failing with a / , it wasn't about not being able to find the file, even after running manually (I would file a separate issue for that). is the error you are still getting the failure in the systemd service? If so, which release / branch / channel are you running?
I still get the same error "read-only filesystem." I suspect this is because the only service I have running that wants to create /var/cache is the one for updatedb, which still doesn't have write permissions to /var to do so. Manually creating /var/cache as root fixes the problem.
Just installed nixos. I to get this errror. Is there any fix for this.?


Same here on a fresh install as root: nixos /nix/store/w1gzi0342kiha08pym7qj09w09ffzhj4-findutils-4.6.0/bin/updatedb: line 323: /nix/store/w1gzi0342kiha08pym7qj09w09ffzhj4-findutils-4.6.0/var/locatedb.n: Read-only file system
just installed 16.09 and I'm getting the same, Read-only file system on updatedb
VERSION="16.09.1836. (Flounder)" nix-env (Nix) 1.11.7 works fine if updatedb is used with --output and later locate is used with --database when invoked by root in a login shell, updatedb tries to write to: /nix/store/95vfigaqdg8jg5bk961k1x06j86p5fh0-findutils-4.6.0/var/locatedb.n: Read-only file system when invoked by user in a login shell, updatedb tries to write to: /nix/store/95vfigaqdg8jg5bk961k1x06j86p5fh0-findutils-4.6.0/var/locatedb.n: Read-only file system this path comes from updatedb shell script which was modified in nix (this line is different in the gnu sources): 186: ${LOCATE_DB=/nix/store/95vfigaqdg8jg5bk961k1x06j86p5fh0-findutils-4.6.0/var/locatedb} systemd service seems to be updating the db: but doesn't have access to some dirs: I'm not surprised it doesn't have access to home, but shouldn't the service be able to list /nix/store files? There are no error messages for /nix/store: the ticket is about service failing to write to /var/cache/locatedb, but it works fine on 16.09, so I think it can be closed.


I see two other problems though: update-locatedb service not being able to process /nix/store running updatedb on the cli tries to write to /nix/store which is a read-only file system
is caused by an option, now named , which contains "/nix/store" by default, the issue is closed already. is resolved by merged , the issue can be closed. is about using updatedb from cli and missing /var/cache directory and needs a decision.


The v8 derivation used by plv8 fails to link: cc Using . Hydra job: Maintainer information:
According to it should be fixed by ;a=commit;h=.


When booting up SABnzbd having done an update recently (5min ago at time of writing), I'm getting the following errors: ! Steps to reproduce the behavior: your on NixOS using current unstable, include the following: . I expected it to pick up SABCtools 7.1.2, but it got 7.0.2 instead. See above N/a
Opened a PR to fix this and provide better testing.
:+1: thanks


Project description It's a new version of Grafana Agent in Flow mode, but based on the OpenTelemetry Collector instead of the custom internals it was previously built on. Metadata homepage URL: source URL: license: Apache 2.0 platforms: linux and darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


GitLab service do not start with configuration . TLDR should be used instead of when creating config file. There is an error message in the log: To Reproduce Steps to reproduce the behavior: to Expected behavior GitLab service should be running after switching to new configuration. Additional context The file mentioned in the error: Note the missing value for . The problem seems to be at , generates empty string: Notify maintainers Metadata Maintainer information:
Thank you for reporting this! I've fixed this on master and will backport the fix to 20.03 and 19.09.


Package name: raysession Latest released version: 0.14.2 Current version on the unstable channel: 0.13.1 Current version on the stable/release channel: 0.13.1 Notify maintainers Note for maintainers: Please tag this issue in your PR.
Update PR:


When "set as default browser" is clicked from within Firefox, it places a custom .desktop file in , and points to this from in the same directory. This file launches Firefox without the wrapper when it's opened using xdg-open. The result is that if xdg-open is used when no Firefox window exists, it will be opened without environment variables set correctly, and without plugins.
This is a great example why wrappers are error prone.
Is there a easy way to fix this? I don't see one
The easy way is to use a non-absolute path in the .desktop file, i.e. . This also ensures that after an upgrade, the new Firefox will be invoked.
This .desktop file is generated by Firefox when "set as default browser" is clicked - it's not one of nixpkgs's .desktop files. That'd involve a patch (which would have to be kept up to date with each Firefox release).
Right, shouldn't be hard to do.
Testing a patch now...
I can't see the patch anywhere -- did it work?
Chromium .desktop file includes and suffers from the same problem.
This is handled and detected with mimetypes.
Would be really nice to fix this one, any takers?
I think I have solved it for Firefox; as for Chromium — apparently it is non-trivial to test for me (StumpWM, not a DE)
There's still no obvious way to set the default browser that I can find - anyone know what the status is here?
A possibly reasonable option in the case of Firefox would be to disable the default browser check using the preferences file, and write a custom dialog for selecting the default browser in the wrapper itself, a very rough basis being: According to a google, similar should work for Chrome/Chromium, except passing instead of messing with config files. Opinions?
Is there no way to trick firefox into thinking its executable name is the wrapper ?
Yes: but this needs some testing, and it affects many browsers.
I fixed the wrapper to work with (), but we get another issue. When we update firefox, we end up with a different /nix path, which firefox considers as a different browser. If you restart firefox (for example when installing addons) then you get the not-your-default-browser" warning. Investaigating MOZAPPLAUNCHER as solution, but I start to think that may be the most general solution.


Package name: senpai Latest released version: 0.3.0 <!-- Search your package here: --- Current version on the unstable channel: 0.2.0 Current version on the stable/release channel: 0.2.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. Has new maintainer There are issues where the pulled dependencies don’t work with the 1.16 specified version. + (as well as 19) created a new batch of errors I decided to give up on. I did ask about in on their SourceHut issue tracker: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


The package has been . Trying to install results in the following error: Why was the package marked as broken? Is there a way to help fix it? System: Nix version: Nixpkgs version:
According to the project homepage it requires a different version of the vte library: If you package this one and add it as a dependency the package should work again.
Thanks for the response . Could you help understand the reasoning behind the commit that marked it as broken? Was the problem that was being packaged with the wrong dependency?
The dependency it needs is not in NixPkgs, so it has to be packaged and nobody cared enough to do it.
We had the patched vte under gnome-3.20, but 3.20 was now removed whole without porting that to the vte in 3.22. EDIT: refs and .
I've wasted hours trying to fix building the special vte library, you may try to continue: This fails with: I don't see marking one package broken preferable to keeping the whole gnome-3.20 in tree, sadly. Please open a pull request if you manage to succeed, but I don't see myself wasting more time on this otherwise soon.
I fixed the errors you found during compilation and submitted a PR to upstream VTE. As the changes may take a while to propagate down into vte-ng, I them as patches to the vte-ng package, which is now used to compile termite.


Package name: feishin Latest released version: 0.7.1 <!-- Search your package here: --- Current version on the unstable channel: 0.6.1 Current version on the stable/release channel: 0.5.1 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
thanks for reporting this, just noticed I hadn't subscribed to release notifications. Shouldn't miss any from now on :) Fixed by (awaiting review).


Project description A markdown-like text editor designed for writing novels and larger projects of many smaller plain text documents. Metadata homepage URL: source URL: license: gpl3 platforms: linux, win, darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Describe the bug nix-gitignore lets the hash of the source change when some file changes in .git (notably .git/FETCHHEAD) To Reproduce Steps to reproduce the behavior: a git repo in a as follows: Expected behavior Hash does not change Additional context I intend to open a PR to fix this soon Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(symphorien): channels(foo): nixpkgs: Maintainer information:


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


While going through the documentation I came about a that explicitly requires matplotlib with the TkAgg backend. I tried to generate a nix-shell with matplotlib and tcl/tk and tkinter. However, the script does not execute and instead I get the following error message: In a simplified form: Start nix-shell:Start Python:Try to import matplotlib, configure the backend, and import parts of Tk:Observe the following error message:System: NixPkgs on openSuse 13.2 (Harlequin) (x86_64) Nix version: nix-env (Nix) 1.10 Nixpkgs version: "16.09pre83147." Matplotlib Maintainer:
Judging from the matplotlib expression we don't build against tcl/tk.
I made an attempt to build matplotlib against tcl/tk with the following patch: Unfortunately, compilation fails with the following error message: The linker cannot find the tcl/tk libraries. The linker flags are quite off: They include and the like. This must be due to matplotlib's own build script, as no such flags are set in my bash environment and is executed with the flag anyway.


CoolerControl does not detect Nvidia GPU when enabled via options Steps to reproduce the behavior: GPU with proprietary drivers (version 555, but might not matter) spits out error about missing and CoolerControl to detect Nvidia GPU ! Logging output: If I manually stop the systemd process and start it detects the requested binaries correctly, which makes me think that the coolercontrold binary just doesn't search the correct paths. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The tools should be on PATH if you check the generated service file. And restarting the daemon would support that I think, since it shouldn't pick up any new paths from the env AFAIU. So might not like whatever state your system is in whenever first launches? I sadly don't have any nvidia system to test this with… I think if you try something like this you could delay the service startup to check if the above guess is correct? (Or override the package with an overlay and patch it into the service that way if this doesn't work the way I think it does)
Restarting the service does not work, as that throws out the same identical error. After adding that to my config, rebuilding and restarting the service, I get this output: which looks like sleep succeeded, but not sure how that would help so I did this instead: Which I either did wrong, but it seems to print the GPU fine? But that made me realize one difference. I am on beta drivers, but as per your code block, you pull in the stable ones... Could that be the distinguishing factor? In which case, maybe it might be better if it pulled in the field rather than hardcode to stable drivers?
Oh sorry, I thought that read "restart coolercontrold". Maybe. Likely.


Steps to reproduce the behavior: tarsnapper on nixos-24.05 @ system: host os: multi-user?: sandbox: version: channels(root): channels(asymmetric): nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Build . Because this hash was updated not long ago by , I think the package may still need some refactor? We may also expect to get everything settled. <!-- 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. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Huh, weird. When I wrote that hash worked fine. I wonder what changed?
Yes I was wondering about the same thing because I knew you updated that hash not long ago. Does that hash depend on any online resources that may change or on other packages? If not, then this package may have some obscure reproducibility issues. This package is so complex that I cannot see what it is doing there at glances.
Yes, but it is my understanding that its pulling resources that are hash-fixed in bazel-land, so iiuc they shouldn't change unless changes... but then again clearly i have some misunderstanding of the behavior here
builds fine for me on .
Is this issue still reproducible for you?
Yes. I just tested on master branch at commit . The exact same error.
Are you using any overlays? Have you set any nixpkgs flags?
I have a local clone of nixpkgs at , and I ran the command Does it depend on my nixos system config?
iirc it will depend on eg but i'm not sure about the nixos system config. What commit of nixpkgs are you on? Does it reproduce on the latest master?
I don't have . I said I was on , which is the latest.
Latest (at the time of writing) is does building on that commit work for you?
That commit does not build either.
Hi, I'm also having the same issue with same hash mismatch. I tested the build on two different systems. If you happen to have a system in which the build runs fine, would you mind sharing the output of the derivation: so I can diff it? I could also send you mine.


Should be fixed by
Fixed by
Hi everyone, sorry to reactivate this issue but if I check out the current master branch and run , I end up with the same error as above (just with different hashes). Can anyone reproduce this behaviour?
what hashes are you seeing now?
I can rebuild the package just fine...
! These are the hashes I get after running on the current master (). I am puzzled by the fact that this exact commands builds fine for . My expectation would have been that the behaviour should be the same if we are on the same platform (I am on x86_64-linux). Do you have an idea how we can dig deeper into this?
I also just stumbled upon this issue and I do get the exact same hash mismatch as :
Well, my only hypothesis is that the bazel dependencies derivation is nothing more than non-deterministic :'(
Does this still build for you? If it does I can offer to send you an archive of my jaxlib with the changed hash so you can run a diff to find out what is wrong. (Or the other way round ofc)
Yes, I have tried once again right now and it works fine... Sure, Send me what you have :)
Alright, I've updated today and will build against nixpkgs . My machine will probably take some time to completely build it though, so I'll post back once it's done.
I'm getting a similar problem when I'm trying to compile . The commit is from the branch. The commit was the only commit I found after going through multiple issues and threads which worked on my system. I have also observed this issue when compiling (), so the issue of build failures due to bazel hash mismatch isn't just limited to . So, I don't think that this issue has been properly resolved yet.
I'm not sure if this is helpful--or noise!--but I just hit a similar issue with (see below for output, repro, and system info).
Btw we're tracking the hash issues in .


systemd seems to use the term split-usr to refer to an attribute of a system, where: is a mount point. is not mounted "at boot". Since systemd v248, support for a split-usr system is deprecated: While don't seem to mention a formal removal of support of split-usr, it seems that . According to : It seems that if is a mount point, this unit calls with on it, regardless of whether it is already mounted — making the assumption that it had already been mounted "at boot". When I installed my first NixOS on my workstation, I made a filesystem for each path under . This let me customize options per directory as I wished, both at install and later on. ZFS's sharing of storage space between filesystems in the same zpool takes the cost out of being "generous" with the number of filesystems. I didn't know that is merely that happens to be generated at boot. I also didn't know that systemd deprecated split-usr. So I did not mark as . The system built successfully and booted successfully. Except for an error in the logs: The failure seems to be due to the attempt to remount using with the option a non-mounted filesystem — . is later successfully mounted along with the rest of the filesystems. Since systemd seems to expect that if is a mount point it would have already been mounted "at boot", I would expect NixOS to: 's to by default, . to build when 's is (that could be ). Understanding this error took around three hours of collaborative debugging with the tremendous help of A workaround is to set for , or to not have a mount point at all. The suggested solution (expected behavior) is with the goal of sparing all future users an investigation of this error. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Not sure who to mention. Please ignore if you no longer wish to be involved. If you happen to know who should be mentioned here and is not, please comment mentioning them. Please run and paste the result. Maintainer information:
gentoo notes this in their wiki as well
ping a couple people who might care: and probably others.


Describe the issue In the opencv build for mac, why is off by default? What needs to be done to enable it? (either development work, dependencies that aren't yet nixpkgs, or, if possible, how to manually override the argument and simply set to ) To Reproduce See above Expected behavior There may be a good reason it's disabled, so I can't say that I'd expect videoio to be enabled by default. Notify maintainers Metadata Please run and paste the result. Maintainer information:
It was removed here 15 months ago: See this PR: due to apple removing most of QTkit in 10.12 Brew does not use this option. You can use an overlay or a nixpkgs checkout with this patch to build with videoio The following will drop you into a nix-shell with the patched opencv, which you can use for testing. I'm not sure if it builds. FWIW, I get the following build failure which indicates the upstream issue might not be resolved, or we're missing some thing in our derivation.
I was originally attempting to use an overlay. After getting nowhere, I made a , which is what redirected me to the nix build. So if you want to help me close that thread, that'd be awesome cause both me and the person that helped me still don't know how to access/change the from an overlay.


RStudio () fails to build from nixpkgs master with a 404 on downloading sources. Steps to reproduce the behavior: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Maintainer information:


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


Describe the bug After electron 12 came out, adding in home-manager succeeds, but trying to start the app fails mentioning a missing javascript function from an older version of electron. To Reproduce Steps to reproduce the behavior: to home-manager's app from terminal with Expected behavior Expected the application start as it had before. Additional context I was able to get it working locally by providing an overlay to home-manager: I would have created a PR myself, but I'm still new to nix and not sure entirely how to require a different electron version in the package derivation. Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(jon): nixpkgs: Maintainer information:
thanks for catching this! Just fixed in the PR above.


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


Steps to reproduce the behavior: So when I wanted to dig deeper, with I'm trying to recreate with a toolchain that's on hydra so I don't have to compile GCC for myself (twice!) Please run and paste the result. In particular, is pinned to:
Diff-ing the two files, I get: I suspect the problem comes from in the that isn't present in the . I wonder why so many differences are present though? I've confirmed this by adding to the derivation, but again why are the differences present? Even if they have been helpful to track this down
I suspect there were impurities in your environment but the difference is still weird. I don't know why would be there but not Adding to the mingw build in


Fail to connect to a l2tp + ipsec VPN after putting in all information. This happens on both Latest Gnome ISO and after NixOS installation. Message received on Gnome Desktop: Connection Failed Activation of network connection failed Steps to reproduce the behavior: Live Gnome ISO. l2tp + ipsec (strongswan) details in NetworkManager. on VPN connection. There are several fixes listed in this issue I was able to fix the problem by creating the file AFTER creating the connection and failing to connect once. (I also created the file BEFORE creating the connection, but that did not fix the issue.) After successfully connecting, this was content of file include The following is the failure output from journalctl From ISO system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
I was also having issues and tried the above suggested by and was able to connect only after a failed connection !
This seems to fix the bug May we have this to the default package?
Fix in


Phew, a big title! Trying to write down as much as I can before I forget. First, the last part: If doesn't exist, will show failing like: fixes this problem. NixOS should probably create this file. I'm not sure if this file should be writable or not, when it exists, I have only ever seen it contain: I don't know what writes that there. Now for can't edit L2TP VPNs, but (GUI) can, even though nm-applet doesn't work under sway. If you see this in the system logs: try enabling "legacy proposals" in nm-connection-editor's IPSec Settings and try again. system: host os: multi-user?: sandbox: version: channels(root): channels(grahamc): nixpkgs:
Side note, how do I know for sure fixes it? I erased my dozens of times nailing it down, reproducing it to exactly this.
I think the strongswan module creates that file and the actual L2TP plugin appends that line to this file.
Nice find that the strongswan module does create that file! I don't have the strongswan module enabled, it seems something else in the stack would periodically create this file?
I'm not sure what does create it eventually, but it appears the plugin expects the file to exist so we should just do exactly that. It doesn't help that it expects it to be mutable, so maybe we can handle this within the NM module to add more secrets. Though it would probably duplicate what the strongswan module does.
^ does this make sense to you?
So I just remembered about this module I have: maybe instead we should have the networkmanager do when it detects the l2tp plugin but I am not sure how to do that. Maybe we would need to introduce a new option in networkmanager to add the nm-l2tp plugin and create the file. I tend to connect physically to the private network and only as a last resort rely to nm-l2tp since it tends to not work regularly and I am not sure if it's blocked by the network or some l2tp breakage.


We could add an option to networkmanager in the same way there's one for strongswan there
Was there ever any follow up on :
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
i guess, it's still relevant, maybe not so urgent. this helped me big time:
I marked this as stale due to inactivity. →
I just ran into this on 21.05. Seeing a log like this: <details<summaryjournalctl log when starting vpn</summary<pre<codecharon[2059]: 00[CFG] loading ca certificates from '/nix/store/va01sq5aqg6p7yakvpg2zlnsdj4pm9dj-strongswan-5.8.1/etc/ipsec.d/cacerts' charon[2059]: 00[CFG] loading aa certificates from '/nix/store/va01sq5aqg6p7yakvpg2zlnsdj4pm9dj-strongswan-5.8.1/etc/ipsec.d/aacerts' charon[2059]: 00[CFG] loading ocsp signer certificates from '/nix/store/va01sq5aqg6p7yakvpg2zlnsdj4pm9dj-strongswan-5.8.1/etc/ipsec.


d/ocspcerts' charon[2059]: 00[CFG] loading attribute certificates from '/nix/store/va01sq5aqg6p7yakvpg2zlnsdj4pm9dj-strongswan-5.8.1/etc/ipsec.d/acerts' charon[2059]: 00[CFG] loading crls from '/nix/store/va01sq5aqg6p7yakvpg2zlnsdj4pm9dj-strongswan-5.8.1/etc/ipsec.d/crls' charon[2059]: 00[CFG] loading secrets from '/nix/store/va01sq5aqg6p7yakvpg2zlnsdj4pm9dj-strongswan-5.8.1/etc/ipsec.secrets' charon[2059]: 00[CFG] expanding file expression '/etc/ipsec.secrets' failed charon[2059]: 00[CFG] opening triplet file /nix/store/va01sq5aqg6p7yakvpg2zlnsdj4pm9dj-strongswan- failed: No such file or directory charon[2059]: 00[CFG] loaded 0 RADIUS server configurations charon[2059]: 00[CFG] no script for ext-auth script defined,


disabled charon[2059]: 00[LIB] loaded plugins: charon unbound pkcs11 aesni aes des rc2 sha2 sha1 md5 mgf1 rdrand random nonce x509 revocation constraints acert pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey dnscert pem openssl af-alg fips-prf gmp curve25519 chapoly xcbc cmac hmac curl attr kernel-netlink resolve socket-default connmark forecast farp stroke vici updown eap-identity eap-sim eap-sim-pcsc eap-aka eap-aka-3gpp2 eap-simaka-pseudonym eap-simaka-reauth eap-md5 eap-gtc eap-mschapv2 eap-radius xauth-generic xauth-eap xauth-pam dhcp counters charon[2059]: 00[JOB] spawning 16 worker threads ipsecstarter[2058]: charon (2059) started after 660 ms charon[2059]: 11[CFG] received stroke: add connection '-ebef-4658-8991-' charon[2059]: 11[CFG] configuration '-ebef-4658-8991-' charon[2059]: 13[CFG] rereading secrets charon[2059]: 13[CFG] loading secrets from '/nix/store/va01sq5aqg6p7yakvpg2zlnsdj4pm9dj-strongswan-5.8.1/etc/ipsec.secrets' charon[2059]: 13[CFG] expanding file expression '/etc/ipsec.secrets' failed charon[2059]: 14[CFG] received stroke: initiate '-ebef-4658-8991-' charon[2059]: 15[IKE] initiating Main Mode IKESA -ebef-4658-8991-[1] to 123.111.111.111 charon[2059]: 15[IKE] initiating Main Mode IKESA -ebef-4658-8991-[1] to 123.111.111.


111 charon[2059]: 15[ENC] generating IDPROT request 0 [ SA V V V V V ] charon[2059]: 15[NET] sending packet: from 192.168.1.11[500] to 123.111.111.111[500] (304 bytes) charon[2059]: 03[NET] received packet: from 123.111.111.111[500] to 192.168.1.11[500] (204 bytes) charon[2059]: 03[ENC] parsed IDPROT response 0 [ SA V V V V V V ] charon[2059]: 03[IKE] received NAT-T (RFC 3947) vendor ID charon[2059]: 03[IKE] received draft-ietf-ipsec-nat-t-ike-03 vendor ID charon[2059]: 03[IKE] received draft-ietf-ipsec-nat-t-ike-02n vendor ID charon[2059]: 03[IKE] received draft-ietf-ipsec-nat-t-ike-02 vendor ID charon[2059]: 03[IKE] received draft-ietf-ipsec-nat-t-ike-00 vendor ID charon[2059]: 03[IKE] received DPD vendor ID charon[2059]: 03[CFG] selected proposal: IKE:AESCBC128/HMACSHA196/PRFHMACSHA1/MODP2048 charon[2059]: 03[ENC] generating IDPROT request 0 [ KE No NAT-D NAT-D ] charon[2059]: 03[NET] sending packet: from 192.168.1.11[500] to 123.111.111.111[500] (372 bytes) charon[2059]: 04[NET] received packet: from 123.111.111.111[500] to 192.168.1.11[500] (356 bytes) charon[2059]: 04[ENC] parsed IDPROT response 0 [ KE No NAT-D NAT-D ] charon[2059]: 04[IKE] no shared key found for 192.168.1.11 - 123.111.111.


111 charon[2059]: 04[ENC] generating INFORMATIONALV1 request [ N(INVALKE) ] charon[2059]: 04[NET] sending packet: from 192.168.1.11[500] to 123.111.111.111[500] (56 bytes) NetworkManager[2277]: initiating Main Mode IKESA -ebef-4658-8991-[1] to 123.111.111.111 NetworkManager[2277]: generating IDPROT request 0 [ SA V V V V V ] NetworkManager[2277]: sending packet: from 192.168.1.11[500] to 123.111.111.111[500] (304 bytes) NetworkManager[2277]: received packet: from 123.111.111.111[500] to 192.168.1.11[500] (204 bytes) NetworkManager[2277]: parsed IDPROT response 0 [ SA V V V V V V ] NetworkManager[2277]: received NAT-T (RFC 3947) vendor ID NetworkManager[2277]: received draft-ietf-ipsec-nat-t-ike-03 vendor ID NetworkManager[2277]: received draft-ietf-ipsec-nat-t-ike-02n vendor ID NetworkManager[2277]: received draft-ietf-ipsec-nat-t-ike-02 vendor ID NetworkManager[2277]: received draft-ietf-ipsec-nat-t-ike-00 vendor ID NetworkManager[2277]: received DPD vendor ID NetworkManager[2277]: selected proposal: IKE:AESCBC128/HMACSHA196/PRFHMACSHA1/MODP2048 NetworkManager[2277]: generating IDPROT request 0 [ KE No NAT-D NAT-D ] NetworkManager[2277]: sending packet: from 192.168.1.11[500] to 123.111.111.111[500] (372 bytes) NetworkManager[2277]: received packet: from 123.111.111.111[500] to 192.168.1.11[500] (356 bytes) NetworkManager[2277]: parsed IDPROT response 0 [ KE No NAT-D NAT-D ] NetworkManager[2277]: no shared key found for 192.168.1.11 - 123.111.111.


111 NetworkManager[2277]: generating INFORMATIONALV1 request [ N(INVALKE) ] NetworkManager[2277]: sending packet: from 192.168.1.11[500] to 123.111.111.111[500] (56 bytes) NetworkManager[2277]: establishing connection '-ebef-4658-8991-' failed NetworkManager[2283]: Stopping strongSwan IPsec. charon[2059]: 00[DMN] signal of type SIGINT received. Shutting down ipsecstarter[2058]: child 2059 (charon) has quit (exit code 0) ipsecstarter[2058]: ipsecstarter[2058]: charon stopped after 200 ms ipsecstarter[2058]: ipsec starter stopped nm-l2tp-service[2039]: gdbusmethodinvocationtake_error: assertion 'error != NULL' failed NetworkManager[954]: <warn[.6803] vpn-connection[0x24c60a0,-ebef-4658-8991-,"my-l2tp-vpn",0]: VPN connection: failed to connect: 'Message recipient disconnected from message bus without replying' .nm-applet-wrap[1470]: Failed to show notification: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Notifications was not provided by any .service files </pre</code</detailsRunning the following command fixed my error and allowed me to connect: The networking part of my only has .
This still appears relevant in 21.11. Adding this (as mentioned above) to my config appears to get an L2TP and IPSec VPN working with NetworkManager:
Still relevant in 22.05. I am confirming that with a clean install, trying to set up L2TP/IPsec VPNs fail with the following indicator: fixed the issue for me straight away as well.
Fix in


Describe the bug Thunderbird 78.2.1 is working. master (Thunderbird 78.2.2) has rendering issues (see screenshot). Most buttons do not react to clicks and the menu is also not reacting. To Reproduce Switch to the mentioned commit and rebuild. Expected behavior Normally working thunderbird. Screenshots ! Notify maintainers Metadata
This was also a bug in Ubuntu, it was fixed there with:
Upstream bug appears to be
Btw temporary workaround would be to switch to thunderbird-bin-78 if you are not opposed to binaries


Steps to reproduce the behavior: Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
might be fixed by confirmed. closing.
Hello. I'm new to NixOS, and also facing this problem: How can I apply that fix? I just updated my NixOS system flake to latest version: But still getting error during system rebuild:
try and update again, the fix is in unstable now.


Add any other context about the problem here. Please run and paste the result. repro'd on commit id
backtrace: <details<summaryBacktrace from lldb</summary</details
shapely 1.8.4 with the fix is now in pypi, I saw you wanted to upgrade it, did you get around to do it?
thanks for the reminder, committed it


When adding a text in Gimp, a green border is visible: ! However, I would expect something like that: ! After , a on both Gimp (need 3.10.30) and (need 1.18 apparently). However, in NixOs Cairo 1.16 is used instead, so I guess it is necessary to upgrade cairo. Steps to reproduce the behavior: some text on gimp, say white text on black background I expect Cairo does not have maintainers so I'm pinging random people that contributed: Running NixOs with KDE Plasma.
Looking at no distributions ship 1.18 yet. I wonder why. Is it an API-breaking release?
Proposed cairo one-liner backport as
The 1.18 branch yet. We could switch to development snapshots (1.17.x) if there are more concerns. But cherry-picks will probably be enough for now.
The above PR solved the issue, thanks a lot! For people wanting to test before it gets into unstable you can do: but it takes a few hours to compile until Hydra compiles it.
Actually I'll maybe let it open until it's merged to unstable (for now it's in stagging) and backported.
GitHub should auto-close once the fixing commit reaches master branch. Though I'm not sure if that wasn't broken by closing and reopening.
It's reached all channels.


Project description <!-- Describe the project a little: --: Newt is a programming library for color text mode, widget based user interfaces. Newt can be used to add stacked windows, entry widgets, checkboxes, radio buttons, labels, plain text fields, scrollbars, etc., to text mode user interfaces. Newt is based on the slang library. is in nixpkgs but only built for targets. It would be great if it could also be built for Homebrew has a , but since I just started using Nix I wasn't able yet to port it to a Nix file. My best try can be . Metadata homepage URL: source URL: license: gpl2+ platforms: unix, linux, darwin


Describe the bug With default settings, sound won't play in the stable repository Tor Browser. I managed to get it working: for some reason, says this: I am still new to Nix so I am not sure what it should say, but it can't be right since this piece in got it working: (after of course) To Reproduce Steps to reproduce the behavior: to your system configuration but leave ALSA disabled to do anything that requires sound in the browser. Metadata system: host os: multi-user?: sandbox: version: channels: nixpkgs: Maintainer information:
I marked this as stale due to inactivity. →
me, too. any word on this? just open any youtube video, and there's no sound. if it matters, i'm using the latest on using overlays.
I marked this as stale due to inactivity. →
I am also interested in solving this. I am using nixos: 21.05.3761. (Okapi) Since I am new to nix, I just tried the package override from above, but this is not working. Reading through nix-pills is not really enlightening which files are involved in what...
Did you remember to uninstall and install after adding the override?
I get an error: but my is located in
Two possibilities that come to mind: 1: You didn't install by attribute. you need to do (assuming your nix channel name is ) as opposed to 2: Your is indeed in the wrong place or wrongly named. I don't recall straight how it should be named. Believe the nixpkgs manual with this one, not me.
After reading I put my stuff now into So tor browser sources are not there anymore... mhhhh... so in that sense I feel nixos is not holding its promises of reliability (caused by external party)
It's our problem, and a known issue. More info .
They have an alternative mirror recently to the unstable channel. If you try the newest unstable, it might download. Can't guarantee that though.


thank you for your attention/help - I will try this later and report back...
I have the following override: So tor-browser reports back the new version: 10.5.10 but I get the following error when playing a video - so audio does still not work:
... it seems that the overlay does not affect of the original package. This part of is not contained in the generated file: since I am quite a novice with nixos, any hint is welcome....
that worked, thanks alot!


For Chromium, there's a convenient way to define custom flags through . However, there doesn't seem to be a similar option for . I tried setting to "--touch-events", but touchscreen scrolling is not enabled when starting VSCode from desktop launcher, while running in console works as expected. Steps to reproduce the behavior: to "--touch-events" VSCode from desktop launcher on the editor area through touchscreen The editor should scroll as I drag. system: host os: multi-user?: sandbox: version: channels(yes): channels(root): nixpkgs:


Overriding idris-no-deps in nixpkgs results in a mismatch between versions of builtin packages and the compiler. With this derivation: I would expect to end up overriding the version of idris-no-deps in idrisPackages would change the derivations of builtin packages to be built with the supplied version of Idris. However, instead they are built with the Idris from the channel used. Leading to this error at build time (for Idris2): By examining the final result of the build I can see 2 versions of idris being used: Please run and paste the results.
Thought I might be able to solve this issue by specifying overrides as well. But no luck This is what the derivation for base looks like Specifically: Which contains the wrong version of Idris.
Same issue with non builtin packages as well. Also perhaps this is a better demonstration of the build time dependencies:
Thanks for the report, above PR should fix it, let me know if it works for you, then I'll merge it :)
Well actually I know it will work, but still. As a workaround if you don't want to change nixpkgs, an overlay should give no problems too:
Brilliant! Yes it's working for me and I'm now able to build Idris 2. Thank you very much!


The Haskell Hackage database allows distros to report which packages they ship, and include a link. Right now, it seems that nixpkgs reports all haskell packags, including broken ones. This makes for a bad user experience – I might see on hackage that nixos comes with a certain package, and then happily go ahead trying to use it, only later to get the dreaded error message. Same actually for repology, reporting packages as available that we know do not build is not great.
We intend to support all package. We just need haskell maintainer
Oh, absolutely! Maybe I shouldn't say “supported” but “available”.
No, we don't. We only intend to support packages which have value to our users. Hackage is append only and contains a lot of dead or niche packages.
I agree this should have been fixed long ago.


Cc: First of all, thanks to everyone for working on NixOS. Awesome 4.3 has a module called , it allows It can be used for theming, as shown in . However, the current build does not include the typelib files needed by the module making it unusable. The  implementation uses lgi to obtain via gobject-introspec return require('lgi').Gtk Since the current build does not include the typelib files needed, the above call fails. After some experimentation, I found out that both and are needed. For example: and try to load Gtk: fails with (the package that actually includes the typelib file) and add the folder to the environment variable: fails with and add it to and finally loads. Awesome as window manager to load the example gtk theme awesome the warnings issues by Awesome: I suggest that both and are as build inputs to the awesome package, I tried this out and it actually works. The catch is that the closure size increases by 123.9M: build awesome without gtk3-x11 and atk -99.6M build awesome with gtk3-x11 and atk -223.4M So, instead of adding the packages unconditionally, we could add an optional flag, like e.g. , defaulting to false. In this way, one could always build awesome and add it to . Ideally one could even add something like to the top level , a bit like : If a decision is made, I'd be happy to submit a PR. system: host os: multi-user?: sandbox: version: channels(root): channels(user): nixpkgs: awesome 4.3 (Too long) Compiled against Lua 5.2.4 (running with Lua 5.2) D-Bus support: execinfo support: xcb-randr version: 1.6 LGI version: 0.9.2
It should not be necessary to use , should work just fine. See for docs on , which will populate the environment variable automatically.
Thanks, I'll have a look. For the record, I used because that's where told be the typelib files where. I am still keen on hearing what the correct solution would be regarding how to add support (closure size, optional arguments etc.). Thanks.
thanks for our suggestions.


Here are my thoughts: seems to work as well, the closure size is 222.9M instead of 223.4M seems quite conveniet, but awesome needs additional options in the wrapper and it's unclear to me whether we could do that after introducint uses that seems to have negative effects, see so we may have to look for alternative solutions anyway (Awesome does not seem to use much of GTK anyway as it's not a GTK app)
how could it shrink? can use as described in the doc PR to add more options. , I am aware of that but other than hardcoding the typelibs like we do in GNOME Shell extensions, we do not have anything better at the moment. See for deeper analysis.
¯()/¯ maybe it's got less dependencies built than the one? I see, I somehow missed that. It seems that works OK (I am using this in an overlay on NixOS waiting for the patches to land in the stable channel): In the end, AwesomeWM should not need the whole of gtk, I think that gtk should be made optional so one can turn it on or off. Thanks, I did notice that and I'll keep an eye on it


fails to compile on unstable. on (Flounder) System: (Flounder) Nix version: nix-env (Nix) 1.11.2 Nixpkgs version: "16.09pre88945." trace:


Project description simplescreenrecorder is not that user-friendly and has problems (). right now i use OBS, but it's overkill for the task. maybe this is a good alternative Metadata homepage URL: source URL: license: GPL-3.0-or-later () platforms: linux, more?


If I only do: then I get virtualbox + nvidia: If I enable virtualbox guest additions: then I get only virtualbox!!! and nvidia does not work anymore on my machine: this is because virtualbox guest additions is overriding services.xserver.videoDrivers: this is not necessary since by default the lists are merged workaround: then I get virtualbox + guest additions + nvidia: Ideally this should work out-of-the box, debugging this kind of behavior is very obscure, and also different configuration options should cohexist


On the master branch ethminer fails to compile with messages about missing getglobalepochcontext from ethash namespace. Attempt to build ethminer on master branch. Successful compilation. Root of the failure is in changes done to the structure of the dependency chfast/ethash; specifically, 0.6.0 -0.7.0. Patching the libethcore/EthashAux.h file in the ethminer repo, by adding to the headers, and the file by changing the line to does the job.


Describe the bug doesn't run on Darwin, due to some Perl / shebang errors. To Reproduce Steps to reproduce the behavior: Darwin, run the only produced binary , ie. following output is produced: Expected behavior The executable should output its help text when run without arguments: Additional context I managed to get it running using a wrapper script that runs . Notify maintainers Metadata Maintainer information:


name: current version: 0.10.1 desired version: 0.11.0 maintainers: The last few updates were done by r-ryantm, I don't know why it didn't do this time. I checked the logs, apparently it didn't even try building it.


In gnome runs fine, in KDE plasma there are a couple problems: Unable to open file explorer when pressing "+", crashes with error Unable to add account, getting error Run in a pure shell: , use the and try to use it OR plasma installed and no other desktop environment: onedriver from nixpkgs (with home manager for example:) and press the button to add a folder. No errors we're missing the inputs and . should fix the gsettings schemas error (). The error requires env variable , we should probably wrap as explained . Quick and dirty way to make it work now, without wrapping, is adding those dependencies and adding the variable to the whole system: and to buildInputs and nativeBuildInputs respectively. (not sure which one for either): to the nixOS configuration the location of the variable: We should create a option eventually ahahha This is my configuration for the onedriver user service: <!-- 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]:
Hello and thanks for reporting this! The is although it is only available in the channel for now, can you please test if the derivation from nixpkgs-unstable works for you? If not, I will add the missing dependency and make a PR asap :) As for the GIOEXTRAMODULES variable I am not sure there is something I can do at the derivation level.
Thanks I can confirm the version on the unstable channel doesn't crash with , but without the variable set the error is still present. I tried to wrap it by adding this line in the end of the postInstall script but it didn't fix it, running now shows two GIOEXTRAMODULES variables set tho I'll keep this open for now because of this problem and update the title the workaround for now is adding to the system configuration
Hey, I just pushed a small branch which should fix your issue with . I built the derivation locally and I get the right GIOEXTRAMODULES path set correctly by the script.


In my attempt in my previous comment, I had also tried a method that seemed to have set the correct GIOEXTRAMODULES path, but I tried your derivation and still: ! I grabbed your commit like this and it took a couple hours to build, it seems to have built a lot of programs besides onedriver, I'm still not a great nixOS wizard:
never mind, I'm dumb, forgot to change the package used in , now the error doesn't appear, but the window comes up grey? !
Trying to use the code from in my own config with callPackage gives me if I use instead of it works perfectly
using just also works
That is because is only on right now, if you're using you need to use , which is the same thing :) Glad to know the problem has been fixed for you. As for the blank page, it seems to be an upstream issue with onedriver and Plasma 6 (see jstaf/onedriver), but since I don't use Plasma I'm afraid I cannot help..


Project description The Open Observatory of Network Interference (OONI) is a free software project that aims to empower decentralized efforts in increasing transparency of Internet censorship around the world. please package as "ooniprobe-cli" ("ooniprobe" as alias) and "ooniprobe-desktop" like used here: Metadata homepage URL: source URL: license: mit (hidden in ) / BSD 3-Clause platforms: unix, linux, darwin, windows
I marked this as stale due to inactivity. →
...
I marked this as stale due to inactivity. →
Still relevant.


For visibility of our project it would be good if Steam can detect NixOS. Then it might appear in their stats: Error on console: Related to Currently detected system informations: steam system informations system: host os: multi-user?: sandbox: version: channels(davidak): channels(root): nixpkgs:
NixOS isn't configured to have . Kinda surprised they don't fallback to in favor of .
They actually do fall back but our doesn't support any files besides deprecated . We had a discussion before about correctness of providing on NixOS but I think we could do that, just print some error when supported LSB version is requested. Maybe we could steal Debian's modern implementation - I think they even use .


Hi there I installed but the driver is not available on CUPS; the printer (Brother HL-1223WE) is detected correctly. My system is on . Steps to reproduce the behavior: to to add the printer on CUPS.
Submitted a with a fix for this issue.


Project description From the home page: Metadata homepage URL: URL: public domain with two files under 3 clause BSD () platforms: "The system is known to run on Linux and BSD-based UNIX systems. Supported target architectures are x86-64 armv6 (hardfp), AArch64, Apple M1 and riscv64 (R64IMAFD)."


For a few days, when booting my amd computer with plymouth enabled I can't enter my passphrase anymore. Pushing keys multiple times eventually end up in one key-press being accepted. Booting with instead of suddenly has no more issues with keyboard entries. Steps to reproduce the behavior: NixOS Unstable to and with a LUKS/ZFS Passphrase -presses are omitted Every key I hit will be used. <!-- 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(pl): channels(root): nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Upstream bug report Fixed in upstream already


Project description nodenv is one of version managers. I know you can manege with Nix itself, but majority of people in the frontend world assume everyone uses version managers which respect files like or , so you have to use them when you're working with them. Metadata homepage URL: source URL: license: MIT platforms: I'm not sure actually, but it's distributed as a homebrew formula
Hello, please check the merged pull request for notes on the package. The package works, but might need some changes or be extended to work better in the future.
Wow, thanks a lot for your help!


, (nixos-unstable, nixos-19.03, nixos-18.09) Scanned versions: nixos-unstable: ; nixos-19.03: ; nixos-18.09: . May contain false positives.


Can't simply apply the upstream commits, unfortunately (AFAICT). This looks pretty serious!
Thank you!! :sparkle:


The audacious package imports audacious-plugins to build most of the common plugins and then link them into the audacious lib path. However, this makes it hard to add more audacious plugins, like vgmstream. The vgmstream package currently has its , because importing the audacious package causes an infinite recursion error. Steps to reproduce the behavior: vgmstream to audacious-plugins buildInputs audacious to vgmstream's buildInputs and comment out the disable configure flag -shell -p audacious-plugins I expected that adding vgmstream to audacious-plugins would enable the plugin. Instead, the build crashes with an infinite recursion. How is it currently working for audacious to import audacious-plugins and audacious-plugins to import audacious? Can this same magic be extended to other plugins? This about how fcitx is packaged shows that fcitx-addons imports fcitx with no reverse import, should the audacious package be refactored to be similar? Should the audacious package gain an extra parameter to take extra plugin derivations, which can be created outside of the audacious-plugins derivation? Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Instead of adding , did you try to add instead? is without as input, and it is used to break the loop.
Thank you for the quick response! That would be elegant, but I don't see any result in my grep of nixpkgs or in the .
Sorry, it is here: Basically you need to do and this should do the trick. Considering that we are going to use this in more than one place it probably makes sense to introduce it as a , but the result is the same regardless.
Oh that's a neat trick! I'll try that approach out next. Thank you so much! I tried out the extra-plugins approach here, seems to work but is not ergonomic:
I , and it's a lot easier to use as a user! If it looks good as an approach, please provide some review feedback and I'll squash it down for a PR :)
Shall I send a PR for a final review?


Package name: juce Latest released version: 7.0.10 Current version on the unstable channel: 7.0.9 Current version on the stable/release channel: 7.0.7 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]:


Steps to reproduce the behavior: hydra build: build logs: 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]:
Not sure why this suddenly started failing after it worked fine for the last 11 days. Reproduced this and submitted a patch in that fixed it for me locally.
Thanks, I can confirm that the patch does work.
In my observation, it only breaks on , the works just fine. That's extremely weird.
I logged the test phase on the latest commit and the one before that, here’s what’s changed: Looks like it is to do with the
Nice work, It looks like is the commit that upgraded to pytest 8, but that was two weeks ago. So I'm not sure how this passed for 4 days ago.
The build that passed 4 days ago used as and the also wasn’t pointing to , here’s a snippet from the logs: The log file: But the latest build which failed, had set to and set to .


Steps to reproduce the behavior: oterm 0.2.7 unstable (I'm doing via home-manager on rev ) Fails finding a typer version Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I will check on my NixOS host later in the day to see if I can replicate.
There's a quick way to fix it:
Also, a PR in upstream:


Steps to reproduce the behavior: something which uses (easily ) 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. --No maintainers, blame says last made a modification. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
No maintainers, blame says last made a modification. Hm, I can’t recall changing anything remotely related to LLVM and/or wrapper stuff recently. Which file(s) are you referring to?


Describe the bug nixos-unstable-small's package is broken: Seems related to beancount/fava To Reproduce Steps to reproduce the behavior: Expected behavior Fava builds correctly Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Maintainer information:
I suspect this isn't the only app that broke with the switch from flask 1.2 to 2.0 and jinja 2 to 3.0.1
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
You can use in the expression for to pin and to compatible versions.


it does not start anymore Steps to reproduce the behavior: davinci-resolve davinci-resolve Working Program. Installed from unstable 22.11pre420742.. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:


, (nixos-unstable) (nixos-unstable) (nixos-unstable) Scanned versions: nixos-unstable: . May contain false positives.
See also


See:
I've been using cryptsetup with an SSD and without kernel crypto to run my entire NixOS and didn't noted any performance issues, but I agree that my patch was a temporary workaround, so enabling the crypto module would be a better solution.
The option also breaks the feature of that can be used when installing nixos to reason about the speed of disk encryption
The NixOS test works with and the kernel userapace crypto API enabled in on at least 19.03. was updated to 2.0.6 in the meantime, maybe the bug was fixed? Haven't noticed anything in release notes. This API shouldn't in fact be need for LUKS, only for tcrypt and the benchmark. Did you also run the test or did you just notice that on your local machine? Do you have any non-standard config concerning the initrd?
Hmm, even with the test succeeds. We need more information.
I haven't ran any tests, I just tested it in my work laptop and in a VM used to isolate the issue. I used a non-standard initrd config only for debugging, but after finding the problem I used the standard one. The only strange thing I did was to have a LUKS2 encrypted volume, which isn't very common (or at least it wasn't at the moment I experienced the issue). In a few days I will try to boot my system both with and without kernel crypto to check whether it is necessary or not.
I can confirm that I still have problems booting my system when kernel crypto is enabled. I put this in my , in an updated unstable NixOS: With this configuration, my system boots. If I uncomment the line, it doesn't because it fails to unencrypt my root partition. I'm using LVM inside a LUKS2 partition.
Here is the result of using when mounting my LUKS2 volume with kernel crypto enabled. The last image is the most important. Sorry for pasting screenshots, I didn't have a flash drive to copy the logs. ! ! ! ! !
Thank you very much for your detailed analysis. :+1: Oh, LUKS2! Seems the userspace API is indeed needed for LUKS2 but not LUKS1. I'll try to adapt the test and fix this issue. There are probably just some modules missing.


Commit introduced to the configuration of . This causes to no longer work, with the following message: Run , where is a truecrypt volume. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
The issue for re-enabling kernel_crypto is
It also breaks
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
still important to me
I marked this as stale due to inactivity. →
are you sure this is still an issue? This seems to have been solved by . e.g. cryptsetup benchmark works just fine on my machine.
I did not check and do not care anymore. Thanks!


The tray icon appears, but he according window shows: Steps to reproduce the behavior: syncthingtray (through home.packages in home-manager in my case) on the tray icon The proper GUI with shiny buttons and stuff
Didn't have time to do actual digging yet, but seems like it's actually a matter of launching it / nixos weirdness rather then the package itself at fault: if I run manually from the terminal it actually works as expected. if I have it launched by plasma's autostart it sits in the tray failed with the message above. if I have it launched as user systemd service through the according home-manager option, it fails to launch because it can not find the tray altogether (probably launched before plasma is ready). So the question is, why is it different when launched from autostart... The message shows the right path in after all... (Disclaimer: total nixos noob here. Maybe it's obvious for a more experienced user...)
I'd investigate this by comparing the environment of your terminal to the environment of autostart's file - try to override the line to something like:
Oh I see what's the problem.. the file generates is pointing in to the unwrapped executable.. This needs to be patched locally in nixpkgs!
That would explain it. What do you mean by "patched locally"?
I mean this:
you are invited to test the fix for your issue in .
I'm really sorry it took me forever to actually test it - had issues with the system I use it on. Anyway, the desktop file wasn't my issue either - I didn't realize the thing in tray is not the autostarted desktop file / syncthingtray process, but the plasmoid which is apparently a completely different beast running within the plasmashell process rather then a separate one. It appears automatically in tray unless I use syncthingtray with and can not be removed from there through plasma controls. Launching the process actually creates a second icon, which behaves properly.
I'm not sure I followed.. Does it work if you set ? has landed in so the environment issue fixed there should affect you somehow I think. Feel free to reopen the issue.
No, the plasmoid is what fails. The plasmoid seems to be launched in a different way, independent from the desktop file.


Whenever I include syncthingtray in the home manager with (which is default), the plasmoid appears in tray on next login - but no process exists. It seems to run as part of plasmashell instead and is not in the autostart at this point. Autostart seems to be a different way to start it as an alternative to the plasmoid stuff, the plasmoid is however what is running by default with the current syncthingtray package. Doesn't seem like I have permissions to reopen it in place.
According to the initially reported issue description it is indeed the Plasmoid that's causing problems here. On Plasma the Plasmoid is supposedly the preferred UI. So the goal should be to fix it. If you nevertheless want to use the executable instead you can do that of course as well. Then you can simply disable the Plasmoid by removing it from all panels/screen as usual. If the Plasmoid is shown as part of Plasma's system tray Plasmoid, you can disable it via the settings of the system tray Plasmoid. To fix the actual issue of the Plasmoid: Supposedly a file is missing in the package. The full list of files to be contained by the package should currently look like this: Of course the exact paths depend on your install prefix and paths of your Qt and Plasma installation. Maybe something is not missing but installed to the wrong directory. Did the Plasmoid (not the stand-alone executable) ever work with your packaging? If it did then I'd try to compare the last working package with the first bad.
Note that an override for the executable path (via a CMake option that then sets a define which is used if present like in your patch) could be upstreamed.
I was thinking about it just today, since usually you'd want it to be the permanent symlink and not the path (to the wrapped executable) that might be removed after a garbage collection.. Let's continue this discussion in
What is the status on this?


I'm still encountering this issue on my machine
I'm not sure what more could I do here.. I will report here after comment that there are no much differences between the files installed by our package and what should be installed: <details<summary<codediff our- upstream-</code</summary</details
Is this a problem affecting all NixOS users or is it just reproducible in the setup of a few people. For debugging it might help to start with the env variable set.
I'd only compare the packaging with how other Plasmoids for NixOS are packaged. Maybe there actually needs to be a difference compared to my "upstream packaging".
I don't experience this issue, here on Gnome, naturally. Other packages in Nixpkgs, like , and also put files in , according to .
Yes, you would obviously need to start a Plasma session to reproduce the issue. (Or just launch or in another session. I suppose will work in any X11 session and in any X11 or Wayland session.) Maybe it makes more sense if the users that actually use Plasma would do further debugging on their side, though. By the way, how do you use Syncthing Tray under GNOME? Last time I've checked whether it works there was no general support for system tray icons at all and issues like suggest that GNOME has no generic system tray icon support at all right now. If there are any workarounds those might be worth documenting under and could be extended with a remark to the workaround section.
As a note, I'm a pretty new NixOS user, but I switched yesterday to the unstable channel, and syncthingtray is working completely fine now.
Using .
Thanks for the report. I wonder what was the problem... I'll close this in the meantime, unless someone from the stable channels will give a detailed bug report.


Unable to launch gplates on NixOS. A shared object file appears to be missing. Steps to reproduce the behavior: : gplates is expected to launch and be usable. N/A N/A No listed maintainers on Nix Packages but was the last to touch the source for this application. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Probably adding to and/or adding to might help, but I'm too tired to debug tonight. I'll look into it in the next few days.
Thank you, I was reading about the first option you suggested being a potential fix. I'll see if I can wrap my head around doing it on my own as well this week, though I don't have a lot of experience contributing to projects likes this.


Steps to reproduce the behavior: trueseeing dependency check fails due to missing termcolor. Full logs : <summary<details<preSourcing python-remove-tests-dir-hook Sourcing python-catch-conflicts- Sourcing python-remove-bin-bytecode- Sourcing pypa-build-hook Using pypaBuildPhase Sourcing python-runtime-deps-check-hook Using pythonRuntimeDepsCheckHook Sourcing pypa-install-hook Using pypaInstallPhase Sourcing python-imports-check- Using pythonImportsCheckPhase Sourcing python-namespaces-hook Sourcing python-catch-conflicts- { "action": "setPhase", "phase": "unpackPhase" } Running phase: unpackPhase unpacking source archive /nix/store/p05bg72wb6ihkj9jjmdgzsnjifd0m0ar-source source root is source setting SOURCEDATEEPOCH to timestamp of file { "action": "setPhase", "phase": "patchPhase" } Running phase: patchPhase { "action": "setPhase", "phase": "updateAutotoolsGnuConfigScriptsPhase" } Running phase: updateAutotoolsGnuConfigScriptsPhase { "action": "setPhase", "phase": "configurePhase" } Running phase: configurePhase no configure script, doing nothing { "action": "setPhase", "phase": "buildPhase" } Running phase: buildPhase Executing pypaBuildPhase Creating a wheel... Getting build dependencies for wheel... Building wheel... Successfully built trueseeing-2.1.9-py3-none- Finished creating a wheel... Finished executing pypaBuildPhase { "action": "setPhase", "phase": "pythonRuntimeDepsCheckHook" } Running phase: pythonRuntimeDepsCheckHook Executing pythonRuntimeDepsCheck Checking runtime dependencies for trueseeing-2.1.9-py3-none- termcolor not installed </pre</details</summaryAdd 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. system: host os: multi-user?: sandbox: version: channels(root): channels(user): nixpkgs: I believe trueseeing is missing the termcolor dependency hence the failure happening during the build.


I can try and PR a fix but I did not try and reproduce the bug under NixOS. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Seems a lot of other packages have broken in similar ways, mitmproxy, ioccheck, theharvester but they all fail due to missing runtime dependencies or version of modules that are not meeting constraints.
I had the same issue with mitmproxy and found this issue because you've mentioned it here. ~git bisect for mitmproxy pointed to this commit for me: ~ Edit: apologies, I used git bisect wrongly. The first bad commit seems to be .
This seems relevant:
That shouldn't change whether or not a package builds.
Yeah, my nightly session of bisecting for pointed to , which is from . I guess affected packages do have to be fixed one-by-one manually.


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


shadowsocks-v2ray-plugin doesn't work anymore in nixos-unstable. Try to use it with shadowsocks-rust. Here what I have in logs: It works. If applicable, add screenshots to help explain your problem. Add any other context about the problem here.
Version from works.
Looks like it got updated again: :)
cc
Just a note - it seems v2ray plugin is not maintained, but maybe can be used instead.


Configuration summary shows several incorrect paths: liblouis tables can probably be easily corrected, not sure what to do about cups dom socket and font directory. nixpkgs: cc
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .


Links like do not work, since the scheme handler is not registered in the desktop entry file. Steps to reproduce the behavior: Zotero stuff to biblography to select item using a url The correct item is selected Related flathub issue: I'm using 21.11 stable, a backport would be appreciated. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --


Steps to reproduce the behavior: alternatively (the output is the same) Found this while trying to build on my mac I also tested this running on my nixos work computer instead of via a remote builder and got the same result. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Though the actual building is done by a remote builder with .
Fortunately it seemed OK after a quick glance, on x86_64-linux at least. Feel free to review.
Yep, this seems to have fixed it, thanks :) building a static lmdb seems to work for at least x86_64-linux and aarch64-darwin. I'll continue my adventure of trying to get murmur to build statically


twmnd does not launch because qt5 library path is missing. Install the twmn package and run twmnd. twmnd works when I manually set the LDLIBRARYPATH to <qtbase/lib. System: NixOS 16.09.931. Nix version: 1.11.4 Nixpkgs version:16.09.931.
I noticed the same or similar thing when trying to run twmnd as a systemd user service. It just SIGABRTs: I could reproduce with Although works fine... So clearly there is some impurity in my local environment which is making twmnd work "by accident?" Possibly related?:


the attribute inside a user-level systemd service seems to be ignored. I have three observations to suggest this. With this snippet from (service details aren't important, just for concreteness) If I run , I see batterycheck.service, but no corresponding timer. If I run , I again see the .service file, but no timer file. If I remove the startAt line and run , I can see from the output that no new environment is being built. I'm pretty sure that this functionality used to work several months ago, when I created this unit definition.


Package name: oracle-instantclient Latest released version:21.9.0.0.0 <!-- Search your package here: --- Current version on the unstable channel:19.16.0.0.0 Current version on the stable/release channel:19.16.0.0.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! -- looks like it tried to upgrade v19 of instant client, but it is stale and not targeting v21. Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR.
It looks like you were the last one to touch instant client.
Package sources:


Describe the bug gitea fails to start due to a too restrictive systemd setup To Reproduce Looks like is a bit too restrictive. :smile:
ping
Removing the blacklist of and gets us past the test, I think, but there's still problems with the socket.
Judging from this error output: it looks like it fails in prescript during in Interestingly enough, there is a right underneath that, in which does not seem to be the issue. This does not look like an issue with Gitea itself, since it fails during the service pre script. Since the and will only be run if the configuration is managed by nix, the tests pass if I set in the test config. (unfortunatly I don't know much about systemd services and especially systemd sanboxing, so I'm not sure if the information from above is useful or not)
Any chance the service is broken too? I recently updated and service failed to start. I haven't dug into it yet... I may have seen something about a database permission issue.
Temporary fix for someone who using bleeding-edge Gitea:
This doesn't solve the issue for me. I get the following output:
Pretty strange. It works for me (). You can try to disable it at all () and if it'll still not work then just change in the same way all other parameters to default values that were introduced in . p.s. probably there's must be something like a mkForceRemove, but I haven't found anything in manual.
Ok the fix is actually working, I just had an own AmbientCapabilities definition in my configuration which didn't play nicely with the new options.


For example: fails similarly. The line that causes the failure according to my testing is: A list of some packages that didn't break: Could be this is an upstream issue.
So digging into it, this is an issue raised by Octave's package management system itself. Namely, this -statement from Line 80 in that file is the statement. It expects to remove a file, which is not existing. The reason the other packages did not break was because they either do not have a directory () or they actually do have a generated file (netcdf & control). You can technically solve this by adding an empty script to the directory. I manually did this, and the package built correctly again. As for why this change happened, I cannot tell. The particular statement shown did not change between 6.4.0 and 7.1.0 in the file.
Looks like
That's the exact issue. Seems like we will need to wait for upstream to fix it. How does this usually get handled
Seems like we should apply to the patch:
There are still 5 packages failing to build, but that is a lot fewer than before.


When using file picker in calibre e.g. on first launch after install that pops up file picker to select library path or by clicking "Add books" in menu calibre will crash with error Steps to reproduce the behavior: not yet crashed - select "Add books" item in menu Calibre should work without issues From i figured adding to solves problem, so running it like this works: Please run and paste the result.


The soundfont that is packaged in is no longer available. The URL in that file is , but that page says: "Sorry, this is a wrong download link.". No packages depend on this package.


This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.
Hi I'd like to work in this issue. First one with documentation so I will probably need to understand a few things first.
Thanks, let us know if you need help!
Hi thanks for picking this up. Are you still working on this? If you're stuck, you could create a draft PR so someone can help, or if you've changed your mind that's also ok.
Hi Sorry for late reply. I worked a little bit, on and off during the holidays, I do not finished yet, I had some problems during the build of the documentation, but from what I read (pandoc output) I made some mistakes during the file conversion. For now, I didn't commit, It's on my personal computer only. As the week is a little difficult, I'll see if I finish it at the weekend. (Maybe I should have asked for this issue just now, just see 14 days ago and I was like "What ?! That was 2 weeks ago ?!" LOL) Thanks for asking!
Hi I followed your suggestion to create a draft PR, at the moment I'm stuck in two things, the first is how to create a note and the second reference errors during the build of the documentation. For the first, pandoc created notes with the following formats: , in this case I should use the default way to create notes in markdown (using ) or wrap this in docbook way? If I remove the references that generate the error below, I can verify that using the markdown format, this note is styled differently from the rest of the documentation. And for the build errors, here is log: For this I tried per but build fails with same error. Any help is appreciated.


Project description Netdata agent plugin Metadata homepage URL: source URL: license: GPL 3.0 platforms: unix, linux, darwin We already do have netdata, however it seems to be built without support for the cloud agent that allows it to stream to the cloud or other netdata servers.
I have a local checkout with some edits that allow me to build netdata with cloud support. Unfortunately they also require a change in the libwebsockets build expression. Should I open a PR to integrate my changes into nixpkgs?
A PR would be great! I'm not a maintainer, but if they decide it's out of scope for nixpkgs, perhaps one on NUR might work - I'd try for a PR here first though
Great, I think having a configuration option that is per default would make sense. Maybe ?
Yeah, that seems to fall in line with the various flags present in other packages
I marked this as stale due to inactivity. →
Upstream has incorporated some of the suggestions in this thread, I intend to pick up on it again soon
what would be needed to make this work? Perhaps I can help?
The newest major release of Netdata (1.30.0) includes a cloud link implementation without the need for vendored dependencies. Unfortunately, it is not currently in a reliable state because of a bug in the custom HTTPS implementation. The has already been merged into Netdata master and will be included in the next release. I plan to make a PR that enables cloud support as soon as that release is available.
v1.31.0 dropped 12 minutes ago :) Anything I can do to help?
Thanks, I've already gotten a notification for that. Planning to make a PR when I get off work today. When my PR is done, it would be helpful if you could test my changes on your machines.
Just FYI, I have opened the PR that enables cloud support a few days ago. If you are still interested it would be greatly appreciated if you could test if everything works for you and maybe drop a comment.
Sorry, missed this but the pr looks good! I propose we backport this to stable?


Steps to reproduce the behavior: nixos-unstable to home.packages -rebuild build Please run and paste the result.


Package name: organicmaps Latest released version: 2023.04.02-7Current version on the unstable channel: 2023.03.05-5 Current version on the stable/release channel: 2023.01.25-3 Notify maintainers Note for maintainers: Please tag this issue in your PR.


Steps to reproduce the behavior: macOS: Since , this fails on macOS due to case-insensitivity (). The offending PR had no description, no reviews and no reports of tests on any platform. It was merged by the author four days after it was opened. Please run and paste the result.
Fuck MacOS and their stupid case insensitive file system.
Can you try mv'ing the file first to another name like?


I'm using NixOS "/ on tmpfs" mode, so I persist my dconf by using a module of home-manager. When I persist the state of GNOME app drawer, I need to write down desktop file name to .nix config. But currently, Android Studio's desktop contains a string of version, this because contains . Details: I also notice used in icon too, which will cause icon file contains version string, I think we can remove them too. If maintainer agrees, I will make a PR to deal with this. Also, I noticed another maintainer deleted the account: Maybe I can send him / her an E-mail for asking what happened, and drop the maintainer info.


On running I get: Add to and run. system: host os: multi-user?: sandbox: version: channels(lev): channels(root): nixpkgs:
Well, the output has at least changed a bit:
my pull request fixes the . It broke down because the package had moved to but requires . But according to the browser is discontinued and `firefox-esr-5.2' is marked as unsecure so I would rather advocate for removing this package altogether.


name: flexoptix-app current version: 5.11.0 desired version: 5.12.1 maintainers: Please tag this issue in your PR.


Enabling fails with: Steps to reproduce the behavior: and enable Nextcloud The notify_push service starts. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Hm, I thought I had tested that. Can you test if it works if you modify the module to drop the parameters from the script where it executes ?
Doesn't work either. I don't know PHP, but it seems that is unable to parse the inline function.
Yeah, notify_push is written in rust and doesn't actually execute php to parse the config, which is why this doesn't work.
Upon further investigation, dropping only works. Dropping the whole result a failure with: It needs an option to set .
can be set like . Maybe we should transition away from putting a function into the nextcloud config and just modify the file in the setup service.
it works, but if the Redis URL has a password it ends up in the Nix store.
I have the same and I can't reproduce this issue.
do you have the line in your ? I think the reason is because I'm using an external DB and S3 storage.
If you have passwords used in the config the nixos module does inject that lookup function. In the initial PR of notifypush was already a discussion how to handle that, and there was already a suggestion to drop I dont remember why it was not done there, i basically withed to non password authentication (as everything is running on the same machine anyways, so using the socket solved the issue back then, so i forgot about it).
nope, I am using socket authentication.


Hayabusa is a swift rust fetch program. <!-- Describe the project a little: --Metadata homepage URL: source URL: license: Attribution-NonCommercial-NoDerivatives 4.0 International platforms: linux, windows Priorities Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


After switching from 21.11 to unstable and a clean reboot ts3client crashes as soon as it tries to access the microphone. Steps to reproduce the behavior: to current unstable ts3client to a server or click Options -Recording -Test Not crash when using microphone Attached the coredump i am receiving. I am using pipewire in this context, but i can't circumscribe the issue on pipewire as other applications still work and are able to record without issues, also switching pipewire out and use pulseaudio seem not to solve the issue. I tried to overlay the package with libForQt512 (just playing around with it) as one of the differences between stable and unstable are version changes on qt libraries. But that did not fix anything. I have also tried the flatpack version, to check it there is something wrong with my pipewire config, but the flatpack version runs fine. Switching back the nixpkg from unstable to 21.11 and rebooting fixes the issue, so at least would tackle it down to changes related with changes in unstable. As stable and unstable ship the same ts3client version it has to be somehow related in between, or (hopefully not) just on my machine. I would not rule out that the issue is somewhere on my side. Please run and paste the result.
Running the version of a previous nixpkgs works just fine, even with an up-to-date environment. It must be a problem with the ts3 drv itself. I'll hopefully have time to run a bisect later.
Bad is which is a staging-next merge. Bisecting staging-next now...
Bad is . (Note: Injecting a cached qtwebengine saves a lot of time here and doesn't falsify results.)