jiebi/CodeConvo huggingface dataset:
Code change:
homepage = "https://github.com/pantsbuild/pex"; changelog = "https://github.com/pantsbuild/pex/releases/tag/v${version}"; license = licenses.asl20; <del> maintainers = with maintainers; [ copumpkin ]; </del> <ins> maintainers = with maintainers; [ copumpkin phaer ]; </ins> }; }

Related discussion:
text: (contact info in profile) Many environment variables like and are different when run via nix (symlinks to /nix/store), but "~/" and other filesystems are not namespaced or sandboxed in any way here. is writable by my user. I've tried with PEXROOT set, but that didn't incfluence the output. Going to have another look tomorrow, but it's quite late already here in CEST.
I don't think notifications are sent for linked issues; think I found a fix in Thanks to for pointing me into the right direction
Ok, this works perfectly fine in nixos (N.B.: I 1st used the vanilla image which is not sandboxed and everything worked fine; so I went through a bit of extra effort below to enable sandboxing in the image and prove it out to see if the sandboxing behavior was relevant to repro): So I'll try to repro using .
Ok, after following the multi-user install instructions for the command here: and enabling flakes, etc - I do repro: So, for someone with knowledge of nixos vs nix shell vs flakes, this would presumably mean something. I'll continue to dig in my shell to see what's up.
Alright, Pex 2.1.141 should fix. Please let me know either way
Sandboxed builds do not work inside Docker as we can't create required namespaces from an unprivileged container.
I've tested a build against your tag and that works just fine on NixOS (with sandboxing enabled).
Ok, great. I used in addition to mounting in that custom nix config.
Code change:
<del> { config, lib, pkgs, ... }: </del> <ins> { config, lib, pkgs, ... }: </ins> with lib;

Related discussion:
text: Steps to reproduce the behavior: -rebuild test on settings.datadir = "/mnt/garage0"; resolves fine Tested on nixos24.05 but code of the module is unchanged in nixos_unstable. I'm using flakes as well Please run and paste the result.
Looks like doesn't apply, maybe should tinker a bit on my own
It looks like the option type was adjusted, but not the other code in the module that checks that value. Shouldn't be too hard to fix.
Code change:
# Splicer will pull out correct variations libDeps = platform: stdenv.lib.optional enableTerminfo [ ncurses ] ++ stdenv.lib.optional (!enableIntegerSimple) gmp <del> ++ stdenv.lib.optional (platform.libc != "glibc" && !targetPlatform.isWindows) libiconv ++ stdenv.lib.optional enableDwarf elfutils; </del> <ins> ++ stdenv.lib.optional (platform.libc != "glibc" && !targetPlatform.isWindows) libiconv; </ins> toolsForTarget = [ pkgsBuildTarget.targetPackages.stdenv.cc

Related discussion:
text: Our can no longer link executables. For example: This issue is present in current versions of . Compiling and linking works fine with an older revision, say . It looks like this might be related to some change in binutils, maybe?
This is probably from
Yes, it is. came to the same conclusion.
This probably is GHC bug though. Things like gmp and libiconv get their paths hardcoded so this isn't a problem. I would expect the same treatment for elfutils. should provide a arg.
/cc
I guess now I know why there's a patch in branch.
I'll reopen the PR fixing the linking issues.
I opened while we wait on upstream fix.
Which one, from
Yes, although it doesn't help. See
Yes, it would have surprised me a bit if it helped against that symptom -- my patch fixes that DWARF-enabling is skipped completely.
I'm surprised this worked for you back then and now there are linking errors.
Code change:
, withVoAmrwbenc ? withFullDeps # AMR-WB encoder , withVorbis ? withHeadlessDeps # Vorbis de/encoding, native encoder exists , withVpx ? withHeadlessDeps && stdenv.buildPlatform == stdenv.hostPlatform # VP8 & VP9 de/encoding <del> , withVulkan ? withFullDeps && !stdenv.isDarwin </del> <ins> , withVulkan ? withSmallDeps && !stdenv.isDarwin </ins> , withWebp ? withFullDeps # WebP encoder , withX264 ? withHeadlessDeps # H.264/AVC encoder , withX265 ? withHeadlessDeps # H.265/HEVC encoder

