jiebi/CodeConvo huggingface dataset:
Change:
} ); <ins> cheroot = super.cheroot.overridePythonAttrs ( old: { dontPreferSetupPy = true; } ); </ins> colour = super.colour.overridePythonAttrs ( old: { buildInputs = (old.buildInputs or [ ]) ++ [ self.d2to1 ];

Discussion:
"Source" link in search result on for Poetry package is pointing to poetry2nix source code instead of poetry. Steps to reproduce the behavior: on "Source" link in "poetry" package. This will point you to instead of When clicking on "Source" link in "poetry" package search results I want to get to "poetry" source code 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. Maintainer information:
This is really a bigger issue in how source code locations are extracted and it isn't unique to Poetry/Poetry2nix. The root cause is related to how is extracted: In this case is resolved to where Poetry2nix inherits descriptions from /. You can explicitly pass to which I just implemented in :
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
nativeBuildInputs = [ extra-cmake-modules kdoctools ]; buildInputs = [ boost fontconfig ibus libcanberra_kde libpulseaudio libXcursor libXft xorgserver <del> libxkbfile phonon xf86inputevdev xf86inputsynaptics xinput xkeyboard_config </del> <ins> libxkbfile phonon xf86inputlibinput xf86inputevdev xf86inputsynaptics xinput xkeyboard_config </ins> accounts-qt qtdeclarative qtquickcontrols qtquickcontrols2 qtsvg qtx11extras

Discussion:
My mouse behavior has reverted to the defaults. The KCM for mouse settings is gone. Build the current version of KDE in the unstable-small channel. Existence of the mouse KCM is System Settings, ability to configure my mouse. During the offending update, I have also configured installation of Steam. <!-- --Please run and paste the result. Maintainer information:
I just updated nixos-unstable and I also am experiencing the same problem Edit: for anyone interested, I use the mouse settings primarily to switch the my primary and secondary mouse buttons. As a temporary fix, I used to swap the buttons using the following steps 1) Run to find your device id. 2) Run to observe the buttons you would like to swap. In my case (i dont know if this is true in general), it was buttons 3 and 1. 3) Run (I'm also not sure if numbers after the third are necessary)
Ping
Same issue with nixos-unstable, the mouse KCM is missing. system: host os: multi-user?: sandbox: version: channels(root): channels(bill): nixpkgs:
Bisecting to find the commit that caused it is likely a good idea if you want this to be fixed.
Does NixOS have an archive of derivations?
Hi, I dont know if this is what youre talking about, but there is a history of channels at
I just ran a bisect. The issue first appears in around when upgrading KDE-related packages. The first commit in that range make the default KDE environment failed to build. When it build again in , the issue already exists.
I can't see anything that stands out, maybe it's a bug caused by an upstream change?
No. I tested Arch Linux with archive on 2021-08-05, which contains the same version of and . It has no issue about Mouse Setting. I believe it's a packaging issue on our side.
arch package has but we dont
plasma-desktop at has it build logs for nixos-unstable and at search
i've made a pr in which there's a so the issue should be fixed
Change:
<ins> module github.com/namecoin/x509-compressed go 1.22.4 require golang.org/x/crypto v0.25.0 </ins>

Discussion:
Steps to reproduce the behavior: ncdns.goModules with or 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]:
The goModules derivation can't be built since go 1.17, see I don't think I can fix it.
Change:
sha256 = "sha256-JwPeSNUc++z6RfMe0qAuXdekzLWR/MCmsT+Ykvp9a/s="; }; <del> nativeBuildInputs = [ autoreconfHook pkg-config ]; buildInputs = [ dav1d rav1e libde265 x265 libpng libjpeg libaom ]; </del> <ins> nativeBuildInputs = [ autoreconfHook pkg-config ]; buildInputs = [ dav1d rav1e libde265 x265 libpng libjpeg libaom gdk-pixbuf ]; </ins> enableParallelBuilding = true; <ins> # Fix installation path for gdk-pixbuf module PKG_CONFIG_GDK_PIXBUF_2_0_GDK_PIXBUF_MODULEDIR = "${placeholder "out"}/${gdk-pixbuf.moduleDir}"; </ins> passthru.tests = { inherit gimp imagemagick imlib2Full imv vips; };

