text:
maintainers/scripts/remove-old-aliases.py: script to remove aliases older than $date

Motivation for this change
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

...but why perl?

...but why perl?

is perl not a good language for this? i've just recently started using perl so i chose to write this in it.
i'll write this in python too as a learning experience

wrote it in python,
here is the perl script for anyone curious
#!/usr/bin/env nix-shell
#!nix-shell -i perl -p perl perlPackages.ListMoreUtils perlPackages.RegexpCommontime
use strict;
use warnings;
use English;
use Cwd qw(abs_path);
use Carp qw(croak);
use Regexp::Common qw(time);
use List::MoreUtils qw(any);
use File::Copy qw(move);
use experimental 'switch';
use 5.034;
our $VERSION = 1; # PerlCritic wanted this

my $aliasfilename;
my $cutoffdate;
my $dryrun;

for (my $n = 0; $n < scalar @ARGV; $n++) {
    my $arg = $ARGV[$n];
    given ($arg) {
        when ( $_ eq "--year") {
            $n++;
            $cutoffdate = $ARGV[$n];
            croak "--year’ requires an argument" unless defined $cutoffdate;
        };
        when ( $_ eq "--file") {
            $n++;
            $aliasfilename = abs_path($ARGV[$n]);
            croak "--file’ requires an argument" unless defined $aliasfilename;
        };
        when ( $_ eq "--dry-run") {
            $dryrun = 1;
        };
        default { croak "usage ex: --year 2020 --file aliases.nix | optional --dry-run"; }
    };
};

croak "no filename" if not defined $aliasfilename;
croak "no year" if not defined $cutoffdate;
my @dateline;
my @onlyrow;
my @separateline;
my @sorted0;
my @sorted1;

sub getdatelines {
    open my $fh, '<:', $aliasfilename
        or croak "Could not open file $aliasfilename $ERRNO";
    while (my $row = <$fh>) {
        chomp $row;
        if ( $row =~ /=.+$RE{time}{ymd}/sm ) {
            my @dates = $row =~ /$RE{time}{ymd}{-keep}/smx;
            my $date = "$dates[0]";
            if ($date lt $cutoffdate) {
                push @dateline, "$date | $INPUT_LINE_NUMBER | $row";
                push @onlyrow, $row;
            };
        };
        # dates that are not on the same line as the assignment
        if ( $row =~ /^(?:(?!=).)*$RE{time}{ymd}/smx ) {
            my @dates = $row =~ /$RE{time}{ymd}{-keep}/smx;
            my $date = "$dates[0]";
            if ($date lt $cutoffdate) {
                push @separateline, "$date | $INPUT_LINE_NUMBER | $row";
            };
        };
    };

    close $fh or croak "Could not close $aliasfilename $ERRNO";

    push @sorted0, sort @dateline;
    push @sorted1, sort @separateline;
    foreach (@sorted0) {
        say;
    };
    if (@sorted1) {
        say "========== on separate line, remove or fix manually ==========";
        foreach (@sorted1) {
            say;
        };
    };
    return;
};
getdatelines();

sub writefile {
    open my $fh, '<:', $aliasfilename
        or croak "Could not open file $aliasfilename $ERRNO";
    open my $writefh, '>:', "$aliasfilename.raliases"
        or croak "Could not open file $aliasfilename.raliases $ERRNO";
    while (my $row = <$fh>) {
        chomp $row;
        my $quoted = quotemeta "$row";
        # filter the dates older than $cutoffdate out
        if (!any { /^$quoted/sm } @onlyrow) {
            say {$writefh} $row;
        } elsif ($row =~ /^\s*$/sm) {
            # ^ if row is just a newline. for some reason the say above does not print those.
            say {$writefh} "$row";
        };
    };

    close $fh or croak "Could not close $aliasfilename $ERRNO";
    close $writefh or croak "Could not close $aliasfilename.raliases $ERRNO";

    move("$aliasfilename.raliases", $aliasfilename) or croak "Move operation failed $ERRNO";
    return;
};

writefile() unless $dryrun;

Cool. python seems like a much better choice to me. I think we allow python for scripts like this 👍

should we convert them to throws first?

...but why perl?

is perl not a good language for this? i've just recently started using perl so i chose to write this in it.

