jiebi/CodeConvo huggingface dataset:
Code change:
"pidgin@muffinmad" = callPackage ./pidgin-im-integration { }; "pop-shell@system76.com" = callPackage ./pop-shell { }; "sound-output-device-chooser@kgshank.net" = callPackage ./sound-output-device-chooser { }; <ins> "systemd-manager@hardpixel.eu" = callPackage ./systemd-manager { }; </ins> "taskwhisperer-extension@infinicode.de" = callPackage ./taskwhisperer { }; "tilingnome@rliang.github.com" = callPackage ./tilingnome { }; "TopIcons@phocean.net" = callPackage ./topicons-plus { };

Related discussion:
text: After reboot, while systemd units are still loading, if user clicks on Systemd-Manger extension the entire DE will crash and Gnome will force a log out of that user. Moreover, Systemd-Manager is at v14 when v15 is out from the developer. Steps to reproduce the behavior: Computer DE loads and user is logged in on Systemd-Manager (while the systemd units [custom systemd units by the user into the extension] are still loading for example "bitcoind") crashes and forces log out No crashing of DE and you should be able to see in Systemd-Manager the units that have not started without it crashing Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Any news on this? Thanks so much!
Any news on this Thanks so much!
Update should be contained in
sweet!!! Thanks, I will keep an eye on it. Thanks again!
I checked and plus the superseding still contain version 14. The author notes on the that they will no longer be publishing to that site, and indeed the latest version available for download there is still 14. So the metadata for that extension may need to be manually overridden in nixpkgs since it is not going to get the latest from via the automated update process.
This works as a standalone package, for inclusion in you'd probably be fine not declaring ,,. Would be happy to make a PR for it, though it's not something I'd actively mantain/use myself. Just updating the metadata itself wont do, as it would still be pulling from for nonexistent files.
Looks good! That updated package does fix the crash for me.
did you just install the package from nixos?
yes, it seems then having its own package would be the best no?
Ah no, it would need a PR to even get into nixpkgs. I just it to my local config using an overlay.
okay, well I will look into how to overly in a nix file. Also, it is hard to maintain a package? As, maybe I could learn how to maintain this extension if will be unable to maintain it?
Code change:
"pidgin@muffinmad" = callPackage ./pidgin-im-integration { }; "pop-shell@system76.com" = callPackage ./pop-shell { }; "sound-output-device-chooser@kgshank.net" = callPackage ./sound-output-device-chooser { }; <ins> "systemd-manager@hardpixel.eu" = callPackage ./systemd-manager { }; </ins> "taskwhisperer-extension@infinicode.de" = callPackage ./taskwhisperer { }; "tilingnome@rliang.github.com" = callPackage ./tilingnome { }; "TopIcons@phocean.net" = callPackage ./topicons-plus { };

Related discussion:
text: Maintaining an extension like this should be as simple as increasing the version number when a new release exists, given it's lack of external dependencies or nixos-specific quirks that need to be patched (there may be some out there). What I meant by not mantaining it is that I do not actively use it within my setup. And I assume these manually packaged ones would need at least a "reference" mantainer to keep it in check and direct issues to.
Thanks for the good info ! Well, I can be the maintainer, but I might need help from time to time. I will use your code if that is okay? So, next steps to put in the PR and then add me as the maintainer. Also, would you want to be on this as well?
piegamesde was only the maintainer of the original extension package because they're the . Manually packaged extensions go in and generally have a maintainer attribute set.
Circling back to this... I would like to be the maintainer of this plugin. However, I have never maintained a piece of software on github and I only have minimal skills with shell and nix configuration files. I have never made or packaged a nix module before. Should this task be reserved for someone else with more skills or is there someone who could mentor me in how to be a maintainer? Thank you all for the help in this.
Added this to extension creator's github :
Okay, I figured out how to add 's code into my existing setup. For all the noobs out there this is what I did it: I did NOT use the "overlay" process in NixOS as describe here: I used the process as described here: This is an excellent write up BTW! Save this link for future use. With these resources in mind, this is what I did. I used 's code and named the file . This naming is arbitrary. It can be anything you want as long it has at the end. Then, move that file into directory. Do this via terminal and you must be the user. Then in my NixOS (not nix) configuration file () I simply into the Then, like always, as root This is all explained in the link above. Limitations: hack does not put the new is in the official repository.
Code change:
"pidgin@muffinmad" = callPackage ./pidgin-im-integration { }; "pop-shell@system76.com" = callPackage ./pop-shell { }; "sound-output-device-chooser@kgshank.net" = callPackage ./sound-output-device-chooser { }; <ins> "systemd-manager@hardpixel.eu" = callPackage ./systemd-manager { }; </ins> "taskwhisperer-extension@infinicode.de" = callPackage ./taskwhisperer { }; "tilingnome@rliang.github.com" = callPackage ./tilingnome { }; "TopIcons@phocean.net" = callPackage ./topicons-plus { };