Discussion:
This is required for HEIF/HEIC support in eog work. Modules are trying to install to gdk-pixbuf prefix, (we are patching it in ) where it works. (That can be fixed using the pkg-config env var.) But the file is not generated/installed so the setup hook cannot pick it up. Originally posted by in
I marked this as stale due to inactivity. &rarr;
Does not look stale to me.
I marked this as stale due to inactivity. &rarr;
Still important to me.
I marked this as stale due to inactivity. &rarr;
will make this possible.
Change:
<ins> { stdenv, fetchFromGitHub, autoreconfHook, libtool, pkgconfig, zlib, serd }: stdenv.mkDerivation rec { pname = "hdt"; version = "1.3.3"; src = fetchFromGitHub { owner = "rdfhdt"; repo = "hdt-cpp"; rev = "v${version}"; sha256 = "1vsq80jnix6cy78ayag7v8ajyw7h8dqyad1q6xkf2hzz3skvr34z"; }; buildInputs = [ zlib serd ]; nativeBuildInputs = [ autoreconfHook libtool pkgconfig ]; enableParallelBuilding = true; meta = with stdenv.lib; { homepage = "http://www.rdfhdt.org/"; description = "Header Dictionary Triples (HDT) is a compression format for RDF data that can also be queried for Triple Patterns."; license = licenses.lgpl21; platforms = platforms.linux; maintainers = [ maintainers.koslambrou ]; }; } </ins>

