Describe the bug addon in chromium does not work. After install addon show errors: "Failed to connect to the main process." "Verify the installation of the plasma-browser-integration package. The running environment of the Plasma desktop environment must be at least version 5.13." "Specified native messaging host not found." Manually run from console not help. To Reproduce Steps to reproduce the behavior: Add to : Expected behavior No errors. Additional context I found issue Everything looks like the same problem but in chromium 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 nix-shell -p nix-info --run "nix-info -m" and paste the result. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Try adding the following line to your configuration:
now And also does not work. Maybe I need to reboot?
That issue is actually unrelated, it has to do with a patch only in our source build of firefox.
I make test with: in . The same error.
I can't reproduce this issue. I just tested in a vm using with this configuration: Are you using plasma5?
Yes plasma5. Looks like it worked for me too. Now all errors are gone. Thanks !
Why are we adding to systemPackages when using the chromium program module? It does this for you.
Just an oversight on my part. You're right, adding chromium to systemPackages is not necessary.
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 .
Thanks - the fix worked for me! Can you please comment on what's the role of package that you install?
I marked this as stale due to inactivity. →
Proposed fix in


To Reproduce Additional context I am building the package on an x8664 machine via distributed build, if that makes any difference. I have also tried to build with llvmPackages8 through 10 and I got the same result. Notify maintainers Metadata Maintainer information:
This looks just like Unsure why it's reoccurring.
Caused by
This is native linux i868? Interesting, it is deciding to build nothing but headers, and then only the dev output is present. I am curious what it decided to build before that filled .
Ah! I bet it was auto-detecting and that gave it something to build, but now the correct arch is manually specified.
I can confirm that reverting fixed this issue.
hopefully fixed in
I'm seeing something similar for 32-bit arm on recent master () , ([build log][]). Do we need to make a version of for ? [build log]:
I suspect that since (and previously ) on i686 is really only building the bare minimum: whereas on : Missing are asan, ubsan related libs and much more. I should probably open a new issue for this.


Project description is already packaged in nixpkgs, but the upstream project has been taken over by new maintainers who have ported it to Python 3 and are continuing development. As far as I know this new version is also used by Debian/Ubuntu (it has python3 dependencies in those distros). I have a local attempt at a new derivation and it Works For Me, but it has a patch in it which I don't think it should need. Also, maybe the original maintainer may want to do the update? If desired I can open a PR with my current state of affairs. Metadata homepage URL: license: GPL2 platforms: Linux
I have limited spare time these days (months), so please be my guest


Describe the bug Edit: After looking at it for a while, it seems the real problem is that this function is too strict: I think it should be something like this instead: To Reproduce Because comes before alphabetically, it's mounted first (which fails). You can read the file using: Expected behavior The list of file systems to be topologically sorted. Additional context Originally found this while trying to try out root-on-tmpfs. Notify maintainers Couldn't find anyone. <!-- 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): channels(jakob): nixpkgs: Maintainer information:
This is also a problem when using since the dependencies are specified in not or and for this problem is not enough to fix the issue. The option sugested by in would solve it. Actually the only reason the current ISO and netboot images aren't broken because of this (they use ) is solely because and comes alphabetically before .
I marked this as stale due to inactivity. →
This is still an issue, and for me a fairly big one, since I can't generate secrets with agenix with my current setup:


Describe the bug When receiving email notifications from , for example after a scrub, the hostname is missing from the subject and from the body of the email: To Reproduce Steps to reproduce the behavior: up ZFS and zed ( and ) a scrub for the email Expected behavior Hostname should be present in the subject and body of the email. Additional context Try adding the following in your configuration and notice how the returns nothing: Notify maintainers Metadata Please run and paste the result. Maintainer information:
I just noticed in my logs: So the environment is probably missing something for the command to be available.
Requires net-tools
Please make a PR to add it to the ZED path as we did for the other tools required in ZED.
I will but I have never committed to this repo so it may take time before I learn what is required.
Also, it would have been nice if such a problem would not have been silent, maybe by using in bash scripts.
you need to add it here: You can rebuild your own NixOS using the instructions from here:
I submitted the PR


Describe the bug does not start up. To Reproduce Install and run in the terminal. Expected behavior A TypeScript REPL should start up. Additional context It's possible that the peer dependency on TypeScript is not handled properly. Notify maintainers Metadata Please run and paste the result.
I am not sure how to fix this as it is not a dependency of the tsun package, it is defined as a peer dependency and this expression is generated from a simple JSON file. Of course it should be fixable with overriding and specifying typescript as a dependency, but I don't see any other packages that have these kind of overrides, thus I am not sure how to do it for node packages. I know some other generated packages have some overrides that adds missing dependencies/applies patches and things like that. For now you should be able to include both packages (typescript and tsun) to get it to work.
I've tried , but this yields the same error message as above, which I produced with my main , where I have Is there a more idiomatic way of installing , either locally or globally?
Ah, it is a bit confusing, but seems you need nodejs as well, this works for me: It seems without nodejs it won't setup the which is used for the modules to be found.
In this works for me. But when I have all this in my and install a new generation, fails with the same error as before. I've tried having in but then I get after installing from .
It is the that needs to be set, so this would work: I see now that there are other overrides in the so I should update this package with this code there.
The correct fix might also be this: As the reason why it is not included by the autogenerated expression is due to it being part of peerDependencies which is not included by default in the node2nix command.


To reproduce: create new (ethernet) connection, with ip4 set to link-local. When ing the connection, the following errors are thrown: An reveals the problem: I thought the following would fix it (): but this creates a new problem:
add that new user when NM is enabled in the nixos module.
Did suggestion work? I was just bitten by this issue.
Did not try it futher yet. If you want you can try it.


The metasploit package no longer builds. I've updating it myself, but I haven't been very successful. If someone could point out my mistake I would gladly correct it and submit a PR.
Is this issue still relevant? , (pinging you because you are able to close this if necessary)
Looks relevant to me, as there was no commit to metasploit that updates or fixes it. Why do you think I isn't relevant anymore?
Current version: 3.3.1 Last stable version: 4.12 We definitely need a maintainer. is there a tag for ?


