jiebi/CodeConvo huggingface dataset:
Code change:
configureFlags = [ "--enable-srt" # Explicit enable srt to ensure the patch is applied. "--with-kde-solid=$out/share/apps/solid/actions" <del> ] ++ optional onlyLibVLC "--disable-vlc" ++ optional skins2Support "--enable-skins2" ++ optionals chromecastSupport [ </del> <ins> ] ++ optional onlyLibVLC "--disable-vlc" ++ optional skins2Support "--enable-skins2" ++ optional waylandSupport "--enable-wayland" ++ optionals chromecastSupport [ </ins> "--enable-sout" "--enable-chromecast" "--enable-microdns"

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:
qt5.wrapQtAppsHook ]; buildInputs = [ libjack2 bash ]; <del> propagatedBuildInputs = [ pydbus pyliblo pyqt5 ]; </del> <ins> propagatedBuildInputs = [ pyliblo pyqt5 ]; </ins> dontWrapQtApps = true; # The program is a python script.

Related discussion:
text: Package name: raysession Latest released version: 0.14.2 Current version on the unstable channel: 0.13.1 Current version on the stable/release channel: 0.13.1 Notify maintainers Note for maintainers: Please tag this issue in your PR.
Update PR:
Code change:
dontConfigure = true; installPhase = '' <ins> runHook preInstall </ins> mkdir -p $out/{bin,opt/${basename},share} # Install all files, remove unnecessary ones cp -a . $out/opt/${basename}/ rm -r $out/opt/${basename}/{{add,remove}-menuitem.sh,credits.html,icons/} <del> wrapProgram $out/opt/${basename}/${basename} --add-flags "--no-version-check" --prefix LD_LIBRARY_PATH : ${runtimeLibs} </del> ln -s "$out/opt/${basename}/${basename}" $out/bin/ <del> ln -s "${desktopItem}/share/applications" $out/share/ </del> <ins> cp -r "${desktopItem}/share/applications" $out/share/ runHook postInstall ''; preFixup = '' gappsWrapperArgs+=( --add-flags "--no-version-check"  --prefix LD_LIBRARY_PATH : ${runtimeLibs}  --prefix PATH : ${runtimeBins} ) </ins> ''; desktopItem = makeDesktopItem {

