Question:
When the tooling is updated, it should be run on Nixpkgs in the same PR. This also relates to This could be achieved using on the derivation which copies Nixpkgs to the store and then runs the tooling on it in a derivation. This would then automatically be run when a commit with the prefix is in the PR. This is however fairly slow and expensive due to the Nixpkgs copy.
OfBorg performs checkouts all the time. I don't think this is significant. To run it locally, this style of test runner is not great, but we can refer readers to the instructions for a manual run.
It's not just a local checkout though, if we use derivations to run the check, then Nixpkgs also needs to be copied into the store. Should probably be fine though, other parts of Nixpkgs also copy Nixpkgs into the store.
I don't think this should be done after all. With the latest idea , the latest version of the tooling in Nixpkgs needs to stay independent of the pinned version used for CI.
Agree that for the PR checking, the currently implemented approach is fine. However, I think it is still good to have the "simple" version that doesn't refer to other Nixpkgs / channels as a attribute. The point of this is not to catch CIs, but to just sanity check with hydra after the fact that everything worked out the way it should. The impure tricky business with channels is still necessary, but the idea is that it is an optimization and the simple self-contained version is the reference implementation that ultimately defines the behavior we want.
Implemented in , turns out this would've been really useful :sweat_smile:

env.NIXPKGS_LIB_PATH = toString nixpkgsLibPath; inputsFrom = [ package ]; }; <ins> # Tests the tool on the current Nixpkgs tree, this is a good sanity check passthru.tests.nixpkgs = runCommand "test-nixpkgs-check-by-name" { nativeBuildInputs = [ package nix ]; nixpkgsPath = lib.cleanSource ../../..; } '' ${initNix} nixpkgs-check-by-name --base "$nixpkgsPath" "$nixpkgsPath" touch $out ''; </ins> }; in package


Question:
When the tooling is updated, it should be run on Nixpkgs in the same PR. This also relates to This could be achieved using on the derivation which copies Nixpkgs to the store and then runs the tooling on it in a derivation. This would then automatically be run when a commit with the prefix is in the PR. This is however fairly slow and expensive due to the Nixpkgs copy.
OfBorg performs checkouts all the time. I don't think this is significant. To run it locally, this style of test runner is not great, but we can refer readers to the instructions for a manual run.
It's not just a local checkout though, if we use derivations to run the check, then Nixpkgs also needs to be copied into the store. Should probably be fine though, other parts of Nixpkgs also copy Nixpkgs into the store.
I don't think this should be done after all. With the latest idea , the latest version of the tooling in Nixpkgs needs to stay independent of the pinned version used for CI.
Agree that for the PR checking, the currently implemented approach is fine. However, I think it is still good to have the "simple" version that doesn't refer to other Nixpkgs / channels as a attribute. The point of this is not to catch CIs, but to just sanity check with hydra after the fact that everything worked out the way it should. The impure tricky business with channels is still necessary, but the idea is that it is an optimization and the simple self-contained version is the reference implementation that ultimately defines the behavior we want.
Implemented in , turns out this would've been really useful :sweat_smile:

// so the UsesByName ratchet is already as tight as it can be NonAttributeSet => Success(Tight), NonCallPackage => Success(Tight), <del> // This is an odd case when _internalCallByNamePackageFile is used to define a package. </del> <ins> // This is the case when the `pkgs/by-name`-internal _internalCallByNamePackageFile // is used for a package outside `pkgs/by-name` </ins> CallPackage(CallPackageInfo { call_package_variant: Auto, .. <del> }) => NixpkgsProblem::InternalCallPackageUsed { attr_name: attribute_name.clone(), </del> <ins> }) => { // With the current detection mechanism, this also triggers for aliases // to pkgs/by-name packages, and there's no good method of // distinguishing alias vs non-alias. // Using `config.allowAliases = false` at least currently doesn't work // because there's nothing preventing people from defining aliases that // are present even with that disabled. // In the future we could kind of abuse this behavior to have better // enforcement of conditional aliases, but for now we just need to not // give an error. Success(Tight) </ins> } <del> .into(), </del> // Only derivations can be in pkgs/by-name, // so this attribute doesn't qualify CallPackage(CallPackageInfo {


Question:
When the tooling is updated, it should be run on Nixpkgs in the same PR. This also relates to This could be achieved using on the derivation which copies Nixpkgs to the store and then runs the tooling on it in a derivation. This would then automatically be run when a commit with the prefix is in the PR. This is however fairly slow and expensive due to the Nixpkgs copy.
OfBorg performs checkouts all the time. I don't think this is significant. To run it locally, this style of test runner is not great, but we can refer readers to the instructions for a manual run.
It's not just a local checkout though, if we use derivations to run the check, then Nixpkgs also needs to be copied into the store. Should probably be fine though, other parts of Nixpkgs also copy Nixpkgs into the store.
I don't think this should be done after all. With the latest idea , the latest version of the tooling in Nixpkgs needs to stay independent of the pinned version used for CI.
Agree that for the PR checking, the currently implemented approach is fine. However, I think it is still good to have the "simple" version that doesn't refer to other Nixpkgs / channels as a attribute. The point of this is not to catch CIs, but to just sanity check with hydra after the fact that everything worked out the way it should. The impure tricky business with channels is still necessary, but the idea is that it is an optimization and the simple self-contained version is the reference implementation that ultimately defines the behavior we want.
Implemented in , turns out this would've been really useful :sweat_smile:

