jiebi/CodeConvo huggingface dataset:
Code change:
Since May 10, .NET 5.0 is EOL (End Of Life), and should not be used. Should it be marked as EOF similar to dotnet 2.2 and 3.0? See All packages using dotnet 5.0 should be updated to use a newer, supported version. These packages still need updating: [x] - [x] - [x] - [x] pkgs/development/tools/build- - [x] -
There is at least one package, which currently uses dotnet 5 sdk - . So we will need to update it beforehand. Btw, I'm not sure if we have any policy regarding packages removal, for nixpkgs in general or specifically for it's dotnet part. , what do you think?
The package is also using .NET 5: . But this is because I made the PR upstream updating it from .NET 4 to 5. I suspect that the transition to 6 will be similarly easy.
I think we should just mark it as depricated, as many projects do still use it upstream. Dotnet version 3 is also still commonly used, so I dont expect it would be realistic to remove version 5 any time soon. also uses dotnet 5 by default, I'll go ahead and switch that over now. See . That doesnt mark dotnet 5 as deprecated or change anything from a SDK perspective, just some preperation work.
See as well, it adds a warning whenever dotnet version 5 is used. Not using a throw for now since a few packages depend on it and I dont have the time to clean that all up at the moment.
Can you provide a list of packages that need updating?
Based on a quick grep: pkgs/development/tools/build-
I believe that after all the above PRs are merged, we should be able to safely remove .NET 5 from nixpkgs :)

Related discussion:
text: dotnet-sdk_7 = dotnetCorePackages.sdk_7_0; dotnet-runtime_3 = dotnetCorePackages.runtime_3_1; <del> dotnet-runtime_5 = dotnetCorePackages.runtime_5_0; </del> dotnet-runtime_6 = dotnetCorePackages.runtime_6_0; dotnet-runtime_7 = dotnetCorePackages.runtime_7_0; dotnet-aspnetcore_3 = dotnetCorePackages.aspnetcore_3_1; <del> dotnet-aspnetcore_5 = dotnetCorePackages.aspnetcore_5_0; </del> dotnet-aspnetcore_6 = dotnetCorePackages.aspnetcore_6_0; dotnet-aspnetcore_7 = dotnetCorePackages.aspnetcore_7_0;
Code change:
Shotwell can't build thumbnails for video files. package has an additional executable , which is broken. When run manually, it fails with this message:

Related discussion:
text: sqlite webkitgtk gst_all_1.gstreamer <ins> gst_all_1.gst-libav </ins> gst_all_1.gst-plugins-base <ins> gst_all_1.gst-plugins-good </ins> libgee libgudev gexiv2
Code change:
Project description  Selectdefaultapplication is a very simple GUI application that lets you define default applications on Linux in a sane way. Basically it just loads all installed applications by reading their .desktop files, reads the MimeType fields to see what it supports, and updates with what the user wants. Not all desktop environments provide such a tool, prompting for an agnostic tool. Metadata homepage URL: source URL: license: gpl2 platforms: linux Additional info: AUR package:
You can try using this in an overlay, use .
Seems to work!

