jiebi/CodeConvo huggingface dataset:
Change:
jre_headless = jre8_headless; }; <ins> nexusmods-app-unfree = callPackage ../by-name/ne/nexusmods-app/package.nix { enableUnfree = true; }; </ins> nmrpflash = callPackage ../development/embedded/nmrpflash { }; norminette = callPackage ../development/tools/norminette { };

Discussion:
Project description From the : Metadata homepage URL: source URL: license: gpl3 platforms: linux (the says tests run on OSX, but I can't find the build instructions) Priorities Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
<ins> # Generated by update.sh { fetchurl }: { "curl-7.84.0.tar.xz" = fetchurl { url = "https://curl.se/download/curl-7.84.0.tar.xz"; hash = "sha256-LRGLQ/VHv+W66AbY1HtOWW6lslpsHwgK70n7zYF8Xbg="; }; "brotli-1.0.9.tar.gz" = fetchurl { url = "https://github.com/google/brotli/archive/refs/tags/v1.0.9.tar.gz"; hash = "sha256-+ejYHQQFumbRgVKa9CozVPg4yTkJX/mZMNpqqc32/kY="; }; "nss-3.87.tar.gz" = fetchurl { url = "https://ftp.mozilla.org/pub/security/nss/releases/NSS_3_87_RTM/src/nss-3.87-with-nspr-4.35.tar.gz"; hash = "sha256-63DqC1jc5pqkkOnp/s0TKn1kTh2j1jHhYzdqDcwRoCI="; }; "boringssl.zip" = fetchurl { url = "https://github.com/google/boringssl/archive/3a667d10e94186fd503966f5638e134fe9fb4080.zip"; hash = "sha256-HsDIkd1x5IH49fUF07dJaabMIMsQygW+NI7GneULpA8="; }; "nghttp2-1.46.0.tar.bz2" = fetchurl { url = "https://github.com/nghttp2/nghttp2/releases/download/v1.46.0/nghttp2-1.46.0.tar.bz2"; hash = "sha256-moKXjIcAcbdp8n0riBkct3/clFpRwdaFx/YafhP8Ryk="; }; } </ins>

Discussion:
Project description is like curl, but doesn't get you blocked by cloudflare and other WAPs that insist you have the TLS fingerprint of a web browser. Metadata homepage URL: source URL: license: MIT platforms: linux
the build process produces a separate 'Chrome' and 'Firefox' impersonation binary
I started packaging the firefox variant of curl-impersonate in , but it has unresolved issues, including: missing the curl-impersonate wrapper scripts; PATH conflicts with ; disabled tests; missing shell completions; possible issues with getting an HTTP response from some sites including But it does sort of work and may be useful as a starting point. (Note that I have not checked the TLS fingerprint.)
I've opened which should add a fully working build from source of curl-impersonate (with both firefox and chrome variants)
Change:
, rSrc , version , oildev <ins> , configargparse </ins> , binlore , resholve-utils }:

Discussion:
fails with the error message: Steps to reproduce the behavior: install bats <details<summarynix profile install nixpkgs#bats --show-trace</summary</detailsupgrading bats fails with the same error (assuming one had installed it before) n.a. Please run and paste the result.
This will be fixed by
Change:
gtdialog = callPackage ../development/libraries/gtdialog { }; <ins> gtkclipblock = callPackage ../by-name/gt/gtkclipblock/package.nix { stdenv = gcc13Stdenv; }; </ins> gtkd = callPackage ../development/libraries/gtkd { dcompiler = ldc; }; gtkgnutella = callPackage ../tools/networking/p2p/gtk-gnutella { };

