I’d appreciate some input on a new package and service for Ethereum:
These printing related PRs are waiting for some time now. They already received soem reviews, although mostly syntax improvements. I would love some help (and maybe a merge).
1 Like
I’d appreciate some help to get this merged. Currently it’s not possible to download all the sources required to build packages from nixpkgs. This is importance for software heritage and ensuring we can have replicas of all distfiles.
2 Likes
A hot-fix for cjdns, which has been failing for several weeks now, simply because their build system doesn’t seem to like python 3.10
I recently wrote a very short PR to Nix that fixes a bug in the fetchGit built-in, but I don’t know who to request a review from.
In specific situations, this bug can cause the wrong git tag to be used when fetching sources due to a caching issue. It seems like a pretty serious issue, so I’d like to get it fixed ASAP.
I have been trying to get a workaround in for xdg-open issues under FHS envs / wrappers that use LD_LIBRARY_PATH for months now.
The latest iteration of attempting to solve it is this PR: xdg-utils,nixos/xdg/portal: implement workaround for opening programs from FHS envs or wrappers reliably by LunNova · Pull Request #197118 · NixOS/nixpkgs · GitHub
The original issue is: https://github.com/NixOS/nixpkgs/issues/160923
Merged!
2 Likes
I have been trying to move clang-tools into llvmPackages. However, when trying to get clang-unwrapped from the tools fixed point, clang-unwrapped strangely lost some of its dependencies.
error: Function called without required argument "clang-tools-extra_src" at /run/media/root/data-btrfs/shamrock-shared/targets/Projects/NixOS/nixpkgs_optparse/pkgs/development/compilers/llvm/5/clang/default.nix:1
error: Function called without required argument "llvm_meta" at /run/media/root/data-btrfs/shamrock-shared/targets/Projects/NixOS/nixpkgs_optparse/pkgs/development/compilers/llvm/14/clang/default.nix:1
New package that has some amount of interest but has gummed up around review/merge. Sounds like the prospective maintainer got tired of tending merge conflicts while it languished. Might be easy enough to move with attention.
1 Like
I have 2 pull requests that are part of the project I initiated to bring apps of all areas of knowledge of software engineering to Nix[pkgs] which are stuck:
- Parsifal (systematic literature reviews for software engineering): parsifal: init at 2.2.0 by yuuyins · Pull Request #196189 · NixOS/nixpkgs · GitHub
- Modelio (UML and BPMN modeling): modelio: init at 5.1.0 by yuuyins · Pull Request #154188 · NixOS/nixpkgs · GitHub
- This one I do not consider too much important, and I personally have used Eclipse Papyrus instead when I needed as it is more faithful/complete to the UML standard instead.
I have another one, Freeplane, unrelated to the project which I mentioned above, which is a mind-mapping tools instead. The only solution I saw last time I tried building it, was just having openjdk-15 or jdk-15 as dependency for it
- Freeplane: freeplane: 1.9.14 -> 1.10.5; refactor by yuuyins · Pull Request #202372 · NixOS/nixpkgs · GitHub
I personally am not having time/resources to deal with any of it.
- tailscale-systray: init at 2022-10-19 by qbit · Pull Request #219502 · NixOS/nixpkgs · GitHub
- Add 6 vscode extensions by jackyliu16 · Pull Request #227581 · NixOS/nixpkgs · GitHub
- phpExtensions.relay: init at 0.6.3 by ostrolucky · Pull Request #227753 · NixOS/nixpkgs · GitHub
- nixos/code-server: add tests and more command line options by drupol · Pull Request #232360 · NixOS/nixpkgs · GitHub
- noson: init at 5.4.1 by callahad · Pull Request #234210 · NixOS/nixpkgs · GitHub
- Add vscode-extensions.RoweWilsonFrederiskHolme.wikitext by Steinhagen · Pull Request #234505 · NixOS/nixpkgs · GitHub
- iosevka: 23.0.0 -> 24.1.0 by lunik1 · Pull Request #234669 · NixOS/nixpkgs · GitHub
- vscode-extensions.ms-vscode.live-server: init at 0.4.8 by Laurent2916 · Pull Request #235033 · NixOS/nixpkgs · GitHub
- teams-for-linux: 1.0.93 -> 1.1.1 by r-ryantm · Pull Request #235107 · NixOS/nixpkgs · GitHub
- vscode-extensions.tailscale.vscode-tailscale: init at 0.4.0 by drupol · Pull Request #235256 · NixOS/nixpkgs · GitHub
1 Like
In the PR linked below we are trying to get RFC42 style settings into the syncthing NixOS module. We have some disagreements there unfortunately, so we’d appreciate if someone a bit experienced with NixOS modules would share their opinion and help us make a decision.
https://github.com/NixOS/nixpkgs/pull/233386
This PR is also blocking a dependent PR of mine, that fixes a very annoying bug in the module, and that was very hard to debug. I have been merging those 2 PRs to my nixpkgs fork for a few months now.
2 Likes
I have a question on this topic, together with two example cases:
What’s the protocol on PRs for software that requires specific hardware and/or setup? I have two PRs open (one is recent and the other one multiple months old) that functionality-wise are hard to review due to their hardware requirements.
Recent example is [edit: has now been merged] a new package/module that was requested: https://github.com/NixOS/nixpkgs/pull/249860 for GoXLR product line audio mixers. The person who requested the feature is active enough that I can likely get them to test the functionality, but I can imagine cases where even that is not available, what’s the protocol in situations where one wants to add a new package that can’t be tested without specific hardware?
The one that’s been hanging for months is luksroot: fix issue when yubikey is detached during boot process by errnoh · Pull Request #228144 · NixOS/nixpkgs · GitHub where there’s a repeatable corner case functionality for niche setup that involves rotating Yubikey full disk encryption. The problem and solution has been thoroughly explained, fix is simple, but as it involves hardware security it’s not like it should just be rubber stamped without proper review.
Unfortunately, we don’t have such a policy, very similarly to how we lack even more basic policies (people are complaining about that these days in this thread). However, in my experience, if 1 person is able to verify the change is working with the hardware, or even if none, and the changes look good and software at least compiles and is able to not crash for a --help argument, it should be good to go.
For the 1st PR you linked, getting a 
from that person who requested the feature would greatly benefit, after most of the review is done.
1 Like
But, for changes such as in the 2nd PR, testing that this doesn’t break a setup for someone else is crucial. So that would require an approval from someone with that hardware available.
A PR rewriting i2pd nixos service is fixing its fundamental functionality is in:
The quality of writing seems very good to me - impressive for a first time contribution. I have little to no experience with freeformed submodules, and little experience with modules with so many options, so help will be appreciated.
nixos/generations-dir: Improve symlinking in `/boot` by Majiir · Pull Request #198728 · NixOS/nixpkgs · GitHub has been “LGTM” for almost a year. I think it’s stuck because not many reviewers run the relevant configuration to test it. (It can be tested on practically any hardware, but almost nobody runs generations-dir because there are better boot loader integrations for most systems.)
I’ve run this patch on one of my systems for at least as long as the PR has been up, and it’s been smooth sailing.
2 Likes