jiebi/CodeConvo huggingface dataset:
Change:
cmakeFlags = [ "-DGMIC_QT_HOST=${if variant == "standalone" then "none" else variant}" <del> "-DENABLE_SYSTEM_GMIC:BOOL=ON" </del> <ins> "-DENABLE_SYSTEM_GMIC=ON" "-DENABLE_DYNAMIC_LINKING=ON" </ins> ]; postPatch = ''

Discussion:
We broke gmic-qt during the bump. After contacting upstream, it seems like the cmake build is not maintained anymore: They migrated to . We should align with them and rewrite a qmake derivation for gmic-qt. Edit: jtojnar advise not to migrate to qmake but instead fix the cmake issue.
Any idea what I can do so I can build my system while this is a WIP?
Install the build from an older version of nixpkgs where the package you want still builds properly. The version in branch should be building properly. For Flakes: For Non-Flake:
Thank you so much!! That section of the wiki described exactly what I was trying to do!
I just posted an upstream PR to fix this:
I've opened with a proper fix if anyone here would like to do some testing (it works for me now)

Steps to reproduce the behavior: Full log: Package built successfully in . Package failed in . I assume package failed to built somewhere in between these two pull request. Please run and paste the result.
Possibly needs update like
tried but had a compilation issue: Error:
Change:
<del> { config, lib, pkgs, ... }: with lib; let cfg = config.hardware.u2f; in { options = { hardware.u2f = { enable = mkOption { type = types.bool; default = false; description = '' Enable U2F hardware support. ''; }; }; }; config = mkIf cfg.enable { services.udev.packages = [ pkgs.libu2f-host ]; }; } </del>