Discussion:
Project description Most useful if this can be to 's ld preload, so wayland users on kde who disabled paste with middle click are able to copy links from the search bar. Metadata homepage URL: source URL: license: lgpl3 platforms: unix Priorities Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
if "@timeout@" != "": f.write("timeout @timeout@n") if profile: <del> f.write("default nixos-%s-generation-%dn" % (profile, generation)) </del> <ins> f.write("default nixos-%s-generation-%d.confn".format(profile, generation)) </ins> else: <del> f.write("default nixos-generation-%dn" % (generation)) </del> <ins> f.write("default nixos-generation-%d.confn".format(generation)) </ins> if not @editor@: f.write("editor 0n"); f.write("console-mode @consoleMode@n");

Discussion:
Describe the bug With systemd-boot v245, the set in by is no longer respected. In the current state, it will always choose the boot loader entry with the largest in the loader file. This corresponds to the largest generation number. To Reproduce Steps to reproduce the behavior: , run or to ensure the latest is used. to switch back to a previous generation. and notice that it still defaults to the latest generation, not the previous one. Additional context This is a result of the following change: The fix seems fairly straightforward, to just have include the suffix on the entry in the file. However, we would still have a problem if the user is using an older version of (if he or she hasn't updated with ). Similarly, a user who hasn't updated using since updating to would not encounter this issue, since the is still correct for their version of . Upstream issue: Notify maintainers
Does the following patch fix it for you? If yes, I can send a PR fixing this.
Yes, it does. But my concern is that it would break this for people who hadn't already run .
Yeah, this is definitely a problem - currently, all fresh installations with systemd 245 won't have a working default selection, and if we update with above patch, all existing ones will break. I don't think upstream will revert the change either - it has been in their codebase since November 2019. We could add some code to that compares ${systemd}/lib/systemd/boot/efi/systemd-boot[x64,aa64].efi with what's in and invokes if it differs to always update bootctl - what do you think?
Updating the bootloader seems like a good idea in general. I would not perform the check the file manually but rather parse the output of for now. This would result in less updates (only for systemd version upgrades) and is therefore less risky (at the cost of missing some fixes of without a bump). It also saves us from re-implementing things like finding out where $ESP is and what infix needs to got into path
would you be willing to file a PR doing as suggested?
Unfortunately, I won't be able to work on this in the near future. I'm up against some deadlines for graduation.
all good, thanks for the heads-up! Maybe someone else picks it up in the meantime :-)
Change:
./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 {

Discussion:
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.
Change:
owner = "kanboard"; repo = "kanboard"; rev = "v${version}"; <del> sha256 = "sha256-pLxCm+T9jdn0FFqbTFe1tsIPTaVTT+QDeLHDxrbpGBg="; </del> <ins> sha256 = "sha256-WG2lTPpRG9KQpRdb+cS7CqF4ZDV7JZ8XtNqAI6eVzm0="; </ins> }; dontBuild = true;

Discussion:
Steps to reproduce the behavior: Added 'kanboard' to Then ran My machine: <!-- 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.
Change:
paperless = 315; #mailman = 316;  # removed 2019-08-30 zigbee2mqtt = 317; <ins> shadow = 318; </ins> # When adding a gid, make sure it doesn't match an existing # uid. Users and groups with the same name should have equal

Discussion:
Describe the bug Currently, /etc/shadow belongs to the root group. For many use cases, this poses no problems, but when some program needs to use PAM to authenticate on the behalf of multiple users, the program needs to be executed as root (which seems generally unacceptable security-wise). One example is PAM authentication in Nginx, where the (see discussion on this). Expected behavior I think it's reasonable for /etc/shadow to belong to a group called "shadow" so users can make the decision on letting some programs/users read /etc/shadow. . If maintainers agree this is a reasonable thing to do, and if someone can confirm if this change is as simple as adding a group called shadow and adding a line in update-users- chown-ing /etc/shadow to root:shadow, then I'll create a PR. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I've tackled this in PTAL.
Just as a reminder, the 20.09 release is scheduled to happen this monday, the 28th. If this is still relevant to blocking the release, then there should be some forward movement. A blocker meeting has still yet to be scheduled. But, if you consider this item to still warrant blocking the entirety of the nixos-20.09 release, the please do so on the . A template for proposing an item can be found
As soon as the above PR is merged (), it can be backported to 20.09, and this issue won't be blocking 20.09 anymore.
Change:
platforms = [ "x86_64-linux" ]; maintainers = with maintainers; [ mdaiter orivej ]; }; <del> } </del> <ins> }) </ins>

