jiebi/CodeConvo huggingface dataset:
Change:
, withCoredump ? true , withCryptsetup ? true , withDocumentation ? true <del> , withEfi ? stdenv.hostPlatform.isEfi && !stdenv.hostPlatform.isMusl </del> <ins> , withEfi ? stdenv.hostPlatform.isEfi </ins> , withFido2 ? true , withHomed ? !stdenv.hostPlatform.isMusl , withHostnamed ? true

Discussion:
The systemd-boot efi binary produced by pkgsMusl.systemd does not boot. This is particularly evil, because it is a runtime failure (pkgsMusl.systemd builds fine) and it occurs before the nixos generation selection, so effectively it will brick the installation. Also the BOOTX64.EFI is only update on a systemd version change, not every time the file changes. So users might think they have successfully booted with one systemd-boot, but actually it was not copied over to the boot partition because the existing file there was already from the same systemd version. A.k.a. we should fix pkgsMusl.nixosTests.systemd-
When I port over the gummiboot package from alpine, it builds and boots
Bisected this, first within nixpkgs: Then within systemd: In the end, it builds and boots even in later versions when removing the parameter again:
Openembedded does not have this problem because they use clang, not gcc. With a few hacks I could build a systemd-boot from pkgsMusl.pkgsLLVM and this booted without patching out the .
Change:
<del> { lib , buildGoModule , fetchFromGitHub }: buildGoModule rec { pname = "kcl-cli"; version = "0.8.9"; src = fetchFromGitHub { owner = "kcl-lang"; repo = "cli"; rev = "v${version}"; hash = "sha256-slU3n7YCV5VfvXArzlcITb9epdu/gyXlAWq9KLjGdJA="; }; vendorHash = "sha256-Xv8Tfq9Kb1xGFCWZQwBFDX9xZW9j99td/DUb7jBtkpE="; ldflags = [ "-X=kcl-lang.io/cli/pkg/version.version=${version}" ]; subPackages = [ "cmd/kcl" ]; meta = with lib; { description = "Command line interface for KCL programming language"; homepage = "https://github.com/kcl-lang/cli"; license = licenses.asl20; maintainers = with maintainers; [ peefy ]; mainProgram = "kcl"; }; } </del>

Discussion:
After installation kcl-cli shell completion is not available. Steps to reproduce the behavior: kcl-cli completion Shell completion should be installed. 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
nativeBuildInputs = [ cmake ninja ]; buildInputs = [ netcdf hdf5 curl ]; <del> # 10 - cxx4_test_filter (Failed) # Setting Filter....Caught unexpected exception. doCheck = false; </del> <ins> doCheck = true; </ins> enableParallelChecking = false; <ins> preCheck = '' export HDF5_PLUGIN_PATH=${netcdf}/lib/hdf5-plugins ''; </ins> meta = { description = "C++ API to manipulate netcdf files";