Project description This flag is available in most other major distros. It is necessary to enable screen sharing on wayland inside of chromium, combined with xlr-desktop-portal-wlr and pipewire. It requires the build flag and a dependency on libpipewire02. See as an example. Metadata homepage URL: source URL: license: mit, bsd, gpl2+ , ... platforms: unix, linux, darwin, ...
that would definitely be nice to have :) I actually also noticed this but unfortunately cannot test this easily as I'm not using screen sharing. If you could contribute a PR that would be awesome (but be aware that Chromium does unfortunately take quite some time to compile). Alternatively (but less preferably) we could make the required changes with the next update and test the core functionality (as always) and you could test screen sharing after the new version is available in the binary caches. Additionally we would need to package in Nixpkgs to make this work on wlroots based compositors. On Gnome/KDE this might work out-of-the-box, but I don't know what they currently implement/provide.
was just merged w/ . I'll try building chromium w/ the flag - as you say it takes a while, so I can leave it overnight and give it a shot.
how does the situation look like with ? Is the flag available there, as in, screensharing with wayland already works there?
yes, it's available in google-chrome. ! I'm still trying to get it to work with xlr-desktop-portal-wlr - I've done this in the past, but it's not working out of the box yet with
And just to make sure, you also did set as described there?
yes I did. I'm almost got it working I think. There are a few issues out of the box: -chrome is missing the pipewire 0.2 runtime dependency, so I it as (I'm on 20.03 so pkgs.pipewire is 0.2): .pipewire service doesn't work - it doesn't seem to be setting up the path correctly. I'm trying to fix this now: My current config on 20.03 looks like: Where is the same package that was recently merged.
yeah, I'm currently already looking at it - pipewire wants to execute , but it's not in . We can patch to contain the absolute path. I'll check if it works and will get back to you.
Btw, we /really/ need a sway NixOS test, and better documentation on how to use sway. I was trying stuff until it worked, and does autologin me into a sway, but there might be a smarter way to do this, without also starting X.
The sway recommendation is to just run sway from the terminal after login - that's how I do it at least. I was able to workaround the environment issue by doing (but this is a kludge I think and shouldn't be necessary). But unfortunately it's now crashing and I'm not sure why:
Yeah, even my sddm config I also had to , otherwise pipewire complained about not being able to reach dbus: Afterwards, it segfaulted, as it wasn't able to find ; I patched to be able to find the path to , and that error message is gone. Now (apart from not being able to find bluez or rtkit) it /might/ only be some version incompatibilities, not sure: I'll see if I can get as far with your chromium PR, will merge that then, and also submit the pipewire patch.
Okay, with the pipewire patch and , It seems I'm able to share at least my own application window :tada:. I don't know yet why the alacritty window nearby isn't shown, and why "Entire Screen" is black, but that's probably due to me running sway inside X via ssdm.
pipewire PRs:
I don't think you're using pipewire in that case. xdg-desktop-portal-wlr only supports full screen sharing atm. If it is black that means it's not working. By the way I had to add pipewire02 to my system packages to prevent xdg-desktop-portal from crashing. But now there seems to be some incompatibility in the pipewire service logs when chrome tries to connect:
you should be able to cherry-pick the to not have to manually add this to $PATH.
Thanks! I'm suspecting google-chrome is compiled with a too old version of pipewire. Enabling pipewire debug logs, it seems to be sending an incompatible format to the pipewire server (similar to ). I have got this working with chromium compiled against pipewire 0.2.7 in the past, so I'm pretty sure it should work assuming the client library is recent enough. Once the chromium package has that flag enabled I'll try to retest.
I just confirmed my last comment by building chromium locally w/ rtcusepipewire=true. It works perfectly for fullscreen sharing.
Hmm take that back - it worked the first time but not anymore :/. Not sure what lib is missing where.
Seems like xdg-desktop-portal is crashing:
This might be yet another version incompatibility problem. I propose merging (as it's built with 0.2 everywhere else too), and then see if we can get it to work if the system pipewire also is 0.2. I asked upstream about these problems in - maybe 0.3 needs to support 0.2 clients for some time until we should switch.
Heads-up: the bad client situation should have been fixed with the latest pipewire release, PR at
Thanks for your help! I'm still getting the xdg-desktop-portal crash, however. I'm guessing there is something missing from my dbus environment - or perhaps it's trying to access a file/directory not available in nixos.
could you open a new issue with some more details, like logs etc.?
Okay, I made


Project description Cross platform chewing user phrase editor Chewing editor is a widely-used bopomofo input method for traditional Chinese, and chewing-editor is the tool to edit the database of user phrases stored by the input method. Users of chewing will need chewing-editor sooner or later. NixOS have chewing include as a fcitx engine () that can be used in the module, but not chewing-editor. Metadata homepage URL: source URL: license: gpl2 platforms: unix
The corresponding pull request is merged. Closing.


Describe the bug pitivi crashes with gtk errors on startup. To Reproduce Steps to reproduce the behavior: in terminal and press enter the error message: Additional context This happens at least on wayland/sway. Notify maintainers as he did the last change to the packet and no maintainer is defined. Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
I get a different error with nix on Ubuntu on commit : On on Ubuntu it works.
PR in .


Describe the bug cannot be built from current master due to failing tests. To Reproduce Additional context Relevant logs: Notify maintainers Metadata Please run and paste the result. Maintainer information:


Describe the bug All last builds on Hydra have failed because of (top level package). E.g. Nr Status -- -- 1 Cached failure (log, raw, tail) (propagated from build ) First broken build 2020-06-05 19:14:56: Nr Status -- -- 1 Failed (log, raw, tail) (propagated from build ) Log: To Reproduce I can't reproduce the issue locally though, does compile. Expected behavior Hydra job should not fail on mariadb. 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 $ nix-shell -p nix-info --run "nix-info -m" system: host os: multi-user?: sandbox: version: channels(theo): channels(root): channels(arsleust): nixpkgs: Maintainer information:
Reproduction: are you sure you tried it on darwin? (That's what fails on Hydra.)
Probably caused by , Darwin doesn't have .so 's right? cc


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


Project description Caprine is an unofficial and privacy-focused Facebook Messenger app with many useful features. Metadata homepage URL: URL: mit platforms: linux, darwin
I marked this as stale due to inactivity. →
I'd love to have this, too. I tried to take a stab at it a while back (using Atom and other Electron apps as a base) but it kept core dumping. I'm going to have to give it another try soon.
I have a binary package PR ( ) dangling for a long time. You may want to take a look.


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


, CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) CVSSv3=5.3 (nixos-20.03) Scanned versions: nixos-20.03: . May contain false positives. Cc Cc
CVE-2018-: imap_mail fixed in 7.2.14 and 7.3.0
CVE-2020-7067: EBCDIC decode fixed in 7.2.30, 7.3.17 and 7.4.5
CVE-2019-: fixed in 7.2.30, 7.3.17, 7.4.5
merged - closeme


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


Describe the bug lacks an option to exclude some packages. Expected behavior xfce service should provide an option like in GNOME3 service. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
I marked this as stale due to inactivity. →


borgmatic is simple, configuration-driven backup software for servers and workstations. Protect your files with client-side encryption. Backup your databases too. Monitor it all with integrated third-party services. Homepage: Source: License: GPL v3 () Platforms: UNIX, Linux, Darwin (I guess anywhere Python is supported)
I marked this as stale due to inactivity. →
Up!


Julia 1.5 is out, see: and we don't have it packaged. More over, see how defines our other Julias: Several issues: is pointing to a TLS version which is old IMO. Certainly there are breaking changes seen in , but since Nixpkgs is a somewhat rolling release distro, are we going to keep these older versions and default to them for ever? I've once tried to reach for the community to hear if there's a strict policy regarding such scenarios, but Anyway, I'd like to propose a change that will keep only the LTS version and the latest - currently 1.4, and perhaps make the attribute , point to the latest. Any thoughts from maintainers or users? cc
Also, now I noticed all of our Julias fail to build, e.g:
I agree. And the 1.5 release candidates are out, so this will become the latest version in the near future. Last time I looked, the package built the same deps for all versions, including 0.7. In versions 1.0 and later, there are actually fewer dependencies (e.g. arpack and fftw have been dropped), so the package should be cleaned up to not include these unnecessary libraries in the build. I also think the default version should be the latest version (i.e., unless somebody explicitly installs julia-1-lts, they should get the latest).
OK I'm glad I have your support. I'll let this issue stay open for a while and hopefully I'll be able to take care of this a month or so from now.
cc
Back when Julia tests were not so messed up, I think there was often 1 previous version. I guess with 1.3 needing overriding to no tests, it is fine to just have julia-1-lts and Julia 1.4 as julia once Julia 1.4 gets built fine with some tests.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Haven't had a lot of time to work on julia in nixpkgs, so just posting this as a FYI. We used multiple versions of julia at work, but we use a custom derivation, similar to this: We also do not run the tests, but in general it has been working great. Previously we also used the binary builds patched with patchelf, as there were some differences in the structure of the results of the vanilla binary build provided by julia and what we got when building from source. We gave up on using 'system' libraries, and build the releases that julia provides, as julia is very specific in the versions for its dependencies (LLVM patches mostly).
I tried to use that tarball in order to write a derivation from scratch. Here's my attempt: It fails with: Naturally I didn't further attempt to add curl or wget to the inputs, as that would fail in a sandbox as well. I've opened an issue upstream: complaining that that tarball doesn't really contain all dependencies.
I ran with sandbox enabled, and the expression I linked with works for me. So I think it is fine to just add curl to the deps, as with the full tarball, it isn't actually used.
There is another approach to avoid running tests: using precompiled binary. I tried downloading the 1.4.2 binary from and then afterward ran on the binary, then I got a running Julia interpreter just like that.
We did the same for a while using code similar to this: Unfortunately, we actually sometimes need to patch Julia, so we switched to the julia expressions from source, that I posted earlier.
Thanks that expression works well thanks to . I'm testing it now.
OK so after a long build, I got a working Julia derivation with these references: And this closure size: Which I must say it is satisfying. The question is, is this how we'd want it to be built? Using all of their dependencies and practically non of ours? Some of their dependencies are required to be patched, according to and they also specify that using the OS' libraries is not officially supported? Anyway I'd happy to get help on deciding this.
does this lead to Julia tests passing? I think for every dependency they patch, it is OK to just use their patched version. I guess it could be nice to use a separate build unpatched (but using the exact same version sounds like a likely restriction), but whatever dependency does not work right away can be switched to bundled.
I think it did, I've set and the build passed but I haven't inspected the log much, but here it is: Currently produces this log but there's no PR yet as I think there are many makeFlags that should probably be set as well. If anyone feels confident to open a PR with this feel free to ping me for a review. I agree with the idea, but what's bothering me is that it's not absolutely clear what versions are patched and which are not - the docs vs what's actually found in is not totally inline. Also, it seems that some of the patches are old, and were suggested upstream (to the libraries) but they weren't merged there for some reason. I'm still investigating, See My current target is to decide what libraries to use our version vs their version, with the preference to use our version, in order to hopefully reduce closure size due to sharing shared libraries. The idea is to decide this by checking whether the libraries have included the patch Julia suggests, and then whether the library's maintainer has released a new version that includes Julia's maintainers' patch, and whether we ship that new version.
does this lead to Julia tests passing? I think this log is cut short before the interesting part…
I've uploaded it here:
Hmmm. Reading the log does not convince me the tests were run… Pity.
Since 1.5 was just released, the title should probably be updated to be 1.5.
Downside with the patching approach, is users lose the ability to compile against MKL, which has HUGE performance increase (last I saw showed that MKL was ~4x faster at matrix multiplication!!). Would need to also package JuliaPro to get MKL. Of course, anything working nothing working, although would be a shame to lose compilation options.
Says
Thanks garrison, I saw that, but I have a feeling it won't play nicely with Nix...although if we go patching route, perhaps could do that during buildPhase
Are you concerned about specifically or all packages that use BinaryBuilder? There are a lot of them. More on this at
As I understand binary builder, that all happens in userspace, but modifies , which is in /nix/store
The installation instructions for do not seem to require root. My guess is that it stores the modified sysimage somewhere in . Am I wrong?
I just tried it with Julia 1.4 installed with Nix, and as I suspected fails to build due to
We need to have a interface - that would support building binary packages, and make the interpreter aware of them. I wish I was a bit more motivated to do this, but upstream disappoints me regarding the humble task of compiling Julia as is, with the right selection of a few system dependencies - no response at all at & . I'm also dis-motivated to explore this aspect, since their build system is of plain makefiles, and they keep patches of dependencies from so long ago, without documenting whether they are needed / used or not...
Nix behind It is a shame to see julia's support in NixOS languish. It seems pretty clear to me that upstream is only interested in supporting the configuration obtained by cloning their repository and typing on a stock Linux distribution. I understand their perspective in many ways, as having julia and all of its packages "just work" requires a lot of care, and building with unsupported configurations is very likely to result in brokenness somewhere in the package ecosystem if not in julia itself. Julia is a bit special in this regard because of its emphasis on performance and also its need to support interfaces to other languages/frameworks that often have weird requirements. I have found that typically, there is very good reason for these patches, even though at times they may not be documented except in git and github history. (Admittedly, I am less involved in upstream than I used to be.)
I think Julia team initially evaluated Nix as their binary distributor () but decided against it—there was a discussion somewhere but can’t find it. IIRC lack of Windows / desire to tie into native pkg management systems were factors. Julia’s does a pretty great job, and uses a solver to properly resolve dependency versions based on constraints. I’ve been incredibly frustrated by the withPackages pattern, at least in python. I constantly run into problems due to nixpkgs ignoring version constraints. There are some other nice advantages to nix of course: binary dependencies are shared across language ecosystems for example, and there are lots of supremely annoying packages (I’m looking at you CUDA...) that Nix makes delightfully easy to install, use, and maintain parallel versions. But until Nixpkgs supports multiple versions across the board, and has a solver baked in, I’m honestly not sure Nix brings enough advantages to bail on Edit: I think the approach done by poetry2nix and Mach-nix are the way to go for Julia packages + nix. yarn2nix is another shining example. I would love to see a solution in this vein—didn’t mean to douse any enthusiasm for people interested in helping improve the Julia situation on NixOS :)
Maybe it is worth to reaching out to Julia Computing folks at to get their attention on ?
We'd probably need to put this information in our attribute sets, just like our Python packages know what deps they need. Hmm that's a bit surprising to hear as the Python ecosystem seems most well organized. Have you ever encountered a real bug with a mismatched version of a dependency with a specific version specified in a package's ? IIRC fails if a version is used and it's not exactly what's available. If you've ever felt there's a certain python package of a certain version missing, have you considered contributing it? Even if not, was it too hard to override it? What do you mean "across the board"? That might be much more harder then it sounds, due to the constraints of Nix it self when being evaluated everytime you run and friends, see It's not a question of whether Nix brings an advantage or not, it's a question of whether there are any Julia packages that are built at other distros imperatively with a , and this produces (or even worse, downloads) shared objects or executables into (not in ), linked to Julia or other Nix deps that do reside in . If the answer is yes, than every Nix user will experience breakage after Julia is updated in his - not necessarily if it's a version bump of Julia, it could be a mere rebuild of Julia by hydra. Yea Mach-nix is an awesome idea well implemented ( thanks for the inspiration :heart:). I've also reached a similar conclusion at . However, this is my opinion for Rust and Go, and I tend to think that for a small ecosystem like Julia, perhaps it'll be too much - it shouldn't be that hard to manage all of these pacakges like Python is managed in Nixpkgs.
I opened
Frequently. Especially with Scipy, matplotlib, bokeh, sklearn, tensorflow, pytorch, etc... Often, nixpkgs used to have it until it was updated. Except in very rare circumstances, we do not keep more than one version of a python package around. I have no interest wasting time working around bugs that authors tried to spare me by specifying precise versions. It seems a sort of cognitive dissonance in our next community that we all care so deeply about reproducible builds, but for convenience often disregard the officially supported dependencies. As a result, there are often subtle bugs in software on NixOS that do not appear on other platforms. (Eg x11vnc crashes, shared memory problems, etc). Nix supports crazy high specificity in versioning, well we past semantic versioning down the the bit in many cases. And yet in nixpkgs, by convention, we remove the old version anytime we update. It’s understandable that Hydra cannot build everything, but it’s always bothered me that I have to pin nixpkgs if I want a build to stay functional over 1+ years. is mostly declarative. Of course, Julia is constantly re-compiling code, and until there is true support for precompilation, I don’t see how it’s possible to use nix store. This is due to multiple dispatch. Suppose I wrote a library to do an efficient k-nearest-neighbor query using some fancy free structure. Perhaps the core algorithms simply require a function for your types. When you write this new function, Julia has to compile all the code in the k-nearest neighbor library for this new type. Thus, it is not possible right now to compile a package on its own as the core pattern in Julia involves extending the function of other packages via multiple dispatch. You can only compile a package in context of the code that is running. Therefore, the Nix store approach is not appropriate. See
I see. You are talking about "authors" of Nixpkgs' expressions? I'm still a bit perplexed, as I earlier said, and correct me if I'm wrong: should fail if is used in , and the exact version is not available. Sometimes (), we do hardcode such version requirement changes in our expressions, but hopefully that's done only when it's justified. I agree (maybe a bit ). Generally I think, every dep's version related issue should be handled by someone like you, who's familiar with python packages you use. I'd at least (open PRs) to fix the issues I encounter :). I see. I guess the situation is more complex than I thought, but I don't think I'd be able to form a strong opinion until I'll get a Julia interpreter from an expression I'm satisfied with. Thanks for the link :).
Unfortunately, this pattern is done constantly (including in my own contributions!). The problem is that, except an extremely rare cases like tensorflow, nixpkgs does not allow multiple versions of same python package to co-exist. Every time we update a package, we remove the previous version from nixpkgs. Confounding this issue, we often disable tests because sometimes the effort is just too high when developers bake in assumptions that aren’t compatible with the Nix ethos (for some reason this seems to happen more with tests then source code...). The most frequent cause of failure is the code needs to download something to run the test. (I’ve tried to lobby in the past that the test phase should be permitted to have Internet access as long as it doesn’t modify /nix/store, but I digress). In any case, the end result is that using a python package on Nix typically means you aren’t using the exact dependencies that upstream declared, and you’re more likely to have a package that despite having changes in dependencies has never had the test run. Thus, amazingly, I’ve had more luck with Julia packages working on NixOS than Python when all other binaries are present in environment.
I don't think there's a strong policy in our Python ecosystem against multiple versions of packages - if this is what upstream recommends. Anyway, the whole topic is out of scope for this issue. Feel free to open a new issue and cc me and who's working hard to ship a 20.09 release.
Yes, sorry getting a little off topic here. I mainly mention it to suggest that our efforts in Julia that start from scratch Can learn from these issues. I’m not too familiar with the new binary builder, but was quite nice in that it would first search for libraries before attempting to install. See this issue for some context: Note that a core Julia dev gave a pretty great endorsement on Nix (albeit back in 2014): I think it might be most productive to do this development outside of nixpkgs, and do it in Julia to hook in with nixpkgs as needed. That way users could seamlessly use Pkg in Julia. I’d love to and have it just work instead of the current hack that I wrote that a lot of people seem to be using ()
Short summary of the Discourse thread: for LLVM and libuv it is essential to use the patches/forks. For other packages it is probably unnecessary to use the exact version specified by upstream.
Thanks for being there with me :). I think I'm gonna work on this once we are through with , to avoid merge conflicts.
TIL Guix manages to package Julia 1.4.1: What's interesting, is that they but they build it with Julia's LLVM patches fetched from the internet - they don't rely on Julia's build system to build it's own LLVM. For similar dependencies which the real system's version can't be used, they do the same. I think we should try to copy this approach.
FWIW I did that in Fedora originally, but I stopped. Since LLVM makes breaking releases very quickly, you'll probably want to move to a new version that Julia doesn't support quite soon.
Maybe I don't understand, but why should I move to an LLVM version that julia doesn't support? Also, aren't the and versions don't introduce breaking changes between minor releases? We could stick to since that's what Guix does and I think Julia uses this version as a base too.
I don't really know how NixOS works, hence the "FWIW". If you used versioned LLVM packages and keep older major versions then it's probably OK.
Just offering a user perspective: Julia provides a package manager that provides mostly reproducible (in a practical/scientific reproducibility sense rather than a bit-identical sense) environments easily from manifests. Increasingly, these environments are isolated from the host OS by binary packages for dependencies being served by Julia. I don't want Nix to manage dependencies that can handle for me: Julia already handles those excellently and conveniently. I just want Nix to handle the (usually few) system dependencies. What I would like as a NixOS user is for Nix to provide me with a working Julia 1.5 derivation that provides: julia, a FHS wrapper or something providing compatible versions of the few things that Julia's binary packages need (just libc, libstdc++, libgfortran; I think. ). When I say "compatible", I mean that these libraries should work with the binaries and with the julia binary provided by Nix. Not all Julia packages are BinaryBuilder-ised yet, so I'd also want an easy way to specify that I want compatible versions of other packages installed (e.g. Qt, cairo, etc). For packages that need python, I don't know if I'd like Julia or Nix to handle installing and managing that. The simplest approach would be to tell Julia to do it (there is pretty good support in Julia for distributing isolated environments of python + packages + dependencies; better than in , imo). I don't know how doable any of that is in Nix, just describing what a good outcome would look like to me.
I think this is quite doable. I would propose that we add a new package, , that is a "batteries included" build that contains system libraries for all common Julia packages. Would this approach work for BinaryBuilder? I haven't used this yet. If not, we could fall back to a FHSuserenv, but I'm reluctant to do so if at all avoidable as there are outstanding nix bugs () that create seg faults in some heavy data processing workflows.
I think that is a good proposal and I think it will work with BinaryBuilder packages (e.g. SDL2_jll). In any case, some approach that works with BinaryBuilder packages should be found because those are a critical part of the Julia environment now :) Some important packages (e.g. GR) still want to build and install their own software dynamically, and that doesn't work well in Nix, but most of those can plausibly move to the BinaryBuilder system (PR for GR ), so I think letting those be broken would be tolerable (and a big improvement over the status quo of Julia on nix). Perhaps we can get something working quickly by just patchelf'ing the official Julia builds for now? (I don't understand how all of this stuff works!)
Is there anything presently blocking just getting julia 1.5 into nixpkgs? I don't care about ecosystem working with nixpkgs, just a good ol' fashioned julia install.
yes, see
If you just want Julia and don't mind about binary packages breaking you can just download Julia from the official site and patchelf it. On Sun, 4 Oct 2020, 09:32 Tyler Benster, <:
On the there was also the idea floated to patch to patchelf dynamically loaded binary dependencies.
Guix has a Julia package and it works quite well. Perhaps some ideas can be borrowed from there: It'd be really useful to get Julia working on Nix. It's the only big outstanding thing that doesn't work and prevents me from migrating some servers in my organization.
I tried to copy their expressions in and it doesn't work yet, but there's also another seemingly working attempt by at .
So, do we want anything else now that 1.5.3 is packaged (:greenheart: ? I think we: 't need clean up the expressions a bit - not use the file if it's not shared. I did (2) along with the julia_10 fix in As for (1) I will need a bit of feedback.
I guess some people like me still use julia_13 via test-disabling overrides, so a bit of time after 1.5 reaches channels for smooth transition could make sense?
Maybe backport 1.5 to 20.09?
OK so I disabled the tests for julia13 in and made the default there as well. All merged pull requests referenced here should be backported.


I would like to use to encrypt my home directory. is already packaged (as , for some reason) What's missing is the PAM setup (). Given that exists for EcryptFS, I would like to request support for via the option, or something similar. I am aware that EcryptFS is available, to achieve the same goals, however it seems to be considered deprecated by other distributions (, ) and has some which I am not comfortable with.
This is just to say hi and to share that I too am interested in this feature
I marked this as stale due to inactivity. →


Project description homepage URL: https://xd- source URL: license: mit platforms: linux
I marked this as stale due to inactivity. →


Describe the bug arrow-cpp cannot be installed on Darwin To Reproduce Steps to reproduce the behavior: -env -i arrow-cpp Expected behavior Successful installation Additional context nix-build -A arrow-cpp from nixpkgs master fails with this error: Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(lclaude): nixpkgs: Maintainer information:


Describe the bug Putting a valid certificate name in will cause nixos-rebuild to fail. To Reproduce Steps to reproduce the behavior: this line in . This command will fail. Expected behavior finishes sucessfully. Additional context This error message is related to : I guess this error is caused by switching to python 3. 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:
isn't compatible with Python 3, it seems. We'll need to update or carry a patch.
MRTC:


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:


Describe the bug Bisect indicates as the likely point of breakage. cc To Reproduce
I can't reproduce the error hydra has, it fails earlier for me on current master:
We've had a staging-next merge in the meantime; this symlink problem was fixed by .
Local build works with my changes in . Should this be tested via ofborg? If so how do I do this (can I even do this)?


Describe the bug Recently I noticed that the Electron applications I commonly used ceased to be able to connect to the internet. Spotify, Discord, Slack cannot connect anymore. To Reproduce Steps to reproduce the behavior: latest nixpkgs channel Slack, Spotify or Discord cannot connect to their respective servers Expected behavior They should be able to connect to the internet. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Got a similar issue, but Discord and Spotify works. For me it's slack-specific. EDIT: Nevermind looks like I am getting only slack from unstable channel :facepalm:
I don’t think it is Electron specific. I see the same issue with qutebrowser
I confirm I can reproduce it with . Might be WebKit related ?
I have issues with qutebrowser aswell, with every https:// site, http:// works. Getting errors like this: But my qutebrowser uses QtWebEngine, not WebKit afaik. I've rolled back so can't double check.
I've been able to track back the issue to the commit Before this commit it works perfectly. EDIT: It seems that there is an update related to in this commit (see ) I believe that could be related to this specific change.
Interestingly, it seems that not all Electron apps are affected. Signal still works, for instance, but Discord and Slack don't.
This also affects Bitwarden and potentially Steam. Temporarily using nss344 for the nss package in Bitwarden & Discord works.
Steam indeed doesn't work.
cc
For reference, so this (hopefully) shows up in search results: ERR_FAILED is the error code qutebrowser shows.
I'm using the canary release and it's working, unfortunately it demands an update from 0.0.104 to 0.0.105
Slack also seems to work with , but not
I see that and had some similar issues with other programs while handling , they fixed it by simply use a previous version of for those programs. Maybe we should do the same ? I'm not completely sure this is the right solution since the list of broken programs seems to be quite long.
Rambox (electron) also seems to be affected
Probably switch the default to the older version? At least that's what this sounds like at a quick look. (i.e. only use the new one for the new Firefox and Thunderbird branches)
Thanks I'm not sure how to achieve this, I will check it out later but if somebody with the knowledge can help that would be really cool :).
So much for "NSS 3.54 shared libraries are backward compatible with all older NSS 3.x shared libraries. A program linked with older NSS 3.x shared libraries will work with NSS 3.54 shared libraries without recompiling or relinking. Furthermore, applications that restrict their use of NSS APIs to the functions listed in NSS Public Functions will remain compatible with future versions of the NSS shared libraries." I guess maybe all of this stuff isn't "restricting their use of NSS APIs to the functions listed in NSS Public Functions". We can switch the default to 3.44.x, but I'm not sure if that will be supported after Firefox ESR 68 is EOL, which will be in a month iirc.
A temp workaround for now is to chuck something like the following in an overlay to build the derivation with the older 3.44 NSS (using discord as an example here):
An alternative workaround that I'm currently using is to replace with in .
Arch has discord (and everything else) using and I'm assuming it works
We use , but I believe this is unrelated ?
is 3.55, if you want to give that a go. Probably doesn't help much, though.
Im aware we're on just wondering if it's an issue affecting other releases on other distros, or a exclusive thing They also appear to have been using for a month too:
Maybe we broke something in the makefile -gyp based build system transition. Apparently that all came down to the default make target being wrong, so what you could do is revert that whole change, append to the makeFlags, update to a newer release, rebuild everything and see if that fixes anything.
Steam, Discord and Bitwarden stopped working for me.
Slack stopped working for me as well. I don't use Steam, Discord, or Bitwarden (the Linux app-- I use it in the browser only). However, using fixed it, as per Thanks!
So for now?
Not sure if related but dropbox doesn't currently work for me.
This might be related, but vscode doesn't connect to the network either. I tried overriding it with nss 3.44 but apparently it doesn't depend on it:
VSCode is pulling nss from atomEnv which is it at On Wed, Jul 29, 2020 at 22:58, Matthew Levan <:
Great. So how would I go about succinctly overriding 's within the expression?
Maybe an overlay for atomEnv. I'm not good with the nix language so I don't have any specifics.
How is everyone using ? It does not exist for me and it clearly does not exist in the stable repo.
No results found.
!
Doesn't show up on stable qutebrowser. ! Works on firefox but can't test unstable qutebrowser because it can't access the internet.
Works here on stable qutebrowser !
Anyways to get back on topic here... How do overlays work and is this the appropriate quick fix for someone like me waiting for a PR to be merged into unstable? theGeekPirate <:
I can't replicate it with so I have no idea what's going on.
The simplest solution is to use the stable version of whichever application(s) is/are causing you trouble until is merged.
Great, thank you. theGeekPirate <:
For someone that has many unstable packages that are broken, is an overlay the way to fix the issue for every conceivable package that depends on the troublesome package without having anonymous functions filled with overrides everywhere?
My Nix-fu isn't great, but I'm assuming there's a way to override nss to use that unstable package globally, instead. Hopefully someone else more knowledgeable can step in and help you.
In case anyone is wondering how to use a package from another channel, .
Thank you for the merge. I've renamed the issue so people that are searching with "my [app] is not connecting anymore" won't get confused by this quite specific nss issue.
Thank you all for finding the source of the problem fast.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Both channels have updated already to contain the fix.


, CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) Scanned versions: nixos-20.03: . May contain false positives. Cc Cc Cc
Backporting update that resolves these ().
Fixed in 20.03 and master.


Describe the bug xscreensaver-demo is both a way to preview individual screensavers and the frontend for configuring xscreensaver. It should be installed alongside all the other xscreensaver binaries; however, it isn't, although its man page is. To Reproduce Steps to reproduce the behavior: Expected behavior is available in . Notify maintainers (raskin) Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:


Dokuwiki login page does not work (timeout) when https is not enabled in the webserver. Steps to reproduce the behavior: Add some user using the usersFile option and disable and options. Click on "Log In" in the top right, fill in form, and click the login button. The page now redirects to a non-existing https url. Disabling these options should allow Dokuwiki to work on a non-HTTPS enabled webserver. Currently when trying to login, the page will time out as the wiki redirects the user to a https version of the url. While the default https enabled webserver is good for security, it is not always needed or wanted. For example, when you have the wiki on an internal trusted network with no access from the internet such as a wireguard VPN of a few personal devices. In that situation, the SSL adds no value and makes it harder to use, as you would need to distribute self signed certificates to all your devices.


Describe the bug error: --- Error --- build-remote build of '/nix/store/x4nz3kqn24vlz257hm8mnsvrn6ggfsrs-v4l-utils-' on 'ssh://root failed: builder for '/nix/store/x4nz3kqn24vlz257hm8mnsvrn6ggfsrs-v4l-utils-' failed with exit code 2 error: --- Error
-------------------------------------------------------- nix builder for '/nix/store/x4nz3kqn24vlz257hm8mnsvrn6ggfsrs-v4l-utils-' failed with exit code 1; last 10 log lines: ../../utils/libcecutil/cec- ../../include/linux/cec.h ../../utils/libcecutil/cec-htng.h ../../include/linux/cec-funcs.h ../../utils/libcecutil/cec-htng-funcs.h /nix/store/j8vysakw78bpgngba32hfwwikqda9yx2-bash-4.4-p23/bin/bash: ../../utils/libcecutil/cec- /usr/bin/perl: bad interpreter: No such file or directory make[3]: [Makefile:782: gen.intermediate] Error 126 make[3]: Leaving directory '/build/v4l-utils-1.20.0/utils/libcecutil' make[2]: [Makefile:482: all-recursive] Error 1 make[2]: Leaving directory '/build/v4l-utils-1.20.0/utils' make[1]: [Makefile:591: all-recursive] Error 1 make[1]: Leaving directory '/build/v4l-utils-1.20.0' make: [Makefile:518: all] Error 2 builder for '/nix/store/x4nz3kqn24vlz257hm8mnsvrn6ggfsrs-v4l-utils-' failed with exit code 2 error: --- Error
-------------------------------------------------------- nix 1 dependencies of derivation '/nix/store/2544nk822aa38adwvdgk8kc1zyxf1wgd-system-' failed to build we need another . PR incoming... I'm on


Describe the bug as described in , the build fails with: To Reproduce Steps to reproduce the behavior: Since this is a dependency of openjdk14, reproduce with: Additional context This broke somewhere between and ; I'm bisecting now. 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: nixpkgs: Maintainer information:
I could've sworn I tested this back when I was working on ... rebuilding from those commits now to confirm.
Yeah, somehow the release fixes this, but I don't know how.


Describe the bug A clear and concise description of what the bug is. If I try to use the function in from the command line I get an error: To Reproduce Steps to reproduce the behavior: is printed to console Expected behavior A clear and concise description of what you expected to happen. should define so works. Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Currently NixOS modules (, ) handle this for the most part, but it would be nice to avoid duplication and have this defined once - in the package instead of modules. 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. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:


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


Project description It's a tool to create pet-container using Podman. The container is fully mutable and maps your user home to the container. Metadata homepage URL: source URL: license: Apache-2.0 platforms: Linux
I took a brief look at this a couple of months ago after it was rewritten in go. I'll post what I had if I can find it. It uses meson/ninja as a build system which makes it kind of non-standard and a bit awkward to package compared to other go projects, might be easier to skip it and specify the build/install phases manually. IIRC it also needed completion/profile.d paths to be patched in, had issues trying to mount other paths on NixOS and it wanted flatpak for some reason.
I also took a shot at getting toolbox working a while back, and wrote a nix expression for building the package, but decided to try it out when podman is rolled out in a stable NixOS channel. Now that 20.09 is released, I'm trying it out but I get cryptic errors like the following: I might look into this further when I get the time, but people are welcome to look into this issue to try and fix it. Meanwhile, here's the nix expression to build it: Note that in order to use toolbox on NixOS, you seem to need the following config: People seem to be against usage of buildGoModule (see ), so if people are interested in seeing this in nixpkgs, someone probably needs to port this to buildGoPackage.
Hi , I modified a little your nix expression I a patch to check if exists (it not exists in my system for instance). I also changed to copy to and it's mapping this file inside the container. I'm having the same error. So I tried to start the container using podman, this way: Maybe the problem now is because o cgroups. I don't now.
I had to submit an upstream patch to fix an error introduced in newer builds with ownership of the toolboxRuntimeDirectory. I think this would be good to have, so I'm interested in carrying on the work. I was able to build toolbox (thanks for the derivation). The biggest issue seems to be this. Trying to start a container with yields: See this issue. Seems that the reported issue occured when host and container glibc don't match. The toolbox binary gets bind-mounted into the fedora container, which may cause issues without the requisite store paths also being mounted. See: Toolbox is kinda leaky by design, so this might be a problem. <details<summaryContainer info </summaryWARN[0000] Error initializing configured OCI runtime kata: no valid executable found for OCI runtime kata: invalid argument DEBU[0000] using runtime "/nix/store/jkg2hzkxc2g05gsbpkb8sybh34j78syh-nvidia-podman/bin/nvidia-container-runtime" INFO[0000] Setting parallel job count to 73 DEBU[0000] Called inspect.PersistentPostRunE(/nix/store/h9was55f3ir6b2sq5vc96cpgns3qbfz0-podman-2.2.1/bin/podman --log-level debug inspect --format json --type container fedora-tool </details
I have it running! Hello from vim installed via dnf. It's blocked by my upstream patch which you can follow here: <img width="1278" alt="Screen Shot 2021-01-22 at 4 20 05 AM" src="https://user-"<img width="634" alt="Screen Shot 2021-01-22 at 4 21 13 AM" src="https://user-"
That's great I think toolbox is a great tool to have in NixOS.
Agreed! Please test the PR if you have time :) Thanks for your work!
Very happy to see your interest in Toolbox! I just wanted to point out that Toolbox doesn't actually need Flatpak proper. It's just the daemon which is a D-Bus session service that comes from but is completely separate from the rest of Flatpak. In fact, in Fedora, we ship it is a separate isolated sub-package. The purpose behind this daemon is to keep certain configuration files in the container's synchronized with their counterparts in the host. eg., , , etc.. Anyway, good news is that these days, since Toolbox 0.0.97, the daemon is no longer used for newly created containers, because the functionality has been absorbed into Toolbox itself. One big reason was to enable rootful Toolbox containers (ie., ). Older, preexisting containers will continue to use the daemon, though.
Just a minor note. The actual issue is See the related for an explanation on how we solved it. Ideas for better solutions welcome. :)
I marked this as stale due to inactivity. →
This issue is important to me.
Any update on this? Can this be merged to upstream and closed?
Is there anything that you need from the Toolbx project?
There are two remaining roadblocks. To clarify, I no longer use nixos and will probably not work on this (I still am an active toolbox user, just on Fedora :)) glibc updates. Any time the hash of glibc changes in the nix store, all toolbox containers will break (and need to be recreated). I'm sure there is a clever way around this, either a service that runs after a nix-rebuild that updates the bind mounts, or patching toolbox to update the bind mount on each toolbox enter. These seem very nix (or guix) specific) SDDM issue, there's nothing I think toolbox should do about this. Nixpkgs could consider carrying the sddm patches until merged upstream. Anyone is free to takeover , I won't be continuing it. The PR "works" with the caveat of point 1 not being handled, so you'll have to periodically recreate toolboxes.
after the container creation, it's possible to change the bind mounts and ports? Is there a file to edit?
I found this alternative to toolbox
There's no support for doing it easily through a Toolbx-specific configuration file at the moment. However, you can script something through one of the shell start-up scripts.


