jiebi/CodeConvo huggingface dataset:
Change:
precice-config-visualizer = callPackage ../tools/misc/precice-config-visualizer { }; <ins> proxmox-backup-client = callPackage ../applications/backup/proxmox-backup-client { }; </ins> pueue = callPackage ../applications/misc/pueue { inherit (darwin.apple_sdk.frameworks) SystemConfiguration; };

Discussion:
Project description Client for proxmox backup server written in Rust. Metadata homepage URL: source URL: ;a=summary license: aGPLv3. platforms: unix, linux
It would also be nice if some sort of service that backups certain folders on a CRON timer to the server. Like:
I have built a derivation for in 2020 (but currently only at version ) that I'm using on some machines and my phone (via nix-on-droid). I'll see if I can update that derivation to the latest release and clean it up for inclusion in nixpkgs.
any updates?
Hello, I packaged 2.2.1:
I moved this version to PR, thanks.
Change:
echo SUPPORTED-LOCALES='${toString locales}' > ../glibc-2*/localedata/SUPPORTED ''; <del> enableParallelBuilding = true; </del> <ins> # Current `nixpkgs` way of building locales is not compatible with # parallel install. `locale-archive` is updated in parallel with # multiple `localedef` processes and causes non-deterministic result: #   https://github.com/NixOS/nixpkgs/issues/245360 enableParallelBuilding = false; </ins> makeFlags = (previousAttrs.makeFlags or []) ++ [ "localedata/install-locales"