Discussion:
Describe the bug I recently noticed errors in logs around a missing group: To Reproduce Steps to reproduce the behavior: to on a NixOS system built from a recent commit logs with e.g Expected behavior No errors in logs. Additional context I'm not 100% sure what changed to trigger this error or how to best address it, but the config file does refer to a group, which commonly is present on other distros: The group is indeed not present on my NixOS system: The udev config seems to be fetched from the package. Metadata Maintainer information:
I see 2 ways of fixing this: a) just adding the group - this group is used in older Debian/Ubuntu distributions to indicate the device can be mounted using pmount b) removing from udev files as should be enough
A simple nixpkgs search shows there are more modules/packages using the group such as: and upstream packages tarballs used in: In we replace the the group with the group.
Since we don't include that group by default like Debian does, we should probably remove these references to plugdev. Users can always add their own custom udev rules if they want special group handling.
Looking at , seems to be the right way forward for most of these rules. We might just want to patch those to use it, and upstream these patches.
most of the affected udev files already have ; they just include the group for older Debian/Ubuntu distros. This is indeed obsolete method, so fix is indeed just a matter of removing this from the udev files.
According to removing breaks some non-systemd distros where nixpkgs maybe independently installed. What are your thoughts on removing the offending rule via ? Same approach can be taken with other . This would preserve backward compatibility with non NixOS systems.
If I'm not mistaken, this comment is not about nixpkgs on non-systemd distros, but other non-systemd distros in general. As written in , we probably can just ignore the warning for now, and remove the udev rule entirely once a systemd with has landed in nixpkgs.
This should be solved by , PTAL.
Change:
catch_workers_output = "yes"; }; <ins> appStores = { # default apps bundled with pkgs.nextcloudXX, e.g. files, contacts apps = { enabled = true; writable = false; }; # apps installed via cfg.extraApps nix-apps = { enabled = cfg.extraApps != { }; linkTarget = pkgs.linkFarm "nix-apps" (mapAttrsToList (name: path: { inherit name path; }) cfg.extraApps); writable = false; }; # apps installed via the app store. store-apps = { enabled = cfg.appstoreEnable == null || cfg.appstoreEnable; linkTarget = "${cfg.home}/store-apps"; writable = true; }; }; webroot = pkgs.runCommand "${cfg.package.name or "nextcloud"}-with-apps" { } '' mkdir $out ln -sfv "${cfg.package}"/* "$out" ${concatStrings (mapAttrsToList (name: store: optionalString (store.enabled && store?linkTarget) '' if [ -e "$out"/${name} ]; then echo "Didn't expect ${name} already in $out!" exit 1 fi ln -sfTv ${store.linkTarget} "$out"/${name} '') appStores)} ''; </ins> inherit (cfg) datadir; phpPackage = cfg.phpPackage.buildEnv {

Discussion:
The extraApp called displays as blank. This was working fine on nextcloud27. Rest of the site is working fine. Steps to reproduce the behavior: am currently on to webpage is blank on: Firefox Chrome Edge It should display the normal forms page. ! Found non-nixos issue relating to it here: Seems it may be a related issue? <!-- 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:
qtwebengine, kcmutils, kcrash, kdbusaddons, kparts, kwindowsystem, akonadi, grantleetheme, kontactinterface, kpimtextedit, <del> mailcommon, libkdepim, pimcommon </del> <ins> mailcommon, libkdepim, pimcommon, akregator, kaddressbook, kmail, knotes, korganizer, zanshin </ins> }: mkDerivation {

Discussion:
After installing , the interface that shows up is completely Steps to reproduce the behavior: to systemPackages in See the standard Kontact interface will all the apps: ! Actual result ! The "Kontact Suite" promises, , to That means the package should depend on: kmail kaddressbook korganizer akregator Additionally, there's a package that has no executable binary yet seems related to . What is is for? Please run and paste the result.
Possibly related to
Looks like grantleetheme is looking in the wrong directory for resources. The files do exist in . Other package managers would just write the files to the global messageviewer path, but that doesn't work with nix. There must be some way to make grantlee theme look in the right directory.
See and
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
, lib , fetchurl , fetchpatch <ins> , fetchFromGitHub </ins> , copyDesktopItems , makeDesktopItem , desktopToDarwinBundle

Discussion:
is built without clipboard or unicode input support. It prints the following warnings to the console Steps to reproduce the behavior: and observe the CLI output. does not output any warnings and supports clipboard Used mupdf from its last nixpkgs change
It looks like that feature needs the thirdparty freeglut:
Fixed by /
Change:
| ${moreutils}/bin/sponge apps/desktop/src/package-lock.json ''; <del> nodejs = nodejs_18; </del> <ins> nodejs = nodejs_20; </ins> makeCacheWritable = true; <del> npmFlags = [ "--legacy-peer-deps" ]; </del> <ins> npmFlags = [ "--engine-strict" "--legacy-peer-deps" ]; </ins> npmWorkspace = "apps/desktop"; <del> npmDepsHash = "sha256-qkg1psct/ekIXB6QmJX1n/UOKUhYSD9Su7t/b4/4miM="; </del> <ins> npmDepsHash = "sha256-9d9pWrFYelAx/PPDHY3m92Frp8RSQuBqpiOjmWtm/1g="; </ins> cargoDeps = rustPlatform.fetchCargoTarball { name = "${pname}-${version}";

Discussion:
When signing in to the Bitwarden, I am met with the following . I have KDE wallet turned off, and my NixOS and nixpkgs channel are both set to stable. I also have another nix machine that runs NixOS and nixpkgs on unstable and this bug does not occur despite having KDE wallet turned off there as well. Bug is potentially tied to Steps to reproduce the behavior: off KDE wallet in to Bitwarden-desktop stable. Should sign in without issue despite KDE wallet being disabled. ! A package update would be great, as my understanding is this was fixed in an update by Bitwarden devs.
Change:
stdenv.cc.libc ] ++ optionals zlibSupport [ zlib <ins> ] ++ optionals stdenv.isDarwin [ libunwind Security </ins> ]; hardeningDisable = optional stdenv.isi686 "pic";

Discussion:
Describe the bug pypy3 cannot be installed using on macOS. The package fails to build from source. To Reproduce Steps to reproduce the behavior: latest macOS (Catalina 10.15, but same error on previous version) latest (master) to home.packages ( from binary cache does work/does not have this problem) Expected behavior pypy3 package builds successfully (including all needed deps). Output/Errors Error encountered during compilation: Metadata
I am also not sure why from binary cache is not used (for pypy's dependency, it is compiled from source), but that could be my misunderstanding of normal behaviour -- I'm new!
Change:
inherit (electron-unwrapped) version; nativeBuildInputs = [ wrapGAppsHook makeWrapper ]; <ins> buildInputs = [ # needed for GSETTINGS_SCHEMAS_PATH gsettings-desktop-schemas glib gtk3 gtk4 ]; </ins> dontWrapGApps = true; buildCommand = '' <ins> gappsWrapperArgsHook </ins> mkdir -p $out/bin makeWrapper "${electron-unwrapped}/libexec/electron/electron" "$out/bin/electron"  "''${gappsWrapperArgs[@]}" 

Discussion:
In element-desktop, clicking on a picture to open it externally, crashes the application:
The pre-built is using wrapGAppsHook So it should be a ok solution for the source built too.
It already was using that (see ), but the hook did not work properly and additional buildInputs were missing.
Change:
src = yabridge.src; sourceRoot = "source/tools/yabridgectl"; <del> cargoHash = "sha256-f5k5OF+bEzH0b6M14Mdp8t4Qd5dP5Qj2fDsdiG1MkYk="; </del> <ins> cargoHash = "sha256-2x3qB0LbCBUZ4zqKIXPtYdWis+4QANTaJdFvoFbccGE="; </ins> patches = [ # By default, yabridgectl locates libyabridge.so by using

Discussion:
The current version of doesn't build support for the bitbridge that allows for running 32 bit VST plugins. Information on building that is on the . Basically, what's necessary is to make sure that the 32 bit versions of and are installed, and adding a meson flag. It didn't end up being that simple when I tried adding it myself by just adding the 32 bit dependencies to buildInputs and the meson flag; I got a vague error about meson being unable to find boost_filesystem. paging the maintainer of the package:
Attached are my modifications to the current yabridge definition. It is very hacky, but it seems to build... all up until it gets to the part where it links stuff. There, ld fails (see attached error log).
I spent a lot of time trying to get this to work, but I couldn't find any way to specify both the 32bit and 64bit version of boost in a build because of There probably is a hacky way to work around it, but I couldn't find how. I decided to give up on it until is fixed, but I would be happy to accept a workaround if you find one.
It looks like that linking error is the same problem I was running into. The build would only ever pick up either the 32bit boost or the 64bit one, but not both. I couldn't find a way to specify the right one per-architecture. I also thought of trying to combine the 32bit & 64bit builds after building them separately, but the project fails to compile as 32bit, because it makes the assumption that the default build will be 64bit.
Hmm. An idea i haven't tried yet is trying to patch one of the release binaries. Might be a little easier than trying to wrangle meson, at least until that issue gets fixed.
Complete crackpot idea; since the 32 bit stuff that gets built are just binaries that yabridgectl looks for in $PATH (i think), maybe it's possible to just take them from the prebuilt binaries and patch them? I'll try this when i get the chance.

EDIT: this idea was as terrible as it sounds, and the prebuilt binaries only worked through steam-run (presumably because they were compiled with hardcoded FHS paths)
Sorry to leave so many comments in a row, but I got it working and pretty much no ugly hacks too. I'll just paste my definition verbatim. Pretty much all i did was replace with (unsure if necessary, probably is), add the bitbridge flag, and replace all references to with (this was the reason for the linking issues at the end). Then i just a wildcard to the installPhase to get the 32 bit stuff in $out/bin. There are a few lines where I don't know if they're actually necessary; once it worked i stopped testing. I'm also unsure of how to handle referring to pkgsi686Linux, or if there's even a better/more specific way rather than just including pkgsi686Linux as an input. EDIT: I can also open a PR tomorrow if these changes look fine.
Change:
buildPythonPackage rec { pname = "pikepdf"; <del> version = "8.14.0"; </del> <ins> version = "8.15.1"; </ins> pyproject = true; disabled = pythonOlder "3.8";

Discussion:
Steps to reproduce the behavior: pikepdf Looks like this maybe fixed by upgrading to latest pikepdf see (Relaxed dependency requirements on lxml.......) Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I can reproduce the build issue using on these do build currently only 3.11 and 3.12 build in CI, are you able to use newer python ?
unfortunately no, in this case pikepdf happens to be a dependency of another library or program. I'm still trying to figure out which dependency requires pikepdf.
Trying to use to build the but am having issues with anyone have any suggestions on how I can build this locally? I want to try and upgrade the package and .
can you test ?
that appears to work!
should be resolved now
Change:
passthru.optional-dependencies = { compare = [ commonmark markdown mistletoe mistune panflute ]; linkify = [ linkify-it-py ]; <ins> plugins = [ mdit-py-plugins ]; </ins> rtd = [ attrs myst-parser pyyaml sphinx sphinx-copybutton sphinx-design sphinx-book-theme ]; };

Discussion:
Package name: Latest released version: <!-- Search your package here: --- Current version on the unstable channel: 0.37.1 Current version on the stable/release channel: 0.24.1 <!-- 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.
Change:
<ins> <section xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xi="http://www.w3.org/2001/XInclude" version="5.0" xml:id="sec-importing-modules"> <title>Importing Modules</title> <para> Sometimes NixOS modules need to be used in configuration but exist outside of Nixpkgs. These modules can be imported: </para> <programlisting> { config, lib, pkgs, ... }: { imports = [ # Use a locally-available module definition in # ./example-module/default.nix ./example-module ]; services.exampleModule.enable = true; } </programlisting> <para> The environment variable <literal>NIXOS_EXTRA_MODULE_PATH</literal> is an absolute path to a NixOS module that is included alongside the Nixpkgs NixOS modules. Like any NixOS module, this module can import additional modules: </para> <programlisting> # ./module-list/default.nix [ ./example-module1 ./example-module2 ] </programlisting> <programlisting> # ./extra-module/default.nix { imports = import ./module-list.nix; } </programlisting> <programlisting> # NIXOS_EXTRA_MODULE_PATH=/absolute/path/to/extra-module { config, lib, pkgs, ... }: { # No `imports` needed services.exampleModule1.enable = true; } </programlisting> </section> </ins>

Discussion:
references , and sticks the import of the specified file into a list. This means you can only have one extra module inside of . Is this intentional? The name of makes me think it just got messed up at some point. I was expecting to need to supply a path to a file like with a list of modules. This would work if the import wasn't being wrapped in a list, like it originally was:
with a being:
Are you saying that should work? I'm also unable to do more than import a single module, but maybe I'm missing something.
I just look at the code, and the earliest version using the environment variable probably never worked because this would imply getting a list out of an environment variable, which returns a string. The example I gave was just a way to show that if you have a the ability to load a single module, then you can load any number of modules that you want.
Ah, I misunderstood how works. Thanks!
Change:
nextcloud18 = generic { version = "18.0.10"; sha256 = "0kv9mdn36shr98kh27969b8xs7pgczbyjklrfskxy9mph7bbzir6"; <del> insecure = true; </del> <ins> eol = true; </ins> }; nextcloud19 = generic { <del> version = "19.0.4"; sha256 = "0y5fccn61qf9fxjjpqdvhmxr9w5n4dgl1d7wcl2dzjv4bmqi2ms6"; </del> <ins> version = "19.0.6"; sha256 = "sha256-pqqIayE0OyTailtd2zeYi+G1APjv/YHqyO8jCpq7KJg="; extraVulnerabilities = [ "Nextcloud 19 is still supported, but CVE-2020-8259 & CVE-2020-8152 are unfixed!" ]; </ins> }; nextcloud20 = generic { <del> version = "20.0.1"; sha256 = "1z1fzz1i41k4dhdhi005l3gzkvnmmgqqz3rdr374cvk73q7bbiln"; </del> <ins> version = "20.0.3"; sha256 = "sha256-4PZFBNM49k08Z3NX8AEs+LDtDcQuwI+Vi23E/3Dt8XU="; </ins> }; }

Discussion:
, CVSSv3=8.1 (nixos-20.09, nixos-unstable) CVSSv3=4.4 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc Cc Cc Cc Cc
Upstream gives the following advisory: If there will be no patch for 19.x I think it would be best to mark as in both 20.09 and unstable.
I feed a bit uneasy about Nextcloud's product update policy but this is nothing NixOS can change
So, it's not very clear to me where the issue got fixed: e.g. states that the issue is in , however there were a few releases after it. As I don't really get where the issue got fixed, I can't just check if the relevant patches got backported. Also, the recommendation to upgrade to v20 seems a bit weird to me since their states that v19 is supposed to be supported until June 2021. I guess, I'll just contact their support and ask about that. After that I'd file an update PR here :)
OK, apparently I'm not the only one who was a bit confused by their way of handling these issues: :D Will file an update PR now. Since is rated as "High" (in contrast to their website where the impact is rated as "Low") and I just checked that the affected encryption feature actually works on NixOS, I guess I'll mark v19 as insecure.
Change:
alan_2 = callPackage ../development/compilers/alan/2.nix { }; <ins> alarm-clock-applet = callPackage ../tools/misc/alarm-clock-applet { }; </ins> algol68g = callPackage ../development/compilers/algol68g { }; ante = callPackage ../development/compilers/ante { };

Discussion:
the package alarm clock applet has been removed via for reasons of being unmaintained and using components of the deprecated gnome2 stack. however the package has a new maintainer a of january 2023. and it has been ported to Gtk 3 this information and the code can be found on https://alarm-clock- the source-distribution goes under the name now. it is to be discussed wheter the new nix derivation should match that new name or keep the old name <!-- Describe the project a little: --Metadata homepage URL: https://alarm-clock- source URL: license: gpl2+ platforms: unix, linux, darwin, ...
Change:
astyle = callPackage ../development/tools/misc/astyle { }; <ins> automaticcomponenttoolkit = callPackage ../development/tools/misc/automaticcomponenttoolkit { }; </ins> awf = callPackage ../development/tools/misc/awf { }; aws-adfs = with python3Packages; toPythonApplication aws-adfs;

Discussion:
, CVSSv3=8.1 (nixos-unstable) Scanned versions: nixos-unstable: . Cc
Change:
<ins> # run the tests with nixt <absolutePath to parent dir> -v { pkgs ? import <nixpkgs> { }, nixt }: let inherit (import ./update-utils.nix { inherit (pkgs) lib; }) extractLatestVersionFromHtml extractSha256FromHtml getLatestStableVersion; in nixt.mkSuite "LibreOffice Updater" { "should extract latest stable version from html" = let latestVersionHtmlMock = '' <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Index of /libreoffice/stable</title> <link rel="stylesheet" href="/mirrorbrain.css" type="text/css" /> </head> <body> <h1>Index of /libreoffice/stable</h1> <table><tr><th>&nbsp;</th><th><a href="?C=N;O=D">Name</a></th><th><a href="?C=M;O=A">Last modified</a></th><th><a href="?C=S;O=A">Size</a></th><th>Metadata</th></tr><tr><th colspan="5"><hr /></th></tr> <tr><td valign="top">&nbsp;</td><td><a href="/libreoffice/">Parent Directory</a></td><td>&nbsp;</td><td align="right">  - </td><td>&nbsp;</td></tr> <tr><td valign="top">&nbsp;</td><td><a href="7.2.7/">7.2.7/</a></td><td align="right">10-Mar-2022 11:12  </td><td align="right">  - </td><td>&nbsp;</td></tr> <tr><td valign="top">&nbsp;</td><td><a href="7.3.3/">7.3.3/</a></td><td align="right">12-May-2022 10:06  </td><td align="right">  - </td><td>&nbsp;</td></tr> <tr><td valign="top">&nbsp;</td><td><a href="7.2.6/">7.2.6/</a></td><td align="right">05-May-2022 07:57  </td><td align="right">  - </td><td>&nbsp;</td></tr> <tr><th colspan="5"><hr /></th></tr> </table> <address>Apache Server at <a href="mailto:hostmaster@documentfoundation.org">download.documentfoundation.org</a> Port 80</address> <br/><address><a href="http://mirrorbrain.org/">MirrorBrain</a> powered by <a href="http://httpd.apache.org/">Apache</a></address> </body></html> ''; actual = extractLatestVersionFromHtml latestVersionHtmlMock; in "7.3.3" == actual; "should extract latest stable version from website" = (builtins.compareVersions getLatestStableVersion "7.3.3") >= 0; "should extract sha256 from html" = let sha256Html = "50ed3deb8d9c987516e2687ebb865bca15486c69da79f1b6d74381e43f2ec863  LibreOffice_7.3.3_MacOS_aarch64.dmgn"; actual = extractSha256FromHtml sha256Html; in "50ed3deb8d9c987516e2687ebb865bca15486c69da79f1b6d74381e43f2ec863" == actual; } </ins>

Discussion:
Apparently the DMG download is 404'ing - see below. Perhaps a different mirror should be used:
Apparently they remove older versions. Maintainer:
Maybe we can use to avoid 404's.
Good input. I'll update the version and have a look at it tomorrow.
is 404'ing again: . Should we re-open this issue?
I can't see version 7.2.5 in any supported nixpkgs branch anymore. If you're using an old commit, you'll be getting old bugs, of course.
Change:
hash = "sha256-3YvQAqN5tdSZ37BQ3R+pr4Ap6ARh9LtsUjxJlz9aOfM="; }; <del> extraPatches = let url = "https://raw.githubusercontent.com/freebsd/freebsd-ports/402562e2559e198c6660171dec58e7a25cc14ec2/security/openssh-portable/files/extra-patch-hpn"; in </del> <ins> extraPatches = let url = "https://raw.githubusercontent.com/freebsd/freebsd-ports/7ba88c964b6e5724eec462021d984da3989e6a08/security/openssh-portable/files/extra-patch-hpn"; in </ins> [ ./ssh-keysign-8.5.patch

Discussion:
After that upgraded openssh to 9.8p1, variant is broken on M1 darwin. Run: it results in the following error during build: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Adding to fixes the issue for me, I'm now trying to figure out why it only shows up on darwin-aarch64.
Seems that 9.7p1-9.8p1 change removed the include directive: -- so it's not clear to me why this succeeds on linux/FreeBSD and fails on darwin.
I'm now trying to fix this upstream, in freebsd ports, where we pull hpn patches from.