Related discussion:
text: Ffmpeg 6.1 supports vulkan video, but it is not enabled in the default version of ffmpeg, it is only enabled in ffmpeg-full. The default version of ffmpeg should support vulkan video so that applications like mpv can use it. Arch enables vulkan by . Vulkan video already works with amd GPUs using ffmpeg-full with this command: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This seems reasonable. I'm in favor.
EDIT: Error on my end, skip reading this. Hm, your command doesn't work for me on Mesa 23.3.3: Another aspect to consider is closure size.
If you haven't tried already, can you try with something in h264? Vulkan video currently only supports h264, h265 and av1(experminental), and only if you gpu supports them.
Indeed it's h.265, let me try h.264. This looks like a generic VK issue though.
As suspected, this happens on h.264 too.
Do you have multiple GPUs in your system except the amd one perhaps? This chooses the first one arbitrarily.
Same error for all.
Then I am not sure about what's causing it, that's the exact same error I receive when using ffmpeg 6.1 instead of ffmpeg-full 6.1.
Uhhh about that... So and that commit didn't seem to have been pulled into this brain thingy of mine... It works as expected with ffmpeg-full.
Code change:
githubId = 10198051; name = "Drew Risinger"; }; <ins> drperceptron = { email = "92106371+drperceptron@users.noreply.github.com"; github = "drperceptron"; githubId = 92106371; name = "Dr Perceptron"; keys = [{ longkeyid = "rsa4096/0x95EB6DFF26D1CEB0"; fingerprint = "7E38 89D9 B1A8 B381 C8DE  A15F 95EB 6DFF 26D1 CEB0"; }]; }; </ins> drupol = { name = "Pol Dellaiera"; email = "pol.dellaiera@protonmail.com";

Related discussion:
text: Project description Tile World 2 Metadata homepage URL: source URL: license: gpl2+ platforms: linux
Code change:
targetPlatform = localSystem; inherit config; <del> preHook = '' # Make "strip" produce deterministic output, by setting # timestamps etc. to a fixed value. commonStripFlags="--enable-deterministic-archives" ${commonPreHook} ''; </del> <ins> preHook = commonPreHook; </ins> initialPath = ((import ../common-path.nix) {pkgs = prevStage;});

Related discussion:
text: The Linux stdenv sets But that flag is specific to GNU strip, and LLVM's strip will fail if passed it. Conveniently, we silence all errors from stripping, so this has gone unnoticed until now: I noticed this while trying to fix . One of the reasons it doesn't work is that it has in , and strip should be removing that reference but isn't. What I'm not sure about here is the best way to fix this. There's nothing platform-specific about this option, so it shouldn't live in the Linux stdenv. (Other platforms like NetBSD use GNU binutils by default.) Ideally it would be a conditional in the strip setup hook, but we don't really have a bash equivalent to . So where (in Nix) should we check this and set the variable? cc
With what we have at the moment, I can only think of hacky workarounds like checking if ends in . However such an approach (and even checking ) is actually incorrect: and don't have to be matched, e. g. with as linker and GNU bintools is quite common actually. Looking at prior art in nixpkgs, I'm quite convinced that the cleanest solution for now would be to bite the bullet and extend to also wrap . In fact, we already seem to have a strip wrapper for darwin.
Hmm, I don't like the idea of globally adding a flag only to remove it again in a wrapper. Another idea I had was to do this in the definition of make- — the hardening flags are precedent for doing manipulation of environment variables for setup hooks in there. We could add an isGNU attribute to the possible values of , and use that? I don't much like this idea either, but I like it better than adding the flag globally and then wrapping to remove it. What do you think?
Since this flag is unconditionally in general, I think we can just remove it from the linux hook and instead add it in the binutils-wrapper. This should also solve the issue of this being binutils-specific and not linux-specific AIUI.
Oh, you mean wrap GNU binutils' strip to add this flag? That sounds fine to me.
If I understand correctly this is now done:
Code change:
</para> <para> <del> Right now changes to the <literal>services.nextcloud.config</literal> attribute set won't take effect after the first install (except <literal><link linkend="opt-services.nextcloud.config.extraTrustedDomains">services.nextcloud.config.extraTrustedDomains</link></literal>) since the actual configuration file is generated by the NextCloud installer which also sets up critical parts such as the database structure. </del> <ins> All configuration parameters are also stored in <literal>/var/lib/nextcloud/config/override.config.php</literal> which is generated by the module and linked from the store to ensure that all values from <literal>config.php</literal> can be modified by the module. However <literal>config.php</literal> manages the application's state and shouldn't be touched manually because of that. </ins> </para> <del> <para> <emphasis>Warning: don't delete <literal>config.php</literal>! This file </del> <ins> <warning> <para>Don't delete <literal>config.php</literal>! This file </ins> tracks the application's state and a deletion can cause unwanted <del> side-effects!</emphasis> </para> </del> <ins> side-effects!</para> </warning> </ins> <del> <para> <emphasis>Warning: don't rerun <literal>nextcloud-occ </del> <ins> <warning> <para>Don't rerun <literal>nextcloud-occ </ins> maintenance:install</literal>! This command tries to install the application <del> and can cause unwanted side-effects!</emphasis> </para> <para> The issues are known and reported in <link xlink:href="https://github.com/NixOS/nixpkgs/issues/49783">#49783</link>, for now it's unfortunately necessary to manually work around these issues. </para> <para> Right now app installation and configuration is done imperatively in the nextcloud web ui or via the <literal>nextcloud-occ</literal> command line utility. You can activate auto updates for your apps via <literal><link linkend="opt-services.nextcloud.autoUpdateApps.enable">services.nextcloud.autoUpdateApps</link></literal>. </para> </del> <ins> and can cause unwanted side-effects!</para> </warning> </ins> </section> </chapter>

Related discussion:
text: Well, for the record it was actually idea :sweat_smile: I guess so, all the stuff from is also in my at the moment. I'll probably have sufficient time next weekend to check if I can trigger such a case. I can't promise that, but unless anybody beats me, I can hopefully prepare a fix for this :)
Did you gain some new insights on this?
Unfortunately not... I was pretty busy back then. But as this only requires some fiddling in the module and no patching of the actual package, the change shouldn't be too painful, so if you'd like to take over... :sweat_smile:
there's with a fix now :)
Code change:
gtk3 libextractor libgcrypt <ins> libsodium </ins> libxml2 ]; <ins> configureFlags = [ "--with-gnunet=${gnunet}" ]; </ins> patchPhase = "patchShebangs pixmaps/icon-theme-installer"; meta = gnunet.meta // { description = "GNUnet GTK User Interface"; homepage = "https://git.gnunet.org/gnunet-gtk.git"; <del> # configure: error: compiling gnunet-gtk requires GNUnet core headers broken = true; </del> }; }