text: String, io_error: io::Error, }, <del> InternalCallPackageUsed { attr_name: String, }, </del> MovedOutOfByName { package_name: String, call_package_path: Option<PathBuf>,


Question:
When the tooling is updated, it should be run on Nixpkgs in the same PR. This also relates to This could be achieved using on the derivation which copies Nixpkgs to the store and then runs the tooling on it in a derivation. This would then automatically be run when a commit with the prefix is in the PR. This is however fairly slow and expensive due to the Nixpkgs copy.
OfBorg performs checkouts all the time. I don't think this is significant. To run it locally, this style of test runner is not great, but we can refer readers to the instructions for a manual run.
It's not just a local checkout though, if we use derivations to run the check, then Nixpkgs also needs to be copied into the store. Should probably be fine though, other parts of Nixpkgs also copy Nixpkgs into the store.
I don't think this should be done after all. With the latest idea , the latest version of the tooling in Nixpkgs needs to stay independent of the pinned version used for CI.
Agree that for the PR checking, the currently implemented approach is fine. However, I think it is still good to have the "simple" version that doesn't refer to other Nixpkgs / channels as a attribute. The point of this is not to catch CIs, but to just sanity check with hydra after the fact that everything worked out the way it should. The impure tricky business with channels is still necessary, but the idea is that it is an optimization and the simple self-contained version is the reference implementation that ultimately defines the behavior we want.
Implemented in , turns out this would've been really useful :sweat_smile:

subpath.display(), text, ), <del> NixpkgsProblem::InternalCallPackageUsed { attr_name } => write!( f, "pkgs.{attr_name}: This attribute is defined using `_internalCallByNamePackageFile`, which is an internal function not intended for manual use.", ), </del> NixpkgsProblem::MovedOutOfByName { package_name, call_package_path, empty_arg } => { let call_package_arg = if let Some(path) = &call_package_path {


Question:
When the tooling is updated, it should be run on Nixpkgs in the same PR. This also relates to This could be achieved using on the derivation which copies Nixpkgs to the store and then runs the tooling on it in a derivation. This would then automatically be run when a commit with the prefix is in the PR. This is however fairly slow and expensive due to the Nixpkgs copy.
OfBorg performs checkouts all the time. I don't think this is significant. To run it locally, this style of test runner is not great, but we can refer readers to the instructions for a manual run.
It's not just a local checkout though, if we use derivations to run the check, then Nixpkgs also needs to be copied into the store. Should probably be fine though, other parts of Nixpkgs also copy Nixpkgs into the store.
I don't think this should be done after all. With the latest idea , the latest version of the tooling in Nixpkgs needs to stay independent of the pinned version used for CI.
Agree that for the PR checking, the currently implemented approach is fine. However, I think it is still good to have the "simple" version that doesn't refer to other Nixpkgs / channels as a attribute. The point of this is not to catch CIs, but to just sanity check with hydra after the fact that everything worked out the way it should. The impure tricky business with channels is still necessary, but the idea is that it is an optimization and the simple self-contained version is the reference implementation that ultimately defines the behavior we want.
Implemented in , turns out this would've been really useful :sweat_smile:

<ins> self: super: { baz = self.foo; } </ins>


Question:
When the tooling is updated, it should be run on Nixpkgs in the same PR. This also relates to This could be achieved using on the derivation which copies Nixpkgs to the store and then runs the tooling on it in a derivation. This would then automatically be run when a commit with the prefix is in the PR. This is however fairly slow and expensive due to the Nixpkgs copy.
OfBorg performs checkouts all the time. I don't think this is significant. To run it locally, this style of test runner is not great, but we can refer readers to the instructions for a manual run.
It's not just a local checkout though, if we use derivations to run the check, then Nixpkgs also needs to be copied into the store. Should probably be fine though, other parts of Nixpkgs also copy Nixpkgs into the store.
I don't think this should be done after all. With the latest idea , the latest version of the tooling in Nixpkgs needs to stay independent of the pinned version used for CI.
Agree that for the PR checking, the currently implemented approach is fine. However, I think it is still good to have the "simple" version that doesn't refer to other Nixpkgs / channels as a attribute. The point of this is not to catch CIs, but to just sanity check with hydra after the fact that everything worked out the way it should. The impure tricky business with channels is still necessary, but the idea is that it is an optimization and the simple self-contained version is the reference implementation that ultimately defines the behavior we want.
Implemented in , turns out this would've been really useful :sweat_smile:

<ins> import <test-nixpkgs> { root = ./.; } </ins>


Question:
When the tooling is updated, it should be run on Nixpkgs in the same PR. This also relates to This could be achieved using on the derivation which copies Nixpkgs to the store and then runs the tooling on it in a derivation. This would then automatically be run when a commit with the prefix is in the PR. This is however fairly slow and expensive due to the Nixpkgs copy.
OfBorg performs checkouts all the time. I don't think this is significant. To run it locally, this style of test runner is not great, but we can refer readers to the instructions for a manual run.
It's not just a local checkout though, if we use derivations to run the check, then Nixpkgs also needs to be copied into the store. Should probably be fine though, other parts of Nixpkgs also copy Nixpkgs into the store.
I don't think this should be done after all. With the latest idea , the latest version of the tooling in Nixpkgs needs to stay independent of the pinned version used for CI.
Agree that for the PR checking, the currently implemented approach is fine. However, I think it is still good to have the "simple" version that doesn't refer to other Nixpkgs / channels as a attribute. The point of this is not to catch CIs, but to just sanity check with hydra after the fact that everything worked out the way it should. The impure tricky business with channels is still necessary, but the idea is that it is an optimization and the simple self-contained version is the reference implementation that ultimately defines the behavior we want.
Implemented in , turns out this would've been really useful :sweat_smile:

<del> pkgs.foo: This attribute is defined using `_internalCallByNamePackageFile`, which is an internal function not intended for manual use. </del>


Question:
When the tooling is updated, it should be run on Nixpkgs in the same PR. This also relates to This could be achieved using on the derivation which copies Nixpkgs to the store and then runs the tooling on it in a derivation. This would then automatically be run when a commit with the prefix is in the PR. This is however fairly slow and expensive due to the Nixpkgs copy.
OfBorg performs checkouts all the time. I don't think this is significant. To run it locally, this style of test runner is not great, but we can refer readers to the instructions for a manual run.
It's not just a local checkout though, if we use derivations to run the check, then Nixpkgs also needs to be copied into the store. Should probably be fine though, other parts of Nixpkgs also copy Nixpkgs into the store.
I don't think this should be done after all. With the latest idea , the latest version of the tooling in Nixpkgs needs to stay independent of the pinned version used for CI.
Agree that for the PR checking, the currently implemented approach is fine. However, I think it is still good to have the "simple" version that doesn't refer to other Nixpkgs / channels as a attribute. The point of this is not to catch CIs, but to just sanity check with hydra after the fact that everything worked out the way it should. The impure tricky business with channels is still necessary, but the idea is that it is an optimization and the simple self-contained version is the reference implementation that ultimately defines the behavior we want.
Implemented in , turns out this would've been really useful :sweat_smile:

else [ ]; <ins> # A list optionally containing the `aliases.nix` file from the test case as an overlay # But only if config.allowAliases is not false optionalAliasesOverlay = if (config.allowAliases or true) && builtins.pathExists (root + "/aliases.nix") then [ (import (root + "/aliases.nix")) ] else [ ]; </ins> # All the overlays in the right order, including the user-supplied ones allOverlays = [ autoCalledPackages ] ++ optionalAllPackagesOverlay <ins> ++ optionalAliasesOverlay </ins> ++ overlays; # Apply all the overlays in order to the base fixed-point function pkgsFun


Question:
Steps to reproduce the behavior: / / All plugins show the same error with a different hash when building, I only included the log from : The es were updated with but the plugins fail with a hash mismatch on two machines I tried it on. Both are x86_64 machines running NixOS unstable. I can make a PR to update the hashes, but I want to make sure I'm not missing something. Please run and paste the result.
I've just opened a PR to fix this, if you have time to review, it would be great, otherwise no worries. I won't wait too long before merging since everything is broken.
Looks good to me, those are the same hashes I got.

inherit pname; version = "0.85.0"; src = nushell.src; <del> cargoHash = "sha256-OKtktjBOujvljAX260TbC2sQWZOiGgU+sXsbYRhGPRM="; </del> <ins> cargoHash = "sha256-WS8VRpJnn/VWS7GUkGowFf51ifUx0SbEZzcoTfx2dp0="; </ins> nativeBuildInputs = [ pkg-config ]; <del> buildInputs = [ IOKit Foundation ]; </del> <ins> buildInputs = lib.optionals stdenv.isDarwin [ IOKit Foundation ]; </ins> cargoBuildFlags = [ "--package nu_plugin_formats" ]; doCheck = false; meta = with lib; {


Question:
Steps to reproduce the behavior: / / All plugins show the same error with a different hash when building, I only included the log from : The es were updated with but the plugins fail with a hash mismatch on two machines I tried it on. Both are x86_64 machines running NixOS unstable. I can make a PR to update the hashes, but I want to make sure I'm not missing something. Please run and paste the result.
I've just opened a PR to fix this, if you have time to review, it would be great, otherwise no worries. I won't wait too long before merging since everything is broken.
Looks good to me, those are the same hashes I got.

inherit pname; version = "0.85.0"; src = nushell.src; <del> cargoHash = "sha256-Fj70uKYzEKxeZeNrqlwM7ZFJ+K1tz10RqLndrdY40CE="; </del> <ins> cargoHash = "sha256-6luY3SIRRd9vaY9KIJcj8Q974FW0LtAvRjVpdpzkdLo="; </ins> nativeBuildInputs = [ pkg-config ]; buildInputs = [ openssl ] ++ lib.optionals stdenv.isDarwin [ Security ]; cargoBuildFlags = [ "--package nu_plugin_gstat" ];


Question:
Steps to reproduce the behavior: / / All plugins show the same error with a different hash when building, I only included the log from : The es were updated with but the plugins fail with a hash mismatch on two machines I tried it on. Both are x86_64 machines running NixOS unstable. I can make a PR to update the hashes, but I want to make sure I'm not missing something. Please run and paste the result.
I've just opened a PR to fix this, if you have time to review, it would be great, otherwise no worries. I won't wait too long before merging since everything is broken.
Looks good to me, those are the same hashes I got.

src = nushell.src; <del> cargoHash = "sha256-8iUqOdGWm2kDW72ptlCBIqqe4zjckN09MOQD77kCf5Y="; </del> <ins> cargoHash = "sha256-xyty3GfI+zNkuHs7LYHBctqXUHZ4/MNNcnnfYvI18do="; </ins> buildInputs = lib.optionals stdenv.isDarwin [ IOKit CoreFoundation ];


Question: Package name: sudo-rs Latest released version: 0.2.1 <!-- Search your package here: --- Current version on the unstable channel: 0.2.0 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.

{ lib , bash , fetchFromGitHub <del> , fetchpatch </del> , installShellFiles , nix-update-script , nixosTests


Question: Package name: sudo-rs Latest released version: 0.2.1 <!-- Search your package here: --- Current version on the unstable channel: 0.2.0 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.

rustPlatform.buildRustPackage rec { pname = "sudo-rs"; <del> version = "0.2.0"; </del> <ins> version = "0.2.1"; </ins> src = fetchFromGitHub { owner = "memorysafety"; repo = "sudo-rs"; rev = "v${version}"; <del> hash = "sha256-Kk5D3387hdl6eGWTSV003r+XajuDh6YgHuqYlj9NnaQ="; </del> <ins> hash = "sha256-EQEdNDUXEMMiFZKuu9LR9ywjvKWyM5bWcRHHUB9+gp4="; </ins> }; <del> cargoHash = "sha256-yeMK37tOgJcs9pW3IclpR5WMXx0gMDJ2wcmInxJYbQ8="; </del> <ins> cargoHash = "sha256-Zs9/A7u4yMLKY4cAUCnsqRHgkxI8R3w1JwkAd2lw0eo="; </ins> nativeBuildInputs = [ installShellFiles pandoc ]; buildInputs = [ pam ]; <del> patches = [ (fetchpatch { # @R-VdP's patch to work with NixOS' suid wrappers name = "Skip self_check when executed as root.patch"; url = "https://github.com/R-VdP/sudo-rs/commit/a44541dcb36b94f938daaed66b3ff06cfc1c2b40.patch"; hash = "sha256-PdmOqp/NDjFy8ve4jEOi58e0N9xUnaVKioQwdC5Jf1U="; }) ]; </del> # Don't attempt to generate the docs in a (pan)Docker container postPatch = '' substituteInPlace util/generate-docs.sh


Question: When creating nixos-containers with umask 077, files get created with the wrong permissions, and services such as dbus don't work because they probably can't read certain files: Like for nixos activation, the creation of nixos containers should force umask 022.

import ./generic.nix ( rec { <del> version = "3.4.2"; </del> <ins> version = "3.4.4"; </ins> testing = false; preConfigure = ''


Question: When creating nixos-containers with umask 077, files get created with the wrong permissions, and services such as dbus don't work because they probably can't read certain files: Like for nixos activation, the creation of nixos containers should force umask 022.

src = fetchurl { url = "mirror://kernel/linux/kernel/v3.x/${if testing then "testing/" else ""}linux-${version}.tar.xz"; <del> sha256 = "0pd96g1qcp2wgdnvk79hljjrpr6xjk0159lks47n181a3yirzf4x"; </del> <ins> sha256 = "0l4h7amhsmgpnii8rgwi32nd7ajsifk2xckjd39pfzwdifacw5yw"; </ins> }; config = configWithPlatform stdenv.platform;


Question:
A clear and concise description of what the bug is. launches, but cannot select language in the welcome screen. If I open the "preference" from tray, no text is displayed. Steps to reproduce the behavior: Ctrl+Shift+I to open devtools, found error. A clear and concise description of what you expected to happen. The app should display normally. If applicable, add screenshots to help explain your problem. ! ! Add any other context about the problem here. Running on NixOS unstable. The log from devtool: <!-- 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.
This is still an issue, and i think the current maintainer is
I have tested out the newest version and found out that the above mentioned issue does not happen on this version.

stdenv.mkDerivation (finalAttrs: { pname = "stretchly"; <del> version = "1.15.1"; </del> <ins> version = "1.16.0"; </ins> src = fetchurl { url = "https://github.com/hovancik/stretchly/releases/download/v${finalAttrs.version}/stretchly-${finalAttrs.version}.tar.xz"; <del> hash = "sha256-suTH6o7vtUr2DidPXAwqrya5/WukQOFmS/34LaiWDBs="; </del> <ins> hash = "sha256-gOMUXGldtZUfqLABJHfbToYe0pcAn8dRWEFxCi/gY9Y="; </ins> }; icon = fetchurl {


Question: Project description A self-hosted BitTorrent indexer, DHT crawler, content classifier and torrent search engine with web UI, GraphQL API and Servarr stack integration. The DHT crawler is bitmagnet’s killer feature that (currently) makes it unique. … DHT’s lesser known feature is that it allows you to crawl the info hashes it knows about. This is how bitmagnet’s DHT crawler works works - it crawls the DHT network, requesting metadata about each info hash it discovers. It then further enriches this metadata by attempting to classify it and associate it with known pieces of content, such as movies and TV shows. It then allows you to search everything it has indexed. This means that bitmagnet is not reliant on any external trackers or torrent indexers. It’s a self-contained, self-hosted torrent indexer, connected via DHT to a global network of peers and constantly discovering new content. Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin

<ins> { lib , buildGoModule , fetchFromGitHub }: buildGoModule rec { pname = "bitmagnet"; version = "0.0.6"; src = fetchFromGitHub { owner = "bitmagnet-io"; repo = "bitmagnet"; rev = "v${version}"; hash = "sha256-+KAIHg8M2CM+GRRv+htmev8MFe/Y1sJ8p+um/c7kI7c="; }; vendorHash = "sha256-ydiZ3KMEiVkmdzhHjYYLJ7wuiKmwlMEn4OWrKSOnaSo="; ldflags = [ "-s" "-w" ]; meta = { description = "A self-hosted BitTorrent indexer, DHT crawler, and torrent search engine"; longDescription = '' A self-hosted BitTorrent indexer, DHT crawler, content classifier and torrent search engine with web UI, GraphQL API and Servarr stack integration. ''; homepage = "https://bitmagnet.io/"; license = lib.licenses.mit; maintainers = with lib.maintainers; [ eclairevoyant ]; mainProgram = "bitmagnet"; }; } </ins>


Question:
I note that the package sets in .[(1)] says [(2)] that the reason to disable "JBIG" is patent concerns, that disabling it removes support for many printers, and that "The patent will expire on April 4, 2012". Given the last, need we still disable this feature? [(1)]: [(2)]:
I don't think so. openSUSE enabled it, too. Other distributions might have done the same, not sure.
A PR that implements this change request would be very welcome. I'd rather not have this issue lying around, though, without someone having committed to actually work on it.

}; preBuild = '' <del> makeFlags="V=1 DISABLE_JBIG=1 CUPSFILTER=$out/lib/cups/filter CUPSPPD=$out/share/cups/model" </del> <ins> makeFlags="V=1 CUPSFILTER=$out/lib/cups/filter CUPSPPD=$out/share/cups/model" </ins> ''; buildInputs = [cups zlib];


Question:
The home-assistant component currently declares that it's missing the input However the package actually exists, it's just called . This appears to be the old name of the package, it looks as though it got renamed at some point, although the nixpkgs packge for it wasn't updated for the name change.
Note that merely setting restores the component's functionality.

<del> { lib , aiohttp , beautifulsoup4 , buildPythonPackage , fetchFromGitHub , pkce , poetry-core , pythonOlder }: buildPythonPackage rec { pname = "pymyq"; version = "3.1.13"; pyproject = true; disabled = pythonOlder "3.8"; src = fetchFromGitHub { owner = "Python-MyQ"; repo = "Python-MyQ"; rev = "refs/tags/v${version}"; hash = "sha256-kW03swRXZdkh45I/up/FIxv0WGBRqTlDt1X71Ow/hrg="; }; nativeBuildInputs = [ poetry-core ]; propagatedBuildInputs = [ aiohttp beautifulsoup4 pkce ]; # Project has no tests doCheck = false; pythonImportsCheck = [ "pymyq" ]; meta = with lib; { description = "Python wrapper for MyQ API"; homepage = "https://github.com/Python-MyQ/Python-MyQ"; changelog = "https://github.com/Python-MyQ/Python-MyQ/releases/tag/v${version}"; license = with licenses; [ mit ]; maintainers = with maintainers; [ fab ]; }; } </del>


Question:
The home-assistant component currently declares that it's missing the input However the package actually exists, it's just called . This appears to be the old name of the package, it looks as though it got renamed at some point, although the nixpkgs packge for it wasn't updated for the name change.
Note that merely setting restores the component's functionality.

<ins> { lib , aiohttp , beautifulsoup4 , buildPythonPackage , fetchFromGitHub , pkce , poetry-core , pythonOlder }: buildPythonPackage rec { pname = "python-myq"; version = "3.1.13"; pyproject = true; disabled = pythonOlder "3.8"; src = fetchFromGitHub { owner = "Python-MyQ"; repo = "Python-MyQ"; rev = "refs/tags/v${version}"; hash = "sha256-kW03swRXZdkh45I/up/FIxv0WGBRqTlDt1X71Ow/hrg="; }; nativeBuildInputs = [ poetry-core ]; propagatedBuildInputs = [ aiohttp beautifulsoup4 pkce ]; # Project has no tests doCheck = false; pythonImportsCheck = [ "pymyq" ]; meta = with lib; { description = "Python wrapper for MyQ API"; homepage = "https://github.com/Python-MyQ/Python-MyQ"; changelog = "https://github.com/Python-MyQ/Python-MyQ/releases/tag/v${version}"; license = with licenses; [ mit ]; maintainers = with maintainers; [ fab ]; }; } </ins>


Question:
The home-assistant component currently declares that it's missing the input However the package actually exists, it's just called . This appears to be the old name of the package, it looks as though it got renamed at some point, although the nixpkgs packge for it wasn't updated for the name change.
Note that merely setting restores the component's functionality.

sqlalchemy ]; "myq" = ps: with ps; [ <del> ]; # missing inputs: python-myq </del> <ins> python-myq ]; </ins> "mysensors" = ps: with ps; [ aiohttp-cors janus


Question:
The home-assistant component currently declares that it's missing the input However the package actually exists, it's just called . This appears to be the old name of the package, it looks as though it got renamed at some point, although the nixpkgs packge for it wasn't updated for the name change.
Note that merely setting restores the component's functionality.

"mullvad" "mutesync" "my" <ins> "myq" </ins> "mysensors" "mystrom" "mythicbeastsdns"


Question:
The home-assistant component currently declares that it's missing the input However the package actually exists, it's just called . This appears to be the old name of the package, it looks as though it got renamed at some point, although the nixpkgs packge for it wasn't updated for the name change.
Note that merely setting restores the component's functionality.

pymc3 = pymc; # added 2022-06-05, module was rename starting with 4.0.0 pymssql = throw "pymssql has been abandoned upstream."; # added 2020-05-04 PyMVGLive = pymvglive; # added 2023-02-19 <ins> pymyq = python-myq; # added 2023-10-20 </ins> pyqt4 = throw "pyqt4 has been removed, because it depended on the long EOL qt4"; # added 2022-06-09 pyramid_beaker = pyramid-beaker; # added 2023-08-23 pyramid_chameleon = pyramid-chameleon; # added 2023-08-23


Question:
The home-assistant component currently declares that it's missing the input However the package actually exists, it's just called . This appears to be the old name of the package, it looks as though it got renamed at some point, although the nixpkgs packge for it wasn't updated for the name change.
Note that merely setting restores the component's functionality.

pymvglive = callPackage ../development/python-modules/pymvglive { }; <del> pymyq = callPackage ../development/python-modules/pymyq { }; </del> <ins> python-myq = callPackage ../development/python-modules/python-myq { }; </ins> pymysensors = callPackage ../development/python-modules/pymysensors { };


Question:
After babashka can't display Unicode characters I have a babashka script that outputs the following JSON: The text is a Nerd Font Symbol code point. After the output is: Steps to reproduce the behavior: This has been fixed in the past by I did not test other packages that could be affected by the PR.
Pretty sure this is related to this bug in GraalVM upstream: I am curious if this is affecting projects using GraalVM 21.0.0 vanilla or if not, how is it working and why it is broken in .
It does seem that even setting up inside the C compiler environment is not sufficient to make it work. CC to see if they have more context on what the possibly issue is.
I also hit this today. I tested the same version(v1.3.186) from upstream binary release, which does not have this issue. Shall we always sync the same version of graavm as upstream build ci?
I don't think this is the issue and even if it was, it is not like babashka is the only GraalVM package we have.
I know that folks can't reproduce this issue with upstream, but I also can't reproduce it with GraalVM using Java, e.g.: A patch if anyone wants to test to be applied to : So, can anyone reproduce this issue with GraalVM Native Image itself? If not, the only thing I can think is that the issue here is the GCC (i.e.: non-static) version (upstream compiles with by default). Or something else.
So I got this warning: But this was after already started to build, so I assume this is the same issue as and need to be fixed upstream.
To explain in more details why I think this is an upstream issue: I don't get the same in the initial part of the build, only when the build starts that I get this warning. So what I assume is doing: Running the CC (C Compiler) inside a shell with clean environment We see the , because this shell couldn't set the proper locale thanks to missing environment variables (e.g.: ) Since this shell environment has no environment variables (at least, not the environment variables that we need), this ends up breaking macOS compilation and locale (Unicode) support in Linux Not sure why it works in GraalVM itself though yet. This is all really strange.
While I'm not familiar with graalvm, I do find a hack for this issue, maybe can weigh in to test whether this hack is valid: Some inspiration from a random reddit post and those issues: And I do find it's using , so I thought if I those two into build args, maybe it'd work. And indeed it seems to work.. After I built bb with above args,
BTW, I cannot reproduce with GraalVM Native Image on helloworld java as well. Helloworld produced by GraalVM Native Image has correct unicode output.
Thanks for investigating this issue. Opened so we can have this fixed.

, glibcLocales # The GraalVM derivation to use , graalvmDrv <del> , name ? "${args.pname}-${args.version}" </del> , executable ? args.pname # JAR used as input for GraalVM derivation, defaults to src , jar ? args.src


Question:
After babashka can't display Unicode characters I have a babashka script that outputs the following JSON: The text is a Nerd Font Symbol code point. After the output is: Steps to reproduce the behavior: This has been fixed in the past by I did not test other packages that could be affected by the PR.
Pretty sure this is related to this bug in GraalVM upstream: I am curious if this is affecting projects using GraalVM 21.0.0 vanilla or if not, how is it working and why it is broken in .
It does seem that even setting up inside the C compiler environment is not sufficient to make it work. CC to see if they have more context on what the possibly issue is.
I also hit this today. I tested the same version(v1.3.186) from upstream binary release, which does not have this issue. Shall we always sync the same version of graavm as upstream build ci?
I don't think this is the issue and even if it was, it is not like babashka is the only GraalVM package we have.
I know that folks can't reproduce this issue with upstream, but I also can't reproduce it with GraalVM using Java, e.g.: A patch if anyone wants to test to be applied to : So, can anyone reproduce this issue with GraalVM Native Image itself? If not, the only thing I can think is that the issue here is the GCC (i.e.: non-static) version (upstream compiles with by default). Or something else.
So I got this warning: But this was after already started to build, so I assume this is the same issue as and need to be fixed upstream.
To explain in more details why I think this is an upstream issue: I don't get the same in the initial part of the build, only when the build starts that I get this warning. So what I assume is doing: Running the CC (C Compiler) inside a shell with clean environment We see the , because this shell couldn't set the proper locale thanks to missing environment variables (e.g.: ) Since this shell environment has no environment variables (at least, not the environment variables that we need), this ends up breaking macOS compilation and locale (Unicode) support in Linux Not sure why it works in GraalVM itself though yet. This is all really strange.
While I'm not familiar with graalvm, I do find a hack for this issue, maybe can weigh in to test whether this hack is valid: Some inspiration from a random reddit post and those issues: And I do find it's using , so I thought if I those two into build args, maybe it'd work. And indeed it seems to work.. After I built bb with above args,
BTW, I cannot reproduce with GraalVM Native Image on helloworld java as well. Helloworld produced by GraalVM Native Image has correct unicode output.
Thanks for investigating this issue. Opened so we can have this fixed.

"-H:Name=${executable}" "-march=compatibility" "--verbose" <ins> "-J-Dsun.stdout.encoding=UTF-8" "-J-Dsun.stderr.encoding=UTF-8" </ins> ] # Extra arguments to be passed to the native-image , extraNativeImageBuildArgs ? [ ] # XMX size of GraalVM during build , graalvmXmx ? "-J-Xmx6g" <del> # Locale to be used by GraalVM compiler , LC_ALL ? "en_US.UTF-8" </del> , meta ? { } , ... } @ args:


Question:
After babashka can't display Unicode characters I have a babashka script that outputs the following JSON: The text is a Nerd Font Symbol code point. After the output is: Steps to reproduce the behavior: This has been fixed in the past by I did not test other packages that could be affected by the PR.
Pretty sure this is related to this bug in GraalVM upstream: I am curious if this is affecting projects using GraalVM 21.0.0 vanilla or if not, how is it working and why it is broken in .
It does seem that even setting up inside the C compiler environment is not sufficient to make it work. CC to see if they have more context on what the possibly issue is.
I also hit this today. I tested the same version(v1.3.186) from upstream binary release, which does not have this issue. Shall we always sync the same version of graavm as upstream build ci?
I don't think this is the issue and even if it was, it is not like babashka is the only GraalVM package we have.
I know that folks can't reproduce this issue with upstream, but I also can't reproduce it with GraalVM using Java, e.g.: A patch if anyone wants to test to be applied to : So, can anyone reproduce this issue with GraalVM Native Image itself? If not, the only thing I can think is that the issue here is the GCC (i.e.: non-static) version (upstream compiles with by default). Or something else.
So I got this warning: But this was after already started to build, so I assume this is the same issue as and need to be fixed upstream.
To explain in more details why I think this is an upstream issue: I don't get the same in the initial part of the build, only when the build starts that I get this warning. So what I assume is doing: Running the CC (C Compiler) inside a shell with clean environment We see the , because this shell couldn't set the proper locale thanks to missing environment variables (e.g.: ) Since this shell environment has no environment variables (at least, not the environment variables that we need), this ends up breaking macOS compilation and locale (Unicode) support in Linux Not sure why it works in GraalVM itself though yet. This is all really strange.
While I'm not familiar with graalvm, I do find a hack for this issue, maybe can weigh in to test whether this hack is valid: Some inspiration from a random reddit post and those issues: And I do find it's using , so I thought if I those two into build args, maybe it'd work. And indeed it seems to work.. After I built bb with above args,
BTW, I cannot reproduce with GraalVM Native Image on helloworld java as well. Helloworld produced by GraalVM Native Image has correct unicode output.
Thanks for investigating this issue. Opened so we can have this fixed.

]; in stdenv.mkDerivation ({ <del> inherit dontUnpack LC_ALL jar; </del> <ins> inherit dontUnpack jar; </ins> nativeBuildInputs = (args.nativeBuildInputs or [ ]) ++ [ graalvmDrv glibcLocales ];


Question:
After babashka can't display Unicode characters I have a babashka script that outputs the following JSON: The text is a Nerd Font Symbol code point. After the output is: Steps to reproduce the behavior: This has been fixed in the past by I did not test other packages that could be affected by the PR.
Pretty sure this is related to this bug in GraalVM upstream: I am curious if this is affecting projects using GraalVM 21.0.0 vanilla or if not, how is it working and why it is broken in .
It does seem that even setting up inside the C compiler environment is not sufficient to make it work. CC to see if they have more context on what the possibly issue is.
I also hit this today. I tested the same version(v1.3.186) from upstream binary release, which does not have this issue. Shall we always sync the same version of graavm as upstream build ci?
I don't think this is the issue and even if it was, it is not like babashka is the only GraalVM package we have.
I know that folks can't reproduce this issue with upstream, but I also can't reproduce it with GraalVM using Java, e.g.: A patch if anyone wants to test to be applied to : So, can anyone reproduce this issue with GraalVM Native Image itself? If not, the only thing I can think is that the issue here is the GCC (i.e.: non-static) version (upstream compiles with by default). Or something else.
So I got this warning: But this was after already started to build, so I assume this is the same issue as and need to be fixed upstream.
To explain in more details why I think this is an upstream issue: I don't get the same in the initial part of the build, only when the build starts that I get this warning. So what I assume is doing: Running the CC (C Compiler) inside a shell with clean environment We see the , because this shell couldn't set the proper locale thanks to missing environment variables (e.g.: ) Since this shell environment has no environment variables (at least, not the environment variables that we need), this ends up breaking macOS compilation and locale (Unicode) support in Linux Not sure why it works in GraalVM itself though yet. This is all really strange.
While I'm not familiar with graalvm, I do find a hack for this issue, maybe can weigh in to test whether this hack is valid: Some inspiration from a random reddit post and those issues: And I do find it's using , so I thought if I those two into build args, maybe it'd work. And indeed it seems to work.. After I built bb with above args,
BTW, I cannot reproduce with GraalVM Native Image on helloworld java as well. Helloworld produced by GraalVM Native Image has correct unicode output.
Thanks for investigating this issue. Opened so we can have this fixed.

doInstallCheck = true; installCheckPhase = '' <del> $out/bin/bb --version | grep '${version}' $out/bin/bb '(+ 1 2)' | grep '3' $out/bin/bb '(vec (dedupe *input*))' <<< '[1 1 1 1 2]' | grep '[1 2]' </del> <ins> $out/bin/bb --version | fgrep '${version}' $out/bin/bb '(+ 1 2)' | fgrep '3' $out/bin/bb '(vec (dedupe *input*))' <<< '[1 1 1 1 2]' | fgrep '[1 2]' $out/bin/bb '(prn "bépo àê")' | fgrep 'bépo àê' </ins> ''; # As of v1.2.174, this will remove references to ${graalvmDrv}/conf/chronology,


Question: Project description Python REPL plugin for automatic time tracking and metrics generated from your programming activity. Metadata homepage URL: source URL: license: gpl3 platforms: unix, linux, darwin, ...

<ins> { lib , buildPythonPackage , pythonOlder , fetchPypi , ptpython , ipython , setuptools , setuptools-scm , setuptools-generate }: let pname = "repl-python-wakatime"; version = "0.0.6"; in buildPythonPackage { inherit pname version; format = "pyproject"; disabled = pythonOlder "3.6"; src = fetchPypi { inherit pname version; hash = "sha256-s2UelniMn4+wWILbVIIKidRCFaOvo/nNNofA7yf2+9c="; }; nativeBuildInputs = [ setuptools setuptools-scm setuptools-generate ]; propagatedBuildInputs = [ ptpython ipython ]; pythonImportsCheck = [ "repl_python_wakatime" ]; meta = with lib; { description = "Python REPL plugin for automatic time tracking and metrics generated from your programming activity"; homepage = "https://github.com/wakatime/repl-python-wakatime"; license = licenses.gpl3Only; maintainers = with maintainers; [ jfvillablanca ]; }; } </ins>


Question: Project description Python REPL plugin for automatic time tracking and metrics generated from your programming activity. Metadata homepage URL: source URL: license: gpl3 platforms: unix, linux, darwin, ...

repeated-test = callPackage ../development/python-modules/repeated-test { }; <ins> repl-python-wakatime = callPackage ../development/python-modules/repl-python-wakatime { }; </ins> repocheck = callPackage ../development/python-modules/repocheck { }; reportengine = callPackage ../development/python-modules/reportengine { };


Question: Package name: python311Packgaes.openrazer Latest released version: 3.6.1 <!-- Search your package here: --- Current version on the unstable channel: 3.5.1 Current version on the stable/release channel: 3.5.1 Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. -- Last update pull request was made by: Note for maintainers: Please tag this issue in your PR.

{ lib , fetchFromGitHub }: rec { <del> version = "3.5.1"; </del> <ins> version = "3.6.1"; </ins> format = "setuptools"; src = fetchFromGitHub { owner = "openrazer"; repo = "openrazer"; rev = "v${version}"; <del> hash = "sha256-6YU2tl17LpDZe9pQ1a+B2SGIhqGdwME3Db6umVz7RLc="; </del> <ins> hash = "sha256-bboTRZqJq5tKeBQuiEQAXxTHYvoldDQlwbfehjDA8EE="; </ins> }; meta = with lib; {


Question: Looking at my filed ofborg does not ping in most cases. I am thinking of ofborg pings people, or the above command does not print (I guess) No response. No response.

, sha256 , odd-unstable ? true , patchlevel-unstable ? true <ins> , passthru ? { } , meta ? { } </ins> , ... } @ args:


Question: Looking at my filed ofborg does not ping in most cases. I am thinking of ofborg pings people, or the above command does not print (I guess) No response. No response.

concatAttrLists = attrsets: zipAttrsWithNames (filterAttrNames isList (head attrsets)) (_: concatLists) attrsets; <del> template = rec { inherit pname version; </del> <ins> template = { </ins> nativeBuildInputs = [ pkg-config xfce4-dev-tools wrapGAppsHook ]; buildInputs = [ hicolor-icon-theme ]; configureFlags = [ "--enable-maintainer-mode" ];


Question: Looking at my filed ofborg does not ping in most cases. I am thinking of ofborg pings people, or the above command does not print (I guess) No response. No response.

pos = builtins.unsafeGetAttrPos "pname" args; <del> passthru.updateScript = gitUpdater { inherit rev-prefix odd-unstable patchlevel-unstable; }; </del> <ins> passthru = { updateScript = gitUpdater { inherit rev-prefix odd-unstable patchlevel-unstable; }; } // passthru; </ins> meta = with lib; { homepage = "https://gitlab.xfce.org/${category}/${pname}"; license = licenses.gpl2Plus; # some libraries are under LGPLv2+ platforms = platforms.linux; <del> }; </del> <ins> } // meta; </ins> }; <del> publicArgs = removeAttrs args [ "category" "pname" "sha256" ]; </del> <ins> publicArgs = removeAttrs args [ "category" "sha256" ]; </ins> in <del> stdenv.mkDerivation (recursiveUpdate template publicArgs // concatAttrLists [ template args ]) </del> <ins> stdenv.mkDerivation (publicArgs // template // concatAttrLists [ template args ]) </ins> # TODO [ AndersonTorres ]: verify if it allows using hash attribute as an option to sha256


Question: Package name: rubberband Latest released version: 3.3.0 Current version on the unstable channel: 3.1.0 Current version on the stable/release channel: 3.1.0 Notify maintainers Note for maintainers: Please tag this issue in your PR.

{ lib, stdenv, fetchurl, pkg-config, libsamplerate, libsndfile, fftw <ins> , lv2, jdk </ins> , vamp-plugin-sdk, ladspaH, meson, ninja, darwin }: stdenv.mkDerivation rec { pname = "rubberband"; <del> version = "3.1.0"; </del> <ins> version = "3.3.0"; </ins> src = fetchurl { url = "https://breakfastquay.com/files/releases/${pname}-${version}.tar.bz2"; <del> sha256 = "sha256-uVp22lzbOWZ3DGARXs2Dj4QGESD4hMO/3JBPdZMeyao="; </del> <ins> hash = "sha256-2e+J4rjvn4WxOsPC+uww4grPLJ86nIxFzmN/K8leV2w="; </ins> }; <del> nativeBuildInputs = [ pkg-config meson ninja ]; buildInputs = [ libsamplerate libsndfile fftw vamp-plugin-sdk ladspaH ] ++ lib.optionals stdenv.isDarwin </del> <ins> nativeBuildInputs = [ pkg-config meson ninja jdk ]; buildInputs = [ libsamplerate libsndfile fftw vamp-plugin-sdk ladspaH lv2 ] ++ lib.optionals stdenv.isDarwin </ins> (with darwin.apple_sdk.frameworks; [Accelerate CoreGraphics CoreVideo]); makeFlags = [ "AR:=$(AR)" ]; <ins> # TODO: package boost-test, so we can run the test suite. (Currently it fails # to find libboost_unit_test_framework.a.) mesonFlags = [ "-Dtests=disabled" ]; doCheck = false; </ins> meta = with lib; { description = "High quality software library for audio time-stretching and pitch-shifting"; homepage = "https://breakfastquay.com/rubberband/";


Question: Project description A powerful testing framework for ZSH projects Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin, ...

<ins> { lib, stdenvNoCC, fetchFromGitHub, zsh, revolver, installShellFiles, testers, nix-update-script, }: stdenvNoCC.mkDerivation (finalAttrs: { pname = "zunit"; version = "0.8.2"; src = fetchFromGitHub { owner = "zunit-zsh"; repo = "zunit"; rev = "v${finalAttrs.version}"; hash = "sha256-GkBewb795piCaniZJZpGEZFhKaNs8p8swV5z34OegPY="; deepClone = true; # Needed in order to get "tests" folder }; strictDeps = true; doCheck = true; doInstallCheck = true; nativeBuildInputs = [ zsh installShellFiles ]; nativeCheckInputs = [ revolver ]; buildInputs = [ zsh revolver ]; postPatch = '' for i in $(find src/ -type f -print); do substituteInPlace $i  --replace-warn " revolver " " ${lib.getExe revolver} " done ''; buildPhase = '' runHook preBuild zsh build.zsh runHook postBuild ''; checkPhase = '' runHook preCheck HOME="$TEMPDIR" zsh zunit runHook postCheck ''; installPhase = '' runHook preInstall install -Dm755 zunit $out/bin/zunit runHook postInstall ''; postInstall = '' installShellCompletion --cmd zunit --zsh zunit.zsh-completion ''; installCheckPhase = '' runHook preInstallCheck PATH=$PATH:$out/bin zunit --help runHook postInstallCheck ''; passthru = { tests.version = testers.testVersion { package = finalAttrs.finalPackage; }; updateScript = nix-update-script { }; }; meta = { description = "Powerful testing framework for ZSH projects"; homepage = "https://zunit.xyz/"; downloadPage = "https://github.com/zunit-zsh/zunit/releases"; license = lib.licenses.mit; mainProgram = "zunit"; inherit (zsh.meta) platforms; maintainers = with lib.maintainers; [ d-brasher ]; }; }) </ins>


Question:
rendered in : ! bumping osl to did not work. Applying did not work <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --- system: host os: multi-user?: sandbox: version: nixpkgs:
I have verified that the problem exists with the current derivation even with version , which was updated away from in . I guess somehow the ZLIB_VERSION is replaced improperly , but I've got no idea what could be causing it, and I'm really confused why it's only become a problem recently, as it doesn't look like osl has been touched in either.
I've tracked it down to , and reverting it seems to fix it. I also believe it's a cmake issue. Consider this file Output: Maybe because the header changed to (? But if I'm reading the correctly, I think it should just set the version to an empty string? Either way, this patch seems to fix it I don't think it's worth raising with zlib because with the next patch version they're going to fix it anyway. It might be worth warning them in advance of 1.4. It's probably worth raising with cmake, because they will want to support all version, and then zlib won't have to care anymore either. I can open a PR for this tomorrow or when I have time, but don't wait for me if anybody wants to do it before.
Nice catch! One minor note: you are looking at 's master branch. It seems to be already fixed there as: We'll need that backport to . UPDATE: or wait for to reach master. With now is in .

in stdenv.mkDerivation rec { pname = "openshadinglanguage"; <del> version = "1.12.13.0"; </del> <ins> version = "1.12.14.0"; </ins> src = fetchFromGitHub { owner = "AcademySoftwareFoundation"; repo = "OpenShadingLanguage"; rev = "v${version}"; <del> hash = "sha256-EVV7YHovWwbRju+uv8IK2wpcpoK1ndZ8yNRHzU8LUuE="; </del> <ins> hash = "sha256-x8t7uC4q29MkTCIS1rK0ICw78u5zZG+/zyhwttLOBr4="; </ins> }; cmakeFlags = [


Question:
rendered in : ! bumping osl to did not work. Applying did not work <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --- system: host os: multi-user?: sandbox: version: nixpkgs:
I have verified that the problem exists with the current derivation even with version , which was updated away from in . I guess somehow the ZLIB_VERSION is replaced improperly , but I've got no idea what could be causing it, and I'm really confused why it's only become a problem recently, as it doesn't look like osl has been touched in either.
I've tracked it down to , and reverting it seems to fix it. I also believe it's a cmake issue. Consider this file Output: Maybe because the header changed to (? But if I'm reading the correctly, I think it should just set the version to an empty string? Either way, this patch seems to fix it I don't think it's worth raising with zlib because with the next patch version they're going to fix it anyway. It might be worth warning them in advance of 1.4. It's probably worth raising with cmake, because they will want to support all version, and then zlib won't have to care anymore either. I can open a PR for this tomorrow or when I have time, but don't wait for me if anybody wants to do it before.
Nice catch! One minor note: you are looking at 's master branch. It seems to be already fixed there as: We'll need that backport to . UPDATE: or wait for to reach master. With now is in .

osl = libsForQt5.callPackage ../development/compilers/osl { boost = boost179; <ins> libclang = llvmPackages_15.libclang; clang = if stdenv.cc.libcxx != null then (overrideLibcxx llvmPackages_15.stdenv).cc else clang_15; llvm = llvm_15; </ins> }; osqp = callPackage ../development/libraries/science/math/osqp { };


Question:
Package name: raysession Latest released version: 0.14.2 Current version on the unstable channel: 0.13.1 Current version on the stable/release channel: 0.13.1 Notify maintainers Note for maintainers: Please tag this issue in your PR.
Update PR:

<del> { lib, fetchurl, buildPythonApplication, libjack2, pydbus, pyliblo, pyqt5, which, bash, qt5 }: </del> <ins> { lib, fetchurl, buildPythonApplication, libjack2, pyliblo, pyqt5, which, bash, qt5 }: </ins> buildPythonApplication rec { pname = "raysession"; <del> version = "0.13.1"; </del> <ins> version = "0.14.2"; </ins> src = fetchurl { url = "https://github.com/Houston4444/RaySession/releases/download/v${version}/RaySession-${version}-source.tar.gz"; <del> sha256 = "sha256-iiFRtX43u9BHe7a4ojza7kav+dMW9e05dPi7Gf9d1GM="; </del> <ins> sha256 = "sha256-qEN3zBK/goRLIZaU06XXm8H5yj4Qjj/NH+bkHkjhLaw="; </ins> }; postPatch = ''


Question:
Package name: raysession Latest released version: 0.14.2 Current version on the unstable channel: 0.13.1 Current version on the stable/release channel: 0.13.1 Notify maintainers Note for maintainers: Please tag this issue in your PR.
Update PR:

qt5.wrapQtAppsHook ]; buildInputs = [ libjack2 bash ]; <del> propagatedBuildInputs = [ pydbus pyliblo pyqt5 ]; </del> <ins> propagatedBuildInputs = [ pyliblo pyqt5 ]; </ins> dontWrapQtApps = true; # The program is a python script.


Question: A NAT port forwarding rule fails to build with nftables when ranges are used. This is also the entirety of nix log /nix/store/sir8pvbk65zk4j6rqcj8sgwi0y78s3kc-nftables- Steps to reproduce the behavior: The nfables-rules derivation should compile. Using a single port rule, or disabling nftables results in a successful build. Please run and paste the result.

<del> { config, lib, pkgs, ... }: </del> <ins> { config, lib, ... }: </ins> with lib;


Question: A NAT port forwarding rule fails to build with nftables when ranges are used. This is also the entirety of nix log /nix/store/sir8pvbk65zk4j6rqcj8sgwi0y78s3kc-nftables- Steps to reproduce the behavior: The nfables-rules derivation should compile. Using a single port rule, or disabling nftables results in a successful build. Please run and paste the result.

mkTable = { ipVer, dest, ipSet, forwardPorts, dmzHost }: let <del> # nftables does not support both port and port range as values in a dnat map. # e.g. "dnat th dport map { 80 : 10.0.0.1 . 80, 443 : 10.0.0.2 . 900-1000 }" # So we split them. fwdPorts = filter (x: length (splitString "-" x.destination) == 1) forwardPorts; fwdPortsRange = filter (x: length (splitString "-" x.destination) > 1) forwardPorts; </del> # nftables maps for port forward # l4proto . dport : addr . port <del> toFwdMap = forwardPorts: toNftSet (map </del> <ins> fwdMap = toNftSet (map </ins> (fwd: with (splitIPPorts fwd.destination); "${fwd.proto} . ${toNftRange fwd.sourcePort} : ${IP} . ${ports}" ) forwardPorts); <del> fwdMap = toFwdMap fwdPorts; fwdRangeMap = toFwdMap fwdPortsRange; </del> # nftables maps for port forward loopback dnat # daddr . l4proto . dport : addr . port <del> toFwdLoopDnatMap = forwardPorts: toNftSet (concatMap </del> <ins> fwdLoopDnatMap = toNftSet (concatMap </ins> (fwd: map (loopbackip: with (splitIPPorts fwd.destination);


Question: A NAT port forwarding rule fails to build with nftables when ranges are used. This is also the entirety of nix log /nix/store/sir8pvbk65zk4j6rqcj8sgwi0y78s3kc-nftables- Steps to reproduce the behavior: The nfables-rules derivation should compile. Using a single port rule, or disabling nftables results in a successful build. Please run and paste the result.

) fwd.loopbackIPs) forwardPorts); <del> fwdLoopDnatMap = toFwdLoopDnatMap fwdPorts; fwdLoopDnatRangeMap = toFwdLoopDnatMap fwdPortsRange; </del> # nftables set for port forward loopback snat # daddr . l4proto . dport


Question: A NAT port forwarding rule fails to build with nftables when ranges are used. This is also the entirety of nix log /nix/store/sir8pvbk65zk4j6rqcj8sgwi0y78s3kc-nftables- Steps to reproduce the behavior: The nfables-rules derivation should compile. Using a single port rule, or disabling nftables results in a successful build. Please run and paste the result.

type nat hook prerouting priority dstnat; ${optionalString (fwdMap != "") '' <del> iifname "${cfg.externalInterface}" dnat meta l4proto . th dport map { ${fwdMap} } comment "port forward" ''} ${optionalString (fwdRangeMap != "") '' iifname "${cfg.externalInterface}" dnat meta l4proto . th dport map { ${fwdRangeMap} } comment "port forward" </del> <ins> iifname "${cfg.externalInterface}" meta l4proto { tcp, udp } dnat meta l4proto . th dport map { ${fwdMap} } comment "port forward" </ins> ''} ${optionalString (fwdLoopDnatMap != "") '' <del> dnat ${ipVer} daddr . meta l4proto . th dport map { ${fwdLoopDnatMap} } comment "port forward loopback from other hosts behind NAT" ''} ${optionalString (fwdLoopDnatRangeMap != "") '' dnat ${ipVer} daddr . meta l4proto . th dport map { ${fwdLoopDnatRangeMap} } comment "port forward loopback from other hosts behind NAT" </del> <ins> meta l4proto { tcp, udp } dnat ${ipVer} daddr . meta l4proto . th dport map { ${fwdLoopDnatMap} } comment "port forward loopback from other hosts behind NAT" </ins> ''} ${optionalString (dmzHost != null) ''


Question: A NAT port forwarding rule fails to build with nftables when ranges are used. This is also the entirety of nix log /nix/store/sir8pvbk65zk4j6rqcj8sgwi0y78s3kc-nftables- Steps to reproduce the behavior: The nfables-rules derivation should compile. Using a single port rule, or disabling nftables results in a successful build. Please run and paste the result.

type nat hook output priority mangle; ${optionalString (fwdLoopDnatMap != "") '' <del> dnat ${ipVer} daddr . meta l4proto . th dport map { ${fwdLoopDnatMap} } comment "port forward loopback from the host itself" ''} ${optionalString (fwdLoopDnatRangeMap != "") '' dnat ${ipVer} daddr . meta l4proto . th dport map { ${fwdLoopDnatRangeMap} } comment "port forward loopback from the host itself" </del> <ins> meta l4proto { tcp, udp } dnat ${ipVer} daddr . meta l4proto . th dport map { ${fwdLoopDnatMap} } comment "port forward loopback from the host itself" </ins> ''} } '';


Question:
H.264 videos and specifically those (WebM and Theora are fine) don't play, which means that videos on Facebook and Twitter (at least) report an error. There are instructions for getting a patched version of the ffmpeg lib installed into your home folder which works, but ideally wouldn't be needed: to that the H.264 video don't work but the others do. System: (NixOS: , Ubuntu/Fedora: , ...) Nix version: (run ) Nixpkgs version: (run ) Sandboxing enabled: (run )
What browser are you using? Works on Chromium, Firefox and qutebrowser (qtwebkit) on master for me.
Vivaldi, hence the title of the issue...
Oh, sorry, didn't know there's a browser called vivaldi.

lihop = "Leroy Hopson <nixos@leroy.geek.nz>"; linquize = "Linquize <linquize@yahoo.com.hk>"; linus = "Linus Arver <linusarver@gmail.com>"; <ins> lluchs = "Lukas Werling <lukas.werling@gmail.com>"; </ins> lnl7 = "Daiderd Jordan <daiderd@gmail.com>"; loskutov = "Ignat Loskutov <ignat.loskutov@gmail.com>"; lovek323 = "Jason O'Conal <jason@oconal.id.au>";


Question:
H.264 videos and specifically those (WebM and Theora are fine) don't play, which means that videos on Facebook and Twitter (at least) report an error. There are instructions for getting a patched version of the ffmpeg lib installed into your home folder which works, but ideally wouldn't be needed: to that the H.264 video don't work but the others do. System: (NixOS: , Ubuntu/Fedora: , ...) Nix version: (run ) Nixpkgs version: (run ) Sandboxing enabled: (run )
What browser are you using? Works on Chromium, Firefox and qutebrowser (qtwebkit) on master for me.
Vivaldi, hence the title of the issue...
Oh, sorry, didn't know there's a browser called vivaldi.

, gstreamer, gst-plugins-base, libxml2 , glib, gtk3, pango, gdk_pixbuf, cairo, atk, gnome3 , nss, nspr <del> , patchelf </del> <ins> , patchelf, makeWrapper , proprietaryCodecs ? true, vivaldi-ffmpeg-codecs ? null </ins> }: stdenv.mkDerivation rec { name = "${product}-${version}"; product = "vivaldi"; <del> version = "1.10.867.38-1"; </del> <ins> version = "1.10.867.48-1"; </ins> src = fetchurl { url = "https://downloads.vivaldi.com/stable/${product}-stable_${version}_amd64.deb"; <del> sha256 = "1h3iygzvw3rb5kmn0pam6gqy9baq6l630yllff1vnvychdg8d9vi"; </del> <ins> sha256 = "1han45swvv0y2i2kg7xhml1wj5zyrf2c2hc5b07kqsjkfg9iz1lc"; </ins> }; unpackPhase = ''


Question:
H.264 videos and specifically those (WebM and Theora are fine) don't play, which means that videos on Facebook and Twitter (at least) report an error. There are instructions for getting a patched version of the ffmpeg lib installed into your home folder which works, but ideally wouldn't be needed: to that the H.264 video don't work but the others do. System: (NixOS: , Ubuntu/Fedora: , ...) Nix version: (run ) Nixpkgs version: (run ) Sandboxing enabled: (run )
What browser are you using? Works on Chromium, Firefox and qutebrowser (qtwebkit) on master for me.
Vivaldi, hence the title of the issue...
Oh, sorry, didn't know there's a browser called vivaldi.

tar -xvf data.tar.xz ''; <del> nativeBuildInputs = [ patchelf ]; </del> <ins> nativeBuildInputs = [ patchelf makeWrapper ]; </ins> buildInputs = [ stdenv.cc.cc stdenv.cc.libc zlib libX11 libXt libXext libSM libICE libxcb


Question:
H.264 videos and specifically those (WebM and Theora are fine) don't play, which means that videos on Facebook and Twitter (at least) report an error. There are instructions for getting a patched version of the ffmpeg lib installed into your home folder which works, but ideally wouldn't be needed: to that the H.264 video don't work but the others do. System: (NixOS: , Ubuntu/Fedora: , ...) Nix version: (run ) Nixpkgs version: (run ) Sandboxing enabled: (run )
What browser are you using? Works on Chromium, Firefox and qutebrowser (qtwebkit) on master for me.
Vivaldi, hence the title of the issue...
Oh, sorry, didn't know there's a browser called vivaldi.

atk alsaLib dbus_libs cups gtk3 gdk_pixbuf libexif ffmpeg systemd freetype fontconfig libXrender libuuid expat glib nss nspr gstreamer libxml2 gst-plugins-base pango cairo gnome3.gconf <del> ]; </del> <ins> ] ++ stdenv.lib.optional proprietaryCodecs vivaldi-ffmpeg-codecs; </ins> libPath = stdenv.lib.makeLibraryPath buildInputs + stdenv.lib.optionalString (stdenv.is64bit)


Question:
H.264 videos and specifically those (WebM and Theora are fine) don't play, which means that videos on Facebook and Twitter (at least) report an error. There are instructions for getting a patched version of the ffmpeg lib installed into your home folder which works, but ideally wouldn't be needed: to that the H.264 video don't work but the others do. System: (NixOS: , Ubuntu/Fedora: , ...) Nix version: (run ) Nixpkgs version: (run ) Sandboxing enabled: (run )
What browser are you using? Works on Chromium, Firefox and qutebrowser (qtwebkit) on master for me.
Vivaldi, hence the title of the issue...
Oh, sorry, didn't know there's a browser called vivaldi.

--set-interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)"  --set-rpath "${libPath}"  opt/vivaldi/vivaldi-bin <ins> '' + stdenv.lib.optionalString proprietaryCodecs '' sed -i '/^VIVALDI_FFMPEG_FOUND/ a  checkffmpeg "${vivaldi-ffmpeg-codecs}/lib/libffmpeg.so"' opt/vivaldi/vivaldi '' + '' </ins> echo "Finished patching Vivaldi binaries" '';


Question:
H.264 videos and specifically those (WebM and Theora are fine) don't play, which means that videos on Facebook and Twitter (at least) report an error. There are instructions for getting a patched version of the ffmpeg lib installed into your home folder which works, but ideally wouldn't be needed: to that the H.264 video don't work but the others do. System: (NixOS: , Ubuntu/Fedora: , ...) Nix version: (run ) Nixpkgs version: (run ) Sandboxing enabled: (run )
What browser are you using? Works on Chromium, Firefox and qutebrowser (qtwebkit) on master for me.
Vivaldi, hence the title of the issue...
Oh, sorry, didn't know there's a browser called vivaldi.

"$out"/opt/vivaldi/product_logo_''${d}.png  "$out"/share/icons/hicolor/''${d}x''${d}/apps/vivaldi.png done <ins> wrapProgram "$out/bin/vivaldi"  --suffix XDG_DATA_DIRS : ${gtk3}/share/gsettings-schemas/${gtk3.name}/ </ins> ''; meta = with stdenv.lib; {


Question:
H.264 videos and specifically those (WebM and Theora are fine) don't play, which means that videos on Facebook and Twitter (at least) report an error. There are instructions for getting a patched version of the ffmpeg lib installed into your home folder which works, but ideally wouldn't be needed: to that the H.264 video don't work but the others do. System: (NixOS: , Ubuntu/Fedora: , ...) Nix version: (run ) Nixpkgs version: (run ) Sandboxing enabled: (run )
What browser are you using? Works on Chromium, Firefox and qutebrowser (qtwebkit) on master for me.
Vivaldi, hence the title of the issue...
Oh, sorry, didn't know there's a browser called vivaldi.

<ins> { stdenv, fetchurl, fetchpatch , dbus_glib, gtk2, gtk3, libexif, libpulseaudio, libXScrnSaver, ninja, nss , pciutils, pkgconfig, python2, xdg_utils }: stdenv.mkDerivation rec { name = "${product}-${version}"; product = "vivaldi-ffmpeg-codecs"; version = "59.0.3071.104"; src = fetchurl { url = "https://commondatastorage.googleapis.com/chromium-browser-official/chromium-${version}.tar.xz"; sha512 = "419cf5bafa80f190cd301c2933502351929c1ef1d5cfedc720ce6762674a0e6af3b4246a8f92e0c29743420338b056061d4e7f9f4a4066a5bdd4d2ee8db3ddbf"; }; buildInputs = [ ]; nativeBuildInputs = [ dbus_glib gtk2 gtk3 libexif libpulseaudio libXScrnSaver ninja nss pciutils pkgconfig python2 xdg_utils ]; configurePhase = '' runHook preConfigure local args="ffmpeg_branding="ChromeOS" proprietary_codecs=true enable_hevc_demuxing=true use_gconf=false use_gio=false use_gnome_keyring=false use_kerberos=false use_cups=false use_sysroot=false use_gold=false linux_use_bundled_binutils=false fatal_linker_warnings=false treat_warnings_as_errors=false is_clang=false is_component_build=true is_debug=false symbol_level=0" python tools/gn/bootstrap/bootstrap.py -v -s --no-clean --gn-gen-args "$args" out/Release/gn gen out/Release -v --args="$args" runHook postConfigure ''; buildPhase = '' ninja -C out/Release -v libffmpeg.so ''; dontStrip = true; installPhase = '' mkdir -p "$out/lib" cp out/Release/libffmpeg.so "$out/lib/libffmpeg.so" ''; meta = with stdenv.lib; { description = "Additional support for proprietary codecs for Vivaldi"; homepage    = "https://ffmpeg.org/"; license     = licenses.lgpl21; maintainers = with maintainers; [ lluchs ]; platforms   = [ "x86_64-linux" ]; }; } </ins>


Question:
H.264 videos and specifically those (WebM and Theora are fine) don't play, which means that videos on Facebook and Twitter (at least) report an error. There are instructions for getting a patched version of the ffmpeg lib installed into your home folder which works, but ideally wouldn't be needed: to that the H.264 video don't work but the others do. System: (NixOS: , Ubuntu/Fedora: , ...) Nix version: (run ) Nixpkgs version: (run ) Sandboxing enabled: (run )
What browser are you using? Works on Chromium, Firefox and qutebrowser (qtwebkit) on master for me.
Vivaldi, hence the title of the issue...
Oh, sorry, didn't know there's a browser called vivaldi.

<ins> #!/usr/bin/env nix-shell #!nix-shell -i bash -p libarchive curl common-updater-scripts set -eu -o pipefail cd "$(dirname "${BASH_SOURCE[0]}")" root=../../../../.. export NIXPKGS_ALLOW_UNFREE=1 version() { (cd "$root" && nix-instantiate --eval --strict -A "$1.version" | tr -d '"') } vivaldi_version_old=$(version vivaldi) vivaldi_version=$(curl -sS https://vivaldi.com/download/ | sed -rne 's/.*vivaldi-stable_([0-9]+.[0-9]+.[0-9]+.[0-9]+-[0-9]+)_amd64.deb.*/1/p') if [[ "$vivaldi_version" = "$vivaldi_version_old" ]]; then echo "nothing to do, vivaldi $vivaldi_version is current" exit fi # Download vivaldi and save hash and file path. url="https://downloads.vivaldi.com/stable/vivaldi-stable_${vivaldi_version}_amd64.deb" mapfile -t prefetch < <(nix-prefetch-url --print-path "$url") hash=${prefetch[0]} path=${prefetch[1]} echo "vivaldi: $vivaldi_version_old -> $vivaldi_version" (cd "$root" && update-source-version vivaldi "$vivaldi_version" "$hash") # Check vivaldi-ffmpeg-codecs version. chromium_version_old=$(version vivaldi-ffmpeg-codecs) chromium_version=$(bsdtar xOf "$path" data.tar.xz | bsdtar xOf - ./opt/vivaldi/vivaldi-bin | strings | grep -A2 -i '^chrome/' | grep '^[0-9]+.[0-9]+.[1-9][0-9]+.[0-9]+') if [[ "$chromium_version" != "$chromium_version_old" ]]; then echo "vivaldi-ffmpeg-codecs: $chromium_version_old -> $chromium_version" (cd "$root" && update-source-version vivaldi-ffmpeg-codecs "$chromium_version") fi </ins>


Question:
H.264 videos and specifically those (WebM and Theora are fine) don't play, which means that videos on Facebook and Twitter (at least) report an error. There are instructions for getting a patched version of the ffmpeg lib installed into your home folder which works, but ideally wouldn't be needed: to that the H.264 video don't work but the others do. System: (NixOS: , Ubuntu/Fedora: , ...) Nix version: (run ) Nixpkgs version: (run ) Sandboxing enabled: (run )
What browser are you using? Works on Chromium, Firefox and qutebrowser (qtwebkit) on master for me.
Vivaldi, hence the title of the issue...
Oh, sorry, didn't know there's a browser called vivaldi.

vivaldi = callPackage ../applications/networking/browsers/vivaldi {}; <ins> vivaldi-ffmpeg-codecs = callPackage ../applications/networking/browsers/vivaldi/ffmpeg-codecs.nix {}; </ins> openmpt123 = callPackage ../applications/audio/openmpt123 {}; opusfile = callPackage ../applications/audio/opusfile { };


Question:
Steps to reproduce the behavior: macOS: Since , this fails on macOS due to case-insensitivity (). The offending PR had no description, no reviews and no reports of tests on any platform. It was merged by the author four days after it was opened. Please run and paste the result.
Fuck MacOS and their stupid case insensitive file system.
Can you try mv'ing the file first to another name like?

cabextract --lowercase viewer1.cab # rename to more standard names <ins> # handle broken macOS file-system </ins> mv andalemo.ttf  Andale_Mono.ttf mv ariblk.ttf    Arial_Black.ttf <del> mv arial.ttf     Arial.ttf </del> <ins> mv arial.ttf     Arial.ttf.tmp mv Arial.ttf.tmp Arial.ttf </ins> mv arialbd.ttf   Arial_Bold.ttf mv arialbi.ttf   Arial_Bold_Italic.ttf mv ariali.ttf    Arial_Italic.ttf


Question:
Steps to reproduce the behavior: macOS: Since , this fails on macOS due to case-insensitivity (). The offending PR had no description, no reviews and no reports of tests on any platform. It was merged by the author four days after it was opened. Please run and paste the result.
Fuck MacOS and their stupid case insensitive file system.
Can you try mv'ing the file first to another name like?

mv courbd.ttf    Courier_New_Bold.ttf mv couri.ttf     Courier_New_Italic.ttf mv courbi.ttf    Courier_New_Bold_Italic.ttf <del> mv georgia.ttf   Georgia.ttf </del> <ins> mv georgia.ttf   Georgia.ttf.tmp mv Georgia.ttf.tmp   Georgia.ttf </ins> mv georgiab.ttf  Georgia_Bold.ttf mv georgiai.ttf  Georgia_Italic.ttf mv georgiaz.ttf  Georgia_Bold_Italic.ttf <del> mv impact.ttf    Impact.ttf mv tahoma.ttf    Tahoma.ttf </del> <ins> mv impact.ttf    Impact.ttf.tmp mv Impact.ttf.tmp    Impact.ttf mv tahoma.ttf    Tahoma.ttf.tmp mv Tahoma.ttf.tmp    Tahoma.ttf </ins> mv times.ttf     Times_New_Roman.ttf mv timesbd.ttf   Times_New_Roman_Bold.ttf mv timesbi.ttf   Times_New_Roman_Bold_Italic.ttf


Question:
Steps to reproduce the behavior: macOS: Since , this fails on macOS due to case-insensitivity (). The offending PR had no description, no reviews and no reports of tests on any platform. It was merged by the author four days after it was opened. Please run and paste the result.
Fuck MacOS and their stupid case insensitive file system.
Can you try mv'ing the file first to another name like?

mv trebucbd.ttf  Trebuchet_MS_Bold.ttf mv trebucit.ttf  Trebuchet_MS_Italic.ttf mv trebucbi.ttf  Trebuchet_MS_Italic.ttf <del> mv verdana.ttf   Verdana.ttf </del> <ins> mv verdana.ttf   Verdana.ttf.tmp mv Verdana.ttf.tmp   Verdana.ttf </ins> mv verdanab.ttf  Verdana_Bold.ttf mv verdanai.ttf  Verdana_Italic.ttf mv verdanaz.ttf  Verdana_Bold_Italic.ttf <del> mv webdings.ttf  Webdings.ttf </del> <ins> mv webdings.ttf  Webdings.ttf.tmp mv Webdings.ttf.tmp  Webdings.ttf </ins> install -m444 -Dt $out/share/fonts/truetype *.ttf