jiebi/CodeConvo huggingface dataset:
Change:
Most python packages seem to use a versioned prefix, e.g. python2.7-. Some modules don't, e.g. python-tkinter, python-pyaudio. I think all packages should use a versioned prefix (in contrast to apps, that should not use a prefix, see ). Having all packages use a versioned prefix we could also enable recursion for python2.6 and python3.2 though this might be a separate discussion.
This is still somewhat undocumented, packages in are versioned and others are not. I agree - all packages should be versioned and separatation should be based on app/module use case (which is also not always easy to determine)
Is this (mostly?) handled by the upcoming stuff?

Discussion:
# python function with default python interpreter buildPythonPackage = pythonPackages.buildPythonPackage; <ins> buildPythonApplication = pythonPackages.buildPythonApplication; </ins> # `nix-env -i python-nose` installs for 2.7, the default python. # Therefore we do not recurse into attributes here, in contrast to

bootstrapped-pip = callPackage ../development/python-modules/bootstrapped-pip { }; }); <ins> buildPythonApplication = args: buildPythonPackage ({namePrefix="";} // args ); </ins> # Unique python version identifier pythonName = if isPy26 then "python26" else

in modules // { <del> inherit python isPy26 isPy27 isPy33 isPy34 isPy35 isPyPy isPy3k pythonName buildPythonPackage; </del> <ins> inherit python isPy26 isPy27 isPy33 isPy34 isPy35 isPyPy isPy3k pythonName buildPythonPackage buildPythonApplication; </ins> # helpers
Change:
() is an old unmaintained software from 2006. Currently fails to build on due to typing changes: And also on that will need an fix: WDYT of removing instead of patching it? Is it still useful? CC Maintainer information:
Thank you for reporting!

Discussion:
export PATH=$PATH:$CERN_ROOT/bin ''; <ins> FFLAGS = lib.optionals (lib.versionAtLeast gfortran.version "10.0.0") [ # Fix https://github.com/vmc-project/geant3/issues/17 "-fallow-invalid-boz" # Fix for gfortran 10 "-fallow-argument-mismatch" ]; makeFlags = [ "FORTRANOPTIONS=$(FFLAGS)" ]; </ins> buildPhase = '' cd $CERN_ROOT mkdir -p build bin lib cd $CERN_ROOT/build $CVSCOSRC/config/imake_boot <del> make -j $NIX_BUILD_CORES bin/kuipc make -j $NIX_BUILD_CORES scripts/Makefile </del> <ins> make -j $NIX_BUILD_CORES $makeFlags bin/kuipc make -j $NIX_BUILD_CORES $makeFlags scripts/Makefile </ins> pushd scripts <del> make -j $NIX_BUILD_CORES install.bin </del> <ins> make -j $NIX_BUILD_CORES $makeFlags install.bin </ins> popd <del> make -j $NIX_BUILD_CORES </del> <ins> make -j $NIX_BUILD_CORES $makeFlags </ins> ''; installPhase = ''
Change:
I have the following expression: When building, I get an error: I did a bisect and found it's nixpkgs commit which broke the expression. could you take a look at this please?
Wow, so this fails: But this succeeds: i.e. s/cacert/bash/ somehow changes whether it passes or fails. What's going on?
cacert doesn't produce a "/nix" directory - just an "/etc" directory.

Discussion:
cp ${layer}/* temp/ chmod ug+w temp/* <del> # FIXME: might not be /nix/store echo '/nix' >> layerFiles echo '/nix/store' >> layerFiles </del> for dep in $(cat $layerClosure); do <del> find $dep >> layerFiles </del> <ins> find $dep -path "${layer}" -prune -o -print >> layerFiles </ins> done <ins> if [ -s layerFiles ]; then # FIXME: might not be /nix/store echo '/nix' >> layerFiles echo '/nix/store' >> layerFiles fi </ins> echo Adding layer tar -tf temp/layer.tar >> baseFiles sed 's/^.//' -i baseFiles <del> comm <(sort -n baseFiles|uniq) <(sort -n layerFiles|uniq|grep -v ${layer}) -1 -3 > newFiles </del> <ins> comm <(sort -u baseFiles) <(sort -u layerFiles) -1 -3 > newFiles </ins> tar -rpf temp/layer.tar --mtime=0 --no-recursion --files-from newFiles 2>/dev/null || true echo Adding meta
Change:
Project description Take full control of your keyboard with this small Python library. Hook global events, register hotkeys, simulate key presses and much more. Metadata homepage URL: source URL: license: mit platforms: linux, darwin (experimental)

Discussion:
<ins> { lib , buildPythonPackage , fetchFromGitHub }: buildPythonPackage rec { pname = "keyboard"; version = "0.13.5"; src = fetchFromGitHub { owner = "boppreh"; repo = pname; rev = "v${version}"; sha256 = "sha256-U4GWhPp28azBE3Jn9xpLxudOKx0PjnYO77EM2HsJ9lM="; }; pythonImportsCheck = [ "keyboard" ]; # Specific OS tests are being run for other OS, like # winmouse on Linux, which provides the following error: # AttributeError: module 'ctypes' has no attribute 'WinDLL' doCheck = false; meta = with lib; { description = "Hook and simulate keyboard events on Windows and Linux"; homepage = "https://github.com/boppreh/keyboard"; license = licenses.mit; maintainers = with maintainers; [ wolfangaukang ]; platforms = platforms.linux; }; } </ins>

kerberos = callPackage ../development/python-modules/kerberos { }; <ins> keyboard = callPackage ../development/python-modules/keyboard { }; </ins> keyring = callPackage ../development/python-modules/keyring { }; keyrings-cryptfile = callPackage ../development/python-modules/keyrings-cryptfile { };
Change:
This breaks a NixOS test which is blocking 's advance. See also and . on .
we may have to update xorgserver OUR there's a abi difference between the version were using now and the newest version NEW xf86videovmware wants a newer abi than ours
The first failing nixpkgs:master commit is
We didn't update xorgserver or this driver. It's libdrm update which triggered this, PR .
I see what's happening. : and now in some libdrm headers was , defining the type.

Discussion:
}); xf86videoqxl = super.xf86videoqxl.overrideAttrs (attrs: { <ins> # https://gitlab.freedesktop.org/xorg/driver/xf86-video-qxl/-/issues/12 postPatch = '' patch -p1 <<EOF --- a/src/qxl_option_helpers.c +++ b/src/qxl_option_helpers.c @@ -37 +37 @@ -        return options[option_index].value.bool; +        return options[option_index].value.boolean; EOF ''; </ins> buildInputs =  attrs.buildInputs ++ [ spice-protocol ]; });

# # We set it to /var/log which can't be touched from inside the sandbox causing the build to hard-fail ./dont-create-logdir-during-build.patch <ins> # Fix e.g. xorg.xf86videovmware with libdrm 2.4.108 # TODO: remove with xorgserver >= 1.21 (fetchpatch { name = "stdbool.patch"; url = "https://gitlab.freedesktop.org/xorg/xserver/-/commit/454b3a826edb5fc6d0fea3a9cfd1a5e8fc568747.diff"; sha256 = "1l9qg905jvlw3r0kx4xfw5m12pbs0782v2g3267d1m6q4m6fj1zy"; }) </ins> ]; buildInputs = commonBuildInputs ++ [ libdrm mesa ]; propagatedBuildInputs = attrs.propagatedBuildInputs or [] ++ [ libpciaccess libepoxy ] ++ commonPropagatedBuildInputs ++ lib.optionals stdenv.isLinux [
Change:
In combination with 21.11 adding it to the job, this prevents channel. The keymap tests don't have any maintainers. That's quite an issue for channel-blocking jobs, I think.
Well, we could remove from the blocking set, at least for now. It certainly doesn't feel so critical to me. (Though qwertz layout gets vast majority in my country actually.)
In it was discussed wether Linux 5.15 could be the cause, but the way I see it the test is running with Linux 5.10? 5.15 seems only to be used for the stdenv.
Yes, It is at least surprising that a large part of the channel tests is about keyboard layouts.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
if the keymap tests have no maintainers, perhaps they should be removed, or at leat disabled for now.
it looks like its random which one symbol fails azerty fails sometimes too
This test has been flaky since and does not provide much value. I propose to simply remove it from the tested job.
I'm thinking this is a race condition with sending keys too fast, maybe made worse when a builder is under high load. Something like this perhaps?
EDIT: it takes way too long to run the test without kvm so i didn't i'll run the test with and without that. and with running to mimic high load i had to apply this patch to run the test vm because kvm was failing but its very very slow now
So, at least the simple step for now?
the sleep patch does indeed fix the issue, at least when building on my Honeycomb. I do think it's odd though that the test fails in exactly the same way every time I run it. I'd expect it to fail less consistently, or in different ways…
azerty test fails sometimes too
While it's far from elegant, I'd be fine with adding the sleep patch. Since it's only 10ms per character, I don't think the performance impact will be significant, and I'd prefer to start verifying the functionality again (major use case: encryption passphrase input, where the results aren't even visible).
i've run some tests on my rpi4b and found that applying this patch fixes the issue even with load and no delay(i still think we should leave the delay) <pre<del0.02 sometimes works if there is no other load at least 0.04 is needed to sometimes not fail when i run 1 is safe according to this the average inter-key interval of a human is 238ms INTER-KEY INTERVALS Average inter-key interval is 238.656 ms (SD = 111.6). A lower bound of about 60 ms can be observed.</del</pre

Discussion:
(onFullSupported "nixos.tests.keymap.dvorak") (onFullSupported "nixos.tests.keymap.dvorak-programmer") (onFullSupported "nixos.tests.keymap.neo") <del> (onFullSupported "nixos.tests.keymap.qwertz") </del> <ins> (onSystems ["x86_64-linux"] "nixos.tests.keymap.qwertz") </ins> (onFullSupported "nixos.tests.latestKernel.login") (onFullSupported "nixos.tests.lightdm") (onFullSupported "nixos.tests.login")
Change:
In combination with 21.11 adding it to the job, this prevents channel. The keymap tests don't have any maintainers. That's quite an issue for channel-blocking jobs, I think.
Well, we could remove from the blocking set, at least for now. It certainly doesn't feel so critical to me. (Though qwertz layout gets vast majority in my country actually.)
In it was discussed wether Linux 5.15 could be the cause, but the way I see it the test is running with Linux 5.10? 5.15 seems only to be used for the stdenv.
Yes, It is at least surprising that a large part of the channel tests is about keyboard layouts.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
if the keymap tests have no maintainers, perhaps they should be removed, or at leat disabled for now.
it looks like its random which one symbol fails azerty fails sometimes too
This test has been flaky since and does not provide much value. I propose to simply remove it from the tested job.
I'm thinking this is a race condition with sending keys too fast, maybe made worse when a builder is under high load. Something like this perhaps?
EDIT: it takes way too long to run the test without kvm so i didn't i'll run the test with and without that. and with running to mimic high load i had to apply this patch to run the test vm because kvm was failing but its very very slow now
So, at least the simple step for now?
the sleep patch does indeed fix the issue, at least when building on my Honeycomb. I do think it's odd though that the test fails in exactly the same way every time I run it. I'd expect it to fail less consistently, or in different ways…
azerty test fails sometimes too
While it's far from elegant, I'd be fine with adding the sleep patch. Since it's only 10ms per character, I don't think the performance impact will be significant, and I'd prefer to start verifying the functionality again (major use case: encryption passphrase input, where the results aren't even visible).
i've run some tests on my rpi4b and found that applying this patch fixes the issue even with load and no delay(i still think we should leave the delay) <pre<del0.02 sometimes works if there is no other load at least 0.04 is needed to sometimes not fail when i run 1 is safe according to this the average inter-key interval of a human is 238ms INTER-KEY INTERVALS Average inter-key interval is 238.656 ms (SD = 111.6). A lower bound of about 60 ms can be observed.</del</pre

Discussion:
def send_key(self, key: str) -> None: key = CHAR_TO_KEY.get(key, key) self.send_monitor_command("sendkey {}".format(key)) <ins> time.sleep(0.01) </ins> def start(self) -> None: if self.booted:
Change:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on github to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the 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: safe <!-- 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: 1.5.1 desired version: 1.6.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.

Discussion:
{ lib <del> , buildGoPackage </del> <ins> , buildGoModule </ins> , fetchFromGitHub }: <del> with builtins; buildGoPackage rec { </del> <ins> buildGoModule rec { </ins> pname = "safe"; <del> version = "1.5.1"; </del> <ins> version = "1.6.1"; </ins> src = fetchFromGitHub { owner = "starkandwayne"; repo = "safe"; rev = "v${version}"; <del> sha256 = "12gzxrnyl890h79z9yx23m1wwgy8ahm74q4qwi8n2nh7ydq6mn2d"; </del> <ins> sha256 = "sha256-ankX4BeMvBEd0e01mQHfaPg4z1z+IZqELaSEJ5deF8Y="; </ins> }; <del> goPackagePath = "github.com/starkandwayne/safe"; </del> <ins> vendorSha256 = "sha256-7hX35FfFxfoiI/dSxWhZH8iJoRWa4slAJF0lULq8KL4="; subPackages = [ "." ]; </ins> ldflags = [ "-X main.Version=${version}"
Change:
When trying to install Ocenaudio, the installation fails due to a sha256 hash mismatch. Steps to reproduce the behavior: ocenaudio to my NixOS config I expected the program to be installed. <!-- 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:
looks like aur has the same problem this should be reported upstream.

Discussion:
stdenv.mkDerivation rec { pname = "ocenaudio"; <del> version = "3.10.6"; </del> <ins> version = "3.11.0"; </ins> src = fetchurl { url = "https://www.ocenaudio.com/downloads/index.php/ocenaudio_debian9_64.deb?version=${version}"; <del> sha256 = "0fgvm1xw2kgrqj3w6slpfxbb3pw9k8i0dz16q9d5d8gyyvr2mh8g"; </del> <ins> sha256 = "1yflpyl0d1mi0zxdyrlbg0px95s2c945ahy0agc8rha01ccf7jwy"; </ins> }; nativeBuildInputs = [
Change:
, CVSSv3=8.1 (nixos-unstable) When PgBouncer is configured to use "cert" authentication, a man-in-the-middle attacker can inject arbitrary SQL queries when a connection is first established, despite the use of TLS certificate verification and encryption. This flaw affects PgBouncer versions prior to 1.16.1. Scanned versions: nixos-unstable: . Cc

Discussion:
stdenv.mkDerivation rec { pname = "pgbouncer"; <del> version = "1.16.0"; </del> <ins> version = "1.16.1"; </ins> src = fetchurl { url = "https://pgbouncer.github.io/downloads/files/${version}/${pname}-${version}.tar.gz"; <del> sha256 = "0li66jk1v07bpfmmqzcqjn5vkhglfhwnbncc5bpalg5qidhr38x4"; </del> <ins> sha256 = "1z7p3ghpmbp5qv1bz9s186jn0hfnr300dc5p0hmh6vbnwklpfx08"; </ins> }; nativeBuildInputs = [ pkg-config ];
Change:
nix-direnv was updated in to assume that is 2.4, but that is no longer true after was merged. This causes files with to fail to active the . Steps to reproduce the behavior: sure your system is running NixOS 21.11 or is nix-darwin following the nixos-21.11 channel; (or any project with a flake); and . The specified in the flake is activated. Overriding in an overlay with allows the flake to activate the as expected. Please run and paste the result. Maintainer information:
This is only for nixpkgs. There was also a home-manager module option that needs to be re-introduced:
Hi, had the same problem too, just updated and everything is fine, seems like it's fixed now.
Yes. This was fixed in the linked pull requests.
I'm using flakes for my configuration and I still exhibit the problem with these fixed inputs: Is this expected? Or am I doing something wrong?
Looks like it was a configuration problem (). Enabling solved the issue.

Discussion:
, stdenv , fetchFromGitHub , gnugrep <del> , nix , enableFlakes ? null # deprecated </del> <ins> , nixStable , nix_2_4 , enableFlakes ? false </ins> }: <ins> let nix = if enableFlakes then nix_2_4 else nixStable; in </ins> stdenv.mkDerivation rec { pname = "nix-direnv"; version = "1.5.0";

nfsUtils = nfs-utils;  # added 2014-12-06 nginxUnstable = nginxMainline; # added 2018-04-25 nilfs_utils = nilfs-utils; # added 2018-04-25 <del> nix-direnv-flakes = nix-direnv; </del> nix-review = nixpkgs-review; # added 2019-12-22 nixFlakes = nix_2_4; # added 2021-05-21 nmap_graphical = nmap-graphical;  # added 2017-01-19

nfstrace = callPackage ../tools/networking/nfstrace { }; nix-direnv = callPackage ../tools/misc/nix-direnv { }; <ins> nix-direnv-flakes = callPackage ../tools/misc/nix-direnv { enableFlakes = true; }; </ins> nix-output-monitor = haskell.lib.compose.justStaticExecutables (haskellPackages.nix-output-monitor);
Change:
After updating to 21.11, the animation for directly switching between workspaces looks really bad. (I hope this isn't normal behaviour with Pantheon 6?) Steps to reproduce the behavior: NixOS 21.05 w/ Pantheon workspace switching NixOS 21.11 w/ Pantheon workspace switching Smooth workspace switching like on 21.05. Before: After: Add any other context about the problem here. Please run and paste the result. Maintainer information:
I can reproduce this on NixOS 21.11: you mean the grey space between the workspaces, right? ! can you reproduce this too? I think the best way forward would be an upstream issue, since we can't do much about this (i think).
Sorry for not being more specific, I was in a hurry to get some assignments done until midnight. I meant the way the workspace doesn't finish smoothly sliding in, instead opting to jump into place once it reaches the last sixth of the screen. This jumpiness is also present in your recording. But maybe this grey space is caused by the same underlying problem, I don't know. This looks very distracting coming from 21.05 where it was fully smooth. And it looks even more wrong because going to the workspace overview first (<kbdSuper</kbd+ <kbd↓</kbd) and then switching workspaces shows a completely smooth animation as expected. That's why I reported it here, because I assumed they wouldn't have shipped that in their own distro considering all the other animations are smooth.
Yes, that's quiet a difference.
FYI there is , not sure if that is the problem described here. When doing Pantheon 7 upgrade, I guess I will be more careful when choosing mutter versions and just use what elementary is using :-(
I doubt they will fix it anytime soon. Focal might be stuck with mutter3.36.
36.4 should be pretty same story as this so just replacing it would fix it gonna give it try

Discussion:
{ lib , stdenv , fetchFromGitHub <ins> , fetchpatch </ins> , nix-update-script , pkg-config , meson

# We look for plugins in `/run/current-system/sw/lib/` because # there are multiple plugin providers (e.g. gala and wingpanel). ./plugins-dir.patch <ins> # WindowManager: save/restore easing on workspace switch # https://github.com/elementary/gala/pull/1430 (fetchpatch { url = "https://github.com/elementary/gala/commit/1f94db16c627f73af5dc69714611815e4691b5e8.patch"; sha256 = "sha256-PLNbAXyOG0TMn1y2QIBnL6BOQVqBA+DBgPOVJo4nDr8="; }) </ins> ]; nativeBuildInputs = [
Change:
[root nixos-rebuild boot [root nix-shell -p nix-info --run "nix-info -m" system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:

Discussion:
sha256 = "1mqspsn6bf3ibvih1zna2glkg8iw7vy5zg9gzg0d1m8zcndk2c48"; }; <del> checkInputs = [ pytestCheckHook pytest-benchmark enum34 numpy arrow ruamel-yaml ]; </del> <ins> checkInputs = [ pytestCheckHook pytest-benchmark enum34 numpy ]; </ins> <del> disabledTests = lib.optionals stdenv.isDarwin [ "test_multiprocessing" ]; </del> <ins> # these have dependencies that are broken on Python 2 disabledTestPaths = [ "tests/gallery/test_gallery.py" "tests/test_benchmarks.py" "tests/test_compiler.py" ]; disabledTests = [ "test_timestamp" ] ++ lib.optionals stdenv.isDarwin [ "test_multiprocessing" ]; </ins> pytestFlagsArray = [ "--benchmark-disable" ];

{ lib , buildPythonPackage , fetchPypi <del> , flake8 , pytest_4 , pytest-expect , mock </del> , six , webencodings <ins> , mock , pytest-expect , pytestCheckHook_5 </ins> }: buildPythonPackage rec {

sha256 = "b2e5b40261e20f354d198eae92afc10d750afb487ed5e50f9c4eaf07c184146f"; }; <del> checkInputs = [ flake8 pytest_4 pytest-expect mock ]; </del> propagatedBuildInputs = [ <del> six webencodings </del> <ins> six webencodings </ins> ]; <del> checkPhase = '' # remove test causing error # https://github.com/html5lib/html5lib-python/issues/411 rm html5lib/tests/test_stream.py py.test ''; </del> <ins> checkInputs = [ mock pytest-expect pytestCheckHook_5 ]; </ins> meta = { homepage = "https://github.com/html5lib/html5lib-python";

# it should not override the version of pytest that is used for say # Python 2. This is an ugly hack that is needed now because the hook # propagates the package. <ins> pytestCheckHook_5 = if isPy3k then self.pytestCheckHook.override { pytest = self.pytest_5; } else self.pytestCheckHook; </ins> pytestCheckHook_6_1 = if isPy3k then self.pytestCheckHook.override { pytest = self.pytest_6_1; } else
Change:
A clear and concise description of what the bug is. Steps to reproduce the behavior: build github:nixos/nixpkgs/nixos-unstable#legacyPackages.x86_64- Nix builds the derivation. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Maintainer information:

Discussion:
MACOSX_DEPLOYMENT_TARGET=10.16 '' else null; <ins> configureFlags = [ "PYTHON_VERSION=${lib.versions.major python.version}" ]; </ins> nativeBuildInputs = [ pkg-config ]; buildInputs = [ dbus dbus-glib ] # My guess why it's sometimes trying to -lncurses.
Change:
All ceph tests are currently broken on release-21.11 and master. First broken in ( to ), likely due to a snappy update, like ). Steps to reproduce the behavior: -build -A etc. Tests should complete. 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. -- Maintainer information:

Discussion:
url = "https://github.com/google/snappy/pull/142/commits/658cb2fcf67b626fff2122a3dbf7a3560c58f7ee.patch"; sha256 = "1kg3lxjwmhc7gjx36nylilnf444ddbnr3px1wpvyc6l1nh6zh4al"; }) <ins> # Re-enable RTTI, without which other applications can't subclass # snappy::Source (this breaks Ceph, as one example) # https://tracker.ceph.com/issues/53060 # https://build.opensuse.org/package/show/openSUSE:Factory/snappy (fetchpatch { url = "https://build.opensuse.org/public/source/openSUSE:Factory/snappy/reenable-rtti.patch?rev=a759aa6fba405cd40025e3f0ab89941d"; sha256 = "sha256-RMuM5yd6zP1eekN/+vfS54EyY4cFbGDVor1E1vj3134="; }) </ins> ]; outputs = [ "out" "dev" ];