Discussion:
Building this package twice does not produce the bit-by-bit identical result each time, making it harder to detect CI breaches. You can read more about this at https://reproducible- . Fixing bit-by-bit reproducibility also has additional advantages, such as avoiding hard-to-reproduce bugs, making content-addressed storage more effective and reducing rebuilds in such systems. You can use to analyze the differences in the output of the two builds. To view the build log of the build that produced the artifact in the binary cache: according to , "A locale archive is a memory-mapped file which contains all the system-provided locales" - oh great
AFAIU locale generation consists of roughly 2 steps: building of individual locales with calls ( macro in 's ) merge into [1.] Should not depend on the order of excution (but might depend on the environment?) [2.] Should not either as it's ran after complete (but might depend on file list on disk?) I hope for a simple bug somewhere in .
Adding a bit of logging: here are the commands used to populate locale archive: It's a bit worrying that flag is not passed there. It probably means we do update in multiple processes.
Proposed disabling ot parallel locale building for now as:
Gentoo for example uses the following: for parallel phase for sequential phase Would be nice if upstream glibc did it for us.
I am totally unsurprised... glibc is full of these kinds of things... unnecessary use of advanced OS features without forethought for the grief they might cause.
I wonder if it's worth us packaging this and using it.
A fix reached master.
Change:
stdenvNoCC.mkDerivation (finalAttrs: { pname = "dbeaver-bin"; <del> version = "24.1.2"; </del> <ins> version = "24.1.3"; </ins> src = let

Discussion:
Package name: dbeaver-bin Latest released version: 24.1.3 <!-- Search your package here: --- Current version on the unstable channel: 24.1.2 Current version on the stable/release channel: 24.0.5 <!-- 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:
inherit (stdenv) buildPlatform hostPlatform; inherit (stdenv.lib) fix' extends makeOverridable; <del> inherit (haskellLib) overrideCabal; </del> <ins> inherit (haskellLib) overrideCabal getHaskellBuildInputs; </ins> mkDerivationImpl = pkgs.callPackage ./generic-builder.nix { inherit stdenv;

Discussion:
system: host os: multi-user?: sandbox: version: channels(luigy): nixpkgs:
cc
Change:
<ins> { lib, buildPythonPackage, fetchFromGitHub, pytestCheckHook, pythonOlder, attrs, boto3, cachetools, color-operations, hatchling, httpx, morecantile, numexpr, numpy, pydantic, pystac, rasterio, rioxarray, }: buildPythonPackage rec { pname = "rio-tiler"; version = "6.6.1"; pyproject = true; disabled = pythonOlder "3.8"; src = fetchFromGitHub { owner = "cogeotiff"; repo = "rio-tiler"; rev = version; hash = "sha256-MR6kyoGM3uXt6JiIEfGcsmTmxqlLxUF9Wn+CFuK5LtQ="; }; build-system = [ hatchling ]; propagatedBuildInputs = [ attrs cachetools color-operations httpx morecantile numexpr numpy pydantic pystac rasterio ]; nativeCheckInputs = [ boto3 pytestCheckHook rioxarray ]; pythonImportsCheck = [ "rio_tiler" ]; meta = with lib; { description = "User friendly Rasterio plugin to read raster datasets"; homepage = "https://cogeotiff.github.io/rio-tiler/"; license = licenses.bsd3; maintainers = lib.teams.geospatial.members; }; } </ins>

Discussion:
Project description User friendly Rasterio plugin to read raster datasets. Metadata homepage URL: source URL: license: bsd platforms: unix Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Already packaged by in . Should be easy to add to nixpkgs.
Requires morecantile and pystac, that shoud be to nixpkgs as well.
Change:
"--with-libsoup=yes" ]; <del> patches = [ ./PppdPath.patch ]; </del> <ins> patches = [ ./PppdPath.patch (fetchpatch { sha256 = "1n90j5rwg97xkrhlldyr92filc2dmycl9pr0svky9hlcn9csk2z6"; name = "null-dereference.patch"; url = "https://github.com/NetworkManager/NetworkManager/commit/4e8eddd100bbc8429806a70620c90b72cfd29cb1.patch"; }) ]; </ins> buildInputs = [ systemd libgudev libnl libuuid polkit ppp libndp <del> bluez5 dnsmasq gobjectIntrospection modemmanager readline newt libsoup ]; </del> <ins> bluez5 dnsmasq gobjectIntrospection modemmanager readline newt libsoup jansson ]; </ins> <del> propagatedBuildInputs = [ dbus_glib gnutls libgcrypt ]; </del> <ins> propagatedBuildInputs = [ dbus_glib gnutls libgcrypt python3Packages.pygobject3 ]; </ins> <del> nativeBuildInputs = [ intltool pkgconfig ]; </del> <ins> nativeBuildInputs = [ intltool pkgconfig libxslt docbook_xsl ]; </ins> preInstall = '' installFlagsArray=( "sysconfdir=$out/etc" "localstatedir=$out/var" "runstatedir=$out/var/run" )

Discussion:
After nixos-rebuild switch, the network-manager service goes down and immediately segfaults every time it tries to come up again. journalctl for the segfault message or something, anyway, at this point I don't have working network anymore. nixos 17.09pre104870.
Specifically it segfaults because returns a non-zero exit status (saying "No for interface NetworkManager"); the segfault itself appears fixes in their HEAD. I haven't checked whether that makes it actually work, yet, but maybe we could arrange for it to have a in the meantime, whatever that means.
In which commit it was fixed?
Does this also happen in 17.03?
Happens with both the 17.03 tag and the 17.03 channel. Looks like cherry-picking the above commit as a patch for our network-manager lets it work correctly, btw.
also fixed in 17.03:
Change:
<ins> diff --git a/vpn/openvpn/openvpnadvancedwidget.cpp b/vpn/openvpn/openvpnadvancedwidget.cpp index 1dea8142..c8013e22 100644 --- a/vpn/openvpn/openvpnadvancedwidget.cpp +++ b/vpn/openvpn/openvpnadvancedwidget.cpp @@ -72,7 +72,7 @@ OpenVpnAdvancedWidget::OpenVpnAdvancedWidget(const NetworkManager::VpnSetting::P connect(m_ui->cmbProxyType, static_cast<void (QComboBox::*)(int)>(&QComboBox::currentIndexChanged), this, &OpenVpnAdvancedWidget::proxyTypeChanged); // start openVPN process and get its cipher list -    const QString openVpnBinary = QStandardPaths::findExecutable("openvpn", QStringList() << "/sbin" << "/usr/sbin"); +    const QString openVpnBinary = "@openvpn@/bin/openvpn"; const QStringList args(QLatin1String("--show-ciphers")); d->openvpnProcess = new KProcess(this); </ins>

Discussion:
I am unable to configure the Cipher field of an openvpn connection in networkmanager. The dropdown is greyed out, with the text "OpenVPN cipher lookup failed". This causes problems because OpenVPN defaults to a very weak cipher (BF-CBC) that most modern vpn servers reject. On a system with set and plasma5 installed, use to create an openvpn connection. On the VPN tab of the connection editor, click Advanced..., and then click on the Security tab in the Advanced OpenVPN Properties window that pops up. The top item should read Cipher: and the dropdown will be greyed out with the error message mentioned above. ! System: NixOS 17.03 at Nix version: 1.11.8 Nixpkgs version:
temporary workaround: use to manually edit the property and add to it
Change:
owner = "chroma-core"; repo = "chroma"; rev = "refs/tags/${version}"; <del> hash = "sha256-wzfzuWuNqLAjfAZC38p1iTtJHez/pJ9Ncgeo23o1dMo="; </del> <ins> hash = "sha256-e6ZctUFeq9hHXWaxGdVTiqFpwaU7A+EKn2EdQPI7DHE="; </ins> }; cargoDeps = rustPlatform.fetchCargoTarball { inherit src; name = "${pname}-${version}"; <del> hash = "sha256-0OE2i29oE6RpJRswQWI8+5dbA6lOWd3nhqe1RGlnjhk="; </del> <ins> hash = "sha256-3FmnQEpknYNzI3WlQ3kc8qa4LFcn1zpxKDbkATU7/48="; </ins> }; pythonRelaxDeps = [

Discussion:
Steps to reproduce the behavior: the chromadb python package for python310. [1/7/9 built] building python3.10-chromadb-0.5.0 (pytestCheckPhase): chromadb/test/auth/testbasicauth[1/7/9 built] building python3.10-chromadb-0.5.0 (pytestCheckPhase): chromadb/test/aut[1/7/9 built] building python3.10-chromadb-0.5.0 (pytestCheckPhase): ... [ 4%] [1/7/9 built] building python3.10-chromadb-0.5.0 (pytestCheckPhase): ... [ 4%] [1/7/9 built] building python3.10-chromadb-0.5.0 (pytestCheckPhase): ... [ 4%] This is not the complete log but it is all that is visible in my terminal since only keeps the latest however many lines. The build reaches this test at 4% every time and then stalls there. I was able to fix the issue by adding an overlay to disable pytestCheckPhase, but this is obviously a workaround. <!-- 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 are flaky. I will ship an update later.
Change:
<ins> { lib , stdenv , fetchFromRepoOrCz , cmake , libGL , libpng , pkg-config , zlib }: stdenv.mkDerivation rec { pname = "glpng"; version = "1.46"; src = fetchFromRepoOrCz { repo = "glpng"; rev = "v${version}"; hash = "sha256-C7EHaBN0PE/HJB6zcIaYU63+o7/MEz4WU1xr/kIOanM="; }; nativeBuildInputs = [ cmake pkg-config ]; buildInputs = [ libGL libpng zlib ]; meta = with lib; { homepage = "https://repo.or.cz/glpng.git/blob_plain/HEAD:/glpng.htm"; description = "PNG loader for OpenGL"; license = licenses.mit; maintainers = with maintainers; [ AndersonTorres ]; platforms = platforms.unix; }; } </ins>

Discussion:
Project description This package is available in the Gentoo package repository: ; (the ebuild isn't for the latest released version, tho) Metadata homepage URL: http://chromium- source URL: gentoo url, nixos has an equivalent to the sourceforge mirrors, but I don't know how to translate it. see also: license: (according to gentoo) , (according to project homepage) platforms: unix. requires OpenGL
Please do the honors,
Change:
<ins> --- a/src/main.c	2021-02-09 13:54:32.847364236 +0100 +++ b/src/main.c	2021-02-09 10:41:51.541203271 +0100 @@ -1350,6 +1351,7 @@ vfs_file_monitor_clean(); return 1; } +            gdk_set_allowed_backends("x11"); gtk_init (&argc, &argv); int ret = custom_dialog_init( argc, argv ); if ( ret != 0 ) </ins>

Discussion:
Describe the bug spacefm segfaults on start with the following output: invoke spacefm on the command line Expected behavior an up and running GUI program Screenshots see error message above Additional context I noticed that there is no It makes no difference whether spacefm is installed via nix-env or Notify maintainers Metadata** $ nix-shell -p nix-info --run "nix-info -m" system: host os: multi-user?: sandbox: version: channels(root): channels(oo): nixpkgs:
I bisected this crash down to Perhaps the package needs to be updated to support the newer version of gtk3?
Hi. I cannot reproduce the crash with (current master). How about you?
Yep, that same binary segfaults for me. I'm on
still crashing with the same error message. Then out of curiosity I ran . The backtrace of the main thread has: 0x0000000000000000 in ?? () 0x00007fa6931c3ceb in ghashtablelookup () from /nix/store/hnk0s558k2h4v8abjzagagflvw1l0cb2-glib-2.66.4/lib/libglib- 0x00007fa69375c50c in gdkx11windowlookupfordisplay () from /nix/store/8pidhwid3ww58wlq705irf48c01dr0hv-gtk+3-3.24.24/lib/libgdk-3.so.0 0x0000000000499915 in getdesktopindex (win=win at main-window.c:4179 0x000000000049bfd1 in fmmainwindowgetoncurrentdesktop () at main-window.c:4225 0x0000000000496343 in handleparsedcommandlineargs () at main.c:1143 0x0000000000421808 in main (argc=<optimized out, argv=<optimized out) at main.c:1526 and now I am wondering about as I am running Wayland and sway. I don't know if it's relevant though.
Does it help if you run spacefm with the environment variable set? BTW, I am using X11.
Seems this a known bug:
GDKBACKEND=wayland does not help.

Found an even older bug report from 2015: Question: this is an upstream known bug. Should I close this issue? (I don't know what the protocol is in this case)
I am not sure. Maybe we can at least improve something here? Change the description to call out that this does not work with wayland for example? Patch it that it fails gracefully with an explanatory message when not run under X11? Then, it seems the project is also not really maintained anymore. Maybe it's time to let it go?
Another idea: a wayland display driver (is this the right wording?) should fall back to x11 support via xwayland if an application cannot run under wayland natively. SpaceFM is a x11 only application, could you try to use and see if it makes a difference?
it actually runs with GDK_BACKEND=x11! Thanks for the suggestion.
I have created a PR to make x11 the only backend that is used.
Change:
''; qemuConfigFile = pkgs.writeText "qemu.conf" '' ${optionalString cfg.qemuOvmf '' <del> nvram = ["${pkgs.OVMF}/FV/OVMF_CODE.fd:${pkgs.OVMF}/FV/OVMF_VARS.fd"] </del> <ins> nvram = ["${pkgs.OVMF.fd}/FV/OVMF_CODE.fd:${pkgs.OVMF.fd}/FV/OVMF_VARS.fd"] </ins> ''} ${cfg.qemuVerbatimConfig} '';

Discussion:
In , I introduced support in libvirtd for UEFI VM creation. rightfully remarked that this brings closure-size up too much. Looking into OVMF shows that only 1MB out of the 114MB install size is needed to enable said UEFI VM creation. I think that we should look into splitting out OVMF_(CODE|VARS) from the rest package.
Change:
stdenv.mkDerivation rec { name    = "monero-${version}"; <del> version = "0.12.3.0"; </del> <ins> version = "0.13.0.2"; </ins> src = fetchgit { url    = "https://github.com/monero-project/monero.git"; rev    = "v${version}"; <del> sha256 = "1609k1qn9xx37a92ai36rajds9cmdjlkqyka95hks5xjr3l5ca8i"; </del> <ins> sha256 = "078iw76ajvaj08rgnx3c13pnq8fxah1z9wwyz54fcnj2349sjbf5"; </ins> }; nativeBuildInputs = [ cmake pkgconfig git ];

Discussion:
Monero is hardforking and changing the proof of work. xmr-stak must be upgraded to v2.5.0 before the 18th of Oct (Thu), or it will stop working Thanks
Thanks & .. When can we expect this to land ? Thanks
It should be ready to merge already.
Change:
nativeCheckInputs = [ pytestCheckHook ]; <ins> disabledTests = [ # The binary file samples/contrib/issue-1004-indirect-mediabox.pdf is # stripped from fix-dereference-MediaBox.patch. "test_contrib_issue_1004_mediabox" ]; </ins> passthru = { tests = { inherit ocrmypdf;

Discussion:
Steps to reproduce the behavior: . the following errors: This is due to a bug in pdfminer-six. With its six-month release cycle, its downstream derivations will continue to fail for a long time. See There is a patch available at For : For : cc: relative to jupyter-lab <!-- 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]:
Verified -- the patch worked!
Change:
owner = "hashicorp"; repo = pname; inherit rev; <del> sha256 = "0i9104anf3qaydm1izlwrzvpzizd6p1zy651hsynscnnxa56cmyk"; </del> <ins> sha256 = "0jg7h52wlgd2aslx13fs97j3b8g5xfgil3p2jsc4j95l7lmqn7bv"; </ins> }; # ui:

Discussion:
When building chromium through nixos-rebuild off of the latest nixpkgs master: Not sure what changed, I don't see any recent updates to heimdal or pthreads, but I may have missed something.
I updated nixpkgs and this issue seemed to disappear. I'll reopen if I encounter this again.
I got this today on master ():
Ah, I see (I assume because of patch dependencies). Testing with that commit reverted now.
It worked. Pushed to master.

it's supposed to be reachable via , from within emacs, but it is not. However, the program can find it, when run as
I misunderstood some emacs-related things. I'm not sure if the situation is perfect or not, but at least the manual I want is available at

We seem to have unpatched vulnerabilities (noticed by nixpkgs monitor):
The first one was explicitly claimed to be fixed in 2.21 NEWS, although the CVE entry claims that version still suffers from it.

Here's the error message: Here's the full log:
cc
My installation command was wrong. I had when I should have had
Change:
'${userPassword}' ) <del> driver.find_element(By.XPATH, "//button[contains(., 'Create Account')]").click() </del> <ins> driver.find_element(By.XPATH, "//button[contains(., 'Create account')]").click() </ins> <del> wait.until_not(EC.title_contains("Create Account")) </del> <ins> wait.until_not(EC.title_contains("Create account")) driver.find_element(By.XPATH, "//button[contains(., 'Continue')]").click() </ins> driver.find_element(By.CSS_SELECTOR, 'input#login_input_master-password').send_keys( '${userPassword}' ) <del> driver.find_element(By.XPATH, "//button[contains(., 'Log In')]").click() </del> <ins> driver.find_element(By.XPATH, "//button[contains(., 'Log in')]").click() </ins> <del> wait.until(EC.title_contains("Bitwarden Web Vault")) </del> <ins> wait.until(EC.title_contains("Vaultwarden Web Vault")) </ins> <del> driver.find_element(By.XPATH, "//button[contains(., 'Add Item')]").click() </del> <ins> driver.find_element(By.XPATH, "//button[contains(., 'Add item')]").click() </ins> driver.find_element(By.CSS_SELECTOR, 'input#name').send_keys( 'secrets'

Discussion:
Package name: VaultWarden Latest released version: 1.27.0 Current version on the unstable channel: 1.27.0 Current version on the stable/release channel: 1.26.0 The currently packaged version of VaultWarden in 22.11 is out of date enough as to be incompatible with officially released BitWarden clients. As I understand it, the latest release has no drawbacks and is server backwards compatible but is compatible with the latest clients. Given that the expectation of the stable channel is to be inter-compatible with the world generally, I would expect the most currently compatible server to be present there. That is not the case presently. I think we should simply backport 1.27.0 from unstable to 22.11. Notify maintainers Note for maintainers: Please tag this issue in your PR.
Change:
<ins> { lib, buildPythonPackage, fetchPypi }: buildPythonPackage rec { pname = "pycotap"; version = "1.2.2"; src = fetchPypi { inherit pname version; sha256 = "sha256-+Tjs1JMczRnZWY+2M9Xqu3k48IuEcXMV5SUmqmJ3yew="; }; meta = with lib; { description = "Test runner for unittest that outputs TAP results to stdout"; homepage = "https://el-tramo.be/pycotap"; license = licenses.mit; maintainers = with maintainers; [ mwolfe ]; }; } </ins>

Discussion:
The package PySolFC is broken: It does not even start but throws an exception. Looks like noone has ever tested this. :( -shell -p pysolfc .py Traceback (most recent call last): File "/nix/store/y3xs17qmzs898jyjcbp9vbcj2kkjqhgz-PySolFC-", line 37, in <modulefrom import main # noqa: E402,I202 File "/nix/store/y3xs17qmzs898jyjcbp9vbcj2kkjqhgz-PySolFC-2.6.4/lib/python3.9/site-", line 30, in <modulefrom import Application File "/nix/store/y3xs17qmzs898jyjcbp9vbcj2kkjqhgz-PySolFC-2.6.4/lib/python3.9/site-", line 31, in <modulefrom import GAMEDB, GI, loadGame File "/nix/store/y3xs17qmzs898jyjcbp9vbcj2kkjqhgz-PySolFC-2.6.4/lib/python3.9/site-", line 28, in <modulefrom pysollib.mfxutil import Struct, printerr File "/nix/store/y3xs17qmzs898jyjcbp9vbcj2kkjqhgz-PySolFC-2.6.4/lib/python3.9/site-", line 146, in <moduleuclock = AttributeError: module 'time' has no attribute 'clock'
Just ran into this as well. Looks like was removed in Python 3.8, but also the version of PySolFC in is three and a half years (and ten minor versions) old so decent chance bumping the package version takes care of it
Change:
] null; release."2.8".sha256 = "sha256-cyK88uzorRfjapNQ6XgQEmlbWnDsiyLve5po1VG52q0="; releaseRev = v: "v${v}"; <ins> extraBuildInputs = [ ITree ]; </ins> propagatedBuildInputs = [ compcert ]; <del> preConfigure = "patchShebangs util"; </del> <ins> preConfigure = '' patchShebangs util substituteInPlace Makefile  --replace 'FLOYD_FILES=' 'FLOYD_FILES= ${toString extra_floyd_files}' ''; </ins> makeFlags = [ "BITSIZE=64"

Discussion:
VST doesn't seem to compile files like in the folder, so the user cannot use it. I have a WIP that tries to resolve this with but it still doesn't seem to help, see The user should be able to import and use from VST.
Are you sure about the expected behavior? Reading the I cannot find any reference to the module.
See how they use wildcards to check if the submodules have been cloned
the problem seems to be that there are missing dependencies so its unable to compile them. i will submit a pr once i figure it out
Sorry but i couldn't fix it here's what i last tested it might have something to do with LoadPaths <details</details
do you have an idea? It looks like is not being compiled.
See proposed
Change:
lld_19 lldb_19 llvm_19 <ins> bolt_19 </ins> llvmPackages_git; lorri = callPackage ../tools/misc/lorri {

Discussion:
This project should be part of the , but it's missing. BOLT is a post-link optimizer developed to speed up large applications. It achieves the improvements by optimizing application's code layout based on execution profile gathered by sampling profiler, such as Linux perf tool. An overview of the ideas implemented in BOLT along with a discussion of its potential and current results is available in . Metadata homepage URL: source URL: license: Apache License v2.0 with LLVM Exceptions platforms: unix, linux, darwin.
OK I managed to build this on NixOS, but with tons of patches. I think the upstream bolt is not ready for separate compilation yet, so I need to copy a bunch of stuff from elsewhere, but here is the build: the patch: <details</detailsThe patch is really ugly and there are some things that are specific to NixOS (I integrated the in other llvm packages). Not sure if we want to try to get the changes upstreamed before opening a PR. The build is successful, but I haven't yet tested it. Patching this is quite painful and consumed me 4 hours already...
it seems that it works directly without the need for wrapping.
The upstream patch which makes packaging bolt possible in Nix has been merged. We'll have things here merged in not too long from now.