jiebi/CodeConvo huggingface dataset:
Code change:
singularity = finalAttrs.finalPackage; }; }; <ins> gpuChecks = lib.optionalAttrs (projectName == "apptainer") { # Should be in tests, but Ofborg would skip image-hello-cowsay because # saxpy is unfree. image-saxpy = callPackage ({ singularity-tools, cudaPackages }: singularity-tools.buildImage { name = "saxpy"; contents = [ cudaPackages.saxpy ]; memSize = 2048; diskSize = 2048; singularity = finalAttrs.finalPackage; }) { }; saxpy = callPackage ({ runCommand, writeShellScriptBin }: let unwrapped = writeShellScriptBin "apptainer-cuda-saxpy" '' ${lib.getExe finalAttrs.finalPackage} exec --nv $@ ${finalAttrs.passthru.tests.image-saxpy} saxpy ''; in runCommand "run-apptainer-cuda-saxpy" { requiredSystemFeatures = [ "cuda" ]; nativeBuildInputs = [ unwrapped ]; passthru = { inherit unwrapped; }; } '' apptainer-cuda-saxpy '') { }; }; </ins> }; })

Related discussion:
text: Before I start posting any details (I don't want to re-open this issue, but I'm also not sure if I'm just doing something wrong) I was wondering if the current implementation of singularity/apptainer on NixOS is expected to work, and I'm just being an idiot, or if there are known breaking issues? I've seen the other issues about singularity/apptainer here, but I'm not knowledgeable enough to make a judgement call if they are responsible for my problem or not. Thanks very much in advance!
(If I understood the message correctly) That usually means you need a reboot, and you should experience the same issue outside the container
No, the reboot didn't help either. For some reason, though, after upgrading to 24.05, everything "just works[tm]" again. So, whatever the issue was, thanks for fixing it (probably)! :)
Thanks to Nixpkgs 24.05 includes GPU-related changes/fixes to the package and the module.
Well more like thanks to ShamrockLee
Code change:
<del> --- old/build/pkgs/git/spkg-install	2015-07-26 15:34:43.000000000 +0200 +++ new/build/pkgs/git/spkg-install	2015-09-17 08:28:03.586657451 +0200 @@ -45,6 +45,8 @@ fi done </del> <ins> diff --git a/build/pkgs/git/spkg-install b/build/pkgs/git/spkg-install index 8469cb58c2..d0dc9a1db9 100755 --- a/build/pkgs/git/spkg-install +++ b/build/pkgs/git/spkg-install @@ -35,6 +35,8 @@ fi </ins> <del> +find . -exec sed -e 's@/usr/bin/perl@perl@g' -i '{}' ';' </del> <ins> cd src +find . -type f -exec sed -e 's@/usr/bin/perl@perl@g' -i '{}' ';' </ins> + # We don't want to think about Fink or Macports export NO_FINK=1

Related discussion:
text: Since Sage is huge and complicated, I figured I would make this issue to collaboratively track progress and share branches. One big issue is that Sage 7 , instead they use some with scant documentation . has the correct SHA256 for Sage 7.6 and updates a patch file. It currently fails when Sage tries to build . Some nice things to do for the future: ) cc:
thanks for picking this up
Me myself being a miserable loser who has failed to update Sage in the past, I hope you succeed… My attempt hit the following wall. It is unbearably slow to let Sage build everything, but when I had convinced it to use the system versions of majority of dependencies it began to complain cryptically about their interaction in some case.
Can you elaborate? Do you have a branch that has that work? Also, to be clear: I probably don't have the skills or time to upgrade Sage by myself, I was hoping that if we shared our knowledge and de-duplicated efforts we might be able to get closer together
I think it was 6-dot-something; it required a metric ton of adding options to the packages in NixPkgs (I have pushed that all to master long ago), and the Sage tricks are most likely too version-specific. It was long enough ago that I have since abandoned and lost the changes.
In case anybody in here is still waiting for this: I got sage to compile and run. I'm currently trying to minimize the dependencies and check that everything is working correctly (there is one doctest failure, but it was mentioned multiple times in the mailing list and apperas to be harmles -- just a timeout). I'll probably make a PR in the next couple of days.
Code change:
<del> --- old/build/pkgs/git/spkg-install	2015-07-26 15:34:43.000000000 +0200 +++ new/build/pkgs/git/spkg-install	2015-09-17 08:28:03.586657451 +0200 @@ -45,6 +45,8 @@ fi done </del> <ins> diff --git a/build/pkgs/git/spkg-install b/build/pkgs/git/spkg-install index 8469cb58c2..d0dc9a1db9 100755 --- a/build/pkgs/git/spkg-install +++ b/build/pkgs/git/spkg-install @@ -35,6 +35,8 @@ fi </ins> <del> +find . -exec sed -e 's@/usr/bin/perl@perl@g' -i '{}' ';' </del> <ins> cd src +find . -type f -exec sed -e 's@/usr/bin/perl@perl@g' -i '{}' ';' </ins> + # We don't want to think about Fink or Macports export NO_FINK=1

Related discussion:
text: Sage needs texlive-core-2014, which is deprecated. Run with modern nixpkgs (i.e. from git) System: NixOS: (Flounder) Nix version: nix-env (Nix) 1.11.2 Nixpkgs version:
Code change:
, fetchFromGitHub , singularity , python3Packages <ins> , fetchpatch </ins> }: python3Packages.buildPythonApplication rec {

Related discussion:
text: Steps to reproduce the behavior: udocker against the master branch of Nixpkgs () Add any other context about the problem here. <!-- 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.
Code change:
pamtester = callPackage ../tools/security/pamtester { }; <ins> pantheon-tweaks = callPackage ../applications/system/pantheon-tweaks { }; </ins> paperless-ng = callPackage ../applications/office/paperless-ng { }; paperwork = callPackage ../applications/office/paperwork/paperwork-gtk.nix { };

Related discussion:
text: Project description Pantheon Tweaks is a Switchboard plug allowing users to somewhat tweak Pantheon (elementary OS's DE) settings of the more hidden kind, not normally available from Switchboard. As NixOS has Pantheon packaged, it might be of use in Nixpkgs. Metadata homepage URL: source URL: license: platforms: same as Pantheon Depending on Pantheon version currently in Nixpkgs, the predecessor elementary-tweaks, also GPLv3, might be of more use:
As I maintain Pantheon in NixOS, I approve of this being packaged in the future, but not , because it's archived and IIRC I denied that .
Then we should probably do it once Pantheon in NixOS advances to whatever version elementary OS 6 Odin will have - this'll probably happen once elementary OS 6 will get released.
Ah yes, the repo says "Pantheon Tweaks is currently only supported on elementary OS Odin" :+1:
Did some initial work for this (), would you like to try that? Will need Pantheon 6 () and following line in your NixOS configuration file: Update: I will move this out from the pantheon namespace when creating the PR due to reasons below.
Did some initial work for this great! would you like to try that? of course works great. only the force darkmode did not work in minder program. haven't tested more... ! ! maybe it could be enabled by an option like ? So it's consistent with other options like .
Tested 1.13.1 on both elementary OS (installed via appcenter) and NixOS (btw minder in Nixpkgs seems out-of-date, just opened a PR: ), I guess this should be an issue to minder, as minder is trying to read information from of granite (, ), so it should respect settings from switchboard-plug-pantheon-shell, while what pantheon-tweaks does is (I guess) setting under you gtk config file and I am not sure how handle this. You can check this with: ! I am not sure as this is not an official part of Pantheon. I guess it should be okay to do this.
I am not sure as this is not an official part of Pantheon.
Code change:
pamtester = callPackage ../tools/security/pamtester { }; <ins> pantheon-tweaks = callPackage ../applications/system/pantheon-tweaks { }; </ins> paperless-ng = callPackage ../applications/office/paperless-ng { }; paperwork = callPackage ../applications/office/paperwork/paperwork-gtk.nix { };

Related discussion:
text: yes, that is a concern, but we can make that clear in the description do you think it is acceptable to enable a third-party component (e.g. pantheon-tweaks) with an option like if we clarify that it is third-party in the description, which is for example displayed at the or in the documentation?
I would not recommend packaging this tweaks app. It regularly breaks since it references gsettings that aren't considered API. That's just my personal opinion though I'm not familiar with NixOS options or what that means so I can't really offer an opinion there
thanks for your opinion! the program exists and people want to use it and we at nixos want to empower users to do what they want, even if the choices could be considered bad, like installing proprietary software. that's why it's considered for advanced users. you are responsible for the choices you make and you can end up with a broken system, but it's easy to roll back to a working state. experimenting is encouraged So i think it's fine for us to offer the package, but we can clarify that "it's not recommended by elementary because it regularly breaks". I'm not familiar with NixOS options or what that means so I can't really offer an opinion there i try to explain quickly: on nixos the whole system is configured by one (or multiple) config. file. as a consequence is read-only if you want to use pantheon, you add this line to the config: that sets up pantheon with default settings. there are options to change those default, like to remove default apps you don't need... so the question here is, all current options with in the name relate to official pantheon software, but would relate to third party software, which is not visible from the name. so it might not be 100% clear all the time so my suggestion is to clarify it at least in the description of the option that it is third-party and not recommended the concern is that it could devaluate you branding like the name "pantheon"
ah okay yeah. If possible then it would great if that was not namespaced with actual parts of pantheon and instead namespaced the way you would hand extensions or apps if there's no special convention for extensions. Thanks!
i suggest then
Code change:
maintainers = with maintainers; [ coroa sauyon ]; homepage = https://quodlibet.readthedocs.io/en/latest/; <del> broken = true; </del> }; }

Related discussion:
text: fails to install on . It worked before the recent update. It fails early on in the check phase. I'm guessing the fact that I have to build it from source at all is because it also fails everywhere else, so there's no cached build to download. Try to install on system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Hmm, the tests worked just fine for me on
Do they work for you now? What's kinda weird is that I never get an error message or anything. You see in the output I posted above, there's just loads of dots. It kind of sits there printing dots for a while and then it looks like it just times out or something.
For what it's worth if I put in the derivation, the resulting player is perfectly functional at least for my purposes. Haven't tested every feature or anything though.
I think it crashes during the test. I will try bisecting.
Bisecting was inconclusive because I ran out of resources when building webkitgtk.
What commands did you run? I have a server with plenty of resources that's just sitting idle at the moment, I could try run it on that.
but I guess it might make more sense to skip the builds where dependencies failed by running something like:
Cool, I've been running this for a while, for what it's worth it's currently narrowed it down to between and .
I'll let you know in the morning when it's finished.
The original bisect command I ran didn't take into account the case where dependencies failed to build, so I had to run it again with a script like the one you suggested. Here's the output of :
FWIW I managed to build it by setting in an overlay. Works for me, but I wouldn't suggest that this is done in the Hydra build of course!
Yeah, we should probably add in the expression if this still occurs.
I get quite a bit further, attempting to build rather than . The entire test suite finishes, then reports three test failures related to icons and GTK / GDK.
Seems like the tests are failing again
I marked this as stale due to inactivity. &rarr;
EDIT: Kindly ignore this comment, didn't notice that I was using the deprecated repository. Hi, I'm encountering the same errors as reported previously. In case anyone else is experiencing the same, I was able to fix them using:
Code change:
stdenv.mkDerivation rec { pname = "materia-kde-theme"; <del> version = "20210814"; </del> <ins> version = "20220607"; </ins> src = fetchFromGitHub { owner = "PapirusDevelopmentTeam"; repo = "materia-kde"; rev = version; <del> sha256 = "KfC1nB5WUcYixqSy5XCP+6Uqhs07Y3p2F1H+5HB8wAg="; </del> <ins> sha256 = "sha256-xshkp1Y5V8A3Fj4HCkmFpWcw3xEuNyRJqOLBkIKhwpQ="; </ins> }; makeFlags = [ "PREFIX=$(out)" ];

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: materia-kde-theme <!-- 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: desired version: <!-- 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:
}: appimageTools.wrapType2 rec { pname = "snipaste"; <del> version = "2.9-Beta2"; </del> <ins> version = "2.9.2-Beta"; </ins> src = fetchurl { url = "https://download.snipaste.com/archives/Snipaste-${version}-x86_64.AppImage"; <del> hash = "sha256-VJvw3M1Ohfji/PoIxn4gc9KcFl6H1wRYW5Pbf1p5rlg="; </del> <ins> hash = "sha256-oV69uABjzkbQdwb+1wRRxszhrwI4uyzhQZ4aXBnyeo8="; </ins> }; <del> meta = with lib; { </del> <ins> meta = { </ins> description = "Screenshot tools"; homepage = "https://www.snipaste.com/"; <del> license = licenses.unfree; maintainers = with maintainers; [ luftmensch-luftmensch ]; </del> <ins> license = lib.licenses.unfree; maintainers = with lib.maintainers; [ luftmensch-luftmensch ]; </ins> mainProgram = "snipaste"; platforms = [ "x86_64-linux" ]; <del> sourceProvenance = [ sourceTypes.binaryNativeCode ]; </del> <ins> sourceProvenance = [ lib.sourceTypes.binaryNativeCode ]; </ins> }; }

Related discussion:
text: Package name: snipaste Latest released version: 2.9.2-Beta <!-- Search your package here: --- Current version on the unstable channel: 2.9-Beta2 Current version on the stable/release channel: n/a <!-- 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]:
Code change:
./programs/npm.nix ./programs/noisetorch.nix ./programs/oblogout.nix <ins> ./programs/pantheon-tweaks.nix </ins> ./programs/partition-manager.nix ./programs/plotinus.nix ./programs/proxychains.nix

Related discussion:
text: Project description Pantheon Tweaks is a Switchboard plug allowing users to somewhat tweak Pantheon (elementary OS's DE) settings of the more hidden kind, not normally available from Switchboard. As NixOS has Pantheon packaged, it might be of use in Nixpkgs. Metadata homepage URL: source URL: license: platforms: same as Pantheon Depending on Pantheon version currently in Nixpkgs, the predecessor elementary-tweaks, also GPLv3, might be of more use:
As I maintain Pantheon in NixOS, I approve of this being packaged in the future, but not , because it's archived and IIRC I denied that .
Then we should probably do it once Pantheon in NixOS advances to whatever version elementary OS 6 Odin will have - this'll probably happen once elementary OS 6 will get released.
Ah yes, the repo says "Pantheon Tweaks is currently only supported on elementary OS Odin" :+1:
Did some initial work for this (), would you like to try that? Will need Pantheon 6 () and following line in your NixOS configuration file: Update: I will move this out from the pantheon namespace when creating the PR due to reasons below.
Did some initial work for this great! would you like to try that? of course works great. only the force darkmode did not work in minder program. haven't tested more... ! ! maybe it could be enabled by an option like ? So it's consistent with other options like .
Tested 1.13.1 on both elementary OS (installed via appcenter) and NixOS (btw minder in Nixpkgs seems out-of-date, just opened a PR: ), I guess this should be an issue to minder, as minder is trying to read information from of granite (, ), so it should respect settings from switchboard-plug-pantheon-shell, while what pantheon-tweaks does is (I guess) setting under you gtk config file and I am not sure how handle this. You can check this with: ! I am not sure as this is not an official part of Pantheon. I guess it should be okay to do this.
I am not sure as this is not an official part of Pantheon.
Code change:
./programs/npm.nix ./programs/noisetorch.nix ./programs/oblogout.nix <ins> ./programs/pantheon-tweaks.nix </ins> ./programs/partition-manager.nix ./programs/plotinus.nix ./programs/proxychains.nix

Related discussion:
text: yes, that is a concern, but we can make that clear in the description do you think it is acceptable to enable a third-party component (e.g. pantheon-tweaks) with an option like if we clarify that it is third-party in the description, which is for example displayed at the or in the documentation?
I would not recommend packaging this tweaks app. It regularly breaks since it references gsettings that aren't considered API. That's just my personal opinion though I'm not familiar with NixOS options or what that means so I can't really offer an opinion there
thanks for your opinion! the program exists and people want to use it and we at nixos want to empower users to do what they want, even if the choices could be considered bad, like installing proprietary software. that's why it's considered for advanced users. you are responsible for the choices you make and you can end up with a broken system, but it's easy to roll back to a working state. experimenting is encouraged So i think it's fine for us to offer the package, but we can clarify that "it's not recommended by elementary because it regularly breaks". I'm not familiar with NixOS options or what that means so I can't really offer an opinion there i try to explain quickly: on nixos the whole system is configured by one (or multiple) config. file. as a consequence is read-only if you want to use pantheon, you add this line to the config: that sets up pantheon with default settings. there are options to change those default, like to remove default apps you don't need... so the question here is, all current options with in the name relate to official pantheon software, but would relate to third party software, which is not visible from the name. so it might not be 100% clear all the time so my suggestion is to clarify it at least in the description of the option that it is third-party and not recommended the concern is that it could devaluate you branding like the name "pantheon"
ah okay yeah. If possible then it would great if that was not namespaced with actual parts of pantheon and instead namespaced the way you would hand extensions or apps if there's no special convention for extensions. Thanks!
i suggest then
Code change:
# Support 32bit Vulkan applications by linking in 32bit Vulkan layers # This is needed for the same reason the 32bit preload workaround is needed. <del> postInstall = lib.optionalString (stdenv.hostPlatform.system == "x86_64-linux") '' </del> <ins> postInstall = lib.optionalString lowerBitnessSupport '' </ins> ln -s ${mangohud32}/share/vulkan/implicit_layer.d/MangoHud.x86.json  "$out/share/vulkan/implicit_layer.d"

Related discussion:
text: Mangohud no longer appears on gnome/wayland when opening a game. "rev": "", (works) "rev": "", (doesn't) Steps to reproduce the behavior: a game on gnome/wayland doesn't appear even when enabled (worked in previous revision of nixpkgs above) ... Mangohud shows system stats Please run and paste the result.
I have the same problem too. I'm using Hyprland btw.
Oh weird. I'll try looking into this. The only thing that really sticks out to me in the diff is possibly ? - but it seems unlikely. I'll do a git bisect to try to narrow it down better.
If it helps you narrow down, here's my repo with the exact commit where mangohud stopped working. If I revert back to previous commit mangohud starts working again:
I bisected it, it's cc
mangohud uses its own internal copy of vulkan-headers: So it's probably the loader? If it is though, it might be tricky to bisect...
So, what are we going to do? Especially w.r.t. 23.05 being around the door. I don't think we should ship a broken mangohud in 23.05. Honestly, I think should have probably not made it to master before branch-off. (Eventhough it was technically merged a few dasy before breaking changes were restricted.)
I'll try to reproduce locally and see if I can bisect vulkan-loader.
cc because of
We could also try updating the headers externally; Mangohud's are really quite old. They use this weird meson wrap thingy rather than letting the distro provide it and it too is very out of date. Also, this is the error we're getting: (This is on 64-bit-only Mangohud.)
It breaks when built with newer headers.
Oh sorry, forgot to get back to this! Maybe we need to switch back to using the system headers?
I'm actually pretty sure it's which we probably don't want to revert, but we may need to look into layer ordering?
oh no - yeah i think you're right, i think the duplicate behaviour was specifically to support multi-arch layers (from what I remember).
Code change:
# Support 32bit Vulkan applications by linking in 32bit Vulkan layers # This is needed for the same reason the 32bit preload workaround is needed. <del> postInstall = lib.optionalString (stdenv.hostPlatform.system == "x86_64-linux") '' </del> <ins> postInstall = lib.optionalString lowerBitnessSupport '' </ins> ln -s ${mangohud32}/share/vulkan/implicit_layer.d/MangoHud.x86.json  "$out/share/vulkan/implicit_layer.d"

Related discussion:
text: If it's just an issue of duplicate layers, perhaps we could add 32 and 64 suffixes to the layer names. obs-vkcapture does that too.
I gave up o pursuing this, as seen in It works, but for this case here, it's probably better to bring attention upstream. Cc
Having only the 64-bit mangohud json in the implicit layer dir works! Going to try giving the 32-bit layer a different name now.
This is also going to affect vkbasalt too then - I haven't tried yet though - I'll take a look at fixing that too!
Speaking of, any reason you gave up on that? I personally really liked the good idea.
Different suffixes work! PR incoming.
It needed a proper rebase+bump to v1.3.250, and I couldn't figure out how to really take a good benefit from it.
Hm, I'll definitely try to pick it up after branch-off then.
Peculiarly, obs-vkcapture seem to do this for some time already: from gamescope might need this fix too.