jiebi/CodeConvo huggingface dataset:
Code change:
<ins> { lib, stdenv, fetchurl, makeWrapper, jre, ncurses }: stdenv.mkDerivation rec { version = "3.1.0"; pname = "scala-bare"; src = fetchurl { url = "https://github.com/lampepfl/dotty/releases/download/${version}/scala3-${version}.tar.gz"; sha256 = "9bsZ2FtIb6AvA3W3r2Vv0dPNicuYjMBz3X48z45Avv8="; }; propagatedBuildInputs = [ jre ncurses.dev ] ; nativeBuildInputs = [ makeWrapper ]; installPhase = '' mkdir -p $out mv * $out ''; fixupPhase = '' bin_files=$(find $out/bin -type f ! -name common) for f in $bin_files ; do wrapProgram $f --set JAVA_HOME ${jre} --prefix PATH : '${ncurses.dev}/bin' done ''; meta = with lib; { description = "Research platform for new language concepts and compiler technologies for Scala"; longDescription = '' Dotty is a platform to try out new language concepts and compiler technologies for Scala. The focus is mainly on simplification. We remove extraneous syntax (e.g. no XML literals), and try to boil down Scala’s types into a smaller set of more fundamental constructs. The theory behind these constructs is researched in DOT, a calculus for dependent object types. ''; homepage = "http://dotty.epfl.ch/"; license = licenses.bsd3; platforms = platforms.all; maintainers = [maintainers.karolchmist maintainers.virusdave]; }; } </ins>

Related discussion:
text: Project description Scala 3 is more than a year old. It would be nice to have it packaged in nixpkgs as well. Maybe it is, but I couldn't find it under "scala-3" or respective versions. Metadata homepage URL: https://scala- source URL: license: Apache-2.0 License platforms: unix, linux, darwin, ...
is already packaged.
Indeed: the Scala 3 compiler started out under the codename 'dotty', and that's how it was packaged initially in nixpkgs. Now that dotty has become the 'official' scala 3 compiler (see also ), we should probably rename the package to as well? /cc
Feel free to update, rename and alias the old name :) Maybe should point at and can be
Code change:
meta = with lib; { description = "A screencasting program created with design in mind"; <del> homepage = "https://code.launchpad.net/kazam"; </del> <ins> homepage = "https://github.com/niknah/kazam"; </ins> license = licenses.lgpl3; platforms = platforms.linux; maintainers = [ maintainers.domenkozar ];

Related discussion:
text: Running the package after installation does not work. It results in an error instead of starting the app. Steps to reproduce the behavior: The application should start up and work. as per Please run and paste the result. Maintainer information:
Code change:
buildPhase = '' runHook preBuild <del> ant -lib ${applicationSrc}/libtest -lib ${applicationSrc}/lib -lib ${jdk8}/lib </del> <ins> ant -lib ${applicationSrc}/libtest -lib ${applicationSrc}/lib -lib ${jdk}/lib </ins> runHook postBuild '';

Related discussion:
text: Wanted to install and start sweethomed.application. the build worked without problems but when i started it, it didnt started. Steps to reproduce the behavior: sweethome3d.application via configuration file to start it Starting the Application stucks at the start screen ! Add any other context about the problem here. At the moment its installed in my user context. When i try to start it as my user over the terminal i get no errors. When i start it with "sudo sweethome3d" I get the following error, and it also dont start, also start at starting screen and vanishing from the task bar: I think these happens because its not installed as user, but propably it helps to find the issue.
Starting random applications as root seems like an unwise idea.
Apologies, I misread the error, this appears to be a separate issue
Just to confirm, which GPU do you use?
I've got the same issue, and none of the solutions given in appear to work. On my side says my GPU is . EDIT: I should mention SH3D 7.02 works fine on my setup Mmh, I just tried with , and things work just fine (even though I'm on NixOS + tells me OpenGL is happy)...
Same problem here, on NIXOS unstable. Stuck on the starting blue window. Had to install it with flatpak in the mean time... Any idea?
sorry for delay i dont get informations from messages in last time from github... really annoying... I have an Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics]
Same here, also on Intel hardware.
Based on the NixGL idea, applying the following patch works to update to the latest version and fix the driver issue on Intel. But this does not seem like the best way to go about it; I can't find a single other package messing with , and it seems more like a debugging tool than something that should be in a package.
I forgot to mention, to avoid getting terrible performance (< 1 fps), I also had to set Not sure if it's needed for others. Maybe related to my using Wayland/Sway. I also have to use to get the window displayed properly, but that's a common issue for most Java apps and tiling windowing managers.
I also ran into this issue with a Nvidia card.
Code change:
buildPhase = '' runHook preBuild <del> ant -lib ${applicationSrc}/libtest -lib ${applicationSrc}/lib -lib ${jdk8}/lib </del> <ins> ant -lib ${applicationSrc}/libtest -lib ${applicationSrc}/lib -lib ${jdk}/lib </ins> runHook postBuild '';