Related discussion:
text: Cannot view any content when running the program because it complains about missing binaries. Steps to reproduce the behavior: to watch any stream No errors, stream works system: host os: multi-user?: sandbox: version: channels(admin): nixpkgs: Add and as runtime dependencies because the following works for me:
Code change:
dwarfs = callPackage ../tools/filesystems/dwarfs { }; <ins> etlegacy = callPackage ../games/etlegacy { lua = lua5_4; }; </ins> copier = callPackage ../tools/misc/copier { }; gamemode = callPackage ../tools/games/gamemode {

Related discussion:
text: Project description ET: Legacy is an open source project based on the code of Wolfenstein: Enemy Territory which was released in 2010 under the terms of the GPLv3 license. Metadata homepage URL: source URL: license: gpl3 platforms: unix, linux, darwin
I got a derivation to work: This is for the 32-bit build, client only. Run and use the binary. Planning to properly package it and contribute to nixpkgs, but since it's my first package it'll require some more time. Also planning to get the server and omnibot working.
I marked this as stale due to inactivity. &rarr;
Still interested.
My version of derivation gist doesn't seem to work now that I've upgraded to NixOS 22.05. Haven't had time to investigate too much yet. Whether I try to join an online game server or host a game, I get the below error:
This adaptation of gist is working for me. It's currently for the 32-bit Linux version only, so produces a package . There is an option to use the mod libs built by the ET Legacy project (CI pipeline) or compile them locally.
Hi guys Based on gist I did compiled using NixOS VM Machine it runs fine but there a small quirks there Date is not set correctly it is set to beginning of the time :D Also does ignores manually set env variables ?
Added those 2 in etlegacy*.nix files ` Those 2 should fix issue with correct compile date and naming scheme to build non package But it does not Am I doing something wrong ? :D
Package created and pull request created. Just waiting on PR to be approved so the package can be to nixpkgs.
Is it normal I cannot find the package in the unstable channel?
I think there may be some delay as it migrates to the unstable channel, and then into 23.05.
it seems to be in unstable now.
Code change:
liberation_ttf_v1_from_source = throw "'liberation_ttf_v1_from_source' has been renamed to/replaced by 'liberation_ttf_v1'"; # Converted to throw 2022-02-22 liberation_ttf_v2_from_source = throw "'liberation_ttf_v2_from_source' has been renamed to/replaced by 'liberation_ttf_v2'"; # Converted to throw 2022-02-22 liberationsansnarrow = throw "'liberationsansnarrow' has been renamed to/replaced by 'liberation-sans-narrow'"; # Converted to throw 2022-02-22 <del> libgcc = throw "libgcc was removed, use gcc.cc.libgcc if needed"; # added 2023-05-13 </del> libgksu = throw "libgksu has been removed"; # Added 2022-01-16 libgme = game-music-emu; # Added 2022-07-20 libgnome_keyring = throw "'libgnome_keyring' has been renamed to/replaced by 'libgnome-keyring'"; # Converted to throw 2022-02-22

Related discussion:
text: 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.
Code change:
liberation_ttf_v1_from_source = throw "'liberation_ttf_v1_from_source' has been renamed to/replaced by 'liberation_ttf_v1'"; # Converted to throw 2022-02-22 liberation_ttf_v2_from_source = throw "'liberation_ttf_v2_from_source' has been renamed to/replaced by 'liberation_ttf_v2'"; # Converted to throw 2022-02-22 liberationsansnarrow = throw "'liberationsansnarrow' has been renamed to/replaced by 'liberation-sans-narrow'"; # Converted to throw 2022-02-22 <del> libgcc = throw "libgcc was removed, use gcc.cc.libgcc if needed"; # added 2023-05-13 </del> libgksu = throw "libgksu has been removed"; # Added 2022-01-16 libgme = game-music-emu; # Added 2022-07-20 libgnome_keyring = throw "'libgnome_keyring' has been renamed to/replaced by 'libgnome-keyring'"; # Converted to throw 2022-02-22

Related discussion:
text: 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.
Code change:
(fetchNuGet { pname = "CheapLoc"; version = "1.1.6"; sha256 = "1m6cgx9yh7h3vrq2d4f99xyvsxc9jvz8zjq1q14qgylfmyq4hx4l"; }) (fetchNuGet { pname = "Config.Net"; version = "4.19.0"; sha256 = "17iv0vy0693s6d8626lbz3w1ppn5abn77aaki7h4qi4izysizgim"; }) (fetchNuGet { pname = "Downloader"; version = "2.2.8"; sha256 = "0farwh3pc6m8hsgqywigdpcb4gr2m9myyxm2idzjmhhkzfqghj28"; }) <del> (fetchNuGet { pname = "Facepunch.Steamworks"; version = "2.3.3"; sha256 = "1r3m7cyzfy8ms9xxfa13xcwha02yk22givkaamw166im89m8wqyc"; }) </del> (fetchNuGet { pname = "goaaats.NativeLibraryLoader"; version = "4.9.0-beta1-g70f642e82e"; sha256 = "1bjjgsw4ry9cz8dzsgwx428hn06wms194pqz8nclwrqcwfx7gmxk"; }) <ins> (fetchNuGet { pname = "goaaats.Steamworks"; version = "2.3.4"; sha256 = "1khxkkjvh6af60rxc13bacxn85amdfzr8z0b9a6gfg6m1fnmlkss"; }) </ins> (fetchNuGet { pname = "goaaats.Veldrid"; version = "4.9.0-beta1-g70f642e82e"; sha256 = "0b35bn4190hxbvrwsygpbpg00gnrj6crxyk8b0d7ian611v4jj0m"; }) (fetchNuGet { pname = "goaaats.Veldrid.ImageSharp"; version = "4.9.0-beta1-g70f642e82e"; sha256 = "1zihi2n9qz18kfkz4qnj3412bfsqvx49809hqkknixdrgn8323i2"; }) (fetchNuGet { pname = "goaaats.Veldrid.MetalBindings"; version = "4.9.0-beta1-g70f642e82e"; sha256 = "13cs5jr8bpkrkzziz8b71l3npr14shxryrpsiw0zm7jcx69vg2qf"; })

Related discussion:
text: is not included in the version of xivlauncher in nixpkgs, meaning that xivlauncher is currently broken. The update will need a backport to 22.05. <!-- 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: xivlauncher <!-- 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: xlcore 1.0.0.9 (upstream release 6.2.33, which I think is probably a more useful version number to use, since xlcore remains at 1.0.0.9 in the most recent release) desired version: 6.2.44 <!-- 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.
Code change:
'' + optionalString (libcxx.isLLVM or false) '' echo "-isystem ${lib.getDev libcxx}/include/c++/v1" >> $out/nix-support/libcxx-cxxflags <ins> echo "-isystem ${lib.getDev libcxx.cxxabi}/include/c++/v1" >> $out/nix-support/libcxx-cxxflags </ins> echo "-stdlib=libc++" >> $out/nix-support/libcxx-ldflags echo "-l${libcxx.cxxabi.libName}" >> $out/nix-support/libcxx-ldflags ''

Related discussion:
text: Clang's wrapper does not set as an include path. Compiling files with since <cxxabi.hrequires is present in the aforementioned path I created the environment using this minimal mkShell expression Adding to
Proposed solution seems reasonable to me. See also started by
Please can you also include the nixpkgs commit hash in the repro (sorry if it's there and I missed it).
Oh thank you, that makes so much sense, I was also looking at how the monorepo handles things as well as their tests on finding the system include headers and what you said is probably the correct reason. Ah, it was the nixpkgs-unstable revision updated just then. Sorry I do not have that, but you can reproduce it with the current master as well.
Code change:
}: buildPythonPackage rec { pname = "sabctools"; <del> version = "7.0.2"; # needs to match version sabnzbd expects, e.g. https://github.com/sabnzbd/sabnzbd/blob/4.0.x/requirements.txt#L3 </del> <ins> version = "7.1.2"; # needs to match version sabnzbd expects, e.g. https://github.com/sabnzbd/sabnzbd/blob/4.0.x/requirements.txt#L3 </ins> format = "setuptools"; src = fetchPypi { inherit pname version; <del> hash = "sha256-AB5/McuOIDkhu7rtb3nFaqOTx3zwm92+3NEnH5HjzBo="; </del> <ins> hash = "sha256-wDgFXuxclmqMlRXyr9qpruJJcOXfOiOWTZXX53uYEB8="; </ins> }; pythonImportsCheck = ["sabctools"];

Related discussion:
text: When booting up SABnzbd having done an update recently (5min ago at time of writing), I'm getting the following errors: ! Steps to reproduce the behavior: your on NixOS using current unstable, include the following: . I expected it to pick up SABCtools 7.1.2, but it got 7.0.2 instead. See above N/a
Opened a PR to fix this and provide better testing.
:+1: thanks
Code change:
"--with-rcdir=no" "--with-shell=${stdenv.shell}" "--with-test-font-path=${dejavu_fonts}/share/fonts/truetype/DejaVuSans.ttf" <ins> "--localstatedir=/var" "--sysconfdir=/etc" </ins> ]; makeFlags = [ "CUPS_SERVERBIN=$(out)/lib/cups" "CUPS_DATADIR=$(out)/share/cups" "CUPS_SERVERROOT=$(out)/etc/cups" ];

Related discussion:
text: Configuration summary shows several incorrect paths: liblouis tables can probably be easily corrected, not sure what to do about cups dom socket and font directory. nixpkgs: cc
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
Code change:
genericName = "Reference Management"; categories = [ "Office" "Database" ]; startupNotify = true; <del> mimeTypes = [ "text/plain" ]; </del> <ins> mimeTypes = [ "x-scheme-handler/zotero" "text/plain" ]; </ins> }; installPhase = ''

Related discussion:
text: Links like do not work, since the scheme handler is not registered in the desktop entry file. Steps to reproduce the behavior: Zotero stuff to biblography to select item using a url The correct item is selected Related flathub issue: I'm using 21.11 stable, a backport would be appreciated. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Code change:
name = "exa-${version}"; version = "2016-04-20"; <del> depsSha256 = "0nyrdl57nhr3lxqs3gaij3mdmlrm0z52qv6mznvgw0ziwqmlq5w1"; </del> <ins> depsSha256 = "0qsqkgc1wxigvskhaamgfp5pyc2kprsikhcfccysgs07w44nxkd0"; </ins> src = fetchFromGitHub { owner = "ogham";

Related discussion:
text: fails to compile on unstable. on (Flounder) System: (Flounder) Nix version: nix-env (Nix) 1.11.2 Nixpkgs version: "16.09pre88945." trace:
Code change:
patches = [ ./hardcoded-compiler.patch ./bin-ext.patch ]; patchFlags = [ "-p3" ]; <ins> # Don't attempt the .so if static, as it would fail. postPatch = lib.optionalString stdenv.hostPlatform.isStatic '' sed 's/^ILIBS>.*/ILIBS = liblmdb.a/' -i Makefile ''; </ins> outputs = [ "bin" "out" "dev" ]; buildInputs = lib.optional stdenv.hostPlatform.isWindows windows.pthreads;

Related discussion:
text: Steps to reproduce the behavior: alternatively (the output is the same) Found this while trying to build on my mac I also tested this running on my nixos work computer instead of via a remote builder and got the same result. <!-- 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. Though the actual building is done by a remote builder with .
Fortunately it seemed OK after a quick glance, on x86_64-linux at least. Feel free to review.
Yep, this seems to have fixed it, thanks :) building a static lmdb seems to work for at least x86_64-linux and aarch64-darwin. I'll continue my adventure of trying to get murmur to build statically
Code change:
<ins> { lib, stdenvNoCC, fetchFromGitLab }: stdenvNoCC.mkDerivation { pname = "xr-hardware"; version = "unstable-2023-11-08"; src = fetchFromGitLab { domain = "gitlab.freedesktop.org"; owner = "monado/utilities"; repo = "xr-hardware"; rev = "9204de323210d2a5ab8635c2ee52127100de67b1"; hash = "sha256-ZS15WODms/WKsPu+WbfILO2BOwnxrhCY/SoF8jzOX5Q="; }; installTargets = "install_package"; installFlagsArray = "DESTDIR=${placeholder "out"}"; meta = with lib; { description = "Hardware description for XR devices"; homepage = "https://gitlab.freedesktop.org/monado/utilities/xr-hardware"; license = licenses.boost; maintainers = with maintainers; [ Scrumplex ]; platforms = platforms.linux; }; } </ins>

Related discussion:
text: The [monado] package doesn't install the udev rules generated by the [xr-hardware util] from the Monado project. Install the package and check the lack of udev rules in It was expected for the udev rules to be installted with the package. The udev rules are needed as some hmd's have some strange and specific permissions. Maybe instead of adding this to the package, monado could turn into an option like . <!-- 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]: [monado]: [xr-hardware util]:
Trying packaging the udev rules similar to how . [brscan4]:
I was working on a Monado NixOS module. Perhaps I can deal with udev rules there. See
Code change:
inherit enableSeccomp enableSuid <ins> externalLocalStateDir </ins> projectName removeCompat starterSuidPath

Related discussion:
text: The derivation is missing the directory to work properly. Steps to reproduce the behavior: A clear and concise description of what you expected to happen. is output without error. This can be fixed by creating the directory manually (). I guess this could be to the derivation. <!-- 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.
NixOS module provides those top-level directories. discussed with one of the main Apptainer developer in . He think it should be easy to specify a directory that will always exist at build time. Regalding this, I'm considering the possibility to put those dilectories under the derivation store path. Not sure if there would be potential problem using a store path as a mount point, but it seems to work without problem.
Could you help me take a look at ?
If you have time, please help me test the PR . It should fundamentally solve this issue. If applied, you no longer need the NixOS module or just to run images. It specifies the LOCALSTATEDIR as , making both Apptainer and Sylabs SingularityCE works without . (The image running still depends on and to run images, which might be the final obstacle to build images as a package without invoking a virtual machine. Other than that, it should not be an issue for most users, as are available on most of the UNIX/UNIX-like systems.)
I removed (the temporary fix for this issue) and ran the following and it seems to work fine: Thank you for this fix!
Glad to hear that! Would you mind ? I've heard that committers tend to merge PRs getting two approvals.
Done!
Code change:
--replace "requests>=2.20.0,<2.26" "requests~=2.20" ''; <del> nativeBuildInputs = [ plux setuptools ]; </del> propagatedBuildInputs = [ <del> cachetools click cryptography </del> dill dnslib dnspython plux <del> psutil python-dotenv pyyaml rich </del> <ins> pyaes python-jose </ins> requests <del> semver stevedore tailer </del> <ins> tabulate </ins> ]; pythonImportsCheck = [ "localstack_ext" ];

Related discussion:
text: Steps to reproduce the behavior: localstack (from unstable) (version 3.2.0) localstack 2.3.0 works and so does (tagged because you bumped the version) (the channel is slightly messed up. I am using 23.11 but with flakes) Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The new version requires too many dependencies to package up in a reasonable time frame and even includes circular ones. contains a revert to 3.0.0 which builds for me and shows the usage. Can you take a look if that works for you?
Sorry for the delay! Yes, the revert works well for me! Thank you!
Code change:
meta = { description = "A notification system for tiling window managers"; homepage = https://github.com/sboli/twmn; <del> platforms = with stdenv.lib.platforms; linux; maintainers = [ stdenv.lib.maintainers.matejc ]; license = stdenv.lib.licenses.lgpl3; </del> <ins> platforms = with lib.platforms; linux; maintainers = [ lib.maintainers.matejc ]; license = lib.licenses.lgpl3; </ins> }; }

Related discussion:
text: twmnd does not launch because qt5 library path is missing. Install the twmn package and run twmnd. twmnd works when I manually set the LDLIBRARYPATH to <qtbase/lib. System: NixOS 16.09.931. Nix version: 1.11.4 Nixpkgs version:16.09.931.
I noticed the same or similar thing when trying to run twmnd as a systemd user service. It just SIGABRTs: I could reproduce with Although works fine... So clearly there is some impurity in my local environment which is making twmnd work "by accident?" Possibly related?:
Code change:
}) (filterAttrs (name: service: service.startAt != "") cfg.services); <ins> # Generate timer units for all services that have a ‘startAt’ value. systemd.user.timers = mapAttrs (name: service: { wantedBy = [ "timers.target" ]; timerConfig.OnCalendar = service.startAt; }) (filterAttrs (name: service: service.startAt != "") cfg.user.services); </ins> systemd.sockets.systemd-journal-gatewayd.wantedBy = optional config.services.journald.enableHttpGateway "sockets.target";

Related discussion:
text: the attribute inside a user-level systemd service seems to be ignored. I have three observations to suggest this. With this snippet from (service details aren't important, just for concreteness) If I run , I see batterycheck.service, but no corresponding timer. If I run , I again see the .service file, but no timer file. If I remove the startAt line and run , I can see from the output that no new environment is being built. I'm pretty sure that this functionality used to work several months ago, when I created this unit definition.