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


Whenever I open a file chooser dialog in Nicotine+, it crashes with this error: Steps to reproduce the behavior: X environment without a DE and run a file dialog I saw a similar issue on Chromium: Maintainers (thanks!): system: host os: multi-user?: sandbox: version: channels(root): channels(ao): nixpkgs:
It looks like the glib setup hook isn't setting for some reason (maybe it's not running?) The wrapped file looks something like () So the packages is being to , which happens here: Right above it, gets to if it's present, but that doesn't show in the wrapper, so the variable is not getting set.


When I update nix I can't copy to our binay cache anymore. All I get is I bisected nixpkgs and found that the bug was introduced by . Run The parent commit works: This error here is fine because our cache has a different name of course. Please run and paste the result.
Just wondered if here is the right place for the issue but I’m quite lost on this. Maybe this is a nix bug?
No you're correct to open this here, this is a good place to start. I'll try to bisect further to see which aws-sdk-cpp commit broke this functionality, hopefully that will tell us more about how to proceed.
Bisected to , but unfortunately the commit is very large so I don't see an obvious cause. Maybe it's best to take this upstream to the Nix repo now.
Thanks for reporting, and sorry if this broke your workflow. I've bookmarked this issue and I'm going to look into adding an installCheck regression test to ensure s3 stays functional on future updates.
Thank you all for the quick response. This was a really sneaky one. Luckily nix allows rollbacks. That would be great. I’m sorry I cannot think of anything better than checking the error message of . When I do I let you know.


Usage of flag without , and it is known in the Clojure community that its usage causes issues. This is because without the binaries are statically linked with , and I tried to create a GraalVM derivation compatible with . The result is here: However, this can't be upstreamed since it brokes all compilations with (including dynamically linked programs as used in nixpkgs). The major issue is that, to make compilation work, . This approach works fine for when we have only one lib C, however if we have two separate lib C we will have name conflicts and either we will have a compilation with glibc symbols on musl libraries or vice-versa. So, what are the options? One approach I can think is extend the wrapper from binary to conditionally include either or depending on the context (e.g.: if the flag is passed or not). We can do this using the flag, as below: For this to work we also need to remove the symbolic links to glibc library, otherwise this can conflict with musl libraries. This should also fix this . However, this looks like a very ugly solution, and I am open for better ones. Steps to reproduce the behavior: . Keep in mind after , it expects binary as . You can create a symbolic link and add it to your a file with contents: (segfaults) It should compile and run successfully. N/A Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Maintainer information:


I updated today my distribution on latest unstable (I was already on unstable before). And it turned out that many things suddently broke (the clock is broken, my does not work anymore (of course), Carla's software does not have anymore a "Canvas" menu, NSM can't run Carla or it gets an error, Giada also fails to connect to Jack...). I quickly realized that I was running Wayland instead of X11, while I was always running X11 before on KDE Plasma. Moreover, the KDE clock and calendar is now broken (negative numbers+hour does not appear at all+what is this ): ! So here are my questions: it normal that Wayland is the default now? I can't find any documentation on Wayland vs X11, and it seems a bit risky to use Wayland by default given all the bugs I encountered... yes, how can I configure X11 to be the default? (I mean in the configuration file, not by just changing at connection time) can I get the clock and calendar back? idea why Carla, Giada and NSM are also not working properly with Wayland? (I'm using pipewire) Steps to reproduce the behavior: the system and reboot Please run and paste the result.
Same issue here. On top of that, I'm unable to share my screen with tools such as Google Meet, Teams, Jitsi. To fix: , then in SDDM select on the bottom left:
There's not supposed to be any changes to the default. If you don't set one via , you might get the wayland version. This should/must be fixed. Others have mentioned the issue with the clock although I'm not seeing that here. As for the screen sharing question, applications need wayland support. That really has nothing to do with Plasma or NixOS.
Thanks for your answer. How can I find a list of valid ? I tried to put an absurd value but it does not give any error. In my case I'm running sddm, plasma5 and x11. Concerning the clock, I'm not sure what I've that you don't. If it helps, the language of the system is french . and in X11 my clock looks like: ! The is replaced with octobre, so that's why I'm thinking it may be linked with the language.
Or well, pipewire support. However screensharing/recording on plasma wayland seems to be broken at the moment (even in OBS which does have explicit support for wayland). Judging from what gets logged in the journal it seems like is not agreeing with kwin about the supported wayland protocols or something.
Same, I also get the broken clock, unless I remove the timezone setting from and get UTC. I saw some people saying Plasma's systemd startup fixes it? Altho IIRC the PR for that was merged but the systemd service isn't running by default.
I have which should be the most standard one... and.
Maybe NixOs does not like people with European timezone…
I notice that the env var is somehow missing for . I run with correctly set, and the clock widget just works. Running it with empty reproduces the same broken clock. I checked that , have , but , and don't. Since is the session entrance started by (so it's not 's fault), we can know the envvar somehow gets dropped during the plasma starting chain. EDIT: Another issue is that, we used to be able to workaround the clock issue by . But after , as I mentioned in , and the option DO NOT work anymore. Session is now always booted without systemd.
By comparing between , exactly is dropped when the wrapper running , no other environment variable are , removed or modified. is wrapped to gain CAPSYSNICE, I'm not sure how the work, but simply removing this wrapper just fix the clock widget issue. But it's definitely not a good idea since is expecting to be real time scheduled. cc
I have nothing to do with KDE, but I made a few changes to in . I don't see how this could possibly have affected the clock, but you could try reverting my commits if you think this is related.
That may be unrelated. I found the related upstream issue The cause here is that rejects , and some other env vars in secure-excution mode, including programs with or capabilities. See In our case, has capabilities set. But I'm still not sure how we could workaround this. Currently my thought is to patch and to let the wrapper pass these envvars in other ways, like renaming envvar name or passing through arguments. If there's a better way to workaround, please point it out.
The "Wayland by default" thing was introduced here: as part of KDE Wayland support in NixOS in general. Mb shouldn't be default yet or at least not to override previous preference of X11 during upgrade. +1 about the clock - same issue. I'm on locale.
Current status: The clock issue can be workaround by setting since which is already in . It will be fixed (without ) in The default session will be set back to X11 on SDDM in Currently, you can manually switch to X11 and login once, and SDDM will remember your last choice (hopefully, it may be reset if you change available desktop sessions. It's an issue of SDDM and I'll look into it later).
This fix didn't work for me. The clock is still broken in exactly the same way as reported in this bug. Even after logging into fresh user. (Again, I'm on Wayland)
Are you sure on nixpkgs and that option is enabled? Please check if the plasma systemd service is started by . If it's not running, please open another issue for not working. If it's running, then there may be some issue of . Since will load PAM environment, which must contain , and it will be propagated to other units. In this case please open an issue about "systemd user units not picking PAM environment".
Thanks for your advice! Yes indeed I'm on master (last synced yesterday) and have this option enabled: Though it says "dead" for some reason (and I'm writing this from an active KDE session), process is a child of systemd according to pstree TZDIR is defined as well: Do you have any other ideas?
Looking at 's process env, indeed env is not defined there. Is that the issue you are trying to point out? (The above returns nothing)
Please open an issue about not working, and provide there.
Did another update from unstable (it updated LOTs of packages) and after reboot, the clock is working again! (and TZDIR env is indeed known to plasma). thanks again for jumping on this!
Could this be the same root cause for issues with IMEs, screen capturing and Flameshot simply not working at all? IME (fcitx) does not activate, screen capturing in browsers and OBS does not show a source selection dialog, Flameshot does not react to its DBus invocation (Spectacle works although it is dog slow -- not sure what their internal differences are) See and I don't know much about DBus but the bit about it not finding services dirs sounds like it could be caused by something like this. I also remember seeing some logs from Flameshot where it thinks it has been started already but actually invoking its screenshot function does not do anything -- wrong DBus instance? ... Or am I the only one with these problems on plasma/wayland? :D
I have 4k 14" laptop display and 2k 27" external display. Flameshot doesn't work for me at all on KDE+Wayland: Spectacle kind of works - about every second time; plus, when trying to annotate, the resolution of the image gets absolutely trashed if I the screenshot was taken from non-hidpi screen.
For the issue, see
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


It seems that all of a sudden a few dependencies are missing to . As a start, I found the need to add . The problem is with which also makes the impression it's needed: But our build of doesn't provide cmake files. Building with cmake instead of autoconf might help, but they don't use the cmake module there which makes the transition harder. cc (maintainers) and .
The new requirements come from thrift since
I have an idea of how to fix this. Will put a PR up shortly


Except from If the main module specifies go 1.17 or higher, go mod vendor now omits and files for vendored dependencies, which can otherwise interfere with the ability of the go command to identify the correct module root when invoked within the vendor tree. This may change the hashes of vendorSha256 in existing packages that are using buildGoModule. Originally posted by in
go 1.17 may not be portable across different go versions, but go 1.16 will be EOL next month (when 1.18 releases). 15 is EOL and should be removed. There isn't a remediation for this problem correct? The only answer I see is to move the versions forward with breaking changes.
Yeah - Regenning the hashes isn't that hard - I'm going to confirm they're stable, and then stack a PR using the infra I used for the og hashes. Walking through the cases vendorSha256 = null Fine - no vendoring happens Go 1.16 to 1.17, not go1.17 No module change - testcase clipman. go 1.16 to go1.17, is go1.17
I'm already working on this.
- Do you have an ETA? I expect I can get this pounded out this weekend, but if you don't want me to I won't.
Also any objection to me trying to clean out the go1.15 deps? I think some of them (i.e. terraform / prometheus), might not be updateable, but the rest probably are.
Hopefully in the coming week. We need to handle the hashes and the usual breakage from the update so I really don't want to push something though quickly in case it turns into a mess. I'm also avoiding normalizing any of the vendor hashes so we aren't needlessly adding noise to the git history. I've been moving some things to 1.16 or 1.17 in advance to limit diff and rebuilds and checking that the updated hashes still build on darwin+linux. If you don't mind doing the hashes in smaller batches like in that would be helpful? Fixing or pinning any broken packages would also help. No that should be fine, only looks like a few packages plus the pinned which needs to be either unpinned or removed.
I'm happy to cut small PRs - How many hashes do you want them batched to? 10 hash updates per PR, 100? I have no strong opinion on how to batch these (and normally my tooling generates a commit per package, so its' real easy for me to batch arbitrarily). I'll probably try and clean out most of the easy stuff (i.e. everything with a null vendorSha, everything which doesn't have a changed vendorSha), then deal with the stuff which causes mod vendor changes, but if you want I can start on the gnarlier stuff first (modules with vendorSha changes + the non module stuff).
20 or less per PR would make merges simple as we can let test it. Unless the needs to be updated or it's broken on 1.17 I'm leaving these for the final PR when the default is changed. Also anything that causes more than a few rebuilds is probably easier left for the final PR as well. I'm not planning to fixing every first before the final PR when the default gets changed but if we can get it down to 50-100 hashes it'll make it easier to test and also avoid conflicts with other PRs.
Got it - so focus on the changed hashes - or anything which breaks. I also just pushed out working PRs for every go1.15 package except one (mostly to go1.17), so we might be able to get rid of go1.15 before go1.18 lands.
Should be under 100 now but I'll keep going until there is only a few left (basically just stuff that should stay in sync with the default or causes a few rebuilds) as I've found some with broken vendoring on 1.17 and it's easier to address that first so the final PR is fairly simple.


Any local users can talk to locally running X server by default. That includes sending keyboard/mouse events, popping windows, etc. Log in as into a host running an X server under , and run I think normally you should have to do something like before you're able to talk to 's X server. System: NixOS: nix-shell -p xorg.xmessage --command xmessage test Nix version: nix-env (Nix) 1.11.2 Nixpkgs version:
Thanks, amazing nobody has spotted this before. The flag has been present ever since (when it at least had a comment about being bad idea...).
:+1:


YouTube tabs reliably crash within a few minutes on nixpkgs-built firefox Steps to reproduce the behavior: firefox from latest (NixOS/nixpkgs to some youtube user's video list up and down for a bit This doesn't happen with my previous env (using firefox 92.0.1, I think NixOS/nixpkgs but I haven't confirmed), nor with . It does happen with . Also, the page is not available on the nixpkgs-built firefox. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
I think it happens when you hover over a video and it starts showing the preview.
Yep that does it!
Possibly this bug?
Seems familiar. Will try the fix they suggest.
Note that in bisecting I've found a commit with the same version of ff but not this bug.
I don't think it's the same bug, I'm able to watch both linked videos (as long as I don't mouse-over a preview on the side)
It's happening for me as well, not sure why though
Not happening with firefox-bin 94.0
As said in the issue it doesn't happen with firefox-bin at all (also checked that myself) (also not 94.0.1)
Also happening for me (using nixpkgs.firefox).
Hotlinking directly to webp files also recreates the issue. That should narrow it down a bit. [edit: I guess these links expire after some time, but its just the url to an animated youtube thumbnail]
Also works on firefox-bin 94.0.1 (master is on 94.0).
Seeing crash locally as well on and . I bisected down to (had to apply to avoid build failures). It is a merge commit with the following conflict resolution:
While at it how does one get meaningful debug symbols out of firefox? is very sad: I tried patching in the below, but got no symbols: Is there a generic way to get the symbols? Or maybe it's a good opportunity to add them to specifically?
I tried reverting , still broken. Worked when 94.0.1 was merged in .
Yeah, I have no idea on how to accomplish that either. And having that could be really helpful :+1:
I can confirm this occurs when mousing over YouTube video link/thumbnail pairs in either the main page, search results or video sidebar (on Firefox 94.0.1). Not only that but doesn't exist at all, which probably means the crash reporting feature is entirely disabled for nixpkgs Firefox?
With the stdenv patch, does ff work on both parents of the merge commit but not the commit itself?
we have crashreporter turned off by default for some reason
its been that way since (2008) we should set it to
Crash report: https://crash-
correct. Re-tested again just in case: ^0: - crash ^1: - ok ^2: - ok ^3: <invalid, only 2 parentsNote that these two branches contain about 2 weeks of commits. One of them is a update, another is an update. This merge mixes both together and firefox does not seem to work. is a full picture of all the commits involved. Anecdotally I tried to disable lto with and got working (but I suspect it also flips to in that case). Would be nice if controlled just aspect and not the rest of toolchain.
Although using is possible for LTO ultimately it complicates the expression and deviates from upstream. When I implemented support for LTO, I think it was agreed upon that we should try to follow upstream as close as possible. Hence enforcing and . The reduced maintenance burden of having to test more configurations was also a plus. That being said it would be nice if someone wants to take on that burden and expand the LTO support to be more general (and maintain it). The end goal was to actually change to build to using too but allow the native system linker. I never got around to implementing that. The reasoning being upstream tests vigorously against . This is speculation on my part but I think a point of interest here is Firefox now builds against instead of . Building with was never a requirement for LTO but a side effect of the old stdenv. At the time did not have a proper nixpkgs wrapper script and was unable to be used outside of it. (On a side note, for some reason had issues during linking with not being configured to pull in LLVM's hence the workaround. It can be removed now since is being used.) reports (about:buildconfig) being built with LLVM 12 and rustc 1.55 so this might be a new bug introduced with LLVM 13 or the newer rustc. A definitive way to test if it is a bug in the switch to would be keeping the same firefox version and having applied (so is used) but change the underlying LLVM and rustc versions to 12 and 1.55 respectively. If the crash goes away then it is tied to the LLVM and rustc version if not then something wrong is happening when using .
I created a upstream bug 3 days ago, including stack backtrace with symbols. The crash function is in . Disabling webp () can mitigate but it of course quite hurt. :disappointed: If anyone gets more information, please also post in the bug thread. BTW: Enabling debug symbols need to set configure flags and set . won't work due to .
It is mentioned in that bug report that directly opening links canot reproduce the crash. I actually had the opposite experience. I was able to recreate the crash by directly opening a webp file, although it's not 100% consistent. I also stumbled across this other URL that crashes firefox, this one is a PNG. If I right-click this URL and "Open in new window" the tab will crash about 50% of the time. Curiously, this URL seems unaffected, despite the resulting file being hash-identical. !
I just now noticed that the above image is being served with a content-type, so looks like its still webp-specific, even though no webp content is being actually rendered.
I cannot reproduce with that URL at all after tens of tries. This DOES crash me sometimes. And note that the URL actually responds a WEBP image despite it contains , maybe due to HTTP fields. You can confirm it by the tab title (once you don't crash) or download and check with . This is also fine for me. It's more complex than I think. I'll guess it might be an index-out-of-bound or other kind of heap corruption? Could you post about this in my bugzilla report?
Can you share exact change needed? Here is my non-working example of enabling the symbols:
Yeah, whatever optimization tricks is doing here is just confusing things. I'm going to ignore those results for now. I was able to create a very small poc for the bug that works reliably with the same image, though. (Also posted in the bugzilla thread)
For how to build with debug symbols, see I'm still working on this issue now and I'll make a PR about that later. Note that you need to follow and set environment before starting or .
This is happening for me.
See
the in the first post is a typo, right? If I read it right, we can keep stable nixpkgs as it is, thanks to using LLVM 12 for firefox.
Yes, updated.


The runuser command from utillinux doesn't work. This is apparently a PAM issue. Original message on the mailing list: System: 16.09pre79463. (Flounder) Nix version: nix-env (Nix) 1.11.2 Nixpkgs version: 15.09.505.
The util-linux (2.27.1-6ubuntu3) package in ubuntu xenial ships with the following pam.d config:
Both files are shipped by and respectively in the original package source. It should be possible to integrate them in our own package. Fetch and unpack.
The following line in the NixOS config appears to solve the problem. But it would be nice to have it fixed in the package itself. Also I know next to nothing about pam so I might be doing something very wrong.


A clear and concise description of what the bug is. Steps to reproduce the behavior: -p nixops ... ... it builds! error: builder for '/nix/store/48sdc9gb26pb3prykylvy644mmsma0km-python2.7-ruamel-yaml-clib-' failed with exit code 1; <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Maintainer information:
Builds on linux thanks to .
still fails:
I think the issue is tracked in I do not understand what the state of nixops is. is an issue about NixOps 2.0 with all checkboxes ticked. Further down in the thread there is a link to a board called . So what's going on? Are the things in that board release blockers? Which version of nixops should normal users use today? The project does not seem to make it clear.
And even with that insecure package enabled, the fails with an import error.
NixOps 1 is effectively end-of-life. That issue does not include critical usability problems present in master. To quote my response to another issue: All maintenance to the NixOps core currently happens on NixOps 2 (master / pre-release), because of the project's limited resources. NixOps 1 relies on python 2.7, so maintaining it is not feasible with the NixOps project's limited resources. Please consider helping with maintenance and testing, or donate to This fund currently supports reviews and fixes on master. Donations greatly increase our ability to get things merged and work towards a functional NixOps 2 release.
Is there a current way to get oneself an overview of what's working in NixOps 2 master, and what isn't? Is it I would like to contribute testing it, but need to know: what the migration path from nixops 1 is (can I continue to use my existing state files?) whether there are dangerous unaddressed issues (will it wipe my infrastructure?) if there are key unsupported parts that nixops 1 has (Hetzner support, EC2 support, Route53 support)
Yes, this is more up to date than the previously linked issue. I'll have to refer to the issues and PRs. For the core, that's The documentation is still lacking in this regard, and some more work on the legacy state storage backend or other state storage code may need to be done, e.g. In my experience, NixOps 1 state files can be picked up by NixOps 2, but the opposite may not be true. Unlikely, but check the issues and prs of the plugins you're using. The plugins that are responsible for these parts should continue to support whatever those parts used to support, and they are available. IIRC we have two plugins for Hetzner now, one using a newer API. I have not worked on any hetzner related code.
don't you dare.
The build passes, if you permit that insecurity, now.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


Launch GNOME Music 3.18 There's no artwork at all Log: System: (Flounder) Nix version: nix-env (Nix) 1.11.2


When is enabled, my printer is not recognized by . Initially, when the option was not enabled, my printer would immediately get recognized upon plugging in the USB, show up in the Printers section in , and printing also works fine. After enabling SANE, the printer is not recognized, but the in-built scanner gets recognized and works properly in apps like . After disabling it and running , the printer is again immediately recognized, but obviously the scanner doesn't work. Configuration: Both the printer and scanner must function and get recognized properly when the above-mentioned configuration is applied. SANE did not give any errors Error after enabling : After disabling it, the printer gets recognized: Based on commit history for the SANE and modules Printer: CANON Pixma MG 2570 Driver: CUPS+Gutenprint v5.3.4
that is extremely puzzling, as sane is enabled or disabled though an environment variable that cannot be changed by a mere nixos-rebuild switch. you need to reboot or to logout/login to effectively toggle it.
Yes. initially, in order to enable the scanning functionality, a reboot was required. But the connection to the printer was established by simply disabling the option and rebuilding
Without lookling deeper into this, are you sure it’s not just a random coincidence? Were you setting up printing and scanning in the same session? Maybe you changed something else in-between.
Just tried it again today, same results
I have the same issue.
Pretty sure it's a permission problem. With cups enabled: With sane, saned and cups enabled: After a reboot, permissions are back to the first case. I guess there's a problem with sane's udev rules. Update: Sane or saned define udev rules that change the group of printer device nodes. I've tried setting , but libusb seems to do extra permission checking beyond the device nodes, so this doesn't allow cups to print.
Nice find! Do I understand correctly that when the device is owned by lp scanning does not work and when it is owned by scanner printing does not work?
Hello! Yes. From my understanding of , generates udev rules for every "scanner" device that changes the group permissions of device nodes to "scanner". This does not work for multifunction devices, as Cups expects device nodes to be accessible via the "lp" group. I've created a quick fix for this by overriding the derivation to delete its udev rules. Note that SANE is set up for device nodes being owned by the group (seems to be implied by . I've worked around this by overriding sane backends to delete the udev rules: This is a temporary fix, but I don't know what the "proper" way to do this would be.
Ok so when the device is owned by lp, it also works with the scanner. Reading you it looks like an issue with upstream udev rules, I wonder if filing a bug upstream is warranted.
Seems to be a known issue:
Looks like is the proper solution. would you mind giving it a try? It's hard to test without affected hardware...
Turns out the command was never run, and the rules were just copied from the sane source. requires a search path to find description files. After patching via rules are indeed generated, and the owner isn't changed.
Sounds nice. Would you mind opening a PR?
I went ahead and created , due to lack of response.
this was fixed, but incorrectly, in . A fix to the fix is in , it would be nice if people affected by this can test it.
Still works for me, tested printing & scanning with the following overlay:
Closing since it sounds like some combination of and fixed this, but I'm happy to reopen if I'm misunderstanding.


unbound-full cannot be built on the unstable channel error message: Steps to reproduce the behavior: build .#unbound-full It should obviously build cc Maintainer information:
This happened in the fixupPhase, maybe we should remove lines?
I've put some information on


The option does not work on aarch64-linux due to See also It seems that the current issue is that does not build on aarch64-linux. Steps to reproduce the behavior: NixOS on aarch64-linux. the option. the failure. aarch64-linux support n/a See also <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Maintainer information:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
It looks like is only pulled in when : Maybe the assertion could be relaxed a bit?
Bump. Please change this so that we can at least use the guest tools in headless mode as mentioned here:
Can you submit a PR and change the assertion message? This makes sense.
or could you give a try?
Any suggestions on how to update the assertion message? Am not sure if it should also be conditional.
Can you tell me how to single pick this PR in my configuration? Define an override?
Yes. There are multiple ways to do this. So finding the simplest or easiest way will depend on your current setup. How do you define/import nixpkgs in your configuration? That'd be one way to do it. AFAIK you'd need to add the vmware- file to (), and bind a new nixpkgs reference to my branch, where you'd import that module from.
AFAICT this is also a blocker for creating a graphical ISO for :
Seems to work on aarch64 for me:
Does not seem to work for me: ! ! Rebuild: ! Assertion is in ! (Sorry for screenshots, but copy/paste does not work yet ... as it requires the vmware guest tools ... )
Any progress - I am a begginer in nixOS. So the way to learn is setup a VM But then I hit this. What are the exact steps to use this PR? This is not just a mouse issue as the previous comment not it stops cut and paste. It also shops the use of shared folders so a fix is needed for the headless case as well.
I would love to have vmware guest on aarch64 too. I'm running VMWare Fusion on my M1 macbook. I tried the above, of disabling the vmware- and adding my own with the assert modified to accept Aarch64. However it not building x11 mouse is one issue, but even with headless = true it still fails; in this case vmw_vpscsi fails in the kernel build: !
that's a module that comes with the kernel and not vmware. It looks like it's not supported under non-x86 architectures: so we should remove it from the module if not on x86
can you test ? I don't have aarch64 but this might work.
Magic. It built successfully and as soon as nixos-rebuild switch completed my X desktop resized to match my monitor (automatically). I just used my own local vmware- (disabling the system one), in which I made the two changes that are in kjeremy's PR ^ Thank you.
Could you elaborate how you did that? The furthest I got still gives me


Get a mac with facetimehd support and the following the laptop lid the lid back (might also need to press a key) I'm running unstable and assuming its broken on 16.03 too. System: (NixOS: , Ubuntu/Fedora: , ...) 16.09pre79453. (Flounder) Nix version: (run ) nix-env (Nix) 1.11.2 Nixpkgs version: (run ) "16.09pre79453."
It is broken since since the module is using which is obsolete and can't handle compressed modules.
Can you report if fixes this?
yes switching to kmod works (only tested facetimehd). Are there plans porting this over to 16.03?
Yeah, I assume we should port it – it doesn't seem likely to break anything and it does fix some bugs.
Oh hrm. I missed this issue conversation and put in this PR: I reckon we should backport , and
This is fixed in 16.03 and master. can you close?


libcanberra is not included in of thunderbird and firefox. This prevents both applications from playing gtk sounds (for instance when receiving an email on thunderbird). Steps to reproduce the behavior: any instance of firefox And in the output of strace you will see that firefox doesn't try to open the lib dir of libcanberra in the nix store. For instance on my system: libcanberra is supposed to be in the of firefox and thunderbird wrappers. AFAIU firefox and thunderbird open this library at runtime with dlopen and that's why it's not in the generated . <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Maintainer information:
You are correct. It probably should be to the wrapper. It seems is pulled in by . Not sure what it is doing or if it is needed but adding to should address . On another note, there ought to be a tool that searches Firefox's source code for all runtime shenanigans. Also the wrapper should probably be expanded so that overriding packages into is possible.
This bug still exists. Is there any idea?


Running fails with the following error: The issue is here: Before the 2.8.0 update, this line used to say So, flutter copied the cache to , which was fine. Now, however, it tries to copy the cache to , which doesn't exist, so flutter throws an error. Steps to reproduce the behavior: do any flutter project `flutter run Flutter builds the app and runs it on the device Please run and paste the result. I cannot run it because I use flakes, so it just says .
My bad, it should be fixed by
thanks!


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


mediathekview might be affected, the latest version 13.8.1 patched the distributed log4j version As it also updated compatibility to Java 17, and no working Java 17 distribution is in 21.11 or master atm, I'm still working on how to best address this.
See PR Full update depends on updated Java 17 , manual patching might be needed in the mean time. As it is distributed as a binary and log4j is packed into the main jar, I'm a bit stumped at the moment how to approach this.
Might work
See PR for a fix


Upgrading fails, seemingly because the existing systemd version is newer in 21.11 than unstable. Steps to reproduce the behavior: NixOS 21.11 21.11 channel, add unstable channel NixOS upgrades from 21.11 to unstable. is the commit upgrading systemd to 249.7, cherry picks it to 21.11. Adding the flag to the invocation would also solve this issue, albeit leaving the newer EFI files in place. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.
I think the corresponding PR is
As pointed out above by this will be fixed when staging-next gets merged ().
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


However, the following input is is rejected as "*: incorrect address specification": I expected kresd to listen on fe80::1 on port 53 on the ofborg interface, as the documentation suggests should be possible. I don't mind that it is impossible, but the documentation for this option isn't correct anymore. nixos-unstable-small, rev
Well, it no longer uses systemd sockets anymore, and instead there are a few in-nix regexps that convert them. It might not be perfect. Either way, the interface spec should surely be part of the IPv6 already, i.e. – and I think that should work (the generated lua config looks OK).
Ah, I see that systemd is weird here, at least in docs. So I don't know what we'll do with it. Either shuffle it in the in-nix regexps or document as a deviation, I suppose.


I get the following collision: What I don't understand is why this collision is happening in the first place? I'm installing this package into an empty profile!
That's a multiple-output problem. The derivation creates two of them, both containing the file. When installing into user profiles, currently the semantics is that all outputs are installed, so this creates the collision.
Vladimír Čunát writes: What's the reason for these semantics? I would expect only 'out' to get installed by default.
Well, as for build inputs, we normally want all to be available, because you need include, lib and possibly others. should know details. It hasn't been used much yet, so I suppose we still have to figure out how to do these best (and have the most usual setup as the default).
What I haven't figured out in these cases: why installing attempts to install both and .
I am getting this same error message. Fresh install of Nix 16. Could it have regressed? This happens when I run nix-env -iA nixos.openjdk but not when I dun nix-env -iA Though those both say they point to openjdk-8


I think it should be marked as broken to avoid frustrating other people. This package is impossible to build without more than 4G address space due to linker memory exhaustion. It can be built only on 64-bit hosts (the same as Firefox). And that permanently breaks Gnome 3 on i686. It was possible to build it in the past using local modifications, though.
what modifications did you used in the past?
Only very few to some Gnome dependencies just to build Gnome itself, like . AFAIK, there were no modifications at all to webkitgtk. It just required huge swap and to free as much RAM as possible, e.g. running nix-build with only one thread. Last December I've tried to install NixOS 21.11 and it was impossible to build because of a linker exhausting all memory address space. I've tried both ld and gold. My investigations into other Linux distros revealed that they used cross-compiling tricks to build 32-bit webkitgtk on 64-bit host. I've spent a week before giving up. Right now I'm using only x86_64 arch because of that issue. I suppose it's impossible to fix on native 32-bit host just like Firefox.
I tried different configurations and was able to complete the building without any memory issue by setting separateDebugInfo to false.
I will now try to build firefox. Edit: it is markerd as broken on 32 bits.
Interesting. Thanks for trying this. It was very painful to experiment with different configurations as it required too many hours to build on my computer. AFAIK, Firefox had a different issue which didn't involve linker. It was probably a compiler. Do you think it's sustainable? I mean, will it still be possible to build next year? Because a year ago it didn't require that trick either. I'm quite pessimistic about browsers on 32-bit architecture as is already evident from Firefox :( Also, there were similar troubles with Haskell (Pandoc) and Qt. Considering that Hydra doesn't have most 32-bit software in a binary cache and that it's often required to set in order to build it, it's really a huge pain to install NixOS on i686 arch.
works great for me. Should we add a conditional for this derivation?


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


A follow up to It seems like is not getting updated when tmux sessions begin/end. Relevant links: Steps to reproduce the behavior: and note the results. a different shell, open a new tmux session: exiting tmux, run again and note that the results are the same. Tmux user sessions to show up in , , and , as is custom in other OSes. n/a n/a <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.


I'm trying to start the service fusionInventory but it fails with the same error as , running the system command in a terminal also trigger the issue. Steps to reproduce the behavior: part in , this is the minimum to have fusioNInventory to start, the server doesn't need to be real, it fails before trying that. I have a real setup that also fail with the same error, I tried this one to be sure it's reproducible by everyone. note that this command line without works: the service is running fine
Solved in after debug with upstream


After updating to the latest NixOS unstable channel, when running , the process will fail when building fcitx-libpinyin. Can repro this in a fresh installed NixOS using , adding the following lines: channel: : process will fail when building .....-fcitx-libpinyin- with exit code 2. The rebuild process should succeed without failure. !
Updating to 0.5.4 seems to fix it:


Blender 2.93.5 Hallo When I start Blender now and set under “Render Properties” → “Cycles” Blender crashes completely. Also when I go to “Edit” → “Preferences” → “System” Blender crashes immediately with this Error: What does that tell me now? My GPU configuration in the clinfo: nix run -c nix-info -m:
I think this might be the same issue as described in


I found a disappointing issue with NixOS on AWS EC2 - absence of support for Enhanced Networking (SRI/OV) out of box. See docs at Here are separate issues: is outdated on 16.03 (less then recommended 2.14). Amazon Linux AMI is better then NixOS here amis are built without --sriov flag. Because of 1) this makes starting spot instances with --sriov trickier As I'm not an expert in AMI creating, instance management or kernel module packaging, I won't do pull requests on this topic. But I'd like to share some success with others. Here is the ixgbevf-3.1.2 kernel module package. it And here is extract from config to enable this module: My instance started and ssh works. Now I have this: Ping
Thanks, I wasn't aware of Enhanced Networking. I'll look into it.
Added the driver to the Amazon config: , . Will need to rebuild the AMIs though (and make NixOps enable Enhanced Networking automatically), and add the driver for instances.


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


I would like to use the following option in in : When running the command I get following error: This is because are appended after the option. It would be better if we switch the order of these. Steps to reproduce the behavior: following configuration to execute the command will fail with following error: The program should be exectued with accepting all


, CVSSv3=9.1 (nixos-21.11, nixos-unstable) CVSSv3=9.1 (nixos-21.11, nixos-unstable) CVSSv3=7.5 (nixos-21.11, nixos-unstable) An issue was discovered in the DNS proxy in Connman through 1.40. The TCP server reply implementation lacks a check for the presence of sufficient Header Data, leading to an out-of-bounds read. An issue was discovered in the DNS proxy in Connman through 1.40. forwarddnsreply mishandles a strnlen call, leading to an out-of-bounds read. An issue was discovered in the DNS proxy in Connman through 1.40. The TCP server reply implementation has an infinite loop if no data is received. Scanned versions: nixos-21.11: ; nixos-unstable: . Cc
Unstable - 11 -


, CVSSv3=7.8 (nixos-21.11, nixos-unstable) CVSSv3=6.5 (nixos-21.11, nixos-unstable) CVSSv3=5.5 (nixos-21.11, nixos-unstable) CVSSv3=5.5 (nixos-21.11, nixos-unstable) CVSSv3=5.5 (nixos-21.11, nixos-unstable) There is an Assertion `scalinglistpredmatrixiddelta==1' failed at in libde265 v1.0.8 when decoding file, which allows attackers to cause a Denial of Service (DoS) by running the application with a crafted file or possibly have unspecified other impact. An Incorrect Access Control vulnerability exists in libde265 v1.0.8 due to a SEGV in An issue was discovered in libde265 v1.0.8.There is a Heap-use-after-free in intrapred.h when decoding file using . A stack-buffer-overflow exists in libde265 v1.0.8 via fallback- in function putepelhvfallback when running program . An issue has been found in libde265 v1.0.8 due to incorrect access control. A SEGV caused by a READ memory access in function derive_boundaryStrength of has occurred. The vulnerability causes a segmentation fault and application crash, which leads to remote denial of service. Scanned versions: nixos-21.11: ; nixos-unstable: . Cc
See


, CVSSv3=6.5 (nixos-21.11, nixos-unstable) A NULL pointer dereference issue was found in the block mirror layer of QEMU in versions prior to 6.2.0. The pointer is dereferenced in mirrorwaiton_conflicts() without ensuring that it's not NULL. A malicious unprivileged user within the guest could use this flaw to crash the QEMU process on the host when writing data reaches the threshold of mirroring node. Scanned versions: nixos-21.11: ; nixos-unstable: . Cc Cc
This is fixed on master since we have QEMU 6.2.0. It's not included in 6.1.1 though, so needs to be fixed on stable. Probably after since it'd be a merge conflict.


I want to use (providing ) for it's Debug Adapter support. Particularly it seems like Helix can utilize it with some early debugging support. However, it doesn't seem to work. After adding that to my nix shell, and entering it, and trying to run it, I get:
cc: since I'm running your latest PR bumping this.
I suspect that vscode-lldb's fork of lldb needs to be updated?
Oh yeah, that would be because the adapter is patched-inline in the extension process and the unwrapped, useless, adapter is passed thru instead.
I have some work that fixes this: just uses regular lldb now, we can drop the "fork" with the "rust-enabled" check tries to exec-itself in certain scenarios and must be patched so that it properly calls its wrapped version But most of all, it seems like is ... just built as part of already. I'm not even sure if there's a huge point in bothering with and in general. I really wish this were less messy. was a hassle to figure out, has a bad name, the repo that you find online is old and says darwin-only. yeesh.
i got hit by this, but now it says
Actually only resolves the issue. The original issue of missing still exists somewhat. Yet a working binary can be found after that PR at Help is wanted to resolve the path issue of the adapter sub package :smilingfacewith_tear:
why was this closed? I don't think it's fixed.


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


I am encountering the following error after launching Pinta 2.0.2. I thought initially that it was a problem in the Adwaita theme itself, but whatever the GTK theme I use, I always have the problem. I tried on two different machines and had the same problem with both. NixOS with unstable channel Ubuntu + Nix 2.5.1 with unstable channel I did not have this problem in the last packaged version of Pinta. Maybe it is there since the 2.0.2 upgrade? Pinta should launch without this error. ! Please run and paste the result.
This looks like exactly the same problem discussed on Except that it should be fixed. Not sure what is happening here, and I don't have access to a Linux machine right now to debug. Maybe can help?
I also have this issue. It also causes the toolbar on the left to not appear.
Can someone show me the contents of the directory inside the package? It should have a directory/file somewhere, inside the icons directory (I don't remember the exact path). If this is missing, this is probably the issue.
It is missing:
Huh... I think I can blindly patch this issue, however someone will need to test on the PR.
Wait, I was wrong, it is there, but not in :
It shouldn't be in , it should be in . This is the issue. This can be probably fixed later correctly by setting some setting on , but since I don't have access to a Linux system for now I will just duplicate the assets for now. Later on I can do a proper fix.
Can someone test this PR please:
Waouh that was fast. Thanks a lot, both of you for your reactivity!


From Currently nixpkgs has as an . We should either have as a nix list of enums, or just a string to allow the user to specify a zsh array.


Project description Cider is an open-source and community-oriented Apple Music client. Metadata homepage URL: source URL: license: GNU Affero General Public License v3.0 platforms: linux, darwin
They ship an AppImage which I use in my own config packaged as follows:


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


I just found out about wrapGAppsHook by examining a gnome package, but there really should be documentation about this in the Nixpkgs User Guide (a section about Gnome would be nice, which would show the right way to package GTK3 / GTK2 glib based apps). Also, perhaps there are other things I missed that one should know when packaging Gnome Applications or GTK3/2 apps? /cc Gnome maintainers
I'd like to know as well. Currently receiving this error: On one of the packages I'm trying to put into nixpkgs. Apparently sometimes you need for buildInputs. So apparently all you need to do to use this is:
The error occurs when you do not have any directory containing in variable. One of the things does is (which usually contains the aforementioned file) of dependencies to . (Actually this happens in cooperation with via variable.) Icon themes work in the same vein, only is used and it is populated by which is propagated to (). (XDG fallback theme) should be probably to any GTK application that uses icons (I think that is every GTK applicaton nowadays due to CSD) but some applications require Adwaita because they use icons not in hicolor. Not sure if this functions correctly though, at least it should not according to my mental model of how icon theme selection works; I will need to read the relevant XDG spec before I can finish the documentation.
Just thought I'd leave this comment here for future reference: if you get an error like for python gtk applications, try adding to propogatedBuildInputs!
It should go to , though. But be wary of


Project description Layan kde is a flat Design theme for KDE Plasma desktop. In this repository you'll find: Aurorae Themes Kvantum Themes Plasma Color Schemes Plasma Desktop Themes Plasma Look-and-Feel Themes Metadata homepage URL: source URL: license: gpl3 platforms: linux


When attempting to install , installation fails with the following error: As noted in , the call to is incorrectly using a capital B in the flag. It should be . The error coming from the matches the error when running the same command by itself: I searched for an existing issue which reports this, but didn't find any (aside from the comment linked earlier). Slack is installed successfully. N/A N/A <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.
Can you make a pr fixing it? I can merge.
I made a commit to do that in my fork here: However it still fails during the , this time with . This was also reported in but only on . However it seems the same issue is also present on and I'm not sure where to go from here on fixing it. I can run the same command from my terminal successfully. Is there anything different about running during the that might cause this?
I think I figured out the problem. writes to , but this isn't accessible to the user running the script (). I'm able to reproduce the problem now if I try to run the command as that user. Is there some way to make this file writable by the user as part of the ? I'll try to do some research on how other packages set property list attributes on darwin to see if there's some other workaround.


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


Qtile is missing all the ffi modules so one can't use the pulse widget Just install qtile and add a To the config There is a script that has to be run as part of the packaging process takes care of creating the ffi modules, not sure if that will be enough or patching to change the paths will also be required.
Problem still here, and only for this module


Obsidian is unable to run (non-nixpkgs) git commands, due to being prefixed with . Steps to reproduce the behavior: non-nixpkgs from nixpkgs in obsidian the command Git syncing properly <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Why don't you use git from nixpkgs (e.g. )?
That does work, although I'd prefer not to install git with on manjaro. I have other workaround that i use, i simply wanted to report how seem to break subcommands.
Just updated, and this also affects electron 16
We could consider prepending to in the derivation (the start script in the output).
can you guesstimate how many percent of obsidian users have obsidian-git plugin installed?
Of all obsidian users: few. Of obsidian∩nixpkgs users: maybe 20%?
Possibly related:
can you please check whether the fix in fixes this issue for you?
Seems to work!


Password hashes, while less sensitive than unhashed passwords, are secrets. We should therefore have a option in that avoids both placing the hashes in the store world-readable and storing the password unhashed.
This is a common misunderstanding due to the bad naming of these options: → string of plaintext password → string of password hash → file containing password hash So, what you want already exists and it's .
Oh wow, indeed. Thanks! Given that the option is named so confusingly and that its description starts with "The full path to a file that contains the user's password." I think we should keep the issue, pending an option rename and a documentation improvement.


yaru-theme fails to build on the latest nixos-unstable Steps to reproduce the behavior: fails Buiild succeeds ! `


QEMU VMs using the profile that have a in their hostname were broken by A clear and concise description of what you expected to happen. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.


, CVSSv3=7.5 (nixos-unstable) Vyper is a Pythonic Smart Contract Language for the Ethereum Virtual Machine. In version 0.3.1 and prior, bytestrings can have dirty bytes in them, resulting in the word-for-word comparisons giving incorrect results. Even without dirty nonzero bytes, two bytestrings can compare to equal if one ends with because there is no comparison of the length. A patch is available and expected to be part of the 0.3.2 release. There are currently no known workarounds. Scanned versions: nixos-unstable: . Cc


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


Can anyone run successfully? When I try it, the tool almost immediately crashes:
On 6 February 2014 19:49, Peter Simons wrote: Same here. Seems to be happening elsewhere too:
Saving to works around the issue for now.
Any way this can be wrapped to happen automatically?


Build of failed on x86_64-linux as of . This is currently breaking maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tag:
can confirm for and
I'm trying to bisect this atm, but it's a truly massive undertaking since there's hundreds of commits between current master and the last successful build... plus there's lots of other irrelevant failures :/
I was unable to find the exact commit that caused these failures, since it was interlaced a bunch of other commits that broke dependencies. Created upstream. We'll see what they say. We're not doing any patching of required dependency versions, so the test suite ought to be passing.
I also tried bisecting. Due to the massive rebuilds, I canceled after 8 hours and did a bisect with . The bad commit is from , which is a merge from staging with changes to python and others: <details</detailsLooking at the there is a requirement for werkzeug < 2.1.0. When applied, the test mostly pass. The only failing test is: There is also a requirement for pytest < 7. Since this packaged builds with the latest nixos/unstable, which includes pytest 7.0.1 I am now testing with that version.
The updates usually breaks the package. I guess from 1.5.7 to 1.5.8. Edit: Was part of
Further investigation: When I apply the following two changes: downgrade to downgrade to sentry-sdk builds without issues. How should we go about this? Just disabling the tests could lead to malfunction of the sentry-sdk package (because they did correctly detected a regression in the SDK). Downgrading both packages Adding an override in for those two packages could lead to potential breakages due to dual imports of two different or imports in packages, which import sentry-sdk and one of the two packages. Obviously it would be awesome if upstream update their end of the SDK of werkzeug. This could take some time and sentry-sdk is needed by other packages.
I notified the authors of the breaking commits and
Another breakage is pgadmin (tracked in )
Module can't have overrides. Thus, till the issues are fixed by upstream the failing tests should be disabled.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


On current nixpkgs unstable, GraalVM 11 won't build (also breaking clojure-lsp, clj-kondo, babashka, etc). Steps to reproduce the behavior: macOS: It should build successfully graalvm17-ce fails for the same reason. GraalVM package maintainers: Please run and paste the result.
My bad, this was probably one change that I made on the previous refactor. This PR should fix it:


Project description Add Khmeros TrueType font for Khmer language. Also, see All issues have attached PRs. Metadata homepage URL: source URL: mirror://debian/pool/main/f/fonts-khmeros/fonts- license: gpl2+ platforms: all


Project description Add Korean Nanum fonts: Nanum Gothic Nanum Barun Gothic Nanum Barunpen Nanum Brush Nanum Myengjo Nanum Pen Nanum Square Nanum Square Round Metadata homepage URL: source URL: license: ofl platforms: all


Commit from broke haskell.compiler.ghc6102Binary haskell.compiler.ghc704Binary and therefore the packages haskell.compiler.ghc6104 haskell.compiler.ghc704 haskell.compiler.ghc722 haskell.compiler.ghc742 haskell.compiler.ghc763 which depend on them.
Please try . I test-built the binary GHCs but no further.
Aha. I relied on the update being API-compatible, but the first bootstraping steps don't recompile...
I'm test-building the whole list above.
All succeeded on x86_64-linux.


Krita fails to build with the following error Steps to reproduce the behavior: Build Krita should build. nixpkgs @
In libraw was updated. Switch to the old stable libraw020 to fix this build.
Installing kirta is showing like it's not in the cache, any idea why?
You're attempting to build the older derivation. And building it would fail. Newer binaries are available:
If you rely on channels, you might want to watch
I'm using the "" and just updated it, and I get this: So, that means the PR is not in that channel yet? If it's that, good to know, didn't know that tool.
Yes, channels that are not -small usually lag by roughly one day.


The package is failing to build Steps to reproduce the behavior: The package to build successfully without errors
I'm sorry, I haven't used in years - but also nothing with that package has changed in some while. I'd assume an upstream problem?
I don't use but took a look out of curiosity. It was an upstream problem that is fixed by a few commits after the latest 2.4.0 release. There hasn't been a new release since then. Is the best thing to do here pull down that commit as an isolated patch or to bump the revision that's pulled down to that (untagged) revision?
Can we use in the meantime?


scipy doesn't build on Darwin right now (trunk). Hydra: The error in Hydra seems to be some builder failure and not actually related to the issue. It however fails as well when I try to build on my Mac. We should get rid of both issues. Steps to reproduce the behavior: to build It builds I don't need this Python module myself but a lot of other packages depend on it. This is currently the package with the most dependants (322) that fails so it'd be nice to have this cleaned up before ZHF starts. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
The too many open files sounds like it could be related to the very low default limit on open files on macOS. For me it defaults to 256, I think more recent versions have increased the limit but it's still lower than for Linux and the tests were probably written with that in mind.
scipy builds for me on both x86_64-darwin and aarch64-darwin. $ nix-info -m system: host os: multi-user?: sandbox: version: channels(reckenrode): channels(root): nixpkgs:
what does report for you?
Ok, then my hypothesis is debunked.
Could this be due to the file descriptor leak bug in nix ? This would explain why it fails to build for some users but not for others. I believe the bug was fixed in nix 2.8.
scipy seems to be build for me on , can anyone else confirm? Looks like it's still failing on .
can we just disable the tests on for now? as a note (or whatever) can bump the open file limit but you might then run into memory limits like I've experienced in
I'm going to disable tests on so we can work on other issues for ZHF. If anyone wants to debug specific failures in scipy please reply to this issue. It currently causes hundreds of other packages to transitively fail.
Wonder if reducing parallelism would help.


The issue is what the title says. By half, I mean and for my previously used from emacs-overlay to your system the eln cache in your home, e.g. to open emacs for the manual for by and inputing the eln cache in your home: , you will find together other eln cache. I think this is a bug since is builtin for emacs and it's eln cache should be distributed together with . Uses of will not need to native-compile builtin libraries themselves. does distributed together with from emacs-overlay I used before. It's . might be related to the bump of 28 , so
The difference between the two versions is that one is built from the tarball, while the other is built from Git. The tarball includes byte-compiled () files but not native-compiled () files. The build notices the files and does not rebuild them, but native-compilation is a side-effect of byte-compilation and so the files aren't built either. (Almost all of the files you see for the new version are trampolines, there are only 3 non-trampoline files.)
ideally we'd run , which is the expected way of deleting such things (or perhaps even ). But the tarball only has a , so we'd need to run , then , then again, which is super ugly. Hopefully deleting the files the naïve way is enough?
I think maybe we should just skip the tarball entirely and fetch it from git instead.
There are other side-effects caused by skipping the tarball. This claims, for example, that bootstrapping is only expected to happen to emacs developers. Part of bootstrapping is converting the Japanese input method dictionaries, and this takes some amount of time. They're in the tarball at , but are absent in the git checkout.
That's a good point, I would still rather inflate build times a bit and exercise bootstrapping as a part of our regular build though to completely avoid these types of issues.
I'm hesitant about building things in a way that upstream doesn't expect, unless necessary to adapt for nixpkgs. For a related example, using the repo instead of the tar distribution for Ruby caused a subtle problem where the commit hash was not propagated, which broke the bootsnap gem's cache invalidation (fixed in , by using the tarball). The real question here, I think, is how upstream expects native compilation to be used if their tarball doesn't support it.


On startup, Tor Browser doesn't start if some variables about Wayland aren't set. Steps to reproduce the behavior: and (if set) Tor Browser in a terminal and see the error message. Tor Browser should start. This issue was caused by . currently does not fix the problem. In the meantime, an easy fix would be : <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Notifying peoples from the aforementioned PRs instead. Please run and paste the result.
I can confirm this issue
thanks !


The option, which enables by default on high-resolution displays like my 4K laptop screen, is supposed to set the console font within the initrd before displaying the LUKS password prompt. However, with , this does not happen until stage 2, so the prompt is tiny. Enable , , and . The console font should be switched before the LUKS password prompt, not after.
Relevant code is probably that it sets . should then properly set everything up if it can find its files in :
Does it work when you do ?
No, it can’t, because points to a font file that’s not present in the initrd.
This works though. It’s a little jarring in that the font is changed about a second before the framebuffer resolution is changed, so it’s temporarily huge. Ideally those would happen simultaneously. But at least they both happen in time for the LUKS prompt.


, an application that simulates user input to keep the screen awake when pressing gamepad buttons, relies on on Plasma Wayland to do this. However, isn't installed (or at least, it's not in ) with a default Plasma installation, making not work: (Among other errors) Steps to reproduce the behavior: Plasma (), without "installing" ; a Plasma Wayland session; ; 'll see the error message, and the program won't work. There is no error message and the program works (which is what happens by installing ). I don't know if the best solution is to add to Plasma or to . I'd vote for the former, since (if I'm not wrong), is already installed with Plasma, it's just not in PATH, and I don't see the harm in being there. Still, that's why I opened an issue. By the way, can't be installed "alone". NixOS says: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.


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


I notice zoom-us from nixpkgs-unstable gets killed by SIGILL shortly after the application window is shown. This does not occur when running zoom-us from NixOS 21.11. A strace ends with the following output: Observe that the zoom process is killed by SIGILL shortly after the application window is shown. The Zoom application proceeds to run without crashing. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
I stepped through commits that touched zoom-us. The behavior appears to start with (no launch), resp. with (SIGILL observed).
I can‘t reproduce this issue, at least I get into a video call and to making faces at myself for a minute without issues. I am running zoom 5.10.4, on x86_64-linux with kernel 5.17.9.
I didn't see this on my system using the version from nixpkgs . It's expected that would not launch (it's fixed by the commits after). These should really have been one commit, or in another order to allow bisection, but oh well.
From what I can muster, SIGILL is caught while in It looks like is part of the binary distribution of Zoom and not built as part of nixpkgs? But I figure if can run it with no crash it’s more likely an application bug rather than some ABI issue?
I now notice that one Zoom invocation results in two coredumps. The other one is a SIGSYS arising from libc. I’m not really versed in such dark magics, but FWIW:
I really don't expect to be able to debug this, but could you post the output of and (and maybe if the output is short, particularly around the marker) from gdb on the SIGILL core? To me this really feels like a zoom problem. You don't happen to be using an ancient or unusual processor do you?
It looks like version 5.10.6 (3192) is out for linux now, so it might be worth trying that too.
Cheers, that seems to resolve the problem. Not really, it’s an i9-10885H. In case you’re still curious for whatever reason, I’ve attached the information copied from gdb. Otherwise I’d say this issue is obsoleted by the new Zoom release. (NB just said “No function contains program counter for selected frame.”)
my zoom is dying too, I got it working for now with
Thanks, that's pretty interesting; something jumps into the middle of an instruction. Good that updating it works anyway.


ACME certificates cannot be provisioned automatically, even though run in manual mode succeeds. This seems to occur whenever allocating a new certificate, and possibly when renewing one. System: (Flounder) Nix version: nix-env (Nix) 1.11.2 Nixpkgs version: "16.03.1168."
Hi guys; if any of you know what's going on here, it'd be greatly appreciated. From what I can tell, the Terms of Service are out of date for nixpkgs's version of letsencrypt - and this makes the service pretty much unusable. If you have any ideas about how we can fix this, I'll be happy to investigate further and make a fix.
Luckily only happens when creating a new account, so renews are not affected. Thanks for reporting. Fixed. :beers:
Awesome; thanks for the very fast fix! I'm wondering if there's a more permanent way to solve this - being unable to deploy new servers whenever letsencrypt releases a new TOS seems a bit fragile. Maybe we could add a configuration option to set the TOS hash on the command line when invoking simp_le?
That's a good idea. Also as we're right before releasing 16.09 we should add that option before the release so NixOS users can easily update the hash themselves if needed.
Hi! Even if the new configuration option to set the TOSH hash would only appear in (makes sense, it's a new feature), is the hash fix () going to reach ? It doesn't seem to be there for now:
Thanks for the reminder. I'll look at it. The only potential problem is that is at another version in 16.03. The patch should apply cleanly, though.
any news? If someone need a fix, just add the following snippet to your configuration to override the package with a patched one: Then you can use the options as usual! But I hope the patch will soon be available in :)
Ah, thanks for testing that! In that case I'll simply backport that patch.
Ok, backported. Will be in the 16.03 channel soon. I'll keep this issue open because I want an to add an option for 16.09 to specify the TOS hash in the module.
Confirmed to work on ! Thanks a lot!
are you still planning on doing this in time for 16.09?
what are actionables here for 16.09?
We won't implement this for now because we need to replace simp_le anyway.
This is happening again?
That fix worked for me. I've no idea if it breaks anything else for others.


This is from nixos-unstable current. For some reason, I get build failures with ZSH. This is with a nixpkgs (system=x86_64-linux) and nixpkgs.crossSystem set to . This seems to be the same failure (I checked, its the same derivation): Steps to reproduce the behavior: ... ... ... A clear and concise description of what you expected to happen. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.
couldn't fix it. I'll leave this assigned to myself so i remember to take a another shot at it in ~6 months
Fixed by


Project description Metadata homepage URL: source URL: license: Business Source License 1.1, change to Apache License 2.0 on June 1st 2027 platforms: linux
Can you check out my PR if everything works?


As of nixos/nixpkgs (i.e., today) seems to be failing due to an unsupported command line switch being passed (see ) Actually, starting doesn't fail, but some (all?) of the other command line arguments are ignored. For example, I tried setting , but see how insists on starting on port . Removing the switch makes start as expected, respecting the other given command line switches, but is this what we want to do? cc
this was broken due to Catalyst bump. See duplicated - I don't know how to best fix this as switch might have an impact. If someone has time to fix it, I'd be very happy :)


The systemd-boot image built in nixpkgs has gaps in the section table. This leads to signature verification failure with some UEFI Secure Boot implementations (e.g. Dell XPS 13 9310) Using NixOS 22.05 @ Using some old version from NixOS 21.11 that I still have in the store: N/A Allegedly something like this was fixed in systemd upstream and the commit is present in v250.4 but for some reason it still appears and Secure Boot fails. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. system: host os: multi-user?: sandbox: version: nixpkgs:
Relevant:
This commit might be the culprit: I will try confirm this, but since it requires rebuilding systemd, it'll take a while.
It's more likely a problem of sbsigntools:
Does your hardware still correctly validate the signature with this patch applied?
Yes, signature verification works with this patch (and only with this patch). Hardware is Dell XPS 13 9310. See also


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


Project description GTK mc-like dual panel file browser ::: very nice for mc users... :) "Double Commander is a free cross platform open source file manager with two panels side by side. It is inspired by Total Commander and features some new ideas." Metadata homepage URL: source URL: license: platforms: linux, ???...
Man, this is a Pascal app! I never tried to build such a thing before...
i'm just suggesting because i'm migrating from debian where i use it... :) ... though have no idea about building or packaging... :( debian has it, if it helps in any way.... i use doublecmd-gtk
Debian rarely provides their build scripts. I am reading the ubiquitous AUR (). However, I have seen that the GTK they use is the old and abandoned-by-us GTK2.
i do not "depend" on gnome/gtk... and was about to eventually give a try qt software... so feel free not to oblige to my request, though i do think is a nice piece of software that deserves a chance of availability... maybe wait for them to upgrade their dependencies... ( hour after ) ... i just tried krusader... and filled this bug report: O.o ... so seams there is not a nice working dual panel graphical browser available... :(
Coincidentally, someone on the Discord server was asking about this application like a week ago and I wrote them a package expression to use. I don't have any interest in maintaining it myself, it sounds like you might be interested :wink: This was adapted from which has some modularity for GTK/Qt, in case you want to get that working as well.
Perfect. Friday I will look at this.
" merged commit into NixOS:master 5 hours ago" does this mean it is packaged?... how can i try?... i searched the unstable channel and cannot find doublecmd package.
It means that now the Hydra bot will build the caches in order to include this package. You can follow the progress of it in the link below: When it reaches nixpkgs-unstable you can possibly call it.
... and is now available... :) ... and installed... :) Seams to work fine, except... When i try to "Commands" -"Search", "New search instance..." or "Synchronize dirs...", sometimes i get a "Function not supported!" error... :( ... After opening the program, if it happens, it always happens until i close it... If does do happen, then does not happen until i close it... o.O?... And now that i'm trying to repeat the error, all seams to work fine... Have no idea what was that... The debian version never gave this error... Since i'm not being able to repeat this error, i will not report it until if it ever happens in a repeatable way... (5 min later) Yap ::: no error for several program restarts, cannot repeat it, have no idea on what may have caused the error (maybe is just be from sharing my home (~) with both versions, of debian and /nix). & thank you for packaging this... :)
for mere curiosity ::: do you have any plans to also pack the "qt" version?
Isn't this the QT version already? Or it has support for older QT releases?
lolz ::: yes, you are right... sorry, it does look like gtk version, here in my debian, i presumed it was the same... so then, do you have any plans to also pack the "gtk" version?...
I don't feel motivated to do it because it uses GTK2, an abandoned release of GTK.
The Free Pascal support for GTK3 is in very rough shape. GTK2 is preferred and Qt5 is getting there. what problem do you have with the qt5 version that gtk2 will solve?
i have no "problem" "with the qt5 version"... :) ... it works just fine... :) ... unlike krusader ::: ... :( I just asked "do you have any plans to also pack the "gtk" version?" out of curiosity... :) And with the small concern that if some one only uses only gnome/gtk and installs the doublecmd (qt5) ::: will be also installing some qt5 libraries just for doublecmd, when the necessary libraries for the doublecmd (gtk) are probably already installed and being shared among other gtk programs. For example, if i want to make a small-as-possible live CD based on gnome, and the only installed qt5 package is doublecmd (qt5) ::: some space could be spared with the doublecmd (gtk) instead... O.o ... i presume. So, there is not a big "problem", that i don't mind now ::: but is also not perfect... i do undersand that might rather wait for "Free Pascal support for GTK3", and agree that adding "GTK2, an abandoned release of GTK" may just be a swim against the current and a waste of time (if no one needs it for a stronger reason).
Fortunately space is cheap, so it doesn’t seem like something truly worth optimizing for. Once you start dragging in graphical programs, you’re going to carry a lot of libraries. Use GNOME Commander in this case? I know it’s not packaged in nixpkgs, but that should be trivial to sort out.
"space is cheap" ... o.O?... & what does life has to do with price?... ... and sure GNOME Commander could be a solution ::: but is not in nixpgks... (as you mentioned)... and is not double-commander... maybe is better, i have not tried it ::: is also not in debian stable, that i use... by the screenshots i would presume that has less features and looks not so nice. ... on my part, for now i'm happy with having dblcmd qt ::: i have not yet decided which to choose: qt, gtk, other or none, to cross with my xmonad... and still far from any kind of release, if ever any... and just scouting for the possibility of using nixos, or debian, or both.
Your first argument fails in the point that, well, GNOME is mostly GTK3+ nowadays, whereas DC is GTK2. Between a well-maintained flavor with an extra library versus an abandoned extra library, the choice is obvious.
It has nothing to do with neither life nor price. The point is that the impact of bringing in an extra library (or set of libraries) in a desktop environment is negligible in most cases. I appreciate that there might be corner cases such as a bootable image where space is limited. Packaging it is most likely trivial - someone just has to want it bad enough. This is getting off-topic, but having used Debian both to run servers (50+ instances, so nothing big) and workstations, NixOS is so much nicer.
i do agree with Anderson ::: "the choice is obvious." ... and sorry, for bringing "life" into the subject... what i meant was ::: i don't care about "cheap" but rather well done... o.O?... a "cheaper" typical size DVD ::: costs more and takes more space than a mini-DVD, which does fit a pocked... & yes, "This is getting off-topic"... but the thread is closed, i presume that now we are just drinking coffee, right?... :) ... "NixOS is so much nicer"... o.O?... lolz ::: at consuming hdd space and having broken packages?... i like debian because is stable, and distinguishes between "required,recommended and suggested" dependencies... i use debian since 2000, and every time i try some other distro ::: i end up getting back to debian... :) ... debian can be small, can be big, is quite stable, and others are always missing something i need... :) ... as for nix ::: i do like the one-file ... but still find unbearable when i bump into a "broken package" (why is it listed for install at all?), and miss the suggested/recommnended variations of packages... NixOS is yet not nice enough to replace my debian... :) ... and debian + /nix is very nice enough for now... :) ... i just run 3 personal machines ::: "so nothing big" at all... :)
This isn't particularly constructive, but I'll bite. "NixOS is so much nicer" When you have multiple versions of the same package, you are bound to take up more space than on a distribution where only a single version can exist. The entire closure of bash (as an example) with all its transitive dependencies doesn't take up more space than bash and its dependencies on Debian. Complaining about NixOS using more space than traditional FHS distributions is a bit like complaining that water is wet. Sure, we have broken packages. All distributions have broken packages (for various definitions of "broken" of course). Certain types of packages (KDE applications on !NixOS) is less likely to be tested well and as a consequence will be more likely to break, that's correct. Do we have more or less broken packages that others as a percentage of all packages? Are they more or less broken? I can't give you a quantifiable answer. In my experience broken packages has not been an issue. Because the existence of a package in the repository is orthogonal to its build status. Exactly the same way that a package in debian can also be installable but not fit for purpose due to bugs (or conflicts or pollution from the global environment and so on). Apart from overriding a given package which is of course always an option, some packages will allow you to toggle various features, but having an application's runtime environment be a product of the global environment is not something we strive for. It's pretty much the antithesis of what we're trying to do here. That's fine, you do you. I was simply making the point that for my personal use-cases as well as those of the company in which I work have been a tremendous upgrade from Debian. Forget about "not even the same ballpark" - it's pretty much "not even playing the same game".
O.o ... please do so... :) ... i think is constructive... i' learning about stuff... :) ... and ::: just having another coffee... :) Debian takes me much (much, much, than with recommended) less space, because i only install required packages, never the recommend, never ever the suggested... :) ... nixos seams to do that some extent with configuration and package options... :) ... but still feel much less clear and customizable to me... :( ... or maybe just don't know, NixOS yet enough, how easy that would be... o.O?... ... though never seen it on debian stable... since 2000... :D O.o ... lolz ::: & i just started now, trying to use NixOS... O.o ... & should i report this brokenness it as a bug?... (but "thanks god" ::: it worked on debian) ... seriously ::: please answer this... :) O.o ... lolz ::: am i "experienced" or what?... (just kidding) O.o ... never had packaging problems with debian since 2000... :) ... have you? ::: lolz, would be ironic... :D sorry ::: did not understand this. O.o ... are "you" not trying to please everyone and everything possible?... is not that what "you" also want?... O.o ... yes ::: i'll end up using both... :) ... i'm comparing with debian and sharing my transitional experience for "you" to be aware of it... :) ... i do find the nix approach very nice... :) ... and single file for the whole configuration is really nice... :) ... all my haskell work now goes into a nix-shell of my Debian /nix, that i test in a NixOS... o.O?... "you" do brag about good haskell support ... o.O?... and lolz ::: i bump haskell broken packages?... lolz... :D so ::: don't brag so much just yet... :) ... & make this "bite" ::: "constructive"... :) ... better yet ::: more construct-able... :) ... and more stable when announced (by being in the NixOS channel ) as stable... :) ... and ::: i hope the "bite" tasted nice... o.O?... i have not much more food for now... :( ... with any luck (for "you") i'll just keep bumping into bugs and brokennesses and report them... :)
Just to be clear, the bokenness i mention above is also broken in NixOS, i did try both.
A bit nore spacing concerns... I'm now upgrading NixOS... noticed all the -doc packages passing by... is there a way of switching them all off? ... and is there such thing like a central html index, linked to the -doc files installed? how can i access them?
Oh well, if you are comfortable using Debian Stable, your needs are such that NixOS won't be of use to you… NixOS is about avoiding conflicts between unrelated packages, supporting rollbacks so you can install fresh stuff with less risk, etc. If you want a minimal setup with Debian Stable, sure, that's another way of avoiding problems that Nix handles for large combinatations of fresh packages.
O.o ... uau ::: not bad, for a dictator... o.O?... good thing i have a will of my own... :D but thank you, for the more clear answer to my question: O.o ... guess not... "NixOS won't be of use to you" ... :( sorry, i had not realized that NixOS just targets a specific audience ): ... as you explain, is not good as debian ::: to make a smallest live-cd, with no repetition of packages and with no -doc packages... :( ... ok ::: upon your advice i'll try to use debian for that... :) ... ty And please notice ::: that you just failed in answering any of the questions i made... :( ... which would actually be even more useful to go with the coffee... :) ... suggestion ::: "get your self a cookie"... :D
I could even try to bite this, however my learning and attention problems trigger as a hell before such a badly written text. For someone complaining about elitism and bloat in an obscure and niche distro, your text does no favor being such an obfuscated and unreadable blob.
Sorry Anderson... I also was happier when we were just 2 making the more useful dialog already closed. Also my "learning and attention problems trigger"ed when someone else when off the good interpretation of my writing... O.o ... lolz ... have no idea of you are talking about. ps ::: according to you published location ::: Presumo que sejas brasileiro, e falas portugues... :) ... a minha lingua nativa ::: sempre escrevo melhor o portugues (sem acentos nem cedilhas porque o teclado nao os tem), que o ingles... e' isso ::: peco desculpa pela falta de qualidade do meu ingles nao nativo... sei e' escrever o meu codigo, e apenas aqui venho para me-vos tentar ajudar... seja ao debian, ao nixos ou whatever... :) ... mas se te estou a fazer confusao ::: ja' nao gosto... o.O?... e menos a ti ::: que empakotaste o dblcmd tao eficazmente... :) ... (lolz ::: maybe someday i'll consider inviting you for my yet non-existing crew) ... enquanto o extendido off-topic apenas esta' a deixar mais duvidas que respostas... :( ... portanto vou ficar por aqui ::: e evitar dar alento a "elitismos" maioritariamente incompreendentes... :) [ & bom dia para ti, obrigado por tudo, ] pode ser que nos encontremo-nos noutra thread. For the English speaking ::: if thou have no answers to my actual questions, please don't waste our time in replying ::: i came by to learn and help a bit, even if for now if is just by complaining and asking... :) ... sorry for my noticeable lack of "social skills" ::: thanks god for that... :) ... unfortunately written words don't carry the voice of the writer, nor attitude ::: and are quite prone to miss understanding... in future threads i'll try to hold my self from expressing so at ease. [ & have you all hopefully a nice day ]
This conversation has really veered off the original path. If you have any questions, I suggest taking them over to which is a far better forum for those types of conversations. I would however recommend considering if your writing style helps or hinders the chances of constructive feedback.


With and , I still have to type my LUKS passphrase in qwerty. The logs say this: but not much else apparently. The vconsole is set up fine by the time I get a login prompt.
Dup of


Can anybody provide a pointer on why allowing dangling commits to be fetched is a security risk? I can't seem to find any details on this. Is the risk because people assume "unreachable" means "deleted"?
There's a guess in is the original author of the documentation (see )
Hrm, that guess has to do with github's PRs, not with anything in git.
Well, I found a reason why git would want to prohibit this, but it isn't related to security. If you a branch, the commit that used to point to is still available in the repository -- at least until the next happens. If people are allowed to fetch commits by their hash even when those commits are unreachable, a force-push like this would put those commits at risk of being garbage collected. But nobody would notice the breakage until (potentially) much later, when a happened, and by then it will be too late to recover the lost commit. But since users are forced to mention a commit from which their desired ref is reachable, they will notice the breakage immediately. Most important of all, they will notice while there is probably still time to rescue the now-gc-able commit. I think this is the reason. If nobody else can come up with a security-related explanation I'm going to submit a PR to remove the word "security" in .


Steps to reproduce the behavior: Please run and paste the result.
Looks like there is already a PR to address this at And fwiw I had to bisect this to fix my config, first bad commit is
Closing since the linked PR was merged. (Not sure why merge of the linked PR didn't close this...)


Project description vibrantLinux is a GUI tool to serves the same purpose as for Windows, which to modify the saturation of any given screen whenever certain programs are launched/are in focus. Metadata homepage URL: source URL: license: MIT platforms: Linux Only
Bump. I have some low vision issues and "vibrance" makes it much easier to read the screen. Thanks!


Steps to reproduce the behavior: Added 'kanboard' to Then ran My machine: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.


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


Linux kernel 4.6 on the stable channel cannot be compiled due to an outdated patch. The patch is removed from the master by the commit but it is not removed from the stable channel. Please backport the commit.
Cc