Related discussion:
text: This needs to be done by someone and they will become the maintainer. you use this hack you will have to update the for NixOS whenever the developers of release a new update.
Upstream devs released version 16. Whoo hooo! Here is the .nix to make it work on your local machine. Again, this is not in the main nixpkgs repo. You will have to use this code and follow my "hack"above to get it to run in your local nix install. Thanks again to for the original code.
Code change:
{stdenv , removeReferencesTo , lib <del> , fetchFromGitHub </del> <ins> , fetchurl </ins> , utillinux <ins> , gpgme </ins> , openssl <ins> , libuuid </ins> , coreutils , go , which , makeWrapper <ins> , cryptsetup </ins> , squashfsTools , buildGoPackage}:

Related discussion:
text: , CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) Scanned versions: nixos-20.03: . May contain false positives. Cc Cc Cc
Backporting update that resolves these ().
Fixed in 20.03 and master.
Code change:
, libXext , sdbus-cpp , udev <ins> , xcbutilimage </ins> , coreutils <ins> , cli11 , ddcutil , fmt , nlohmann_json , spdlog </ins> }: stdenv.mkDerivation rec { pname = "gummy"; <del> version = "0.3"; </del> <ins> version = "0.6.0"; </ins> <del> src = fetchFromGitHub { owner = "fushko"; </del> <ins> src = fetchFromGitea { domain = "codeberg.org"; owner = "fusco"; </ins> repo = "gummy"; rev = version; <del> sha256 = "sha256-dw2yOXTS61OIe+NOq8MPydhkZvTit13eC7cbL5nFseg="; </del> <ins> hash = "sha256-kATieFf+dEpcYgSEPoETacP7R+u2dOrg7rOhIkNQ1uE="; </ins> }; nativeBuildInputs = [

Related discussion:
text: Package name: gummy Latest released version: 0.6.0 <!-- Search your package here: --- Current version on the unstable channel: 0.3 Current version on the stable/release channel: 0.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! --- There is an open pull request () by from October 2023, but it has not been merged and later versions of the program have been released since then. I think it is also worth noting that the source code repository of the is no longer available on GitHub. as the repository has moved to Codeberg (see ). Notify maintainers (last updated the package) <!-- 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]:
I updated my linked PR to the latest version.
Thank you for updating it so quickly! Is there a time frame in which we can expect the pull request to be merged by someone?
Code change:
, libXext , sdbus-cpp , udev <ins> , xcbutilimage </ins> , coreutils <ins> , cli11 , ddcutil , fmt , nlohmann_json , spdlog </ins> }: stdenv.mkDerivation rec { pname = "gummy"; <del> version = "0.3"; </del> <ins> version = "0.6.0"; </ins> <del> src = fetchFromGitHub { owner = "fushko"; </del> <ins> src = fetchFromGitea { domain = "codeberg.org"; owner = "fusco"; </ins> repo = "gummy"; rev = version; <del> sha256 = "sha256-dw2yOXTS61OIe+NOq8MPydhkZvTit13eC7cbL5nFseg="; </del> <ins> hash = "sha256-kATieFf+dEpcYgSEPoETacP7R+u2dOrg7rOhIkNQ1uE="; </ins> }; nativeBuildInputs = [

Related discussion:
text: Package name: gummy Latest released version: 0.5.4 <!-- Search your package here: --- Current version on the unstable channel: 0.3 Current version on the stable/release channel: 0.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 I've tried to bump the version to 0.5.4. <details<summaryThe build fails when downloading json-poputlate</summary</details<!-- If the result shows no maintainers, tag the person that last updated the package. --
Code change:
<ins> --- old/build/pkgs/giac/spkg-install	2017-07-21 14:10:00.000000000 -0500 +++ new/build/pkgs/giac/spkg-install	2017-10-15 15:55:55.321237645 -0500 @@ -4,6 +4,8 @@ ## Giac ########################################### +find . -type f -exec sed -e 's@/bin/cp@cp@g' -i '{}' ';' && echo "Patching input parser" && find . -iname 'input_parser.cc' +sed -e 's@yylex (&yylval)@yylex (&yyval, scanner)@gp' -i 'src/src/input_parser.cc' if [ "$SAGE_LOCAL" = "" ]; then echo "SAGE_LOCAL undefined ... exiting"; </ins>

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:
<ins> --- old/build/pkgs/giac/spkg-install	2017-07-21 14:10:00.000000000 -0500 +++ new/build/pkgs/giac/spkg-install	2017-10-15 15:55:55.321237645 -0500 @@ -4,6 +4,8 @@ ## Giac ########################################### +find . -type f -exec sed -e 's@/bin/cp@cp@g' -i '{}' ';' && echo "Patching input parser" && find . -iname 'input_parser.cc' +sed -e 's@yylex (&yylval)@yylex (&yyval, scanner)@gp' -i 'src/src/input_parser.cc' if [ "$SAGE_LOCAL" = "" ]; then echo "SAGE_LOCAL undefined ... exiting"; </ins>

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:
--add-flags ${electron}/bin/electron  --add-flags $out/share/itch/resources/app  --set BROTH_USE_LOCAL butler,itch-setup  <del> --prefix PATH : ${butler}/bin/:${itch-setup} </del> <ins> --prefix PATH : ${butler}:${itch-setup} </ins> ''; <del> meta = with lib; { </del> <ins> meta = { </ins> description = "Best way to play itch.io games"; homepage = "https://github.com/itchio/itch"; <del> license = licenses.mit; platforms = platforms.linux; </del> <ins> license = lib.licenses.mit; platforms = lib.platforms.linux; </ins> sourceProvenance = [ lib.sourceTypes.binaryBytecode ]; <del> maintainers = with maintainers; [ pasqui23 ]; </del> <ins> maintainers = with lib.maintainers; [ pasqui23 ]; </ins> mainProgram = "itch"; }; <del> } </del> <ins> }) </ins>

Related discussion:
text: Package name: itch Latest released version: 26.1.3 Current version on the unstable channel: 26.1.3 Current version on the stable/release channel: 26.1.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! --- The current version is broken since butler is marked broken 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 latest version on seems to be 26.1.3 which is used in the package.
There is 26.1.5 as a source code , but current package uses binaryBytecode
Code change:
<ins> # expr and script based on our lsb_release { stdenv , lib , substituteAll , coreutils , getopt , modDirVersion ? "" }: substituteAll { name = "uname"; src = ./deterministic-uname.sh; dir = "bin"; isExecutable = true; inherit coreutils getopt; uSystem = if stdenv.buildPlatform.uname.system != null then stdenv.buildPlatform.uname.system else "unknown"; inherit (stdenv.buildPlatform.uname) processor; # uname -o # maybe add to lib/systems/default.nix uname attrset # https://github.com/coreutils/coreutils/blob/7fc84d1c0f6b35231b0b4577b70aaa26bf548a7c/src/uname.c#L373-L374 # https://stackoverflow.com/questions/61711186/where-does-host-operating-system-in-uname-c-comes-from # https://github.com/coreutils/gnulib/blob/master/m4/host-os.m4 operatingSystem = if stdenv.buildPlatform.isLinux then "GNU/Linux" else if stdenv.buildPlatform.isDarwin then "Darwin" # darwin isn't in host-os.m4 so where does this come from? else "unknown"; # in os-specific/linux module packages # --replace '$(shell uname -r)' "${kernel.modDirVersion}"  # is a common thing to do. modDirVersion = if modDirVersion != "" then modDirVersion else "unknown"; meta = with lib; { description = "Print certain system information (hardcoded with <nixpkgs/lib/system> values)"; longDescription = '' This package provides a replacement for `uname` whose output depends only on `stdenv.buildPlatform`.  It is meant to be used from within derivations. Many packages' build processes run `uname` at compile time and embed its output into the result of the build.  Since `uname` calls into the kernel, and the Nix sandbox currently does not intercept these calls, builds made on different kernels will produce different results. ''; license = [ licenses.mit ]; maintainers = with maintainers; [ artturin ]; platforms = platforms.all; }; } </ins>

Related discussion:
text: libgtop is not reproducible, since it embed the output of into one of its binaries. See or build on 2 machines with different kernel versions. Report attached since r13y will not keep it, I think: libgtop build should be reproducible. This patch works from a nixpkgs perspective: However, it should ideally be reported and fixed upstream. N/A Maintainer information:
I marked this as stale due to inactivity. &rarr;
Code change:
six tqdm urllib3 <del> ]; </del> <ins> ] ++ lib.optionals stdenv.isDarwin [ idna cryptography pyopenssl ]; </ins> checkInputs = [ pkg-config

Related discussion:
text: Description Attempting to install conan with nix-env on Mac OS X errors out with the following message: To Reproduce Steps to reproduce the behavior: Expected behavior As Mac OS X is a supported platform for conan, it's expected that it would install. Additional context This appears to be due to conan's dependency on the python3-distro package, which only compiles on Linux architectures. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(tclemons): channels(root): nixpkgs:
Code change:
# TODO: investigate and fix properly "-march=westmere" ] ++ lib.optionals stdenv.isDarwin [ <del> "-DMAC_OS_X_VERSION_MAX_ALLOWED=MAC_OS_X_VERSION_10_10" "-DMAC_OS_X_VERSION_MIN_REQUIRED=MAC_OS_X_VERSION_10_10" </del> <ins> "-DMAC_OS_X_VERSION_MAX_ALLOWED=MAC_OS_X_VERSION_10_12" "-DMAC_OS_X_VERSION_MIN_REQUIRED=MAC_OS_X_VERSION_10_12" </ins> # # Prevent errors like

Related discussion:
text: The component of the derivation fails to compile on MacOS. But in two ways, and I can't tell what causes one or the other to trigger. On command: On command: the channel compilation failure Compiles.
It has been broken for a while now for different reasons. Maintaining it for darwin is a lot of work and nobody has stepped up to do that. Also, this is a duplicate of
By the way, what is your use case for ?
We're building a desktop version of mobile application and we need for our in-app browser with Ethereum support.
Code change:
# TODO: investigate and fix properly "-march=westmere" ] ++ lib.optionals stdenv.isDarwin [ <del> "-DMAC_OS_X_VERSION_MAX_ALLOWED=MAC_OS_X_VERSION_10_10" "-DMAC_OS_X_VERSION_MIN_REQUIRED=MAC_OS_X_VERSION_10_10" </del> <ins> "-DMAC_OS_X_VERSION_MAX_ALLOWED=MAC_OS_X_VERSION_10_12" "-DMAC_OS_X_VERSION_MIN_REQUIRED=MAC_OS_X_VERSION_10_12" </ins> # # Prevent errors like

Related discussion:
text: Full log: Error message: That's the result I get from my macOS remote builder. When I run the build on my desktop Mac, it builds fine and uses the impure SDK from my Catalina install (10.15.1): However, the local build displays this warning repeatedly: I assume this is related to the macOS patches and hopefully gives some clue as to why it's broken.
qtbase builds fine on hydra: qtwebengine fails:
Those links point to the same thing. Anyway, strictly speaking I'm trying to build , but it's failing in .
Can you explain what do you mean? How are you using ?
It's a dependency of . edit: sorry, I see what you mean now. is a dependency of . I was confused by the message from the build saying that QT would be installed in .
Sure, depends on . Realistically, your best bet for now is to just use anki from an old version of nixpkgs. You see, doesn't have a darwin maintainer. I think, I was the last person to fix it around last January. The problem is that it's hard to keep up with all the updates. Every "minor" Qt version bump brings serious breaking changes for on darwin (like they might not even support our version of SDK anymore...). To make things worse we port all those bumps to the stable branch, so it quickly breaks there too.
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 .
Still important to me, many qt apps are broken on darwin due to this one.
Code change:
#!${pkgs.runtimeShell} diff <(echo 'hi') <(${pkgs.rclone}/bin/rclone cat nextcloud:test-shared-file) ''; <ins> findInClosure = what: drv: pkgs.runCommand "find-in-closure" { exportReferencesGraph = [ "graph" drv ]; inherit what; } '' test -e graph grep "$what" graph >$out || true ''; nextcloudUsesImagick = findInClosure "imagick" nodes.nextcloud.config.system.build.vm; nextcloudWithoutDoesntUseIt = findInClosure "imagick" nodes.nextcloudWithoutMagick.config.system.build.vm; </ins> in '' <del> start_all() </del> <ins> assert open("${nextcloudUsesImagick}").read() != "" assert open("${nextcloudWithoutDoesntUseIt}").read() == "" nextcloud.start() client.start() </ins> nextcloud.wait_for_unit("multi-user.target") # This is just to ensure the nextcloud-occ program is working nextcloud.succeed("nextcloud-occ status")

Related discussion:
text: There is about the use of imagemagick in NextCloud due to . Admins may want to disable it unless they are certain that users won't upload untrusted files (which can easily happen by accident if folder sync is active). NextCloud is only passing certain file types to imagemagick but it is doing so based on the file extension. Therefore, an attacker can pass any file type to imagemagick. I have tested this with a PNM image (not supported by NextCloud) that I have renamed to . doesn't get a preview image but does, i.e. NextCloud thinks it is HEIF and passes it to ImageMagick, which processes it as PNM. There are several ways to disable imagick: in the NextCloud config. This will not only disable imagick but also previews for PNG and JPEG (which do not use imagick). in the NextCloud config. This may need manual adjustment after a NextCloud update. the extension for PHP. This also disables it for NextCloud plugins. Option 1 and 2 can already be used by an admin if the drawbacks are acceptable. However, I think 3 is the best option in most cases. has options that disable the other PHP extensions that used to be by default. I think we should do the same for imagick. If imagick is disabled, NextCloud will automatically disable the preview generators that need it. It will also show a warning about that (which is subject to debate in the issue linked above) and there may be some implications for the themes app (which I don't use). Therefore, I think we should keep imagick enabled by default and leave the decision to the admin. We could also add a suitable policy for ImageMagick and thereby disable any file formats or features that are considered insecure. I don't think I could write such a policy and be sure that it is secure (or even "secure enough"). In addition, we will have to keep it up-to-date with newer versions and CVEs. That is why I recommend that we only add a simple off switch. The above information is based on NextCloud 20. I will wait until and NextCloud 21 have landed in nixos-unstable (and on my server) and then test again and create a PR if there is any interest in having this upstream.