Discussion:
Project description C++ implementation of the HDT compression format Metadata homepage URL: source URL: license: lgpl3 platforms: linux
Pull request awaiting to be merged:
Change:
patches = [ ./compiler-rt-codesign.patch # Revert compiler-rt commit that makes codesign mandatory <del> ];# ++ stdenv.lib.optional stdenv.hostPlatform.isMusl ./sanitizers-nongnu.patch </del> <ins> ]# ++ stdenv.lib.optional stdenv.hostPlatform.isMusl ./sanitizers-nongnu.patch ++ stdenv.lib.optional stdenv.hostPlatform.isAarch32 ./compiler-rt-armv7l.patch; </ins> # TSAN requires XPC on Darwin, which we have no public/free source files for. We can depend on the Apple frameworks # to get it, but they're unfree. Since LLVM is rather central to the stdenv, we patch out TSAN support so that Hydra

Discussion:
Describe the bug A clear and concise description of what the bug is. Same issue as or , but on armv7l Additional context Add any other context about the problem here. On hydra, the clang build first started failing with this error after going from to . I diffed the range and found to be the most likely culprit. It enabled some cmakeFlags globally which used to only be enabled on darwin and useLLVM systems. I don't know what exactly these do but, I was able to build on my rpi2 by disabling them on aarch32: Since I have no idea why this works and what would be affected, I'd rather have someone look over this. 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 Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
we probably need to add armv7l here:
I tried but it fails with this error now: I guess it can't find a default target for armv7l somehow? Not really familiar with cmake unfortunately
I made some progress, it seems to be taking the target arch from the triplet given to , even if you override the target arch with a flag. Printf debugging showed me that it does this halfway through the configure phase, it's armhf in the beginning if I set the flag. Setting the compiler target to instead of makes it find its target and compile successfully. Does have any importance outside the build process?
I don't think it does. It's possible it sets in compiler calls, but that is considered equivalent to .
Change:
stdenv.mkDerivation rec { pname = "bluejeans"; <del> version = "2.23.0.39"; </del> <ins> version = "2.24.0.89"; </ins> src = fetchurl { url = "https://swdl.bluejeans.com/desktop-app/linux/${getFirst 3 version}/BlueJeans_${version}.rpm"; <del> sha256 = "sha256-LGg14KJ/hEnSaSrdTltY9YXv7Nekkfo66uLkxjMx8AI="; </del> <ins> sha256 = "sha256-rneX8ys/oKfVLavAZk5RJouOZkVsp+9BIAReSeYiKJc="; </ins> }; nativeBuildInputs = [ rpmextract makeWrapper ];

Discussion:
I would like to do this myself, but I'm getting some errors. I fixed the version fetching in , but now I am a bit stuck: No change to the actual package file is seen. I was able to work out that those errors are coming from inside but that's as far as I got. <!-- 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 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: bluejeans-gui <!-- The current version can be found easily with the same process than 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.23.0.39 desired version: 2.24.0.89 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: (tagging because just merged my bluejeans version fetch PR ()) and (tagging because seems to have committed to the package recently) Please tag this issue in your PR.
this is why it fails:
something like this will work:
Oh! I thought the I saw when checking was from something else. Thanks.
Thanks for picking this up!
First step:
looks like my work paid off and the bots are taking it the rest of the way
Change:
inherit (protobuf) name src; inherit disabled doCheck; <ins> # work around python distutils compiling C++ with $CC NIX_CFLAGS_COMPILE = stdenv.lib.optionalString stdenv.isDarwin "-I${libcxx}/include/c++/v1"; </ins> propagatedBuildInputs = [ protobuf google_apputils ]; buildInputs = [ google_apputils pyext ];

Discussion:
Building the python 3 protobuf package fails for me on macOS. Digging in (by launching ), the cause seems to be that calls instead of . The call above fails, but the same call works after replacing by . Similarly, works fine. That in turn matters because of in the / wrappers, because the system include path is missing in the case. System: mac OS 10.12.5 Nix version: nix-env (Nix) 1.11.8 Nixpkgs version: "17.09pre108299." Sandboxing enabled: grep: No such file or directory :) When digging in, I used a checkout of nixpkgs with hash , but it seems to make no difference.
seems related.
uses Python on Darwin and might help here.
I've had a look at the python setup tools: The relevant line is (rather: appears to be, I haven't tested this) which causes C++ source files to be compile with . Not sure whether this is the right or wrong thing to do... I see two reasonable ways to fix this bug, in a more principled way than : python distutils to compile C++ files using nixpkg to treat like with respect to and friends If 1. is the right thing to do, it might still be nice to work around the bug in another way for now.
I've also been bitten by this problem once: The core problem is that setuptools pretty much ignores the difference between CC and CXX. This however is not a problem on a standard mac xcode installation, as both and link the C++ standard library there. However our nix-clang does not link against the C++ standard library (and probably should not) and that's why you will encounter this problem every once in a while when dealing with darwin and c++ python extensions. I'm not an expert on the darwin-stdenv, so I wouldn't know how to fix this in a way that does not require hacking our ways around that problem. To hack around this problem you simply have to grep the pythonPackages for . There are a few packages that use a workaround that involves adding to the C-compile flags: See e.g.

