jiebi/CodeConvo huggingface dataset:
Code change:
addPkgLocalList $out ${octave} wrapOctavePrograms "${lib.concatStringsSep " " packages}" <ins> # We also need to modify the Exec= line of the desktop file, so it will point # to the wrapper we generated above. rm $out/share/applications # should be a symlink to ${octave}/share/applications mkdir $out/share/applications substitute  ${octave}/share/applications/org.octave.Octave.desktop  $out/share/applications/org.octave.Octave.desktop  --replace-fail ${octave}/bin/octave $out/bin/octave </ins> '' + postBuild; inherit (octave) meta;

Related discussion:
text: When defining the desktop shortcut that gets installed globally doesn't point to the correct executable. The executable that it points to is the one of the non-wrapped package, causing any plugins that are installed to fail to load. Steps to reproduce the behavior: the following in a launching the application from your desktop menu/launcher the command pallete inside of the program in - THIS fails HOWEVER, if we launch octave from the commandline instead by issuing the command, everything works as it should. When you launch octaveFull from the desktop menu it should behave the same as if it was launched from the commandline. When launched from the OS desktop menu. ! When launched from the command-line ! Inside of your octave-env derivation that's generated when you do a system rebuild, theres a file located, there you'd be able to see that the wrong executable path is used for it. Please fix this. <!-- 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]:
Thanks for the report! Indeed we never thought about this detail. I pushed a fix in . Here's how I tested it: And note how the paths in the line above is the same as the path to the wrapping derivation (from ). I also checked with that I can in the GUI. Your approval on will be welcomed.
Will take a while to build as I don't use unstable, there's a ton of dependencies
Code change:
<del> { lib, stdenv, fetchurl, makeWrapper, jre_headless, gawk }: stdenv.mkDerivation rec { pname = "nexus"; version = "3.68.1-02"; src = fetchurl { url = "https://download.sonatype.com/nexus/3/nexus-${version}-unix.tar.gz"; hash = "sha256-VHS4KDFgU3djteDzDAe43TZIwRG/8bb7u3usoOCJS5M="; }; preferLocalBuild = true; sourceRoot = "${pname}-${version}"; nativeBuildInputs = [ makeWrapper ]; patches = [ ./nexus-bin.patch ./nexus-vm-opts.patch ]; postPatch = '' substituteInPlace bin/nexus.vmoptions  --replace ../sonatype-work /var/lib/sonatype-work  --replace etc/karaf $out/etc/karaf  --replace =. =$out ''; installPhase = '' runHook preInstall mkdir -p $out cp -rfv * .install4j $out rm -fv $out/bin/nexus.bat wrapProgram $out/bin/nexus  --set JAVA_HOME ${jre_headless}  --set ALTERNATIVE_NAME "nexus"  --prefix PATH "${lib.makeBinPath [ gawk ]}" runHook postInstall ''; meta = with lib; { description = "Repository manager for binary software components"; homepage = "https://www.sonatype.com/products/sonatype-nexus-oss"; sourceProvenance = with sourceTypes; [ binaryBytecode ]; license = licenses.epl10; platforms = platforms.all; maintainers = with maintainers; [ aespinosa ironpinguin zaninime ]; }; } </del>

