jiebi/CodeConvo huggingface dataset:
Code change:
Recently, we fixed : However, on , still fails to run on my machine throughing the dreaded: Steps to reproduce the behavior: run nixpkgs#puddletag The application seems to be correctly wrapped: but still, it does not work. and myself. Please run and paste the result.
There’s definitely an impurity somewhere - it’s working perfectly fine here. I hadn’t used it in a while, but it runs with nixos-unstable` currently on this machine.
This is interesting. The command definitely fails for me. (I was incorrectly saying , but I am also using ). I have trouble debugging this. I had a look at the wrapper shell script, and all looks fine. The paths are ok and do exist.
That seems to indicate an impurity then.
This is also happening on nixos-22.11, not just unstable. A friend is having this issue, so I tested it out for myself and got the same thing. For what it's worth, we both use i3, so the impurity may be related to things a DE would normally set up.
runs fine for me.
So definitely a purity thing then. Care to do a PR?
Sure, I suppose. Just a minute.
Hi! Thanks for looking into this! I could not test the PR directly because the review process starts to build Python Pandas an whatnot. However, I could start using the fix of Some remarks: The wrapper without the fix is: The file with the fix (adding the Qt wrapper line): So there is a substantial difference, and wrapping doesn't seem to work properly without the extra line, even though it should work. Further, when opening on using the fix, the program crashes when clicking with the following error: I do not think this is related to the wrapping, but it should definitely also be fixed. Somehow, is not found.
My version wraps twice, so the original wrapper and all its settings are still there, in , while the real puddletag script is now in . There's a note at the bottom of which says that doesn't wrap scripts, only ELF binaries. I don't know what the reasoning for that is, but apparently invoking the wrapping manually is "what you're supposed to do". At least as far as I could tell.
Ok I see. So the first wrapper handles the python dependencies, and the second one the qt dependencies. Is that so?
Counting the layers outward from the core (rather than, say, in execution order), yes, that's correct.
Then we should modify the wrapper args instead to avoid double-wrapping.
Well, to do that, I believe you'd need to reimplement either the python wrapping or the qt wrapping systems, which seems prone to breakage.

Related discussion:
text: # the file should be executable but it isn't so our wrapper doesn't run preFixup = '' chmod 555 $out/bin/puddletag <ins> wrapQtApp $out/bin/puddletag </ins> ''; doCheck = false; # there are no tests
Code change:
Project description RiscPC Emulator Metadata homepage URL: source URL: license: gpl2 platforms: linux, darwin This also includes ROM images which could also be downloaded, as ROOL maintains these on an open source licence. Not sure the best idea for these... /var/lib? Thanks very much for all your hard work.
Builds and compiles. I will upload it tomorrow
The roms are mostly optional, in the sense the software will seek them in . There is no such a need for include them now.
Thanks very much.
how did you get it to work? I can't get it to recognize the existence of the hostfs folder.

Related discussion:
text: <ins> { lib , stdenv , fetchhg , qt5 }: let inherit (qt5) qtbase qtmultimedia wrapQtAppsHook; in stdenv.mkDerivation (self: { pname = "rpcemu"; version = "0.9.4"; src = fetchhg { url = "http://www.home.marutan.net/hg/rpcemu"; rev = "release_${self.version}"; sha256 = "sha256-UyjfTfUpSvJNFPkQWPKppxp/kO0hVGo5cE9RuCU8GJI="; }; nativeBuildInputs = [ wrapQtAppsHook ]; buildInputs = [ qtbase qtmultimedia ]; configurePhase = '' runHook preConfigure cd src/qt5 qmake runHook postConfigure ''; installPhase = '' runHook preInstall cd ../.. install -Dm755 rpcemu-interpreter -t $out/bin runHook postInstall ''; meta = { homepage = "https://www.marutan.net/rpcemu/index.php"; description = "Risc PC Emulator"; longDescription = '' RPCEmu is an emulator of classic Acorn computer systems, such as the Risc PC and A7000. It runs on multiple platforms including Windows, Linux and Mac OS X. RPCEmu should be considered Alpha Quality code. It has many known and unknown bugs, and all files used with it should be well backed up before using them with RPCEmu. ''; license = lib.licenses.gpl2Plus; maintainers =  builtins.attrValues { inherit (lib.maintainers) AndersonTorres; }; platforms = lib.platforms.linux; }; }) </ins>
Code change:
Project description RiscPC Emulator Metadata homepage URL: source URL: license: gpl2 platforms: linux, darwin This also includes ROM images which could also be downloaded, as ROOL maintains these on an open source licence. Not sure the best idea for these... /var/lib? Thanks very much for all your hard work.
Builds and compiles. I will upload it tomorrow
The roms are mostly optional, in the sense the software will seek them in . There is no such a need for include them now.
Thanks very much.
how did you get it to work? I can't get it to recognize the existence of the hostfs folder.

Related discussion:
text: ripes = libsForQt5.callPackage ../applications/emulators/ripes { }; <ins> rpcemu = callPackage ../applications/emulators/rpcemu { }; </ins> rpcs3 = libsForQt5.callPackage ../applications/emulators/rpcs3 { }; ruffle = callPackage ../applications/emulators/ruffle { };
Code change:
Project description spotify-player is a fast, easy to use, and configurable terminal music player. Metadata homepage URL: source URL: license: MIT platforms: linux, windows, darwin

Related discussion:
text: <ins> { lib , rustPlatform , fetchFromGitHub , pkg-config , openssl , cmake , alsa-lib , dbus , fontconfig }: rustPlatform.buildRustPackage rec { pname = "spotify-player"; version = "0.10.0"; src = fetchFromGitHub { owner = "aome510"; repo = pname; rev = "v${version}"; sha256 = "sha256-bHPWpx8EJibr2kNuzuGAQPZ0DE6qeJwIRYDy+NFS/PQ="; }; cargoSha256 = "sha256-QeQ3PYI5RmbJ+VQ9hLSTXgQXVVoID5zbRqSTrbWzVy8="; nativeBuildInputs = [ pkg-config cmake ]; buildInputs = [ openssl alsa-lib dbus fontconfig ]; buildNoDefaultFeatures = true; buildFeatures = [ "rodio-backend" "media-control" "image" "lyric-finder" ]; meta = with lib; { description = "A command driven spotify player"; homepage = "https://github.com/aome510/spotify-player"; license = licenses.mit; maintainers = with maintainers; [ dit7ya ]; }; } </ins>
Code change:
Project description spotify-player is a fast, easy to use, and configurable terminal music player. Metadata homepage URL: source URL: license: MIT platforms: linux, windows, darwin

Related discussion:
text: spotify = callPackage ../applications/audio/spotify { }; <ins> spotify-player = callPackage ../applications/audio/spotify-player { }; </ins> spotifywm = callPackage ../applications/audio/spotifywm { }; psst = callPackage ../applications/audio/psst { };
Code change:
On or cross-compiled from , breaks: From : You can either run this on another architecture using . or should not crash: This was responsible for failing to replicate datasets to my ARM NAS. The issue does not_ occur for natively compiled builds. It appears to be a cross-compilation issue only.
It is a bug in / derivations. In non-cross cases it gets copied from used to bid into output: But in cross-case used to build does not yet provide as it needs bits of for it (and the library path is slightly incorrect). One of possible workarounds is to try to add to to get it pulled via from expected location.
We don't do the copying to glibc anymore, but this error still occurs as described on current nixpkgs master.
Yup. cross-compilation never propagated to in any form (and does not today).
Could you please try this PR? It should fix the problem.
With that PR, I'm seeing this on both (a Raspberry Pi CM4) and with QEMU on : Log from aarch64 machine: Log from machine with QEMU:
Well it's finding now, so there's clearly some other problem with addition to that. When I run it with I even get line numbers from inside : That line () is the last line in the following snippet of code: ... so is deliberately ing here due to . Grepping through the docs turns up: This is happening because uses . Once you do that, glibc needs to unwind the stack frame of any thread that calls . And unwinders are a giant headache. I'm afraid that's all I've got here. I've removed the closed-by from since it was only part of the problem here.
Ah, I think I know what it is. We can compile a without , but it won't have an unwinder. We need to pass the glibc headers to the build in order to get one of those.
would you please try ? I believe it fixes one of the two problems which caused this issue, and it includes which fixes the other one. It works for me: BTW, this issue (cross-compile , then run it under qemu) is a really valuable test case. We really ought to add it to so Hydra will catch any regressions automatically. Especially since the failure mode gives the user no error message to help them troubleshoot the problem! is a great candidate for this since it's one of those very rare non-C++ programs that uses advanced stack-unwinding features from pthreads.
Confirming fixes the issue. Tested with both and on real hardware and with QEMU on x86_64.
~I think this is fixed, and more cleanly,~ by Edit: it is not. :frowning_face: I will keep trying. Test is in Currently building.
Added this to , but commented out since it is not fixed yet.

Related discussion:
text: , enableMultilib }: <ins> let forceLibgccToBuildCrtStuff = import ./libgcc-buildstuff.nix { inherit lib stdenv; }; in </ins> originalAttrs: (stdenv.mkDerivation (finalAttrs: originalAttrs // { <ins> passthru = (originalAttrs.passthru or {}) // { inherit forceLibgccToBuildCrtStuff; }; </ins> preUnpack = '' oldOpts="$(shopt -po nounset)" || true set -euo pipefail
Code change:
On or cross-compiled from , breaks: From : You can either run this on another architecture using . or should not crash: This was responsible for failing to replicate datasets to my ARM NAS. The issue does not_ occur for natively compiled builds. It appears to be a cross-compilation issue only.
It is a bug in / derivations. In non-cross cases it gets copied from used to bid into output: But in cross-case used to build does not yet provide as it needs bits of for it (and the library path is slightly incorrect). One of possible workarounds is to try to add to to get it pulled via from expected location.
We don't do the copying to glibc anymore, but this error still occurs as described on current nixpkgs master.
Yup. cross-compilation never propagated to in any form (and does not today).
Could you please try this PR? It should fix the problem.
With that PR, I'm seeing this on both (a Raspberry Pi CM4) and with QEMU on : Log from aarch64 machine: Log from machine with QEMU:
Well it's finding now, so there's clearly some other problem with addition to that. When I run it with I even get line numbers from inside : That line () is the last line in the following snippet of code: ... so is deliberately ing here due to . Grepping through the docs turns up: This is happening because uses . Once you do that, glibc needs to unwind the stack frame of any thread that calls . And unwinders are a giant headache. I'm afraid that's all I've got here. I've removed the closed-by from since it was only part of the problem here.
Ah, I think I know what it is. We can compile a without , but it won't have an unwinder. We need to pass the glibc headers to the build in order to get one of those.
would you please try ? I believe it fixes one of the two problems which caused this issue, and it includes which fixes the other one. It works for me: BTW, this issue (cross-compile , then run it under qemu) is a really valuable test case. We really ought to add it to so Hydra will catch any regressions automatically. Especially since the failure mode gives the user no error message to help them troubleshoot the problem! is a great candidate for this since it's one of those very rare non-C++ programs that uses advanced stack-unwinding features from pthreads.
Confirming fixes the issue. Tested with both and on real hardware and with QEMU on x86_64.
~I think this is fixed, and more cleanly,~ by Edit: it is not. :frowning_face: I will keep trying. Test is in Currently building.
Added this to , but commented out since it is not fixed yet.

Related discussion:
text: !langJit && !stdenv.hostPlatform.isDarwin && enableShared <del> ; </del> <ins> ; </ins> <del> # For some reason libgcc_s.so has major-version "2" on m68k but # "1" everywhere else.  Might be worth changing this to "*". libgcc_s-version-major = if targetPlatform.isM68k then "2" else "1"; </del> <ins> # For some reason libgcc_s.so has major-version "2" on m68k but # "1" everywhere else.  Might be worth changing this to "*". libgcc_s-version-major = if targetPlatform.isM68k then "2" else "1"; </ins> in (pkg: pkg.overrideAttrs (previousAttrs: lib.optionalAttrs ((!langC) || langJit || enableLibGccOutput) {
Code change:
On or cross-compiled from , breaks: From : You can either run this on another architecture using . or should not crash: This was responsible for failing to replicate datasets to my ARM NAS. The issue does not_ occur for natively compiled builds. It appears to be a cross-compilation issue only.
It is a bug in / derivations. In non-cross cases it gets copied from used to bid into output: But in cross-case used to build does not yet provide as it needs bits of for it (and the library path is slightly incorrect). One of possible workarounds is to try to add to to get it pulled via from expected location.
We don't do the copying to glibc anymore, but this error still occurs as described on current nixpkgs master.
Yup. cross-compilation never propagated to in any form (and does not today).
Could you please try this PR? It should fix the problem.
With that PR, I'm seeing this on both (a Raspberry Pi CM4) and with QEMU on : Log from aarch64 machine: Log from machine with QEMU:
Well it's finding now, so there's clearly some other problem with addition to that. When I run it with I even get line numbers from inside : That line () is the last line in the following snippet of code: ... so is deliberately ing here due to . Grepping through the docs turns up: This is happening because uses . Once you do that, glibc needs to unwind the stack frame of any thread that calls . And unwinders are a giant headache. I'm afraid that's all I've got here. I've removed the closed-by from since it was only part of the problem here.
Ah, I think I know what it is. We can compile a without , but it won't have an unwinder. We need to pass the glibc headers to the build in order to get one of those.
would you please try ? I believe it fixes one of the two problems which caused this issue, and it includes which fixes the other one. It works for me: BTW, this issue (cross-compile , then run it under qemu) is a really valuable test case. We really ought to add it to so Hydra will catch any regressions automatically. Especially since the failure mode gives the user no error message to help them troubleshoot the problem! is a great candidate for this since it's one of those very rare non-C++ programs that uses advanced stack-unwinding features from pthreads.
Confirming fixes the issue. Tested with both and on real hardware and with QEMU on x86_64.
~I think this is fixed, and more cleanly,~ by Edit: it is not. :frowning_face: I will keep trying. Test is in Currently building.
Added this to , but commented out since it is not fixed yet.

Related discussion:
text: librarian-puppet-go = callPackage ../development/tools/librarian-puppet-go { }; <ins> libgcc = stdenv.cc.cc.libgcc or null; </ins> # This is for e.g. LLVM libraries on linux. gccForLibs = if stdenv.targetPlatform == stdenv.hostPlatform && targetPackages.stdenv.cc.isGNU
Code change:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- 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! --- name: msmtp <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 1.8.22 desired version: 1.8.23 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.

Related discussion:
text: it is set, instead of the previous hardcoded default of `${networking.hostName}.${security.ipa.domain}`. <ins> - The `MSMTP_QUEUE` and `MSMTP_LOG` environment variables accepted by `msmtpq` have now been renamed to `MSMTPQ_Q` and `MSMTPQ_LOG` respectively. </ins> - The fcgiwrap module now allows multiple instances running as distinct users. The option `services.fgciwrap` now takes an attribute set of the configuration of each individual instance.
Code change:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- 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! --- name: msmtp <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 1.8.22 desired version: 1.8.23 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.

Related discussion:
text: let inherit (lib) getBin getExe optionals; <del> version = "1.8.22"; </del> <ins> version = "1.8.25"; </ins> src = fetchFromGitHub { owner = "marlam"; <del> repo = "msmtp-mirror"; </del> <ins> repo = "msmtp"; </ins> rev = "msmtp-${version}"; <del> hash = "sha256-Jt/uvGBrYYr6ua6LVPiP0nuRiIkxBJASdgHBNHivzxQ="; </del> <ins> hash = "sha256-UZKUpF/ZwYPM2rPDudL1O8e8LguKJh9sTcJRT3vgsf4="; </ins> }; meta = with lib; {
Code change:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- 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! --- name: msmtp <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 1.8.22 desired version: 1.8.23 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.

Related discussion:
text: pname = "msmtp-scripts"; inherit version src meta; <del> patches = [ ./paths.patch ]; </del> <ins> patches = [ ./msmtpq-remove-binary-check.patch ./msmtpq-systemd-logging.patch ]; </ins> postPatch = '' substituteInPlace scripts/msmtpq/msmtpq
Code change:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- 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! --- name: msmtp <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 1.8.22 desired version: 1.8.23 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.

Related discussion:
text: <ins> diff --git a/scripts/msmtpq/msmtpq b/scripts/msmtpq/msmtpq index bcb384e..9622e47 100755 --- a/scripts/msmtpq/msmtpq +++ b/scripts/msmtpq/msmtpq @@ -60,8 +60,6 @@ err() { dsp '' "$@" '' ; exit 1 ; } ##   export the location of the msmtp executable before running this script  (no quotes !!) ##   e.g. ( export MSMTP=/path/to/msmtp ) MSMTP="${MSMTP:-msmtp}" -"$MSMTP" --version >/dev/null 2>&1 ||  -  log_later -e 1 "msmtpq : can't run the msmtp executable [ $MSMTP ]"   # if not found - complain ; quit ## ## set the queue var to the location of the msmtp queue directory ##   if the queue dir doesn't yet exist, create it (0700) </ins>
Code change:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- 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! --- name: msmtp <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 1.8.22 desired version: 1.8.23 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.

Related discussion:
text: <ins> diff --git a/scripts/msmtpq/msmtpq b/scripts/msmtpq/msmtpq index bcb384e..dbaf1b5 100755 --- a/scripts/msmtpq/msmtpq +++ b/scripts/msmtpq/msmtpq @@ -92,6 +92,8 @@ if [ ! -v MSMTPQ_LOG ] ; then fi fi [ -d "$(dirname "$MSMTPQ_LOG")" ] || mkdir -p "$(dirname "$MSMTPQ_LOG")" + +JOURNAL=@journal@ ## ====================================================================================== ## msmtpq can use the following environment variables : @@ -144,6 +146,7 @@ on_exit() {                          # unlock the queue on exit if the lock was ## display msg to user, as well ## log() { +  local NAME=msmtpq local ARG RC PFX PFX="$('date' +'%Y %d %b %H:%M:%S')" # time stamp prefix - "2008 13 Mar 03:59:45 " @@ -161,10 +164,19 @@ log() { done fi +  if [ "$JOURNAL" = "Y" ]; then +    for ARG; do +      [ -n "$ARG" ] && +        echo "$ARG" | systemd-cat -t "$NAME" -p info +    done +  fi + if [ -n "$RC" ] ; then             # an error ; leave w/error return [ -n "$LKD" ] && lock_queue -u   # unlock here (if locked) [ -n "$MSMTPQ_LOG" ] &&  echo "    exit code = $RC" >> "$MSMTPQ_LOG" # logging ok ; send exit code to log +    [ "$JOURNAL" = "Y" ] &&  +      echo "exit code= $RC" | systemd-cat -t "$NAME" -p emerg exit "$RC"                       # exit w/return code fi } </ins>