jiebi/CodeConvo huggingface dataset:
Code change:
Describe the bug The Airsonic service fails to start. To Reproduce Steps to reproduce the behavior: = true; to your config. reveals the following error: Cannot load configuration class: which causes the application to enter a restart loop. <details<summaryError trace</summary<p</p</detailsExpected behavior It doesn't error, and instead runs successfully. Additional context It doesn't seem to be due to an Airsonic update that this started to fail, so my guess is that something got changed with the JRE. I think Airsonic will only work with JDK 8 (see: ), but I'm not very familiar with how Java works, so I'm not sure. Notify maintainers Metadata Fails on both of the following systems: Maintainer information:

Related discussion:
text: <del> { lib, stdenv, fetchurl }: </del> <ins> { lib, stdenv, fetchurl, nixosTests }: </ins> stdenv.mkDerivation rec { pname = "airsonic";
Code change:
Describe the bug The Airsonic service fails to start. To Reproduce Steps to reproduce the behavior: = true; to your config. reveals the following error: Cannot load configuration class: which causes the application to enter a restart loop. <details<summaryError trace</summary<p</p</detailsExpected behavior It doesn't error, and instead runs successfully. Additional context It doesn't seem to be due to an Airsonic update that this started to fail, so my guess is that something got changed with the JRE. I think Airsonic will only work with JDK 8 (see: ), but I'm not very familiar with how Java works, so I'm not sure. Notify maintainers Metadata Fails on both of the following systems: Maintainer information:

Related discussion:
text: cp "$src" "$out/webapps/airsonic.war" ''; <ins> passthru.tests = { airsonic-starts = nixosTests.airsonic; }; </ins> meta = with lib; { description = "Personal media streamer"; homepage = "https://airsonic.github.io";
Code change:
Describe the bug Unbound allows the "include" directive to appear more than once. : However the type definition of is too strict. This code raises an error: Notify maintainers Metadata Maintainer information:
Could you provide me with the value you set the option to?
An example has been provided above. Simply set to a list of string. The service will fail, but it should work. You can try
Ah yes indeed, sorry I didn't see that. I'll open a PR that fixes this.

Related discussion:
text: freeformType = let validSettingsPrimitiveTypes = oneOf [ int str bool float ]; validSettingsTypes = oneOf [ validSettingsPrimitiveTypes (listOf validSettingsPrimitiveTypes) ]; <del> settingsType = (attrsOf validSettingsTypes); in attrsOf (oneOf [ string settingsType (listOf settingsType) ]) </del> <ins> settingsType = oneOf [ str (attrsOf validSettingsTypes) ]; in attrsOf (oneOf [ settingsType (listOf settingsType) ]) </ins> // { description = '' unbound.conf configuration type. The format consist of an attribute set of settings. Each settings can be either one value, a list of
Code change:
Project description Add Youtube Music Desktop player Metadata homepage URL: source URL: license: Creative Commons Zero v1.0 Universal platforms: linux, MacOS Similar application to Google Play Music Desktop:

Related discussion:
text: githubId = 6652840; name = "Jade"; }; <ins> lgcl = { email = "dev@lgcl.de"; name = "Leon Vack"; github = "LogicalOverflow"; githubId = 5919957; }; </ins> lheckemann = { email = "git@sphalerite.org"; github = "lheckemann";
Code change:
Project description Add Youtube Music Desktop player Metadata homepage URL: source URL: license: Creative Commons Zero v1.0 Universal platforms: linux, MacOS Similar application to Google Play Music Desktop:

Related discussion:
text: <ins> { lib, fetchurl, appimageTools, }: let pname = "ytmdesktop"; version = "1.13.0"; name = "${pname}-${version}"; src = fetchurl { url = "https://github.com/ytmdesktop/ytmdesktop/releases/download/v${version}/YouTube-Music-Desktop-App-${version}.AppImage"; sha256 = "0f5l7hra3m3q9zd0ngc9dj4mh1lk0rgicvh9idpd27wr808vy28v"; }; appimageContents = appimageTools.extract { inherit name src; }; in appimageTools.wrapType2 rec { inherit name src; extraInstallCommands = '' mv $out/bin/{${name},${pname}} install -m 444  -D ${appimageContents}/youtube-music-desktop-app.desktop  -t $out/share/applications substituteInPlace  $out/share/applications/youtube-music-desktop-app.desktop  --replace 'Exec=AppRun' 'Exec=${pname}' cp -r ${appimageContents}/usr/share/icons $out/share ''; meta = with lib; { description = "A Desktop App for YouTube Music"; homepage = "https://ytmdesktop.app/"; license = licenses.cc0; platforms = platforms.linux; maintainers = [ maintainers.lgcl ]; }; } </ins>
Code change:
Project description Add Youtube Music Desktop player Metadata homepage URL: source URL: license: Creative Commons Zero v1.0 Universal platforms: linux, MacOS Similar application to Google Play Music Desktop:

Related discussion:
text: ytcc = callPackage ../tools/networking/ytcc { }; <ins> ytmdesktop = callPackage ../applications/audio/ytmdesktop { }; </ins> zam-plugins = callPackage ../applications/audio/zam-plugins { }; zanshin = libsForQt5.callPackage ../applications/office/zanshin {
Code change:
On NixOS 20.09, steps to reproduce the behavior: setting up wireguard, change to another port still shows the old port:
This seems to be fixed by my PR

Related discussion:
text: </listitem> <listitem> <para> <ins> The WireGuard module gained a new option <option>networking.wireguard.interfaces.&lt;name&gt;.peers.*.dynamicEndpointRefreshSeconds</option> that implements refreshing the IP of DNS-based endpoints periodically (which WireGuard itself <link xlink:href="https://lists.zx2c4.com/pipermail/wireguard/2017-November/002028.html">cannot do</link>). </para> </listitem> <listitem> <para> </ins> MariaDB has been updated to 10.5. Before you upgrade, it would be best to take a backup of your database and read <link xlink:href="https://mariadb.com/kb/en/upgrading-from-mariadb-104-to-mariadb-105/#incompatible-changes-between-104-and-105">
Code change:
On NixOS 20.09, steps to reproduce the behavior: setting up wireguard, change to another port still shows the old port:
This seems to be fixed by my PR

Related discussion:
text: example = "demo.wireguard.io:12913"; type = with types; nullOr str; description = ''Endpoint IP or hostname of the peer, followed by a colon, <del> and then a port number of the peer.''; </del> <ins> and then a port number of the peer. Warning for endpoints with changing IPs: The WireGuard kernel side cannot perform DNS resolution. Thus DNS resolution is done once by the <literal>wg</literal> userspace utility, when setting up WireGuard. Consequently, if the IP address behind the name changes, WireGuard will not notice. This is especially common for dynamic-DNS setups, but also applies to any other DNS-based setup. If you do not use IP endpoints, you likely want to set <option>networking.wireguard.dynamicEndpointRefreshSeconds</option> to refresh the IPs periodically. ''; }; dynamicEndpointRefreshSeconds = mkOption { default = 0; example = 5; type = with types; int; description = '' Periodically re-execute the <literal>wg</literal> utility every this many seconds in order to let WireGuard notice DNS / hostname changes. Setting this to <literal>0</literal> disables periodic reexecution. ''; </ins> }; persistentKeepalive = mkOption {
Code change:
On NixOS 20.09, steps to reproduce the behavior: setting up wireguard, change to another port still shows the old port:
This seems to be fixed by my PR

Related discussion:
text: ''; }; <del> generatePeerUnit = { interfaceName, interfaceCfg, peer }: </del> <ins> peerUnitServiceName = interfaceName: publicKey: dynamicRefreshEnabled: </ins> let keyToUnitName = replaceChars [ "/" "-"    " "     "+"     "="      ] [ "-" "x2d" "x20" "x2b" "x3d" ]; <del> unitName = keyToUnitName peer.publicKey; </del> <ins> unitName = keyToUnitName publicKey; refreshSuffix = optionalString dynamicRefreshEnabled "-refresh"; in "wireguard-${interfaceName}-peer-${unitName}${refreshSuffix}"; generatePeerUnit = { interfaceName, interfaceCfg, peer }: let </ins> psk = if peer.presharedKey != null then pkgs.writeText "wg-psk" peer.presharedKey
Code change:
On NixOS 20.09, steps to reproduce the behavior: setting up wireguard, change to another port still shows the old port:
This seems to be fixed by my PR

Related discussion:
text: dst = interfaceCfg.interfaceNamespace; ip = nsWrap "ip" src dst; wg = nsWrap "wg" src dst; <del> in nameValuePair "wireguard-${interfaceName}-peer-${unitName}" </del> <ins> dynamicRefreshEnabled = peer.dynamicEndpointRefreshSeconds != 0; # We generate a different name (a `-refresh` suffix) when `dynamicEndpointRefreshSeconds` # to avoid that the same service switches `Type` (`oneshot` vs `simple`), # with the intent to make scripting more obvious. serviceName = peerUnitServiceName interfaceName peer.publicKey dynamicRefreshEnabled; in nameValuePair serviceName </ins> { description = "WireGuard Peer - ${interfaceName} - ${peer.publicKey}"; requires = [ "wireguard-${interfaceName}.service" ];
Code change:
On NixOS 20.09, steps to reproduce the behavior: setting up wireguard, change to another port still shows the old port:
This seems to be fixed by my PR

Related discussion:
text: environment.WG_ENDPOINT_RESOLUTION_RETRIES = "infinity"; path = with pkgs; [ iproute2 wireguard-tools ]; <del> serviceConfig = { Type = "oneshot"; RemainAfterExit = true; }; </del> <ins> serviceConfig = if !dynamicRefreshEnabled then { Type = "oneshot"; RemainAfterExit = true; } else { Type = "simple"; # re-executes 'wg' indefinitely # Note that `Type = "oneshot"` services with `RemainAfterExit = true` # cannot be used with systemd timers (see `man systemd.timer`), # which is why `simple` with a loop is the best choice here. # It also makes starting and stopping easiest. }; </ins> script = let <del> wg_setup = "${wg} set ${interfaceName} peer ${peer.publicKey}" + optionalString (psk != null) " preshared-key ${psk}" + optionalString (peer.endpoint != null) " endpoint ${peer.endpoint}" + optionalString (peer.persistentKeepalive != null) " persistent-keepalive ${toString peer.persistentKeepalive}" + optionalString (peer.allowedIPs != []) " allowed-ips ${concatStringsSep "," peer.allowedIPs}"; </del> <ins> wg_setup = concatStringsSep " " ( [ ''${wg} set ${interfaceName} peer "${peer.publicKey}"'' ] ++ optional (psk != null) ''preshared-key "${psk}"'' ++ optional (peer.endpoint != null) ''endpoint "${peer.endpoint}"'' ++ optional (peer.persistentKeepalive != null) ''persistent-keepalive "${toString peer.persistentKeepalive}"'' ++ optional (peer.allowedIPs != []) ''allowed-ips "${concatStringsSep "," peer.allowedIPs}"'' ); </ins> route_setup = optionalString interfaceCfg.allowedIPsAsRoutes (concatMapStringsSep "n" (allowedIP: <del> "${ip} route replace ${allowedIP} dev ${interfaceName} table ${interfaceCfg.table}" </del> <ins> ''${ip} route replace "${allowedIP}" dev "${interfaceName}" table "${interfaceCfg.table}"'' </ins> ) peer.allowedIPs); in '' ${wg_setup} ${route_setup} <ins> ${optionalString (peer.dynamicEndpointRefreshSeconds != 0) '' # Re-execute 'wg' periodically to notice DNS / hostname changes. # Note this will not time out on transient DNS failures such as DNS names # because we have set 'WG_ENDPOINT_RESOLUTION_RETRIES=infinity'. # Also note that 'wg' limits its maximum retry delay to 20 seconds as of writing. while ${wg_setup}; do sleep "${toString peer.dynamicEndpointRefreshSeconds}"; done ''} </ins> ''; postStop = let route_destroy = optionalString interfaceCfg.allowedIPsAsRoutes (concatMapStringsSep "n" (allowedIP: <del> "${ip} route delete ${allowedIP} dev ${interfaceName} table ${interfaceCfg.table}" </del> <ins> ''${ip} route delete "${allowedIP}" dev "${interfaceName}" table "${interfaceCfg.table}"'' </ins> ) peer.allowedIPs); in '' <del> ${wg} set ${interfaceName} peer ${peer.publicKey} remove </del> <ins> ${wg} set "${interfaceName}" peer "${peer.publicKey}" remove </ins> ${route_destroy} ''; };
Code change:
On NixOS 20.09, steps to reproduce the behavior: setting up wireguard, change to another port still shows the old port:
This seems to be fixed by my PR

Related discussion:
text: ${values.preSetup} <del> ${ipPreMove} link add dev ${name} type wireguard ${optionalString (values.interfaceNamespace != null && values.interfaceNamespace != values.socketNamespace) "${ipPreMove} link set ${name} netns ${ns}"} </del> <ins> ${ipPreMove} link add dev "${name}" type wireguard ${optionalString (values.interfaceNamespace != null && values.interfaceNamespace != values.socketNamespace) ''${ipPreMove} link set "${name}" netns "${ns}"''} </ins> ${concatMapStringsSep "n" (ip: <del> "${ipPostMove} address add ${ip} dev ${name}" </del> <ins> ''${ipPostMove} address add "${ip}" dev "${name}"'' </ins> ) values.ips} <del> ${wg} set ${name} private-key ${privKey} ${ optionalString (values.listenPort != null) " listen-port ${toString values.listenPort}"} </del> <ins> ${concatStringsSep " " ( [ ''${wg} set "${name}" private-key "${privKey}"'' ] ++ optional (values.listenPort != null) ''listen-port "${toString values.listenPort}"'' )} </ins> <del> ${ipPostMove} link set up dev ${name} </del> <ins> ${ipPostMove} link set up dev "${name}" </ins> ${values.postSetup} ''; postStop = '' <del> ${ipPostMove} link del dev ${name} </del> <ins> ${ipPostMove} link del dev "${name}" </ins> ${values.postShutdown} ''; };
Code change:
On NixOS 20.09, steps to reproduce the behavior: setting up wireguard, change to another port still shows the old port:
This seems to be fixed by my PR

Related discussion:
text: nsList = filter (ns: ns != null) [ src dst ]; ns = last nsList; in <del> if (length nsList > 0 && ns != "init") then "ip netns exec ${ns} ${cmd}" else cmd; </del> <ins> if (length nsList > 0 && ns != "init") then ''ip netns exec "${ns}" "${cmd}"'' else cmd; </ins> in {
Code change:
Describe the bug VAAPI records repeated frames (see upstream bug report). upstream fix: To Reproduce Steps to reproduce the behavior: ... open OBS ... try recording using VAAPI (possible AMD hardware required?) ... watch replay Expected behavior full FPS. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Maintainer information:
As for 21.0, the fix contained in upstream release = 21.0.2 so e.g. PR
Sadly a look at that thread, it's blocked because something broke, and they're not pushing it to 21.05, so this bug is going to exist until someone figures this out the regression, this patch is only one line of code, maybe it can be supplied as a patch until they get 21.0.3 working? Is there a way to build a patched mesa without rebuilding my entire desktop stack? It's currently stupidly slow on my computer when doing a packageOverride.
This will not be the only bug people will have to deal with on 21.05 unless we backport a more recent mesa (=21.1). Alternative we could also start to includes as well. Without it, this will lead to crashes in wine (incl. steam proton) when on some hardware ( for reference). While one can set as a workaround, it is hardly ideal and difficult to diagnose from within steam alone. Would it be possible to backport the mesa update currently in staging-next () once it is merged?
I don't know... this is hard. Maybe after a version has been a couple weeks in , we might be sufficiently confident that it won't make things worse overall.
I'm okay with backporting it, but probably as its own job set, just to get a better idea of regressions.
I'm not afraid of build-time regressions in this case. Those would be easy (to find). And mesa isn't such a big rebuild now anyway.
If it's been on unstable for a while, I guess I'm okay with it as well
I guess we can close this now, I haven't noticed any problems recently.

Related discussion:
text: let # Release calendar: https://www.mesa3d.org/release-calendar.html # Release frequency: https://www.mesa3d.org/releasing.html#schedule <del> version = "21.0.1"; </del> <ins> version = "21.0.3"; </ins> branch  = versions.major version; self = stdenv.mkDerivation {
Code change:
Describe the bug VAAPI records repeated frames (see upstream bug report). upstream fix: To Reproduce Steps to reproduce the behavior: ... open OBS ... try recording using VAAPI (possible AMD hardware required?) ... watch replay Expected behavior full FPS. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Maintainer information:
As for 21.0, the fix contained in upstream release = 21.0.2 so e.g. PR
Sadly a look at that thread, it's blocked because something broke, and they're not pushing it to 21.05, so this bug is going to exist until someone figures this out the regression, this patch is only one line of code, maybe it can be supplied as a patch until they get 21.0.3 working? Is there a way to build a patched mesa without rebuilding my entire desktop stack? It's currently stupidly slow on my computer when doing a packageOverride.
This will not be the only bug people will have to deal with on 21.05 unless we backport a more recent mesa (=21.1). Alternative we could also start to includes as well. Without it, this will lead to crashes in wine (incl. steam proton) when on some hardware ( for reference). While one can set as a workaround, it is hardly ideal and difficult to diagnose from within steam alone. Would it be possible to backport the mesa update currently in staging-next () once it is merged?
I don't know... this is hard. Maybe after a version has been a couple weeks in , we might be sufficiently confident that it won't make things worse overall.
I'm okay with backporting it, but probably as its own job set, just to get a better idea of regressions.
I'm not afraid of build-time regressions in this case. Those would be easy (to find). And mesa isn't such a big rebuild now anyway.
If it's been on unstable for a while, I guess I'm okay with it as well
I guess we can close this now, I haven't noticed any problems recently.

Related discussion:
text: "ftp://ftp.freedesktop.org/pub/mesa/${version}/mesa-${version}.tar.xz" "ftp://ftp.freedesktop.org/pub/mesa/older-versions/${branch}.x/${version}/mesa-${version}.tar.xz" ]; <del> sha256 = "1fqj2xhhd1ary0pfg31jq6fqcnd6qgyrw1445nmz554k8n2ck7rp"; </del> <ins> sha256 = "0awiyvicvcn3b18x0vx5ik3ly0k3k51ivz2ljj8pnx6ms95nyp2n"; </ins> }; prePatch = "patchShebangs .";
Code change:
Describe the bug VAAPI records repeated frames (see upstream bug report). upstream fix: To Reproduce Steps to reproduce the behavior: ... open OBS ... try recording using VAAPI (possible AMD hardware required?) ... watch replay Expected behavior full FPS. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Maintainer information:
As for 21.0, the fix contained in upstream release = 21.0.2 so e.g. PR
Sadly a look at that thread, it's blocked because something broke, and they're not pushing it to 21.05, so this bug is going to exist until someone figures this out the regression, this patch is only one line of code, maybe it can be supplied as a patch until they get 21.0.3 working? Is there a way to build a patched mesa without rebuilding my entire desktop stack? It's currently stupidly slow on my computer when doing a packageOverride.
This will not be the only bug people will have to deal with on 21.05 unless we backport a more recent mesa (=21.1). Alternative we could also start to includes as well. Without it, this will lead to crashes in wine (incl. steam proton) when on some hardware ( for reference). While one can set as a workaround, it is hardly ideal and difficult to diagnose from within steam alone. Would it be possible to backport the mesa update currently in staging-next () once it is merged?
I don't know... this is hard. Maybe after a version has been a couple weeks in , we might be sufficiently confident that it won't make things worse overall.
I'm okay with backporting it, but probably as its own job set, just to get a better idea of regressions.
I'm not afraid of build-time regressions in this case. Those would be easy (to find). And mesa isn't such a big rebuild now anyway.
If it's been on unstable for a while, I guess I'm okay with it as well
I guess we can close this now, I haven't noticed any problems recently.

Related discussion:
text: , expat, libdrm, xorg, wayland, wayland-protocols, openssl , llvmPackages, libffi, libomxil-bellagio, libva-minimal , libelf, libvdpau <del> , libglvnd , enableRadv ? true </del> <ins> , libglvnd, libunwind </ins> , galliumDrivers ? ["auto"] , driDrivers ? ["auto"] , vulkanDrivers ? ["auto"]
Code change:
Describe the bug VAAPI records repeated frames (see upstream bug report). upstream fix: To Reproduce Steps to reproduce the behavior: ... open OBS ... try recording using VAAPI (possible AMD hardware required?) ... watch replay Expected behavior full FPS. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Maintainer information:
As for 21.0, the fix contained in upstream release = 21.0.2 so e.g. PR
Sadly a look at that thread, it's blocked because something broke, and they're not pushing it to 21.05, so this bug is going to exist until someone figures this out the regression, this patch is only one line of code, maybe it can be supplied as a patch until they get 21.0.3 working? Is there a way to build a patched mesa without rebuilding my entire desktop stack? It's currently stupidly slow on my computer when doing a packageOverride.
This will not be the only bug people will have to deal with on 21.05 unless we backport a more recent mesa (=21.1). Alternative we could also start to includes as well. Without it, this will lead to crashes in wine (incl. steam proton) when on some hardware ( for reference). While one can set as a workaround, it is hardly ideal and difficult to diagnose from within steam alone. Would it be possible to backport the mesa update currently in staging-next () once it is merged?
I don't know... this is hard. Maybe after a version has been a couple weeks in , we might be sufficiently confident that it won't make things worse overall.
I'm okay with backporting it, but probably as its own job set, just to get a better idea of regressions.
I'm not afraid of build-time regressions in this case. Those would be easy (to find). And mesa isn't such a big rebuild now anyway.
If it's been on unstable for a while, I guess I'm okay with it as well
I guess we can close this now, I haven't noticed any problems recently.

Related discussion:
text: let # Release calendar: https://www.mesa3d.org/release-calendar.html # Release frequency: https://www.mesa3d.org/releasing.html#schedule <del> version = "21.0.1"; </del> <ins> version = "21.1.4"; </ins> branch  = versions.major version; self = stdenv.mkDerivation {