Related discussion:
text: Package name: nexus Latest released version: 3.69.0 <!-- Search your package here: --- Current version on the unstable channel: 3.68.1-02 Current version on the stable/release channel: 3.68.1-02 <!-- 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:
github = "tirimia"; githubId = 11174371; }; <ins> titaniumtown = { email = "titaniumtown@proton.me"; name = "Simon Gardling"; github = "titaniumtown"; githubId = 11786225; matrix = "@titaniumtown:envs.net"; keys = [ { fingerprint = "D15E 4754 FE1A EDA1 5A6D  4702 9AB2 8AC1 0ECE 533D"; } ]; }; </ins> tjni = { email = "43ngvg@masqt.com"; matrix = "@tni:matrix.org";

Related discussion:
text: Package name: gpt4all Latest released version: 3.2.1 <!-- Search your package here: --- Current version on the unstable channel: 2.8.0 Current version on the stable/release channel: 2.7.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]:
Hi, I don't maintain GPT4All any longer, I switched to some other technologies (Open-WebUI).
haha, maybe i'll give that one a try then :) ty for all your hard work
Code change:
description = "Renew ACME Certificate for ${cert}"; after = [ "network.target" "network-online.target" ]; wants = [ "network-online.target" ]; <ins> wantedBy = [ "multi-user.target" ]; </ins> serviceConfig = { Type = "oneshot"; # With RemainAfterExit the service is considered active even

Related discussion:
text: Describe the bug I have configured the new ACME module (from 20.03) and after a rebuild nothing happened. I expected to have a certificate or a (failed) certificate request, but neither of these happened. Apparently I have to wait four days until my certificates would automatically appear, that is a bit long. To Reproduce Steps to reproduce the behavior: a certificate through certificate request doesn't happen before the systemd-timer is due Expected behavior I should have a certificate as soon as possible. Metadata Maintainer information:
presumably you have a service which requires this certificate. You should make that service require your certificate service. Both and services do this with their options and could demonstrate for you how to do this. If any part of what I said isn't clear, or any part of the code please do not hesitate to ask for details.
Got it, I can make that work. But is that really the intended behaviour?
Would you want each certificate to renew each and every time you rebuilt your system? That sounds like much more of a problem. You could always manually execute the certificate service any time you want, but the intention is that you utilize systemd and make services depend on other services. Why provision a certificate unless you need it. If you need it, declare it so and it will be provisioned.
It wouldn't renew on every rebuild: Starting the renew service doesn't do anything if no renew is needed. I think having the certificate be created when a rebuild is done sounds reasonable. I think it might simply be a matter of adding to the acme services.
That and also making sure on boot that the certificate is in order is also a good practice.
thanks for clarifying that. I think I was mistaking the implementation which did attempt to renew every time it was called, if I recall correctly :thinking:
Code change:
buildInputs = [autoconf cmake automake libtool gfortran clang gnumake hwloc jre liblapack blas hdf5 expat ncurses readline qt4 webkitgtk which lp_solve omniorb sqlite libatomic_ops pkgconfig file gettext flex bison <del> doxygen boost openscenegraph gnome2.gtkglext pangox_compat xorg.libXmu </del> <ins> doxygen boost openscenegraph gnome2.gtkglext xorg.libXmu </ins> git gtk2 makeWrapper]; hardeningDisable = [ "format" ];

Related discussion:
text: Describe the bug Seems like some updates to pango broke a few packages Among the broken ones: ettercap (see ) pangox-compat (which anydesk needs) probably a few more To Reproduce Steps to reproduce the behavior: to build ettercap or anydesk from master will fail to build with some pango-related errors Expected behavior It should work Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Metadata system: host os: multi-user?: sandbox: version: channels(maciej): nixpkgs: Maintainer information:
Also remmina is broken But doesn't seem to depend on pango directly, so unsure which dependency actually is broken
Here's an issue for pangox-compat
Lutris is broken too - not an urgent requirement but just making you fine folks aware!
Not sure why Lutris is broken, but Lutris-unwrap is fine.
It's a failure in the dependency chain, in this case .
no longer depends on on its master branch: We should probably switch to that. should not be needed in according to the README in , I suspect it was only there because we did not propagate it until ebassi also suggests switching to HEAD and says we need not worry about ABI changes:
Not having pangox_compat fixed is definitively still an issue. Can this be re-opened?
After , the only program depending on this is anydesk and openmodelica which is broken.
So it breaks anydesk thus either we mark anydesk as broken or we fix that?
Anydesk shouldn't use this deprecated library. Yes, we can mark it as broken.
Code change:
dataclasses ]; <del> buildInputs = [ libX11 libXinerama libXrandr ]; </del> <ins> postPatch = '' substituteInPlace screeninfo/enumerators/xinerama.py  --replace 'load_library("X11")' 'ctypes.cdll.LoadLibrary("${libX11}/lib/libX11.so")'  --replace 'load_library("Xinerama")' 'ctypes.cdll.LoadLibrary("${libXinerama}/lib/libXinerama.so")' substituteInPlace screeninfo/enumerators/xrandr.py  --replace 'load_library("X11")' 'ctypes.cdll.LoadLibrary("${libX11}/lib/libX11.so")'  --replace 'load_library("Xrandr")' 'ctypes.cdll.LoadLibrary("${libXrandr}/lib/libXrandr.so")' ''; </ins> checkInputs = [ pytestCheckHook

Related discussion:
text: remarkable-mouse doesn't work for me, exiting with the following traceback: Digging through github issues led me to , and the following traceback: I guess this is a problem with screeninfo's packaging, but I'm unsure what exactly the issue is, or how to fix it; maybe related to ? screeninfo (and, by extension, remarkable-mouse) should work. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
As far as I know there is no infrastructure in place that lets (in ) work correctly, since it has no knowledge about the Nix store or the buildInputs of screeninfo. There used to be a call which replaced all findlibrary calls with store paths, but it was removed in I think the two load_library related substitutions need to be back in (compare with , which contains comparable code).
Replacing calls seems sensible, I will try to make a PR. A workaround for now (e.g. for remarkable-mouse users) is to set $LDLIBRARY_PATH to , but that probably isn't usable within the library itself.
Code change:
<del> { lib, stdenv </del> <ins> { lib , stdenv </ins> , fetchurl <ins> , fetchpatch2 </ins> , meson , ninja , gtk3

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:
export CHROME_DEVEL_SANDBOX="$sandbox/bin/${sandboxExecutableName}" fi <ins> # Make generated desktop shortcuts have a valid executable name. export CHROME_WRAPPER='chromium' </ins> '' + lib.optionalString (libPath != "") '' # To avoid loading .so files from cwd, LD_LIBRARY_PATH here must not # contain an empty section before or after a colon.

Related discussion:
text: I enabled the following chromium enterprise policy: This created a .desktop file in But the command crashes, because it tries to start the unwrapped binary directly from the nix store. We should try to point Exec at just so the wrapper from PATH is used.
CC
Not sure what's happening here. On my system it seems to be fine:
Please read the description again, specifically I am talking about the .desktop files created by chromium, at runtime.
Ok, I was assuming NixOS put it there. Chromium creating files at runtime sucks... (unfortunately it's not even surprising :o)
setting the env var in the wrapper script may help ;drc=;l=405
I marked this as stale due to inactivity. &rarr;
(as already mentioned) would probably work for Chromium too. Just in case someone's still interested and has time and motivation to test it and submit a PR ;)
This is not exactly a NixOS caused issue. As chrome creates the shortcut wherever the binary is currently installed, and there is no nice way (other than patching chrome) to solve this. While discussion of patching chromium to always point to relative chrome i cant say much about. To get this working today, you need to edit each desktop file manually from to its relative name . and use at the top of the file. While this adds a minor security issue due to executable being relative and not absolute, it seems like the simplest solution for now. There is also this flake that will run a service in the background to do this editing automatically for you: Hope this helps! :D
Code change:
}: stdenv.mkDerivation rec { <del> name = "nsd-4.1.7"; </del> <ins> name = "nsd-4.1.9"; </ins> src = fetchurl { url = "http://www.nlnetlabs.nl/downloads/nsd/${name}.tar.gz"; <del> sha256 = "12hskfgfbkvcgpa1xxkqd8lnc6xvln1amn97x6avfnj9kfrbxa3v"; </del> <ins> sha256 = "1wn8jm5kpp81m88c77j97850mnmd87yaw8qp3xsdwcakcd6j44dq"; </ins> }; buildInputs = [ libevent openssl ];

Related discussion:
text: We need to standardize and document this. The current contents in nixpkgs manual seems obsolete (section 4.2). I suggest at least these should be standardized: preference for usage of <codelib.licenses.*</codeinstead of the choice from some strings, meta.licenses semantics (any license at your choice, or different parts under different licenses?).
:+1:
I'd go for a documentation changes with pull request and point people to read that.
Is someone working on this? Would be good to get into (which also will presumably have with its new way of handling attributes)
First bullet is addressed in . For more complicated cases when it's not all one single license, I don't know how deep should we go. Choice from multiple licenses is probably the most common and using nix lists for that is suggestive, but it occasionally happens that multiple licenses need to be complied to at once (different files/parts under different licenses) or even more complex combinations. I don't see any possibility of "smooth extension" in such directions.
Solutions I encountered: Debian has per-file license granularity , and offers some RDF-based solution.
what's missing here?
I see the first bullet was fixed in . Attribute is still unspecified, but IMHO describing the licensing precisely in all cases is out of the scope of nixpkgs.
BTW, thanks for the notification. I forget to pass through old open issues.
Code change:
<ins> diff --git a/src/libsystemd/sd-device/device-monitor.c b/src/libsystemd/sd-device/device-monitor.c index fd5900704d..f9106fdbe5 100644 --- a/src/libsystemd/sd-device/device-monitor.c +++ b/src/libsystemd/sd-device/device-monitor.c @@ -445,9 +445,6 @@ int device_monitor_receive_device(sd_device_monitor *m, sd_device **ret) { "sd-device-monitor: No sender credentials received, message ignored."); cred = (struct ucred*) CMSG_DATA(cmsg); -        if (cred->uid != 0) -                return log_debug_errno(SYNTHETIC_ERRNO(EAGAIN), -                                       "sd-device-monitor: Sender uid="UID_FMT", message ignored.", cred->uid); if (streq(buf.raw, "libudev")) { /* udev message needs proper version magic */ </ins>

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:
# rewritten to /nix/store/<hash>/bin/python.  Interpreters that are # already in the store are left untouched. <del> fixupOutputHooks+=('if [ -z "$dontPatchShebangs" -a -e "$prefix" ]; then patchShebangs "$prefix"; fi') </del> <ins> fixupOutputHooks+=(patchShebangsAuto) # Run patch shebangs on a directory. # patchShebangs [--build | --host] directory # Flags: # --build : Lookup commands available at build-time # --host  : Lookup commands available at runtime # Example use cases, # $ patchShebangs --host /nix/store/...-hello-1.0/bin # $ patchShebangs --build configure </ins> patchShebangs() { <ins> local pathName if [ "$1" = "--host" ]; then pathName=HOST_PATH shift elif [ "$1" = "--build" ]; then pathName=PATH shift fi </ins> local dir="$1" header "patching script interpreter paths in $dir" local f local oldPath

Related discussion:
text: uses to determine the substitute for the shebang path. This selects the wrong path during cross-builds and results in x8664 binaries getting pulled in as dependencies to cross-built binaries that can't possibly use them at runtime. I don't know if we can reliably pick the correct /bin/sh without it being in the PATH envvar. I presume patchShebangs works fine for binaries that don't overlap with stdenv's and are included in buildInputs. If you cross-build some packages to ARM platforms, patchShebangs runs in the fixup phase and run , you'll see it points to the native /bin/sh rather than the cross one. I was considering a PR to just add to the cross build of glibc, but figured it'd be better if the root issue were fixed instead. System: "16.03pre75806." Nix version: nix-env (Nix) 1.12pre1234abcdef Nixpkgs version: (Gorilla)
/participate. (I've stumbled across this too.)
Is it safe to assume are the only paths that will ever realistically have this problem? If so, how and where would we pull in as a buildInput without it clobbering the native /bin/sh used by stdenv to run the builder? Once we're already executing , it's too late to find any s. This problem overlaps with another, , which is that crossDrvs clobber stdenv's binaries in the PATH. The best solution I can come up with is to manually include in of e.g. glibc, add logic in to not add to the PATH when crossbuilding, based on some new derivation attr like , then search during , independently of what's set in the PATH. Or we could just make smarter about importing /bin/ PATHs that contain elements of the stdenv, namely: .
is essential to fix this without greatly complicating bootstrapping.
don't forget to close. :)
Addressed in
Code change:
<del> { stdenv, fetchurl, pkgconfig, e19, xlibs, libffi, pam, alsaLib, luajit, bzip2, libpthreadstubs, gdbm, libcap, set_freqset_setuid ? false }: </del> <ins> { stdenv, fetchurl, pkgconfig, e19, xlibs, libffi, pam, alsaLib, luajit, bzip2 , libpthreadstubs, gdbm, libcap, mesa_glu, xkeyboard_config, set_freqset_setuid ? false }: </ins> stdenv.mkDerivation rec { name = "enlightenment-${version}";

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.
Code change:
pname = "azure-cli-core"; inherit version src; <ins> patches = [ (fetchpatch { name = "fix-python311.patch"; url = "https://github.com/Azure/azure-cli/commit/a5198b578b17de934e15b1c92e369e45323e9658.patch"; hash = "sha256-qbyKF6Vvtz8QwY78sG7ptTVcbM2IR+phntOKqsrWetE="; stripLen = 2; includes = [ "azure/cli/core/tests/test_command_registration.py" "azure/cli/core/tests/test_help.py" "azure/cli/core/tests/test_parser.py" ]; }) ]; </ins> sourceRoot = "${src.name}/src/azure-cli-core"; propagatedBuildInputs = with self; [

Related discussion:
text: Steps to reproduce the behavior: azure-cli Add any other context about the problem here. <!-- 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.
For now, changing python used to seems to fix the build:
Made a PR that fixes the failure.
Will investigate this failure and try to fix it (by using Python 3.11), but the build was working before (We may temporarily fix it using as a workaround), some dependencies must have been changed, from before, not sure which one is causing this failure, I'd need to bisect commits on master branch, I guess...
The failure is because of python3.11, the tests didn't work properly on 3.11. Upstream fixed those tests for a future release. For now we can either rollback the python used to 3.10, or back port the tests fixed. From what I tested, nothing is broken on 3.11 except for those tests.
Thanks a lot for those clarifications and appreciating a lot your help in fixing all this However, we can't really make sure that those tests won't break again, unless we pin a patch on those ? And this is what you've done in your fix PR. I'll be trying the latest release 2.53.1 with the dependencies cleanup.
Code change:
<del> { stdenv, lib, fetchFromGitHub, pkgconfig, cmake, git, doxygen, help2man, ncurses, tecla </del> <ins> { stdenv, lib, fetchFromGitHub, fetchpatch, pkgconfig, cmake, git, doxygen, help2man, ncurses, tecla </ins> , libusb1, udev }: let

Related discussion:
text: Describe the bug libbladeRF fails to build on the nixos-unstable channel and latest master: Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Cannot reproduce this in master. I am on . Was this fixed in ?
I have just tried on , here is a full log:
Can also confirm that the build fails on .
This appears to me a genuine error in the source. Live bladerf1.c:841 (and also bladerf2.c:283) reference , but it should be . With , we stop the build on purpose. Luckily the typo is not of further consequence, since both values are numerically the same (both zero). I will try to report this to upstream.
Oh nice, this has already been fixed in upstream master (in from last May to be precise), but there isn't yet a new release containing a fix. I'll prepare a pull request cherrypicking this patch. Be aware though that I cannot test libbladeRF (in fact I don't even know what it is about :-)).
maybe also add . This options is meant for development where there is control over the compiler, but in nixpkgs we want to update gcc without breaking half the packages due to warnings.
I see, thank you for the suggestion! Generally I'm in favor of , but your argument is quite reasonable. I'll force-push in a second.