Related discussion:
text: For me, was needed (with patch). I also needed . and didn't seem needed (or give noticable changes).
Code change:
rustPlatform.buildRustPackage rec { pname = "cargo-bloat"; <del> version = "0.10.1"; </del> <ins> version = "0.11.0"; </ins> src = fetchFromGitHub { owner = "RazrFalcon"; repo = pname; rev = "v${version}"; <del> sha256 = "sha256-VcdZ/dKqFFQs8ItNEj407z1pWJqpHwwIsuNnsQ8KU/8="; </del> <ins> sha256 = "sha256-UzMo+IqoP3GpGu7tWlrkEU1YpVLgEL7UwIU1hPmoJNg="; </ins> }; <del> cargoSha256 = "sha256-1TIGv0yVhkhThqZiQW9JrvFd0eouTlr8kgN/g7b4vDM="; </del> <ins> cargoSha256 = "sha256-w3+ypGuVRGwC94zj/OaDUUoUbBnepGHvqulY4IVIsfo="; </ins> meta = with lib; { description = "A tool and Cargo subcommand that helps you find out what takes most of the space in your executable";

Related discussion:
text: name: current version: 0.10.1 desired version: 0.11.0 maintainers: The last few updates were done by r-ryantm, I don't know why it didn't do this time. I checked the logs, apparently it didn't even try building it.
Code change:
, fetchFromGitHub , cmake , pkg-config <del> , fftw </del> , libpng , libjpeg , libwebp <del> , openblas </del> <ins> , blas , lapack , config </ins> , guiSupport ? false , libX11 <del> # see http://dlib.net/compile.html </del> , sse4Support ? stdenv.hostPlatform.sse4_1Support , avxSupport ? stdenv.hostPlatform.avxSupport <del> , cudaSupport ? true }: stdenv.mkDerivation rec { </del> <ins> , cudaSupport ? config.cudaSupport , cudaPackages }@inputs: (if cudaSupport then cudaPackages.backendStdenv else inputs.stdenv).mkDerivation rec { </ins> pname = "dlib"; version = "19.24.2"; src = fetchFromGitHub { owner = "davisking"; repo = "dlib"; <del> rev ="v${version}"; </del> <ins> rev = "v${version}"; </ins> sha256 = "sha256-Z1fScuaIHjj2L1uqLIvsZ7ARKNjM+iaA8SAtWUTPFZk="; };

Related discussion:
text: When you set , although it sets the CMAKE flag correctly the resulting package isn't actually built correctly as cmake can't find cuda so it unsets the flag. This is due to the incorrect usage of instead of when building the cuda related packages. The correct usage can be seen in the package. It also tries to build with CUDA by default which is wrong. Dlib hasn't supported fftw since however there are leftover references to it in cmake which might lead people to think it does support fftw. fftw should be removed. As mentioned in this it makes more sense to have as an input into rather that so that people can override it with other BLAS implementations e.g more easily if they want to. The package was also missing lapack which should be . Steps to reproduce the behavior: Build the package, it tries to build with CUDA by default. I made an example with a fairly simple nix flake that let's you switch between my patch and the original package. I have created a which fixes these issues. For it to build with CUDA. How CMAKE fails ! For this simple c switching from my fix to the original bugged package on 23.11 before openblas was . ! Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: Thanks!
Code change:
}; }; <del> pythonefl_1_11 = buildPythonPackage rec { </del> <ins> pythonefl_1_12 = buildPythonPackage rec { </ins> name = "python-efl-${version}"; <del> version = "1.11.0"; </del> <ins> version = "1.12.0"; </ins> src = pkgs.fetchurl { <del> url = "http://download.enlightenment.org/rel/bindings/python/${name}.tar.xz"; sha256 = "1d4hj39alg6j7ah1bc8wvlka9d13i8iy3fxxraik2f60w6811i48"; </del> <ins> url = "http://download.enlightenment.org/rel/bindings/python/${name}.tar.gz"; sha256 = "0rxv5nrqg5c2l93ns2k6gjil1y7qq6amfh5slkarm3kv8fzk17xv"; </ins> }; preConfigure = '' export NIX_CFLAGS_COMPILE="-I${pkgs.e19.efl}/include/eo-1 -I${pkgs.e19.efl}/include/eina-1 -I${pkgs.e19.efl}/include/eina-1/eina -I${pkgs.e19.efl}/include/evas-1 -I${self.dbus}/include/dbus-1.0 -I${pkgs.e19.efl}/include/efl-1 -I${pkgs.e19.efl}/include/eet-1 -I${pkgs.e19.efl}/include/ecore-1 -I${pkgs.e19.efl}/include/ecore-evas-1 -I${pkgs.e19.efl}/include/ecore-file-1 -I${pkgs.e19.efl}/include/ecore-input-1 -I${pkgs.e19.efl}/include/ecore-imf-1 -I${pkgs.e19.efl}/include/ecore-con-1 -I${pkgs.e19.efl}/include/edje-1 -I${pkgs.e19.efl}/include/eldbus-1 -I${pkgs.e19.efl}/include/efreet-1 -I${pkgs.e19.efl}/include/ethumb-client-1 -I${pkgs.e19.efl}/include/ethumb-1 -I${pkgs.e19.efl}/include/ecore-x-1 $NIX_CFLAGS_COMPILE"

Related discussion:
text: Possible, because X11/xkb/rules/*.lst [0] are somewhere 'hidden' in the /nix/store. [0]
Fixed, just let me do some updating on E19 libraries and I will make a pull request.
Code change:
version = "0.14.0.2"; src = fetchurl { <del> url = "mirror://sourceforge/project/refind/${version}/${pname}-src-${version}.tar.gz"; </del> <ins> url = "mirror://sourceforge/project/refind/${version}/refind-src-${version}.tar.gz"; </ins> hash = "sha256-JqDFXf01ZUmeH4LY/ldGTb7xnKiGzm0BqBUii478iw8="; };

Related discussion:
text: efibootmgr is not a dependency, despite being needed Steps to reproduce the behavior: refind refind-install the error message: ! efibootmgr is a dependency of refind I already had refind installed (from another distro) Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
}; <ins> pythondaemon = buildPythonPackage rec { name = "python-daemon-${version}"; version = "2.1.1"; src = pkgs.fetchurl { url = " https://pypi.python.org/packages/source/p/python-daemon/${name}.tar.gz"; sha256 = "17v80qb98p1gv4j9mq6wb55cv7hc4j1hzw5y2f4s5hrpxs3w3a2q"; }; # A test fail within chroot builds. doCheck = false; buildInputs = with self; [ mock testscenarios ]; propagatedBuildInputs = with self; [ docutils lockfile ]; meta = { description = "Library to implement a well-behaved Unix daemon process"; homepage = https://alioth.debian.org/projects/python-daemon/; licenses =  [ licenses.gpl3Plus licenses.asl20 ]; }; }; </ins> sympy = buildPythonPackage rec { name = "sympy-0.7.6.1"; disabled = isPy34 || isPy35 || isPyPy;  # some tests fail

Related discussion:
text: To make sure that we are on the same page: Kernel: System: Nix version: Nixpkgs version: broke legacy packages (only tested with the -set). Multiple options to solve this: revert the commit (an update will eventually have to be done) make sure no-one depends on sqlalchemy legacy versions (this would be the best choice, but can require a big amount of work) re-introduce an outdated version only used by legacy version (I’ll prepare a PR shortly that follows this path) cc
To be complete, the build problem is a test failure: I also checked, we cannot downgrade sqlite only for few pythonPackages, the entire python (and package set) have to be changed. Any preferred way to go?
(We should check if we still need this version, have it removed locally for virtmanager, virtinst as it isn't used, but haven't had the time to push that)
Yes, this is the preferred way to go. I began that but did not finish it yet, and it impacts some important parts (it causes xen to fail) I would prefer not to break because of unsufficient testing from me. This is in progress but could require some time to complete.
FYI xen already fails on
FYI: I switched away from sqlalchemy7 in yesterday.
Apart from virtinst, acd_cli, beaker, coilmq, and geeknote are the only revdeps of sqlalchemy7, as far as I can tell.
I openned to do some cleanup on sqlalchemy7. There still is that explicitly require . The same work will have to be done for and .
This should have remained open.
Using an older version of sqlite requires overriding the derivations of the interpreters.
See
Code change:
, gst_all_1 , gtk4 , libadwaita <del> , libclang </del> , openssl , pipewire , sqlite

Related discussion:
text: The application fails to start with the following error: Steps to reproduce the behavior: to run the application The application should start and work properly.
Same issue with  (
I was looking at fractal-next as well, and found possibly related - [HELP] "Failed to retrieve template child" for Rust 1.67.0-nightly - Dec 4, 2022 - closed with Fixed in 0.5.3 a day later.
Ah, I see. There is a related PR for Amberol:
What commit did you build from? I’d like to bisect
My first try of fractal-next was about a week ago and it was failing already. I've tried HEAD and branch () although I'm not entlrely sure is the correct way to refer to that branch.
if you’re updating the version to point to an unreleased version the should
Indeed, thanks. What I meant was that I'm not entirely sure that setting in to (via ) does indeed let me build from a branch. I could not find a definitive reference for that, but it seems to work. I've the rust backtrace to - Draft: general: Use AdwDualPaneView and AdwAdaptiveState_
Hi there :) This is an unfortunate gtk-rs bug, and there's nothing to do on the app side for this. In addition, draft MRs are not expected to be packaged. That MR in particular depends on unstable libadwaita features and unstable bindings.
Is the gtk-rs package version something I can control? I was under the impression that this is managed in . I understand the branches/merge-requests I tried are not to be packaged. I'm merely trying to get fractal-next to run at all, as element is unusable on my phone.
In it is the minimum version we want to use. The pinned version (the one that is compiled) is in , and it is currently  on . This issue should have been fixed in . I don't know much about packaging for Nix but looking at the diff you posted , have you tried with the whole commit hash? Also don't you need to update the sha256 hash?
We’re not building from , we’re building from . I’m gonna check if we can just bump the version in to and leave it at that.
(how naive of me.
Code change:
, gst_all_1 , gtk4 , libadwaita <del> , libclang </del> , openssl , pipewire , sqlite

Related discussion:
text: maybe just building from is better)
Opened a PR that should solve this, assuming it's accepted. In the meantime you can use it in an overlay if you want a fix now.
You were right - thanks for the hint! - I was indeed still building fractal-next from before the fix :disappointed:
Code change:
nap = callPackage ../development/tools/nap { }; <ins> nex = callPackage ../development/tools/parsing/nex {}; </ins> ninja = callPackage ../development/tools/build-managers/ninja { }; nimbo = with python3Packages; callPackage ../applications/misc/nimbo { };

Related discussion:
text: Project description mgmt: next generation config management! Metadata homepage URL: source URL: license: GNU3 platforms: unix, linux, darwin
After fixing up the mgmt make scripts , from !/bin/bash to !/usr/bin/env bash trying to build from 'nix-shell -p go git' git clone cd mgmt make path make deps make Building: mgmt, os/arch: linux-amd64, version: 0.0.21-90-g5c6a66e-dirty. go build runtime/cgo: copying /run/user/1000/go-build892927552/b057/pkg.a: open /nix/store/y2nrzzz2yz7k36xvwr7bbfx76cb8jg16-go-1.14.8/share/go/pkg/linuxamd64/runtime/cgo.a: read-only file system make: * [Makefile:175: build/mgmt-linux-amd64] Error 1 go env GO111MODULE="" GOARCH="amd64" GOBIN="/home/demo/gopath/bin/" GOCACHE="" GOENV="" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOINSECURE="" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/demo/gopath/" GOPRIVATE="" GOPROXY=",direct" GOROOT="/nix/store/y2nrzzz2yz7k36xvwr7bbfx76cb8jg16-go-1.14.8/share/go" GOSUMDB="" GOTMPDIR="" GOTOOLDIR="/nix/store/y2nrzzz2yz7k36xvwr7bbfx76cb8jg16-go-1.14.
Code change:
nap = callPackage ../development/tools/nap { }; <ins> nex = callPackage ../development/tools/parsing/nex {}; </ins> ninja = callPackage ../development/tools/build-managers/ninja { }; nimbo = with python3Packages; callPackage ../applications/misc/nimbo { };

Related discussion:
text: 8/share/go/pkg/tool/linuxamd64" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGOENABLED="1" GOMOD="" CGOCFLAGS="-g -O2" CGOCPPFLAGS="" CGOCXXFLAGS="-g -O2" CGOFFLAGS="-g -O2" CGOLDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/run/user/1000/go-build275716735=/tmp/go-build -gno-record-gcc-switches"
mgmt now compiles under a I'm going to need a little bit of help to turn this into a nix package, as i'm not too sure how to handle it , as there are buildgopackage, buildgomodule , vgo2nix etc etc . Any pointers welcomed. to avoid I had to remove the -i from the go build this seems to be related to this NixOS/nixpkgs golang/go to run
I marked this as stale due to inactivity. &rarr;
Code change:
domain = "gitlab.freedesktop.org"; owner = "wlroots"; repo = "wlroots"; <del> rev = "00b869c1a96f300a8f25da95d624524895e0ddf2"; hash = "sha256-5HUTG0p+nCJv3cn73AmFHRZdfRV5AD5N43g8xAePSKM="; </del> <ins> rev = "0cb091f1a2d345f37d2ee445f4ffd04f7f4ec9e5"; hash = "sha256-Mz6hCtommq7RQfcPnxLINigO4RYSNt23HeJHC6mVmWI="; </ins> }; patches = [ ]; # don't inherit old.patches

Related discussion:
text: Package name: hyprland Latest released version: 0.36.0 <!-- Search your package here: --- Current version on the unstable channel: 0.35.0 Current version on the stable/release channel: 0.32.3 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. -- Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: The 035.0 has a bug that makes my system crash very often (nullptr when monitor is disconnected) the issue is supposed to be fixed in 0.36.0.
Code change:
, libepoxy # postPatch: , glibc # gconv + locale <ins> # postFixup: , vulkan-loader </ins> # Package customization: , cupsSupport ? true, cups ? null

Related discussion:
text: Even when vulkan is installed and working, opening chromium and going to chrome://gpu shows vulkan is disabled. Also chromium logs the following warning: Warning: Couldn't open Info: Couldn't load Vulkan at LoadVulkan () at Initialize () Running confirms that vulkan is installed properly and working. vulkan is installed and working with running chromium and go to chrome://gpu check if vulkan is enabled or disabled. vulakn is enabled in chrome://gpu Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(robert): channels(root): nixpkgs: Maintainer information:
Hey I think you meant to ping the chromium maintainers:
yes thank you!
Not sure if this is actionable, AFAIK Chromium's Vulkan support is still pretty experimental (depending on the platform). Did it even ever work before? Also: X11 or Wayland, which flags are you using for Chromium, and could you provide the full output? might be actionable but apparently it's only a warning so idk... You could use to figure out the complete path where Chromium expects . Relevant parts from the source code: ;l=43;drc= ;l=173;drc=;bpv=0;bpt=1 But since Dawn () is Google's WebGPU implementation this shouldn't even be relevant (yet). Anyway, I'm afraid you're on your own here as I don't have enough time to give it a proper look. (Potentially) also interesting/relevant: ,RAMandSwap,ChromiumWillEatItAll PS: I also finally submitted but that should only be relevant when using SwiftShader.
This issue affects also google-chrome.
seems to be relevant as it's ANGLE's Vulkan wrapper rather than the real libvulkan from the system. I only had a quick look through the source-code but it seems like we should definitely install it (but other Linux distributions don't seem to do it yet). Anyway, could you re-test this once is built by Hydra (maybe I can also give it a go during the weekend)? we already install for Google Chrome so it seems like there are some other issues as well. If you have time to debug/investigate that would be great (my older test system for Google Chrome lacks Vulkan support :o).
great thanks for looking into it!
Code change:
, libepoxy # postPatch: , glibc # gconv + locale <ins> # postFixup: , vulkan-loader </ins> # Package customization: , cupsSupport ? true, cups ? null

Related discussion:
text: will definitely try to test it over the weekend
unfortunately it does not seem to fix the problem. I still get the same warning that could not be load
Confirming this is also an issue on google-chrome-beta: (Excuse the unrelated dbus things) I'm not experienced at debugging this kind of thing but happy to give it a shot if there are any hints for where to get started. :) Edit: I did confirm that exists and paths seem valid.
If you have time it would be nice if you or someone else could use strace (or similar tools) to figure out where Chrome/Chromium is looking for . Something like (see - e.g. can be useful as well). It's a bit advanced though. I'm hoping that I can also give it a go soon (currently working on a few other Chromium TODOs).
Below is the strace output if it's any help. Pretty sure just the first ~2 lines are relevant. The first line happens when the browser opens, second line onwards happens after opening and the browser prints: (This is with stable, same thing happens with beta too). <details<summary<codestrace-fe file --timestamps google-chrome-stable OCLOEXEC) = 37 : 17:09:44 openat(ATFDCWD, "/nix/store/abmblk7xs49q0xhgkrp9izhab64jqri6-google-chrome-", ORDONLYOCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/kxs3h7ffg2s061y9s8m00m5c6nbggg6f-libXScrnSaver-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/lbignzjfjydc4zb1d6qal3sjq7km3pqf-libXcomposite-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/6cy62r6hnzq5yqjj347p6dwv9pw21ixy-libxcb-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD,
Code change:
, libepoxy # postPatch: , glibc # gconv + locale <ins> # postFixup: , vulkan-loader </ins> # Package customization: , cupsSupport ? true, cups ? null

Related discussion:
text: "/nix/store/1pj4gnng9ibcbd3cy4002lnyjwv2sjv3-alsa-lib-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/l9s8gcnh687p4cpkj0ic4ym180lpy9an-libXdamage-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/shjhw9gp0k78abd8mpd6jlgvbk17k2zv-libXtst-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/nfgwb2xk9jhidd4dh2l5j90kiyq17faa-libXrandr-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/pb2i4d6q7fai3kiqrw9za8svisyrngh5-libxshmfence-", ORDONLYOCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/6hwhq9szpm65zhcvhfw42gzdlyi7b2rz-gdk-pixbuf-", ORDONLYOCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/aqwqh3drn9bf6qrs70wiyrxaawh1wcnz-systemd-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/iy5g2611yc6y6jzcmpm55bjbskhcydkm-libexif-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/g7y8adgr5fac89kzfx8ddm66253a3idn-pciutils-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD,