jiebi/CodeConvo huggingface dataset:
Change:
allowlist = config.allowlistedLicenses or config.whitelistedLicenses or []; blocklist = config.blocklistedLicenses or config.blacklistedLicenses or []; <del> onlyLicenses = list: lib.lists.all (license: let l = lib.licenses.${license.shortName or "BROKEN"} or false; in if license == l then true else throw ''‘${showLicense license}’ is not an attribute of lib.licenses'' ) list; </del> areLicenseListsValid = if lib.mutuallyExclusive allowlist blocklist then <del> assert onlyLicenses allowlist; assert onlyLicenses blocklist; true </del> <ins> true </ins> else throw "allowlistedLicenses and blocklistedLicenses are not mutually exclusive.";

Discussion:
Looks like / require referenced licenses to match attribute name of . This is broken for SSPL license and for some packages that have inline license attrset. Steps to reproduce the behavior: (can use also ) in NixOS global configuration. to build configuration. Can build your system unless it references package with license (I guess Mongodb related stuff) and which is referenced in . Can reference licenses in-lined in packages . E.g. (or its direct value) This was found out in attempt to use pre-approved list of "safe" open source licenses by adding in all that are not on the list but present in . But have next definition (notice upper case in ): In order to fully implement pre-approved "allow list" (different from ) it is required to be able to reference licenses that are in package meta but not in . <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --MongoDB maintainers: Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): channels(nikolay): nixpkgs:
Why do we even have this restriction in a first place? I'm not sure what it solves. And is silent about side-effect of using in-place license which is that it is not usable in . Tracing back to when it was introduced led me to . But original code had no such restrictions: (this is roughly what I expected when I tried to use ) Can we remove this restriction? This will allow to use licenses out of (my attempt to patch with overlay was no successful).
do you remember why you this in ?
Oops I missed this question, sorry. I don't remember, but I expect that I the check to make sure that all licenses are maintained in the central registry.
Change:
- The `services.ananicy.extraRules` option now has the type of `listOf attrs` instead of `string`. <ins> - JACK tools (`jack_*` except `jack_control`) have moved from the `jack2` package to `jack-example-tools` </ins> - The `matrix-synapse` package & module have undergone some significant internal changes, for most setups no intervention is needed, though: - The option [`services.matrix-synapse.package`](#opt-services.matrix-synapse.package) is now read-only. For modifying the package, use an overlay which modifies `matrix-synapse-unwrapped` instead. More on that below. - The `enableSystemd` & `enableRedis` arguments have been removed and `matrix-synapse` has been renamed to `matrix-synapse-unwrapped`. Also, several optional dependencies (such as `psycopg2` or `authlib`) have been removed.

Discussion:
jack2 as of 1.9.22 no longer ships with tools or examples, those now live in a separate repo (). it doesn't look like these have been packaged yet, removing a bunch of important utilities with no replacement. (approved the bot update) (merged & tested)
Ah semantic versioning, I knew ye well.
Change:
<ins> diff --git a/libcurl/curl_wrap.cpp b/libcurl/curl_wrap.cpp index 11ac9dd..93edd44 100644 --- a/libcurl/curl_wrap.cpp +++ b/libcurl/curl_wrap.cpp @@ -401,9 +401,10 @@ std::wstring zen::formatCurlStatusCode(CURLcode sc) ZEN_CHECK_CASE_FOR_CONSTANT(CURLE_PROXY); ZEN_CHECK_CASE_FOR_CONSTANT(CURLE_SSL_CLIENTCERT); ZEN_CHECK_CASE_FOR_CONSTANT(CURLE_UNRECOVERABLE_POLL); +            ZEN_CHECK_CASE_FOR_CONSTANT(CURLE_TOO_LARGE); ZEN_CHECK_CASE_FOR_CONSTANT(CURL_LAST); } -    static_assert(CURL_LAST == CURLE_UNRECOVERABLE_POLL + 1); +    static_assert(CURL_LAST == CURLE_TOO_LARGE + 1); return replaceCpy<std::wstring>(L"Curl status %x", L"%x", numberTo<std::wstring>(static_cast<int>(sc))); } </ins>

