Describe the bug Not able to install pycuda. Error To Reproduce Install pycuda Expected behavior install pycuda with dependencies Metadata Please run and paste the result.
Is nobody having this issue it seems is not solved :(
I'm having this issue, incoming PR. Likely half of the problem is that the cudatoolkit is pinned to 7.5 and cuda root is not passed during the build process, which is not compatible with newer cards. The other half of the problem is that python3 boost isn't being linked. I see boost is mentioned as not being necessary for pycuda in the docs, so I'm wondering if we can just remove it.
try and let me know if it works for you


Project description Desktop client for the LBRY protocol. A YouTube alternative that uses the blockchain. Metadata homepage URL: source URL: license: MIT platforms: Linux
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
Still not packaged.
Work has been started in .
I marked this as stale due to inactivity. →
still actual
PR
PR closed, anyone else willing, reopen under a new PR and try your luck at the merge roulette
Small update, I'm currently working on packaging LBRY from source (it actually seems possible).
Ok, while not from source (that didn't work out) LBRY has been packaged.


Describe the bug NixOS’ Reaper package is not configured to work with Jack2 backend. To Reproduce Expected behavior Reaper should manage jack backend. See for instance . For now, Reaper only says in Reaper Preferences/Audio/Device. Additional context Everything is working fine on my system with jack2 (Ardour, Supercollider, VLC, etc.), except Reaper. Metadata


Describe the bug When I launch using a keyboard shortcut, it didn't get any context, resulting in it displaying strangely: ! If I launch it using the menu it displays correctly. For other applications, depending on what they requires, they sometime just don't open. EDIT : I have the feeling that the reason that is not opening when using the keybinding is the same reason. To Reproduce Steps to reproduce the behavior: a shortcut to Konsole konsole with the shortcut Additional information While starting with the shortcut, this inputs is visible in : Expected behavior The program should behave the same way as when launched using menu. Metadata Maintainer information:
Woah, it doesn't seem to even have a PATH environment.
New way to reproduce the issue : when the feature to restore previous window after a logout/login is active, it restarts the application with the same issue.
Applying the fix from fixed this issue.
I cherry-picked and it fixed this issue for me; however my KDE windows are all still borderless.
Hmm, that sounds like kwin died.


Describe the bug bazel broken on darwin in nixpkgs HEAD () To Reproduce Steps to reproduce the behavior: to build bazel on darwin Expected behavior Able to build bazel on darwin Additional context might be related to Metadata Please run and paste the result. Maintainer information: cc:
The bazel build is passing LDFLAGS flags to the compiler instead of the linker. Those should be prefixed with or moved somewhere else.
Clang used as a frontend should accept linker flags.
Flags were in .


Describe the bug Installing nomachine-client fails To Reproduce Steps to reproduce the behavior: to environment.systemPackages Expected behavior It should build the derivation Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Metadata Please run and paste the result. Maintainer information:
I tried overriding the hash (any tip on how to more properly do this would be appreciated), but still got build errors in my under environment.systemPackages result:
There's a PR to upgrade : I this to my and it seems to be working for me:
Yep, this is because NoMachine removes each old release as soon as they make a new one. To combat this, I'll add to the sources list when the update is done.
I was finding at the time that even overriding with the latest URL and hash from the nomachine website, that it was failing to download the whole blob. I could do it from my browser, but it seemed to abort/not download the full size via nixos
Oh, that's strange.. Thankfully, it seems to work just fine now :)


Describe the bug I've tried building two packages from source on my new MacBook Air running macOS 10.15/Catalina ( and a custom expression for ), and both times I get the same set of errors involving Xcode/iOS simulator/permissions/etc. It never seems to start to the build. Example: I don't know for sure whether it has to do with Catalina, but I never received these errors when using 10.14/Mojave. To Reproduce Steps to reproduce the behavior: Nix on a Mac running Catalina. I used the instructions . to install a package that has a source-based build for Darwin such as . Expected behavior The package should install or at least give me errors related to the build rather than Xcode/iOS simulator/permissions/etc. errors. Metadata Maintainer information:
iterm2 is currently broken on Catalina. I remember to have it fixed locally months ago but didn't find the time to open a pull request.
I was just using iterm2 as an example. The errors I'm receiving are generic and occur for any source build using Xcode on my new computer running Catalina. Separately, I also remember iterm2 being broken while I was using Mojave. These are different errors.
Could you test my pull request that should fix this issue (at least for iterm2)?
just tested and it works, thanks! But what are and ? I can't find those documented anywhere.


Update certbot Current packaged version is 0.39.0, upstream version is 1.2.0.
Fix in


I'm thinking of bringing this line back: and getting rid of nixos/modules/misc/extra- Does anyone have objections? I fully buy the ability to pass arguments in the module system using , but if it doesn't work (and breaks in a horrible way) for the most common use case ( in imports), that seems bad and the cost of restoring the old way seems pretty low. Anyone have objections? I can make the change if nobody objects. Ideally, I'd like it in 15.06, since it's getting in the way of some work I'm trying to squeeze into 15.06. cc
IMO our only choices are to do this or to set as a prerequisite (perhaps enforced using ) that points there. No strong preference either way.
Yeah, this is probably the best solution.
Cool! Do any of you know of VM tests that would suitably make sure I don't break anything too obvious by making that change? I'd obviously rather not make the change and then discover a week from now that I broke someone's key use case :smile: I'll be making the change this evening at this rate.
Any thoughts on having set using scopedImport? That way stays NixOS-independent. But not a huge difference IMO.
I don't see how adding back could break anything.
Famous last words! :grinning: But I agree, as long as it evaluates at all it's almost certainly fine.
That sounds more complicated than the one-liner suggested by


Describe the bug The description of is: Path to the unix socket file on which to accept FastCGI requests. This option is read-only and managed by NixOS. So i can't set it. But how can i figure out how the socket path is now? Please add an example to the description! To Reproduce Steps to reproduce the behavior: option desciption Expected behavior Useful description. Metadata same in 19.09 and 20.03 Maintainer information:
The point of the option is that you don't need to find out, just reference it. That being said I agree with your issue and it would be helpful to set an example
The point of the option is that you don't need to find out, just reference it. Sure, that works in but i have that path explicitely in my webserver config which is next to the content, e.g. . For reference: The path is actually as i set it before: So i can just remove the option from my .


Describe the bug Trying to build a combined TexLive that includes Biber (e.g. ) results in failure on darwin. This seems to be the relevant error: To Reproduce Steps to reproduce the behavior: , where Expected behavior The build should succeed. Additional context The build succeeds in the example above if is omitted. Other schemes that include Biber, like , fail with the same error. Metadata system: host os: multi-user?: sandbox: version: channels(matt): nixpkgs: Maintainer information:


Describe the bug Haskell derivations: behaviour of in regards to changed in 20.03. Projects relying on the old behaviour will break. A number of Haskell projects I work on use to make test dependencies and build tools available in the environment when invoking . PR changed the implementation of the attribute which subtly changes the effect has. Using instead is a workaround for this (or possibly the function I should've been using all along). I believe I was using incorrectly but it is difficult to be sure, because the expected usage of and is not documented (AFAIK). Using In 19.09, ( ++ ) produces: In 20.03, ( ++ ) produces: is present in 19.09 but not 20.03. Interestingly, is not present in either. If we instead use : we get the following results in 19.09: and in 20.03: and are present in both. So, using in and does exactly what I want (with the version being a bit cleaner). The "fix" for this issue might just be to document the intended usage of: , , , , , , , and a bit more clearly (if not already - sorry, I couldn't find any). To Reproduce Steps to reproduce the behavior: (). it and cd into the directory. the following commands in a : where the invocation is one of: number of convenience make targets are available too. Expected behavior I expected to make and available in my shell.
cc as the author of , (who I think wrote the original version), and (who did an extensive review) We should probably have documentation for this, or at the very least a note in the release notes for 20.03.
Side question: how did you print the result of in the context of your actual package?
So I created a small nix file something like: Then:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I think this looks correct to me. Nevermind the build-time vs run-time distinctions I am usually harping about. The most important thing to understand for this is just like the regular generic builder always did, the now respects the different type of inputs parameters stating Haskell vs non-Haskell, and uses that instead of the predicate it used to sift between the combination of everything before. tl;dr and items always don't become in env, and instead get passed on to the , while and do become . On the build-time deps side, including the tools, whether or not something was written in Haskell doesn't matter, so they all become .


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


Describe the bug When writing , it was important to ensure that the .lego state directory was common to all certs to ensure that new accounts were not being created for every certificate. The rate limit on new accounts is 10 every 3 hours. This is fine for most cases, but in my deployment I have 30 different domains to request certificates for, and that's after a lot of deduplication and grouping of domains. As of this has been changed such that all certificates get their own state directories, and thus their own account credentials. As pointed out, the account directory can be symlinked using preStart scripts if necessary. I feel this isn't a matter of migrating user data but more about maintaining compatibility with existing setups like my own and also avoiding rate limits in LE's service. This should be part of the module's configuration by default.
cc and whoever else I'm missing...
I have been focused on getting a mail stack in Nixos working over the past week and I missed that PR and other things :/ sorry about that. I would've commented if I had seen it sooner.
Seems like reverting for now would probably be for the best; multiple certs for the same domain seems like a less important feature than not spamming LE with account creations. It should be possible to reuse the same account while keeping the certificates split, but maybe we'll have to make some ugly symlink forests? I wish lego's CLI was more explicit.
Well that or, we can patch in symlinking of accounts directories back a folder. I think it wouldn't be too hard, I can prepare a PR now
You before self-merging the PR and backporting it to 20.03; could you please subject your changes to critical infrastructure to wider review in future? It's quite frustrating to work with Let's Encrypt engineers to make the NixOS service well-behaved, only to have a change merged and backported that runs roughshod over rate limits and can potentially result in hundreds of certificates being renewed at once on upgrade just to avoid incorporating , with less than three hours between the PR being opened and merged, and only one recent contributor to the service being pinged. It's a lot easier to fix issues before merge than it is to rush to fight fires after something's hit the channels...
: merging every certificates in a single directory leads to this issue: It was considered blocking for 20.03 because it broke a behavior that was authorized and expected in simp_le’s age. (The idea of symlinking the account folder was proposed, but since noone reacted noone implemented it I guess)
I saw that issue and I don't intend to reintroduce it, but sharing just the accounts folder would fix this issue without regression. Of course, I will test and ensure that is the case on my system first but rest assured I have no intention to completely undo
Thanks :bow:
I created a I still don't fully understand the use case behind having multiple certs for the same domain? Surely, on a single system, you would only want one certificate per domain, even if they are for different services? Also I did think of an issue with the .lego folder as a whole... if a user uses different user and group for 2 certificates then 1 of them will own the directory and the other will not be able to write to it. I don't know if we want to support that sort of configuration? It would certainly prevent us optimising around rate limits, but it is solvable if the .lego directory is under
You can use different key types (to serve both RSA and ECDSA certificates for the same domain), or perhaps set other alternate names. In terms of directory sharing, I increasingly think that the only permissions option that makes sense from a privilege separation point of view is to have unconditionally owned by and just selectively add other services like nginx to the acme group for read access (per ).
Yeah I had read that earlier and I agree that an user + group would make sense. How do people feel about a PR for a complete revamp of the module? This was suggested back when I finished DNS-01 due to the number of changes and the complexity of the module at this stage. I would be tempted to at least try and do this (now that I have the time again), and see what can be simplified. It's becoming quite the monster.
: if you want to completely rewrite the module, you might be interested in my recently listing of some issues regarding ACME: I think the last one might be very annoying: once a certificate is created, changing the list of domains in the certificate won’t work (in other words, in the current state of the module you cannot add or delete domains from a certificate after it’s generated)
Yep also started tracking that issue already :) I think that one is resolvable by writing some file that hashes the domains + extraDomains, and takes action accordingly, but RemainAfterExit is a bigger bummer. I'll continue conversations about a rewrite over in that issue.
It was reviewed by and Catching ratelimits is not something one can easily test or fix. If one has 30 certificates they will run into certificate creation limits, in which only SAN certificates would help. The needed migration code was posted on Discourse and the Github issue for those that run unstable (Lego in ACME was never part of any stable release).
PLEASE backport this to 20.03, since it's a serious bug, with effectively completely breaks the lets-encrypt-certificate-renewal in 20.03 if more than 10 certificates are used on a server.
It was backported already. Are you actually experiencing issues? If so; please open a new bug for that
I've updated a server to 20.03 today, and I'm experiencing exactly this issue.


Describe the bug Systemd ships dbus system services (in ), which are used for dbus system activation (see ) This includes some of the units shipped with systemd itself: We currently don't have the proper tooling ready to make these available in NixOS. Also, we shouldn't blindly enable all. For example, we might not want to enable `share/dbus-1/system-services/org.freedesktop.resolve1.service, if resolved is enabled. Originally discovered in , but it always hasn't worked, so it's not a regression. Notify maintainers
I wonder if that's why every program I have that uses dBus in some way or another, spits from time to time:
Can you tell me which programs those are?
Sure, from , prints: I'm using as my display manager and I'm using as my desktop environment but I don't use . Not sure if that matters.. EDIT: Currently I can't identify another program that spits this message, although IIRC I saw it coming out of other programs as well. This could be an upstream issue as well.
It does seem that somehow picks up the systemd configuration; though I do not fully understand how it's just missing the when is enabled
Ah apparently all applications are loaded into dbus by default? Not sure how I feel about that ... so the only reason why resolved wasn't working is because we didnt included unit file in Easy fix! All the other services already work!
It seems we do, but we shouldn't do that. If we try to not restart , changes in there don't get propagated. It should just use nscd like everything else. can you file a PR removing this?
reopened, as got reverted.
I've found another example for: prints:
Another symptom is:
I'm not sure if that is a symptom of what I am solving here. I recall recently running into the same issue and I think it's a problem with how we set up user environment in certain desktop managers.
Should I open a distinct issue then?


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


Describe the bug A clear and concise description of what the bug is. The package fails to build. It errors out during the installation of bash completions with "Permissions denied". To Reproduce Steps to reproduce the behavior: -build -A mosh Expected behavior Successful build Notify maintainers Metadata on Maintainer information:
The breaking commit is the bash-completion update from 2.9 to 2.10: . Any idea how to resolve this?
I think you meant to link . Seems to be a regression from incorrectly dropping by ( in ). The "wrong" prefix comes from . A possible alternative would be to drop the dependency on for (if there's a correct fallback - since we don't actually the prefix from anyway).
I think removing this patch was correct, as the functionality introduced in that patch was to 2.10, however a program needs to define instead of when reading variable, which may necessitate patches (which could be upstreamed). It's unfortunate that the upstream decided on different approach than what was done previously, but trying to preserve the old behaviour would cause more issues in long-term. Let's not overcomplicate things when some of upstream projects already have code that uses when using = 2.10. I imagine this is the line that needs changing:
sorry, my assumption about the patch was wrong then :o And thanks for the fix :) Edit: And I agree that we should follow upstream then.


Describe the bug do not run. To Reproduce Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. Maintainer information:
meets the same error.
I think I might have the same issue with solargraph: The same command from nixpkgs-19.09 seems fine: Possibly due to the bundler changes in ? EDIT: Hm. But in a docker container (lnl7/nix:2020-03-07), runs fine. Something in my environment? Or darwin weirdness?
I had a similar issue and I found that my global bundler config was the problem. changed the generated binstubs so that the environment variable is no longer set which I think means that bundler will now use from the global config if it exists. This seems to result in bundler looking for gems in the wrong location. A possible workaround is to set using an environment variable instead of using the global config since this value will be unset by the generated binstubs but will still have an effect when bundler is used from somewhere else. There is also the environment variable which causes bundler to ignore all configuration but that might have other unwanted effects.
I marked this as stale due to inactivity. →
Do you still experience the issue? nixos tests of the service are passing and I'm unable to replicate on the current nixpkgs or even in commit
Yes. and don't run. I'm in nixos-unstable .
I removed in then both programs run fine.
Hopefully or a similar change will get merged and prevent these problems. I've seen a few issues like this get reported.


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


Describe the bug KDE has trouble with some SVGs, particularly the one bundled in alacritty. To Reproduce Steps to reproduce the behavior: alacritty Expected behavior The icon was properly rendered. Screenshots See picture of gwenview vs. inkscape vs icon in my taskbar. ! Additional context It seems alacritty bundles a png for KDE, as well as a high compat svg, I'm currently trying to make an overlay to fix this. See:


Describe the bug Since switching from to I needed to switch from to , otherwise the system does not boot anymore. To Reproduce Steps to reproduce the behavior: system on lvm-inside-luks using either or channel password - gets accepted correctly - LUKS seems to be working does not boot - complains about missing root device Expected behavior Would boot :) Screenshots : ! : ! Additional context All my config for this machine starts from - I link this file in place of Notify maintainers maybe ? <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata Please run and paste the result. ^ using channel with kernel right now Happy to help debug this if needed :)
What filesystem are you using? If it's a mainlined filesystem, I don't believe hardened should've broken that. But it's probably depending on which is disabled in hardened.
Thanks so much for the reponse :) It's for , hopefully still mainlined ? ;) I can try to compile the kernel with set but otherwise with hardened settings enabled and see if it helps ?
Sorry, this is my fault! Yeah, my guess is that we need to re-enable AIO. I did notice some additional harmless-seeming warnings at boot that seemed AIO-related when writing (which switched to a patchset that disables AIO by default), but I guess it didn't affect any of my systems because they use ZFS. I was hoping AIO was only required by marginal things (like Oracle...), but LVM is pretty important. Given that nginx also uses AIO per , it might be worth explicitly turning it on in the default shared Kconfig (as I did for System V IPC in the original PR). I'm not sure if the AIO code is known to be particularly crufty by Linux standards or if it's just a general attack surface reduction thing; a few of the linux-hardened defaults are a bit better-suited to the Android environment than a desktop Linux distro. credits to the original linux-hardened author's Android-based which makes me suspect this might be the case here. Here's a nixpkgs diff to re-enable AIO: It'd definitely be good to know if this fixes things for you. should be enough to test this. If you don't want to use a custom nixpkgs then you can do a fiddly thing like the definition of  in .
Also, this would be pretty easy to test for, so if this change fixes it then we should also update the hardened test to use LVM.
Heya, good news ! One kernel compilation later - I'm back to running thanks to you :) I tried the route and indeed it worked. For the test - I think that would be awesome, to catch things like this in the future :)


Describe the bug Riot-Desktop -Security & Privacy Under the "Message search" heading, observe: Riot is missing some components required for securely caching encrypted messages locally. If you'd like to experiment with this feature, build a custom Riot Desktop with search components . it links to here: Notify maintainers cc: Metadata Maintainer information:
Would be fantastic to have built with . I tried building it myself but couldn't do it. :cry:
Just stumbled across this myself. What's the current state on this? What needs to be done before this can be fixed?
So, element seems to use its own build system to build these native dependencies. It tries to download and build those itself with cargo and stuff. Seems quite complicated to package.
I would like to add that support for desktop notifications would be also appreciated. (They showed up on Arch's version, at least) Edit: This problem has been resolved since
I made some progress. This solves the issue of downloading the hakDependencies. Unfortunately they are not locked in any way, so we need to lock them at packaging-time (is that even a term?) by adding them to and Since yarn2nix always runs yarn with , we can safely ignore the upstream reasoning for fetching them outside of yarn dependencies. I'm now at the point where it tries to build seshat in the element-desktop derivation, but unfortunately they don't provide a Cargo lockfile. I'm working on resolving this problem upstream: <details</details
It turns out to be much more complicated, because the cargo build of seshat-node-native calls , so we have multiple layers of npm calling yarn calling cargo calling npm. With lots of things being downloaded and executed. It's a huge shitshow.
Is there anything we could do to help fix building with encrypted chat search working on NixOS?
I poured some (many) more hours into this today. I can build the two native modules, matrix-seshat and keytar, both in a seperate derivation and as part of the element-desktop build. However, I can not build them correctly against electron's node lib, so when starting the compiled thing, it refuses to load the module. Attempting to build against electron gives a mystic error. Or the second approach, with everything in one derivation using the hak tool: <details</details<rantHonestly it's just a horrible build system. hak and neon and so on don't give any consideration to users who want to build the libraries in an environment without an internet connection. </rant If you can find a fix for the error, there shouldn't be much work left.
I think I found the solution to that error: Upstream is using Electron 12.x while we are using Electron 13.x.
! PR incoming :sparkles:


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


Describe the bug The package is supposed to vend a binary called . Instead it's vending a binary called . The upstream repo has a Makefile that explicitly passes to . I don't see any equivalent in our package (which bypasses the Makefile). This is a problem both because of breaking expectations, and also because the package makes the assumption that provides a binary called . In particular, the script tries to invoke the binary as part of the subcommand. To Reproduce Steps to reproduce the behavior: what binaries it provides Expected behavior It should provide . Notify maintainers Also the maintainers, in case the resolution is to change to use the name instead of : Metadata system: host os: multi-user?: sandbox: version: channels(lilyball): nixpkgs: Maintainer information:
It's possible to override the buildPhase in to run make. However in this case it might be easier to just perform the remame with a in .


Describe the bug Error build php packages. To Reproduce Steps to reproduce the behavior: Run Notify maintainers Build error occurs after this PR Build log:
After this PR error build php. cc
fixes it


The I wrote is failing on (): The problem is that when machines reboot in quick succession, consensus (and cluster leadership) is lost permanently, and 2-of-3 servers cannot continue to serve requests. I have debugged it and found that it is already broken since (), but it was noticed only now. :red_circle: This is why we should run the relevant tests for every PR and should show big red warning signs when they fail! In any case, I have bisected the problem to be commit , introduced between Consul and . I have filed an upstream bug: I also found a way to make the test pass: But I don't think that's good, because I think this is a fundamental issue with Consul that affects operations (the 2-of-3 HA promise being broken), so I think it should be fundamentally fixed, and that the test is right. NixOS 20.03 still has Consul so it does not suffer from this bug, but the next NixOS release will. CC as previous consule package contributors.
IMO we shouldn't even use attr, but always refer to concrete version, like or . Seamless major consul upgrade is fine in docs, but disaster in reality (happened twice to me). That doesn't quite solve this particular problem, I know.
Yes, the key thing is that Consul doesn't permit downgrades of its state in . I would thus also always recommend to upgrade non-point-releases separately from NixOS upgrades.
Honestly I kinda wanna make a few changes to most of the Hashi packages and tests soon to provide more stable versioning (and reliable testing). I'll start cleaning it up this weekend hopefully
Upstream has a great explanation and recommended fix: Test fix and more tests in PR . Key change: . I recommend every Consul user to read that linked comment and the updated test to understand the upstream-recommended rolling reboot/upgrade procedure.


Describe the bug It should be the path to ca- To Reproduce Expected behavior No error happens. Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(mnacamura): nixpkgs:


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


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


I am failing to install on right now: What more details should I provide?
perf fails on kernel 4.1 and 4.2 only
for an (arguably hacky) fix.


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?


Describe the bug , a package which requires PySide2, fails to install, either system-wide, nix-env local, nix-env global, or with home-manager. To Reproduce Results Running the above command: Expected behavior Syncplay installs correctly without error. Notify maintainers pyside2: syncplay: Metadata Please run and paste the result.
This not only affects syncplay. Many other dependencies are broken as well. Freecad for instance does not build either.
looks like updating pyside2 to 5.12.6 fixed this issue on my fork:
Your fix looks good to me. Could you PR it?
done,


Describe the bug oneDNN is a dependency of pytorch. Today, oneDNN's are all linux-based but oneDNN actually appears to compile fine on ; its tests just all immediately fail because of RPATH problems. To Reproduce Expected behavior I expect oneDNN to build and check successfully. Additional context I think that this problem may be able to be fixed by adding in on Darwin, much like is currently set and exported. Note, for even more detail/context on CMake's support for controlling RPATH on macOS, please see Notify maintainers Metadata (Note, I am actually testing this using nix flakes, with this ) Maintainer information:


Describe the bug AppImages assume that the gmp library is present on the system, but appimage-run does not include gmp. To Reproduce Steps to reproduce the behavior: +x the appimage Expected behavior The app should run. Additional context I believe it is because of this commit: I fixed it on my end with: Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
I marked this as stale due to inactivity. →
not stale
Also affected:
as pointed out by t-paul, appimage specifically assumes GMP is provided by the system


See e.g. or
I've been hoping for someone else to look at this one, but I expect I have to give it more visibility, hence this ticket.


The current version of qutebrowser (1.13.0, nixpkgs svn-revision: .) packaged in unstable fails to start with webkit backend. Forcing the backend in the resulting error dialog does nothing. To Reproduce Steps to reproduce the behavior: in qutebrowser Screenshots ! Notify maintainers
The qtwebkit backend was disabled in . Apparently at the time there was talk about dropping the backend but eventually they decided to keep it for a while. In any case here's what the current README says about it Soo, we could revert the commit but it seems it's going to be anyway. This is the reason, it looks like a variable that points to the qutebrowser executable is not actually resolved:
Thanks for the info regarding the readme and webkit. I'm pretty new to nixpks. Let me now if this would be a viable solution: and I'll make the PR. Also, where should I branch off of and what should be the target branch for my PR. It is the best I could come up with, because webkit and webengine depend on to different versions of qt5 so, we cannot easily have qutebrowser depend on both.
You can just revert the commit I mentioned: that should take care of also enabling qtwebkit by default, which is probably what you want. To make a PR you should target the master branch, also take a look at the .
Hmm... I don't really know, what to make of this part: in the current version it reads: and reverting just the other changes gives me build-errors.
Uhm, try something like this:
Now I get the original import error on starting qutebrowser, when I have set to . Maybe was the right solution after all, because that at least worked.


Dropbox does not work for me after the last update to version to 3.8.5 (commit ). The daemon starts, but no activity at all can be observed (it doesn't sync nor start the notification applet). If I start the old version that I still have in the store (3.6.9) it works. I run nixos on 32bit. I made several attempt: unlink/relink the computer from the dropbox site; restart with fresh ~/.dropbox and ~/Dropbox dirs; etc. Nothing works.
/cc author
does output anything?
also, which channel are you on? I just set up a nixos-unstable 32bit vm with dropbox 3.8.8 (not yet pushed) and it works fine
It's probably, because with 3.8.4, dropbox' qt dependency has been upgraded to 5.4, while current nixos-stable is still on 5.3 I bet you're on stable, right? Not sure if we should backport qt 5.4 to stable, or just downgrade dropbox to 3.6.9 and hope it keeps working till there is a new stable release.


Describe the bug fails to build when attempting to cross-compile to aarch64 on : To Reproduce Expected behavior builds without error. Metadata nixpkgs Maintainer information:
I marked this as stale due to inactivity. →
Not stale - this issue still reproduces on current nixos-unstable ()


Mattermost fixed a security issue in 4.5.1:
cc
thanks for bringing this up. I'll create the necessary PRs.


Describe the bug Bazel is currently broken on the latest master, tested at . Bazel was built fine back at . I'm currently bisecting trying to find the offending commit. To Reproduce Steps to reproduce the behavior: -build . -A bazel Expected behavior Bazel builds correctly on Darwin. Additional context <details<summaryError log</summary</detailsNotify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. Maintainer information:
I suppose this might be related:
It's possible. I reverted , , and but I could not verify that it works because gcc failed to build. <details<summarygcc error</summary</details
perhaps or can provide some guidance here. I'm not familiar with how it's all wired up together in nixpkgs.
What’s the content of that fails?
I'm trying to compare the environment of the working build against the one not working. As far as Nix environment variables go, there are no differences except for these that are missing: However, exporting them does not seem to make a difference.
I've tried several different iterations, I'm unsure how to fix this. Anyone else would like to take a stab at this? Things I've tried: Adding clang to the buildInputs, nativeBuildInputs and propagatedBuildInputs. This was a long shot but gave it a try anyway. Exported the and . Added to the and of the bazelrc construction at line 421. Added various files in to NIXLDFLAGS and NIXCFLAGSCOMPILE I also compared the NIXLDFLAGS and NIXCFLAGS_COMPILE between the working version and HEAD, I did not find anything different.
I am not quite sure what the actual error message produced by bazel. However to debug this, you can do to see what flags are passed to the actual gcc.
This is not set if c++ usage is not detected. See also this bit: If you want to include those manually you need to put them in instead. This can affect C programs however.
proposed to check whether it’s a similar issue than what was solved in (He’s not available the next few days though.)
did fix this?
This should be fixed in


According to the 3.5 life-cycle () , the final release has already occurred and is now considered EOL. The jump from 3.5 to 3.6 has already happened in the majority of python packages and should not be a similar situation in which we had to extend python2's life long after its official EOL date.


I am building nixos against the latest head and I get this warning message when running my Makefile command in my configuration It seems like it warns you about the obsolete option even after you've removed it from your configuration.
That's because it's used internally
It should be fine now, I believe. Thanks.


Describe the bug After fixing the the evaluation of the in I realized that it occasionally breaks with the following error: node1: output: PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data. --- 10.0.0.2 ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 4085ms error: Traceback (most recent call last): File "/nix/store/b6m9jif1kib2dqc6fy2ym31vzs4f7hhd-nixos-test-", line 830, in run_tests exec(tests, globals()) File "<string", line 1, in <moduleFile "<string", line 8, in <moduleFile "/nix/store/b6m9jif1kib2dqc6fy2ym31vzs4f7hhd-nixos-test-", line 363, in succeed raise Exception( Exception: command failed (exit code 1) cleaning up killing node1 (pid 6) killing node2 (pid 18) error: --- Error
nix-build error: --- Error --- nix-daemon builder for '/nix/store/g14icd814yvak6syxjimgc6g8y459ki1-vm-test-run-' failed with exit code 1 Please note that the functionality isn't broken per se, on I managed to successfully build it as . Notify maintainers cc
I'm guessing that having the pings be would resolve this, unless we want to assert that actually ensures that the peers are fully connected?
No it doesn't, I already tried this out, the command times out then. I guess that sometimes the isn't configured properly.
The issue is coming from the private key (/run/wg-priv), for some reason, it looks like networkd is sometimes trying to load it to wireguard before the systemd tmpfile gets linked.


Describe the bug The last several Hydra trunk-combined runs have been blocked by (among other problems) a , which was recently back(?) to release-combined in (). When I run the test locally it sometimes succeeds and sometimes hangs forever. To Reproduce Steps to reproduce the behavior: it succeeded, clear the result with (is there a better way to do that?) and try again. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(anders): nixpkgs: Maintainer information:
We have a lot of channel blockers currently, so I recommend to also purpose revert this one. Though it sounds like it's only with issues, so perhaps comment it linking to this issue. We can always re-add it.


, CVSSv3=7.7 (nixos-unstable) CVSSv3=7.5 (nixos-unstable) CVSSv3=7.1 (nixos-unstable) CVSSv3=6.5 (nixos-unstable) CVSSv3=6.5 (nixos-unstable) CVSSv3=6.5 (nixos-unstable) Scanned versions: nixos-unstable: . Cc Cc


If you want root access to an NFS share secured with Kerberos, you need to modify the default . Currently, I override the source, because NixOS has no options to modify : The text is mostly copied from the default NixOS . The only changes are This solution is brittle, and requires manual intervention if the default ever changes. I'm not sure exactly what the NixOS options should look like, but there should be mechanisms to modify in NixOS. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
what about an option like so you can easily override/append values as you see fit?
That looks great. I'm a big fan of RFC 42 :) Just one question though. Can you remove an option, such as ?
Good question. can we bug you for some advice on how you can remove values from a option?
There's nothing builtin for that. The best that can be done is to just filter out values during string generation. Though in INI's case, is also a valid value in INI files, so that might not be a great idea. There is that adds a way to "unset" values, though I haven't looked into it much.
Thanks for mentioning without the ability to remove values would this not work?
I did a double-check on , and it looks like and are actually separate, but related. defaults to the value of . Also, the default value of is already , so removing it in my configuration had no effect. On that note, we may consider removing , as that is already the default. Regardless, your RFC 42 solution should work, even without the ability to remove values.
are you interested in opening a PR? Feel free to use the branch I posted.
I can open a pull request. Just one question: is there a reason the option and variables are called instead of ?
Typo
pull request is up. I fixed the typo and a syntax error.


The package takes a long time to build the individual glyphs using . See also Other distros simply use the release tarball (e.g. AUR ) which already has the resulting 13 MB file prebuilt. Should we do this as well, given that it's a font? CC maintainer:
I'm conflicted: on one hand NixOS is a source based distribution and building from source makes it possible to apply patches and whatnot, but on the other it's just a font without any executable stuff and 1.5 hours is a lot. I guess it depends on how valuable build time is?
It seems quite common for fonts in nixpkgs to use the upstream-release-provided font files; examples I picked randomly by clicking around in : Some fonts are generated by a call to , for example , but there doesn't seem to be a requirement for that. So I propose to make one of the former category.
EDIT: confused with
Ow. Well, that's a good enough reason to switch I guess :) I'll open a pr. edit: or I could Increase the timeout :)
cc
I have a sentiment for source builds but no rational arguments. The above arguments for building from source are reasonable. We also have package for a bitmap version of the font (using build system from Noto). That artefact is not available upstream so we need to build it ourselves, unless we want to depend on Fedora.
Yeah, I'm similar (at least for fonts, outside fonts there's many rational arguments :rofl: ). And I think considering how it times out... It's the best choice for now as there's not a ton of benefit to argue. Though doesn't seem to be incredibly difficult to do :frowning_face.
I think in practice this is still not going to address the root issue that the calling of inkscape is highly inefficient. Hehe, I bet nix being content addressed would make a lot of us much happier with not having to rebuild stuff pointlessly.
I'm sorry, I confused the two packages. It's apparently the other one that's timing out on Hydra:
Even with the 5x speedup I found in it'd still take 20 minutes to build it though. If somebody goes through the effort of fixing it upstream, we may want to consider switching back to fully-from-source. But there are 1000s of open-source tasks higher than this on my list :)
Can relate. (says ever opensource contributor ever while submitting 10x README PRs in a day :grin: )


Project description DeepSpeech is an open source Speech-To-Text engine, using a model trained by machine learning techniques based on Baidu's Deep Speech research paper. Project DeepSpeech uses Google's TensorFlow to make the implementation easier. Metadata homepage URL: source URL: license: Mozilla Public License platforms: Unsure
I already tried this with a local clone of deepspeech: But I get this error for unknown reasons:
I guess pip is searching for a python package named sox.
That one doesn't seem to be in nixpkgs, is that right?
Doesn't look like it, you might want to package that as well looks like this would need packaged as well
There is .
I marked this as stale due to inactivity. →
:(
I binary package in , which works fine for my use case (linking to it from Rust). The binary itself works fine as well


Describe the bug To Reproduce Expected behavior It should give me a shell Additional context I can fix it with which is based off 20.09-beta but I don't seem to be able to use HEAD (it breaks for another reason). Notify maintainers Metadata Maintainer information: