jiebi/CodeConvo huggingface dataset:
You might want to open a separate issue for this if you're interested in seeing support or getting this fixed. We would need to detect if nftables support is available and use the correct iptables package everywhere. Not sure if it's worth it, though.
this seems to also cause problems when upgrading systems from before the nftables bump. In my case, these were fixed after a reboot, but it's still a pretty annoying thing, for which we probably should at least make sure there's a release note entry. cc
Hmmh, I'm also a bit baffled about how to interpret defaulting to false. ~It seems and are mutually exclusive, but since we now configure nftables in other places, the firewall module is just broken?~
It seems only supports defining all rules exclusively, which doesn't play very nicely together with other things invoking iptables, or managing rules by themselves (like networkd , libvirt and other programs invoking iptables). Maybe that module needs a bit of a re-vamp - with merged we might want to configure most of what the module was doing, except managing the ruleset by default. However, that's a bit offtopic from the original issue.
you should see nftable tables when invoking , which is where systemd keeps its nft rules. iptables rules configured with the command are in . I think this is mostly a matter of updating the release notes, and raising awareness, that nftables is used, the command is only managing some tables in the nft system, and that there's more rules than what you can see with . I'll try to come up with a PR updating the release notes in that regard. It might not be possible to translate some nftable rules to a iptables syntax - I'm not sure if logging a warning breaks backwards compat with some tools relying on iptables output…
I improved the docs in , PTAL. Fixing the nftables module, and using less iptables in the firewall module should probably be left to another PR.
I opened to track the nftables NixOS module improvements.
git package includes which defines functions for shell prompt customization like . Even though the file is included it's not sourced by default and doesn't make the functions available. Steps to reproduce the behavior: package system-wide. one of the functions provided: the file manually: function becomes available: shell function being available out of the box when package installed. Making the prompt functions available when bash completions are enabled seem to have been the original intention of . However one might also argue that the functions should not be sourced by default if someone doesn't use git prompt customisations provided. It could be placed behind an option but I'm not sure it's worth the hassle. cc
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I'm not a maintainer or expert, but I read your linked Discourse thread and your ticket because it sounded interesting. Great analysis and writeup. My interpretation is that was never intended to be sourced automatically when completions are enabled, for two reasons. First, inside of : which is an instruction to source it explicitly. Second, the for says: which leads me to believe that was created so that it can be used independently from bash completion. Prior to its creation, it might have been available automatically as a consequence of completion scripts being loaded eagerly, but that was accidental.
Thanks for digging deeper into this, Theodore! I agree with your conclusion: it does look like the prompt script wasn't intended to be sourced automatically. I think the best way to approach this in NixOS would be to have a option that would enable sourcing of the file.
I think something like this sounds reasonable. I'm sorry I can't help with it right now, because I haven't set up NixOS yet. (I'm just using nix on my Mac right now.)
No worries, thanks for your help so far :) I might eventually give it a shot myself.
The package fails to build because of missing test dependencies: system: host os: multi-user?: sandbox: version: channels(z0028sn): nixpkgs:
I jailbroke it and the the tests fail anyway. So it should be set to . succeeds.
The problem is that the release tarball on Hackage is incomplete, i.e. the required file appears to be missing. This should be reported upstream () so that they can release a fixed version. Ping:
This should be fixed in 0.6.1, which I just uploaded to Hackage. Please tell me (probably on a pure-zlib ticket?) if you have any further problems.
Describe the bug While Nixpkgs provides version 2018-12-14, there are some fixes landed since then. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
can please check using with a local chekout of nixpkgs?
Yes, I will. Thank you for your prompt response!
I did and tried some commands. It seems to work fine and the store size does not grow significantly. Is there anything else to test?
Describe the bug AppImages assume that the gmp library is present on the system, but appimage-run does not include gmp. To Reproduce Steps to reproduce the behavior: +x the appimage Expected behavior The app should run. Additional context I believe it is because of this commit: I fixed it on my end with: Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
I marked this as stale due to inactivity. &rarr;
not stale
Also affected:
as pointed out by t-paul, appimage specifically assumes GMP is provided by the system
Describe the bug Building fails with the following messages: Note that points to which updates . To Reproduce Steps to reproduce the behavior: Expected behavior The package is built successfully. Notify maintainers (gfan, cddlib), (cddlib) Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(omasanori): nixpkgs: Maintainer information:
cddlib put its .h file in <hash-cddlib-0.94l/include/cddlib/ rather than the old version of the library placing it .h headers in the root. <hash-cddlib-0.94j/include/ So options are get upstream to #include "cddlib/setoper.h" (and the rest of the directly pathed includes) Patch it in the derivation Take a look at the library is being why it differs from 0.94j to 0.94l ...... and see if can be symlinked (botched). not sure why it's subpathing these .h file now?
v0.94k header files are now installed to PREFIX/include/cddlib to avoid clashes with other libraries. configuration file for pkg-config : assuming cddlib installed in <prefixknown to pkg-config, "pkg-config --cflags cddlib" etc will work. (Otherwise, one would need PKGCONFIGPATH=<prefix/lib/pkgconfig). this is the source of the breakage. this probably breaks everything that uses this library.... lovely! So, options are fix it gfan upstream, or patch it in nix?????? has a 41 length thread, where the developers are trying to workout how not to break any application that uses this library and which distro's they want to break.
Thank you for your survey, The long-term solution would be fixing gfan upstream, given that this is not Nix-specific. The current Makefile assumes that, if cddlib headers are prefixed, the prefix is instead of . A variable to change the prefix will help every package maintainer IMHO. However, adding a patch to gfan just altering with into nixpkg may be fine for now. I will try to address it next week but feel free to make a PR if it is urgent for anyone.
Try building
Just ran into the same problem when updating my system flake. For bisecting purposes, nixpkgs was my previous (working) configuration. EDIT: bisection in progress, have to do some large builds now:
Excerpt from : which seems to be the change that breaks , so we probably need to file an upstream issue.
As a workaround, something like this should work:
Note that the downgrade would undo some security fixes; see PR ... which is also why we backported this problem to 22.05.
I see...I'll wait to re-enable qtile then
Depending on how much value you place on the failing test, something like this worked for me: Modifying the package in a general overlay triggered huge rebuilds for me, so I've just replaced it inside my derivation, which is what pulls in in my system configuration.
How would you modify the package with a general overlay? Something like this didn't work for me:
This global overlay works for me, without annoying rebuilds: Note, I'm using and this is imported in . I don't know if you can use it without modifications otherwise.
I have a similar setup, I have (minus the let bindings I have in my config): So I don't see the difference between our configs...
Somehow, the overlay proposed by worked. This reaches about the limits of my Nix knowledge, but maybe is required instead of simply ? Is the only difference I can notice.
Describe the bug There is no AWS AMI for NixOS 20.03 To Reproduce Steps to reproduce the behavior: Check or Try find it in AWS AMI console Expected behavior 03 is created and uploaded to AWS
CC I think knows how to do this part.
Yep, I have no idea how to do this for NixOS, so I'd need someone in the know with AWS AMI for 20.03. This actually was one of my concerns for 20.03.
I know how to build the release AMI and put it on a personal AWS S3 bucket (I'm using one now for my NixOps AWS cluster), but do not have the permissions to upload it on the official account. about 2 months ago I followed this process, which you can use if you're looking to unblock yourself: then follow these instructions to upload using : Then on NixOps you set to your custom AMI. You can also use this to bake in pkgs to the AMI so there's less startup time if you know you'll be downloading specific things on provisioning startup otherwise.
Describe the bug rspamd for aarch64 can't find luajit and fails to build. To Reproduce At the moment of writing, the latest unstable seems to be . Expected behavior Build succeeds Screenshots n/a Additional context Hydra build log: Notify maintainers Metadata Maintainer information:
I managed to pinpoint the issue to the commit , where rspamd was updated from 2.5 to 2.6. Build log: It looks like rspamd is trying to find LuaJIT, but it's only available in builds. Probable fix would be disabling LuaJIT support in CMake flags.
Sorry, looks like I broke it in PR . I didn't notice the failure, probably because it showed as a grey dot instead of a red cross :x:: I'm not sure why that is, perhaps because it has both a build failure in the output (same one as you see), AND an evaluation failure
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: sumneko-lua-language-server <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 3.2.3 desired version: 3.4.1 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
Hi. So I'm running KDE and whenever I try to launch the AnyDesk application, I get the notification: Launching AnyDesk (Failed) Could not find the program '/nix/store/a1cic900s29g1hfwv731cm3bsgni7p9i-AnyDesk.desktop/bin/anydesk' I have to run from the terminal to open AnyDesk. Please run and paste the result. Content of /run/current-system/sw/share/applications/AnyDesk.desktop: However, that Nix store path only has the desktop file and no binaries. The AnyDesk binary is in .
Steps to reproduce the behavior: on darwin aarch64 see Since neomutt is broken on darwin-aarch64. See the CI output: Tangent: is it normal that a failing CI build wasn't marked as a failed check, but rather just ignored? <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.
Broken on Darwin x86-64 as well.
seems to work — I can't tell whether they are running the tests, though, or not. Here are the failing tests.
Looking at the latest comment on the already closed issue here: This issue could use some love. Neomutt is broken on MacOS and it looks like it's the derivation, not upstream.
I can't install neomutt on MacOS with home-manager too
The failing tests were disabled upstream in . I tried simply upgrading to HEAD with the following patch, and the succeeded (darwin-aarch64):
( That's a different bug which you should probably raise separately.)
Unfortunately, the latest fix didn't work for my Intel Mac, some tests are failing for me. I tested using because I didn't know how to do overrides from the CLI
Yes, the failure on should be a separate bug (and could probably be fixed by putting into ).
When I click on any program in latte-dock, nothing happens. If I run in a terminal, I get these warnings:
I figured out the issue is that latte-dock code fails to detect the version of plasma desktop. For that they parse the output of . I made a dirty test with hardcoded value in and which works around the issue. What is the correct solution to have latte-dock detect the version of plasma? Does it not have access to plasmashell path? Also I noticed that the command results in a segfault. Is that an issue?
See for more discussion. Would you mind describing how to trigger the issue for a person (such as me) who doesn't use plasma shell nor latte dock and so is unaware of (a) how the thing is supposed to work (b) how to set it up?
Sure. the latte-dock package latte-dock. There will be a in the nix store path/share/applications that should appear in your application launcher. For more verbosity, run will see the default layout for latte-dock appear at the bottom of the screen ! By default it has in my case Firefox, Dolphin, and a clock widget. I don't know if it will show your default browser and file manager instead. will auto-hide if a windows covers its area. app that you open should also appear there (eg. a terminal emulator) on an icon of an app that is not already open should open a new instance on an icon of an app that is already open should show that windows if there is only one. If there are more than one, it should show an option to chose the window. At point 6 or 7 in NixOS currently nothing happens and we get in the log which is due to in latte-dock (see )
Curious. I can't reproduce this. Could you try cleaning latte-dock qml cache () and trying again? [aroun plasmashell -v plasmashell 5.26.4 Segmentation fault (core dumped) Can't reproduce this either with Plasma 5.27.
When running , the issue is still happening for me. The segfault also happens for me in plasma 5.27 on NixOS unstable (inside a VM). !
Which DE are you using? Maybe this happens only in KDE plasma?
NixOS Unstable () with KDE and Radeon graphics. Ok, this seems like a plasma bug, though very weird. Can you provide a stack trace? Here's the short instruction: Install gdb in your system cp . chmod u+w ./plasmashell open plasmashell in your text editor, scroll to the last line, add gdb into it so that it looks like this: (the hash might be different) run You'll be presented with the gdb repl. Run commands and . If you get a segfault, run . Copy the stack trace and paste it here. Also, having your VM would help.
Thank you for the instructions.
Oh sorry.. i forgot to ask you to run in gdb if you get a segfault. That was actually supposed to give you the stack trace. Updated the instruction above. But from the looks of it, there's something wrong with d-bus in your system and this is a plasma bug, not a latte-dock or nix bug. The best course of action for you would be to create an issue in KDE bug tracker and attack system info, stack trace, and other relevant data.
Here is the bt Ok I will try to create an issue in the KDE bug tracker. Are you saying that latte-dock works perfectly well on NixOS on your side, in the current state? Can you share your nix config? EDIT: How do I install debug symbols on NixOS?
Are you saying that latte-dock works perfectly well on NixOS on your side, in the current state? Can you share your nix config? It's pretty generic. I have latte-dock in and KDE installed as per wiki: This has worked with Radeon, Nvidia, and Intel graphics. EDIT: How do I install debug symbols on NixOS? This might be tricky. Here are a couple of relevant links. I haven't tried this myself, mind you. P.S. I use X11 only. Scrolled through this thread and didn't find any mentions of whether you test this with Xorg or Wayland.
My config is pretty generic too, especially in the VM, I installed NixOS with KDE Plasma, latte-dock in system packages and not much more. I actually switched channel to unstable to try with plasma 5.27, but apart from that I'm basically on default nix config. I did slightly more configuration on my main NixOS install, 22.11, but get same behavior in both cases. Debug symbols seems painful on NixOS. Unsure if I will do that now. Thank you for the help. I use X11 too.
Ok, so after reading the suggested , I enabled and followed the instructions of the option I have and The part for plasma-workspace seems to work fine, but the one for qt5 givers this:
To reproduce the bug described in this issue, a simple way is this: the official NixOS virtualbox ova from (22.11.2939. at the date of writing this) it in VirtualBox the vm konsole will segfault will run latte-dock and you will see that clicking on items in the dock does nothing
I also tried to update the vm to unstable still segfaults, only that the version shown is 5.27.2 still nothing happens when clicking on items in the dock
Again, this seems like a Plasma bug, possibly due to VirtualBox video drivers or something.
Package name: Latest released version: 0.1.39 <!-- Search your package here: --- Current version on the unstable channel: 0.1.38 Current version on the stable/release channel: 0.1.28 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers (sorry!) Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
When trying to install Ocenaudio, the installation fails due to a sha256 hash mismatch. Steps to reproduce the behavior: ocenaudio to my NixOS config I expected the program to be installed. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Maintainer information:
looks like aur has the same problem this should be reported upstream.
Package name: lightningcss Latest released version: 1.24.1 <!-- Search your package here: --- Current version on the unstable channel: 1.22.0 Current version on the stable/release channel: 1.24.0 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers myself, <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Despite being a minor version bump, an entire dependency chain was for NAPI which I think has something to do with WASM which fails the test in Nix. See lightningcss’s open bug on their Microsoft GitHub proprietary issue tracker @ As a non-Rust developer, I have no idea what this error is supposed to mean with its Cargo package management. Hopefully their maintainer will eventually have a look. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: [^1] or offering a non-proprietary, non-US-corporate-controlled mirror for this free software project. I wish to delete this Microsoft account in the future, but I need more projects like this to support alternative methods to send patches & contribute.
Build error when updating:
Personally I’ve stuck with version 1.23.0 since 1.24.0 had a regression for system colors. The upstream maintainer seems to be too busy with other stuff to look into issues.
should fix it for further releases. For this particular 1.24.1 release, I a patch to automatically patch the source, see
great work!
Describe the bug See https://nix- The particular cases that fail are I believe rust was updated recently (was that in the release?). It doesn't appear upstream has made a release recently, so perhaps if this report is forwarded to them they can direct us to which patches could fix the test failures etc. cc
According to and bug reports, this seems like a ulimit issue. An interesting workaround for hydra could be using , as suggested in but it's certainly isn't necessary on my machine because I've tested the build and it passed it.
sounds like it would make an already long checkPhase longer :rofl: How about we try ?
We can try this indeed. The question is, what are the default limits of a build user on hydra? Are we sure this might make a difference?
I noticed you've marked sequoia as broken in . Even if a package fails to build on hydra butt doesn't fail locally, does it mean we mark it as broken in its ? Doesn't sound right to me..
That's was the motivation for the issue being opened. If we bump in preCheck and unmark it as broken I think we should be good. ofborg can serve as testing perhaps similar to hydra.
The point is, that we haven't even tried playing with these settings. I would have tried doing it my self but since I know nothing nor I have any effect on Hydra's deployment etc., I wouldn't even know how to test it. What bothers me is the fact it was marked as broken without any attempts by someone with more influence then me to debug it's failure to build only on hydra. Are we even sure this wasn't a failure that happened only once?
Should we close this issue with the PR?
No, it's still failing , at least for hydra, it runs out of file handles
A bit off-topic maybe but I generated a Nix expression for sequoia using , as build times for sequoia where around hours for me. It works now like a charm, as every crate got its own derivation. It can be found here, as a flake: Maybe repackaging with could be an option?
This may be an option, but unpleasant as the generated deps file usually is 1-10k+ of generated noise.
(for local building, this works great)
Yeah, that noise is a bummer. Sometimes I dream of having all of packaged the way we do it with , but I guess that would blow up Nixpkgs indefinitely. But maybe someday when Nix flakes are ready? …
I'm not sure I have enough time to have a good view on this. What's most important about specifically, is the fact we use upstream's to install many other files that should be part of the package's output - files such as libraries, ZSH/Bash completion files and headers. So I'm not sure how will this go together with the approach.
If anyone is interested in a sequoia flake which is built incrementally (vs. everything built in a single derivation), I try to maintain one here:
sequoia , but it hasn't tried 0.16.0 yet - .
Yep, we need to fix it for python 38 though
The 'select file' dialog works fine, but I cant actually open or edit anything. Steps to reproduce the behavior: Either: via the GUI, then a design or a design via the command line: A edit window with a preview should appear. Please run and paste the result.
Judging by the error message, this might be as simple as compiling with wayland in the deps like ?
Omg it worked! Can I leave it with the maintainers or do you want me to file a PR?
If you submit the PR yourself then you automatically get ownership/credit for your work :-)