jiebi/CodeConvo huggingface dataset:
Code change:
The issue is what the title says. By half, I mean and for my previously used from emacs-overlay to your system the eln cache in your home, e.g. to open emacs for the manual for by and inputing the eln cache in your home: , you will find together other eln cache. I think this is a bug since is builtin for emacs and it's eln cache should be distributed together with . Uses of will not need to native-compile builtin libraries themselves. does distributed together with from emacs-overlay I used before. It's . might be related to the bump of 28 , so
The difference between the two versions is that one is built from the tarball, while the other is built from Git. The tarball includes byte-compiled () files but not native-compiled () files. The build notices the files and does not rebuild them, but native-compilation is a side-effect of byte-compilation and so the files aren't built either. (Almost all of the files you see for the new version are trampolines, there are only 3 non-trampoline files.)
ideally we'd run , which is the expected way of deleting such things (or perhaps even ). But the tarball only has a , so we'd need to run , then , then again, which is super ugly. Hopefully deleting the files the naïve way is enough?
I think maybe we should just skip the tarball entirely and fetch it from git instead.
There are other side-effects caused by skipping the tarball. This claims, for example, that bootstrapping is only expected to happen to emacs developers. Part of bootstrapping is converting the Japanese input method dictionaries, and this takes some amount of time. They're in the tarball at , but are absent in the git checkout.
That's a good point, I would still rather inflate build times a bit and exercise bootstrapping as a part of our regular build though to completely avoid these types of issues.
I'm hesitant about building things in a way that upstream doesn't expect, unless necessary to adapt for nixpkgs. For a related example, using the repo instead of the tar distribution for Ruby caused a subtle problem where the commit hash was not propagated, which broke the bootsnap gem's cache invalidation (fixed in , by using the tarball). The real question here, I think, is how upstream expects native compilation to be used if their tarball doesn't support it.

Related discussion:
text: , withSQLite3 ? false , withCsrc ? true , withWebP ? false <del> , srcRepo ? false, autoreconfHook ? null, texinfo ? null </del> <ins> , srcRepo ? true, autoreconfHook ? null, texinfo ? null </ins> , siteStart ? ./site-start.el , nativeComp ? false , withAthena ? false
Code change:
The issue is what the title says. By half, I mean and for my previously used from emacs-overlay to your system the eln cache in your home, e.g. to open emacs for the manual for by and inputing the eln cache in your home: , you will find together other eln cache. I think this is a bug since is builtin for emacs and it's eln cache should be distributed together with . Uses of will not need to native-compile builtin libraries themselves. does distributed together with from emacs-overlay I used before. It's . might be related to the bump of 28 , so
The difference between the two versions is that one is built from the tarball, while the other is built from Git. The tarball includes byte-compiled () files but not native-compiled () files. The build notices the files and does not rebuild them, but native-compilation is a side-effect of byte-compilation and so the files aren't built either. (Almost all of the files you see for the new version are trampolines, there are only 3 non-trampoline files.)
ideally we'd run , which is the expected way of deleting such things (or perhaps even ). But the tarball only has a , so we'd need to run , then , then again, which is super ugly. Hopefully deleting the files the naïve way is enough?
I think maybe we should just skip the tarball entirely and fetch it from git instead.
There are other side-effects caused by skipping the tarball. This claims, for example, that bootstrapping is only expected to happen to emacs developers. Part of bootstrapping is converting the Japanese input method dictionaries, and this takes some amount of time. They're in the tarball at , but are absent in the git checkout.
That's a good point, I would still rather inflate build times a bit and exercise bootstrapping as a part of our regular build though to completely avoid these types of issues.
I'm hesitant about building things in a way that upstream doesn't expect, unless necessary to adapt for nixpkgs. For a related example, using the repo instead of the tar distribution for Ruby caused a subtle problem where the commit hash was not propagated, which broke the bootsnap gem's cache invalidation (fixed in , by using the tarball). The real question here, I think, is how upstream expects native compilation to be used if their tarball doesn't support it.

