jiebi/CodeConvo huggingface dataset:
Change:
{ <del> "name": "Sunshine", </del> <ins> "name": "sunshine", </ins> "lockfileVersion": 3, "requires": true, "packages": {

Discussion:
Package name: sunshine Latest released version: 0.22.2 <!-- Search your package here: --- Current version on the unstable channel: 0.22.0 Current version on the stable/release channel: 0.21.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: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
{ lib, consult, <del> embark, </del> <ins> embark-consult, </ins> fetchFromGitHub, forge, gh,

Discussion:
part of No errors in native compliation of emacsPackages.consult-gh <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
mkdir -p /run/systemd/system/systemd-udev-trigger.service.d cat <<-EOF > /run/systemd/system/systemd-udev-trigger.service.d/zzz-lxc-override.conf <del> @@ -145,24 +97,12 @@ EOF </del> <ins> @@ -132,37 +84,13 @@ ExecStart=-${cmd} trigger --type=devices --action=add EOF </ins> } <ins> -# fix_systemd_sysctl overrides the systemd-sysctl.service to use "ExecStart=-" instead of "ExecStart=". -fix_systemd_sysctl() { -	cmd=/usr/lib/systemd/systemd-sysctl -	! [ -e "${cmd}" ] && cmd=/lib/systemd/systemd-sysctl -	mkdir -p /run/systemd/system/systemd-sysctl.service.d -	cat <<-EOF > /run/systemd/system/systemd-sysctl.service.d/zzz-lxc-override.conf -[Service] -ExecStart= -ExecStart=-${cmd} -EOF -} - </ins> ## Main logic -# Nothing to do in Incus VM but deployed in case it is later converted to a container -is_incus_vm || is_lxd_vm && exit 0

Discussion:
not working in lxc containers. But sysctl command works fine and /proc/sys/ is writable. This nix option seems to finally take effect via . And the look like this: This looks fine, So I tried to manually run the command in , and it takes effect! But this looks even weirder. Through , I got: There is an unusual . It looks like this: Obviously, there is not is NixOS. So won't run at all. I looked it up on the internet and found out it's from distrobuilder: So maybe we should just patch it? Steps to reproduce the behavior: a privilege container with NixOS in it. something to and rebuild the system , and there is no effect should run and takes effect. <!-- 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]:
Are you able to you reproduce this with unstable? There are some improvements post 23.11 to the use of the lxc generator.
Yes, I'm already on latest unstable channel. The channel information in metadata tab is incorrect because I'm using flakes. There are many hard-coded FHS paths in distrobuilder. Such as this line, that causes this problem:
can you test this change?
It works fine for me. But I don’t know if there are any problems caused by other hard-coded paths in distrobuilder. And I don’t know whether using sysctl on an unprivileged container will cause the service to fail to start, and whether the startup failure will cause problems. But it seems that sets , so there should be no problem?
Thanks for testing! There shouldn't be, since we patch and wrap the distrobuilder lxc generator. I audited it again after updating the patch for this fix. You can always see the resulting file by building . The PR has tests which should cover unprivileged containers. I've just updated them to add a check verifying systemd-sysctl successfully started.
Change:
unpackCmdHooks+=(_tryUnzip) _tryUnzip() { if ! [[ "$curSrc" =~ .zip$ ]]; then return 1; fi <del> unzip -qq "$curSrc" </del> <ins> # UTF-8 locale is needed for unzip on glibc to handle UTF-8 symbols: #   https://github.com/NixOS/nixpkgs/issues/176225#issuecomment-1146617263 # Otherwise unzip unpacks escaped file names as if '-U' options was in effect. # # Pick en_US.UTF-8 as most possible to be present on glibc, musl and darwin. LANG=en_US.UTF-8 unzip -qq "$curSrc" </ins> }

Discussion:
Hydra fails to fetch when ran on darwin, blocks even linux builds as is a fixed-output derivation: (linux failure: ) I think it's the following suspicious UTF-8 path: darwin and linux should both be able to fetch the same tarball.
The issue with fetching the tarball on macOS was discovered in , and we believe this is a fetchzip bug on macOS. However, until now, it wasn't an actual issue for users because macOS users would use the fixed-output derivation downloaded on Linux and cached by Hydras (see ). Now, it seems like Hydras caches failures as well (it's a new thing, isn't it? Or we were just lucky previously that the Linux fetching would have happened before the macOS one?) and that because of this, a failure to download the source on Darwin is affecting everyone! I don't really have any solution to propose except: as a workaround is it possible to remove the cached failure and retrigger the build on Linux? fetchzip needs to be fixed to handle UTF-8 file names properly. Even if Coq was modified to not include these file names in its source archive anymore, this wouldn't resolve the issue with already released versions. One last workaround idea to the fetchzip issue would be to make the fixed-output derivation not the direct result of fetching the tarball, but something that would fetch it and fix the divergent paths (e.g., by removing the corresponding tests). But I wouldn't even know how to implement this.
I've seen this in a couple other packages already. It's... not nice but fortunately not a very common problem (perhaps partly due to some linux getting it faster or on a retry).
Do you think works correctly on linux? I find -translation as very odd. Is it broken too?
Unpacking is locale-dependent: LANG=C -(bad) LANG=C.UTF-8 -(ok)
My guess the mismatch happens because macos supports UTF-8 locales as is (and mossibly musl as well?). While does not unless is pulled into unzip. I think we have 2 routes: make work on linux (and break a bunch of fixed-output derivations that contain UTF-8), should be a matter of pulling into 's hook (did not test yet). make ASCII-only everywhere by using in 's . It will start consistently mangle non-ASCII for everyone.

Confirmed failure on as well:
WDYT of proposed fix? Once it's in we can fix and friends.
Thanks a lot for digging into and figuring out the cause of this issue! I find your proposed fix as the best (most principled) solution, even if it will require some work to fix past fix-output derivations.
Change:
buildPythonPackage rec { pname = "jsondiff"; <del> version = "1.1.2"; </del> <ins> version = "1.2.0"; </ins> src = fetchPypi { inherit pname version; <del> sha256 = "7e18138aecaa4a8f3b7ac7525b8466234e6378dd6cae702b982c9ed851d2ae21"; </del> <ins> sha256 = "00v3689175aqzdscrxpffm712ylp8jvcpqdg51ca22ni6721p51l"; </ins> }; <ins> postPatch = '' sed -e "/'jsondiff=jsondiff.cli:main_deprecated',/d" -i setup.py ''; </ins> # No tests doCheck = false;

Discussion:
Describe the bug depend on: python3Packages.jsondiff provides . which depends on jsonpatch which also provides . To Reproduce Steps to reproduce the behavior: Expected behavior A shell with the library available to Python scripts. Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): channels(kalbasit): channels(yl): nixpkgs: AND host os: multi-user?: sandbox: version: channels(yl): nixpkgs: Maintainer information: cc
do you have an ETA on this issue? Workaround perhaps?
Apparently the executable in the package is deprecated. I therefore suggest patching out the entry from the entry points:
Another solution is to increase (or was it decrease?) the priority of the package so it takes precedence. Though I am not sure whether this solution works.
removing the binary has fixed this particular issue. However, there's another collision now. What to do with this one? I'm filing the PR to fix the first issue, will wait to fix the second one before merging obviously.
Having a collision between files in the backports package implies that one or more of those packages is using the wrong namespaces convention. See e.g.
or if they are namespace packages, then they shouldn't be installing the there altogether for python3, because they should be adhering to That seems to be the case: Taking another step back, for python3, this module shouldn't be needed as python3x will use the module
would you be able to help me get this fixed in . You seem to have more Python knowledge than myself :smile:
hmmm this worked Is this an acceptable fix?
I made it work with Python3, but it's still broken for Python2 (see ).
I'm trying to make a pr now :)
For python2, you will need to do something similar to where you do Unfortunately with namespace packages and python2, there's no way to avoid this :(
you should be able to rebase on top of master now that has been merged
Change:
<ins> { lib, stdenv, fetchurl, perl, linuxPackages_latest }: stdenv.mkDerivation rec { pname = "linux-manual"; inherit (linuxPackages_latest.kernel) version src; nativeBuildInputs = [ perl ]; dontConfigure = true; dontBuild = true; postPatch = '' patchShebangs --build  scripts/kernel-doc  scripts/split-man.pl ''; installPhase = '' mandir=$out/share/man/man9 mkdir -p $mandir KBUILD_BUILD_TIMESTAMP=$(stat -c %Y Makefile)  grep -F -l -Z  --exclude-dir Documentation  --exclude-dir tools  -R '/**'  | xargs -0 -n 256 -P $NIX_BUILD_CORES  $SHELL -c '{ scripts/kernel-doc -man "$@" || :; }  | scripts/split-man.pl '$mandir kernel-doc test -f $mandir/kmalloc.9 ''; meta = with lib; { homepage = "https://kernel.org/"; description = "Linux kernel API manual pages"; license = licenses.gpl2Only; maintainers = with maintainers; [ mvs ]; }; } </ins>

Discussion:
Package man(9) docs The man(9) docs contain information about the Linux kernel's routines. For example, there would be an entry for the function, which is responsible for installing a driver to the kernel that handles the events and their responses required by that particular piece of hardware. Metadata homepage URL: source URL: license: gpl2Only (?) platforms: linux This set of documentation is generated by running the Perl script , which then outputs the generated man-page to STDOUT.
Change:
${pkgs.envsubst}/bin/envsubst -i ${ini.generate (lib.escapeShellArg profile.n) profile.v} > ${path (lib.escapeShellArg profile.n)} '') (lib.mapAttrsToList (n: v: { inherit n v; }) cfg.ensureProfiles.profiles) + '' <del> if systemctl is-active --quiet NetworkManager; then ${pkgs.networkmanager}/bin/nmcli connection reload fi </del> <ins> ${pkgs.networkmanager}/bin/nmcli connection reload </ins> ''; serviceConfig = { EnvironmentFile = cfg.ensureProfiles.environmentFiles;

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:
systemd.services.systemd-remount-fs.restartIfChanged = false; systemd.services.systemd-update-utmp.restartIfChanged = false; systemd.services.systemd-user-sessions.restartIfChanged = false; # Restart kills all active sessions. <ins> systemd.services.systemd-udev-settle.restartIfChanged = false; # Causes long delays in nixos-rebuild </ins> # Restarting systemd-logind breaks X11 # - upstream commit: https://cgit.freedesktop.org/xorg/xserver/commit/?id=dc48bd653c7e101 # - systemd announcement: https://github.com/systemd/systemd/blob/22043e4317ecd2bc7834b48a6d364de76bb26d91/NEWS#L103-L112

Discussion:
When running , sometimes fails to start with an error message: Run System: NixOS: Nix version: Nixpkgs version:
I can confirm this issue. It also delays restarting of other units (probably dependent services) after upgrade. I do: as a workaround when this happens, so that the other services can restart faster. It only happens on my physical machine. My v-server never had this problem.
Can confirm this is still happens on 17.09 (just happened right now, and has been happening on every single ).
My workaround is to use:
how do you specify that? I get:
there was a typo: UPDATE 2: One also need to make it a list to override!
The solution posted above no longer seems to work after upgrading to 18.09 - has anyone else solved this in a different way?
Ran into this issue when I didn't have the EFI boot partition mounted while rebuilding. I think I was starting up an old nixos configuration. Seems to work fine now.
I forgot to make it a list. The empty string makes systemd first resets the option so it can be overriden afterwards.
A potential fix is also here: I want to test this option a bit for myself first.
Change:
'' runHook preInstall <del> mkdir -p $out/share/{applications,ppsspp} </del> <ins> mkdir -p $out/share/{applications,ppsspp,icons} </ins> '' + (if enableQt then '' install -Dm555 PPSSPPQt $out/bin/ppsspp wrapProgram $out/bin/ppsspp 

Discussion:
Missing application icon. I looked at the ".desktop" file and inside is written "Icon = ppsspp", but I can't find an icon with that name. Steps to reproduce the behavior: for "ppsspp" in KDE/Gnome or using anything that can show app icons. isn't shown, for example, on Gnome it just shows the default icon for binaries. The icon appears when searching for the app. Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
! There should be . Upstream has a directory which can be copied over as-is in the custom :
Hi, could you please explain this a little more? I went into usr/share/icons/hicolors, but I'm not sure what to do after that? You said that folder should be copied over. Where do I copy it over? What am I copying over and to where? Could you please elaborate more? Thank you!
Change:
<ins> { cabal, binary, executablePath, filepath, ghcPaths, ioStorage , time, xdgBasedir }: cabal.mkDerivation (self: { pname = "dyre"; version = "0.8.11"; sha256 = "0sg5csshznbbyvq72s4sps7bkjlkfxiwcy4i3ip83lrxjw1msvr8"; buildDepends = [ binary executablePath filepath ghcPaths ioStorage time xdgBasedir ]; meta = { homepage = "http://github.com/willdonnelly/dyre"; description = "Dynamic reconfiguration in Haskell"; license = self.stdenv.lib.licenses.bsd3; platforms = self.ghc.meta.platforms; }; }) </ins>

Discussion:
I'm planning to use nix as a package manager for my development toolchain, but not do the actual development in nix, is that a supported use case? I've hit some issues and have been sending in PRs to resolve them, but looking into it more the issues I've been hitting might have been derivations just working as intended. explains that library derivations in Nix only work when used in a nix environment, be it nix-shell or within nixpkgs. Is the same true for all development derivations, for example compilers and build tools? Examples: ++ doesn't work outside of nix-shell on darwin, but it does on linux, and I'm not sure which of the two is correct (). creates compiler wrappers to handle the way flags from dependencies are propagated in nixpkgs, but those wrappers are unnecessary when using the compilers from profiles. the bazel derivation is a script that wraps bazel to make it use clang and java from nix, instead of resolving it from the caller's , so that it can be used from within nixpkgs, but it results in a bazel that doesn't function correctly when installed. If existing development derivations are meant to be only used in a nix environment, would it be ok to add new derivations for use outside of a nix environment?
Nixpkgs do not explicitly support C++ compilers outside Nix environment, but this is a valuable use case and it would be great if you could work towards it.
It won't be helpful if there's no convention around it, how would someone find out which specific compilers work outside a Nix environment and which don't?
Either the default compilers will work (, ), or people will discover the new compilers (e.g. ) in the list of packages, in Nixpkgs issues, on the wiki, on IRC etc.
I have managed to work around this issue by creating wrappers for the compilers tailored to the specific use cases I have. It works very well, and it seems it's what others are doing as well. I'll close this issue since it's not relevant anymore.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
glib gst_all_1.gstreamer gst_all_1.gst-plugins-base <ins> gst_all_1.gst-plugins-good </ins> libsoup_3 <ins> glib-networking </ins> libadwaita ];

Discussion:
Translation fails using any of the available providers, thus rendering it useless: Google API as per below LibreTranslate API immediately shows a full-window error as per screenshot Lingva API immediately shows a full-window error as per screenshot Steps to reproduce the behavior: anything I expect a translator to be able to translate. ! ! ! is also available.
It seems this is already known.
Change:
]; buildInputs = [ <ins> (opencv4.override { inherit ffmpeg; }) </ins> ffmpeg fftw frei0r

Discussion:
kdenlive can't encode to AV1 due to missing access to libaom-av1 Steps to reproduce the behavior: a new project. → Render → Ultra-High Definition (4K) WebM-AV1/Opus (libre) is available. instead it is disabled. ! This is strange because the package appears to try an use the : I also have ffmpeg installed in my PATH with libaom-av1 support: <details<summary<code% ffmpeg -help encoder=libaom-av1</code</summary</details The exact package I am using is which is available in system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Can reproduce.
Is this related to ?
I'm not sure, but it might be that the encoding libraries are actually not limited by the that uses, but by , which uses and not .
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Yes, this seems to be the issue.
Hi there :) I updated my channels and then rebuild, and still haven't gotten this fix. It still shows the same error, as in the original screenshot. I even libaom by hand, still the same.
Which channels have you updated, and to which versions?
11 and with nix-channel --update
Ah ok, as you see the issue was reported after release of 23.11, so it is fixed only in (and the next release).
I am on NixOS unstable () and Kdenlive 24.02.2 still reports "Unsupported video codec: libaom-av1".
Yes, it seems to have regressed for me as well.
I can't easily bisect the kdenlive derivation itself as it fails to load pipewire shared libraries probably due to skew between my base system and the built kdenlive. However I ran a bisection on with the override and found to be the culprit. At first glance this seems like it should be unrelated. <details<summarybisect script</summary</details
So before this change depends on both ffmpeg 4 and 6. After this change only 6 is in the dependency graph. Maybe 4 was somehow being used and that is needed for to work?
does have libaom-av1.

So presumably something isn't working with ffmpeg 6. Reverting to 4 for now is a possible solution but likely has a lot of downsides as well.
It is worth noting that ffmpeg 6 does have libaom support. So it is possibly an incompatibility between mlt and ffmpeg.
I do see that we are linking two versions of ffmpeg. -full and non-full. So possibly what is happening is that when the other version was 4 it wasn't getting used, so full was. But now that both are 6 the wrong one happens to get used.
This fixes the issue. Maybe the best solution is updating to use the same as . However this makes me think that this isn't the best solution in general.
Created to propagate the ffmpeg version through . I don't know if this fix is the most maintainable solution, but it solves this problem and doesn't harm maintainability.
Change:
postBuild = '' wrapProgram "$out/bin/asciidoctor-epub3"  <del> ${lib.optionalString (epubcheck != null) "--set EPUBCHECK ${epubcheck}/bin/epubcheck"}  ${lib.optionalString (kindlegen != null) "--set KINDLEGEN ${kindlegen}/bin/kindlegen"} </del> <ins> ${lib.optionalString (epubcheck != null) "--set EPUBCHECK ${epubcheck}/bin/epubcheck"} </ins> ''; passthru = {

Discussion:
. Consequently, the is broken. I suppose we need to choose whether to remove the package or find a mirror? CC maintainer: Side notes: Sadly, its replacement, , has no Linux support. But on a more positive note, there are other programs that can produce mobi files, some mentioned in .
I suggest we just drop it. Considering that kindlegen was under an unfree license, we're probably not allowed to distribute it, so let's just blow it away with a release note entry that mentions some alternatives.
I marked this as stale due to inactivity. &rarr;
My current recommendation for NixOS is to use calibre for conversion. It also has commandline tools for scripting.
Change:
wrapQtAppsHook ]; <del> buildInputs = [ libqalculate libarchive muparser qtbase qtscxml qtsvg qtdeclarative qtwayland qt5compat qttools ] ++ (with python3Packages; [ python pybind11 ]); </del> <ins> buildInputs = [ libqalculate libarchive muparser qtbase qtscxml qtsvg qtdeclarative qtwayland qt5compat qttools ] ++ (with python3Packages; [ python pybind11 ]); </ins> postPatch = '' find -type f -name CMakeLists.txt -exec sed -i {} -e '/INSTALL_RPATH/d' ; <del> sed -i src/qtpluginprovider.cpp  -e "/QStringList dirs = {/a    QFileInfo("$out/lib").canonicalFilePath()," </del> <ins> # WARN: This is necessary for albert to detect the package libraries. # Please check if the file below has changed upstream before updating. sed -i src/app/qtpluginprovider.cpp  -e "/QStringList install_paths;/a    install_paths << QFileInfo("$out/lib").canonicalFilePath();" </ins> ''; postFixup = ''

Discussion:
When I try opening the new version of albert (), it crashes and reports that no frontend plugin is found. Steps to reproduce the behavior: albert to 0.23.0 albert Albert opens normally. This issue exists under Wayland and X11. : : Also notifying the author of the last commit Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I think I have relevant infos in my logs. I included the full log (including application restarts and the full stacktrace) as there are some unique messages on consecutive restarts. Note that I use systemd to run Albert. Beware wall of text :eyes: <details<summaryHardware</summary</details<details<summaryAlbert Details</summary</details<details<summaryLog</summary</details