here:
However our nix-clang does not link against the C++ standard library (and probably should not) and that's why you will encounter this problem every once in a while when dealing with darwin and c++ python extensions. any clue how to solve this issue?
The problem does not seem all-too widespread, but there are a few instances:
Any reason we can't just change to use ? Seems like it would work on Linux just fine, and fix a bunch of other stuff.
I knew this was an issue in general (), but assumed the problem was something more complicated.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
<del> #!/usr/bin/env nix-shell #!nix-shell -I nixpkgs=./. -i bash -p curl jq nix-prefetch common-updater-scripts mktemp nix coreutils # First, check that we only update once per day since the version tag is dependent on the date. NEW_VERSION="unstable-$(date -u +%F)" CURRENT_VERSION=$(nix-instantiate --eval -E "with import ./. {}; reindeer.version" | tr -d '"') if [[ "$NEW_VERSION" == "$CURRENT_VERSION" ]]; then echo "skipping reindeer update within same day (version: "$CURRENT_VERSION")" exit 0 fi # Second, let's check if there's a new commit to main. NEW_REV=$(curl https://api.github.com/repos/facebookincubator/reindeer/branches/main | jq '.commit.sha') CURRENT_REV=$(nix-instantiate --eval -E "with import ./. {}; reindeer.src.rev") if [[ "$NEW_REV" == "$CURRENT_REV" ]]; then echo "reindeer is up-to-date (rev: $CURRENT_REV)" exit 0 fi echo "updating reindeer (new: $NEW_REV) (old: $CURRENT_REV)" # Generate the new lockfile in a temporary directory. pushd $(mktemp -d) git clone https://github.com/facebookincubator/reindeer.git --depth=1 pushd reindeer cargo generate-lockfile LOCKFILE=$(realpath ./Cargo.lock) popd popd cp $LOCKFILE pkgs/development/tools/reindeer/ # Get the new sha256 value. TRIMMED_REV=$(echo $NEW_REV | tr -d '"') HASH_RAW=$(nix-prefetch-url https://github.com/facebookincubator/reindeer/archive/${TRIMMED_REV}.tar.gz --unpack --type sha256) HASH_SRI=$(nix hash to-sri --type sha256 ${HASH_RAW}) # Update the file accordingly. update-source-version reindeer "$NEW_VERSION" ${HASH_SRI} --rev=${TRIMMED_REV} </del>

Discussion:
now has an available file (). There are two implications here: should no longer use a generated/patched lockfile can use now because is avoided (which means the custom can be deleted as well) n/a n/a
, I ran the update script but ran into
Thank you! I'll keep an eye on it as well.
Is this going to work with still open?
it would still run, but the package would fail to build, so r-ryantm wouldn't make a successful update until is merged
Change:
- `CoenraadS.bracket-pair-colorizer` -> `coenraads.bracket-pair-colorizer` - `golang.Go` -> `golang.go` <ins> - `services.uptimed` now uses `/var/lib/uptimed` as its stateDirectory instead of `/var/spool/uptimed`. Make sure to move all files to the new directory. </ins> ## Other Notable Changes {#sec-release-21.11-notable-changes} - The setting [`services.openssh.logLevel`](options.html#opt-services.openssh.logLevel) `"VERBOSE"` `"INFO"`. This brings NixOS in line with upstream and other Linux distributions, and reduces log spam on servers due to bruteforcing botnets.

Discussion:
Despite beeing installed for a few days now: it seems like the uptimed service does not find its database properly and prints just the current uptime. I guess this is because the database file gets recreated every boot. But that's only a shot into the blue guess. System: 17.03pre99626. (Gorilla) Nix version: nix-env (Nix) 1.11.6 Nixpkgs version: "17.03pre99626."
Some logs from the journal: Pinging maintainers of the service (there is no maintainer in the pkg):
Probably a permission problem or the said directory does not exists.
Yep, looks like it,... though I have no time to investigate, so I'll just leave this here and hope it gets fixed.
In the meantime you can use this one instead:
:smile:
Still no love for this?
Still no love for this?
Does the following (untested) code help?
Tried yours and but fails with: tested on System: 18.03pre124015. (Impala) Nix version: nix-env (Nix) 1.11.16 Nixpkgs version: "18.03pre124015." Sandboxing enabled: build-use-sandbox = true (diff applied on )
It seems that it did not saved my updated change (I forgot to prefix first)
I know nothing about , sorry.
close as unresolved?
Closed as unresolved.
The issue is still present under 18.09 and (I presume) as  does not seem to contain any of the changes proposed here. Why is this issue closed?
Because I do not care anymore and nobody else seems to care either. Do you want me to reopen?
I probably do. I have some extra details on the issue: So it seems that the user cannot write to the directory even though it owns it.
It seems that is a workaround. Not sure about its safety though.
So now it works, but in a roundabout way: The next steps are making the directory world-readable and bringing into user scope.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me".