Discussion:
While rebuilding on this system that requires the package a failure while building has been occurring since NixOS 22.11. One of the tests fails.
I am not the maintainer of this package. Maybe can help? also have a look at:
Silly me for not checking and just the current release, disabling tests is a hell of a workaround but definitely works!
I'm also not a maintainer of the package, but I'm happy to fix it nonetheless :) There's an issue in that we don't have a good way of setting HDF5PLUGINPATH appropriately. Maybe I'll come back and fix this at some point, but for now this will do...
Change:
postPatch = '' substituteInPlace cmake/libutils.cmake --replace /usr/bin/libtool libtool substituteInPlace cmake/os/Darwin.cmake --replace /usr/bin/libtool libtool <ins> substituteInPlace cmake/fido2.cmake  --replace ''${MY_PKG_CONFIG_EXECUTABLE} "${pkg-config}/bin/pkg-config" </ins> ''; buildInputs = [

Discussion:
with having mysql pulls mysql-8.0.28. Steps to reproduce the behavior: : Nix shell started with mysql-8.0.28 installed with necessary libraries, scripts and binaries to run in Intelx8664 darwin macOS. N.A. Please run and paste the result.
facing the same issue on macOS aarch64
fix:
Change:
, libtheora , dav1d , zimg <ins> , svt-av1 </ins> # Codecs, audio , libopus , lame

Discussion:
As title says, the ffmpeg that handbrake uses can't be built, complaining about missing sdl2. Steps to reproduce the behavior: to install handbrake the error Handbrake is installable If applicable, add screenshots to help explain your problem. Please run and paste the result.
Try with this patch:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
sorry i missed this, I don't know how can I try that?
I am getting a similar error, after running a channel update on the unstable channel.
Here to report the same issues, specifically seems to fail with . Here's the errors: Results of : Might be worth reopening.
This is a different issue and already fixed in nixos-unstable-small and should be in normal nixos-unstable shortly.
Sounds great, appreciate the heads up.
Change:
enable = mkEnableOption "Plymouth boot splash screen"; <ins> font = mkOption { default = "${pkgs.dejavu_fonts.minimal}/share/fonts/truetype/DejaVuSans.ttf"; type = types.path; description = '' Font file made available for displaying text on the splash screen. ''; }; </ins> themePackages = mkOption { default = [ nixosBreezePlymouth ]; type = types.listOf types.package;

Discussion:
It should always show the NixOS version. Reproducible on: Lenovo Thinkpad X230 with grub Not reproducible on: Apple iMac 11,3 with systemd-boot (EFI) Thinkpad L470 with systemd-boot (EFI) system down system system: host os: multi-user?: sandbox: version: channels(davidak): channels(root): nixpkgs:
I can second this. It's been the case for ages.
Yes, I'm not sure why this is. It used to show it at startup, and I don't think anything much has changed there.
I did an update yesterday and bootet the system today and the version was shown. It's a Thinkpad L470. I will see if it fixes it also on the system i used when reporting this issue. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Doesn't work here on latest unstable.
Seems to be a problem specifically with GRUB.
I'm using systemd-boot, not GRUB.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
Problem persists.
This is because the Plymouth plugin is missing from the initrd, along with a font with which to render the text. See .
Change:
rev = "v${version}"; sha256 = "sha256-B4d8D4IfLYAIYVN80Lrh5bywD5iacSnUVwEzbc6Xq7g="; }; <del> nativeBuildInputs = [ pkg-config ]; </del> <ins> prePatch = lib.optionalString (!dbusSupport) '' substituteInPlace cmake/modules.cmake --replace 'list(APPEND MODULES ctrl_dbus)' "" ''; nativeBuildInputs = [ pkg-config cmake ]; </ins> buildInputs = [ zlib openssl

Discussion:
Baresip fails to build after because the baresip no longer finds librem through pkg-config. Building baresip with Cmake resolves this, but then there is a new build failure: Steps to reproduce the behavior: baresip
Sorry! I think fixes this. I developed and tested them together but wanted to take more time to be sure baresip was finding all of its dependencies. I didn't realize that merging one without the other would break things. We can either merge or else revert and
Waiting for is fine by me.
Change:
systemd.services.systemd-resolved = { wantedBy = [ "multi-user.target" ]; <ins> aliases = [ "dbus-org.freedesktop.resolve1.service" ]; </ins> restartTriggers = [ config.environment.etc."systemd/resolved.conf".source ]; };

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

Discussion:
I in total 173 profiles to and now after booting, only around 100 connections are known to . Steps to reproduce the behavior: a lot of connections configured over All connections are available. All 173 connections are available in the folder By manually triggering a all missing profiles are loaded. I noticed that the connections are missing which stand at the end of the script . This I find weird, as at the end of the script stands <details<summaryOutput after reboot</summary</details<details<summaryOutput after 'sudo nmcli connection reload'</summary</details- Suspecting a race condition during boot, here are syslogs of a boot with 173 connections and of of a boot with 4 connections <details<summary173 connections (connections missing)</summary</details<details<summary4 connections (everything works fine)</summary</details<details<summaryMeld difference of the logs</summary! </detailsOfficial maintainers in the meta: teams.freedesktop.members From git blame: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hey, I'll try to debug this soon-ish
stupid question, try adding and see if that fixes your problem.
yes that fixed it :+1: could have tried this myself :seenoevil: maybe this should be automatically set with ensureProfiles?
Yeah I'll do a pr, should have done it the first time around :seenoevil:
Change:
<ins> diff --git a/sdk/program/src/account_info.rs b/sdk/program/src/account_info.rs index 372370d0e15a0f2877b02ad29586e5b352438b24..3db3e9839b6535786e60be5602c03d0c909bf937 100644 --- a/sdk/program/src/account_info.rs +++ b/sdk/program/src/account_info.rs @@ -182,6 +182,7 @@ impl<'a> AccountInfo<'a> { Ok(()) } +    #[rustversion::attr(since(1.72), allow(invalid_reference_casting))] pub fn assign(&self, new_owner: &Pubkey) { // Set the non-mut owner field unsafe { </ins>

Discussion:
Package name: solana-cli Latest released version: 1.16.27 <!-- Search your package here: --- Current version on the unstable channel: 1.14.23 Current version on the stable/release channel: 1.14.23 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hello I was able make the building script work so solana-cli is updated to 1.16.27 expect solana has bug in a which doesn't let me compile. The issue was already reported back back in 22 november 2023: solana-labs/solana So until is fixed I can't do anything more, as soon as it is fixed I will post my pr
Thanks , did you manage to build it for the current version? () On the master of nixpkgs I couldn't even build the existing version of Solana due a rocksdb issue I also found this commit on homebrew PRs. Seems like they patched this part in order to make the build work:
Hello I didn't test it and I don't think I need since I made it able to compile 1.16.27 I appreciate the citation, with the patch used by them I was able to fix it, appreciate your help
Change:
<link xlink:href="https://grafana.com/docs/grafana/latest/installation/upgrading/#upgrading-to-v7-0">in the Grafana documentation</link>. </para> </listitem> <ins> <listitem> <para> The <literal>hardware.u2f</literal> module, which was installing udev rules was removed, as udev gained native support to handle FIDO security tokens. </para> </listitem> </ins> </itemizedlist> </section> </section>

Discussion:
Describe the bug I recently noticed errors in logs around a missing group: To Reproduce Steps to reproduce the behavior: to on a NixOS system built from a recent commit logs with e.g Expected behavior No errors in logs. Additional context I'm not 100% sure what changed to trigger this error or how to best address it, but the config file does refer to a group, which commonly is present on other distros: The group is indeed not present on my NixOS system: The udev config seems to be fetched from the package. Metadata Maintainer information:
I see 2 ways of fixing this: a) just adding the group - this group is used in older Debian/Ubuntu distributions to indicate the device can be mounted using pmount b) removing from udev files as should be enough
A simple nixpkgs search shows there are more modules/packages using the group such as: and upstream packages tarballs used in: In we replace the the group with the group.
Since we don't include that group by default like Debian does, we should probably remove these references to plugdev. Users can always add their own custom udev rules if they want special group handling.
Looking at , seems to be the right way forward for most of these rules. We might just want to patch those to use it, and upstream these patches.
most of the affected udev files already have ; they just include the group for older Debian/Ubuntu distros. This is indeed obsolete method, so fix is indeed just a matter of removing this from the udev files.
According to removing breaks some non-systemd distros where nixpkgs maybe independently installed. What are your thoughts on removing the offending rule via ? Same approach can be taken with other . This would preserve backward compatibility with non NixOS systems.
If I'm not mistaken, this comment is not about nixpkgs on non-systemd distros, but other non-systemd distros in general. As written in , we probably can just ignore the warning for now, and remove the udev rule entirely once a systemd with has landed in nixpkgs.
This should be solved by , PTAL.
Change:
, qtsvg , qtimageformats , gtk3 <ins> , glib-networking </ins> , boost , fmt , libdbusmenu