Project description cchat-gtk appears to be a generic chat frontend cchat-discord appears to be a discord-capable backend gtkcord3 was the predecessor and was quite nice, I'm excited to get this packaged. Metadata homepage URL: source URL: license: gpl3 platforms: linux
updated OP to reflect that we should package cchat-gtk/cchat-discord now instead of gtkcord3.
I marked this as stale due to inactivity. →
still important to me
I have this packaged in my own config:
I marked this as stale due to inactivity. →


Describe the bug It's easiest to see in this picture: ! To Reproduce Steps to reproduce the behavior: system with nixpkgs at how init complains about /dev/fd/62 Expected behavior No error pertaining to /dev/fd/62. Screenshots See above. Additional context I don't actually remember when this started, because the boot logging scrolls so fast I missed it a few times (and I might have updated nixos-unstable-small at some point). The problematic line is: According to the blame, that hasn't been touched in 5 years, so I don't know why this would start cropping up now. 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:
Why I think we should block on this: there should be no scary pointless outputs in the init script in nixos. Same if the activation script was being loud and scary for no reason.
So, I attempted to bisect this, but due to build failures (and the size of some builds) I was unable to pinpoint. However, I've now set up a machine that I can use for those huge builds, and will try to go further sometime soon. For anybody interested, below is my ( and ):
OK, I re-bisected (by removing all the skipped commits and building them on a machine) and got this result: cc What are the chances this is an issue with the package/one of our patches and not with upstream? New bisect log, for the curious:
did this happen in a VM, or on your real machine as well? What's with the `chown: invalid user" in there? Is this related?
I can reproduce in a VM and on my machine. Ignore everything below the fd error -- screenshot was taken from another issue, before I was able to build a VM myself. (EDIT: I've uploaded my own screenshot sans the JSON and errors, to make things clearer.) I'm going to try to bisect systemd soon, but it'll probably take a while, especially given how many patches there are that could fail to apply :P
OK, maybe the stuff is a red herring? I d the entire call and got the following log: <details<summarystrace output</summary</detailsCan't interpret this now, but maybe it will give somebody an idea. Most interesting part to me:
Alright, thanks to my Google-fu, I found a diff that fixes the issue: According to , one of the articles that turned up, this might be caused by udev missing?


Describe the bug When trying to start a dynamic playlist, the user is greeted by an error banner stating the following: To Reproduce Steps to reproduce the behavior: Cantata dynamic playlist to play dynamic playlist Expected behavior I expected Cantata to start the dynamic playlist. Screenshots ! Additional context This is likely fallout from perl's removal in However, this exposed something impure about Cantata's packaging, so it's a good thing! I tried simply patching the shebang to point to (as well as changing this condition to never return true: ), but to no avail. EDIT: Even adding to my does nothing -- when I click on the play button by the dynamic playlist, it turns to the red stop button, and then back to the play button without ever playing or queuing any songs. Seems like this might need more work. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
If you have the time to give it go, I think this should do the trick: And then add to .
Thanks for the tip. It was slightly more involved than that, but fixed in this PR:


Describe the bug It was left out being implemented in the initial PR , but it's a very useful feature for nixos development and endusers. I do understand it's nothing can't do, but it's a useful wrapper. cc
See for an attempt at adding support for this.


ping It was agreed that should be removed before . It was generally accepted that an option isn't a great idea and was to the module temporarily for ease of testing. It is important to remove this because other people have seen this option and started believing this is an accepted design pattern for NixOS modules - we don't want people getting the wrong idea and having more options like this slip in. can you please file a PR removing this option and the entry from the release notes?


Describe the bug I am trying to install (cli version) on macos from the unstable channel but I a getting the following error: To Reproduce Steps to reproduce the behavior: Expected behavior joplin should be installed correctly Screenshots N/A Additional context Notify maintainers Unfortunaltely maintainers are not specified :( Metadata system: host os: multi-user?: sandbox: version: channels(dbarrosop): nixpkgs:
I marked this as stale due to inactivity. →


Describe the bug The file has this function: Since this is called for every dependency, we get quadratic complexity. This may cause a non-trivial slowdown - building digikam I noticed it takes a few seconds just to get to , but there might be other causes. It also causes huge amounts of debug output when you add a to (about 600 MB for digikam). We should use an associative array for this like stdenv does (see ). Notify maintainers
We also need to do this in the setup hook for paths seen by .
I marked this as stale due to inactivity. →
Not stale.
Fixed in .


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


Describe the bug According to and , noto-fonts-cjk should have 14 ttc files, but noto-fonts-cjk in nixpkgs downloads from , this zip files doesn't include serif fonts. To Reproduce Steps to reproduce the behavior: -env -iA -list : family | grep 'Noto Serif CJK' Expected behavior It should output: Notify maintainers Metadata Please run and paste the result.
The nix file should download 14 .ttc files and install to target directory in a loop, it's a simple logic, but sorry I'm not familiar with Nix language yet. Mention more people involved in this file since 2020: hope this gets fixed soon, thanks!
As I recall, the issue with packaging it initially is there was no Super OTC version of the noto serif cjk font available. There still isn't a Super OTC in the repository. There is https://noto-website- from , but that URL doesn't look stable. I guess for now you could use , it is 99% the same font.
, thanks for your quick response! Although is almost same, fontconfig can’t assure it will alway be selected for document using , there are a few other popular cjk font such as Arphic PR UMing & UKai, WenQuanYi, GNU freefont, GNU unifont. Like Debian, Gentoo also packages separate ttc files. FreeBSD even packages separate otf font, I guess this can save some memory and time for applications to load a font subset. It’s a pity google doesn’t upload a single super otc file for noto serif cjk, but I guess the huge noto sans zip is uploaded to git by mistake, it’s kept there just to not break download url. So I suggest just packaging 14 separate ttc file, it’s convenient enough compared to those separate otf files. Another reminder, it’s better to also include a fontconfig configuration snippet like Debian and Gentoo.
Arch also packages separate ttc and include a fontconfig configuration file.
I marked this as stale due to inactivity. →
Still important to me.