Related discussion:
text: patches = patches fetchpatch; <del> src = fetchurl { url = "mirror://gnu/emacs/${name}.tar.xz"; </del> <ins> src = fetchFromSavannah { repo = "emacs"; rev = version; </ins> inherit sha256; };
Code change:
On startup, Tor Browser doesn't start if some variables about Wayland aren't set. Steps to reproduce the behavior: and (if set) Tor Browser in a terminal and see the error message. Tor Browser should start. This issue was caused by . currently does not fix the problem. In the meantime, an easy fix would be : <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Notifying peoples from the aforementioned PRs instead. Please run and paste the result.
I can confirm this issue
thanks !

Related discussion:
text: TMPDIR="''${TMPDIR:-/tmp}"  HOME="$HOME"  XAUTHORITY="''${XAUTHORITY:-$HOME/.Xauthority}"  <del> DISPLAY="$DISPLAY"  </del> <ins> DISPLAY="''${DISPLAY:-}"  </ins> DBUS_SESSION_BUS_ADDRESS="''${DBUS_SESSION_BUS_ADDRESS:-unix:path=$XDG_RUNTIME_DIR/bus}"   XDG_DATA_HOME="$HOME/.local/share"
Code change:
On startup, Tor Browser doesn't start if some variables about Wayland aren't set. Steps to reproduce the behavior: and (if set) Tor Browser in a terminal and see the error message. Tor Browser should start. This issue was caused by . currently does not fix the problem. In the meantime, an easy fix would be : <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Notifying peoples from the aforementioned PRs instead. Please run and paste the result.
I can confirm this issue
thanks !

Related discussion:
text: PULSE_SERVER="''${PULSE_SERVER:-}"  PULSE_COOKIE="''${PULSE_COOKIE:-}"   <del> MOZ_ENABLE_WAYLAND=$MOZ_ENABLE_WAYLAND  WAYLAND_DISPLAY="$WAYLAND_DISPLAY"  XDG_RUNTIME_DIR="$XDG_RUNTIME_DIR"  XCURSOR_PATH="$XCURSOR_PATH"  </del> <ins> MOZ_ENABLE_WAYLAND="''${MOZ_ENABLE_WAYLAND:-}"  WAYLAND_DISPLAY="''${WAYLAND_DISPLAY:-}"  XDG_RUNTIME_DIR="''${XDG_RUNTIME_DIR:-}"  XCURSOR_PATH="''${XCURSOR_PATH:-}"  </ins>  APULSE_PLAYBACK_DEVICE="''${APULSE_PLAYBACK_DEVICE:-plug:dmix}"
Code change:
On startup, Tor Browser doesn't start if some variables about Wayland aren't set. Steps to reproduce the behavior: and (if set) Tor Browser in a terminal and see the error message. Tor Browser should start. This issue was caused by . currently does not fix the problem. In the meantime, an easy fix would be : <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Notifying peoples from the aforementioned PRs instead. Please run and paste the result.
I can confirm this issue
thanks !

Related discussion:
text: LD_LIBRARY_PATH=$libPath $TBB_IN_STORE/TorBrowser/Tor/tor --version >/dev/null echo "Checking tor-browser wrapper ..." <del> DISPLAY="" MOZ_ENABLE_WAYLAND="" WAYLAND_DISPLAY="" XAUTHORITY=""  XCURSOR_PATH="" XDG_RUNTIME_DIR="" XDG_SESSION_TYPE=""  DBUS_SESSION_BUS_ADDRESS="" TBB_HOME=$(mktemp -d)  </del> <ins> TBB_HOME=$(mktemp -d)  </ins> $out/bin/tor-browser --version >/dev/null '';
Code change:
The option, which enables by default on high-resolution displays like my 4K laptop screen, is supposed to set the console font within the initrd before displaying the LUKS password prompt. However, with , this does not happen until stage 2, so the prompt is tiny. Enable , , and . The console font should be switched before the LUKS password prompt, not after.
Relevant code is probably that it sets . should then properly set everything up if it can find its files in :
Does it work when you do ?
No, it can’t, because points to a font file that’s not present in the initrd.
This works though. It’s a little jarring in that the font is changed about a second before the framebuffer resolution is changed, so it’s temporarily huge. Ideally those would happen simultaneously. But at least they both happen in time for the LUKS prompt.

Related discussion:
text: "${config.boot.initrd.systemd.package}/lib/systemd/systemd-vconsole-setup" "${config.boot.initrd.systemd.package.kbd}/bin/setfont" "${config.boot.initrd.systemd.package.kbd}/bin/loadkeys" <del> "${config.boot.initrd.systemd.package.kbd.gzip}/bin/gzip" # keyboard layouts are compressed </del> <ins> "${config.boot.initrd.systemd.package.kbd.gzip}/bin/gzip" # Fonts and keyboard layouts are compressed ] ++ optionals (hasPrefix builtins.storeDir cfg.font) [ "${cfg.font}" ] ++ optionals (hasPrefix builtins.storeDir cfg.keyMap) [ "${cfg.keyMap}" </ins> ]; systemd.services.reload-systemd-vconsole-setup =
Code change:
, an application that simulates user input to keep the screen awake when pressing gamepad buttons, relies on on Plasma Wayland to do this. However, isn't installed (or at least, it's not in ) with a default Plasma installation, making not work: (Among other errors) Steps to reproduce the behavior: Plasma (), without "installing" ; a Plasma Wayland session; ; 'll see the error message, and the program won't work. There is no error message and the program works (which is what happens by installing ). I don't know if the best solution is to add to Plasma or to . I'd vote for the former, since (if I'm not wrong), is already installed with Plasma, it's just not in PATH, and I don't see the harm in being there. Still, that's why I opened an issue. By the way, can't be installed "alone". NixOS says: <!-- 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.

Related discussion:
text: plasma-browser-integration konsole oxygen <ins> (lib.getBin qttools) # Expose qdbus in PATH </ins> ]; in requiredPackages
Code change:
, an application that simulates user input to keep the screen awake when pressing gamepad buttons, relies on on Plasma Wayland to do this. However, isn't installed (or at least, it's not in ) with a default Plasma installation, making not work: (Among other errors) Steps to reproduce the behavior: Plasma (), without "installing" ; a Plasma Wayland session; ; 'll see the error message, and the program won't work. There is no error message and the program works (which is what happens by installing ). I don't know if the best solution is to add to Plasma or to . I'd vote for the former, since (if I'm not wrong), is already installed with Plasma, it's just not in PATH, and I don't see the harm in being there. Still, that's why I opened an issue. By the way, can't be installed "alone". NixOS says: <!-- 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.

Related discussion:
text: services.accounts-daemon.enable = true; # when changing an account picture the accounts-daemon reads a temporary file containing the image which systemsettings5 may place under /tmp systemd.services.accounts-daemon.serviceConfig.PrivateTmp = false; <ins> services.power-profiles-daemon.enable = mkDefault true; services.system-config-printer.enable = mkIf config.services.printing.enable (mkDefault true); </ins> services.udisks2.enable = true; services.upower.enable = config.powerManagement.enable; <del> services.system-config-printer.enable = mkIf config.services.printing.enable (mkDefault true); </del> services.xserver.libinput.enable = mkDefault true; # Extra UDEV rules used by Solid
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: qtcreator <!-- 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: 5.0.3 desired version: 7.0.1 <!-- 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.
Version 8.0.0 is now available.

Related discussion:
text: <ins> { stdenv , lib , fetchurl , cmake , pkg-config , ninja , python3 , qtbase , qt5compat , qtdeclarative , qtdoc , qtquick3d , qtquicktimeline , qtserialport , qtsvg , qttools , qtwebengine , qtshadertools , wrapQtAppsHook , yaml-cpp , litehtml , gumbo , llvmPackages , rustc-demangle , elfutils , perf }: stdenv.mkDerivation rec { pname = "qtcreator"; version = "9.0.2"; src = fetchurl { url = "https://download.qt.io/official_releases/${pname}/${lib.versions.majorMinor version}/${version}/qt-creator-opensource-src-${version}.tar.xz"; sha256 = "sha256-7KWMxcoNOXiWlAVCYZzyA/WWLuPIggCBIics23Ifoyg="; }; nativeBuildInputs = [ cmake pkg-config qttools wrapQtAppsHook python3 ninja ]; buildInputs = [ qtbase qtdoc qtsvg qtquick3d qtwebengine qtserialport qtshadertools qt5compat qtdeclarative qtquicktimeline yaml-cpp litehtml gumbo llvmPackages.libclang llvmPackages.llvm rustc-demangle elfutils ]; cmakeFlags = [ # workaround for missing CMAKE_INSTALL_DATAROOTDIR # in pkgs/development/tools/build-managers/cmake/setup-hook.sh "-DCMAKE_INSTALL_DATAROOTDIR=${placeholder "out"}/share" # qtdeclarative in nixpkgs does not provide qmlsc # fix can't find Qt6QmlCompilerPlusPrivate "-DQT_NO_FIND_QMLSC=TRUE" "-DWITH_DOCS=ON" "-DBUILD_DEVELOPER_DOCS=ON" "-DBUILD_QBS=OFF" "-DQTC_CLANG_BUILDMODE_MATCH=ON" "-DCLANGTOOLING_LINK_CLANG_DYLIB=ON" ]; qtWrapperArgs = [ "--set-default PERFPROFILER_PARSER_FILEPATH ${lib.getBin perf}/bin" ]; postInstall = '' substituteInPlace $out/share/applications/org.qt-project.qtcreator.desktop  --replace "Exec=qtcreator" "Exec=$out/bin/qtcreator" ''; meta = with lib; { description = "Cross-platform IDE tailored to the needs of Qt developers"; longDescription = '' Qt Creator is a cross-platform IDE (integrated development environment) tailored to the needs of Qt developers. It includes features such as an advanced code editor, a visual debugger and a GUI designer. ''; homepage = "https://wiki.qt.io/Qt_Creator"; license = licenses.lgpl3Plus; maintainers = [ maintainers.rewine ]; platforms = platforms.linux; }; } </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: qtcreator <!-- 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: 5.0.3 desired version: 7.0.1 <!-- 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.
Version 8.0.0 is now available.

Related discussion:
text: inherit (linuxPackages) perf; }; <ins> qtcreator-qt6 = qt6Packages.callPackage ../development/tools/qtcreator/qt6.nix { inherit (linuxPackages) perf; stdenv = llvmPackages_14.stdenv; llvmPackages = llvmPackages_14; }; </ins> qxmledit = libsForQt5.callPackage ../applications/editors/qxmledit {} ; r10k = callPackage ../tools/system/r10k { };
Code change:
I notice zoom-us from nixpkgs-unstable gets killed by SIGILL shortly after the application window is shown. This does not occur when running zoom-us from NixOS 21.11. A strace ends with the following output: Observe that the zoom process is killed by SIGILL shortly after the application window is shown. The Zoom application proceeds to run without crashing. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
I stepped through commits that touched zoom-us. The behavior appears to start with (no launch), resp. with (SIGILL observed).
I can‘t reproduce this issue, at least I get into a video call and to making faces at myself for a minute without issues. I am running zoom 5.10.4, on x86_64-linux with kernel 5.17.9.
I didn't see this on my system using the version from nixpkgs . It's expected that would not launch (it's fixed by the commits after). These should really have been one commit, or in another order to allow bisection, but oh well.
From what I can muster, SIGILL is caught while in It looks like is part of the binary distribution of Zoom and not built as part of nixpkgs? But I figure if can run it with no crash it’s more likely an application bug rather than some ABI issue?
I now notice that one Zoom invocation results in two coredumps. The other one is a SIGSYS arising from libc. I’m not really versed in such dark magics, but FWIW:
I really don't expect to be able to debug this, but could you post the output of and (and maybe if the output is short, particularly around the marker) from gdb on the SIGILL core? To me this really feels like a zoom problem. You don't happen to be using an ancient or unusual processor do you?
It looks like version 5.10.6 (3192) is out for linux now, so it might be worth trying that too.
Cheers, that seems to resolve the problem. Not really, it’s an i9-10885H. In case you’re still curious for whatever reason, I’ve attached the information copied from gdb. Otherwise I’d say this issue is obsoleted by the new Zoom release. (NB just said “No function contains program counter for selected frame.”)
my zoom is dying too, I got it working for now with
Thanks, that's pretty interesting; something jumps into the middle of an instruction. Good that updating it works anyway.

Related discussion:
text: version = { aarch64-darwin = "5.10.4.6592"; x86_64-darwin = "5.10.4.6592"; <del> x86_64-linux = "5.10.4.2845"; </del> <ins> x86_64-linux = "5.10.6.3192"; </ins> }.${system} or throwSystem; srcs = {
Code change:
I notice zoom-us from nixpkgs-unstable gets killed by SIGILL shortly after the application window is shown. This does not occur when running zoom-us from NixOS 21.11. A strace ends with the following output: Observe that the zoom process is killed by SIGILL shortly after the application window is shown. The Zoom application proceeds to run without crashing. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
I stepped through commits that touched zoom-us. The behavior appears to start with (no launch), resp. with (SIGILL observed).
I can‘t reproduce this issue, at least I get into a video call and to making faces at myself for a minute without issues. I am running zoom 5.10.4, on x86_64-linux with kernel 5.17.9.
I didn't see this on my system using the version from nixpkgs . It's expected that would not launch (it's fixed by the commits after). These should really have been one commit, or in another order to allow bisection, but oh well.
From what I can muster, SIGILL is caught while in It looks like is part of the binary distribution of Zoom and not built as part of nixpkgs? But I figure if can run it with no crash it’s more likely an application bug rather than some ABI issue?
I now notice that one Zoom invocation results in two coredumps. The other one is a SIGSYS arising from libc. I’m not really versed in such dark magics, but FWIW:
I really don't expect to be able to debug this, but could you post the output of and (and maybe if the output is short, particularly around the marker) from gdb on the SIGILL core? To me this really feels like a zoom problem. You don't happen to be using an ancient or unusual processor do you?
It looks like version 5.10.6 (3192) is out for linux now, so it might be worth trying that too.
Cheers, that seems to resolve the problem. Not really, it’s an i9-10885H. In case you’re still curious for whatever reason, I’ve attached the information copied from gdb. Otherwise I’d say this issue is obsoleted by the new Zoom release. (NB just said “No function contains program counter for selected frame.”)
my zoom is dying too, I got it working for now with
Thanks, that's pretty interesting; something jumps into the middle of an instruction. Good that updating it works anyway.

Related discussion:
text: }; x86_64-linux = fetchurl { url = "https://zoom.us/client/${version}/zoom_x86_64.pkg.tar.xz"; <del> sha256 = "9gspydrGaEjzAM0nK1u0XNm07HTupJ2wnPxCFWy+Nts="; </del> <ins> sha256 = "8QIkF5+875VFoGK6T0CROsqML6bJDG934c1gkuz8Klk="; </ins> }; };