Discussion:
The webkit integration of telegram-desktop is broken, resulting in bots using to not work properly. Steps to reproduce the behavior: a chat with the demo bot . the "Order Food" button telegram-desktop crashes, or the webview fails to render the webpage The webkit integration works as shown in Reference:
Arch Linux related issue closed today: , telegram-desktop now works on Arch Linux since 5.0.2.
There is also improvement on our front, it now shows "tls support is not available" in stead of straight crashing. Edit: which can be fixed by adding glib-networking.
Change:
text = "whoa"; }; <ins> networking.hostName = "ec2-test-vm"; # required by services.httpd </ins> services.httpd = { enable = true; adminAddr = "test@example.org"; <del> virtualHosts.localhost.documentRoot = "${pkgs.valgrind.doc}/share/doc/valgrind/html"; </del> <ins> virtualHosts.localhost.documentRoot = "''${pkgs.valgrind.doc}/share/doc/valgrind/html"; </ins> }; networking.firewall.allowedTCPPorts = [ 80 ]; } ''; script = '' $machine->start; <ins> # amazon-init must succeed. if it fails, make the test fail # immediately instead of timing out in waitForFile. $machine->waitForUnit('amazon-init.service'); </ins> $machine->waitForFile("/etc/testFile"); $machine->succeed("cat /etc/testFile | grep -q 'whoa'");

Discussion:
Describe the bug On current master (), the ec2 tests don't work: Expected behavior They should work in order to be portable to python, see CCing contributors who wrote/touched this code:
Change:
# this adds a good chunk of time to the build "-DBUILD_TESTING:BOOL=ON" "-DGOOGLE_CLOUD_CPP_ENABLE_EXAMPLES:BOOL=OFF" <ins> "-DCMAKE_CXX_STANDARD=17" </ins> ] ++ lib.optionals (apis != [ "*" ]) [ "-DGOOGLE_CLOUD_CPP_ENABLE=${lib.concatStringsSep ";" apis}" ];

