jiebi/CodeConvo huggingface dataset:
Change:
buildPythonPackage rec { pname = "zope-deferredimport"; <del> version = "4.3"; </del> <ins> version = "4.3.1"; </ins> src = fetchPypi { pname = "zope.deferredimport"; inherit version; <del> sha256 = "2ddef5a7ecfff132a2dd796253366ecf9748a446e30f1a0b3a636aec9d9c05c5"; </del> <ins> sha256 = "57b2345e7b5eef47efcd4f634ff16c93e4265de3dcf325afc7315ade48d909e1"; </ins> }; propagatedBuildInputs = [ zope_proxy ];

Discussion:
Upgrading fails, seemingly because the existing systemd version is newer in 21.11 than unstable. Steps to reproduce the behavior: NixOS 21.11 21.11 channel, add unstable channel NixOS upgrades from 21.11 to unstable. is the commit upgrading systemd to 249.7, cherry picks it to 21.11. Adding the flag to the invocation would also solve this issue, albeit leaving the newer EFI files in place. <!-- 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.
I think the corresponding PR is
As pointed out above by this will be fixed when staging-next gets merged ().
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
</listitem> <listitem> <para> <ins> <link xlink:href="https://www.getoutline.com/">Outline</link>, a wiki and knowledge base similar to Notion. Available as <link linkend="opt-services.outline.enable">services.outline</link>. </para> </listitem> <listitem> <para> </ins> <link xlink:href="https://github.com/aiberia/persistent-evdev">persistent-evdev</link>, a daemon to add virtual proxy devices that mirror a physical input device but persist even if the underlying hardware is

Discussion:
Project description Outline is a modern web application for creating documentation, kind of a Wiki. Metadata homepage URL: source URL: license: Custom platforms: linux
I marked this as stale due to inactivity. &rarr;
Closing in favor of

Project description Team wiki, documentation, meeting notes, playbooks, onboarding, work logs, brainstorming, & more… Metadata homepage URL: source URL: license: Business Source License 1.1 platforms: unix
I marked this as stale due to inactivity. &rarr;
Change:
# Add a ‘qemu-kvm’ wrapper for compatibility/convenience. postInstall = '' <ins> ln -s $out/libexec/virtiofsd $out/bin </ins> ln -s $out/bin/qemu-system-${stdenv.hostPlatform.qemuArch} $out/bin/qemu-kvm '';

Discussion:
Describe the bug libvirt can't find I'm unsure how to reference virtiofsd via libvirt xml without it being garbage collected. I'm currently hard coding nix store: Expected behavior A consistent reference to virtiofsd either via a link in or putting it on the $PATH. Additional context Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
It's not perfect, but adding the following snippet to does the trick for me. I have the following line in my virtual machine XML to make use of it:
I marked this as stale due to inactivity. &rarr;
Still important to me.
Sorry about the spam, I had to push to my fork in order to test it and I managed to have this crappy typo that I missed for a while.. Anyway, that PR should fix it.
That's what and are for. To have stable links in xml files which survive upgrades of and , hibernation of guests, reboots of host, GCs and all of those interleaved. Maintaining through all XML's seems ugly
Change:
''; }; <del> pruneFS = mkOption { type = listOf str; </del> <ins> pruneFS = lib.mkOption { type = lib.types.listOf lib.types.str; </ins> default = [ "afs" "anon_inodefs"

Discussion:
Using more-or-less the default configuration for (with ), the list of results is printed twice whenever running . For example: Steps to reproduce the behavior: the module like so: the job with some file name that exists on the system Matching files should each be printed once. The issue is fixed if I unset the environment variable. plocate deliberately reads from both and the hard coded default path, even if they are the same: The comment claims that this is also the behavior of mlocate, but I do not have an mlocate database installed and haven't wanted to change my running system to use mlocate. It looks like recently started being set in NixOS in . Please run and paste the result.
Sounds to me like an upstream issue. Can you write a mail to the upstream maintainer? ;a=blob;f=README;h=;hb=HEAD#l40
Sure, I have done so. I'll follow up when I get a response.
The plocate maintainer says they do not consider this to be a bug in plocate, and is intentional behavior. Rather than setting the environment variable, could we just make a wrapper script for that uses the NixOS-configured dbpath, if we don't want to re-build itself when the path is changed?
I would be personally fine to just drop support for a custom place for the db. If people really want to have it somewhere else they could symlink it. Then we don't need a wrapper or to worry about the env.
I can confirm the behaviour with .
Could we just take out the variable setting? It isn't needed for or , and just causes this annoying behaviour. If it's needed for , maybe the setting could be made conditional. It would be nice to get something done about it sooner rather than later. This issue has been open for 4 months now.
Please take a look at
I've reviewed the PR and it LGTM. Thanks for doing this! It will be great to have this fixed.
Change:
, zlib }: <ins> let zig_0_10_0 = fetchFromGitHub { owner = "ziglang"; repo = "zig"; rev = "0.10.0"; hash = "sha256-DNs937N7PLQimuM2anya4npYXcj6cyH+dRS7AiOX7tw="; }; in </ins> stdenv.mkDerivation rec { pname = "zig"; version = "0.9.1";

Discussion:
I'm trying to install ncdu on darwin, which depends on zig; it has started failing to build in recent nixpkgs on the 22.11 track, though. Steps to reproduce the behavior: zig installs cleanly. <details<summaryoutput of nix log</summary<p</p</details Please run and paste the result.

Steps to reproduce the behavior: ncdu Please run and paste the result. `
Try adding ncurses to buildInputs for darwin.
It's already there - just not picked up for some reason. (I may have time to look at it soon, but was hoping to interest someone in the meantime :) )
ncdu is still broken in 22.11 on darwin
Change:
mkdir -p "$out/lib/udev/rules.d" <del> # Patch MathInstaller's shebangs and udev rules dir patchShebangs MathInstaller substituteInPlace MathInstaller  </del> <ins> # Set name of installer file if [ -f "MathInstaller" ]; then INSTALLER="MathInstaller" else INSTALLER="WolframInstaller" fi # Patch Installer's shebangs and udev rules dir patchShebangs $INSTALLER substituteInPlace $INSTALLER  </ins> --replace /etc/udev/rules.d $out/lib/udev/rules.d # Remove PATH restriction, root and avahi daemon checks, and hostname call

Discussion:
(Note: this may be a somewhat more complex upgrade, as Wolfram has moved to using the Wolfram Installer for everything. Not sure if that'll affect the actual package, though.) Package name: mathematica Latest released version: 14.1.0 <!-- Search your package here: --- Current version on the unstable channel: 14.0.0 Current version on the stable/release channel: 14.1.0 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers Note for maintainers: Please tag this issue in your PR.
Also, I'm not currently able to find a link with the old installer for 14.0.0. Wolfram may have taken it down, making it seemingly impossible to install this package right now. If anyone knows an archive of it, please let me know.
Found a direct link: If you're signed into your wolfram account, this will work. This works for using mathematica until the package update.
I will take a look at this later in October. I apologize for the delay.
Change:
{ stdenv , buildPythonPackage , fetchPypi <del> , docutils , virtualenv </del> , webtest , zope_component , hupper

Discussion:
Describe the bug As of now the pyramid package depends on the package which is originally on the section of the package definition: This brings in a big chunk of dependencies that are on the for an unclear advantage. As of now the dependency on brings in also a dependency on making it very difficult to override it for a database applications that uses pyramid. Would it be possible/feasible to duplicate the package building one without all that chunk of doc-only dependencies? Should I propose a PR? Maintainer information:
Maybe a solution could be to just move the "docs" dependencies to the .
extras should not be included by default
cc
Change:
}; patches = [ <del> ./respect-xml-catalog-files-var.patch </del> <ins> passthru.respect_xml_catalog_files_var_patch </ins> ]; outputDevdoc = "out";

Discussion:
Once you take a video with cheese (as webm), a few strange things happen: No thumbnails for images or videos will load. Cheese will refuse to close without a 'kill/killall .cheese-wrapped' Errors: video in cheese. cheese via 'Quit' button OR by closing the window Check (cheese will still be running) and taking up quite a bit of CPU. Normal behavior is returned once webm file is moved or deleted. Cheese doesn't understand webm yet tries to record as webm. Then every attempt at loading the webm in the preview pane causes an error. Maybe a dependency issue and we should depend on some webm support library? Or an upstream issue with Cheese itself? System: 16.09.1445. (Flounder); 16.03.885. (Emu) Nix version: nix-env (Nix) 1.11.4; nix-env (Nix) 1.11.2 Nixpkgs version: 16.09.1445.; 16.03.885. Cheese version: 3.20.2; 3.18.1
Updated. Still an issue in 16.09.
I can reproduce the problems with thumbnails and webm-related issues on 17.03 and master. It doesn't seem to crash on exit in my testing. Playing with gets problems with missing to disappear, adding gstreamer bits (like is done in totem or sushi) doesn't seem to be sufficient (I'm no expert here). Related: (?).
I opened an upstream issue:
Running cheese with environment variable revealed missing path to bubblewrap. After patching , user still needs to have thumbnailers ( and ) installed, for now I have them as dependencies like I did in . The infinite loop is still an upstream bug but with thumbnailers, it at least should not appear.
Change:
"linux_py_37_cpu $bucket/linux/cpu/tensorflow_cpu-${version}-cp37-cp37m-manylinux2010_x86_64.whl" "linux_py_38_cpu $bucket/linux/cpu/tensorflow_cpu-${version}-cp38-cp38-manylinux2010_x86_64.whl" "linux_py_39_cpu $bucket/linux/cpu/tensorflow_cpu-${version}-cp39-cp39-manylinux2010_x86_64.whl" <ins> "linux_py_310_cpu $bucket/linux/cpu/tensorflow_cpu-${version}-cp310-cp310-manylinux2010_x86_64.whl" </ins> "linux_py_37_gpu $bucket/linux/gpu/tensorflow_gpu-${version}-cp37-cp37m-manylinux2010_x86_64.whl" "linux_py_38_gpu $bucket/linux/gpu/tensorflow_gpu-${version}-cp38-cp38-manylinux2010_x86_64.whl" "linux_py_39_gpu $bucket/linux/gpu/tensorflow_gpu-${version}-cp39-cp39-manylinux2010_x86_64.whl" <del> "mac_py_37_cpu $bucket/mac/cpu/tensorflow-${version}-cp37-cp37m-macosx_10_11_x86_64.whl" "mac_py_38_cpu $bucket/mac/cpu/tensorflow-${version}-cp38-cp38-macosx_10_11_x86_64.whl" "mac_py_39_cpu $bucket/mac/cpu/tensorflow-${version}-cp39-cp39-macosx_10_11_x86_64.whl" </del> <ins> "linux_py_310_gpu $bucket/linux/gpu/tensorflow_gpu-${version}-cp310-cp310-manylinux2010_x86_64.whl" "mac_py_37_cpu $bucket/mac/cpu/tensorflow-${version}-cp37-cp37m-macosx_10_14_x86_64.whl" "mac_py_38_cpu $bucket/mac/cpu/tensorflow-${version}-cp38-cp38-macosx_10_14_x86_64.whl" "mac_py_39_cpu $bucket/mac/cpu/tensorflow-${version}-cp39-cp39-macosx_10_14_x86_64.whl" "mac_py_310_cpu $bucket/mac/cpu/tensorflow-${version}-cp310-cp310-macosx_10_14_x86_64.whl" </ins> ) hashfile=binary-hashes.nix

Discussion:
Build of failed on x86_64-linux as of . This is currently breaking python3Packages.tensorflow-bin. python3Packages.tensorflow-bin maintainers cc: python39Packages.tensorflow maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tag:
I'm not quite sure why this doesn't have the same internal tag as they seem to be the same AFAICT.
oh I see... the hashes in /nix/store/[hash]-pname-version for each of the dependencies changed. hmmmm
Change:
with machine.nested("Waiting for instance to start and be usable"): retry(instance_is_up) <ins> def check_sysctl(instance): with subtest("systemd sysctl settings are applied"): machine.succeed(f"incus exec {instance} -- systemctl status systemd-sysctl") sysctl = machine.succeed(f"incus exec {instance} -- sysctl net.ipv4.ip_forward").strip().split(" ")[-1] assert "1" == sysctl, f"systemd-sysctl configuration not correctly applied, {sysctl} != 1" </ins> machine.wait_for_unit("incus.service") # no preseed should mean no service

Discussion:
not working in lxc containers. But sysctl command works fine and /proc/sys/ is writable. This nix option seems to finally take effect via . And the look like this: This looks fine, So I tried to manually run the command in , and it takes effect! But this looks even weirder. Through , I got: There is an unusual . It looks like this: Obviously, there is not is NixOS. So won't run at all. I looked it up on the internet and found out it's from distrobuilder: So maybe we should just patch it? Steps to reproduce the behavior: a privilege container with NixOS in it. something to and rebuild the system , and there is no effect should run and takes effect. <!-- 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]:
Are you able to you reproduce this with unstable? There are some improvements post 23.11 to the use of the lxc generator.
Yes, I'm already on latest unstable channel. The channel information in metadata tab is incorrect because I'm using flakes. There are many hard-coded FHS paths in distrobuilder. Such as this line, that causes this problem:
can you test this change?
It works fine for me. But I don’t know if there are any problems caused by other hard-coded paths in distrobuilder. And I don’t know whether using sysctl on an unprivileged container will cause the service to fail to start, and whether the startup failure will cause problems. But it seems that sets , so there should be no problem?
Thanks for testing! There shouldn't be, since we patch and wrap the distrobuilder lxc generator. I audited it again after updating the patch for this fix. You can always see the resulting file by building . The PR has tests which should cover unprivileged containers. I've just updated them to add a check verifying systemd-sysctl successfully started.
Change:
++ optional stdenv.hostPlatform.isLinux linux-pam ++ optional (!stdenv.hostPlatform.isDarwin) mytopEnv; <del> patches = common.patches ++ [ ./cmake-without-client.patch ] ++ optionals stdenv.hostPlatform.isDarwin [ </del> <ins> patches = common.patches ++ optionals stdenv.hostPlatform.isDarwin [ </ins> ./cmake-without-plugin-auth-pam.patch ];

Discussion:
Describe the bug Erorr first init mysql databases if use package builded To Reproduce Steps to reproduce the behavior: this patch command Expected behavior Error running this command Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: cc
Thanks for reporting Any of the , , , options require a client so I'm guessing the best we can do is document this. Any other ideas
is an argument that is only available for the derivation, and is not exposed in - so it's hard people stumble over this by accident. They need to explicitly set a global package override. Also, as error message by itself should already be clear enough, especially when looking at the system configuration. I don't consider this a bug. It works as intended - if you override mysql globally to not contain the client components, you'd have to expect client operations to fail. given you by yourself in , and it doesn't really work properly anyways, what about removing that argument?
When I made this parameter, I did not test database creation on first run. I wanted to split mariadb into components - server and client. Example in another distribution: But due to the different file locations, occur such errors. Is this variant bad? (Not worked witn MySQL 8.0)
If you use then there no reason to split package because you install both anyways. Arch Linux probably doesn't offer option so it makes sense.
What was the initial idea of having a server without the client binaries? Closure size reduction? In that case pulling in the client anyways in a separate derivation doesn't make much sense. I understand we want to have a separate client without pulling in server components (and we have that for mariadb), but I having the server without client isn't much of use. There's usually enough storage space on the database server to also ship the client binaries, and they are needed for most options in the mysql module, as well as for local administration / backups anyways. I'm pretty much for removing the argument. It causes a lot of confusion when uses for arguable benefit.
Change:
version = "2.10"; src = fetchFromGitHub { <del> owner = "c4dm"; </del> <ins> owner = "vamp-plugins"; </ins> repo = "vamp-plugin-sdk"; rev = "vamp-plugin-sdk-v${version}"; <del> sha256 = "1lhmskcyk7qqfikmasiw7wjry74gc8g5q6a3j1iya84yd7ll0cz6"; </del> <ins> hash = "sha256-5jNA6WmeIOVjkEMZXB5ijxyfJT88alVndBif6dnUFdI="; </ins> }; nativeBuildInputs = [ pkg-config ];

Discussion:
vamp-plugin-sdk's repository doesn't contain the releases linked on nixpkgs this repository actually still has the releases. the metadata in nixpkgs is Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
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

Discussion:
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?
Change:
meta = with stdenv.lib; { description = "A high-quality Japanese font based on Inconsolata and Migu 1M"; <del> homepage = https://www.rs.tus.ac.jp/yyusa/ricty.html; </del> <ins> homepage = http://www.yusa.lab.uec.ac.jp/~yusa/ricty.html; </ins> license = licenses.unfree; maintainers = [ maintainers.mikoim ]; };

Discussion:
Describe the bug The build of package () fails because returns a 403 error code (and no useful data) To Reproduce Steps to reproduce the behavior: in the nixpkgs directory, on current master Expected behavior Build succeeds Screenshots Additional context Metadata Please run and paste the result. Maintainer information:
Possible hotfix: Use as url which provides the needed source, but sadly no https, and this is not a mirror with versions in the url.
It seems the homepage moved to
The versioned ~yusa/ricty/ricty_generator- also exists
Change:
]; buildInputs = [ <del> qt6.qtbase qt6.qtsvg  # Needed for the systray icon </del> <ins> qtwayland qtbase qtsvg  # Needed for the systray icon </ins> ]; nativeBuildInputs = [ <del> qt6.wrapQtAppsHook </del> <ins> wrapQtAppsHook </ins> ]; dontWrapQtApps = true;

Discussion:
A clear and concise description of what the bug is. Steps to reproduce the behavior: on crash (coredump) The behaviour is very similar to a previous bug: Doesn't crash on startup.
Change:
<ins> { stdenv, lib, fetchFromGitHub, pkg-config, wayland-scanner, wayland-protocols, unstableGitUpdater, pixman, fcft, wayland, }: stdenv.mkDerivation { pname = "dwlb"; version = "0-unstable-2024-05-16"; src = fetchFromGitHub { owner = "kolunmi"; repo = "dwlb"; rev = "0daa1c1fdd82c4d790e477bf171e23ca2fdfa0cb"; hash = "sha256-Bu20IqRwBP1WRBgbcEQU4Q2BZ2FBnVaySOTsCn0iSSE="; }; nativeBuildInputs = [ pkg-config ]; env = { PREFIX = placeholder "out"; }; buildInputs = [ wayland-scanner wayland-protocols pixman fcft wayland ]; passthru.updateScript = unstableGitUpdater { }; meta = { description = "Fast, feature-complete bar for dwl"; homepage = "https://github.com/kolunmi/dwlb"; license = lib.licenses.gpl3Plus; mainProgram = "dwlb"; maintainers = with lib.maintainers; [ bot-wxt1221 ]; platforms = wayland.meta.platforms; }; } </ins>

Discussion:
Project description A fast, feature-complete bar for . Metadata homepage URL: source URL: license: GNU platforms: (I don't know what those are, but if it runs wayland, it should run this bar) Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
, sysctl , buildLlvmTools , debugVersion ? false <del> , doCheck ? (if lib.versionOlder release_version "15" then stdenv.isLinux else true) </del> <ins> , doCheck ? !stdenv.isAarch32 && (if lib.versionOlder release_version "15" then stdenv.isLinux else true) </ins> && (!stdenv.isx86_32 /* TODO: why */) && (!stdenv.hostPlatform.isMusl) && (stdenv.hostPlatform == stdenv.buildPlatform) , enableManpages ? false

Discussion:
Steps to reproduce the behavior: llvm on like this Broken on 14, 15, 16, 17, 18 and git versions. Likely broken by See also <!-- 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]:
in package should be fine I guess
Change:
name = "tmux-${version}"; version = "2.2"; <del> outputs = [ "out" "bin" "man" ]; </del> <ins> outputs = [ "out" "man" ]; </ins> src = fetchFromGitHub { owner = "tmux";

Discussion:
Issue appears to have introduced a regression in darwin builds, this was detected by the automated build: Reverting commit causes a successful build. On OS X (currently running OS X 10.11.5), run Output of the failed can be found in this gist: System: OS X 10.11.5 Nix version: nix-env (Nix) 1.11.2 Nixpkgs version: 16.09pre87025.
still a problem with Nixpkgs version 16.09pre87038.
change output order works for me: or change propagatedBuildOutputs like