Related discussion:
text: Describe the bug To Reproduce Steps to reproduce the behavior: ... ... ... Expected behavior A clear and concise description of what you expected to happen. Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Notify maintainers and edited it last Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
I really have no idea, contains it, even bumping gnunet-gtk to be the same release version still doesn't fix it.
Have you tried applying
Code change:
'' maxstartdelay = ${toString cfg.maxStartDelay} <del> ${flip concatStringsSep (forEach (attrValues cfg.ups) (ups: ups.summary)) " "} </del> <ins> ${concatStringsSep "nn" (forEach (attrValues cfg.ups) (ups: ups.summary))} ''; "nut/upsd.conf".source = pkgs.writeText "upsd.conf" '' ${concatStringsSep "n" (forEach cfg.upsd.listen (listen: "LISTEN ${listen.address} ${toString listen.port}"))} ${cfg.upsd.extraConfig} </ins> ''; "nut/upssched.conf".source = cfg.schedulerRules; <del> # These file are containing private information and thus should not # be stored inside the Nix store. /* "nut/upsd.conf".source = ""; "nut/upsd.users".source = ""; "nut/upsmon.conf".source = ""; */ </del> <ins> "nut/upsd.users".source = "/run/nut/upsd.users"; "nut/upsmon.conf".source = "/run/nut/upsmon.conf"; </ins> }; power.ups.schedulerRules = mkDefault "${pkgs.nut}/etc/upssched.conf.sample"; systemd.tmpfiles.rules = [ "d /var/state/ups -" <ins> "d /var/lib/nut 700" </ins> ];