Discussion:
is only ever built with the default version of because the line which adds the derivation never changes the version of provided: I confirmed this by making this change to the derivation and trying to build it with two different versions of . Notice that the error is the same: <details</detailsIn the pattern seems to be passing . However, it is relatively rare that the derivation takes as an argument. Instead, it seems to be preferred to have the derivation take, as arguments, the actual python packages required. To bring the NCCL derivation in line with this pattern, it should take the CUDA packages it requires as arguments. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
We only expose nccl as . Let's change it to take cudaPackages' individual attributes as arguments, so that works properly. Nccl already uses solely the redist packages, so I guess we needn't worry about cuda10
Agreed -- WIP at Running a now :)
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Well, since gh pushed a notification anyway: that's one long nixpkgs-review:)

As proposed in , should switch to because invoking is manual and can easily cause breakages if files are missed. This is a followup from <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
<del> { stdenv, buildPythonPackage, fetchPypi, pytest, isPy3k }: </del> <ins> { stdenv, buildPythonPackage, fetchPypi, pytest, isPy3k, isPy35, async_generator }: </ins> buildPythonPackage rec { pname = "pytest-asyncio"; version = "0.9.0";

Discussion:
The derivation is available but cannot be built. I get the following error : I get the original package to work in a nix-shell with the following derivation:
I commented in the PR to address this issue. It is due to a circular dependency that and have on each other for testing. You may run into more similar issues since python 35 it not heavily tested in the community right now. If you can use 36 or 37. 37 will be the default soon.
Thanks!
Change:
in stdenv.mkDerivation rec { pname = "graphviz"; <del> version = "8.1.0"; </del> <ins> version = "9.0.0"; </ins> src = fetchFromGitLab { owner = "graphviz"; repo = "graphviz"; rev = version; <del> hash = "sha256-xTdrtwSpizqf5tNRX0Q0w10mEk4S0X7cmxHj3Us14kY="; </del> <ins> hash = "sha256-lLESaULvHkWJjbKjjG9VIcVInqsDmY1OAAKfjCFDThQ="; </ins> }; nativeBuildInputs = [

Discussion:
Package name: graphviz Latest released version: 9.0.0 Current version on the unstable channel: 8.1.0 Current version on the stable/release channel: 7.1.0 Notify maintainers Note for maintainers: Please tag this issue in your PR.
Completed in .
Change:
stdenv.mkDerivation rec { pname = "github-desktop"; <del> version = "3.0.5"; </del> <ins> version = "3.0.6"; </ins> src = fetchurl { url = "https://github.com/shiftkey/desktop/releases/download/release-${version}-linux1/GitHubDesktop-linux-${version}-linux1.deb"; <del> sha256 = "sha256-7Sk2jDNZtOA04hkl/J+Up2yMGT8+FcXGPiUMcHhb7iY="; </del> <ins> hash = "sha256-UQsMT4/D571xgrU8C4HBoRO+qf08GCGerA4Y5gHcjRc="; </ins> }; nativeBuildInputs = [

Discussion:
Steps to reproduce the behavior: githhub-desktop Libs not to the Update of Package:
This issue is addressed by
Change:
<del> diff --git a/builder.go b/builder.go index ed6c5ef..36e8055 100644 --- a/builder.go +++ b/builder.go @@ -200,7 +200,7 @@ func NewReplace(old, new string) Replace { // It is the caller's responsibility to remove the folder when finished. func newTempFolder() (string, error) { var parentDir string -	if runtime.GOOS == "darwin" { +	if false && runtime.GOOS == "darwin" { // After upgrading to macOS High Sierra, Caddy builds mysteriously // started missing the embedded version information that -ldflags // was supposed to produce. But it only happened on macOS after </del>

Discussion:
Caddy fails to build for riscv64 Steps to reproduce the behavior: ... ... ... A clear and concise description of what you expected to happen. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
(please fill out more parts of the bug report template next time) Assuming this is , likely an instance of . Pinging maintainers:
Hi, thanks for the ping :) The fix for this is fairly trivial. Either skip the shell completions/man pages[^1], or use something like But I am upset that you ( didn't even care enough to do the bare minimum and fill out the issue template. [^1]: Technically only the kills the build, not the , because bash pipefail defaults.
i'm sorry for the issue template, it was more of a quick note to myself. i'll do it right next time
Change:
stdenv.mkDerivation rec { pname = "keepassxc"; <del> version = "2.6.6"; </del> <ins> version = "2.7.1"; </ins> src = fetchFromGitHub { owner = "keepassxreboot"; repo = "keepassxc"; rev = version; <del> sha256 = "15rm3avdmc2x2n92zq6w1zbcranak4j6dds2sxmgdqi1ffc0a3ci"; </del> <ins> sha256 = "sha256-BOtehDzlWhhfXj8TOFvFN4f86Hl2EC3rO4qUIl9fqq4="; </ins> }; NIX_CFLAGS_COMPILE = optionalString stdenv.cc.isClang [

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: keepassxc <!-- 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: 2.6.6 desired version: 2.7.0 <!-- 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 PR now:
Thanks for the information
Change:
cssselect keyring lxml <ins> markdown2 matrix-client </ins> minidb <ins> pushbullet </ins> pycodestyle <ins> pyppeteer </ins> pyyaml requests <del> pyppeteer </del> ]; # no tests

Discussion:
Describe the bug Trying to use the matrix notification fails. To Reproduce Steps to reproduce the behavior: a config with matrix enabled urlwatch check a URL. the error Expected behavior Working matrix integration Screenshots Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(dfrank): nixpkgs: Maintainer information:
could you please test ?
I get an error about an invalid token, but I assume that's wrong configuration on my end. Thanks for being so fast!
Change:
, libpthreadstubs , magmaRelease , ninja <ins> , python3 </ins> , config # At least one back-end has to be enabled, # and we can't default to CUDA since it's unfree , rocmSupport ? !cudaSupport , static ? stdenv.hostPlatform.isStatic , stdenv <del> , symlinkJoin </del> }: let inherit (lib) lists strings trivial; <del> inherit (cudaPackages) backendStdenv cudaFlags cudaVersion; </del> <ins> inherit (cudaPackages) cudaAtLeast cudaFlags cudaOlder; </ins> inherit (magmaRelease) version hash supportedGpuTargets; # NOTE: The lists.subtractLists function is perhaps a bit unintuitive. It subtracts the elements

Discussion:
Build of failed on x86_64-linux as of . This is currently breaking . python3Packages.torchvision maintainers cc: magma maintainers cc: Other cc: n/a nixpkgs at commit Contents of : This issue was automatically generated by . that created this issue. Internal tags:
This is also breaking atm
This shows that fortran name mangling is using the underscore ``. (See ) Magma should have the flag "-DADD" set during compilation to fix this
And, in fact, clmagma already sets :
Both of the following overlays fixed the problem: Specify the fortran name mangling convention To explain this, in , we see that if USEFORTRAN=off then the FORTRANCONVENTIONS flag is set and also copied to CFLAGS and CXXFLAGS. FORTRANCONVENTIONS is copied outside of this block into the NVCCFLAGS, and DEVCCFLAGS (which can't otherwise be set), so all three flags are necessary if we use the default of USE_FORTRAN=on. Disable fortran in magma
Nice! Would you be interested in turning that into a PR? It'd be great to fix on master!
Change:
<ins> -----BEGIN CERTIFICATE----- MIIC3jCCAcagAwIBAgIUWW1hb9xdRtxAhA42jkS89goW9LUwDQYJKoZIhvcNAQEL BQAwDzENMAsGA1UEAwwEcmt2bTAeFw0yMzA4MjIxOTI1NDlaFw0zMzA4MTkxOTI1 NDlaMA8xDTALBgNVBAMMBHJrdm0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCuBsh0+LDXN4b2o/PJjzuiZ9Yv9Pz1Oho9WRiXtNIuHTRdBCcht/iu3PGF ICIX+H3dqQOziGSCTAQGJD2p+1ik8d+boJbpa0oxXuHuomsMAT3mib3GpipQoBLP KaEbWEsvQbr3RMx8WOtG4dmRQFzSVVtmAXyM0pNyisd4eUCplyIl9gsRJIvsO/0M OkgOZW9XLfKiAWlZoyXEkBmPAshg3EkwQtmwxPA/NgWbAOW3zJKSChxnnGYiuIIu R/wJ8OQXHP6boQLQGUhCWBKa1uK1gEBmV3Pj6uK8RzTkQq6/47F5sPa6VfqQYdyl TCs9bSqHXZjqMBoiSp22uH6+Lh9RAgMBAAGjMjAwMA8GA1UdEQQIMAaHBAoAAAEw HQYDVR0OBBYEFEh9HEsnY3dfNKVyPWDbwfR0qHopMA0GCSqGSIb3DQEBCwUAA4IB AQB/r+K20JqegUZ/kepPxIU95YY81aUUoxvLbu4EAgh8o46Fgm75qrTZPg4TaIZa wtVejekrF+p3QVf0ErUblh/iCjTZPSzCmKHZt8cc9OwTH7bt3bx7heknzLDyIa5z szAL+6241UggQ5n5NUGn5+xZHA7TMe47xAZPaRMlCQ/tp5pWFjH6WSSQSP5t4Ag9 ObhY+uudFjmWi3QIBTr3iIscbWx7tD8cjus7PzM7+kszSDRV04xb6Ox8JzW9MKIN GwgwVgs3zCuyqBmTGnR1og3aMk6VtlyZUYE78uuc+fMBxqoBZ0mykeOp0Tbzgtf7 gPkYcQ6vonoQhuTXYj/NrY+b -----END CERTIFICATE----- </ins>

Discussion:
Project description It's like synergy or barrier, but supports wayland and windows as well. I started packaging it , but it doesn't build yet ( fails to find the evdev files it wants). Metadata homepage URL: source URL: license: mit platforms: linux
here's the build log so far:
well, this is probably the issue: I'll file an issue.
If this is the only issue you can probably patch it like this: And during phrase you can use or to substitute with . Should work.
Good idea. Another weird one popped out though: Not sure what's up, since libevdev does not seem to actually come with that header file included... and from what I can tell ubuntu's libevdev-dev packages don't either??
Weird, debian's libevdev-dev pkg:
Looks like I misunderstood. I think they bundle their input.h for building their lib, but expect to be providing , so I'm adding that to the clang_args too...
Okay, update: error:
I marked this as stale due to inactivity. &rarr;
build: please see:
What's the status on this, doesn't look like it's made it into the binary cache yet. Is it a 23.11 addition?
the PR is still being reviewed:
Change:
<del> { config, lib, pkgs, ... }: </del> <ins> { config, lib, pkgs, utils, ... }: </ins> with lib; let cfg = config.services.xserver.desktopManager.xfce; <ins> excludePackages = config.environment.xfce.excludePackages; </ins> in {

Discussion:
Describe the bug lacks an option to exclude some packages. Expected behavior xfce service should provide an option like in GNOME3 service. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
I marked this as stale due to inactivity. &rarr;