text:
okular: missing gschemas

Issue description
Opening a file dialog leads to a crash with:
GLib-GIO-ERROR **: No GSettings schemas are installed on the system

Technical details

System: 17.03 25c590f9 (probably the same on master)

This is surprising to me.  Apparently qtbase can decide to use lib/qt5/plugins/platformthemes/libqgtk3.so and thus show gtk3 file dialogs.  Those lead to a crash unless the executable can find the schemas; we typically solve this by a wrapper that extends $XDG_DATA_DIRS by ${gtk3.out}/share/gsettings-schemas. (IIRC wrapGAppsHook does this automatically, maybe conditioned on having gtk3 in build inputs.)
I suspect all Qt apps may suffer from this problem. /cc @ttuegel.

Yes, all Qt applications will have this problem. Qt 5 already depends on GTK 3, so I think it would be fine to extend makeQtWrapper to depend on it also.
Related: we really really need an extensible interface for wrapProgram in Nixpkgs. To implement this, I will have to copy wrapGAppsHook into makeQtWrapper. We can't have both run because that will just stack wrappers on top of wrappers...

IIRC wrapGAppsHook is extensible.  Packages can define setup hooks that extend gappsWrapperArgs.  Maybe it doesn't cover all use cases or something...

It has built-in functionality: just because I want an extensible wrapper doesn't mean I want all of the presets that come with wrapGAppsHook.
It wraps everything it can get its hands on, which is not correct.

Adding this to the milestone -- seems pretty serious (all Qt applications terminate for me now when I try to open a file).

I can't do anything about this on the Qt end except to disable all GTK support. Qt 5 detects GTK 3 at runtime for desktop integration; there is no build dependency. I can't add GTK as a dependency to every Qt program, so I can't set this in wrappers. Either I completely disable GTK integration in Qt, or you patch GTK to find its own dependencies. (Fair is fair: I've patched Qt several times for the same reason.)

I wanted to propose this very idea -- since GTK applications don't work without gsettings_desktop_schemas to this extent it would be easier to just patch it into GTK.

I'm working on that now; this will require patches to both GTK and Glib (I also want to patch dconf into GTK so settings for file choosers and other components would work as expected). On the good side this will actually allow us to reduce closure of many applications: most of non-GNOME ones don't actually require gsettings_desktop_schemas, just the schemas from GTK 3 itself.
@ttuegel I'm interested, how does Qt find GTK if it's not a build dependency?

After a little more investigation:

Instead of (very hacky) patches we should just require everyone to properly use wrapGAppsHook instead of custom wrappers; it should also add dconf by default to ensure GTK can save its settings.
Qt 5 does actually have a dependency on GTK3 now (in nix-store -qR) so what about adding needed additional wrapping to wrapQtProgram? One needs to add paths to GTK3 gsettings schemas and GIO paths to dconf; I'll try to do it later if @ttuegel agrees with the general direction.

Qt 5 does actually have a dependency on GTK3 now (in nix-store -qR) so what about adding needed additional wrapping to wrapQtProgram?

I thought it was supposed to dlopen(libgtk) at runtime to avoid retaining a dependency. Either that is broken or I misunderstood how it works.

One needs to add paths to GTK3 gsettings schemas and GIO paths to dconf; I'll try to do it later if @ttuegel agrees with the general direction.

That would be fine with me. You will need to fork make-qt-wrapper.sh because Qt < 5.7 do not have GTK support, but Qt >= 5.7 do have it. There is also a separate setup hook make-qt-wrapper-darwin.sh for Darwin. I'm not sure if qgtk is disabled on Darwin, but it it probably should be. (Ostensibly, the point of qgtk is for Qt apps to integrate into GTK-based desktop environments, but there aren't such on Darwin!)

@ttuegel Quick question: why do you use import for calling Qt instead of callPackage? I ask because I need to add several arguments and wonder if I can just use callPackage instead.

Two reasons: First, I have been reprimanded in the past for using callPackage on a thing that is not a package. More importantly, callPackage uses makeOverrideable, which will break the call to makeScope in the Qt 5 package set.
By the way, I'm putting together something to supplant makeQtWrapper and maybe wrapGAppsHook which would probably fix this by coincidence:
https://github.com/ttuegel/nixpkgs/tree/wrapProgramsHook
It may or may not be of interest.

I wanted to do just that too, thanks for linking otherwise we would duplicate the work ^_^
But I'm not sure if we would be able to get this into release so I wanted to make something minimal meanwhile. Is that a good idea or maybe we should just pursue more fundamental solution?

But I'm not sure if we would be able to get this into release so I wanted to make something minimal meanwhile. Is that a good idea or maybe we should just pursue more fundamental solution?

No, you're absolutely right, a minimal solution is what we want for the release.

authors: abbradar ttuegel vcunat


text:
Package request: wio (fork)

Project description
Wayland compositor similar to Plan 9's rio (mirror).
Note that the upstream for this software was removed previously due to being unmaintained and depending on an outdated wlroots. I am proposing that this fork of that software is added to pkgs and the entry for the original in aliases.nix is amended to point to the fork. Note also that the only changes made from the original wio derivation to build the software (other then changing src) is the addition of preConfigure = ''sed -i "16 a '-Wno-maybe-uninitialized'," meson.build'';. I am pinging @AndersonTorres because they where the maintainer of the deprecated software that this addition will posthumously replace.
Metadata

homepage URL: https://github.com/Rubo3/wio
source URL: https://github.com/Rubo3/wio
license: BSD 3-Clause
platforms: linux

I am happy to know!

source: gharchive/issue

repo: NixOS/nixpkgs

license: MIT

license_type: permissive

license_source: github-api


text:
Pipewire Microphone detected but no Sound recieved

Describe the bug
I use Pipewire for my system sound. When I try to use my microphone (e.g. with Discord), the microphone registers normally, but the application does not get any sound data, as if it is muted. I checked, but could not find a setting to mute the microphone. The audio output works fine.
Steps To Reproduce

I am using the following config:

security.rtkit.enable = true;
services.pipewire = {
  enable = true;
  alsa.enable = true;
  alsa.support32Bit = true;
  pulse.enable = true;
  jack.enable = true;
};
hardware.pulseaudio.enable = false;
sound.enable = false;

Open an Application that uses Sound Input (e.g. Discord)
All microphones are recognized, but no audio is provided

Expected behavior
Getting audio from my microphone.
Additional context
I already posted a comment in the subreddit, a few people had similar issues there, but no one was able to solve the problem.
Notify maintainers

@Kranzes @K900
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.1.63, NixOS, 24.05 (Uakari), 24.05pre552293.5a09cb4b393d`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.1`
 - channels(root): `"home-manager, nixos, nixos-unstable"`
 - channels(isiko404): `"nixos-stable-23.05, nixos-unstable"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Priorities
Add a :+1: reaction to issues you find important.

Hold on. So this is a USB microphone, not your laptop's built-in one?

I have an Internal Mic and a Scarlet Solo Audio interface. Both are recognized in Applications, both don't give me sound data

EDIT: I just retested with audacity, and I'm getting a different result now. When using the External Audio interface I'm getting an "Invalid sample rate" Error (Error code -9997). Internal Mic seems to be working now, at leas in Audacity.
Issue is still the same with Discord though.

Update: Added some Logs from journalctl to this Issue, maby that helps

(maybe off-topic)
I have similar log output in journalctl when I try pw-play. I get no sound played from it (direct Pipewire client).
On the other hand when I try to play with paplay (via PulseAudio) it works normally despite going through Pipewire also.

I have the same issue with the same errors in journalctl https://github.com/NixOS/nixpkgs/issues/275431#issuecomment-1882431145
My internal laptop mic isnt recognized by pipewire or pulse, but I tried to record from a sink (using an application called broo, it just redirects mumble output to a sink) and when I connect the output of mumble to me speakers I can definitely hear my voice, but when I connect it to the sink, the application (firefox, discord, etc) doesnt receive any audio.
What's interesting is audacity's behaviour:
On the ALSA backend my laptop's internal mic IS recognized and works just fine! (I thought it was a driver bug). However, when switching to the "pulse" ALSA device it doesn't work.
On the JACK backend my laptop's internal mic is also recognized (unlike in pulse/pavucontrol) but it doesn't get any data.
I've tried this on both 23.11 and unstable. Here's my audio config:
  # Enable sound.
  sound.enable = true;
  security.rtkit.enable = true;
  services.pipewire = {
    enable = true;
    alsa.enable = true;
    alsa.support32Bit = true;
    pulse.enable = true;
    jack.enable = true;
  };

As kquote mentioned, this issue is possibly related. It sounds an awful lot like the issue I am experiencing

Seems to be similar, but #275431 mentions that the problem occurs when migrating to 23.11. I've had the problem since I switched to NixOS, so since 23.05.

Ah! You're totally right... I completely glossed over that. I'm intrigued to find out if they actually relate or not if/when we find a solution to this

deleting ~/.local/state/wireplumber and rebooting fixed it for me

deleting ~/.local/state/wireplumber and rebooting fixed it for me

Tried that, sadly didn't work for me :/

BTW: I just tested running arecord with my current config and although it was extremely distorted, I got sound data back

I also had to delete ~/.config/systemd/ as my pipewire and wireplumber service files were for some odd reason 0 bytes

I also had to delete ~/.config/systemd/ as my pipewire and wireplumber service files were for some odd reason 0 bytes

That might have fixed it for me, at least my internal mic now gives me sounds. I'm currently not home, but will update when I get home and can test with my USB Mic.

Update: It worked! My mic now works without any problems. If anyone has an idea or explanation as to how this problem arose, please tell me :)

Update: It worked! My mic now works without any problems. If anyone has an idea or explanation as to how this problem arose, please tell me :)

i have nooooooooooo idea???! i actually installed fedora on a separate subvolume but with the same home subvolume/partition to dualboot because i did need my mic but nixos was too good to uninstall, and the pipewire service file just "did not exist" in fedora each time i tried to start it, I thought it was a broken symlink, so I deleted the entire systemd folder from my user because I dont user other systemd user services, and I saw that fedora had the same mic issue, so I also removed the wireplumber dirs from my user and saw that it fixed it. I rebooted to nixos and saw that the mic works there too. it's just all happy accidents LOL

LOL

deleting ~/.local/state/wireplumber and rebooting fixed it for me

This has fixed my problem!!, no need to reboot just restart the services:
systemctl --user start pipewire-pulse pipewire wireplumber
how did you come to this solution?

I also had to delete ~/.config/systemd/ as my pipewire and wireplumber service files were for some odd reason 0 bytes

Could you specify which file under this directory is causing the issue?

deleting ~/.local/state/wireplumber and rebooting fixed it for me

@kquote03 Thanks, this works for me, but this state is quickly disrupted to the point where I have to delete the directory again, it seems it's not a final solution. Is there a better way to handle this?

deleting ~/.local/state/wireplumber and rebooting fixed it for me

This has fixed my problem!!, no need to reboot just restart the services: systemctl --user start pipewire-pulse pipewire wireplumber
how did you come to this solution?

Thanks, this works for me


text:
Unwanted boilerplate: finalAttrs.finalPackage.doCheck

Currently much cross logic is not included in the finalAttrs fixed point, meaning that if you use finalAttrs.doCheck internally in your derivation then this does not automatically account for whether stdenv.buildPlatform.canExecute stdenv.hostPlatform.
The current most elegant fix is to inject finalPackage into the expression, but this is not documented.

Example
For example, consider:
https://github.com/NixOS/nixpkgs/blob/221b92f95ea48aee4a12c6f9e242d5f75fd1a701/pkgs/development/libraries/libspatialindex/default.nix#L25-L27
nix-repl> libspatialindex.cmakeFlags
[ "-DSIDX_BUILD_TESTS=ON" ]

nix-repl> pkgsCross.aarch64-multiplatform.libspatialindex.cmakeFlags
[ "-DSIDX_BUILD_TESTS=ON" "-DCMAKE_SYSTEM_NAME=Linux" "-DCMAKE_SYSTEM_PROCESSOR=aarch64" "-DCMAKE_HOST_SYSTEM_NAME=Linux" "-DCMAKE_HOST_SYSTEM_PROCESSOR=x86_64" ]

The fix is to inject finalPackage:
https://github.com/NixOS/nixpkgs/blob/ad5e744714640aad36eda89e6b6026c397b4ace5/pkgs/development/libraries/libspatialindex/default.nix#L25-L27
which will get us
nix-repl> libspatialindex.cmakeFlags
[ "-DSIDX_BUILD_TESTS=ON" ]

nix-repl> pkgsCross.aarch64-multiplatform.libspatialindex.cmakeFlags
[ "-DSIDX_BUILD_TESTS=OFF" "-DCMAKE_SYSTEM_NAME=Linux" "-DCMAKE_SYSTEM_PROCESSOR=aarch64" "-DCMAKE_HOST_SYSTEM_NAME=Linux" "-DCMAKE_HOST_SYSTEM_PROCESSOR=x86_64" ]

The current recommendation in the docs (added in 2017) is to hoist the cross logic up into the derivation:
https://github.com/NixOS/nixpkgs/blob/5a67e3268c84b93fb113a2dc4288b357726d5588/doc/stdenv/cross-compilation.chapter.md?plain=1#L148-L154
Tree-wide fixes are simple to apply, but are ultimately a bodge. Hence this issue
Related: #266485

Add a :+1: reaction to issues you find important.

I believe this could be fixed by putting the cross logic into the default value of the doCheck argument directly. Something like
diff --git a/pkgs/stdenv/generic/make-derivation.nix b/pkgs/stdenv/generic/make-derivation.nix
index faa83507893f..2ae5dde79fd1 100644
--- a/pkgs/stdenv/generic/make-derivation.nix
+++ b/pkgs/stdenv/generic/make-derivation.nix
@@ -158,7 +158,7 @@ let

 # TODO(@Ericson2314): Make unconditional / resolve #33599
 # Check phase
-, doCheck ? config.doCheckByDefault or false
+, doCheck ? (config.doCheckByDefault or false) && stdenv.buildPlatform.canExecute stdenv.hostPlatform

 # TODO(@Ericson2314): Make unconditional / resolve #33599
 # InstallCheck phase

Expressing it as a global overrideAttrs (old: { doCheck = old.doCheck && stdenv.buildPlatform.canExecute stdenv.hostPlatform; }) may work, but the cross infra is to me too daunting to try to make major changes to.

authors: infinisil pbsds


text:
Figure out what to do with our uses of builtins.match before Nix 1.12 is released

A quick git grep against a recent HEAD reveals that we use builtins.match fairly extensively:
$ git grep builtins.match
lib/filesystem.nix:                          (map (builtins.match pattern) files);
lib/sources.nix:    in lib.any (re: builtins.match re relPath != null) regexes) src;
nixos/modules/services/misc/geoip-updater.nix:          (x: builtins.match ".*\.(gz|xz)$" x == null) cfg.databases) == [];
nixos/modules/services/misc/geoip-updater.nix:          ${toString (builtins.filter (x: builtins.match ".*\.(gz|xz)$" x == null) cfg.databases)};
pkgs/build-support/fetchgit/default.nix:    matched = builtins.match "(.*).git" base;
pkgs/build-support/fetchgit/default.nix:    appendShort = if (builtins.match "[a-f0-9]*" rev) != null
pkgs/build-support/fetchurl/boot.nix:    let m = builtins.match "mirror://([a-z]+)/(.*)" url; in
pkgs/development/idris-modules/default.nix:      m = builtins.match "(.*)\.nix" name;
pkgs/os-specific/linux/kernel/cpu-cgroup-v2-patches/default.nix:  match = builtins.match "(.*)\\.patch" name;
pkgs/top-level/impure.nix:            (builtins.filter (n: builtins.match ".*\.nix" n != null || pathExists (path + ("/" + n + "/default.nix")))

We need to figure out which regexes will be affected by the change (if any) and fix them.
Also, many of them already behave differently between Linux and Darwin (see https://github.com/NixOS/nix/issues/1537), so we should probably do something about those even before 1.12 😄

I can look at the idris usage of builtins.match but how has it changed in version 1.12?
Eventually I think I will refactor that code anyway to not rely on match at all.

It now uses std::regex in C++ which I think has slightly different syntax and behavior from before.

Here's one difference which I noticed with non-matching capture groups:
$ nix-build -A nix
/nix/store/6lgqkk4cpcsi3bl2xnk5q0ylsn2vdmvj-nix-1.11.15
$ ./result/bin/nix-instantiate --eval -E 'builtins.match "(x)?(y)?" ""'
[ ]
$ nix-build -A nixUnstable
/nix/store/h2zl1b3297gwixk26lpvzhmlcdzyl1j9-nix-1.12pre5663_c7af84ce
$ ./result/bin/nix-instantiate --eval -E 'builtins.match "(x)?(y)?" ""'
[ null null ]

authors: copumpkin dezgeg mpickering


text:
Build failure: vimPlugins.nvim-treesitter.tests.check-queries

Steps To Reproduce
Steps to reproduce the behavior:

build vimPlugins.nvim-treesitter.tests.check-queries

Build log

Check failed!
Errors:
) Invalid capture @OrgStars1 in highlights for org.
(x) Invalid capture @OrgHeadlineLevel1 in highlights for org.
(x) Invalid capture @OrgStars2 in highlights for org.
(x) Invalid capture @OrgHeadlineLevel2 in highlights for org.
(x) Invalid capture @OrgStars3 in highlights for org.
(x) Invalid capture @OrgHeadlineLevel3 in highlights for org.
(x) Invalid capture @OrgKeywordTodo in highlights for org.
(x) Invalid capture @OrgKeywordDone in highlights for org.
(x) Invalid capture @OrgPriority in highlights for org.
(x) Invalid capture @OrgPriorityCookie in highlights for org.
(x) Invalid capture @OrgTag in highlights for org.
(x) Invalid capture @OrgTagList in highlights for org.
(x) Invalid capture @OrgPropertyDrawer in highlights for org.
(x) Invalid capture @OrgPropertyName in highlights for org.
(x) Invalid capture @OrgPropertyValue in highlights for org.
(x) Invalid capture @OrgProperty in highlights for org.
(x) Invalid capture @OrgTimestampInactive in highlights for org.
(x) Invalid capture @OrgTimestampDay in highlights for org.
(x) Invalid capture @OrgTimestampDate in highlights for org.
(x) Invalid capture @OrgTimestampTime in highlights for org.
(x) Invalid capture @OrgTimestampRepeat in highlights for org.
(x) Invalid capture @OrgTimestampDelay in highlights for org.
(x) Invalid capture @OrgTimestampActive in highlights for org.
(x) Invalid capture @OrgFootnoteLabel in highlights for org.
(x) Invalid capture @OrgFootnoteDescription in highlights for org.
(x) Invalid capture @OrgFootnoteDefinition in highlights for org.
(x) Invalid capture @OrgDirectiveName in highlights for org.
(x) Invalid capture @OrgDirectiveValue in highlights for org.
(x) Invalid capture @OrgDirective in highlights for org.
(x) Invalid capture @OrgComment in highlights for org.
(x) Invalid capture @OrgDrawerName in highlights for org.
(x) Invalid capture @OrgDrawerContents in highlights for org.
(x) Invalid capture @OrgDrawer in highlights for org.
(x) Invalid capture @OrgBlockName in highlights for org.
(x) Invalid capture @OrgBlockContents in highlights for org.
(x) Invalid capture @OrgBlock in highlights for org.
(x) Invalid capture @OrgDynamicBlockName in highlights for org.
(x) Invalid capture @OrgDynamicBlockContents in highlights for org.
(x) Invalid capture @OrgDynamicBlock in highlights for org.
(x) Invalid capture @OrgListBullet in highlights for org.
(x) Invalid capture @OrgCheckbox in highlights for org.
(x) Invalid capture @OrgCheckInProgress in highlights for org.
(x) Invalid capture @OrgCheckDone in highlights for org.
(x) Invalid capture @Error in highlights for org.
(x) Invalid capture @OrgTableHorizontalRuler in highlights for org.
(x) Invalid capture @OrgCellFormula in highlights for org.
(x) Invalid capture @OrgCellNumber in highlights for org.
(x) Invalid capture @property in locals for qmljs.
(x) Invalid capture @reference._let in locals for racket.
(x) Invalid capture @reference._def in locals for racket.

Additional context
Add any other context about the problem here.
Notify maintainers
Maintainer: cc @figsoda
Other relevant contributors: cc @teto @mrcjkb
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.6.43, NixOS, 24.11 (Vicuna), 24.11.20240804.cb9a96f`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.5`
 - nixpkgs: `/nix/store/4cpakzyvfw1rmm9v5i3387x6jd2h1v86-source`

Add a :+1: reaction to issues you find important.

:thinking: nvim-treesitter no longer bundles any queries for tree-sitter-org. So I wonder where they're coming from (if not from an older version of nvim-treesitter).

now its bundling ALL the grammars into a single vimplugin-treesitter-grammars DRV, and another one of my plugins is somehow adding in duplicates causing a collision and I cannot figure out why, or what changed....
If I build a neovim with JUST nvim-treesitter.withAllGrammars it builds, and groups them all into a vimplugin-treesitter-grammars drv which it did not before, it used to just put them all in the packpath as their own plugin.
If I try to build my config, something is adding more stuff in there to it and its conflicting, all I get is a single line saying it cant use ln because the parser exists already...
its not the norg overlay I tried disabling that...
Pretty confused rn

Also, judging by the issues threads about grammars,
Does anyone ACTUALLY know how the queries were being included before being copied as described in this issue?

https://github.com/NixOS/nixpkgs/pull/339076?notification_referrer_id=NT_kwDOBRauArQxMjIxOTk5ODQ4NDo4NTM3MjQxOA#issuecomment-2327676324
The collisions I mentioned were this issue

Collisions in treesitter grammars are impossible, as treesitter chooses the first grammar it finds, and ignores others (to allow plugins overwrite built-in grammars).
Though bisected this to 51e69413cfc928d02e19c27c9342af2931166d4d, maybe that's also an upstream bug?

authors: BirdeeHub GaetanLepage PerchunPak mrcjkb


text:
Migrate from PCRE to PCRE2

PCRE2 was released in 2015. The original PCRE is end‐of‐life and will not receive further bug fixes. Debian decided to remove it years ago (they called their original‐PCRE package pcre3 for historical reasons), filed mass bug reports against packages still using it, and it has been gone entirely since the release of Bookworm last year. We should follow suit, upgrading packages to PCRE2 where possible and considering dropping obsolete software that won’t get updated to a supported version, especially if it processes untrusted input.
Issues and PRs

https://github.com/NixOS/nixpkgs/pull/355989
https://github.com/NixOS/nixpkgs/pull/356690
https://github.com/NixOS/nixpkgs/pull/356976

We need to be careful with services that have systemd hardening because they can block the PCRE2 jit like eg https://github.com/NixOS/nixpkgs/pull/179444

Here's a list of all the packages in pkgs/by-name that still refer to pcre (may not be complete):

[ ] adriconf
[ ] aegisub
[ ] ansel
[ ] apvlv
[ ] argyllcms
[ ] atheme
[ ] audacity
[ ] bambu-studio
[ ] blendfarm
[ ] chow-kick
[ ] chow-phaser
[ ] chow-tape-model
[ ] classads
[ ] contour
[ ] cppcheck
[ ] cppcms
[ ] cpu-x
[ ] createrepo_c
[ ] dablin
[ ] darktable
[ ] dico
[ ] edbrowse
[ ] ethtool
[ ] ettercap
[ ] evolution-data-server
[ ] ezquake
[ ] fastfetch
[ ] fntsample
[ ] frei0r
[ ] gmt
[ ] gromit-mpx
[ ] gsmartcontrol
[ ] haka
[ ] hardinfo
[ ] hashlink
[ ] hybridreverb2
[ ] hyperscan
[ ] hyprpaper
[ ] igprof
[ ] infamousPlugins
[ ] inspircd
[ ] io
[ ] ivan
[ ] jiten
[ ] kamailio
[ ] kermit-terminal
[ ] kismet
[ ] lemminx
[ ] libgaminggear
[ ] liblognorm
[ ] libmp3splt
[ ] libr3
[ ] lightdm-enso-os-greeter
[ ] lightspark
[ ] logstalgia
[ ] luastatus
[ ] maildrop
[ ] megacmd
[ ] memtier-benchmark
[ ] min
[ ] miraclecast
[ ] mkbootimage
[ ] modsecurity_standalone
[ ] mosdepth
[ ] mpfr
[ ] mutt
[ ] mydumper
[ ] neko
[ ] neocomp
[ ] ngrep
[ ] nim-2_2
[ ] nim-unwrapped-2_2
[ ] nimmm
[ ] nnn
[ ] nrpl
[ ] omxplayer
[ ] oobicpl
[ ] opencollada
[ ] openscap
[ ] pnmixer
[ ] poke
[ ] polybar
[ ] pplatex
[ ] prboom-plus
[ ] proxysql
[ ] rcon
[ ] rdup
[ ] renderdoc
[ ] rewritefs
[ ] root5
[ ] root
[ ] rpm-ostree
[ ] rspamd
[ ] serd
[ ] shadowsocks-libev
[ ] silver-searcher
[ ] simh
[ ] slang
[ ] smuview
[ ] sngrep
[ ] sniproxy
[ ] snort
[ ] solvespace
[ ] sonarlint-ls
[ ] sratom
[ ] swig3
[ ] swig
[ ] syslogng
[ ] taterclient-ddnet
[ ] ted
[ ] tenacity
[ ] thc-hydra
[ ] the-foundation
[ ] tintin
[ ] tiscamera
[ ] touchegg
[ ] trafficserver
[ ] transmission_3
[ ] ucg
[ ] ultrastardx
[ ] uwsgi
[ ] vectorscan
[ ] vimpc
[ ] wget
[ ] whatsapp-for-linux
[ ] xastir
[ ] xautoclick
[ ] xneur
[ ] yara
[ ] yoshimi
[ ] zoneminder

This is probably going to be much harder than expected.

authors: SuperSandro2000 emilazy pluiedev


text:
Vulnerability roundup 71: qemu-4.0.0: 2 advisories

search, files

[ ] CVE-2019-12928 (nixos-unstable)
[ ] CVE-2019-12929 (nixos-unstable)

Scanned versions: nixos-unstable: 73392e79aa6. May contain false positives.

Both are still being disputed.

CVE-2019-12928: Disputed, “QEMU's -qmp interface is meant to be used by trusted users.”
CVE-2019-12929: Disputed, “QEMU's -qmp interface is meant to be used by trusted users.”

Let's move on and concentrate on actionable items.

authors: ckauhaus mmahut omasanori


text:
Samba server cannot find users when using the valid users field.

ie.
The connection is rejected everytime I try to connect to the share with the valid user.
When I remove the valid users field, samba still asks for my username and password and it works. The user exist in the Linux environment, and have also been created with smbpasswd.
I pasted the samba log and the samba config.
Log
[2015/03/14 03:51:43.073527,  5] passdb/pdb_tdb.c:562(tdbsam_getsampwnam)
pdb_getsampwnam (TDB): error fetching database.
Key: USER_my_samba_user
[2015/03/14 03:51:43.073555,  4] smbd/sec_ctx.c:422(pop_sec_ctx)
pop_sec_ctx (0, 0) - sec_ctx_stack_ndx = 0
[2015/03/14 03:51:43.073572,  3] auth/check_samsec.c:399(check_sam_security)
check_sam_security: Couldn't find user 'my_samba_user' in passdb.
Config
services.samba = {
enable = true;
extraConfig = ''
  workgroup = WORKGROUP
  netbios name = desktop
  server string = %h
  comment = Samba

  log file = /var/log/samba/log.%m
  log level = 10
  max log size = 50000
  security = user
  client lanman auth = yes

  [samba_share]
  comment = samba private share
  valid users = my_samba_user
  create mask = 770
  path = /path/to/share
  guest ok = no
  read only = no
  public = no
  browsable = yes
'';

};

(triage) what’s the status?

authors: Profpatsch mtetreault


text:
alacritty reports strange error message on startup (unstable)

Describe the bug
Alacritty starts with this error message:
[2019-09-15 19:05] [WARN] Config window.start_maximized is deprecated; please use window.startup_mode instead
[2019-09-15 19:05] [WARN] Config render_timer is deprecated; please use debug.render_timer instead
[2019-09-15 19:05] [WARN] Config persistent_logging is deprecated; please use debug.persistent_logging instead

Metadata

system: "x86_64-linux"
host os: Linux 5.2.13, NixOS, 19.09pre192418.e19054ab3cd (Loris)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.3
channels(root): "nixos-19.09pre192418.e19054ab3cd, nixpkgs-20.03pre193019.a26445a2ddf"
channels(earendil): ""
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute: alacritty

Hi @gregor-alexandru
Don't worry, that messages are warning about deprecated variables in the configuration file
You can check that changes in the release changelog here: https://github.com/jwilm/alacritty/releases/tag/v0.3.3
And you can use the configuration file from the official repository as reference to do the changes https://github.com/jwilm/alacritty/blob/v0.3.3/alacritty.yml
Don't hesitate to ask if you find any kind of problem

When you update a program with a configuration file the default behaviour is update the file manually manually according to the updates.
But when you install that program from zero, of course, the last configuration file is installed.

Thanks a lot!

authors: gregor-alexandru mimame


text:
eagle package broken

Describe the bug
Eagle does not start anymore. When starting it from the command line I get the following message:
$ eagle
qt.qpa.plugin: Could not find the Qt platform plugin "xcb" in ""
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Aborted (core dumped)

To Reproduce
Steps to reproduce the behavior:

Install eagle
Start it by calling eagle

Expected behavior
Instead of getting an error message on the console, I'd expect the software to show a graphical window.
Metadata

system: "x86_64-linux"
host os: Linux 4.19.79, NixOS, 19.09.809.5000b1478a1 (Loris)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.3
channels(root): "nixos-19.09.809.5000b1478a1, unstable-19.09pre192418.e19054ab3cd"
channels(matthias): ""
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

Maintainer information:
attribute: [ eagle ]
module:

cc #65399

I noted this as well #71549

CC maintainer @rittelle.

it has to do with the qt wrapping, and i keep forgetting the best practices

I tried that, but it needs some non-qt libraries, and felt like i was wasting too much time on it, so i moved on

Hmm, I'll try to look into the issue this week.

I think this should fix it:
diff --git a/pkgs/applications/science/electronics/eagle/eagle.nix b/pkgs/applications/science/electronics/eagle/eagle.nix
index 7789f4cf8ba..a0eec53ce0b 100644
--- a/pkgs/applications/science/electronics/eagle/eagle.nix
+++ b/pkgs/applications/science/electronics/eagle/eagle.nix
@@ -1,4 +1,4 @@
-{ stdenv, fetchurl, makeDesktopItem
+{ stdenv, fetchurl, makeDesktopItem, mkDerivation
 , libXrender, libXrandr, libXcursor, libX11, libXext, libXi, libxcb
  , libGL, glib, nss, nspr, expat, alsaLib
 , qtbase, qtdeclarative, qtsvg, qtlocation, qtwebchannel, qtwebengine
@@ -11,7 +11,7 @@ let
       qtbase qtdeclarative qtsvg qtlocation qtwebchannel qtwebengine
     ];
   in
-  stdenv.mkDerivation rec {
+  mkDerivation rec {
     pname = "eagle";
     version = "9.5.0";

It's probably going to be wrapped several times because of the old logic

How can I apply this patch locally? I tried to load eagle from nixos-unstable, but that patch isn't there yet.

Thanks for merging it :)

authors: bjornfor jonringer mawis rittelle veprbl


text:
bitlbee does not build

Describe the bug
Bitlbee does not build on master.
To Reproduce
Steps to reproduce the behavior:

nix-build --no-build-output -A bitlbee

these derivations will be built:
  /nix/store/2a69lfr8r6zh6d20nwvqyxcd6p9yii05-bitlbee-3.6.drv
building '/nix/store/2a69lfr8r6zh6d20nwvqyxcd6p9yii05-bitlbee-3.6.drv'...
builder for '/nix/store/2a69lfr8r6zh6d20nwvqyxcd6p9yii05-bitlbee-3.6.drv' failed with exit code 2; last 10 log lines:
              ^~~~~~~~~~~~~~~~~
  check_util.c:27:12: warning: 'test_strip_newlines' defined but not used [-Wunused-variable]
   START_TEST(test_strip_newlines)
              ^~~~~~~~~~~~~~~~~~~
  check_util.c:11:12: warning: 'test_strip_linefeed' defined but not used [-Wunused-variable]
   START_TEST(test_strip_linefeed){
              ^~~~~~~~~~~~~~~~~~~
  make[1]: *** [Makefile:27: check_util.o] Error 1
  make[1]: Leaving directory '/build/bitlbee-3.6/tests'
  make: *** [Makefile:65: check] Error 2
error: build of '/nix/store/2a69lfr8r6zh6d20nwvqyxcd6p9yii05-bitlbee-3.6.drv' failed

Expected behavior
The bitlbee derivation should build without errors.
Metadata

system: "x86_64-linux"
host os: Linux 5.3.11, NixOS, 20.03.git.6be20178f08 (Markhor)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.3.1
nixpkgs: 25fc378642e

Maintainer information:
attribute:
- bitlbee
- bitlbee-steam
- bitlbee-mastodon
- bitlbee-facebook
- bitlbee-discord
# a list of nixos modules affected by the problem
module:
- services/networking/bitlbee

@pSub

Bisecting pointed me to the following commit. It seems like START_TEST changed a bit and use without creating a block to contain the unit-test code stopped working.
738fdb49830feb3e0594c053970b1e08ab45ffb1 is the first bad commit
commit 738fdb49830feb3e0594c053970b1e08ab45ffb1
Author: R. RyanTM <ryantm-bot@ryantm.com>
Date:   Fri Nov 1 12:33:14 2019 -0700

    check: 0.12.0 -> 0.13.0

Looks like it was done in this commit in libcheck: https://github.com/libcheck/check/commit/3987c1d906ee68e0a6a5fd7888d88e0873f914d9

authors: d-goldin terlar


text:
NixOS evaluation speed regression

Describe the bug
NixOS evaluation has gotten ~2x slower since 18.09.
To Reproduce
$ command time nix-instantiate nixos/release-combined.nix -A nixos.tests.misc.x86_64-linux --dry-run

on my system (Ryzen 3700X) takes ~1.7s on 18.09, but ~3.2s on master. And for historical perspective, it takes 0.4s on 14.04.
Also, memory usage went from 113 MiB max resident in 14.04, to 395 MiB in 18.09, and 642 MiB on master. (This is with GC_INITIAL_HEAP_SIZE=1m.)
Edit: original numbers for master were inflated by the use of cleanSource, which adds about 2 seconds to evaluation time (3182fbdeaae38dd20c1420a23a2c5f99566f280f). But that didn't affect Hydra.

Maybe it's time to revisit https://github.com/NixOS/rfcs/pull/22.

I'm hopeful that Flakes will make 22/(something like 22) an easy, obvious choice for growth for 20.09.

Flakes help with out-of-tree modules, but they're not necessary for modules that are in Nixpkgs but not in module-list.nix. Those can be imported using imports = [ (pkgs.path + "/nixos/modules/.../bla.nix") ].

Yeah,  think we could create a way for people to contribute modules somewhere organized by the community and fetched via flakes -- instead of inclusion in to NixOS. One subtlety of my previous comment I want to point out is that I don't think we can make such changes for 20.03.

Related is https://github.com/NixOS/nixpkgs/issues/57477

I've written down my thoughts in NixOS always imports all modules.
It's a low tech solution, which makes it viable. Also with flakes we'll need the same transformation to happen anyway.

Still a problem

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/slow-nixos-rebuild/48059/7

authors: Infinisil edolstra grahamc infinisil nixos-discourse roberth


text:
type_traits not found

With the hopes that someone possibly running into this issue maybe being able to find something; I'm leaving a note here (most google results are about reinstalling stuff and don't drill into the underlying issue):
If you're trying to parse qt headers with clang similar to:
NIX_DEBUG=1 clang -xc++ -std=c++11 -stdlib=libc++ -nostdinc++ -I $(nix-build --no-out-link '<nixpkgs>' -A llvmPackages.libcxx)/include/c++/v1/ -I qtheaders/include/ -fsyntax-only qtheaders/include/QtWidgets/QPushButton -v

If you get errors like
qtheaders/include/QtCore/qglobal.h:45:12: fatal error: 'type_traits' file not found

-- the reason is because you dont have the libcxx includes in your search path (which type_traits[1] is a part of, and not type_traits.h which is in includes/llvm/Support).
This I have half kludged in with the above command (there's probably a more direct fix for this) via https://libcxx.llvm.org/docs/UsingLibcxx.html
[1] https://en.cppreference.com/w/cpp/header/type_traits

NIX_DEBUG=1 clang -xc++ -std=c++11 -stdlib=libc++ -nostdinc++ -I $(nix-build --no-out-link '<nixpkgs>' -A llvmPackages.libcxx)/include/c++/v1/ -I qtheaders/include/ -fsyntax-only qtheaders/include/QtWidgets/QPushButton -v

Hi, I still got this error, when I tried to compile smokeqt from https://github.com/commonqt/commonqt5/,
this is my mkshell.nix https://github.com/prehonor/nixscript/blob/master/project/qt5env.nix
this is log :
[  0%] Generating smokedata.cpp, x_1.cpp, x_2.cpp, x_3.cpp, x_4.cpp, x_5.cpp, x_6.cpp, x_7.cpp, x_8.cpp, x_9.cpp, x_10.cpp, x_11.cpp, x_12.cpp, x_13.cpp, x_14.cpp, x_15.cpp, x_16.cpp, x_17.cpp, x_18.cpp, x_19.cpp, x_20.cpp
using generator "/home/prehonor/.local/bin/../lib/smokegen/generator_smoke.so"
didn't find file "/home/prehonor/CLionProjects/smokeqt/build/qtdefines"
parsing "/home/prehonor/CLionProjects/smokeqt/qtcore/qtcore_includes.h"
In file included from /home/prehonor/CLionProjects/smokeqt/qtcore/qtcore_includes.h:1:
In file included from /nix/store/q2s73wjkn5shgn2swp1gwibvzwipnlyi-qtbase-5.15.3-dev/include/QtCore/QtCore:4:
/nix/store/q2s73wjkn5shgn2swp1gwibvzwipnlyi-qtbase-5.15.3-dev/include/QtCore/qglobal.h:45:12: fatal error: 'type_traits' file not found
include <type_traits>
       ^~~~~~~~~~~~~

1 error generated.
make[2]: *** [qtcore/CMakeFiles/smokeqtcore.dir/build.make:75: qtcore/smokedata.cpp] Error 1
make[1]: *** [CMakeFiles/Makefile2:259: qtcore/CMakeFiles/smokeqtcore.dir/all] Error 2
make: *** [Makefile:136: all] Error 2

authors: deliciouslytyped prehonor


text:
nixos-rebuild wrongly(?) thinks systemd-boot is "not installed in ESP"

Describe the bug
For years, I think as long as I've been using NixOS, I've been using systemd-boot, but, recently, seeming starting circa 2020-06-20 according to the nixos-upgrade.service logs, nixos-rebuild has begun complaining, seemingly on each rebuild, that "systemd-boot [is] not installed in ESP" and it "could not find any previously installed systemd-boot". For example, here's the output of nixos-rebuild switch when there's nothing to rebuild:
$ nixos-rebuild --keep-going switch --upgrade
unpacking channels...
building Nix...
building the system configuration...
systemd-boot not installed in ESP.
could not find any previously installed systemd-boot
activating the configuration...
setting up /etc...
[...]

Here are the files in my EFI System Partition, mounted at /boot:
$ find /boot -type f
/boot/EFI/gummiboot/gummibootx64.efi
/boot/EFI/Boot/BOOTX64.EFI
/boot/EFI/nixos/h3nmpipd7rsip3ni1xk1fpxcizb2nrrq-linux-5.4.46-bzImage.efi
/boot/EFI/nixos/4izqilbfch08d9i4sxh33av39chngg1p-initrd-linux-5.4.46-initrd.efi
/boot/EFI/nixos/ka3ddjw9w5hj0d5qdxwx1lnvv1fhx24h-linux-5.4.46-bzImage.efi
/boot/EFI/nixos/xxz0bb66r4gyjv8nl1zcpibbips1dxjx-initrd-linux-5.4.46-initrd.efi
/boot/EFI/nixos/kyn2y7h8001r8a96w3v0ygp28d4d4hf8-initrd-linux-5.4.46-initrd.efi
/boot/EFI/nixos/m88lhs7igr1qyy1v2pzz0zrcs2ps0j2x-linux-5.4.47-bzImage.efi
/boot/EFI/nixos/bai3l9b0kxdpmmkrhnagpzvqzrnmvm98-initrd-linux-5.4.47-initrd.efi
/boot/EFI/nixos/7ysn9377x9ac4s9605gh47lwv3cjwhl0-linux-5.4.49-bzImage.efi
/boot/EFI/nixos/2fz4c3vr9is9pnrnzx7rf1c97q6zhgr7-initrd-linux-5.4.49-initrd.efi
/boot/EFI/nixos/660pcsfpa3jwwhcc92jf46sbdrva8css-linux-5.4.50-bzImage.efi
/boot/EFI/nixos/5apilnxgvbq07zcwah174b99m0xzs7al-initrd-linux-5.4.50-initrd.efi
/boot/EFI/nixos/9b6mx7cykl27yfilxgl32dn26m67jarc-linux-5.4.51-bzImage.efi
/boot/EFI/nixos/57x08bza5vq3s68w5ydrr9bh10idqhgd-initrd-linux-5.4.51-initrd.efi
/boot/EFI/nixos/iw1cvzqf2pmxhz6kqssx9j1q33fazibf-linux-5.4.51-bzImage.efi
/boot/EFI/nixos/0z0w74n2157nfp6fchbs82425xz783lq-initrd-linux-5.4.51-initrd.efi
/boot/loader/entries/nixos-generation-860.conf
/boot/loader/entries/nixos-generation-861.conf
/boot/loader/entries/nixos-generation-862.conf
/boot/loader/entries/nixos-generation-863.conf
/boot/loader/entries/nixos-generation-864.conf
/boot/loader/entries/nixos-generation-865.conf
/boot/loader/entries/nixos-generation-866.conf
/boot/loader/entries/nixos-generation-867.conf
/boot/loader/entries/nixos-generation-868.conf
/boot/loader/entries/nixos-generation-869.conf
/boot/loader/entries/nixos-generation-870.conf
/boot/loader/entries/nixos-generation-871.conf
/boot/loader/entries/nixos-generation-872.conf
/boot/loader/entries/nixos-generation-873.conf
/boot/loader/entries/nixos-generation-874.conf
/boot/loader/entries/nixos-generation-875.conf
/boot/loader/loader.conf

My uptime is less than two weeks, so this system has booted successfully since nixos-rebuild started thinking systemd-boot is not installed, so I would guess that systemd-boot is installed despite nixos-rebuild's complaints.
Expected behavior
nixos-rebuild, if it wants to find an installation of systemd-boot, finds the one that I thought I've been using for years.
Notify maintainers
@danielfullmer I guess (from nixos/tests/systemd-boot.nix, as nixos/modules/system/boot/loader/systemd-boot/systemd-boot.nix has no listed maintainers)
Metadata

system: "x86_64-linux"
host os: Linux 5.4.49-hardened, NixOS, 20.09pre234242.c71518e75bf (Nightingale)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.3.7
channels(root): "nixos-20.09pre234242.c71518e75bf"
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute: [] # I guess?
# a list of nixos modules affected by the problem
module: [boot.loader.systemd-boot] # I guess?

So the change that happened in June was https://github.com/NixOS/nixpkgs/pull/90386 which is intended to address this issue https://github.com/NixOS/nixpkgs/issues/86422
NixOS will now automatically update systemd-boot, but only does so if it detects that systemd-boot has previously been installed, and is currently an older version.  It looks like you have gummiboot in your /boot, which is a quite old version (before it was renamed to systemd-boot).  Unfortunately the name change means that bootctl status doesn't detect the fact that you have gummiboot/systemd-boot installed.  In it's current state, you just aren't getting the systemd-boot updates properly, but it shouldn't cause any other issues.
You should be able to just run bootctl install once to force reinstallation of systemd-boot.

You should be able to just run bootctl install once to force reinstallation of systemd-boot.

Thanks, I did that and now nixos-rebuild no longer complains that systemd-boot isn't installed.  Would you recommend additionally removing the old gummiboot?

Yeah, after verifying that it boots correctly with the newly installed /boot/EFI/systemd/systemd-bootx64.efi, it should be fine to remove the old gummiboot.

Let's close this, we probably shouldn't automatically try to remove gummiboot, and apart from that, there's not much else doable here.

It might be worth putting a note in the manual about it. But it has a distinct error message and this issue shows up in GitHub search just fine.

For anyone still having this issue, I was able to fix it by not following the manual's efi setup. I used the NixOS kde install  process to erase and partition my ssd. Then removed all the settings I didn't want from the configuration.nix .
After the installer finished I was able to use nixos-rebuild or nixos-install properly.

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/nixos-hangs-on-boot/26376/5

Just for anyone finding this after manually installing any firmware across systems, you have to remount /boot or you will get this error.

authors: 8573 MDNLss Mathnerd314 danielfullmer flokli martin-braun nixos-discourse


text:
nixos/swap: refactor, add randomEncryption option

This patch adds support for randomEncryption option for swap devices. When enabled, before activation swap device is formatted as a LUKS partition with a random key and mounted. Because this happens essentially on each boot (and LUKS headers are wiped just after opening), this breaks hibernate/resume capability, but gives you a guarantee that after shutdown there would be no way for anyone to get contents of your swap device from that session, ever.
I've also took an opportunity to refactor swapDevices option to use the new types.submodule.
Note: fixed "secretkey" passphrase should be good, because a passphrase is used to decrypt a header where an actual encryption key (random, generated during format) is contained. Those headers are wiped right after the device is opened. Please, correct me if I have understood something wrong!
cc @edolstra

I've been running this on machines without swap, with unencrypted (using hibernation) and encrypted one with no issues. Also after some reading [1] it looks a fixed passphrase should indeed be enough. I plan to merge this in several days if there would be no issues.
1: https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5-security-aspects

source: gharchive/pull-request


text:
nixos/mysql: properly configure mariadb for galera recovery

Motivation for this change
Currently our galera recovery is way too manual and can put your database in an inconsistent state if you're not very careful :scream:
This is roughly the same approach as recommended by upstream, with a minor tweak that seems like a good idea (given we support both mariadb and mysql packages).
Things done

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

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[x] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

@GrahamcOfBorg test mariadb-galera-mariabackup mariadb-galera-rsync
@GrahamcOfBorg test mysql mysql-autobackup mysql-backup mysql-replication

@aanderse don't need replace in file bin/galera_recovery? from:
eval ./bin/mysqld $cmdline_args --user=$user --wsrep_recover \

to full path
eval /nix/store/m5yy8nqbsjwj5khbwlnsfz7r3zlk9h8p-mariadb-server-10.5.8/bin/mysqld $cmdline_args --user=$user --wsrep_recover \

@Izorkin no, the script isn't meant to be called directly but instead referenced from a systemd service (or alternative):
VAR=$(cd ${cfg.package}/bin/..; ${cfg.package}/bin/galera_recovery);

The cd call first is what upstream (and other distros) ship.

Thanks @Izorkin!

authors: Izorkin aanderse


text:
mariadb-connector-c: 3.1.8 -> 3.1.12

Motivation for this change
Update mariadb-connector-c to 3.1.12
Things done

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

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Update PR.

@ofborg eval


text:
retroshare: drop

Motivation for this change
It was marked as broken in 2018.
Things done

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

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

There still seem to be people (e.g. @ehmry) interested in it #54213

I'm not actually interested in Retroshare, I was just commenting on an old issue.

authors: ajs124 dotlambda ehmry


text:
pcl: fix convex hull support

Motivation for this change
PCL requires a patch to be compatible with QHull 2020.2. The patch has been accepted upstream, but this commit uses a version of the patch from Conda which has been backported to 1.11.
Without this patch, the build still succeeds, but convex hull support is disabled.
Things done

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

[x] NixOS
[ ] macOS
[x] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Added a release notes entry if the change is major or breaking
[x] Fits CONTRIBUTING.md.

cc @viric

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

1 package built:

pcl


text:
getmail6: 6.16 -> 6.17

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for getmail6 is: "A program for retrieving mail"
meta.homepage for getmail6 is: "https://getmail6.org"
meta.changelog for getmail6 is: ""
Updates performed

Ran passthru.UpdateScript

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

/nix/store/m88wkgm78xyhn7rrncx8mnni5i6cpjg7-getmail6-6.17/bin/getmail passed the binary check.

/nix/store/m88wkgm78xyhn7rrncx8mnni5i6cpjg7-getmail6-6.17/bin/getmail-gmail-xoauth-tokens passed the binary check.

/nix/store/m88wkgm78xyhn7rrncx8mnni5i6cpjg7-getmail6-6.17/bin/getmail_fetch passed the binary check.

/nix/store/m88wkgm78xyhn7rrncx8mnni5i6cpjg7-getmail6-6.17/bin/getmail_maildir passed the binary check.

/nix/store/m88wkgm78xyhn7rrncx8mnni5i6cpjg7-getmail6-6.17/bin/getmail_mbox passed the binary check.

/nix/store/m88wkgm78xyhn7rrncx8mnni5i6cpjg7-getmail6-6.17/bin/getmails passed the binary check.

/nix/store/m88wkgm78xyhn7rrncx8mnni5i6cpjg7-getmail6-6.17/bin/.getmail-wrapped passed the binary check.

/nix/store/m88wkgm78xyhn7rrncx8mnni5i6cpjg7-getmail6-6.17/bin/.getmail-gmail-xoauth-tokens-wrapped passed the binary check.

/nix/store/m88wkgm78xyhn7rrncx8mnni5i6cpjg7-getmail6-6.17/bin/.getmail_fetch-wrapped passed the binary check.

/nix/store/m88wkgm78xyhn7rrncx8mnni5i6cpjg7-getmail6-6.17/bin/.getmail_maildir-wrapped passed the binary check.

/nix/store/m88wkgm78xyhn7rrncx8mnni5i6cpjg7-getmail6-6.17/bin/.getmail_mbox-wrapped passed the binary check.

10 of 11 passed binary check by having a zero exit code.

11 of 11 passed binary check by having the new version present in output.

found 6.17 with grep in /nix/store/m88wkgm78xyhn7rrncx8mnni5i6cpjg7-getmail6-6.17

found 6.17 in filename of file in /nix/store/m88wkgm78xyhn7rrncx8mnni5i6cpjg7-getmail6-6.17

directory tree listing: https://gist.github.com/c7a4482521504b956d46e0dd74f7e6f7

du listing: https://gist.github.com/d35c64e2faded939e2778708327e1ec0

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

4 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
1 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
getmail6

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/m88wkgm78xyhn7rrncx8mnni5i6cpjg7-getmail6-6.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 getmail6 https://github.com/r-ryantm/nixpkgs/archive/c1a7645601b7ad883f0de8cf3b12e73b51307930.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/m88wkgm78xyhn7rrncx8mnni5i6cpjg7-getmail6-6.17
ls -la /nix/store/m88wkgm78xyhn7rrncx8mnni5i6cpjg7-getmail6-6.17/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:

getmail6

Maintainer pings
cc @wahjava for testing.

superseded by #127478

authors: dotlambda r-ryantm


text:
liberfa: 1.7.1 -> 2.0.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/erfa/versions.
meta.description for liberfa is: "Essential Routines for Fundamental Astronomy"
meta.homepage for liberfa is: "https://github.com/liberfa/erfa"
meta.changelog for liberfa is: ""
Updates performed

Version 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

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 2.0.0 with grep in /nix/store/mvcmvnhb4m70009y9aqikyji4db5jb3g-erfa-2.0.0

found 2.0.0 in filename of file in /nix/store/mvcmvnhb4m70009y9aqikyji4db5jb3g-erfa-2.0.0

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

1 total rebuild path(s)

1 package rebuild(s)

0 x86_64-linux rebuild(s)
0 i686-linux rebuild(s)
0 x86_64-darwin rebuild(s)
0 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
liberfa

Instructions to test this update (click to expand)

Build yourself:
nix-build -A liberfa https://github.com/Kranzes/nixpkgs/archive/3dfa3779e7673d4f2e5476b5d60c955a506d4156.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/mvcmvnhb4m70009y9aqikyji4db5jb3g-erfa-2.0.0
ls -la /nix/store/mvcmvnhb4m70009y9aqikyji4db5jb3g-erfa-2.0.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.
nixpkgs-review took longer than 45m and timed out

Maintainer pings
cc @mir06 for testing.

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

14 packages failed to build:

python38Packages.aplpy
python38Packages.asdf
python38Packages.pyregion
python38Packages.pytest-astropy
python38Packages.reproject
python38Packages.spectral-cube
python38Packages.sunpy
python39Packages.aplpy
python39Packages.asdf
python39Packages.pyregion
python39Packages.pytest-astropy
python39Packages.reproject
python39Packages.spectral-cube
python39Packages.sunpy

17 packages built:

liberfa
python38Packages.astropy
python38Packages.astropy-healpix
python38Packages.astroquery
python38Packages.drms
python38Packages.pyavm
python38Packages.pyerfa
python38Packages.pytest-astropy-header
python38Packages.radio_beam
python39Packages.astropy
python39Packages.astropy-healpix
python39Packages.astroquery
python39Packages.drms
python39Packages.pyavm
python39Packages.pyerfa
python39Packages.pytest-astropy-header
python39Packages.radio_beam

Result of nixpkgs-review pr 133888 at 3dfa3779 run on aarch64-linux 1

14 packages failed to build:

python38Packages.aplpy
python38Packages.asdf
python38Packages.pyregion
python38Packages.pytest-astropy
python38Packages.reproject
python38Packages.spectral-cube
python38Packages.sunpy
python39Packages.aplpy
python39Packages.asdf
python39Packages.pyregion
python39Packages.pytest-astropy
python39Packages.reproject
python39Packages.spectral-cube
python39Packages.sunpy

16 packages built successfully:

python38Packages.astropy
python38Packages.astropy-healpix
python38Packages.astroquery
python38Packages.drms
python38Packages.pyavm
python38Packages.pyerfa
python38Packages.pytest-astropy-header
python38Packages.radio_beam
python39Packages.astropy
python39Packages.astropy-healpix
python39Packages.astroquery
python39Packages.drms
python39Packages.pyavm
python39Packages.pyerfa
python39Packages.pytest-astropy-header
python39Packages.radio_beam

Note that build failures may predate this PR, and could be nondeterministic or hardware dependent.
Please exercise your independent judgement. Does something look off? Please file an issue or reach out on IRC.

This is a semi-automatic executed nixpkgs-review with nixpkgs-review-checks extension. It is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
Result of nixpkgs-review pr 133888 run on x86_64-linux 1

14 packages failed to build and already failed to build on hydra master:

python38Packages.aplpy: log was empty
python38Packages.asdf: log was empty
python38Packages.pyregion: log was empty
python38Packages.pytest-astropy: log was empty
python38Packages.reproject: log was empty
python38Packages.spectral-cube: log was empty
python38Packages.sunpy: log was empty
python39Packages.aplpy: log was empty
python39Packages.asdf: log was empty
python39Packages.pyregion: log was empty
python39Packages.pytest-astropy: log was empty
python39Packages.reproject: log was empty
python39Packages.spectral-cube: log was empty
python39Packages.sunpy: log was empty

7 packages failed to build and are new build failures:

python39Packages.astropy: log was empty
python39Packages.astropy-healpix: log was empty
python39Packages.astroquery: log was empty
python39Packages.drms: log was empty
python39Packages.pyavm: log was empty
python39Packages.pytest-astropy-header: log was empty
python39Packages.radio_beam: log was empty

10 packages built:

liberfa
python38Packages.astropy
python38Packages.astropy-healpix
python38Packages.astroquery
python38Packages.drms
python38Packages.pyavm
python38Packages.pyerfa
python38Packages.pytest-astropy-header
python38Packages.radio_beam
python39Packages.pyerfa

This is a semi-automatic executed nixpkgs-review with nixpkgs-review-checks extension. It is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
Result of nixpkgs-review pr 133888 run on x86_64-linux 1

14 packages failed to build and already failed to build on hydra master:

python38Packages.aplpy: log was empty
python38Packages.asdf: log was empty
python38Packages.pyregion: log was empty
python38Packages.pytest-astropy: log was empty
python38Packages.reproject: log was empty
python38Packages.spectral-cube: log was empty
python38Packages.sunpy: log was empty
python39Packages.aplpy: log was empty
python39Packages.asdf: log was empty
python39Packages.pyregion: log was empty
python39Packages.pytest-astropy: log was empty
python39Packages.reproject: log was empty
python39Packages.spectral-cube: log was empty
python39Packages.sunpy: log was empty

17 packages built:

liberfa
python38Packages.astropy
python38Packages.astropy-healpix
python38Packages.astroquery
python38Packages.drms
python38Packages.pyavm
python38Packages.pyerfa
python38Packages.pytest-astropy-header
python38Packages.radio_beam
python39Packages.astropy
python39Packages.astropy-healpix
python39Packages.astroquery
python39Packages.drms
python39Packages.pyavm
python39Packages.pyerfa
python39Packages.pytest-astropy-header
python39Packages.radio_beam

authors: Artturin Kranzes SuperSandro2000 r-rmcgibbo


text:
zoxide: 0.7.3 -> 0.7.4

also disable a time-sensitive test which is annoying on a loaded
machine
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 via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.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.

A bit strange that this went to staging...

It does not build with rust 1.53, it needs 1.54 which is only on staging.

Ah, that makes sense. Thanks for the clarification.


text:
python3Packages.catalogue: 2.0.4 -> 2.0.6

Motivation for this change
Update to latest upstream release 2.0.6
Change log: https://github.com/explosion/catalogue/releases/tag/v2.0.6
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 via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.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 135596 run on x86_64-linux 1

6 packages marked as broken and skipped:

python38Packages.spacy
python38Packages.spacy-transformers
python38Packages.textacy
python39Packages.spacy
python39Packages.spacy-transformers
python39Packages.textacy

8 packages built:

python38Packages.catalogue
python38Packages.spacy-pkuseg
python38Packages.srsly
python38Packages.thinc
python39Packages.catalogue
python39Packages.spacy-pkuseg
python39Packages.srsly
python39Packages.thinc


text:
tfsec: 0.58.4 -> 0.58.5

Motivation for this change
Update to latest upstream release 0.58.5
Change log: https://github.com/aquasecurity/tfsec/releases/tag/v0.58.5
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 via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.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 136019 run on x86_64-linux 1

1 package built:

tfsec


text:
libofx: 0.10.2 -> 0.10.3

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/LibOFX/libofx/releases.
meta.description for libofx is: "Opensource implementation of the Open Financial eXchange specification"
meta.homepage for libofx is: "http://libofx.sourceforge.net/"
meta.changelog for libofx is: ""
Updates performed

Version 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
/nix/store/c3d4q4qzdfirzjyjjg62pi4a84hqz6dd-libofx-0.10.3/bin/ofxdump passed the binary check.
/nix/store/c3d4q4qzdfirzjyjjg62pi4a84hqz6dd-libofx-0.10.3/bin/ofx2qif passed the binary check.
2 of 2 passed binary check by having a zero exit code.
1 of 2 passed binary check by having the new version present in output.
found 0.10.3 with grep in /nix/store/c3d4q4qzdfirzjyjjg62pi4a84hqz6dd-libofx-0.10.3
found 0.10.3 in filename of file in /nix/store/c3d4q4qzdfirzjyjjg62pi4a84hqz6dd-libofx-0.10.3

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

7 total rebuild path(s)

6 package rebuild(s)

6 x86_64-linux rebuild(s)
0 i686-linux rebuild(s)
1 x86_64-darwin rebuild(s)
0 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
gnucash
grisbi
homebank
kmymoney
libofx
skrooge

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/c3d4q4qzdfirzjyjjg62pi4a84hqz6dd-libofx-0.10.3 \
  --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 libofx https://github.com/r-ryantm/nixpkgs/archive/cbfd92d51c87f11e98b00513e96b81db8ce103a5.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/c3d4q4qzdfirzjyjjg62pi4a84hqz6dd-libofx-0.10.3
ls -la /nix/store/c3d4q4qzdfirzjyjjg62pi4a84hqz6dd-libofx-0.10.3/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

6 packages built:

gnucash
grisbi
homebank
kmymoney
libofx
skrooge

Maintainer pings

fix gmt offset seconds
fix various typos in source code
win32 build failure

https://github.com/libofx/libofx/commit/70ae1b44fd4ea00175ae9fa5a6abd12243534fc2 is the only change that needs review and it looks good to me.
Give me some time to check the build results.


text:
checkSSLCert: 1.80.0 -> 2.12.0

Things done
Updated checkSSLCert to latest release.

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/)
21.11 Release Notes (or backporting 21.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.

Updated to 2.19.0 in #155043, still thanks for your contribution!

Thanks for the heads-up!


text:
spotify: 1.0.27 -> 1.0.28

Again, the binaries on master are gone from upstream. Tested and works locally on NixOS.
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
[ ] 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.

Thanks!

authors: bradediger sheenobu


text:
firejail: fix examples

pkgs is not always global in the nix configuration file
Motivation for this change
In a relatively default configuration.nix file, the snippets found in configuration.nix man page are not working because pkgs is not "global".
error: undefined variable 'lib'
       at /etc/nixos/configuration.nix:25:27:
           24|       firefox = {
           25|           executable = "${lib.getBin pkgs.firefox}/bin/firefox";
             |                           ^
           26|           profile = "${pkgs.firejail}/etc/firejail/firefox.profile";
       … while evaluating 'isFunction'

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

[ ] Fits CONTRIBUTING.md.

the lib in these examples shouldn't be taken from pkgs but from a module argument; the module system also passes lib as an argument to each module. the firejail module (and indeed most documentation) assumes that modules are declared with at the config, options, pkgs, lib arguments. changing a few occurences here isn't a great solution, we should probably try to be more clear about which arguments documentation expects in modules instead.

Thanks for the explanations. I'm closing the PR.

authors: pennae rapenne-s


text:
python3Packages.requests: remove unneded trustme dependency

This removes rust from the build closure

Motivation for this change
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[x] 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.

@GrahamcOfBorg build python3Packages.requests

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

1 package built:

python3Packages.requests

authors: siraben veprbl


text:
python310Packages.pyathena: 2.4.1 -> 2.5.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python310Packages.pyathena is: "Python DB API 2.0 (PEP 249) client for Amazon Athena"
meta.homepage for python310Packages.pyathena is: "https://github.com/laughingman7743/PyAthena/"
meta.changelog for python310Packages.pyathena 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

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 2.5.0 with grep in /nix/store/qkq1d06ixg8sx3k5k28lldmnm45sf5fr-python3.10-pyathena-2.5.0

found 2.5.0 in filename of file in /nix/store/qkq1d06ixg8sx3k5k28lldmnm45sf5fr-python3.10-pyathena-2.5.0

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

4 total rebuild path(s)

2 package rebuild(s)

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

First fifty rebuilds by attrpath
python310Packages.pyathena
python39Packages.pyathena

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/qkq1d06ixg8sx3k5k28lldmnm45sf5fr-python3.10-pyathena-2.5.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.pyathena https://github.com/r-ryantm/nixpkgs/archive/29d9b431289229cb75da5fd7378391998644c839.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/qkq1d06ixg8sx3k5k28lldmnm45sf5fr-python3.10-pyathena-2.5.0
ls -la /nix/store/qkq1d06ixg8sx3k5k28lldmnm45sf5fr-python3.10-pyathena-2.5.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

2 packages built:

python310Packages.pyathena
python39Packages.pyathena

Maintainer pings
cc @turion for testing.

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

2 packages built:

python310Packages.pyathena
python39Packages.pyathena

authors: fabaff r-ryantm


text:
nixos/jenkinsSlave: install java

Description of changes

Generally, when creating a Jenkins agent, it will run a set of steps after obtaining the SSH access to the server. One of these steps is verifying if Java is installed through java -fullversion. Currently, if you enable the services.jenkinsSlave option, it won't work as it does not have Java installed.
This change will install the current JDK and will allow the user to specify which package to use.
Added a line on the test to verify the slave has Java installed and this is the snippet that indicates it works:
slave: must succeed: java -fullversion
slave # openjdk full version "17.0.1+12-nixos"
(finished: must succeed: java -fullversion, in 0.66 seconds)

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

[ ] Fits CONTRIBUTING.md.

@bjornfor Ready, I tried to summarize the PR comment into the commit. Let me know if it looks good.


text:
python310Packages.phonopy: 2.13.1 -> 2.14.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python310Packages.phonopy is: "A package for phonon calculations at harmonic and quasi-harmonic levels"
meta.homepage for python310Packages.phonopy is: "https://atztogo.github.io/phonopy/"
meta.changelog for python310Packages.phonopy 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
Warning: no invocation of /nix/store/y3y1mwkk042lvi6lp5fw5px32r37a130-python3.10-phonopy-2.14.0/bin/phonopy-vasp-born had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/y3y1mwkk042lvi6lp5fw5px32r37a130-python3.10-phonopy-2.14.0/bin/.phonopy-gruneisenplot-wrapped had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/y3y1mwkk042lvi6lp5fw5px32r37a130-python3.10-phonopy-2.14.0/bin/.phonopy-load-wrapped had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/y3y1mwkk042lvi6lp5fw5px32r37a130-python3.10-phonopy-2.14.0/bin/phonopy-qha had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/y3y1mwkk042lvi6lp5fw5px32r37a130-python3.10-phonopy-2.14.0/bin/phonopy-gruneisenplot had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/y3y1mwkk042lvi6lp5fw5px32r37a130-python3.10-phonopy-2.14.0/bin/phonopy had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/y3y1mwkk042lvi6lp5fw5px32r37a130-python3.10-phonopy-2.14.0/bin/phonopy-calc-convert had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/y3y1mwkk042lvi6lp5fw5px32r37a130-python3.10-phonopy-2.14.0/bin/.phonopy-vasp-efe-wrapped had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/y3y1mwkk042lvi6lp5fw5px32r37a130-python3.10-phonopy-2.14.0/bin/phonopy-tdplot had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/y3y1mwkk042lvi6lp5fw5px32r37a130-python3.10-phonopy-2.14.0/bin/.phonopy-vasp-born-wrapped had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/y3y1mwkk042lvi6lp5fw5px32r37a130-python3.10-phonopy-2.14.0/bin/phonopy-pdosplot had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/y3y1mwkk042lvi6lp5fw5px32r37a130-python3.10-phonopy-2.14.0/bin/.phonopy-wrapped had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/y3y1mwkk042lvi6lp5fw5px32r37a130-python3.10-phonopy-2.14.0/bin/.phonopy-calc-convert-wrapped had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/y3y1mwkk042lvi6lp5fw5px32r37a130-python3.10-phonopy-2.14.0/bin/.phonopy-pdosplot-wrapped had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/y3y1mwkk042lvi6lp5fw5px32r37a130-python3.10-phonopy-2.14.0/bin/.phonopy-bandplot-wrapped had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/y3y1mwkk042lvi6lp5fw5px32r37a130-python3.10-phonopy-2.14.0/bin/phonopy-bandplot had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/y3y1mwkk042lvi6lp5fw5px32r37a130-python3.10-phonopy-2.14.0/bin/phonopy-gruneisen had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/y3y1mwkk042lvi6lp5fw5px32r37a130-python3.10-phonopy-2.14.0/bin/phonopy-vasp-efe had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/y3y1mwkk042lvi6lp5fw5px32r37a130-python3.10-phonopy-2.14.0/bin/.phonopy-qha-wrapped had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/y3y1mwkk042lvi6lp5fw5px32r37a130-python3.10-phonopy-2.14.0/bin/.phonopy-propplot-wrapped had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/y3y1mwkk042lvi6lp5fw5px32r37a130-python3.10-phonopy-2.14.0/bin/.phonopy-tdplot-wrapped had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/y3y1mwkk042lvi6lp5fw5px32r37a130-python3.10-phonopy-2.14.0/bin/phonopy-load had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/y3y1mwkk042lvi6lp5fw5px32r37a130-python3.10-phonopy-2.14.0/bin/phonopy-propplot had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/y3y1mwkk042lvi6lp5fw5px32r37a130-python3.10-phonopy-2.14.0/bin/.phonopy-crystal-born-wrapped had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/y3y1mwkk042lvi6lp5fw5px32r37a130-python3.10-phonopy-2.14.0/bin/.phonopy-gruneisen-wrapped had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/y3y1mwkk042lvi6lp5fw5px32r37a130-python3.10-phonopy-2.14.0/bin/phonopy-crystal-born had a zero exit code or showed the expected version
0 of 26 passed binary check by having a zero exit code.
0 of 26 passed binary check by having the new version present in output.
found 2.14.0 with grep in /nix/store/y3y1mwkk042lvi6lp5fw5px32r37a130-python3.10-phonopy-2.14.0
found 2.14.0 in filename of file in /nix/store/y3y1mwkk042lvi6lp5fw5px32r37a130-python3.10-phonopy-2.14.0

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

12 total rebuild path(s)

6 package rebuild(s)

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

First fifty rebuilds by attrpath
python310Packages.atomman
python310Packages.phonopy
python310Packages.sumo
python39Packages.atomman
python39Packages.phonopy
python39Packages.sumo

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/y3y1mwkk042lvi6lp5fw5px32r37a130-python3.10-phonopy-2.14.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.phonopy https://github.com/r-ryantm/nixpkgs/archive/4bb87758c8d3cb72efe1221078e16790d85ff732.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/y3y1mwkk042lvi6lp5fw5px32r37a130-python3.10-phonopy-2.14.0
ls -la /nix/store/y3y1mwkk042lvi6lp5fw5px32r37a130-python3.10-phonopy-2.14.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

2 packages failed to build:

python310Packages.atomman
python39Packages.atomman

4 packages built:

python310Packages.phonopy
python310Packages.sumo
python39Packages.phonopy
python39Packages.sumo

Maintainer pings
cc @PsyanticY for testing.

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

2 packages failed to build:

python310Packages.atomman
python39Packages.atomman

4 packages built:

python310Packages.phonopy
python310Packages.sumo
python39Packages.phonopy
python39Packages.sumo

Superseded by 7d1cfa2810f73288935602a42aee7f32c0d4da1f.

authors: WolfangAukang r-ryantm smancill


text:
tor-browser-bundle-bin: 11.0.14 -> 11.0.15

Description of changes
Upstream update: https://blog.torproject.org/new-release-tor-browser-11015/

Update Tor to 0.4.7.8

Please also backport to 22.05.
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.

Ping past reviewers: @FliegendeWurst @lourkeur @rapenne-s

Result of nixpkgs-review run on x86_64-linux 1

1 package built:

tor-browser-bundle-bin


text:
steampipe: 0.13.4 -> 0.15.0

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
[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.

Please dot the go version override in top-level the next time so it can be easily dropped with when it is no longer required.


text:
librewolf: 102.0.1-1 -> 103.0-3

Description of changes
Update LIbrewolf to 103.0-3.
NixOS tests pass. Manual browsing tests pass on NixOS x86_64.
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.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.

The 103.0-3 patch update fixed a problem with the uBlock origin icon not appearing. @mweinelt I think this is ready to be merged.