Related discussion:
text: Describe the bug I'm trying to use NixOS in a UPS client (not server). When , the and services shouldn't be running. There is a note that says that is not used currently. To Reproduce Steps to reproduce the behavior: Error: and fail. Expected behavior only upsmon should be running Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata Maintainer information: See also
Looks like there's a pretty simple workaround:
I marked this as stale due to inactivity. &rarr;
Code change:
'' maxstartdelay = ${toString cfg.maxStartDelay} <del> ${flip concatStringsSep (forEach (attrValues cfg.ups) (ups: ups.summary)) " "} </del> <ins> ${concatStringsSep "nn" (forEach (attrValues cfg.ups) (ups: ups.summary))} ''; "nut/upsd.conf".source = pkgs.writeText "upsd.conf" '' ${concatStringsSep "n" (forEach cfg.upsd.listen (listen: "LISTEN ${listen.address} ${toString listen.port}"))} ${cfg.upsd.extraConfig} </ins> ''; "nut/upssched.conf".source = cfg.schedulerRules; <del> # These file are containing private information and thus should not # be stored inside the Nix store. /* "nut/upsd.conf".source = ""; "nut/upsd.users".source = ""; "nut/upsmon.conf".source = ""; */ </del> <ins> "nut/upsd.users".source = "/run/nut/upsd.users"; "nut/upsmon.conf".source = "/run/nut/upsmon.conf"; </ins> }; power.ups.schedulerRules = mkDefault "${pkgs.nut}/etc/upssched.conf.sample"; systemd.tmpfiles.rules = [ "d /var/state/ups -" <ins> "d /var/lib/nut 700" </ins> ];