This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
As people seemed to interested in this and it is a bug: still important to me
Should be made a tmpfiles rule or if possible changed to /var/lib/uptime, in which case we can set .
I marked this as stale due to inactivity. &rarr;
Change:
]; meta = with lib; { <ins> changelog = "https://github.com/tensorflow/tensorboard/blob/${version}/RELEASE.md"; </ins> description = "TensorFlow's Visualization Toolkit"; homepage = "https://www.tensorflow.org/"; license = licenses.asl20; <ins> mainProgram = "tensorboard"; </ins> maintainers = with maintainers; [ abbradar ]; }; }

Discussion:
Package name: Latest released version: 2.27.0 <!-- Search your package here: --- Current version on the unstable channel: 2.21.0 Current version on the stable/release channel: 2.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: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
x86_64-linux = { stable = fetchurl { url = "https://dl.discordapp.net/apps/linux/${version}/discord-${version}.tar.gz"; <del> sha256 = "sha256-MPdNxZJBmIN4NGEoYWvL2cmNm37/YT275m2bVWHXbwY="; </del> <ins> sha256 = "sha256-6fHaiPBcv7TQVh+TatIEYXZ/LwPmnCmU/QWXKFgUR7U="; </ins> }; ptb = fetchurl { url = "https://dl-ptb.discordapp.net/apps/linux/${version}/discord-ptb-${version}.tar.gz";

Discussion:
Package name: Discord Latest released version: 0.0.27 <!-- Search your package here: --- Current version on the unstable channel: 0.0.26 Current version on the stable/release channel: 0.0.26 <!-- 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.
Surprised that an auto-update didn't catch this one.
Change:
stdenv.mkDerivation rec { pname = "guile-git"; <del> version = "0.7.0"; </del> <ins> version = "0.8.0"; </ins> src = fetchFromGitLab { owner = "guile-git"; repo = pname; rev = "v${version}"; <del> hash = "sha256-7xKs5Biq9HHOJbNILLU1oX8oPuEbti0uLMiobKz//bU="; </del> <ins> hash = "sha256-EZ2uGyk1K2YCl/U7EzTKri6CEe8CGDRy4pNRVjp7ZZY="; </ins> }; strictDeps = true;

Discussion:
Steps to reproduce the behavior: nix-env -i guile-git I was trying to install GNU GUIX and the package would fail building. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
It seems that this issue is caused by version . To temporarily resolve it, you should consider using the guix/guile-git/libgit2 before commit . Relevant links: Once the upstream resolved this issue, updating to the next version of should resolve this issue.
Could updating the gile-guit package so that it uses Libgit2 version 1.7.2 until upstream is solved work as a band-aid fix until then? There doesn't seem to have been major security updates between 1.7.2 and 1.8.1.
What do you mean by guix/guile-git/libgit2? Where can I find that?
You may choose any commit of earlier than , but ensure it’s not too outdated. For example, the parent of commit is . If you're using Flake, you can add these versions as a new input. Then, use an override to replace the used by . old-guile-git- Finally, apply it wherever you need to use it. If you are not using Flake, I cannot provide advice on using since I haven't used it myself.
Change:
sha256 = "113vfrgapyv72lalhd3nkw7jnks8az0gcb5wqn9hj19nhcxlrbcn"; }; <ins> patches = [ (fetchpatch { name = "CVE-2019-17362.patch"; url = "https://github.com/libtom/libtomcrypt/pull/508/commits/25c26a3b7a9ad8192ccc923e15cf62bf0108ef94.patch"; sha256 = "1bwsj0pwffxw648wd713z3xcyrbxc2z646psrzp38ys564fjh5zf"; }) ]; </ins> nativeBuildInputs = [ libtool ]; postPatch = ''

Discussion:
, CVSSv3=9.1 (nixos-20.03, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-unstable: . May contain false positives.