Sorry @Artturin I unfortunately missed this PR eariler, so a bit late to the party. I've added some comments on the initial script below.
@aanderse Imho: Perl and Python are both equally good languages for this kind of task. I don't think we should dissuade contributions in a mature systems language unless there are specific reasons for it.
...
### croak() and friends are mostly useful when writing modules, as errors will be
### in the context of the caller. https://perldoc.perl.org/Carp
###
use Carp qw(croak);
...
### Low-severity perlcritic can be a bit too picky, imho. A $VERSION is
### certainly needed in a vendored module, but imho not really useful in scripts.
###
our $VERSION = 1; # PerlCritic wanted this
...
### Consider using using Getopt::Long (or something more modern like Applify) to
### automatically handle input arguments. The latter also automatically
### usage doc based on expected input arguments.
###
for (my $n = 0; $n < scalar @ARGV; $n++) {
    my $arg = $ARGV[$n];
...
sub getdatelines {
    open my $fh, '<:', $aliasfilename
      or croak "Could not open file $aliasfilename $ERRNO";
    ### chomp() can be used in the while condition directly, but something like
    ###
    ###    use File::Slurp;
    ###    my (@rows) = read_file($aliasfilename);
    ###
    ### .. is perhaps easier to read, and handles exceptions automatically.
    ### Mojo::File is also a nice module to use when dealing with most file
    ### operations.
    ###
    while (my $row = <$fh>) {
        chomp $row;
        if ( $row =~ /=.+$RE{time}{ymd}/sm ) {
          ### You can assign $date directly in the my by setting it up in list
          ### context like this:
          ###
          ###   my ($date) = $row =~ m/=.($RE{time}{ymd}{-keep})/smx;
          ###
            my @dates = $row =~ /$RE{time}{ymd}{-keep}/smx;

unless there are specific reasons for it.

To the best of my knowledge there are approximately 4 people active in our community that are comfortable writing perl.
If I had to make a wild guess I would exaggerate to make a joke and illustrate a point at the same time: I would guess there are maybe 4 people in our community who are not willing to write python.
It isn't that there is something intrinsically wrong with perl, but purely from a demographics point of view our community is not overly willing or able to maintain perl code. Look at many PRs showing people's hesitancy to modify any of ourperl scripts or hack on hydra
I understand you're very capable with perl and I greatly appreciate that about you. I have had to be responsible for many programs written in perl. Thanks to you and the perl contributors in this community I was able to confidently port these applications to NixOS which greatly improved my life. I don't mean to trash talk what you do... I just try to make a relevant point to maximize supportability within our community.
As always thanks for being so great @stigtsp ❤

now the script first converts old aliases to throws and adds a comment "Converted to throw $date"
- bridge_utils = bridge-utils; # Added 2015-02-20
+ bridge_utils = throw "'bridge_utils' has been renamed to/replaced by 'bridge-utils'"; # Converted to throw 2022-02-20

once a throw has a date older than the cutoff date , the throw line will be removed.
i still have to add some checks and clean the script a bit and then its ready

alright, ready.

In general I am in favor of doing this, but I'm really uncomfortable with the idea of stream editing Nix code like this, especially if we later want to run this automatically without human attendance.
Therefore, I'd like to evaluate the possibility of migrating our aliases to a machine-readable format (JSON, YAML, TOML, whatever) so that our script can safely run there.

ready, and added a syntax check with nix-instantiate --eval

In general I am in favor of doing this, but I'm really uncomfortable with the idea of stream editing Nix code like this, especially if we later want to run this automatically without human attendance.
Therefore, I'd like to evaluate the possibility of migrating our aliases to a machine-readable format (JSON, YAML, TOML, whatever) so that our script can safely run

i'd prefer a json file imported with importJSON
{
    "letsencrypt": {
        "points-to": "certbot",
        "added": "2016-05-14",
        "expiry": "2018-01-01",
        "throw": false,
    }
}

however if we had to do throw logic withing evaluation then the nixpkgs eval would become slower right?

https://github.com/NixOS/nixpkgs/pull/161146

It is sad that we restrain ourselves from implementing solutions we deem better because of fear of performance regressions (this is not the first time I see this). Obviously the "correct" way would be to implement both and then measure the performance impact to determine if it is worth it. Of course, this is not a practical approach because it requires more than double the amount of work. :(

authors: Artturin aanderse piegamesde stigtsp


text:
metasploit: 6.1.29 -> 6.1.30

Motivation for this change
Update to latest upstream release 6.1.30
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 160781 run on x86_64-linux 1

1 package built:

metasploit

source: gharchive/pull-request

repo: NixOS/nixpkgs

license: MIT

license_type: permissive

license_source: github-api


text:
python3Packages.intellifire4py: 1.0.1 -> 1.0.2

Description of changes
https://github.com/jeeftor/intellifire4py/blob/master/CHANGELOG

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 164546 run on x86_64-linux 1

3 packages built:

home-assistant-component-tests.intellifire
python310Packages.intellifire4py
python39Packages.intellifire4py


text:
prometheus-apcupsd-exporter: 0.2.0 -> 0.3.0

Signed-off-by: Matt Layher mdlayher@gmail.com
Description of changes
New release of apcupsd_exporter. Adds new metrics regarding UPS temperature and status, and fixes timestamp bugs.

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Builds and runs:
16:04 $ ./result/bin/apcupsd_exporter -h
Usage of ./result/bin/apcupsd_exporter:
  -apcupsd.addr string
        address of apcupsd Network Information Server (NIS) (default ":3551")
  -apcupsd.network string
        network of apcupsd Network Information Server (NIS): typically "tcp", "tcp4", or "tcp6" (default "tcp")
  -telemetry.addr string
        address for apcupsd exporter (default ":9162")
  -telemetry.path string
        URL path for surfacing collected metrics (default "/metrics")

/cc @Ma27 @WilliButz

/marvin opt-in

/marvin status needs_reviewer

@GrahamcOfBorg test prometheus-exporters.apcupsd

/status needs_reviewer

@GrahamcOfBorg test prometheus-exporters.apcupsd


text:
sage: post python-unstable/staging-next merge fixes

Description of changes
Fixes #167672.
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

There's more breakage here, I'm taking a look.

i didn't know it would rebuild that many packages
i'll submit a another pr

@Artturin I really appreciate the idea and I will add Sage to a few dependencies' passthru.tests in the near future. However, for the particular case of networkx, I have to agree with @FRidh's feedback, and because of this I have removed the commit you pushed (Sage is currently broken on master and this PR fixes it, so I want it to be as minimal as possible). Sorry for the trouble and thanks again for the suggestion!

authors: Artturin collares


text:
git: 2.35.3 -> 2.36.0

Description of changes
https://github.blog/2022-04-18-highlights-from-git-2-36/
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

This will certainly have to target staging

This will certainly have to target staging

@lovesegfault rebased onto staging :)

It won't build on aarch64-darwin: https://hydra.nixos.org/build/174700755
Maybe a simple addition of a dependency will suffice; say could someone from @NixOS/darwin-maintainers have a look?

I'd make a patch but I can't right now -- but the fix is to add the CoreServices framework as a dependency. See how we handle adding it in callPackage; if nobody else makes a patch I'll do it when I can.

I had guessed so, but I don't have a means to verify.

@winterqt @vcunat I created #170291 with the fix (add CoreServices framework). I didn’t add it to callPackage because I didn’t want to risk breaking anything since git is used in quite a few places with different git packages.

And tests... I suppose well have to disable one, at least on aarch64-darwin?  (the other three built OK)
https://hydra.nixos.org/build/174778232

For reference, done in 9b6415840

authors: lovesegfault reckenrode techknowlogick vcunat winterqt


text:
natscli: 0.0.30 -> 0.0.32

Description of changes
https://github.com/nats-io/natscli/releases/tag/v0.0.32

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 170386 run on x86_64-linux 1

1 package built:

natscli


text:
python310Packages.pims: 0.5 -> 0.6.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python310Packages.pims is: "Python Image Sequence: Load video and sequential images in many formats with a simple, consistent interface"
meta.homepage for python310Packages.pims is: "https://github.com/soft-matter/pims"
meta.changelog for python310Packages.pims is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
Warning: a test defined in passthru.tests did not pass
found 0.6.0 with grep in /nix/store/mxn6xy9wvryy7g6jdd1kgdafcxq4ykm7-python3.10-PIMS-0.6.0
found 0.6.0 in filename of file in /nix/store/mxn6xy9wvryy7g6jdd1kgdafcxq4ykm7-python3.10-PIMS-0.6.0

Rebuild report (if merged into master) (click to expand)

10 total rebuild path(s)

5 package rebuild(s)

5 x86_64-linux rebuild(s)
5 x86_64-darwin rebuild(s)

First fifty rebuilds by attrpath
python310Packages.dask-image
python310Packages.pims
python39Packages.dask-image
python39Packages.pims
python39Packages.stytra

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/mxn6xy9wvryy7g6jdd1kgdafcxq4ykm7-python3.10-PIMS-0.6.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python310Packages.pims https://github.com/r-ryantm/nixpkgs/archive/e5cd0b86b1ff8ddb45eb4438f310c6c2624ab560.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/mxn6xy9wvryy7g6jdd1kgdafcxq4ykm7-python3.10-PIMS-0.6.0
ls -la /nix/store/mxn6xy9wvryy7g6jdd1kgdafcxq4ykm7-python3.10-PIMS-0.6.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

5 packages built:

python310Packages.dask-image
python310Packages.pims
python39Packages.dask-image
python39Packages.pims
python39Packages.stytra

Maintainer pings
cc @costrouc for testing.

Result of nixpkgs-review pr 171228 run on x86_64-linux 1

5 packages built:

python310Packages.dask-image
python310Packages.pims
python39Packages.dask-image
python39Packages.pims
python39Packages.stytra

authors: fabaff r-ryantm


text:
eclipse-sdk: 4.5.1 -> 4.5.2 -> 4.6

Motivation for this change
Added eclipse-sdk 4.5.2 and 4.6
Things done

[ ] Tested using sandboxing
(nix.useChroot on NixOS,
or option build-use-chroot in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] OS X
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Merged to master. Thanks for your contribution!

authors: Dinnanid rycee


text:
searxng: init at 2022-06-29

Description of changes
Fork of SearX with faster development and additional patches/features. The fork only does not release tags, so I picked the latest commit from master.
Tested working on my personal system via services.searx.package.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 179621 run on x86_64-linux 1

1 package built:

searxng

+1 now i can setup searxng instancez thx @Kranzes !

@Kranzes, do you plan to write the service file for SearXNG?

@Kranzes, do you plan to write the service file for SearXNG?

No, there is no point. You just do services.searx.package = pkgs.searxng

authors: Kranzes MagicRB McSinyx


text:
bird-lg: fix proxy service script

Description of changes
There was an error where the last lines of the service script were missing the  \ and so the script wouldn't start.

Things done

Built on platform(s)

[x] x86_64-linux
[x] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

not sure how to submit bug report but the syntax for bird-lg-go should be something like this, according to xddxdd/bird-lg-go:
./frontend \       --servers="Gigs<gigsgigscloud>,Hostdare<hostdare>" \       --domain=dn42.lantian.pub
arguments shall be followed by the = sign and parameters shall be enclosed in quotation marks " ".
The service script has arguments followed by whitespace and parameters are not in quotation marks.

not sure how to submit bug report but the syntax for bird-lg-go should be something like this, according to xddxdd/bird-lg-go: ./frontend \ --servers="Gigs<gigsgigscloud>,Hostdare<hostdare>" \ --domain=dn42.lantian.pub
arguments shall be followed by the = sign and parameters shall be enclosed in quotation marks " ".
The service script has arguments followed by whitespace and parameters are not in quotation marks.

Will fix that, thx for the report

@yonghan can you please check because it's still working on my side

Oh, I've totally overlooked this when doing #226169. Sorry! But with that one merged, I think this can be closed. But thank you anyways for this PR.

authors: Tchekda e1mo yonghan


text:
libcaca: fix missing darwin inputs

Motivation for this change
http://hydra.nixos.org/build/41806046/log
Things done

[ ] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[x] OS X
[x] No changes on other platforms

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Thanks!


text:
jfrog-cli: 2.34.2 -> 2.34.6

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/jfrog/jfrog-cli/releases.
meta.description for jfrog-cli is: Client for accessing to JFrog's Artifactory and Mission Control through their respective REST APIs
meta.homepage for jfrog-cli is: https://github.com/jfrog/jfrog-cli
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.34.6 with grep in /nix/store/y3dr2icgbzrxrhj8spzyvrl6w7yar8ks-jfrog-cli-2.34.6
found 2.34.6 in filename of file in /nix/store/y3dr2icgbzrxrhj8spzyvrl6w7yar8ks-jfrog-cli-2.34.6

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
jfrog-cli

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/y3dr2icgbzrxrhj8spzyvrl6w7yar8ks-jfrog-cli-2.34.6 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A jfrog-cli https://github.com/r-ryantm/nixpkgs/archive/8c7e78ad9d29610e57c394d06aa4e8dda1914ea0.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/y3dr2icgbzrxrhj8spzyvrl6w7yar8ks-jfrog-cli-2.34.6
ls -la /nix/store/y3dr2icgbzrxrhj8spzyvrl6w7yar8ks-jfrog-cli-2.34.6/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

jfrog-cli

Maintainer pings
cc @Detegr for testing.

Result of nixpkgs-review pr 219795 run on aarch64-darwin 1

1 package built:

jfrog-cli

authors: r-ryantm wegank


text:
nixos/bind: Support defining the zone file using nix expressions

This removes the need to manually write a zone file for bind, and it can instead be defined in nix expressions.
Description of changes

Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

There are some prior art at https://github.com/kirelagin/dns.nix, which may worth checking.

That is a pretty nice library. It would at least make sense to move the creation of the zone file into its own lib, so it can be reused by non-bind daemons.
Or does it make more sense to not put this functionality into nixpkgs itself, and rather have people use that library?

The best path forward would be integrating it into nixpkgs, IMO. Anyway, there are a lot of DNS servers packaged in nixpkgs, having a generic interface not tied to bind benefits them all.

Makes sense. I think the easiest and best path would be to integrate the library as a whole then, as it supports a lot more of the DNS entries. I can see if kirelagin wants to upstream it, or has anything against someone else (me) doing that work.
And then we can ignore this PR

authors: NickCao martiert


text:
lmms: Add support for Carla

Add Carla as an optional dependency and the needed patch.
This adds the Carla rack and Carla instrument LMMS plugins.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Here is the upstream issue: https://github.com/LMMS/lmms/issues/6395
And here is the corresponding patch: https://github.com/LMMS/lmms/pull/6403
Could you apply it with fetchfatch? (https://github.com/LMMS/lmms/commit/3518d307f47c79db06bd0e9430f39b91488673dc.patch)
Fixes the sed are difficult to maintain, it is hard to know when they become obsolete.

@orivej thanks for the suggestion, I'll work on that this friday

Here is the upstream issue: LMMS/lmms#6395 And here is the corresponding patch: LMMS/lmms#6403 Could you apply it with fetchfatch? (https://github.com/LMMS/lmms/commit/3518d307f47c79db06bd0e9430f39b91488673dc.patch) Fixes with sed are difficult to maintain, it is hard to know when they become obsolete.

@orivej It looks like the files plugins/carlabase/carla.h were renamed to camelcase at some point so the patch doesn't apply.
Even if we change the names it still doesn't apply because of this line (and others) which comes from this feature
This patch from Arch Linux  would apply or we could also include it ourselves.
How do you suggest to proceed?

Good idea! However, the link https://raw.githubusercontent.com/archlinux/svntogit-community/packages/lmms/trunk/lmms-carla-export.patch will expire as soon as ArchLinux deletes that patch (probably when they update lmms). To keep the link working we refer to patches on github by their tags or hashes rather than by their branch names (in this case the branch name is packages/lmms). To obtain a stable link you can open https://github.com/archlinux/svntogit-community/blob/packages/lmms/trunk/lmms-carla-export.patch , press y on the keyboard (or click … near "Go to file", choose "Copy permalink", and visit the copied link), and then click "Raw" and copy the link from the browser url bar. In this case the result is https://raw.githubusercontent.com/archlinux/svntogit-community/cf64acc45e3264c6923885867e2dbf8b7586a36b/trunk/lmms-carla-export.patch

authors: Rampoina orivej


text:
fix/ngspice update

Motivation for this change
Ngspice 26 was out in 2014, but NixOS always got 25.
Things done

[X] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[X] NixOS
[ ] macOS
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[ ] Fits CONTRIBUTING.md.

Applied to master (7ea20c9e2752d5164e5a37f44a5dae9955d5d03f) and release-16.09 (1605af1eb59f432025b094bd65c768c0748ff19d).
"Next time", please add yourself to lib/maintainers.nix in a separate commit :-)
Also, changes should go to master first, then backported to release branch. This PR is directly against release-16.09 with changes not found in master.

I can't merge against master because there are thousands of conflicts... Since I based my branch on my current system version. What should I do about that?

@rongcuid: Yes, merging the branch in this PR directly to master would cause lots of conflicts, since it is based on the release branch. Hence I just cherry-picked the single commit on top of master.
Next time you want to make a PR, base your changes on master instead of the release branch. You don't have to move your whole (NixOS) system over, you can build separate packages just fine from a nixpkgs working tree.

authors: bjornfor rongcuid


text:
Remove KVM assumption

Description of changes
Challenge insistance on KVM.
KVM is a very particular way to accelerate VMs, why is that the default?
Insistance on KVM also introduces the need for side-effects and makes building images non-portable between envrionments: KVM is typically available on bare-metal, not so much in Containers, sub-VMs or Mac.
KVM is never a requirement; VMs runs fine without KVM - albeit slower.
This puts the onus on making KVM an opt-in capability, rather than a
necessary requirement.
Besides, QEMU is perfectly able to fallback from KVM to TCG JIT but that
can never happen if nix-daemon prevents it from ever trying.
In the current situation:

one has to modify nix.conf on Non-NixOS
AND have a CPU with virtualization extensions
AND have the {amd, intel}-kvm kernel module loaded
AND have correct permissions to /dev/kvm
and that is too much to insist on - certainly for building images.

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

See also
https://github.com/nix-community/nixos-generators/issues/83
https://github.com/NixOS/nix/issues/2964

[...] the qemu package includes emulators for all targets, while the qemu_kvm package only includes an emulator for the hostPlatform and does work without kvm despite its naming

Thanks, good to know!

people run into timeouts when running NixOS tests and the likes without KVM (exactly because it did a fallback to emulation instead of KVM it was very hard to debug why this test fails on one machine but succeeds on the other!).

I can appreciate that from own experience too, but that can be attributable to many things beyond KVM: Machine speed, contention. Generally, setting a hard time-deadline for something that is not real-time will always fail in some corner cases. A better approach would be to set the deadline based on machine speed -- otherwise who is to say that my cloud vCPU or random-old-machine won't violate the timeout.
So I don't find that to be an argument for insisting on KVM.
Best of both worlds:

We use qemu_kvm, for its smaller closure size etc. QEMU falls back to TCG if KVM is unavailable. (qemu_kvm is quite a poor name; qemu_small_host might be better and wouldn't cause a collision with established terminology, thus preventing my assumption).
Nix C++ has its dynamic detection of KVM capability. Good.
nixpkgs drops its insistance of KVM. If KVM not found, large warning is printed (to make it discoverable) and test deadlines are multipled by 10x (or better: based on some performance measurement).

I'd be happy to contribute towards this. How do you feel about this?

Thank you for your interesting contribution, please follow the CONTRIBUTING guide and rename the PR title accordingly and same for your commit messages.
FWIW, such changes are too big to be landed in the future days, you will have to wait for the branch-off after 23.05, also, it would be a good thing to have a Hydra jobset to perform regression testing on your changes to ensure you did not break the tests for whatever edge case reason.
On the contents, I think you are missing a lot of occurrences of qemu_kvm, I'd move the change inside of qemu_kvm, rename qemu_kvm treewide, then we need to discuss the removal of requiredSystemFeatures for runInLinuxVM.
Ideally, building images should not require a VM at all, but unfortunately, supporting all our usecases seems not feasible even with LKL. Let's put this as an orthogonal problem.
On the dynamic detection, it seems like what we would like is preferredSystemFeatures and indeed a large warning print seems a good idea.
I'm not sure how you would bump the deadline dynamically though unfortunately, it's Hydra's area and I believe this to be quite thorny at the moment.

A better approach would be to set the deadline based on machine speed -- otherwise who is to say that my cloud vCPU or random-old-machine won't violate the timeout.

You are right but in the meantime, we are experiencing less issues with KVM rather than without, except if you do suggest a major change in the buildfarm system to take into account the machine speed and its busyness, I don't think it's a realistic change (to not use KVM).

qemu_kvm is quite a poor name; qemu_small_host might be better and wouldn't cause a collision with established terminology, thus preventing my assumption

absolutely agree it is a bad name

A better approach would be to set the deadline based on machine speed

When talking about timeouts, I was not talking about Hydra or overall derivation build time, but things like systemd services and service-internal timeouts in NixOS test VMs.

nixpkgs drops its insistance of KVM

Okay, so you want to remove the requiredSystemFeatures = [ "kvm" ];?
Consider this: When you have several remote builders, some of which have kvm support and others don't, it would be much smarter to run these derivations on the ones that do have kvm support. Removing the feature flag from the derivation would make it impossible to perform this kind of scheduling.
Instead, it might be better to rename the system feature to "vm" or "qemu", to signify that you can also enable this feature in nix.conf on hosts that don't have kvm, to tell Nix to run VM derivations on that host.

Hydra.nixos.org: I don't think we really utilize the tag there.  All our linux builders support it and we also have nixos-test feature that probably covers very similar set of jobs on Hydra.

Is anyone still planning to work on this, or can it be closed?

authors: RaitoBezarius mped-oticon vcunat yu-re-ka


text:
gnu-efi: 3.0.15 -> 3.0.17

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for gnu-efi is: GNU EFI development toolchain
meta.homepage for gnu-efi is: https://sourceforge.net/projects/gnu-efi/
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 3.0.17 with grep in /nix/store/ik3i4chh4bdld9kj0a80xw8pg39w5nz6-gnu-efi-3.0.17
found 3.0.17 in filename of file in /nix/store/ik3i4chh4bdld9kj0a80xw8pg39w5nz6-gnu-efi-3.0.17

Rebuild report (if merged into master) (click to expand)

17253 total rebuild path(s)

17253 package rebuild(s)

First fifty rebuilds by attrpath

AusweisApp2
CHOWTapeModel
ChowKick
ChowPhaser
CuboCore.coreaction
CuboCore.corearchiver
CuboCore.corefm
CuboCore.coregarage
CuboCore.corehunt
CuboCore.coreimage
CuboCore.coreinfo
CuboCore.corekeyboard
CuboCore.corepad
CuboCore.corepaint
CuboCore.corepdf
CuboCore.corepins
CuboCore.corerenamer
CuboCore.coreshot
CuboCore.corestats
CuboCore.corestuff
CuboCore.coreterminal
CuboCore.coretime
CuboCore.coretoppings
CuboCore.coreuniverse
CuboCore.libcprime
CuboCore.libcsys
DisnixWebService
EBTKS
EmptyEpsilon
HentaiAtHome
MIDIVisualizer
OSCAR
OVMF
OVMFFull
PageEdit
R
SDL2
SDL2_gfx
SDL2_image
SDL2_image_2_0_5
SDL2_mixer
SDL2_mixer_2_0
SDL2_net
SDL2_sound
SDL2_ttf
SDL2_ttf_2_0_15
SDL_audiolib
SDL_compat
SDL_gpu

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/ik3i4chh4bdld9kj0a80xw8pg39w5nz6-gnu-efi-3.0.17 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A gnu-efi https://github.com/r-ryantm/nixpkgs/archive/6efc3981aab2b94545beef6e17a467bedfe748cf.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/ik3i4chh4bdld9kj0a80xw8pg39w5nz6-gnu-efi-3.0.17
ls -la /nix/store/ik3i4chh4bdld9kj0a80xw8pg39w5nz6-gnu-efi-3.0.17/bin

Pre-merge build results
NixPkgs review skipped

Maintainer pings

Broke this one, I think:
https://hydra.nixos.org/build/221624593/nixlog/2/tail

https://sourceforge.net/p/gnu-efi/bugs/37/
Let's revert this PR, then.

authors: r-ryantm vcunat wegank


text:
edac-utils: unstable-2015-01-07 -> unstable-2023-01-30

Description of changes
This change updates edac-utils package to the latest commit (see changes).
It also

adds perl to buildInputs so that shebang is fixed in edac-ctl command,
adds a patch to avoid using wrapProgram for PATH,
removes sysv init script from $out/etc.

Things done

Built on platform(s)

[x] x86_64-linux (pkgsCross.gnu64)
[x] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Force-pushed rebase to the latest master branch.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-already-reviewed/2617/1380

adds perl to buildInputs so that shebang is fixed in edac-ctl command,

Please add this info as a comment next to perl so that people know why it's there and won't remove it thinking it unnecessary (the upstream project does not seem to explicitly explain the dependency in README or otherwise).

@nh2 done.

@nh2, gentle ping.

authors: nh2 nixos-discourse tie


text:
pianoteq: Submit/pianoteq version update

Description of changes

Things done
Updated version number of trial version to 8.1.1 and added standard-8, standard-7, and standard-6 versions with hashes.

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Unsure of how to request reviews with current permissions, but I believe the current maintainer for pianoteq is @mausch if you are able to merge this.

Hi and thanks for the updates!
A few things to fix:

There are two seemingly identical commits.
There's a merge from master, please don't do that.
Did you use some sort of automated formatting tool? There's some odd formatting there e.g. no spaces in lists, I don't think that's typical for nixpkgs. Also it's best in general to keep formatting changes in  commits separate from actual changes.

Hello,
It looks like I have accidentally managed to ping a ton of unrelated people, so I will be closing this pull request. Apologies as I am somewhat new to this.

authors: mausch purepani


text:
lib.lists.{hasPrefix,removePrefix}: init

Description of changes
Adds two new functions:

lib.lists.hasPrefix :: [ a ] -> [ a ] -> bool: Whether the first list is a prefix of the second list:lib.lists.hasPrefix [ 1 2 ] [ 1 2 3 4 ]
-> true

lib.lists.removePrefix :: [ a ] -> [ a ] -> [ a ]: Remove the first list as a prefix from the second list, erroring if it's not a prefix:lib.lists.removePrefix [ 1 2 ] [ 1 2 3 4 ]
-> [ 3 4 ]
lib.lists.removePrefix [ 1 2 ] [ 3 4 ]
-> <error>

This is distantly part of the path library effort, in order to be able to work with lists of path components.
This work is sponsored by Antithesis :sparkles:
Things done

[x] Docs
[x] Tests

Yeah I think I'm happy with this design, I think this can be merged.


text:
grafana-agent: build and embed flow mode web ui

Description of changes
Build and embed the flow mode web ui frontend (default localhost:12345), which is only available in when starting in flow mode.
See #246742 for more context and a sample config.
Upstream docs: https://grafana.com/docs/agent/latest/flow/
Closes #246742
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review run on x86_64-linux 1

1 package built:

grafana-agent

@emilylange with the recent version bumps, does this need to be rebased / the hash updated? Any way to ensure this doesn't forget to get updated during version bumps?

@emilylange with the recent version bumps, does this need to be rebased / the hash updated?

No, as the recent bumps did not touch the yarn.lock^1.

Any way to ensure this doesn't forget to get updated during version bumps?

If there is a mismatch between the provided FOD yarn offline cache and the yarn.lock in src, the yarn install simply fails and thus the build itself fails.
To provide an example error log, I went back to d375babda185cf7a6eb41298cb9f23e522f30010 (v0.30.2) and cherry-picked this commit on top.
@nix { "action": "setPhase", "phase": "unpackPhase" }
unpacking sources
unpacking source archive /nix/store/bjk429c1iiws7i9a4nqwk4rdakh0y0bx-source
source root is source
@nix { "action": "setPhase", "phase": "patchPhase" }
patching sources
@nix { "action": "setPhase", "phase": "configurePhase" }
configuring
@nix { "action": "setPhase", "phase": "buildPhase" }
building
~/source/web/ui ~/source
yarn config v1.22.19
success Set "yarn-offline-mirror" to "/nix/store/xbgc0i5hjp24jidqmg0bc2014b5dj828-offline".
Done in 0.02s.
yarn install v1.22.19
[1/4] Resolving packages...
[2/4] Fetching packages...
error Can't make a request in offline mode ("https://registry.yarnpkg.com/_fortawesome_fontawesome_svg_core___fontawesome_svg_core_6.1.2.tgz")
info Visit [0m1mhttps://yarnpkg.com/en/docs/cli/install for documentation about this command.

Meaning, a mismatch will be easy to catch -- both locally and by ofborg :)
@ofborg build grafana-agent
nix-update, however, does not support updating the fetchYarnDeps hash yet^2.

I migrated some of my configs to flow mode and can confirm the web interface does do what it should. Thanks! :+1:

authors: emilylange flokli


text:
ssh-tpm-agent: init at unstable-2023-08-12

Description of changes
Adds the new experimental ssh-tpm-agent package, allowing ssh users to easily authenticate with keys sealed by their TPM2 chip.
Todo:

[ ] Fix failing tests
[ ] Maybe wait for newer release

Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

@Foxboron ^^

After discussing it with @stigtsp the idea is to wait for a 1.0.0 release and keep the PR available for people that want to test ssh-tpm-agent.

@RaitoBezarius Hi! A certain fox noticed that you had some options for ssh-tpm-agent in your config. I'm thinking to set up NixOS options for this as well - likely in a later PR. Would you be interested in reviewing?
https://github.com/RaitoBezarius/nixos-home/blob/master/ssh/tpm-agent.nix

@RaitoBezarius Hi! A certain fox noticed that you had some options for ssh-tpm-agent in your config. I'm thinking to set up NixOS options for this as well - likely in a later PR. Would you be interested in reviewing?
https://github.com/RaitoBezarius/nixos-home/blob/master/ssh/tpm-agent.nix

Of course! I didn't know this certain fox was okay with 0.3.0 :>

Of course! I didn't know this certain fox was okay with 0.3.0 :>

After implementing the ASN.1 TPM keys I don't really need to lock down the key format anymore. So it should be fine as the key would probably not need to be upgraded in the future.

@stigtsp You want to pull this patch fwiw, https://github.com/Foxboron/ssh-tpm-agent/commit/65d5a501bf1ce7f358006ad48af0c2c85f459d1c

@stigtsp You want to pull this patch fwiw, Foxboron/ssh-tpm-agent@65d5a50

Should we bump it to the next releaee

@stigtsp You want to pull this patch fwiw, Foxboron/ssh-tpm-agent@65d5a50

Are you planning a new release soon? Would prefer to update this PR to that if it's not far off.

@stigtsp I can do a bugfix release this weekend probably.

https://github.com/Foxboron/ssh-tpm-agent/releases/tag/v0.3.1
should be fine.

Tested this a bit more, and it works for me.
@RaitoBezarius Any showstoppers to merging this you think?

This looks good to me except it’s missing meta.mainProgram

Thanks, added.

Here's a simple HM config (easily translated to nixos). I'm actually not going to use this for now because I need to load other keys into the agent and this agent, like yubikey-agent, doesn't support that.
home.packages = [ pkgs.ssh-tpm-agent ];
systemd.user.services.ssh-tpm-agent = {
  Unit.PartOf = [ "default.target" ];

  Service = {
    Type = "simple";
    ExecStart = "${lib.getExe pkgs.ssh-tpm-agent} -l %t/ssh-agent";
    RestartSec = 3;
    Restart = "on-abort";
  };

  Install.WantedBy = [ "default.target" ];
};

@adamcstephens
Look at the proxy support.
https://github.com/Foxboron/ssh-tpm-agent?tab=readme-ov-file#proxy-support

@Foxboron thanks! i missed that in the readme.

authors: Foxboron RaitoBezarius adamcstephens stigtsp


text:
python311Packages.pysignalclirestapi: 0.3.18 -> 0.3.21

Description of changes
Diff: https://github.com/bbernhard/pysignalclirestapi/compare/0.3.18...0.3.21
Changelog: https://github.com/bbernhard/pysignalclirestapi/releases/tag/0.3.21

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 264203 run on x86_64-linux 1

5 packages built:

home-assistant-component-tests.signal_messenger
python310Packages.pysignalclirestapi
python310Packages.pysignalclirestapi.dist
python311Packages.pysignalclirestapi
python311Packages.pysignalclirestapi.dist

authors: dotlambda natsukium