jiebi/CodeConvo huggingface dataset:
Change:
tar xf build/distributions/JabRef-${version}.tar -C $out --strip-components=1 unzip $out/lib/javafx-web-18-linux${lib.optionalString stdenv.isAarch64 "-aarch64"}.jar libjfxwebkit.so -d $out/lib/ <del> wrapProgram $out/bin/JabRef  --suffix PATH : ${lib.makeBinPath [ xdg-utils ]}  --set JAVA_HOME "${jdk}"  --set JAVA_OPTS "-Djava.library.path=$out/lib/ --patch-module org.jabref=$out/share/java/jabref/resources/main" </del> # lowercase alias (for convenience and required for browser extensions) ln -sf $out/bin/JabRef $out/bin/jabref <ins> rm $out/bin/JabRef.bat </ins> runHook postInstall ''; <ins> preFixup = '' gappsWrapperArgs+=( --suffix PATH : ${lib.makeBinPath [ xdg-utils ]} --set JAVA_HOME "${jdk}" --set JAVA_OPTS "-Djava.library.path=$out/lib/ --patch-module org.jabref=$out/share/java/jabref/resources/main" ) ''; </ins> meta = with lib; { description = "Open source bibliography reference manager"; homepage = "https://www.jabref.org";

Discussion:
File open dialog results in crash due to missing GSettings schema path. This seems similar to Steps to reproduce the behavior: on "Open library" icon File open dialog opens. Please run and paste the result.
I can't reproduce it on a clean NixOS VM.
to reproduce these issues do to empty XDGDATADIRS
Great! Now I can reproduce it without a VM.
Please test
Thanks for the quick fix, works for me.
Would be nice if this could be backported (let's try with issue label on the PR again after it is merged, if you would be so kind to 22.05 as well.
I'll add the label. :ok_hand:
I am not sure whether this label should only be applied after the PR is successfully merged, i.e. only then does the action trigger, but let's see about that assumption.
Unfornately there is confilctions so the auto backport failed.
Thanks, yes, already saw it. Will open a manual backport PR.
Change:
ejabberd = callPackage ../servers/xmpp/ejabberd { }; <ins> exhibitor = callPackage ../servers/exhibitor { }; </ins> prosody = callPackage ../servers/xmpp/prosody { lua5 = lua5_1; inherit (lua51Packages) luasocket luasec luaexpat luafilesystem luabitop luaevent luazlib;

Discussion:
We currently have a nice ZooKeper module and package, but apparently all the cool kids run ZK via , which we don't have packaged or any module around. Anyone feel like packaging and/or writing a module for it? cc who have dealt with ZK
I would like to own this. Thank you for bringing this up.
Let's assign it to you then &ndash; informally, as GitHub only allows that for organization members (or some similar condition).
Thanks
is this happening?
Sorry for the delay. Yes I am working on this.
any progress?
FYI, I took a crack at this in
Change:
libX11 libXcursor libXdamage <ins> libXdmcp </ins> libXext libXi libXinerama

Discussion:
I reported some flakey test in freerdp upstream and they hinted that maybe we could be building freerdp better: Filing this so I don't forget to look at it.
I use freerdp all the time, so I have patched things up on my side and will open a proper PR when I have been running with it for a while. FYI, we are in fact already building against ffmpeg.
Change:
{ stdenv, fetchurl, unzip }: let <del> version = "1.6.0"; </del> <ins> version = "1.6.1"; </ins> sources = let base = "https://releases.hashicorp.com/vault/${version}"; in { x86_64-linux = fetchurl { url = "${base}/vault_${version}_linux_amd64.zip"; <del> sha256 = "0fay6bw31x9kxmc52sh5qp63nfkwji74fbnlx8pj3smz3qnqw143"; </del> <ins> sha256 = "1la2pylcj9y5gr7hr4aaa49427y3lgxi2phhl46pqmr7an62pkbm"; </ins> }; i686-linux = fetchurl { url = "${base}/vault_${version}_linux_386.zip"; <del> sha256 = "0bjks9lpgl39cq55c9cyc0glhmyxzs37a2an8ynzza94gv5mgcxa"; </del> <ins> sha256 = "1a2rhv5bpv43qp74a49msrwr7djzy86irsn73jl0xnkh0k6ijci1"; </ins> }; x86_64-darwin = fetchurl { url = "${base}/vault_${version}_darwin_amd64.zip"; <del> sha256 = "0hl1k35x78y0hi3y5xjnzby1ygisqjyvdak7s61m9f363nsr1shh"; </del> <ins> sha256 = "0snswwai2ya26crm3ksifrmbdnajr36v4vamh7g65plg6vzban9a"; </ins> }; aarch64-linux = fetchurl { url = "${base}/vault_${version}_linux_arm64.zip"; <del> sha256 = "018a5i14x6phhx1axvx0bvqn4ggsimfizs48xbmykgiyfmzkrwgz"; </del> <ins> sha256 = "0ix99da3xd4z200dgvpfc2h1sfx6l8cipichvfjlj39md45grs89"; </ins> }; };

Discussion:
, CVSSv3=5.3 (nixos-20.09) CVSSv3=5.3 (nixos-20.09) Scanned versions: nixos-20.09: . Cc Cc Cc Cc
Change:
name = "racket-minimal-${oldAttrs.version}"; src = oldAttrs.src.override { inherit name; <del> sha256 = "0yc5zkpq1bavj64h67pllw6mfjhmdp65fgdpyqcaan3syy6b5cia"; </del> <ins> sha256 = "0qvfi6rg9cwzh716q5j7m30rqq9xysi6zsalqlpdqrzhnx8y54k0"; </ins> }; meta = oldAttrs.meta // {

Discussion:
Project description Racket on Chez Scheme (Racket CS) may become the default Racket implementation in the next release [1] [1] Metadata homepage URL: https://racket- source URL: license: MIT or Apache 2.0 platforms: unix
Released:
Just a note. Reading stumbled upon the following (emphasis mine): This probably needs to be worked-around...
I thought I'd have a stab at a pull request for bumping to 8.0. It's still compiling, but right now it's looking good. I just had to bump the version number, correct the checksum and fix some hardcoded paths and their like. I'll report back when I know more! Update: There were no further problems. Upstream took care of everything :-) I confirm that I got a working drracket 8.0. Test for yourself here:
Change:
$ export NIXPKGS_ALLOW_INSECURE=1 ${flakeNote} <del> b) for `nixos-rebuild` you can add ‘${lib.getName attrs}’ to </del> <ins> b) for `nixos-rebuild` you can add ‘${getNameWithVersion attrs}’ to </ins> `nixpkgs.config.permittedInsecurePackages` in the configuration.nix, like so: { nixpkgs.config.permittedInsecurePackages = [ <del> "${lib.getName attrs}" </del> <ins> "${getNameWithVersion attrs}" </ins> ]; } c) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add <del> ‘${lib.getName attrs}’ to `permittedInsecurePackages` in </del> <ins> ‘${getNameWithVersion attrs}’ to `permittedInsecurePackages` in </ins> ~/.config/nixpkgs/config.nix, like so: { permittedInsecurePackages = [ <del> "${lib.getName attrs}" </del> <ins> "${getNameWithVersion attrs}" </ins> ]; }