Related discussion:
text: githubId = 20391; name = "Nahum Shalman"; }; <ins> nsnelson = { email = "noah.snelson@protonmail.com"; github = "peeley"; githubId = 30942198; name = "Noah Snelson"; }; </ins> nthorne = { email = "notrupertthorne@gmail.com"; github = "nthorne";
Code change:
Project description  Selectdefaultapplication is a very simple GUI application that lets you define default applications on Linux in a sane way. Basically it just loads all installed applications by reading their .desktop files, reads the MimeType fields to see what it supports, and updates with what the user wants. Not all desktop environments provide such a tool, prompting for an agnostic tool. Metadata homepage URL: source URL: license: gpl2 platforms: linux Additional info: AUR package:
You can try using this in an overlay, use .
Seems to work!

Related discussion:
text: <ins> { stdenv, lib, fetchFromGitHub, qmake, qtbase, wrapQtAppsHook }: stdenv.mkDerivation { pname = "selectdefaultapplication"; version = "unstable-2021-08-12"; src = fetchFromGitHub { owner = "sandsmark"; repo = "selectdefaultapplication"; rev = "c752df6ba8caceeef54bcf6527f1bccc2ca8202a"; sha256 = "C/70xpt6RoQNIlAjSJhOCyheolK4Xp6RiSZmeqMP4fw="; }; nativeBuildInputs = [ qmake wrapQtAppsHook ]; buildInputs = [ qtbase ]; installPhase = '' runHook preInstall mkdir -p $out/bin cp selectdefaultapplication $out/bin install -Dm644 -t "$out/share/applications" selectdefaultapplication.desktop install -Dm644 -t "$out/share/icons/hicolor/48x48/apps" selectdefaultapplication.png runHook postInstall ''; meta = with lib; { description = "A very simple application that lets you define default applications on Linux in a sane way"; homepage = "https://github.com/sandsmark/selectdefaultapplication"; maintainers = with maintainers; [ nsnelson ]; license = licenses.gpl2; platforms = platforms.linux; }; } </ins>
Code change:
Project description  Selectdefaultapplication is a very simple GUI application that lets you define default applications on Linux in a sane way. Basically it just loads all installed applications by reading their .desktop files, reads the MimeType fields to see what it supports, and updates with what the user wants. Not all desktop environments provide such a tool, prompting for an agnostic tool. Metadata homepage URL: source URL: license: gpl2 platforms: linux Additional info: AUR package:
You can try using this in an overlay, use .
Seems to work!

Related discussion:
text: seexpr = callPackage ../development/compilers/seexpr { }; <ins> selectdefaultapplication = libsForQt5.callPackage ../applications/misc/selectdefaultapplication { }; </ins> semgrep = python3.pkgs.callPackage ../tools/security/semgrep { }; semgrep-core = callPackage ../tools/security/semgrep/semgrep-core.nix { };
Code change:
I'm bringing up new RPis and their clocks are often wrong. Even though upstream systemd has given exceptions to be able to skip dnssec check for ntp sync, it doesn't... appear to be working. If I set the date manually, often by time I check timesyncd will have already taken care of kicking in and it reports that it's synced. Steps to reproduce the behavior: the clock badly. . and see if your DNS works
If I read it right, only works for systemd-resolved. One general workaround is to use hard-coded IP addresses for NTP (our routers actually do that IIRC).
That commit seems to indicate that it should bypass DNSSEC for timesyncd. This would get my clock back in sync, thus resolving DNSSEC errors for the rest of the system. But timesyncd isn't doing its job. I assume that's because: date wrong -dnssec failure. But maybe also fails if the clock is just too askew? I'll try to look more later, maybe I have to opt-in large corrections? Seems a bit weird to me. Or do we maybe use timesyncd in a non-standard way?
I ran into this on a Raspberry Pi 3B. I'm using systemd-networkd including systemd-resolved. At some point DNS started failing, and I noticed the system clock was out of sync by about 4 hours and not synchronizing anymore. The log of systemd-resolved was full of DNSSEC s: I'm not sure what changed, because I was able to install NixOS just fine. It also was offline before for some time without this problem happening (as far as I noticed at least), and it started happening after it was online for some time without break. Also, the systemd-native workaround should be working on NixOS as well, I can't find anything that indicates a non-standard setup that might overwrite tha workaround. Checking is the standard original systemd unit file that includes the relevant line and as far as I can see it isn't overridden. I also checked and it includes . For now, I worked around the issue by specifying my NTP servers by IP (I used the ones by the ).
Closing as this should be fixed by Please reopen if this is still an issue.

Related discussion:
text: wantedBy = [ "sysinit.target" ]; aliases = [ "dbus-org.freedesktop.timesync1.service" ]; restartTriggers = [ config.environment.etc."systemd/timesyncd.conf".source ]; <ins> # systemd-timesyncd disables DNSSEC validation in the nss-resolve module by setting SYSTEMD_NSS_RESOLVE_VALIDATE to 0 in the unit file. # This is required in order to solve the chicken-and-egg problem when DNSSEC validation needs the correct time to work, but to set the # correct time, we need to connect to an NTP server, which usually requires resolving its hostname. # In order for nss-resolve to be able to read this environment variable we patch systemd-timesyncd to disable NSCD and use NSS modules directly. # This means that systemd-timesyncd needs to have NSS modules path in LD_LIBRARY_PATH. When systemd-resolved is disabled we still need to set # NSS module path so that systemd-timesyncd keeps using other NSS modules that are configured in the system. environment.LD_LIBRARY_PATH = config.system.nssModules.path; </ins> preStart = ( # Ensure that we have some stored time to prevent
Code change:
I'm bringing up new RPis and their clocks are often wrong. Even though upstream systemd has given exceptions to be able to skip dnssec check for ntp sync, it doesn't... appear to be working. If I set the date manually, often by time I check timesyncd will have already taken care of kicking in and it reports that it's synced. Steps to reproduce the behavior: the clock badly. . and see if your DNS works
If I read it right, only works for systemd-resolved. One general workaround is to use hard-coded IP addresses for NTP (our routers actually do that IIRC).
That commit seems to indicate that it should bypass DNSSEC for timesyncd. This would get my clock back in sync, thus resolving DNSSEC errors for the rest of the system. But timesyncd isn't doing its job. I assume that's because: date wrong -dnssec failure. But maybe also fails if the clock is just too askew? I'll try to look more later, maybe I have to opt-in large corrections? Seems a bit weird to me. Or do we maybe use timesyncd in a non-standard way?
I ran into this on a Raspberry Pi 3B. I'm using systemd-networkd including systemd-resolved. At some point DNS started failing, and I noticed the system clock was out of sync by about 4 hours and not synchronizing anymore. The log of systemd-resolved was full of DNSSEC s: I'm not sure what changed, because I was able to install NixOS just fine. It also was offline before for some time without this problem happening (as far as I noticed at least), and it started happening after it was online for some time without break. Also, the systemd-native workaround should be working on NixOS as well, I can't find anything that indicates a non-standard setup that might overwrite tha workaround. Checking is the standard original systemd unit file that includes the relevant line and as far as I can see it isn't overridden. I also checked and it includes . For now, I worked around the issue by specifying my NTP servers by IP (I used the ones by the ).
Closing as this should be fixed by Please reopen if this is still an issue.

Related discussion:
text: systemd-shutdown = handleTest ./systemd-shutdown.nix {}; systemd-sysupdate = runTest ./systemd-sysupdate.nix; systemd-timesyncd = handleTest ./systemd-timesyncd.nix {}; <ins> systemd-timesyncd-nscd-dnssec = handleTest ./systemd-timesyncd-nscd-dnssec.nix {}; </ins> systemd-user-tmpfiles-rules = handleTest ./systemd-user-tmpfiles-rules.nix {}; systemd-misc = handleTest ./systemd-misc.nix {}; systemd-userdbd = handleTest ./systemd-userdbd.nix {};
Code change:
I'm bringing up new RPis and their clocks are often wrong. Even though upstream systemd has given exceptions to be able to skip dnssec check for ntp sync, it doesn't... appear to be working. If I set the date manually, often by time I check timesyncd will have already taken care of kicking in and it reports that it's synced. Steps to reproduce the behavior: the clock badly. . and see if your DNS works
If I read it right, only works for systemd-resolved. One general workaround is to use hard-coded IP addresses for NTP (our routers actually do that IIRC).
That commit seems to indicate that it should bypass DNSSEC for timesyncd. This would get my clock back in sync, thus resolving DNSSEC errors for the rest of the system. But timesyncd isn't doing its job. I assume that's because: date wrong -dnssec failure. But maybe also fails if the clock is just too askew? I'll try to look more later, maybe I have to opt-in large corrections? Seems a bit weird to me. Or do we maybe use timesyncd in a non-standard way?
I ran into this on a Raspberry Pi 3B. I'm using systemd-networkd including systemd-resolved. At some point DNS started failing, and I noticed the system clock was out of sync by about 4 hours and not synchronizing anymore. The log of systemd-resolved was full of DNSSEC s: I'm not sure what changed, because I was able to install NixOS just fine. It also was offline before for some time without this problem happening (as far as I noticed at least), and it started happening after it was online for some time without break. Also, the systemd-native workaround should be working on NixOS as well, I can't find anything that indicates a non-standard setup that might overwrite tha workaround. Checking is the standard original systemd unit file that includes the relevant line and as far as I can see it isn't overridden. I also checked and it includes . For now, I worked around the issue by specifying my NTP servers by IP (I used the ones by the ).
Closing as this should be fixed by Please reopen if this is still an issue.

Related discussion:
text: ./0017-core-don-t-taint-on-unmerged-usr.patch ./0018-tpm2_context_init-fix-driver-name-checking.patch ./0019-systemctl-edit-suggest-systemdctl-edit-runtime-on-sy.patch <ins> ./0020-timesyncd-disable-NSCD-when-DNSSEC-validation-is-dis.patch </ins> ] ++ lib.optional stdenv.hostPlatform.isMusl ( let oe-core = fetchzip {
Code change:
<!-- 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: syncthingtray <!-- 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.1.3 desired version: 1.1.20 <!-- 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.
There's a new dependency now needed for syncthingtray - but there's a problem in the logic upstream here: Here's my packaging attempt:

Related discussion:
text: , extra-cmake-modules , cpp-utilities , qtutilities <ins> , qtforkawesome , boost </ins> , cmake , kio , plasma-framework
Code change:
<!-- 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: syncthingtray <!-- 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.1.3 desired version: 1.1.20 <!-- 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.
There's a new dependency now needed for syncthingtray - but there's a problem in the logic upstream here: Here's my packaging attempt:

Related discussion:
text: }: mkDerivation rec { <del> version = "1.1.3"; </del> <ins> version = "1.1.20"; </ins> pname = "syncthingtray"; src = fetchFromGitHub { owner = "Martchus"; repo = "syncthingtray"; rev = "v${version}"; <del> sha256 = "sha256-ovit2XSkxSjcbpqQUv8IzMqfsfItbtXLbx0/Vy0+J0Y="; </del> <ins> sha256 = "sha256-T0ddAROwVSh+IKGZZNDMC7YB2IfQZal2pAQ5ArirtjI="; </ins> }; <del> buildInputs = [ qtbase cpp-utilities qtutilities ] </del> <ins> buildInputs = [ qtbase cpp-utilities qtutilities boost qtforkawesome ] </ins> ++ lib.optionals webviewSupport [ qtwebengine ] ++ lib.optionals jsSupport [ qtdeclarative ] ++ lib.optionals kioPluginSupport [ kio ]
Code change:
<!-- 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: syncthingtray <!-- 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.1.3 desired version: 1.1.20 <!-- 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.
There's a new dependency now needed for syncthingtray - but there's a problem in the logic upstream here: Here's my packaging attempt:

Related discussion:
text: <ins> { stdenv , lib , fetchFromGitHub , cpp-utilities , qtutilities , qttools , qtbase , cmake , perl }: let fork_awesome_release = fetchFromGitHub { owner = "ForkAwesome"; repo = "Fork-Awesome"; rev = "1.2.0"; sha256 = "sha256-zG6/0dWjU7/y/oDZuSEv+54Mchng64LVyV8bluskYzc="; }; in stdenv.mkDerivation rec { pname = "qtforkawesome"; version = "0.0.4"; src = fetchFromGitHub { owner = "Martchus"; repo = pname; rev = "v${version}"; sha256 = "sha256-J3F+ikz6gQqV+JsOX8EpMOWoTmI6UK5KndFALUo4oiU="; }; buildInputs = [ qtbase cpp-utilities qtutilities ]; nativeBuildInputs = [ cmake qttools perl perl.pkgs.YAML ]; cmakeFlags = [ "-DFORK_AWESOME_FONT_FILE=${fork_awesome_release}/fonts/forkawesome-webfont.woff2" "-DFORK_AWESOME_ICON_DEFINITIONS=${fork_awesome_release}/src/icons/icons.yml" ]; dontWrapQtApps = true; meta = with lib; { homepage = "https://github.com/Martchus/qtforkawesome"; description = "Library that bundles ForkAwesome for use within Qt applications"; license = licenses.gpl2Plus; maintainers = with maintainers; [ doronbehar ]; platforms   = platforms.linux; }; } </ins>
Code change:
<!-- 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: syncthingtray <!-- 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.1.3 desired version: 1.1.20 <!-- 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.
There's a new dependency now needed for syncthingtray - but there's a problem in the logic upstream here: Here's my packaging attempt:

Related discussion:
text: qtfeedback = callPackage ../development/libraries/qtfeedback { }; <ins> qtforkawesome = callPackage ../development/libraries/qtforkawesome { }; </ins> qtutilities = callPackage ../development/libraries/qtutilities { }; qtinstaller = callPackage ../development/libraries/qtinstaller { };
Code change:
The file generated for nixos is not compatible with the R programming language's interpreter (). On startup, the R interpreter prints the following warning (though it does continue as normal after printing the warning): This could be resolved by adding a trailing newline to . Steps to reproduce the behavior: the R interpreter by running , or if you don't have R installed. No error message should be printed. I'm not entirely sure whether this should be resolved adding the trailing newline to , or whether R should be modified so it doesn't assume a trailing newline. The man page for describes the format of the file as "a newline-separated list of environment-like shell-compatible variable assignments". The existing format (no trailing newline) is indeed newline-separated and shell-compatible (bash and zsh both have no problems with it), so maybe I should bring this up with the R folks instead? On the other hand, all the other distros I've checked (ubuntu, archlinux, and alpine) include a trailing newline, so maybe we should just stick to what they're doing? The fix is trivial: Let me know what you think, and I'd be happy to open a PR wherever we decide the fix should be made. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
This! It shouldn’t be needed and yet here we are. No harm in doing so that though, so I’m all for this. Sounds great!

Related discussion:
text: attrsToText = attrs: concatStringsSep "n" ( mapAttrsToList (n: v: ''${n}=${escapeIfNeccessary (toString v)}'') attrs <del> ); </del> <ins> ) + "n"; </ins> osReleaseContents = { NAME = "NixOS";