Discussion:
Steps to reproduce the behavior: freefilesync Just tried to update to current nixos-unstable and got hit with this build error for freefilesync. <!-- 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:
philter = callPackage ../tools/networking/philter { }; phoc = callPackage ../applications/misc/phoc { <del> wlroots = wlroots_0_12; </del> <ins> wlroots = wlroots_0_14; </ins> }; phodav = callPackage ../tools/networking/phodav { };

Discussion:
We've temporarily introduced as part of to avoid breaking some reverse dependencies. The affected attributes should switch to when possible (usually a new upstream release). There's no hurry but let's use this issue to track the current progress. : [x] phoc [x] cage (): [x] hikari ( and ): [x] waybox (): [x] wayfire (supported since ): [x] wio (, turns out the pending patches on the ML should fix the build with wlroots 0.13): [x] cagebreak ( and additional commits): () : [x] sway: [x] hikari (downstream patches: ): [x] wio (, send via git-send-email to ):
cage: was just merged, do we want to: until a next release it using the now-merged patch the latest version from master
I think waiting for the next release is the best option for now (we're in no hurry). For some other packages that are already based on commits instead of releases there's no need to wait if the package maintainers deem a newer version stable (in that case I'd leave it up to the package maintainers).
(though I hope that doesn't have the same problems as cage)
(kinda flew under the radar for me, but it happened!)
Don't we want to split this issue up per version? It seems like we're always gonna have a handful of wlroots versions around, would be nice if we could close those issues individually instead of having one perpetually open issue
I thought about that too but I was hoping we can close this before the next wlroots release. is the main blocker, should be fairly easy to drop (I'm waiting for patches and, if necessary, I might be able to patch again but I might also mark it as broken instead (until there's a maintained fork) as I don't intend to do that every release).
I have merely made a new fork for wio outside SourceHut, but me myself do not plan to maintain it alone.
in that case we should eventually drop it from Nixpkgs, at least IMO. I had some time yesterday so I've sent you a patch for wlroots 0.14 (, tested with ).
I have patched it on my particular fork
Phoc 0.11.0 was released targeting wlroots 0.14.0 (), so this can finally be closed.
Change:
stdenv.mkDerivation (rec { pname = "coreutils${optionalString (!minimal) "-full"}"; <del> version = "9.0"; </del> <ins> version = "9.1"; </ins> src = fetchurl { url = "mirror://gnu/coreutils/coreutils-${version}.tar.xz"; <del> sha256 = "sha256-zjCs30pBvFuzDdlV6eqnX6IWtOPesIiJ7TJDPHs7l84="; </del> <ins> sha256 = "sha256:08q4b0w7mwfxbqjs712l6wrwl2ijs7k50kssgbryg9wbsw8g98b1"; </ins> }; <del> patches = [ ./fix-chmod-exit-code.patch # Workaround for https://debbugs.gnu.org/cgi/bugreport.cgi?bug=51433 ./disable-seek-hole.patch # Workaround for https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52330 # This patch can be dropped, once we upgrade to the next coreutils version after 9.0 ./fix-arm64-macos.patch ]; </del> postPatch = '' # The test tends to fail on btrfs,f2fs and maybe other unusual filesystems. sed '2i echo Skipping dd sparse test && exit 77' -i ./tests/dd/sparse.sh

Discussion:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: coreutils <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 9.0 desired version: 9.1 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
I'm already on it :) might take some while before I do the pr because I want to build stdenv first
Change:
<ins> // taken from https://aur.archlinux.org/cgit/aur.git/tree/libuosdevicea.c?h=wechat-universal /* * licensestub - compat layer for libuosdevicea * Copyright (C) 2024 Zephyr Lykos <self@mochaa.ws> * Copyright (C) 2024 Guoxin "7Ji" Pu <pugokushin@gmail.com> * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. * */ #define _GNU_SOURCE #include <string.h> #define declare_string_getter(suffix, constant) void uos_get_##suffix(char *const restrict out) { if (out) strcpy(out, constant); } declare_string_getter(mac,      // MAC address with colon stripped "000000000000") declare_string_getter(hddsninfo, "SN") declare_string_getter(hwserial, // MD5 of hddsninfo "92666505ce75444ee14be2ebc2f10a60") declare_string_getter(mb_sn,    // hardcoded "E50022008800015957007202c59a1a8-3981-2020-0810-204909000000") declare_string_getter(osver, "UnionTech OS Desktop") declare_string_getter(licensetoken, "djEsdjEsMSwyLDk5QUFFN0FBQVdRQjk5OFhKS0FIU1QyOTQsMTAsOTI2NjY1MDVjZTc1NDQ0ZWUxNGJlMmViYzJmMTBhNjAsQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUE6ZjA3NjAwYzZkNmMyMDkyMDBkMzE5YzU2OThmNTc3MGRlYWY1NjAyZTY5MzUxZTczNjI2NjlhNzIyZTBkNTJiOTNhYzk0MmM3YTNkZTgxNjIxMmUwMDA1NTUwODg4N2NlMDQ4ODMyNTExY2JhNGFiMjdmYzlmZjMyYzFiNTYwNjMwZDI3ZDI2NmE5ZGIxZDQ0N2QxYjNlNTNlNTVlOTY1MmU5YTU4OGY0NWYzMTMwZDE0NDc4MTRhM2FmZjRlZGNmYmNkZjhjMmFiMDc5OWYwNGVmYmQ2NjdiNGYwYzEwNDhkYzExNjYwZWU1NTdlNTdmNzBlNjA1N2I0NThkMDgyOA==") int uos_is_active() { return 0; } </ins>

Discussion:
the package wechat uos is still using OpenSSL 1.1 which is end of life on 2023/09/11, so it is marked as insecure now. not sure if we need to wait for wechat-uos or we can just bump it up in here. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
As far as I know, only from depends on OpenSSL 1.1. Seems like we may replace it with to completely remove dependency. I will try to fix that in the next PR when I have free time.
Would it be offensive if I could submit a patch about it now.
Feel free to do so. I would be happy to review your pr :)
Change:
inherit (cfg) group; }; }) <del> (lib.attrsets.setAttrByPath [ cfg.user "packages" ] [ cfg.package mastodonEnv pkgs.imagemagick ]) </del> <ins> (lib.attrsets.setAttrByPath [ cfg.user "packages" ] [ cfg.package pkgs.imagemagick ]) </ins> ]; users.groups.${cfg.group}.members = lib.optional cfg.configureNginx config.services.nginx.user;

Discussion:
When one installs mastodon via the following minimal config: Then there is no obvious way to run tootctl. or any other login user doesn't have the executable by default, nor can this be enabled in an obvious way. is not a login user, so can't (and shouldn't?) log in as and execute . Steps to reproduce the behavior: mastodon as per minimal config above ... nope. ... nope. ... nope. ... nope. Any of: a setting such that is installed for that user an explanation in the docs what to do as a login user (probably bad idea?) Workaround: CC
I think upstream intends only to be run by the mastodon user. My way for doing that is just running and continuing in that shell. The reason why doesn't work is probably because sudo inherits PATH from the user you are coming from? I'm not sure I understand the concept of a login user enough. How would mastodon become a login user and why would that be a bad idea?
In the mastodon docs, it is described the following way: But is not possible, it gives the error They do recommend (which is what I meant by it shouldn't be a login user), but still they seem to do something different than nixos does. Maybe that's fine, and it would be helpful to document this somewhere, so people don't spend a long time trying to find it out.
This is default for almost all service users because they have no login shell. Use ` This is wrong. Sudo resets all path like variables like PATH and PYTHON PATH. Also inheriting needs to be turned on explicitly and PATH mist always ve inherited explicitly. Other services like nextcloud include a wrapper that sudos to the right user. This should be for mastodon, too.
Sounds like a good solution. Then we could make the command globally available.
That isn't? I would have expected that it is very similar to nextcloud-occ.
No currently it is only available to the mastodon user, so tootctl never gets called as the wrong user.
There is a hack in the nixos nextcloud-occ script that automatically sudoes if called by a different user. This could be adapted to tootctl I think.
Yes, this should be adapted. Changing the mastodon to a login user would not be the correct fix.
Change:
- [appvm](https://github.com/jollheef/appvm), Nix based app VMs. Available as [virtualisation.appvm](options.html#opt-virtualisation.appvm.enable). <ins> - [dragonflydb](https://dragonflydb.io/), a modern replacement for Redis and Memcached. Available as [services.dragonflydb](#opt-services.dragonflydb.enable). </ins> - [infnoise](https://github.com/leetronics/infnoise), a hardware True Random Number Generator dongle. Available as [services.infnoise](options.html#opt-services.infnoise.enable).

Discussion:
Project description Metadata homepage URL: source URL: license: Business Source License 1.1, change to Apache License 2.0 on June 1st 2027 platforms: linux
Can you check out my PR if everything works?
Change:
}; }; <ins> python27 = super.python27.override { static = true; }; </ins> }

Discussion:
So today I tried to build on unstable as described in the . This fails on the dependency . Thanks for your information in that guide! I tried to build according to the guide on and (with slight modifications for compatibility) on they both fail in at this point. Do you have any insights as to how you managed to get it to build? e.g. a nixpkgs commit?
Fix in
Change:
<del> { stdenv, lib, fetchFromGitHub, fetchurl, cmake, makeWrapper, pkgconfig </del> <ins> { stdenv, lib, fetchFromGitHub, fetchurl, substituteAll, cmake, makeWrapper, pkgconfig </ins> , curl, ffmpeg, glib, libjpeg, libselinux, libsepol, mp4v2, libmysqlclient, mysql, pcre, perl, perlPackages , polkit, utillinuxMinimal, x264, zlib , coreutils, procps, psmisc }:

Discussion:
Zoneminder, but it seems there is no code that handles upgrades, while that is provided by upstream and for example the Ubuntu packaging. It seems to be more of a developer preview version on NixOS than something that could be used by end-users in a production environment. I would have a flag like that needs to be set to true before it does something for that reason. I welcome the progress that has been made, but it doesn't appear to be in good enough shape to compete with other solutions. I will open another issue for adding declarative camera support (), because there was another user who also wanted to have that, which should also make this issue smaller.
Looking at zoneminder_1.30.4+dfsg- in debian/TODO.Debian it says: and there is no mention of the in the scripts. Are you sure Ubuntu has support for this? My personal opinion is that automatic upgrades are not such a great thing. While there are provided migrations to upgrade the database, there doesn't seem to be an official way to downgrade. This conflicts with the nature of Nix where we expect seamless version changes in any direction. Having user manually run ensures that they are aware of the upgrade and prepared for consequences.
has recently changed, but I have seen it upgrade automatically and there was at some point some code for doing it automatically. The manual part here only seems to be the ppa configuration. The main point is that the effort required on Ubuntu is less than on NixOS.
Yes, I see that this PPA with an unofficial zoneminder package (from Ubuntu standpoint) does indeed run in its zoneminder.postinst script.
I wasn't aware of this issue until just now, hence the rather late reply. That is correct - so far we have only released a single version in nixpkgs but of course it will come back and bite us. Things can break in unstable - nothing new there and unless we hit security issues, new versions will not be back-ported, so that at least gives us to 19.09 to sort out. What other options (packaged for NixOS) do we have? I personally have very strong reservations about the architectural choices the ZM developers have made, but I am not aware of any real alternative ATM. Declarative camera support is definitely a good idea.

I support for ZM because I needed it and it solves my problem right now (until we need to update of course), but any PR would be very much welcome.
The is already part of the package - we just don't do anything with it and according to the comment in the header: But then of course it does have functionality for dealing with a number of changes. So the short version - someone just has to write (and test) how it behaves when upgraded and ensure this runs. I am realistically not going to work on that right now though.
Change:
''; # We override checkPhase to be able to test ./... while using subPackages <ins> # Temporary fix for https://github.com/superfly/flyctl/issues/3642. We # should go back to buildGoDir instead of go test once that is resolved. </ins> checkPhase = '' runHook preCheck # We do not set trimpath for tests, in case they reference test assets export GOFLAGS=''${GOFLAGS//-trimpath/} <del> buildGoDir test ./... </del> <ins> go test ./... </ins> runHook postCheck '';

Discussion:
Steps to reproduce the behavior: flyctl-0.2.69 Looks like recent bump with failing ofborg was merged and attempted to be backported right away... <!-- 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]:
Copied my response from the backport of the linked PR
This is caused by a weird map merge implementation in the sentry-go SDK used by upstream, that is only hit when the tests are run with . Upstream runs tests without the tag, and we have the tag in our derivation which propagates through to the tests I will include a temporary fix as part of the bump, and file upstream issues for both flyctl and sentry-go
This has been addressed in
Change:
{ callPackage }: builtins.mapAttrs (_: callPackage ./generic.nix) rec { <del> wordpress = wordpress6_1; </del> <ins> wordpress = wordpress6_2; wordpress6_2 = { version = "6.2"; hash = "sha256-FDEo3rZc7SU9yqAplUScSMUWOEVS0e/PsrOPjS9m+QQ="; }; </ins> wordpress6_1 = { version = "6.1.1"; hash = "sha256-IR6FSmm3Pd8cCHNQTH1oIaLYsEP1obVjr0bDJkD7H60=";

Discussion:
Package name: wordpress Latest released version: 6.2 <!-- Search your package here: --- Current version on the unstable channel: 6.1.1 Current version on the stable/release channel: 6.1.1 <!-- 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.
Change:
manpages = man-pages; # added 2015-12-06 mariadb-client = hiPrio mariadb.client; #added 2019.07.28 matcha = throw "matcha was renamed to matcha-gtk-theme"; # added 2020-05-09 <ins> mathics = throw "mathics has been removed from nixpkgs, as it's unmaintained"; # added 2020-08-15 </ins> matrique = spectral; # added 2020-01-27 mbedtls_1_3 = throw "mbedtls_1_3 is end of life, see https://tls.mbed.org/kb/how-to/upgrade-2.0"; # added 2019-12-08 mess = mame; # added 2019-10-30

Discussion:
The mathics test does not work because: /cc (commit history)
I see the same error with on the 20.03 beta channel. I think it also happens on Master. It used to work (maybe a few weeks ago? if I have time I'll bisect).
I removing mathics.
Change:
updateScript = ./update.sh; }; <del> dotnet-sdk = dotnetCorePackages.sdk_7_0; </del> <ins> dotnet-sdk = with dotnetCorePackages; combinePackages [ sdk_7_0 sdk_6_0 ]; </ins> dotnet-runtime = dotnetCorePackages.runtime_7_0; dotnetFlags = [

Discussion:
Some .NET packages depend on SDK-specific nugets, requiring updates when the SDK is updates, as seen in [x] - should be fixed by [x] - SDK-specific nugets should not be included in
Change:
<ins> { lib, buildGoModule, fetchFromGitHub }: buildGoModule rec { pname = "alertmanager-irc-relay"; version = "0.3.0"; src = fetchFromGitHub { owner = "google"; repo = "alertmanager-irc-relay"; rev = "v${version}"; sha256 = "sha256-SmyKk0vSXfHzRxOdbULD2Emju/VjDcXZZ7cgVbZxGIA="; }; vendorSha256 = "sha256-aJVA9MJ9DK/dCo7aSB9OLfgKGN5L6Sw2k2aOR4J2LE4="; buildFlagsArray = [ "-ldflags=-s -w" ]; meta = with lib; { description = "Alertmanager IRC Relay is a bot relaying Prometheus alerts to IRC"; longDescription = '' Alertmanager IRC Relay is a bot relaying Prometheus alerts to IRC. Alerts are received from Prometheus using Webhooks and are relayed to an IRC channel ''; homepage = "https://github.com/google/alertmanager-irc-relay"; license = licenses.asl20; maintainers = with maintainers; [ ymatsiuk ]; }; } </ins>

Discussion:
Project description Send Prometheus Alerts to IRC using Webhooks. Alertmanager IRC Relay is a bot relaying Prometheus alerts to IRC. Alerts are received from Prometheus using Webhooks and are relayed to an IRC channel. Metadata homepage URL: source URL: license: apache2 platforms: any
Change:
]; buildInputs = [ <del> texinfo libXext xorgproto libX11 libXpm libXt libXcursor </del> <ins> texinfo6_5 libXext xorgproto libX11 libXpm libXt libXcursor </ins> alsaLib cmake zlib libpng libvorbis libXxf86dga libXxf86misc libXxf86vm openal libGLU libGL ];

Discussion:
Describe the bug To Reproduce Steps to reproduce the behavior: ~/nixpkgs -build -A lutris <details<summarylog</summary</detailsExpected behavior Screenshots Additional context 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:
thanks !!