Discussion:
When running it fails due to an insecure package. To resolve this the output of recommends adding to the file (in my case for electron) This is incorrect as the correct line that should be must contain the package name and ver sion instead of just the package name (eg: instead of ) Steps to reproduce the behavior: while having an insecure package the instructions in the output The output must specify instead of in the sample code. This is the current (wrong) full output
Change:
qrupdate = callPackage ../development/libraries/qrupdate { }; <ins> qadwaitadecorations-qt6 = callPackage ../by-name/qa/qadwaitadecorations/package.nix { useQt6 = true; }; </ins> qgnomeplatform = libsForQt5.callPackage ../development/libraries/qgnomeplatform { }; qgnomeplatform-qt6 = qt6Packages.callPackage ../development/libraries/qgnomeplatform {

Discussion:
Project description Qt decoration plugin implementing Adwaita-like client-side decorations (Replacement for ) <!-- Describe the project a little: --Metadata homepage URL: source URL: license: LGPL2.1 platforms: linux
QGnomePlatform is discontinued and will no longer receive updates the replacement is QAdwaitaDecorations.
CC
Change:
$out/LICENSE.txt  $out/NEWS.txt  $out/NOTICE.txt  <del> $out/javadoc  </del> $out/share/doc/${pname}-${version} if [[ -d $out/doc ]]; then

Discussion:
, CVSSv3=9.1 (nixos-21.11, nixos-unstable) When running Apache Cassandra with the following configuration: enableuserdefinedfunctions: true enablescripteduserdefinedfunctions: true enableuserdefinedfunctions_threads: false it is possible for an attacker to execute arbitrary code on the host. The attacker would need to have enough permissions to create user defined functions in the cluster to be able to exploit this. Note that this configuration is documented as unsafe, and will continue to be considered unsafe after this CVE. Scanned versions: nixos-21.11: ; nixos-unstable: . Cc
This CVE only affects configurations with a specific option enabled that is not enabled by default.
Upon second reading, a fix is available, which is relevant for those with vulnerable configs.
Change:
fingerprint = "9E6A 25F2 C1F2 9D76 ED00  1932 1261 173A 01E1 0298"; }]; }; <ins> n8henrie = { name = "Nathan Henrie"; github = "n8henrie"; githubId = 1234956; "keys" = [{ "fingerprint" = "F21A 6194 C9DB 9899 CD09 E24E 434B 2C14 B8C3 3422"; }]; }; </ins> nadir-ishiguro = { github = "nadir-ishiguro"; githubId = 23151917;

Discussion:
Project description A CLI tool for saving a faithful copy of a complete web page in a single HTML file. Metadata homepage URL: (the entire project) source URL: (the CLI tool) license: AGPL-3.0 platforms: Linux, possibly others (not sure) Priorities Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Also there is a single-file(z)-cli variant: homepage URL: (the entire project) source URL: (the CLI tool)
Change:
nativeBuildInputs = [ qmake qttools ]; <del> buildInputs = [ curl libmediainfo libzen ffmpeg qtbase qtdeclarative qtmultimedia qtsvg ]; </del> <ins> buildInputs = [ curl ffmpeg libmediainfo libzen qtbase qtdeclarative qtmultimedia qtsvg ]; </ins> qmakeFlags = [ "USE_EXTERN_QUAZIP=${quazip}/include/quazip5"

Discussion:
MediaElch works correctly, except it cannot load StreamDetails. In About/Developer, it complains about not finding Steps to reproduce the behavior: or add it in MediaElch and scan some files to «Stream details» tab and try to «load from files» (3bis) You can also open About/Developer modal to see the message about the missing module. MediaElch should find libmediainfo and be able to use it to get info from media. ! NixOS 21.11 with Gnome/Wayland Thanks in advance !
As found by in it works perfectly with
Change:
stdenv.mkDerivation rec { pname = "microcode-intel"; <del> version = "20201112"; </del> <ins> version = "20201118"; </ins> src = fetchFromGitHub { owner = "intel"; repo = "Intel-Linux-Processor-Microcode-Data-Files"; rev = "microcode-${version}"; <del> sha256 = "104l3py5z6405wpa2fscqpc5r9dgrf1ckaf27hrswivi32gvp7f2"; </del> <ins> sha256 = "1xs3f2rbfqnpz9qs7a1kl363qdyb8fybmmyd37v573clqf7l4lgg"; </ins> }; nativeBuildInputs = [ iucode-tool libarchive ];

Discussion:
Describe the bug There appears to be a bug in the latest microcode from Intel that causes the XPS 13 9310 (and possibly other Tiger Lake machines) to freeze right after initrd with heavy graphical glitching presented on the screen. You can find the main bug report here The last comment appears to be an administrator: Perhaps this is taken to mean that Intel advise rolling back to the previous version until a new patched version is released? Perhaps it's worth reverting this commit temporarily? If not, perhaps someone can offer some advice on how NixOS users on XPS 9310 can patch their file to switch back to the previous version? I'm still getting my head around Nix and it's not obvious to me what the best way to achieve this would be. To Reproduce Run on the unstable nixos channel on a Dell XPS 13 9310 and run . Reboot into a glitchy screen. To get back to a usable state, reboot once more but select the previously working generation from the nixos generation menu. Expected behavior Boot into NixOS smoothly on Dell XPS 13 9310. Additional context I'm on a mission to get the XPS 13 9310 working nicely with NixOS, and land the necessary patches in nixos/nixos-hardware. You can follow along This bug was an unexpected regression that caught me off guard a few days ago while attempting to update my system while trying out new kernel patches to get wi-fi working. Notify maintainers cc as you are listed in the package cc as you made the aforementioned commit updating the version.
It looks like this is the commit the administrator is referring to that removes the update here
Rather than revert, I'll submit a PR that updates the package to point to the aforementioned Intel commit that supposedly removes the culprit microcode.
Thanks for the report. Can you testdrive ?
Change:
<ins> { lib , buildPythonPackage , fetchPypi , sqlalchemy , boto3 , botocore , pandas , tenacity }: buildPythonPackage rec { pname = "pyathena"; version = "2.3.0"; src = fetchPypi { pname = "PyAthena"; inherit version; sha256 = "08fl653yayvqi991zvcai5ifcxwy9ip6xh0cr3lbimggjnjgwsl5"; }; # Nearly all tests depend on a working AWS Athena instance, # therefore deactivating them. # https://github.com/laughingman7743/PyAthena/#testing doCheck = false; propagatedBuildInputs = [ boto3 botocore pandas tenacity ]; meta = with lib; { homepage = "https://github.com/laughingman7743/PyAthena/"; license = licenses.mit; description = "Python DB API 2.0 (PEP 249) client for Amazon Athena"; maintainers = with maintainers; [ turion ]; }; } </ins>

Discussion:
Project description PyAthena is a Python DB API 2.0 (PEP 249) client for Amazon Athena. Metadata homepage URL: source URL: license: mit platforms: all
I marked this as stale due to inactivity. &rarr;
I started a PR to solve this
Change:
sha256 = "sha256-g80WedX+TGHE9EJ/RSgOc53PM17V3WZslUNaHoqKTo0="; }; <ins> SETUPTOOLS_SCM_PRETEND_VERSION = version; </ins> patches = [ (substituteAll { src = ./paths.patch;

Discussion:
On the latest unstable (I'm testing on ), the build of ocrmypdf has started erroring. Steps to reproduce the behavior: on nixpkgs-unstable Clean build, link <details<summaryBuild output</summary</details Please run and paste the result. Maintainer information:
Change:
buildInputs = [ libuuid <ins> gnu-efi </ins> ]; # Fails very rarely with 'No rule to make target: ...'

Discussion:
Steps to reproduce the behavior: The src is: We tried to use from nixpkgs in , but that made nix-build . -A fail. I guess that happened due to one of the commits between and (which is the latest commit on ) <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
# TODO Patch this somehow; tries to dlopen './libturbojpeg.so' from cwd ln -s $(readlink -e "${libjpeg_turbo.out}/lib/libturbojpeg.so") $out/share/zoom-us/libturbojpeg.so <ins> # Again, requires faac with a nonstandard filename. ln -s $(readlink -e "${faac}/lib/libfaac.so") $out/share/zoom-us/libfaac1.so </ins> runHook postInstall '';

Discussion:
Describe the bug Zoom-us recordings have no sound, tested on three different NixOS machines, other non-NixOS Linux machines work well. To Reproduce Steps to reproduce the behavior: . a meeting. someone record it. for conversion to finish. it → no sound. with → no sound stream. , file is just 292 bytes. Expected behavior To have sound stream muxed into the resulting file. Screenshots n/a Additional context n/a Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(m): channels(root): nixpkgs: Maintainer information:
Because it's not free software I see no way at all I can help debug this. Did it work for you on a different distro?
I don’t know how either. :'( Yes, exactly. Also I suppose that have rather extensive tests in place, and wouldn’t release a version with such a bug. Perhaps, as the first step, we could look at its when “Record” is being pressed — maybe it’s missing some library?
I cannot confirm, works for me.
huh, that’s good to hear! Can you show your ?
Another way to test on NixOS is to enable and install the Flatpak package from here: If the Flatpak package also does not work, we may be able to rule out the package itself, but not necessarily vice-versa.
Incidentally, I am able to reproduce this on Gnome + Wayland with nixpkgs-unstable. The Zoom application does show a popup saying "Your speakers and microphone are not working correctly". Investigating.
Using reveals that Zoom requires on its PATH. PR incoming.
Change:
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

Discussion:
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.
Change:
sha256 = "sha256-j5K5i+hl/miyHste73akZL62K6YTxXmN8mmFK9BCecs="; <ins> nativeBuildInputs = [ gobject-introspection ]; </ins> buildInputs = [ dbus-glib garcon

Discussion:
Apparently there's a problem with wrapped command. When try to configure my screensaver (e.g. slideshow), it won't open. Opening it via terminal returns nothing. The command itself points to /nix/store/hash-xfce4-screensaver-version/bin/.xfce4-screensaver-configure-wrapped. Its a python script, but interpreter is set as #!/usr/bin/python3, which is obviously not available on nixos. Steps to reproduce the behavior: Configuration program should open ! strace output:
Does help?
Thanks, now it works. Shall i close the issue or wait for PR?
Change:
preFixup = '' glib-compile-schemas $out/share/gsettings-schemas/${pname}-${version}/glib-2.0/schemas <del> gappsWrapperArgs+=(--set PYTHONPATH "$PYTHONPATH") </del> <ins> gappsWrapperArgs+=(--set PYTHONPATH "${python3.pkgs.makePythonPath dependencies}") </ins> # these are called from virt-install in initrdinject.py gappsWrapperArgs+=(--prefix PATH : "${lib.makeBinPath [ cpio e2fsprogs file findutils gzip ]}")

Discussion:
Build on () and when running I find in the runtime closure pytest shouldn't be a runtime dependency <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
, vamp-plugin-sdk , wafHook , xjadeo <ins> , optimize ? true # disable to print Lua DSP script output to stdout </ins> , videoSupport ? true }: stdenv.mkDerivation rec { pname = "ardour"; <del> version = "7.5"; </del> <ins> version = "8.0"; </ins> # We can't use `fetchFromGitea` here, as attempting to fetch release archives from git.ardour.org # result in an empty archive. See https://tracker.ardour.org/view.php?id=7328 for more info. src = fetchgit { url = "git://git.ardour.org/ardour/ardour.git"; rev = version; <del> hash = "sha256-cmYt6fGYuuVs6YhAXaO9AG6TrYLDVUaE1/iC67rt76I="; </del> <ins> hash = "sha256-ZL8aTq2OsCWwLUUx5XYbH4eRN+Xz+oMAj9IS07RfTag="; </ins> }; bundledContent = fetchzip {

Discussion:
is adding ardour 7.0 to the repository. As noted by 7.0 still experiences crashes. Thus we've opted to keep version 6.9 around for a little while for people to optionally use as a more stable base for their projects. Once ardour 7.x (package name ) is deemed stable, ardour 6.x (package name ) should be removed from nixpkgs.
updated to in preparation for 8.0, so this issue should be either closed or updated. Fwiw, maintaining the package of the last stable release of the previous major version seems like a good tradition for Ardour.
Thanks for pointing that out. I agree that keeping (at least) the last version around is helpful for some people who can't update for one reason or another. If someone objects, they can create a new issue.
Change:
`config.services.zoneminder.database.createLocally` to true. Otherwise, when set to `false` (the default), you will have to create the database and database user as well as populate the database yourself. <ins> Additionally, you will need to run `zmupdate.pl` yourself when upgrading to a newer version. </ins> ''; webserver = mkOption {

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

I support for ZM because I needed it and it solves my problem right now (until we need to update of course), but any PR would be very much welcome.
The is already part of the package - we just don't do anything with it and according to the comment in the header: But then of course it does have functionality for dealing with a number of changes. So the short version - someone just has to write (and test) how it behaves when upgraded and ensure this runs. I am realistically not going to work on that right now though.