jiebi/CodeConvo huggingface dataset:
Code change:
}; config = mkMerge [ <ins> ({ # minimal configuration file to make lvmconfig/lvm2-activation-generator happy environment.etc."lvm/lvm.conf".text = "config {}"; }) </ins> (mkIf (!config.boot.isContainer) { systemd.tmpfiles.packages = [ cfg.package.out ]; environment.systemPackages = [ cfg.package ];

Related discussion:
text: Describe the bug While the configuration contains no settings related to LVM, is launched during boot, and so on, and the "lvm2-activation-generator: lvmconfig failed" message is logged in the journal. Expected behavior At least, does not produce error messages. It might be better if the service is not activated if the system does not use LVM at all. Additional context may or may not be relevant. Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(omasanori): nixpkgs: Maintainer information:
cc
I'll try to find some time to look into this, as I might be responsible for this.
I got this error when running in the console. It just froze, didn't reboot. Hitting enter put me back into the shell. Doing shutdown -h now worked. Very strange ..
I strongly suspect that your freeze was not caused by this warning message.
Yeah, so this was most likely caused by , which combined with the rest of leads to systemd being aware of lvm2 things. lvm2 was already in and for anything that's not a container, before this, but now it's also in . As for why this happens, it looks like it's , which fails when does not return what it expects. Since we do not install the default lvm config, it fails like so: The easiest solution to this is probably to install the default config file to . There is a problem with that though. If we use , we cannot use anymore to append any settings. We also cannot "copy" the defaults into e.g. with , because that would be import from derivation. So the remaining option is to simply set some default settings, which also kind of sucks, because then we need to track upstream on those, but it's probably our best option. If you have any other/better ideas, I'd gladly go for those, but if nobody does, I'll go with specifying some defaults, in a few days.
+1 to importing upstream defaults as it seems the safest option if it tracks upstream properly, even though it will certainly increase the maintenance cost.
I also would just create a default configuration if it is not possible to disable lvm2-activation-generator somehow if lvm is not used.
Detecting if lvm is used sadly isn't trivial.
Code change:
}; config = mkMerge [ <ins> ({ # minimal configuration file to make lvmconfig/lvm2-activation-generator happy environment.etc."lvm/lvm.conf".text = "config {}"; }) </ins> (mkIf (!config.boot.isContainer) { systemd.tmpfiles.packages = [ cfg.package.out ]; environment.systemPackages = [ cfg.package ];

Related discussion:
text: For filesystems (in ) we can just look at the and enable the respective kernel modules and tools, but how would that be done for lvm?
Maybe it would be possible to fix/patch(&upstream) the generator?
lvm seems to have its default hard coded so we don't need to copy over the whole file. To fix the loading error I just an almost empty configuration to make the warning go away:
Code change:
xdotool = callPackage ../tools/X11/xdotool { }; <ins> xed-editor = callPackage ../applications/editors/xed-editor { xapps = cinnamon.xapps; }; </ins> xenPackages = recurseIntoAttrs (callPackage ../applications/virtualization/xen/packages.nix {}); xen = xenPackages.xen-vanilla;

Related discussion:
text: Xed Text Editor from Linux Mint Text editor from the Linux Mint distribution xed text editor homepage URL: source URL: license: gpl2 platforms: linux
needs an update of a dependency to package newest version 2.8.4
Code change:
libcaca = null; }; <del> vlc_qt5 = vlc; </del> libvlc = vlc.override { withQt5 = false; qtbase = null;

Related discussion:
text: Packaged VLC does not seem to support wayland. Steps to reproduce the behavior: vlc with on e.g. sway opens as a XWayland window VLC opens as a Wayland native window Not applicable Possibly related to VLC not depending on qtwayland. Please run and paste the result. EDIT: Typo
It is strange. I built it and verified, it is not linked with QT libraries even if they are put as inputs.
Is also pulled in as an input?
Nope. Working on it now. First encounter: Wayland is considered experimental and disabled by default.
Can you test the patch?
Works like a charm, thanks a lot! :)
I'm on NixOS 23.05 and discovered that vlc prefers to use XWayland if var is set. If I unset then vlc starts in Wayland mode. Does anyone know how to make it to start on Wayland by default?
For now I hacked it with: Special thanks to
Well, if this is hardcoded on VLC, there is nothing to do (besides maybe searching some hidden commandline flag).
The "use QTQPAPLATFORM be damned" behavior is apparently just what QT does, and is not specific to VLC
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Here is the updated wrap that also addresses the desktop file
Code change:
let pname = "shogun"; version = "6.1.4"; rxcppVersion = "4.0.0"; gtestVersion = "1.8.0"; srcs = { toolbox = fetchFromGitHub { owner = pname + "-toolbox";

Related discussion:
text: shogun fails to build since the eigen 3.4.0 bump: The package is a likely candidate for removal. Upstream is unresponsive and development has halted. Removed from debian: Removed from fedora: Blocking vcpkg update: Please run and paste the result. Maintainer information:
I think you were the last one to modify this package, so please speak up if you need it. Also pinging Last call - if no one responds within the next week, I'll open a PR to remove this package.
Yes, I was working on making it build on Darwin and adding it as a Python 3 module. Well, I did, but I didn't feel motivated to create a PR. As you comment, upstream has been inactive for almost a year, the latest release is several years old, and it becomes harder and harder to make it work, and the patches would start to accumulate. To make it work on Darwin we need two upstream patches that fix the build with newer compiler versions. In the current derivation, the Python interface is not built because the CMake flag is not the right one. When enabled, Swig 3 is used to generate the Python interface, but Swig 3 doesn't support Python 3.8+ (and with Swig 4 just fails). It can be fixed with a patch, that feels more like a hack, intercepting the Makefile build, so I am not happy with it: Another small patch is needed to fix the deprecated . Also, I wasn't happy that adding it as a Python module will recompile the entire library again, which takes too much time IMO. I haven't checked if it is possible to build with Eigen 3.4 because it takes forever to compile. It could probably work on the development version. Note that the development version doesn't support Eigen 3.4 because of this, but it may work: But there is no such limitation on the 6.1.4 release, which probably means it would require another patch to fix the code, if somebody figures out. So, I'd argue that the package is too old now, and the derivation has too many issues, and it's too much of a hassle to maintain it, so it's probably better to just remove it.
I decided to sit and take a look at the error, and I actually fixed it.
Code change:
let pname = "shogun"; version = "6.1.4"; rxcppVersion = "4.0.0"; gtestVersion = "1.8.0"; srcs = { toolbox = fetchFromGitHub { owner = pname + "-toolbox";

Related discussion:
text: I don't really use Eigen but the patch makes sense. So, I can send a PR to keep this package on the repo for another cycle at least. I mean, I already did all of the work and it builds. Other distros end up removing it because nobody cares to maintain it.
Nice! Thanks for looking into it. Like you said, if you've already done the work to get it working I don't see why not. If it's too much work to keep it working in the future we can always revisit this and drop it.
Code change:
}) ]; <ins> # Tweaks to fix undefined variable substitutions # https://github.com/HowardHinnant/date/pull/538#pullrequestreview-1373268697 postPatch = '' substituteInPlace date.pc.in  --replace '@CMAKE_INSTALL_LIB@' '@CMAKE_INSTALL_FULL_LIBDIR@'  --replace '@CMAKE_INSTALL_INCLUDE@' '@CMAKE_INSTALL_FULL_INCLUDEDIR@'  --replace '@PACKAGE_VERSION@' '${version}' ''; </ins> nativeBuildInputs = [ cmake ]; cmakeFlags = [

Related discussion:
text: The pkg-config file in pkg looks like this: The and variables are empty. The keyword is also empty. As a result, the flags returned by pkg-config are wrong and checking the version does not work. Note the empty and and that the package version is actually 3.0.1, i.e. = 3.0.0. and should point to the correct directories in the and outputs of the pkg.
Code change:
github = "auchter"; githubId = 1190483; }; <ins> aucub = { name = "aucub"; email = "dr56ekgbb@mozmail.com"; github = "aucub"; githubId = 78630225; }; </ins> augustebaum = { email = "auguste.apple@gmail.com"; github = "augustebaum";

Related discussion:
text: waveterm Modern open-source terminal emulator supporting inline rendering. homepage URL: source URL: license: Apache-2.0 platforms: linux, darwin
I've tried, got stuck at packaging waveterm with scripthaus. However i have packaged scripthaus which is required here. Maybe someone with better understanding of nodejs will make it.
Here's my attempt at cobbling something together for linux, which seems to be working locally for me (well, it's "working" in the sense that it builds, the GUI shows up and the basic shell features seem to be working): I wasn't able to get it building using the provided scripthaus scripts yet, but I'm also quite inexperienced in this area so that could be why. I'm currently using and instead, basing it off from a bunch of other electron and go packages on nixpkgs. I haven't carried across all the build flags from waveterm's provided scripthaus scripts though, and you might also see some vestigial code that I copied from other packages that don't apply for waveterm which I haven't cleaned up yet. If I have time I might give the scripthaus scripts another try. Some other remaining todos that I'm aware of include the desktop icon, getting it working on darwin, checking the AI features, checking that the package includes all the dependencies it needs at runtime, and fixing a failing test regarding command completions. Please feel free to continue working off from what I have if it helps, especially if I don't get back to this soon.
Waveterm offers a packages. I was installing and noticed that it fetched a package and installed it. Is it not possible to do the same? I also saw in this that packages are pulled for Opera and Skype as well. So, is it possible to do the same for Waveterm as well?
Forced M1 user here, tried packaging wave but didn't manage to make the scripthaus scripts run without fails, mainly because both go and scripthaus try to create cache directories and I didn't manage to disable this behaviour.
Code change:
github = "auchter"; githubId = 1190483; }; <ins> aucub = { name = "aucub"; email = "dr56ekgbb@mozmail.com"; github = "aucub"; githubId = 78630225; }; </ins> augustebaum = { email = "auguste.apple@gmail.com"; github = "augustebaum";

Related discussion:
text: I also tried to use package but due to it requiring electron and it not being available for the M1 architecture I couldn't compile the application from source, so I think packaging for the M1 will have to be done through the .dmg that they have on the realeases page. I'll try packaging the application when I have time this weekend.
In the end I couldn't resist and worked something out for M1 in my free time, this works and creates a ./result directory with an application I can open, so I think it's pretty much done. The only thing missing is integrating with solution... I'll try doing it this weekend.
where did you get that info from?
When I searched for electron on Nix packages it never appeared a platform for darwin... I know it should be possible to have electron in M1 but at least on Nix it isn't packaged for it already. <img width="313" alt="image" src=""
Oh, nice! I thought the panel with platforms displayed all of them, clearly it doesn't. I'll first merge the linux build mentioned previously and then I'll try using that electron to build the app from scratch. Thank you!
Code change:
<ins> diff --git a/build.gradle b/build.gradle index 7025b2b..d063da3 100644 --- a/build.gradle +++ b/build.gradle @@ -20,6 +20,11 @@ repositories { } +tasks.withType(AbstractArchiveTask) { +    preserveFileTimestamps = false +    reproducibleFileOrder = true +} + licenseReport { renderers = [new JsonReportRenderer()] </ins>

Related discussion:
text: Project description <!-- Describe the project a little: --Tools to manipulate pdf files. Metadata homepage URL: source URL: license: mit, bsd, gpl2+ , ... platforms: unix, linux, darwin, ... Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I'll see what I can do, should be good practice working with Gradle apps
Thank you Tom, much appreciated, best of luck.
By the way, I have pretty much succeeded in packaging it, and it seemed to run fine. Just forgot about it a little. The only issue with the package currently is that jar files are created non-deterministically by default (timestamps are not set to a fixed time). After using the fixup hook made for this situation (unzip and rezip the jar file) springboot doesn't recognise its files anymore, which is really weird. So it stayed non-deterministic. So I have two options: A) use the non-deterministic package or B) use the prebuilt jar from GitHub. The latter one is much less complex to work with.
See if this helps you.. or this discussion from the top (concerning java apps)...
Thanks for the pointers, though the second thing linked is my own post :) I finally managed to figure out how to fix the jar timestamps, so I'll open a PR adding the package
Thank you for your help . Much appreciated.. sorry for the delay. had a rough week last and it spilled into this one. Looking forward to using stirling-pdf on nixos.
Code change:
sha256 = "09xz06g57wxbacic617pq9c0qb7nly42gif0raplldn5lw964xl2"; revert = true; }) <ins> (fetchpatch { name = "CVE-2021-4145.patch"; url = "https://gitlab.com/qemu-project/qemu/-/commit/66fed30c9cd11854fc878a4eceb507e915d7c9cd.patch"; sha256 = "10za2nag51y4fhc8z7fzw3dfhj37zx8rwg0xcmw5kzmb0gyvvz70"; }) </ins> ] ++ lib.optional nixosTestRunner ./force-uid0-on-9p.patch ++ lib.optionals stdenv.hostPlatform.isMusl [ ./sigrtminmax.patch

Related discussion:
text: , CVSSv3=6.5 (nixos-21.11, nixos-unstable) A NULL pointer dereference issue was found in the block mirror layer of QEMU in versions prior to 6.2.0. The pointer is dereferenced in mirrorwaiton_conflicts() without ensuring that it's not NULL. A malicious unprivileged user within the guest could use this flaw to crash the QEMU process on the host when writing data reaches the threshold of mirroring node. Scanned versions: nixos-21.11: ; nixos-unstable: . Cc Cc
This is fixed on master since we have QEMU 6.2.0. It's not included in 6.1.1 though, so needs to be fixed on stable. Probably after since it'd be a merge conflict.
Code change:
# Note: fish completion script is not supported. $out/bin/rustup completions bash cargo > "$out/share/bash-completion/completions/cargo" $out/bin/rustup completions zsh cargo >  "$out/share/zsh/site-functions/_cargo" <ins> # add a wrapper script for ld.lld mkdir -p $out/nix-support substituteAll ${../../../../../pkgs/build-support/wrapper-common/utils.bash} $out/nix-support/utils.bash substituteAll ${../../../../../pkgs/build-support/bintools-wrapper/add-flags.sh} $out/nix-support/add-flags.sh substituteAll ${../../../../../pkgs/build-support/bintools-wrapper/add-hardening.sh} $out/nix-support/add-hardening.sh export prog='$PROG' export use_response_file_by_default=0 substituteAll ${../../../../../pkgs/build-support/bintools-wrapper/ld-wrapper.sh} $out/nix-support/ld-wrapper.sh chmod +x $out/nix-support/ld-wrapper.sh </ins> ''; <ins> env = lib.optionalAttrs (pname == "rustup") { inherit (stdenv.cc.bintools) expandResponseParams shell suffixSalt wrapperName coreutils_bin; hardening_unsupported_flags = ""; }; </ins> meta = with lib; { description = "The Rust toolchain installer"; homepage = "https://www.rustup.rs/";

Related discussion:
text: Running a fresh fails, the core message being: Steps to reproduce the behavior: a rust project (or if you already have one) Either the rustup gcc/ld to be patched for NixOS use, or rust to use the system gcc/ld. Please run and paste the result.
Actually, it looks like this is an issue specifically appearing with ; so I'll try to pass the message upstream.
Very specifically, introducing the issue, when it has been decided to switch from the system linker to . I suppose the new binaries should also be elf-patched?
Patching those binaries will make them execute, but they also need the applied so that the binaries they build will also get patched automatically.
Code change:
let pname = "osu-lazer-bin"; <del> version = "2023.1026.0"; </del> <ins> version = "2023.1114.1"; </ins> name = "${pname}-${version}"; osu-lazer-bin-src = { aarch64-darwin = { url = "https://github.com/ppy/osu/releases/download/${version}/osu.app.Apple.Silicon.zip"; <del> sha256 = "sha256-6IaN189cV/ORP77zrjdcCPwPzNR/W6JmrZXVasCx8MQ="; </del> <ins> sha256 = "sha256-MQkHbodSkAQQpjaBP+Q35afcCrgcie6UoUldc+vjRA0="; </ins> }; x86_64-darwin = { url = "https://github.com/ppy/osu/releases/download/${version}/osu.app.Intel.zip"; <del> sha256 = "sha256-XrlajKT3GLjfj800mULj9iwkF9Bvx9Rlz56K6welq2U="; </del> <ins> sha256 = "sha256-40ylXbn9jV9v+ve1hFwhT5/jhzNfWHjL2WIplVUD2qk="; </ins> }; x86_64-linux = { url = "https://github.com/ppy/osu/releases/download/${version}/osu.AppImage"; <del> sha256 = "sha256-yr7PtBUBE0tB0giAE8aQCNJvxS/tMzlLWpJ3NyosQZk="; </del> <ins> sha256 = "sha256-Q2z2Js0Zc9nvyQNxzLuuV7TcwiNIRo+RMRER6ZYgh74="; </ins> }; }.${stdenv.system} or (throw "${pname}-${version}: ${stdenv.system} is unsupported.");

Related discussion:
text: Package name: osu-lazer-bin Latest released version: <!-- Search your package here: --- Current version on the unstable channel: 2023.1026.0 Current version on the stable/release channel: 2023.511.0 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers Note for maintainers: Please tag this issue in your PR.
Code change:
./services/misc/tautulli.nix ./services/misc/tiddlywiki.nix ./services/misc/tp-auto-kbbl.nix <ins> ./services/misc/turn-rs.nix </ins> ./services/misc/tuxclocker.nix ./services/misc/transfer-sh.nix ./services/misc/tzupdate.nix

Related discussion:
text: Project description A pure rust implemented turn server. <!-- Describe the project a little: --Metadata homepage URL: source URL: license: gpl-3.0 platforms: linux, windows Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
runHook postInstall ''; <ins> fixupPhase = '' runHook preFixup wrapProgramShell $out/share/spotify/spotify  ''${gappsWrapperArgs[@]}  ${lib.optionalString (deviceScaleFactor != null) '' --add-flags "--force-device-scale-factor=${toString deviceScaleFactor}"  ''}  --prefix LD_LIBRARY_PATH : "$librarypath"  --prefix PATH : "${gnome.zenity}/bin"  --add-flags "''${NIXOS_OZONE_WL:+''${WAYLAND_DISPLAY:+--enable-features=UseOzonePlatform --ozone-platform=wayland}}" runHook postFixup ''; </ins> meta = meta // { maintainers = with lib.maintainers; [ eelco ftrvxmtrx sheenobu timokau ma27 ]; };

Related discussion:
text: When adding a local directory to spotify client, it always fails due to missing gsettings schema(s) and spotify crashes. This issue is the same as the one from 2021 Works as expected on arch based distros indicating that this an issue with nixpkgs Steps to reproduce the behavior: spotify Settings on Show Local Files ADD A SOURCE button Open a file chooser to select which directory to be . <!-- 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]:
I can't actually reproduce the issue, but I do see some inherent packaging issues that I attempted to address. Can you test the linked PR?
I also cannot reproduce the issue. However, I have never actually had local files appear after I have their directories (without crashing).
Yes your PR solves the issue!!! Thanks a lot for the fast reply :) I would really like to learn more about packaging programs for nixpkgs so I can contribute more myself. Do you have any recommendations on how to learn the different options for mkDerivation, the different phases, wrapping programs and libraries, etc.? I feel like the documentation is basically non-existend. If anything comes to mind (including workshops, etc.) feel free to just send me an email (this issue is probably the wrong place to discuss this)
Code change:
inherit pname; version = "2.0.1"; <del> outputs = [ "bin" "out" "dev" "doc" "man" ]; </del> <ins> outputs = [ "out" "lib" "dev" "doc" "man" ]; </ins> src = fetchFromGitLab { domain = "salsa.debian.org";

Related discussion:
text: uses two actions and do get necessary authorization via . but these actions are not properly registed, leading to error: (It can be verified that these actions don't exist by using ) This breaks and . I tried both pcsclite 1.9.5 and 2.0.1 ending up with the same error. Steps to reproduce the behavior: and in , configure your smartcard (yubikey) to use yubikey error There actions are registered correctly and usable. Please run and paste the result. I'm using flakes (no channels). Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
correct description of your effect, i am not able to use my yubikey with gpg.
This can be solved by
this works, thanks! but this is really unintuitive, given that is already adding the package to : I am leaving this open as I believe a proper fix should be provided in the module itself.
Same issue here. It was working approx. last Dec. I don't have a specific commit hash. Adding to works for me.
Looks like a regression in () - is implying to me that polkit actions get included in the output, however: isn't included, which explains why adding to fixes the issue. Solution ideas: Add to . Not sure about this one? seems to also contain some libraries that probably don't need to be installed. Install polkit actions to instead of . IMO this one makes the most sense, especially as it seems to have been the previous behaviour before this change.
I was bitten by this when attempting to update over the weekend as well. In my case it prevented login because I use smartcards for user login which made debugging difficult due to the number of reboots required. I tend to agree with that going back to having the polkit actions file in the output instead of makes the most sense. That will mean that of the pcsc module will again result in the polkit action file being to the system configuration.
Cc: ()
I also think the location should be fine, the files are also there.
I ran into this issue when I couldn't access my yubikey anymore via pcsc for commits. The above solution worked for me.