jiebi/CodeConvo huggingface dataset:
Code change:
, texinfo , hevea , buildDocs ? false <ins> , optimize ? false # optimize sage to the current system (obviously impure) </ins> }: stdenv.mkDerivation rec {

Related discussion:
text: The recent changes seem to make sage crash when it tries to run some code using openblas (I think). I installed the sage derivation from the latest github repository. In the sage interpreter, run the following sage crashes with the following message: Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(okideal): channels(root): nixpkgs:
Procedural: as it is , please specify the CPU model. Looks like the Sage build system had the idea to use somewhere… I.e. the local build could work. I wonder how feasible it is to find where Sage does it — the Sage derivation is allowed to rebuild a lot of dependencies because it is just too much pain to make it use the system versions.
Here is the output of lscpu
From the traceback it presumably crashes here: which is which indeed is an AMD-only instruction (MMX? thought that would be long obsolete by now...)
You were right. A local build works fine. Thanks for the help.
Thanks for your report. do we set to and give up?
This should be fixed by exporting (see ). I'm not quite ready to give up (even though it would probably be the healthier choice :grin:). I'm actually currently experimenting with doing it the "right way" and replacing the sage buildsytem with nix (with a mix of sage and system dependencies).
can you confirm that the latest binary works?
Sorry for the late answer. The binaries from the master branch seem to work. The initial crashes are gone and running gives only unrelated failures. Installing from still gives me the old, faulty binaries though.
Are you sure you updated the channel? What do you mean by "binaries from master"?
I meant that installing from the master branch of the git repository works. I was not aware that there is a difference between nixos-unstable and nixpkgs-unstable. The latter does not seem to include the fix yet. Installing from nixos-unstable works well. Thanks for your help.
Okay, I guess hydra is a bit overwhelmed by all the fixes for the upcoming release. Thanks for reporting.
Code change:
<ins> { lib , stdenv , fetchFromGitHub , cmake , gcc12Stdenv , SDL2 , libGL }: gcc12Stdenv.mkDerivation (finalAttrs: { pname = "bstone"; version = "1.2.12"; src = fetchFromGitHub { owner = "bibendovsky"; repo = "bstone"; rev = "v${finalAttrs.version}"; hash = "sha256-wtW595cSoVTZaVykxOkJViNs3OmuIch9nA5s1SqwbJo="; }; nativeBuildInputs = [ cmake ]; buildInputs = [ libGL SDL2 ]; postInstall = '' mkdir -p $out/bin mv $out/bstone* $out/bin ''; meta = { description = "Unofficial source port for the Blake Stone series"; homepage = "https://github.com/bibendovsky/bstone"; changelog = "https://github.com/bibendovsky/bstone/blob/${finalAttrs.src.rev}/CHANGELOG.md"; license = with lib.licenses; [ gpl2Plus # Original game source code mit # BStone ]; maintainers = with lib.maintainers; [ keenanweaver ]; mainProgram = "bstone"; platforms = lib.platforms.linux; #TODO: macOS / Darwin support }; }) </ins>

Related discussion:
text: Project description Unofficial source port for Blake Stone series (Aliens Of Gold and Planet Strike). Metadata homepage URL: source URL: license: mit platforms: linux
Code change:
nativeBuildInputs = [ meson ninja pkg-config python3 wayland-scanner ]; buildInputs = [ cairo colord dbus freerdp lcms2 libGL libXcursor libdrm libevdev libinput <del> libjpeg libseat libunwind libva libwebp libxcb libxkbcommon mesa mtdev pam </del> <ins> libjpeg seatd libunwind libva libwebp libxcb libxkbcommon mesa mtdev pam </ins> pango pipewire udev vaapi wayland wayland-protocols xlibsWrapper ];

Related discussion:
text: error while building using unstable channel trying to build a system using weston pkg building successfully I assume its an easy name swap changing "libseat" on 4th line to "seatd"
Code change:
dontStrip = true; src = fetchzip { <del> url = "https://usa.kyoceradocumentsolutions.com/content/dam/kdc/kdag/downloads/technical/executables/drivers/kyoceradocumentsolutions/us/en/Kyocera_Linux_PPD_Ver_${version}.tar.gz"; </del> <ins> url = "https://la.kyoceradocumentsolutions.com/content/dam/kdc/kdag/downloads/technical/executables/drivers/kyoceradocumentsolutions/lad/en/Kyocera_Linux_PPD_Ver_${version}.tar.gz"; </ins> sha256 = "11znnlkfssakml7w80gxlz1k59f3nvhph91fkzzadnm9i7a8yjal"; };

Related discussion:
text: Describe the bug The uses the following source definition to build (in ): This source is no longer available, returning an HTP 302 redirect to a new homepage: Navigating the new home, this seems to be an alternative download location: However it seems to be a different file (warning, very slow download, file is ~ 140M in size): To Reproduce Steps to reproduce the behavior: -shell -p cups-kyodialog3 Expected behavior Packabe builds properly. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(marc): nixpkgs: Maintainer information:
I was slightly wrong because I don't understand how is supposed to work; it is the same file. The following works for me: I had to add the URL fragment to get to extract the file though.
does kyodialog3 works this way? Could you create a merge request?
Code change:
, bison ? null , flex , texinfo <ins> , perl </ins> }: let reuseLibs = enableShared && withAllTargets; <del> # Remove gold-symbol-visibility patch when updating, the proper fix # is now upstream. # https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=330b90b5ffbbc20c5de6ae6c7f60c40fab2e7a4f;hp=99181ccac0fc7d82e7dabb05dc7466e91f1645d3 version = "2.31.1"; </del> <ins> version = "2.34"; </ins> basename = "binutils"; # The targetPrefix prepended to binary names to allow multiple binuntils on the # PATH to both be usable.

Related discussion:
text: Describe the bug is currently in nixpkgs master. It was released in July 2018. was released in October 2019. It contains a few improvements and may also contains fix for some vulnerabilities: Is there a reason to keep the old version in nixpkgs, other than a lack of manpower? I'd be happy to do this work, but I just want to be sure that I was not starting a long, difficult and redundant work. I already tried a "naive" bump of the and but it does not work, mostly because most of the patchs are not valid anymore.
This was solved by cc.
Thank you for continuing this work!
Code change:
<del> { lib, fetchurl, appimageTools, imagemagick }: </del> <ins> { lib, fetchurl, appimageTools, imagemagick, systemd }: </ins> let pname = "ledger-live-desktop";

Related discussion:
text: Describe the bug From IRC: ; Looks like we currently just use their appimage: and our appimage tooling uses buildUserFHSEnv: It seems like we can either: using (build from source, maybe?) similar to how iohk patches Daedalus.
I tried packaging it with yarn2nix, but stumbled upon , unfortunately.
I don't know much about the appimage architecture. Why exactly can we not run appimages natively without FhsUserEnv? Is it just because binaries linking against fhs paths? In this case we probably could run autoPatchelfHook on the contents of the appimage and produce a new image that links against nix libs. EDIT: I just tried this. Extracted the appimage contents, patched all binaries, but then when executing ledger-live-desktop, I'm getting: Currently I'm running ledger live via qemu + usb device passthru via . That works fine.
how difficult would it be to lift Daedalus's patch and use it for the libudev inside the fhs? I've never worked with FHS before, but also don't want to build ledger live from source...
I tried to build ledger live from source and it didn't work because of the issue that mentioned. Patching libudev worked though.
can you link to the patch? It would be great to be able to use my more-trusted nixos machines for these types of activities.
I already created a PR for it and it's referenced above. This one:
Feel free to comment in the PR whether it actually works for you :)
The patch had to be re-done in Should this problem probably be communicated to upstream, so we can think about how to fix this long-term in a more sustainable fashion?
Code change:
sha256 = "0wmw823ildwm9rcfyk22pvzg100yhps3y9hfjlrpspfd1hhkbp0d"; <del> extraPatches = [ ]; </del> <ins> extraPatches = [ reapplyPathSanitizerPatch ]; </ins> }; zfsUnstable = common {

Related discussion:
text: Describe the bug When booting with ZFS legacy mountpoints like this: the boot fails as described in this post: To Reproduce I guess this is difficult if not anyone is having this issue with legacy mountpoints, but it seems that in the linked discourse post, I'm not the only one with this issue. But I've tested it just on this commit: where it fails, and on this (just one commit before): And there everything works. Expected behavior Mounting of legacy ZFS mountpoints succeeds while booting. Notify maintainers <!-- Metadata Please run and paste the result. Maintainer information: --
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Can you check if this is fixed by ?
I tried with this overlay: Not sure if that's the way to do it, but it didn't work.
it should probably be
Thanks I tried that, and it didn't work. Not sure how to confirm the patch got applied properly though.
if you have the log output, you will have something like:
Guys, just to report, I'm in the latest zen with ZFS 2.0.1-1 with encryption, unstable channel and I'm not having any problems.
I've just found time to test this, thanks for the research. The patch did indeed fix the issue for me! (I've checked the log output for the application of the patch). For the sake of completeness the overlay I've applied (needed a slightly different sha256 sum for me):
Could you make a PR adding the patch to zfs?
Code change:
"OCT_INSTALL_DIR=$(out)/${octave.sitePath}/oct" ]; <ins> postFixup = '' substituteInPlace $out/lib/cmake/nlopt/NLoptLibraryDepends.cmake --replace  'INTERFACE_INCLUDE_DIRECTORIES "''${_IMPORT_PREFIX}/' 'INTERFACE_INCLUDE_DIRECTORIES "' ''; </ins> meta = { homepage = "https://nlopt.readthedocs.io/en/latest/"; description = "Free open-source library for nonlinear optimization";

Related discussion:
text: A clear and concise description of what the bug is. The package doesn't include a folder. I am looking for a version of which includes the executable. Are we building the package incorrectly such that it doesn't include a binary? Any and all help/advice is much appreciated :bow: Steps to reproduce the behavior: output - notice there is no folder A clear and concise description of what you expected to happen. I want the executable. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- might know something about this? :man_shrugging:
was the binary there before On a quick note: I have never used , so I am not familiar with the package. It seems that the package also needs an update:
It appears that the binary requires AMPL, a commercial package, which is not packaged in nixpkgs. See: https://coin-
ah, I understand. Thank you.
Code change:
mv $out/usr/* $out/ rm -r $out/share/lintian rm -r $out/usr/ <ins> sed -i "s/${pname})/.${pname}-wrapped)/" $out/bin/${pname} </ins> # sed -i "s/'${pname}'/'.${pname}-wrapped'/" $out/bin/${pname} wrapProgram $out/bin/${pname}  --prefix "PATH" : "${gvfs}/bin"

Related discussion:
text: We've had issues with building atom-beautify since This happens now in both Atom and Atom Beta channels. Error for Atom: Error for Atom Beta: Travis CI for your fork Travis CI or a Docker image for nix and checkout master from atom and atom-beta Last successful beta/stable build: https://travis- Last successful stable build: https://travis- Both failed: https://travis-
here is a new issue.
Seems to be related to
For stable maybe, beta is slightly different error.
Code change:
captive-browser = callPackage ../applications/networking/browsers/captive-browser { }; <del> ndn-cxx = callPackage ../development/libraries/ndn-cxx { boost = boost175; }; </del> <ins> ndn-cxx = callPackage ../development/libraries/ndn-cxx { }; </ins> ndn-tools = callPackage ../tools/networking/ndn-tools { };

Related discussion:
text: The default boost version has been bumped from 1.69 (or 1.75) to 1.77. This is a notice for maintainers that the following packages are now failing to build: - - - - - - - - - - [x] cryfs A typical fix would involve pinning the package to a specific version (e.g. see )
My fix in is not the same as . Is there a very good reason to prefer one over the other ?
Well, I like trying to keep it away from the huge top-level file. (which is e.g. harder to use in git)
Re. pivx, I think we should mark it broken. Our current version is very old (and therefore useless), and the new version includes a rust build. I don't have the capacity to fix this ATM.
In my case, what broke it was the update from boost175 to boost177. Fix is in .
It's in the branch now, so please target any further fixes there as well (unless they're a mass rebuild, etc.)
colobot fixed with
FYI, ledger has some broken behavior with the new boost version, although it curiously doesn't cause a test failure: ledger/ledger.
Our expression does not attempt to run tests.
Ah, that would be why, thanks. Nevertheless, the binary exhibits the same problem described in that issue in interactive use.
Code change:
modernx-zydezu = callPackage ./modernx-zydezu.nix { }; mpris = callPackage ./mpris.nix { }; mpv-cheatsheet = callPackage ./mpv-cheatsheet.nix { }; <ins> mpv-discord = callPackage ./mpv-discord.nix { }; </ins> mpv-notify-send = callPackage ./mpv-notify-send.nix { }; mpv-osc-modern = callPackage ./mpv-osc-modern.nix { }; mpv-playlistmanager = callPackage ./mpv-playlistmanager.nix { };

Related discussion:
text: Project description A cross-platform Discord Rich Presence integration for mpv with no external dependencies. (MPV Userscript) Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin, windows
I've already but haven't PR'ed this to nixpkgs yet. Will probably do this when I get home from vacation next week.
Code change:
stdenv.mkDerivation rec { pname = "shotwell"; <del> version = "0.31.5"; </del> <ins> version = "0.31.7"; </ins> src = fetchurl { url = "mirror://gnome/sources/${pname}/${lib.versions.majorMinor version}/${pname}-${version}.tar.xz"; <del> sha256 = "sha256-OwSPxs6ZsjLR4OqbjbB0CDyGyI07bWMTaiz4IXqkXBk="; </del> <ins> sha256 = "sha256-gPCj2HVS+L3vpeNig77XZ9AFdtqMyWpEo9NKQjXEmeA="; </ins> }; <ins> patches = [ # Fix build with vala 0.56.4, can be removed on next update # https://gitlab.gnome.org/GNOME/shotwell/-/merge_requests/69 (fetchpatch2 { url = "https://gitlab.gnome.org/GNOME/shotwell/-/commit/cd82759231e5ece2fa0dea40397c9051d15fd5c2.patch"; hash = "sha256-Vy2kvUlmPdEEuPB1RTcI5pGYNveeiQ+lId0YVlWo4wU="; }) ]; </ins> nativeBuildInputs = [ meson ninja

Related discussion:
text: Steps to reproduce the behavior: shotwell from latest nixos-unstable I simply install shotwell with . Noticed that often updates this derivation, last time it was changed by but I don't think his change would cause this. Otherwise - meta.maintainers is empty. Please run and paste the result.
Code change:
stdenv.mkDerivation rec { pname = "xow"; <del> version = "0.5"; </del> <ins> version = "unstable-2022-04-24"; </ins> src = fetchFromGitHub { owner = "medusalix"; repo = "xow"; <del> rev = "v${version}"; sha256 = "071r2kx44k1sc49cad3i607xg618mf34ki1ykr5lnfx9y6qyz075"; </del> <ins> rev = "d335d6024f8380f52767a7de67727d9b2f867871"; sha256 = "0q5nr21p4dlx2a99hiivwz6qj9anrqqsdhiz6xi375yqkxis4251"; </ins> }; firmware = fetchurl {

Related discussion:
text: Enabling services.hardware. (as a systemd service) breaks. Steps to reproduce the behavior: error about and several other errors like "has not been declared", "does not name a type", etc. To rebuild xow and everything else without any issues. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
The git not found problem is not fatal and the derivation overrides the version info anyway. Looks like another victim of our stdenv compiler upgrade. Looks like upstream master has a fix for that. Upstream is also orphaned so upgrading the derivation to an unstable revision is going to be needed in the short term and in the long term a replacement should probably be found. I don't have a working controller to test xow with any more so if someone wants to adopt the package, feel free to.
Code change:
perlPackages.buildPerlPackage rec { pname = "SpamAssassin"; <del> version = "4.0.0"; rulesRev = "r1905950"; </del> <ins> version = "4.0.1"; rulesRev = "r1916528"; </ins> src = fetchurl { url = "mirror://apache/spamassassin/source/Mail-${pname}-${version}.tar.bz2"; <del> hash = "sha256-5aoXBQowvHK6qGr9xgSMrepNHsLsxh14dxegWbgxnog="; </del> <ins> hash = "sha256-l3XtdVnoPsPmwD7bK+j/x/FcxAX7E+hcFI6wvxkXIag="; </ins> }; defaultRulesSrc = fetchurl { url = "mirror://apache/spamassassin/source/Mail-${pname}-rules-${version}.${rulesRev}.tgz"; <del> hash = "sha256-rk/7uRfrx/76ckD8W7UVHdpmP45AWRYa18m0Lu0brG0="; </del> <ins> hash = "sha256-OB6t/H5RPl9zU4m3gXPeWvRx89Bv5quPEpY0pmRLS/Q="; </ins> }; patches = [

Related discussion:
text: Steps to reproduce the behavior: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
pixman cairo pango <ins> ] ++ lib.optionals stdenv.isDarwin [ darwin.apple_sdk_11_0.frameworks.CoreText </ins> ]; desktopItems = [

Related discussion:
text: Package name: Latest released version: <!-- Search your package here: --- Current version on the unstable channel: Current version on the stable/release channel: <!-- 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]:
Code change:
in stdenv.mkDerivation rec { pname = "openshadinglanguage"; <del> version = "1.12.13.0"; </del> <ins> version = "1.12.14.0"; </ins> src = fetchFromGitHub { owner = "AcademySoftwareFoundation"; repo = "OpenShadingLanguage"; rev = "v${version}"; <del> hash = "sha256-EVV7YHovWwbRju+uv8IK2wpcpoK1ndZ8yNRHzU8LUuE="; </del> <ins> hash = "sha256-x8t7uC4q29MkTCIS1rK0ICw78u5zZG+/zyhwttLOBr4="; </ins> }; cmakeFlags = [

Related discussion:
text: rendered in : ! bumping osl to did not work. Applying did not work <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --- system: host os: multi-user?: sandbox: version: nixpkgs:
I have verified that the problem exists with the current derivation even with version , which was updated away from in . I guess somehow the ZLIB_VERSION is replaced improperly , but I've got no idea what could be causing it, and I'm really confused why it's only become a problem recently, as it doesn't look like osl has been touched in either.
I've tracked it down to , and reverting it seems to fix it. I also believe it's a cmake issue. Consider this file Output: Maybe because the header changed to (? But if I'm reading the correctly, I think it should just set the version to an empty string? Either way, this patch seems to fix it I don't think it's worth raising with zlib because with the next patch version they're going to fix it anyway. It might be worth warning them in advance of 1.4. It's probably worth raising with cmake, because they will want to support all version, and then zlib won't have to care anymore either. I can open a PR for this tomorrow or when I have time, but don't wait for me if anybody wants to do it before.
Nice catch! One minor note: you are looking at 's master branch. It seems to be already fixed there as: We'll need that backport to . UPDATE: or wait for to reach master. With now is in .
Code change:
githubId = 303489; name = "Manuel Bärenz"; }; <ins> tu-maurice = { email = "valentin.gehrke+nixpkgs@zom.bi"; github = "tu-maurice"; githubId = 16151097; name = "Valentin Gehrke"; }; </ins> tv = { email = "tv@krebsco.de"; github = "4z3";

Related discussion:
text: Project description Converts Linux images and kernels into UEFI images. Metadata homepage URL: source URL: license: GPL3 platforms: Linux
Code change:
''; }; <ins> virtualisation.libvirtd.qemuOvmf = mkOption { type = types.bool; default = true; description = '' Allows libvirtd to take advantage of OVMF when creating new QEMU VMs with UEFI boot. ''; }; </ins> virtualisation.libvirtd.extraOptions = mkOption { type = types.listOf types.str; default = [ ];

Related discussion:
text: 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.
Code change:
python3Packages.buildPythonApplication rec { pname = "electron-cash"; <del> version = "4.2.0"; </del> <ins> version = "4.2.4"; </ins> src = fetchFromGitHub { owner = "Electron-Cash"; repo = "Electron-Cash"; rev = version; <del> sha256 = "0ixsx4224jilc5zis6wbsbxqxv10mm5sksrzq15xp30zz0bzb6md"; </del> <ins> sha256 = "sha256-hiOS0cTaPqllb31p+6nU4GYvw/E1Hdn8yd3sppzGkqg="; </ins> }; propagatedBuildInputs = with python3Packages; [ <del> dnspython </del> <ins> # requirements pyaes </ins> ecdsa <ins> requests qrcode protobuf </ins> jsonrpclib-pelix <del> matplotlib pbkdf2 pyaes pycrypto pyqt5 </del> pysocks <del> qrcode requests tlslite-ng </del> qdarkstyle <ins> python-dateutil </ins> stem <ins> certifi pathvalidate dnspython </ins> <del> # plugins keepkey </del> <ins> # requirements-binaries pyqt5 psutil pycryptodomex cryptography # requirements-hw cython </ins> trezor <ins> keepkey </ins> btchip <ins> hidapi pyscard pysatochip </ins> ]; nativeBuildInputs = [ wrapQtAppsHook ];

Related discussion:
text: Describe the bug failed to build on master. To Reproduce Steps to reproduce the behavior: nixpkgs master Expected behavior It builds. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): channels(oxa): nixpkgs: Maintainer information:
Code change:
}; buildInputs = [ makeWrapper pkgconfig e19.efl python27 dbus ]; <del> propagatedBuildInputs = [ python27Packages.pythonefl_1_11 python27Packages.dbus e19.elementary ]; </del> <ins> propagatedBuildInputs = [ python27Packages.pythonefl_1_12 python27Packages.dbus e19.elementary ]; </ins> postInstall = '' <del> wrapProgram $out/bin/econnman-bin --prefix PYTHONPATH : ${python27Packages.dbus}/lib/python2.7/site-packages:${python27Packages.pythonefl_1_11}/lib/python2.7/site-packages </del> <ins> wrapProgram $out/bin/econnman-bin --prefix PYTHONPATH : ${python27Packages.dbus}/lib/python2.7/site-packages:${python27Packages.pythonefl_1_12}/lib/python2.7/site-packages </ins> ''; meta = {

Related discussion:
text: Possible, because X11/xkb/rules/*.lst [0] are somewhere 'hidden' in the /nix/store. [0]
Fixed, just let me do some updating on E19 libraries and I will make a pull request.