jiebi/CodeConvo huggingface dataset:
Code change:
librsvg ]; <del> cargoBuildFlags = [ "--bin" "eww" ]; </del> <ins> cargoBuildFlags = [ "--bin" "eww" ]; </ins> cargoTestFlags = cargoBuildFlags;

Related discussion:
text: I personally have been using it for a while and it works correctly (let me know if you need help, i'm on the matrix server with the same username). For now, I guess this issue can be closed because both are upstream bugs and the fixes will make it into a future release.
I think I we can backport the changes using patches. I'll send a PR.
Still I don't know how this 0.6.0 version was pulled from unstable into my system...I'm in my way learning nixos. Flakes! my never ending story :). I'll try to use it and if I have problems I'll try to ping you on the matrix server. Thx!
Since 0.6.0 reached unstable, of course, and you updated your channels/inputs. BTW the search can be out-of-date, so don't expect 100% accuracy from it.
Yep, that makes sense to me and seems to be the missing piece that confused me: how could it be possible that in the search appeared version 0.5 and I had installed v 0.6. thanks for clarifying it for me and for your work in Nixos.
Code change:
<ins> { lib , fetchFromGitHub , rustPlatform , at-spi2-atk , pkg-config , glib , gtk3 , gtk-layer-shell , installShellFiles , scdoc }: rustPlatform.buildRustPackage rec { pname = "wleave"; version = "0.3.0"; src = fetchFromGitHub { owner = "AMNatty"; repo = "wleave"; rev = version; hash = "sha256-qo9HnaWYsNZH1J8lAyKSwAOyvlCvIsh9maioatjtGkg="; }; cargoHash = "sha256-6Gppf1upWoMi+gcRSeQ1txSglAaBbpOXKs2LoJhslPQ="; nativeBuildInputs = [ pkg-config installShellFiles scdoc ]; buildInputs = [ at-spi2-atk gtk3 gtk-layer-shell glib ]; postInstall = '' for f in man/*.scd; do local page="man/$(basename "$f" .scd)" scdoc < "$f" > "$page" installManPage "$page" done installShellCompletion --cmd wleave  --bash <(cat completions/wleave.bash)  --fish <(cat completions/wleave.fish)  --zsh <(cat completions/_wleave) ''; meta = with lib; { description = "A Wayland-native logout script written in GTK3"; homepage = "https://github.com/AMNatty/wleave"; license = licenses.mit; mainProgram = "wleave"; maintainers = with maintainers; [ ludovicopiero ]; platforms = platforms.linux; }; } </ins>

Related discussion:
text: Project description A Wayland-native logout script written in Gtk3 Metadata homepage URL: source URL: license: mit platforms: unix, linux
It's already packaged in nixpkgs-wayland IIRC
Code change:
ln -s ${extraInit} $out/lib/php.ini if test -e $out/bin/php; then <del> wrapProgram $out/bin/php --set PHP_INI_SCAN_DIR $out/lib </del> <ins> wrapProgram $out/bin/php --prefix PHP_INI_SCAN_DIR : $out/lib </ins> fi if test -e $out/bin/php-fpm; then <del> wrapProgram $out/bin/php-fpm --set PHP_INI_SCAN_DIR $out/lib </del> <ins> wrapProgram $out/bin/php-fpm --prefix PHP_INI_SCAN_DIR : $out/lib </ins> fi if test -e $out/bin/phpdbg; then <del> wrapProgram $out/bin/phpdbg --set PHP_INI_SCAN_DIR $out/lib </del> <ins> wrapProgram $out/bin/phpdbg --prefix PHP_INI_SCAN_DIR : $out/lib </ins> fi ''; };

Related discussion:
text: Since it's not possible to use PHPINISCANDIR variable to pass additional php configuration. That breaks tools also. To Reproduce Steps to reproduce the behavior: 1 . Install php74 Expected behavior Notify maintainers Metadata
Env variable concatenation should fix it
This was intentional to avoid impure state, IIRC. The expressions we have now are very flexible. You can create a executable to include any configuration desired on the fly like so: nix-shell -p 'php.buildEnv { extraConfig = "memorylimit = -1"; }'. Also keep in mind you can pass configuration via to any instance.
By the way... are you familiar with ? Combine with and you have a really powerful combo that accomplishes what you want and more.
sure, I'm working on this kind of setup for my long running projects and I love it. Just migrated from 20.03 where we haven't soo much options. However, for some short term scenarions (like clone, patch, test, remove) creating nix config is not an option. Most of projects maintain their own and symfony tool use them both for cli and web/fpm without any additional setup and cost. I'm ok to use php -d / php -c , but still ignores custom ini files on 20.09
I didn't know that HPINISCANDIR can have multiple directories, but if that's the case, prefixing it in is fine. I mean, we also do that for many other env vars such as , etc.
Yeah I think that should be fine. I would like and to give a thumbs up first, just to make sure the idea is congruent in their minds. You're still happy if we don't automatically import though, right?
This claim seems interesting to me, I have, probably never seen a project provide a And I've been working professionally with PHP for about 10 years. And from what I can recall I haven't ever seen this before. Even working with symfony components along that way. So maybe some does, but I wouldn't say that "most projects does". I wasn't aware of this either, but from reading the documentation again: It's kinda clear that it allows the variable to be separated as any other like variable. I'm fine with introducing the possibility for such impurity just for flexibility for usages such as
there is backported version also can we merge it too?
Code change:
bazel_1 = callPackage ../development/tools/build-managers/bazel/bazel_1 { inherit (darwin) cctools; inherit (darwin.apple_sdk.frameworks) CoreFoundation CoreServices Foundation; <del> buildJdk = jdk8; </del> <ins> buildJdk = jdk8_headless; </ins> buildJdkName = "jdk8"; runJdk = jdk11_headless; stdenv = if stdenv.cc.isClang then llvmPackages_6.stdenv else stdenv;

Related discussion:
text: Describe the bug Bazel is currently broken on the latest master, tested at . Bazel was built fine back at . I'm currently bisecting trying to find the offending commit. To Reproduce Steps to reproduce the behavior: -build . -A bazel Expected behavior Bazel builds correctly on Darwin. Additional context <details<summaryError log</summary</detailsNotify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. Maintainer information:
I suppose this might be related:
It's possible. I reverted , , and but I could not verify that it works because gcc failed to build. <details<summarygcc error</summary</details
perhaps or can provide some guidance here. I'm not familiar with how it's all wired up together in nixpkgs.
What’s the content of that fails?
I'm trying to compare the environment of the working build against the one not working. As far as Nix environment variables go, there are no differences except for these that are missing: However, exporting them does not seem to make a difference.
I've tried several different iterations, I'm unsure how to fix this. Anyone else would like to take a stab at this? Things I've tried: Adding clang to the buildInputs, nativeBuildInputs and propagatedBuildInputs. This was a long shot but gave it a try anyway. Exported the and . Added to the and of the bazelrc construction at line 421. Added various files in to NIXLDFLAGS and NIXCFLAGSCOMPILE I also compared the NIXLDFLAGS and NIXCFLAGS_COMPILE between the working version and HEAD, I did not find anything different.
I am not quite sure what the actual error message produced by bazel. However to debug this, you can do to see what flags are passed to the actual gcc.
This is not set if c++ usage is not detected. See also this bit: If you want to include those manually you need to put them in instead. This can affect C programs however.
proposed to check whether it’s a similar issue than what was solved in (He’s not available the next few days though.)
did fix this?
This should be fixed in
Code change:
ip2location-c = callPackage ../development/libraries/ip2location-c { }; <del> iir1 = callPackage ../development/libraries/iir1 { }; </del> irrlicht = if !stdenv.isDarwin then callPackage ../development/libraries/irrlicht { } else callPackage ../development/libraries/irrlicht/mac.nix {

Related discussion:
text: Steps to reproduce the behavior: dosbox-staging on darwin Complaining that alsa-lib not available on darwin I suggest referencing the derivation of in which use to opt-in dependencies P.S. wonder why the maintenance of this package is separated from and Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I don't have a Darwin machine. Nice. A full log would be nicer of course, but nice nonetheless. Wonder why they should be maintained by the same people.
Code change:
<ins> { lib , stdenv , fetchFromSourcehut }: stdenv.mkDerivation rec { pname = "swipe-guess"; version = "0.2.1"; src = fetchFromSourcehut { owner = "~earboxer"; repo = "swipeGuess"; rev = "v${version}"; hash = "sha256-8bPsnqjLeeZ7btTre9j1T93VWY9+FdBdJdxyvBVt34s="; }; dontConfigure = true; buildPhase = '' runHook preBuild ${lib.getExe stdenv.cc} swipeGuess.c -o swipeGuess runHook postBuild ''; postInstall = '' install -Dm555 swipeGuess -t $out/bin ''; meta = { description = "Completion plugin for touchscreen-keyboards on mobile devices"; homepage = "https://git.sr.ht/~earboxer/swipeGuess/"; license = lib.licenses.agpl3Only; mainProgram = "swipeGuess"; maintainers = with lib.maintainers; [ eclairevoyant ]; platforms = lib.platforms.all; }; } </ins>

Related discussion:
text: Project description Turn swipes into words -- "plugin" for wvkbd to enable swipe-typing under wayland SXMO. Metadata homepage URL: source URL: license: agpl3 platforms: at least
Code change:
src = fetchFromGitHub { owner = "EdenEast"; repo = "nightfox.nvim"; <del> rev = "f9b0f96f61a4aa136f9fd6a04e60829f50eda9b0"; sha256 = "0p28x0xsahr9z1a4zgnjlxrdb7wv8p82gh0gc9rbfprym230k9lg"; </del> <ins> rev = "2b19e2ad758f078b607408b15bdaf39f3beafac6"; sha256 = "0xn78z74wldjq7p5xzlbv4562b6i5nha3lj0bc2hv6w9n3m7q494"; </ins> }; meta.homepage = "https://github.com/EdenEast/nightfox.nvim/"; };

Related discussion:
text: Project description Various vim plugins iamcco/coc-tailwindcss coc-extensions/coc-svelte evanleck/vim-svelte
Code change:
fuzzywuzzy = callPackage ../development/python-modules/fuzzywuzzy { }; <ins> fvs = callPackage ../development/python-modules/fvs { }; </ins> fx2 = callPackage ../development/python-modules/fx2 { }; galario = toPythonModule (pkgs.galario.override {

Related discussion:
text: Vulkan/dxvk doesnt work on bottles. Vulkan is working correctly on my laptop as vkcube, vulkaninfo and the game im trying to run on bottles (that i ran thru wineWowPackages.staging + dxvk install from the official archive file) run perfectly. Steps to reproduce the behavior: bottles a bottle for gaming a game. the "directx error" pop up. Also, the dxvk log files say that the "VKKHRsurface" extension failed to load. DXVK/Vulkan should work on bottles. ! Please run and paste the result.
Having the exact same Issue on 22.11pre393800. (Raccoon)
If fails then there is a driver issue. Vulkan wont be able to draw anything to screen without it. When it occurs in proton issues it's usually a missing 32bit Vulkan library. Tho there can ofc probably be other causes
update: using the system wine doesn't fix dxvk either. only running thru the command line does. As i said, running it thru wine on the terminal does work, so something in the bottles thing is not working right.
I found the cause: these hardcoded paths right there: With this extra lines in , Vulkan will work on Bottles: I'm not sure if this is the best way to solve it, though. Tested only on a 64-bit bottle (I don't know if 32-bit bottles need to also link ). .
!!! nice find!
Code change:
fuzzywuzzy = callPackage ../development/python-modules/fuzzywuzzy { }; <ins> fvs = callPackage ../development/python-modules/fvs { }; </ins> fx2 = callPackage ../development/python-modules/fx2 { }; galario = toPythonModule (pkgs.galario.override {

Related discussion:
text: <!-- 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: bottles <!-- 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: 2022.5.28-trento-3 desired version: 2022.7.14-brescia-1 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
While automatic update using was removed by in you need to wait while we will "get auto updates from r-rynatm"
That not true. I removed the over complicated updater in which wasn't necessary at all. Since r-ryantm also uses nix-update there was also no need to replace it. That's wrong. You can always create an update PR yourself by running ` or by manually update the package and create a PR with that. r-ryantm goes through all packages so it can sometimes take a few days until the update PR is created. Also nix-update is very lightweight with minimal dependencies, so there is not really a reason to not use it. It also does not require any kind of token or authentication.
Bottles the version released after the one currently present in nixpkgs, was released on June 13. Over one month has passed, so something about the auto-updater isn't working.
The latest r-ryantm log is here . Not sure why that is not working like it should.
I guess a update script is needed for this case :disappointed: Since the package is using , it HAS a fallback update script , so nixpkgs-update is no longer trying to figure out the latest version itself but just run the script.
Code change:
fuzzywuzzy = callPackage ../development/python-modules/fuzzywuzzy { }; <ins> fvs = callPackage ../development/python-modules/fvs { }; </ins> fx2 = callPackage ../development/python-modules/fx2 { }; galario = toPythonModule (pkgs.galario.override {

Related discussion:
text: However seems like cannot handle the version , so it will fail at You may just try Repology gets software latest version from various Linux distributions that ships this app, so since AUR and OpenMandriva have 2022.6.14 (no suffix) the latest version is 2022.6.14. Looks like there is also an related report in Note that nixpkgs-update does not really tries to bump package in this way because it has an fallback update script.
Code change:
configureScript = "./mconfig"; configureFlags = [ <del> "--localstatedir=/var/lib" </del> <ins> "--localstatedir=${if externalLocalStateDir != null then externalLocalStateDir else "${placeholder "out"}/var/lib"}" </ins> "--runstatedir=/var/run" ] ++ lib.optional (!enableSeccomp) "--without-seccomp"

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:
mkdir -p $out/etc/udev/rules.d sed -i '/udev-acl/d' usb/55-Argyll.rules cp -v usb/55-Argyll.rules $out/etc/udev/rules.d/ <ins> sed -i -e 's/^CREATED .*/CREATED "'"$(date -d @$SOURCE_DATE_EPOCH)"'"/g' $out/share/argyllcms/RefMediumGamut.gam </ins> ''; meta = with lib; {

Related discussion:
text: Describe the bug fails to build when attempting to cross-compile to aarch64 on : To Reproduce Expected behavior builds without error. Metadata nixpkgs Maintainer information:
I marked this as stale due to inactivity. &rarr;
Not stale - this issue still reproduces on current nixos-unstable ()
Code change:
# Home of persistent runner data, e.g., credentials StateDirectory = [ systemdDir ]; StateDirectoryMode = "0700"; <del> WorkingDirectory = runtimeDir; </del> <ins> WorkingDirectory = workDir; </ins> InaccessiblePaths = [ # Token file path given in the configuration, if visible to the service

Related discussion:
text: Working with large repositories on low-memory systems (such as aarch64-linux SBCs) can lead to out-of-storage scenarios with the github-runner service because the working directory is set to by default , which is sized to 25% of the system memory by default . Ideally there can be an option to use storage instead of memory for the working directory. I'm opening an issue first because I am not sure if there is a way to work around this already; can the argument in the service be overridden, or is there another way to change for this service with a systemd setting? If there isn't a straightforward solution I can open a PR to add this as an option. Maintainers:
I also experienced issues with no space left on . So far, however, increasing its size did the job. Nevertheless, I'd also appreciate the option to use another filesystem for the runtime directory. We won't be able to use systemd for that as it demands a -like filesystem for the runtime directory.
I guess standard installs avoid this by using the directory. Maybe we should just document how increase size instead of adding another option?
You may pass an arbitrary path to the options of the configuration script. Our module currently always uses the runtime directory systemd assigns to the service.
Yeah, in our case using the runtime directory that provides makes the most sense for dynamic user, again, with documentation on how to increase the size of the runtime directory. Currently our module doesn't support static users so isn't very useful... though I'm guessing our lack of support for static users is an oversight - see details here:
Code change:
makeWrapper, nix-update-script, python3, <ins> fetchpatch, </ins> fuseSupport ? false, }:

Related discussion:
text: This is . Trying to build bcachefs-tools` for an aarch64-linux from x86_64-linux produces: I think comes from binutils. Adding binutils to nativeBuildInputs wasn't enough to fix it.
It's using a non-prefixed version of , it should instead be using
And after that we need to pass something like to cargo (or maybe directly to rustc?) somewhere. And we're spoiled for choice here: from in the Makefile to and env variables to maybe even .
I was able to fix this partially with this diff: That fixed the issue but seems like our libraries are incompatible? <details</details
Something has to be substituted in the source because ar is hardcoded
Applying that patch and adding The build now fails at
command encounters an error? Weird.
The built file is in instead of
Code change:
x86_64-linux = x86_64-linux-version; }.${system} or throwSystem; <del> src = let base = "https://downloads.slack-edge.com"; in { x86_64-darwin = fetchurl { url = "${base}/releases/macos/${version}/prod/x64/Slack-${version}-macOS.dmg"; sha256 = x86_64-darwin-sha256; }; x86_64-linux = fetchurl { url = "${base}/linux_releases/slack-desktop-${version}-amd64.deb"; sha256 = x86_64-linux-sha256; }; }.${system} or throwSystem; </del> <ins> src = let base = "https://downloads.slack-edge.com"; in { x86_64-darwin = fetchurl { url = "${base}/releases/macos/${version}/prod/x64/Slack-${version}-macOS.dmg"; sha256 = x86_64-darwin-sha256; }; x86_64-linux = fetchurl { url = "${base}/linux_releases/slack-desktop-${version}-amd64.deb"; sha256 = x86_64-linux-sha256; }; }.${system} or throwSystem; </ins> meta = with lib; { description = "Desktop client for Slack";

Related discussion:
text: Describe the bug Starting slack doesn't show the window in 8 out of 10 runs To Reproduce Steps to reproduce the behavior: Expected behavior Slack window should open Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. 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 system: host os: multi-user?: sandbox: version: channels(ymatsiuk): channels(root): nixpkgs: Maintainer information:
Code change:
, SDL2_net , alsa-lib , copyDesktopItems <ins> , darwin </ins> , fluidsynth , glib , gtest

Related discussion:
text: Steps to reproduce the behavior: dosbox-staging on darwin Complaining that alsa-lib not available on darwin I suggest referencing the derivation of in which use to opt-in dependencies P.S. wonder why the maintenance of this package is separated from and Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I don't have a Darwin machine. Nice. A full log would be nicer of course, but nice nonetheless. Wonder why they should be maintained by the same people.