Discussion:
name: google-cloud-cpp current version: 1.38.0 desired version: 1.42.0 maintainers: who did the last update Please tag this issue in your PR.
I don't have time to work on this at the moment.
Change:
kawkab-mono-font = callPackage ../data/fonts/kawkab-mono { }; <del> kde-rounded-corners = libsForQt5.callPackage ../data/themes/kwin-decorations/kde-rounded-corners { }; </del> <ins> kde-rounded-corners = kdePackages.callPackage ../data/themes/kwin-decorations/kde-rounded-corners { }; </ins> khmeros = callPackage ../data/fonts/khmeros { };

Discussion:
the package kde-rounded corners does not work with plasma 6 Steps to reproduce the behavior: the package <name.packages = [ ] = true; there should be an effect "shaped corners" in kde settings Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
--prefix PATH : ${lib.makeBinPath [ openssl ]} ''; <del> preFixup = lib.optionalString (stdenv.isLinux && !stdenv.hostPlatform.isMusl) # XXX: revisit </del> <ins> preFixup = lib.optionalString withSlimLib </ins> # Build libunbound again, but only against nettle instead of openssl. # This avoids gnutls.out -> unbound.lib -> openssl.out. <del> # There was some problem with this on Darwin; let's not complicate non-Linux. </del> '' configureFlags="$configureFlags --with-nettle=${nettle.dev} --with-libunbound-only" configurePhase

Discussion:
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
Change:
owner = "nushell"; repo = "nushell"; rev = version; <del> hash = "sha256-itr/n8fodi9EvED6j4UMGFUaF42UVhgkGws8A5JqBA8="; </del> <ins> hash = "sha256-s/aJVk+45Ietegb9Cn19/U3NlNMHQh2GezHkoIRxRrk="; </ins> }; <del> cargoHash = "sha256-s2O/6g3+fAkiqZwq3PUDpaFtG+uj/3pSs3eZbCbAcuQ="; </del> <ins> cargoHash = "sha256-0xwo3M5uog6v0VcT9IhNZ22/xIhUShVNt6Vkp3GpsNI="; </ins> nativeBuildInputs = [ pkg-config ] ++ lib.optionals (withDefaultFeatures && stdenv.isLinux) [ python3 ]

Discussion:
Package name: nushell Latest released version: 0.93.0 <!-- Search your package here: --- Current version on the unstable channel: 0.92.1 Current version on the stable/release channel: 0.87.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 <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Looks like I was mentioned, or not..... :)
Thanks for the update! In it says without the r in the middle. Maybe you should correct that.
Sorry that was a bad joke ;) Nope, it's not a mistake. is indeed a maintainer of this package. Their last update package update () was 3 years ago, back in April 2021. Their last PR to Nixpkgs was in Nov 2021. They still seem to be active in Nixpkgs in reviewing PRs (last review being in February this year). I happened to see this update request and decided to make a PR :)
Change:
}: let <del> inherit (python2Packages) pygtk wrapPython python; </del> <ins> python = python2.withPackages (pp: [ pp.pygtk ]); </ins> in stdenv.mkDerivation rec { pname = "gimp"; version = "2.10.20";

Discussion:
Describe the bug GIMP uses Python and GTK+ for e.g. plugins. But GIMP in the NixOS-GIMP-package cannot find the Python-gtk-module: GIMP itself starts, but e.g. some plugins cannot be used, e.g. . When selecting this plugin, nothing happens, and the following error is shown in the console (again): To Reproduce Steps to reproduce the behavior: GIMP. GIMP. at the error-messages. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Can confirm this still doesn't work. Of note is that installing will allow when used from the REPL, but GIMP will still not recognize it. Tagging since they are tagged as the maintainer.

I see the following warnings when running gimp: Not sure if they are critical or not. I do have problems with one Python plugin, not sure if this could be related. Run gimp from the terminal. I'm running it from i3+none desktop environment, if that matters. Please run and paste the results.
I can see the warning too. This is what the file looks like on Arch: nothing special compared to ours: The file exists and is executable Not really sure what is wrong. Also the Python scripts seem to work, at least does.
For me, resynthesizer runs but it doesn't produce correct results:
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
Still important to me. This is the current console output:
I have found this issue can be fixed by installing the python package by yourself (which is weird: it looks like GIMP may be trying to use the command from your ). I have it in my systemPackages and I got past that stage. However, is still blocking the usage of some plugins.
Spent some time in and it looks like the extension mapping from file only searches in path, not in the mapping described on previous lines and registered in : : The extension is so some other mechanism than extension matching must be involved – perhaps shebangs are applied. We will still want to hardcode the path to ensure purity.