Related discussion:
text: Describe the bug The following snippet: results in services failing to start due to missing config files etc. : : ( fails too, but that could be down to the fact that I haven't plugged the UPS in yet -- but for the record, it complains ) Expected behavior I'd expect the services to start successfully (and probably complain about the missing actual UPS). Notify maintainers (The UPS module appears to have received only drive-by changes for the last several years, so no idea who to bug personally). Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
OK, should've read the whole module: I'm supposed to supply the missing /etc/nut files myself because it's unwise to keep them in the store (they could contain passwords and whatnot, I guess?). Declaring (in the service definitions) the state directory to be but creating for the purpose appears to be a real bug, though :)
Also (sorry for the semi-off-topic) what are best practices for referencing hand-written config files without their contents winding up in the store? Double-symlinking? If this is documented somewhere, then I haven't found where.
I was struggling with the same problem as until I noticed this bug report. After copying and editing , , and from to (and setting on all those files), I was able to get it to work. I think this should be more discoverable. If it's not appropriate to copy those sample files to on the users behalf, there should at least be detailed instructions on the option to explain what else needs to be done.
I marked this as stale due to inactivity. &rarr;
Agreed this should be more discoverable. Perhaps at least could be defaulted to empty and written, since I seem to be getting away without anything in there. In case it helps anyone, I got it working with something like this:
I was hit this bug today, too. Maybe we can fix it by using a startup unit that handles the secrets and setup the state directories like nextcloud or syncthing do
Been working on today and wanted to put some notes here. Using version 2.7.4. First, isn't used by for PIDs and it will try to write to .
Code change:
'' maxstartdelay = ${toString cfg.maxStartDelay} <del> ${flip concatStringsSep (forEach (attrValues cfg.ups) (ups: ups.summary)) " "} </del> <ins> ${concatStringsSep "nn" (forEach (attrValues cfg.ups) (ups: ups.summary))} ''; "nut/upsd.conf".source = pkgs.writeText "upsd.conf" '' ${concatStringsSep "n" (forEach cfg.upsd.listen (listen: "LISTEN ${listen.address} ${toString listen.port}"))} ${cfg.upsd.extraConfig} </ins> ''; "nut/upssched.conf".source = cfg.schedulerRules; <del> # These file are containing private information and thus should not # be stored inside the Nix store. /* "nut/upsd.conf".source = ""; "nut/upsd.users".source = ""; "nut/upsmon.conf".source = ""; */ </del> <ins> "nut/upsd.users".source = "/run/nut/upsd.users"; "nut/upsmon.conf".source = "/run/nut/upsmon.conf"; </ins> }; power.ups.schedulerRules = mkDefault "${pkgs.nut}/etc/upssched.conf.sample"; systemd.tmpfiles.rules = [ "d /var/state/ups -" <ins> "d /var/lib/nut 700" </ins> ];

Related discussion:
text: flags , , may be needed instead of environment variables until a 2.7.5 release. Ref: Using for debug makes it non-forking, requiring a change to the systemd unit . I was able to get to run as non-root: I'm still working on understanding how to manage state directories in NixOS but this was needed:
I set out to get my UPS (cyberpower CP1500 AVR UPS) working with NixOS today. This was the first issue I came across, I figured this was the best place to share my configuration. I probably made this more complex than it needed to be because I have no idea what I am doing, and it is definitely not secure; one problem at a time.
Not stale; still relevant
Thanks for providing your standalone config! I learned a ton tweaking it into a netserver config! The below config creates a working NUT netserver that other machines on your local network can be connected to. The only thing I have yet to figure out is a secure way to include passwords in .nix files that won't show up if I push my local copy to github. Any ideas? If you want to tweak when NUT shuts down your computers you can modify the values of " = <percentage" and " = <seconds" under "directives". SHUTDOWNCMD will be triggered when both conditions are met. The "ignorelb" directive is necessary to have NUT ignore the UPS's defaults. Anyone using this config may want to make sure SHUTDOWNCMD and NOTIFYCMD point to the correct binaries in their filesystem. One other thing of note is to check the value of the "schedulerRules" field under below. You must give it the path to your file. I just put a copy of it inside my /etc/nixos. Could probably add another variable to hold the path for convenience. `
For secrets in nix config, I think the current recommendation is to put it in a separate file and not include it in the repo. See also
I have been using sops-nix to commit encrypted passwords to my NixOS repo, but I have yet to put in the elbow grease to make this work with my upsmon password.
is my attempt at making generate the config files necessary for basic operation. If you are using , could you try out the changes and leave a review?
Code change:
fingerprint = "D0CF 440A A703 E0F9 73CB  A078 82BB 70D5 41AE 2DB4"; }]; }; <ins> geri1701 = { email = "geri@sdf.org"; github = "geri1701"; githubId = 67984144; name = "Gerhard Schwanzer"; }; </ins> gerschtli = { email = "tobias.happ@gmx.de"; github = "Gerschtli";

Related discussion:
text: Project description Formatter for typst. Metadata homepage URL: source URL: license: mit, bsd, gpl2+ , ... platforms: unix, linux, darwin, ...
There is no CLI:
Looks like the author use .
looks like it is still a WIP in
what do you mean wrong default branch? Hi there, I wasn't sure there was interest for a cli, I'll merge the cli in a few days, want a ping then?
I merged my change, it should be good to package!
has renamed the project from typst-fmt to typstfmt in
Code change:
, gtk3 , gsettings-desktop-schemas , p7zip <ins> , autoPatchelfHook </ins> , libXxf86vm , unzip }:

Related discussion:
text: Describe the bug I copied a closure from one system (19.03) to a USB thumb drive and from that to another system (19.09), but the program don't work. I think nix packages should be pure and work also on another system running a different NixOS channel. (Right?) To Reproduce Steps to reproduce the behavior: sweethome3d installed in thumb drive thumb drive (i use pantheons files app and open a terminal from there, then ) a folder on the thumb drive. mine is "nixpkgs" to that folder: the nix store path of the program: the usb drive into another system and mount it, get the path the nix store path to your system: you can install it for the current user if you like: or just open a nix shell: run the program: Expected behavior Program just work. Additional context I moved to a new flat with most of my computers and want to plan where to put my furniture. I installed sweethome3d on my notebook, but it is not powerfull enough. So i want to copy the program to my iMac. I have internet from my tethered mobile phone, so i can't just install it from the internet! sweethome3d is about 500 MB, that would be 1/4 of my data plan!!! Metadata X230: system: host os: multi-user?: sandbox: version: channels(davidak): channels(root): nixpkgs: imac: system: host os: hangs after that Maintainer information:
Looks like this problem again: cc
When i run the package from unstable on stable, i get the same error: (but it will hopefully work on the imac when i copy it there again)
I get the same error when i run the package from unstable on my 19.09 branch. So it might be generally broken on unstable.
Yes, looks like be some kind of impurity. It runs on my NixOS 19.03 system, both from the stable and unstable channels. And I did the "nix run" thing you said and it works there too (I'm not sure how much isolation gives, apparently not enough).
Code change:
, gtk3 , gsettings-desktop-schemas , p7zip <ins> , autoPatchelfHook </ins> , libXxf86vm , unzip }:

Related discussion:
text: It looks like the program copies some so files to on start-up: Two of the programs match to libraries in the but I could not match the other two; also I do not have the same filenames as you. Not sure what libraries’ RPATH should be patched but perhaps adding the following to wrapper would work as well:
For the reference, the libraries loaded are listed here:
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 .