text:
Add possibility to pass allowedSlaveAttributes

Hello @felixgborrego and @sbz!
With this PR we wanted to add the possibility to pass allowedSlaveAttributes to the Singularity Request.
Quite recently we not only needed the ability to pin certain requests to certain nodes, but also reserve these specific nodes for the mentioned requests only, done via reserveSlaveWithAttributes  in Singularity.
While this works for requests that have requiredAttributes set, we also have requests that need to run on every mesos node, also on these reserved nodes. To make some requests run on every mesos node, done via SPREAD_ALL_SLAVES, we need the ability to pass allowedSlaveAttributes.
I've added this to the test case and hope you're fine with this change.
Best regards,
Tom
cc @relistan

@felixgborrego reserved attributes is a pretty nice feature that you guys might also take advantage of. It allows you to do what we once tried to do with Roles: you can carve off various bits of the cluster for special purposes. But this fix to nmesos is required if you want to also have requests with SPREAD_ALL_SLAVES because otherwise those jobs can't run on the reserved hosts.

Thanks, lgtm

@felixgborrego Would you be willing to merge/release? We owe you at least a couple of beers by now :) 🍻

Done!
brew update
brew upgrade nmesos-cli

nitro/nmesos/nmesos-cli 0.2.14 -> 0.2.15

Awesome. Thank you @felixgborrego!

Thanks @felixgborrego !

authors: felixgborrego patoms relistan

repo: Nitro/nmesos


text:
Create component Page not Found

Add route
when url is wrong landing to this page

Hey @dinithchanuka, thank you for creating this pull request! Have a wonderful day...

source: gharchive/pull-request

authors: Niweera dinithchanuka

repo: Niweera/cinesimile

license: MIT

license_type: permissive

license_source: github-api


text:
Docs make flake check fail

nix flake check is complaining about these lines:
https://github.com/NixNeovim/NixNeovim/blob/main/flake.nix#L53-L56
Says it is a function instead of an attr set, I might've introduced it inside of the augroups PR or the flake utils PR, I'm not sure...

Did you just run nix flake check? I just pulled main and got no errors.
Also, the docs packages should not be included in the checks

I was running nix flake check on the augroups PR

Then, you should have commented that on the PR. Please continue discussion there.
Ref: #66

source: gharchive/issue

authors: jalil-salame jooooscha

repo: NixNeovim/NixNeovim


text:
Failed to open fglrx_dri.so

After installing the AMD Catalyst driver (fglrx) in NixOS 15.09 by setting services.xserver.videoDrivers = [ "ati_unfree" ];, direct rendering is not enabled. Details are:
$ LIBGL_DEBUG=verbose glxinfo | grep direct
libGL: AtiGetClientDriverName: 15.20.3 fglrx (screen 0)
libGL error: OpenDriver: failed to open /usr/X11R6/lib64/modules/dri/fglrx_dri.so, error[/usr/X11R6/lib64/modules/dri/fglrx_dri.so: cannot open shared object file: No such file or directory]
libGL error: OpenDriver: failed to open /usr/lib64/dri/fglrx_dri.so, error[/usr/lib64/dri/fglrx_dri.so: cannot open shared object file: No such file or directory]
libGL error: OpenDriver: failed to open /run/opengl-driver/lib/dri/fglrx_dri.so, error[libstdc++.so.6: cannot open shared object file: No such file or directory]
libGL error: OpenDriver: failed to open /usr/lib/dri/fglrx_dri.so, error[/usr/lib/dri/fglrx_dri.so: cannot open shared object file: No such file or directory]
libGL error: OpenDriver: failed to open /usr/X11R6/lib32/modules/dri/fglrx_dri.so, error[/usr/X11R6/lib32/modules/dri/fglrx_dri.so: cannot open shared object file: No such file or directory]
libGL error: OpenDriver: failed to open /usr/lib32/dri/fglrx_dri.so, error[/usr/lib32/dri/fglrx_dri.so: cannot open shared object file: No such file or directory]
libGL error: dlopen fglrx_dri.so failed
direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose)

The AMD Catalyst Arch wiki section for this "failed to open fglrx_dri.so" error says to create symlinks for the missing requested paths, which I suppose might be a workaround, but really shouldn't Nix be taking care of this?
On the other hand, /run/opengl-driver/lib/dri/fglrx_dri.so does actually exist, so maybe the error is with finding libstdc++.so.6?

Pinging @nathanielbaxter, @jgeerds, @vcunat, and @offlinehacker for involvement in #3989 and #4185.
Could the issue be at https://github.com/NixOS/nixpkgs/blob/1a86bf8aae151c40747f4e47e791356ff0084e2b/nixos/modules/hardware/video/ati.nix#L22 where libPath is set?
Setting environment.extraInit = pkgs.lib.mkIf (videoDriver == "ati_unfree") "export LD_LIBRARY_PATH=${pkgs.gcc_multi.cc}/lib:${pkgs.gcc_multi.cc}/lib64:$LD_LIBRARY_PATH''; and creating the /usr/X11R6/lib64/modules/dri -> /run/opengl-driver/lib/dri symlink causes glxinfo to segfault but gets rid of the above errors.

I know little about the proprietary ATI drivers in particular. From what you write, there seem to be some ugly hacks done, perhaps prone to break. You can test ldd /run/opengl-driver/lib/dri/fglrx_dri.so to find if that file links correctly at least.

I suggest having a look at the driver package if you haven't already, more likely to be an issue there (where the ugly hacks are) than in the module.
I haven't used these drivers for over a year, so I'm unsure what state they're in at the moment, last update was made by @dfoxfranke

@vcunat
$ ldd /run/opengl-driver/lib/dri/fglrx_dri.so
	linux-vdso.so.1 (0x00007ffe240e1000)
	libstdc++.so.6 => not found
	libpthread.so.0 => /nix/store/npfsi1d9ka8zwnxzn3sr08hbwvpapyk7-glibc-2.21/lib/libpthread.so.0 (0x00007ffa6f4aa000)
	librt.so.1 => /nix/store/npfsi1d9ka8zwnxzn3sr08hbwvpapyk7-glibc-2.21/lib/librt.so.1 (0x00007ffa6f2a2000)
	libdl.so.2 => /nix/store/npfsi1d9ka8zwnxzn3sr08hbwvpapyk7-glibc-2.21/lib/libdl.so.2 (0x00007ffa6f09e000)
	libm.so.6 => /nix/store/npfsi1d9ka8zwnxzn3sr08hbwvpapyk7-glibc-2.21/lib/libm.so.6 (0x00007ffa6ed9b000)
	libgcc_s.so.1 => /nix/store/npfsi1d9ka8zwnxzn3sr08hbwvpapyk7-glibc-2.21/lib/libgcc_s.so.1 (0x00007ffa6eb85000)
	libXext.so.6 => /run/opengl-driver/lib/libXext.so.6 (0x00007ffa6e973000)
	libX11.so.6 => not found
	libc.so.6 => /nix/store/npfsi1d9ka8zwnxzn3sr08hbwvpapyk7-glibc-2.21/lib/libc.so.6 (0x00007ffa6e5d3000)
	/nix/store/npfsi1d9ka8zwnxzn3sr08hbwvpapyk7-glibc-2.21/lib64/ld-linux-x86-64.so.2 (0x00007ffa71f27000)
	libX11.so.6 => /nix/store/cwzl5vyl3lqzilh4hklff0h8zh3c77w4-libX11-1.6.3/lib/libX11.so.6 (0x00007ffa6e296000)
	libxcb.so.1 => /nix/store/dfwj9b6vb2g65asg681yw2w8knpmlqq4-libxcb-1.11/lib/libxcb.so.1 (0x00007ffa6e078000)
	libXau.so.6 => /nix/store/p408ns8dn0cfi4z4fzd6f10b9pvlfhss-libXau-1.0.8/lib/libXau.so.6 (0x00007ffa6de75000)
	libXdmcp.so.6 => /nix/store/xm4jqqq9m2nb9mczvv02z1lsyj225kvf-libXdmcp-1.1.2/lib/libXdmcp.so.6 (0x00007ffa6dc70000)

@nathanielbaxter Thanks for pointing me to the driver package. That does seem like it would be more likely what needs to be updated.

Then I think the best step is to use patchelf to extend RPATH so that it finds those libraries, probably from packages stdenv.cc.cc and xorg.libX11.

The hacks that you are probably looking for are here; using sed to replace paths in binary files is ugly but such is life.
As vcunat said you may need to run patchelf on "$out/lib/dri/fglrx_dri.so" and/or other libs provided by ati, patchelf is already used in builder.sh to fix references to libstdc++ for other libs.

I did create a pull request with my changes at #11817. As I mention there, I am still getting the segfault. Would you mind please helping me? I know little about driver issues.

Is this related to #8676?

/nix/store/HASHPATH/ati-drivers-15.7/lib/fglrx/switchlibglx
Usage:
switchlibglx   amd|intel|query
amd:   switches to the AMD version of libglx.so .
intel: switches to the open-source version of libglx.so .

FTW we should delete or adapt the scripts in that directory because they won't work as is in nixos.
glxinfo is for when using the open-source version of libglx.so.
fglrxinfo is for when using the AMD version of libglx.so.
The nixos package definitely does not use the open-source version of libglx.so by default.
In order to fix glxinfo to work as OP expects, the open-source version of libglx.so needs to be re-built or patched to look at the correct paths if ati-drivers is installed.
As we don't use the open-source version of libglx.so in ati-drivers - glxinfo failing is a non-issue unless the option to use the open-source version of libglx.so is added to ati-drivers.
What this report did expose is that in ati-drivers there are missing library paths to libstdc++.so.6 and that there is also an empty entry pointing to libX11.so.6.
Fixing those two issue likely solves any other issues people (like me) were having with ati-drivers.

That's super confusing to me. Shouldn't glxinfo, and anything else, use the unfree libglx.so when that is the one that is installed? Does NixOS have different packages bypassing the driver that's installed and using whatever driver they choose?

libglx.so is part of the opengl implementation. The open source implementation named mesa is not feature complete. That is to say that it does not fully support all current opengl standards. It is on going work and is progressing.
AMD cards support opengl extensions which are proprietary which are not part of the current opengl standards so AMD bundle libglx.so with their driver which supports their own proprietary opengl extensions (which are not part of the opengl specification) and may (or may not) include feature completeness for existing opengl standards which are not complete in mesa.
So it is better for catalyst to not use libglx.so provided by mesa if you want to use AMD supported opengl feature x or proprietary extension x which is provided by the opengl library AMD have bundled with their driver.
This relates to glxinfo because glxinfo is a tool to look at opengl information supported by a driver. Depending upon whether the driver uses libglx.so from AMD or not will depend upon what is returned by the program. switchlibglx is supposed to enable a user to switch between the driver using mesa opengl or the AMD bundled opengl. In it's current form it will not work in nixos.
glxinfo not working does not effect direct rendering. glxinfo only reports that direct rendering is not enabled because it cannot probe to find out.
clinfo from the AMD sdk is actually how you check the AMD catalyst driver. I haven't tried it although it has been packaged.
nixpkgs/pkgs/tools/graphics/glxinfo/ needs to be patched using patchelf or compiled so that the paths to the libraries are correct should ati-drivers be installed (and I suspect also the non free nvidia drivers also) in order that it works should a non-free driver be installed.

Thanks @heydojo for the explanation. Some of that was already clear to me, but I think what I am still having trouble understanding is why any application, glxinfo or not, would need to be patched based on what driver is installed. It may end up to be the correct solution to simply patch it, but how would we know that glxinfo is the only app not seeing the correct library paths?
I have at least one other app not working correctly when I use unfree Catalyst, so I'm concerned this is a systemic problem.
Shouldn't every app, including glxinfo, be using whatever is in /run/opengl-driver as the driver?

Why any application, glxinfo or not, would need to be patched based on what driver is installed?

Purity in Nixos. When glxinfo is built it cannot see ati-drivers and does not know that ati-drivers are installed (should it need to.)
In your debug you can see glxinfo is looking for /usr/X11R6/lib64/modules/dri/fglrx_dri.so and that path is clearly wrong. The root of that problem lies either with glxinfo or the opengl library.

But how would we know that glxinfo is the only app not seeing the correct library paths?

You can test, use ldd to check paths and run strace on programs.

I have at least one other app not working correctly when I use unfree Catalyst, so I'm concerned this is a systemic problem.

Which app is not working? You have one other app not working or you have more than one not working? Maybe this is a systemic problem. It wouldn't be a reason to be concerned.

Shouldn't every app, including glxinfo, be using whatever is in /run/opengl-driver as the driver?

I don't understand. Graphical applications talk to the xserver, usually using a toolkit library and the xserver handles the driver.

When glxinfo is built it cannot see ati-drivers and does not know that ati-drivers are installed
If glxinfo relies on drivers to work, I do think it should know about the drivers that are installed when it is built, at least if I understand the problem correctly. If this isn't the case, glxinfo ceases to have a purpose.

use ldd to check paths and run strace on programs
Seems like an overwhelmingly large task.

Which app is not working?
HipChat, that I know of so far...

Maybe this is a systemic problem. It wouldn't be a reason to be concerned.
So far NixOS has been the most painful distro I have used in terms of configuration. I am still new to it, and I haven't given up because I have the ability to contribute, and I think the core idea is good. However, if I can't convince myself that installing an application will guarantee that the application will work, including using the correct graphic driver, I will probably move to another distro.

I don't understand. Graphical applications talk to the xserver, usually using a toolkit library and the xserver handles the driver.
If you don't understand, imagine how I must feel. You are saying only the xserver needs to know about the driver? Why does the xserver not handle things for glxinfo, if you are correct? Why is that an exception? How many exceptions are there?

Seems like an overwhelmingly large task.

Welcome to the world of developing nix expressions where every path should be checked for purity. :)

So far NixOS has been the most painful distro I have used in terms of configuration.

But it is improving and has huge potential. I was a distro shuffler for about two years. Then I dug in, read documentation, studied and gained enough skills to get by.

Why does the xserver not handle things for glxinfo

If you look at the builder for glxinfo you will see that it is a small stand alone program. Look at the source code for glxinfo if you want to understand how it works.

I don't understand what's not clear about libglx; I believe the state is this:
our X server has its own libglx implementation, and in addition it is set up to search for modules in /run/opengl-driver/lib/xorg/modules/extensions where the proprietary drivers are supposed to install their libglx versions. It is nixos who does the switching. (Therefore you're correct that fglrx switching script would better not be installed.)

I don't understand what's not clear about libglx

I don't have the background/understanding of how any given app (including glxinfo) interacts with the graphics drivers. I'll try to again re-state my current understanding and my outstanding questions.
I have gathered that libglx is a part of the graphics driver "suite", there there are conflicting versions of it, and that it's up to NixOS to resolve that conflict.
I'm not sure if libglx is special, but it seems to me that for any app that needs any library belonging to the graphics driver, Nix should make the appropriate connection. Note that it's not clear to me precisely by what means this "connection" should be made, whether it takes the form of LD_LIBRARY_PATH, patchelf, or something else.
The specific case in question for this issue, which has not been answered in a way that I can understand, is why the app glxinfo does not use the unfree ATI driver (fglrx) when it is installed. If libglx is a relevant library to glxinfo that is a part of the fglrx driver, and NixOS is responsible for the "switching", what needs to happen to set things right? And also important to me: can it be solved in a way that also ensures other applications do not have this problem?

I believe this GPU driver switching works fine in general on NixOS. I'm using the proprietary nvidia drivers for years, even for various heavier use cases (steam and other games). The glxinfo+fglrx breakage may well be unrelated to this directly, IMHO.

Thanks @vcunat. Knowing that will at least keep me from going down a very scary rabbit-hole.

I don't think the glxinfo problem is entirely unrelated. I now have R7 370, and if I try and run my own personal SDL2 projects:
Preprocessing executable 'ssao-example' for ssao-example-0.1.0.0...
Running ssao-example...
libGL: AtiGetClientDriverName: 15.20.3 fglrx (screen 0)
libGL error: OpenDriver: failed to open /usr/X11R6/lib64/modules/dri/fglrx_dri.so, error[/usr/X11R6/lib64/modules/dri/fglrx_dri.so: cannot open shared object file: No such file or directory]
libGL error: OpenDriver: failed to open /usr/lib64/dri/fglrx_dri.so, error[/usr/lib64/dri/fglrx_dri.so: cannot open shared object file: No such file or directory]
ukiDynamicMajor: found major device number 249
ukiDynamicMajor: found major device number 249
ukiDynamicMajor: found major device number 249
ukiOpenDevice: node name is /dev/ati/card0
ukiOpenDevice: open result is 4, (OK)
ukiGetBusid returned 'PCI:1:0:0'
ukiOpenDevice: node name is /dev/ati/card1
ukiOpenDevice: UKI_ERR_NOT_ROOT
ukiOpenDevice: node name is /dev/ati/card2
ukiOpenDevice: UKI_ERR_NOT_ROOT
ukiOpenDevice: node name is /dev/ati/card3
ukiOpenDevice: UKI_ERR_NOT_ROOT
ukiOpenDevice: node name is /dev/ati/card4
ukiOpenDevice: UKI_ERR_NOT_ROOT
ukiOpenDevice: node name is /dev/ati/card5
ukiOpenDevice: UKI_ERR_NOT_ROOT
ukiOpenDevice: node name is /dev/ati/card6
ukiOpenDevice: UKI_ERR_NOT_ROOT
ukiOpenDevice: node name is /dev/ati/card7
ukiOpenDevice: UKI_ERR_NOT_ROOT
ukiOpenDevice: node name is /dev/ati/card8
ukiOpenDevice: UKI_ERR_NOT_ROOT
ukiOpenDevice: node name is /dev/ati/card9
ukiOpenDevice: UKI_ERR_NOT_ROOT
ukiOpenDevice: node name is /dev/ati/card10
ukiOpenDevice: UKI_ERR_NOT_ROOT
ukiOpenDevice: node name is /dev/ati/card11
ukiOpenDevice: UKI_ERR_NOT_ROOT
ukiOpenDevice: node name is /dev/ati/card12
ukiOpenDevice: UKI_ERR_NOT_ROOT
ukiOpenDevice: node name is /dev/ati/card13
ukiOpenDevice: UKI_ERR_NOT_ROOT
ukiOpenDevice: node name is /dev/ati/card14
ukiOpenDevice: UKI_ERR_NOT_ROOT
ukiOpenDevice: node name is /dev/ati/card15
ukiOpenDevice: UKI_ERR_NOT_ROOT
ukiDynamicMajor: found major device number 249
ukiOpenByBusid: Searching for BusID PCI:1:0:0
ukiOpenDevice: node name is /dev/ati/card0
ukiOpenDevice: open result is 4, (OK)
ukiOpenByBusid: ukiOpenMinor returns 4
ukiOpenByBusid: ukiGetBusid reports PCI:1:0:0
ukiDynamicMajor: found major device number 249
ukiDynamicMajor: found major device number 249
ukiOpenByBusid: Searching for BusID PCI:1:0:0
ukiOpenDevice: node name is /dev/ati/card0
ukiOpenDevice: open result is 5, (OK)
ukiOpenByBusid: ukiOpenMinor returns 5
ukiOpenByBusid: ukiGetBusid reports PCI:1:0:0
Segmentation fault

I also get a segmentation fault, like glxinfo.

authors: a1russell heydojo nathanielbaxter ocharles vcunat

repo: NixOS/nixpkgs


text:
scryer-prolog fails to build on Linux (non-NixOS)

Describe the bug
scryer-prolog (0.8.127) fails to build on Linux (Elementary OS, x86_64)
Steps To Reproduce
Steps to reproduce the behavior:

nix run nixpkgs/nixpkgs-unstable#scryer-prolog

Expected behavior
I expected the scryer-prolog package to install successfully.
Screenshots
Additional context
Error from log:
[...]
   Compiling dirs v2.0.2
error[E0308]: mismatched types
   --> /build/scryer-prolog-0.8.127-vendor.tar.gz/lexical-core/src/atof/algorithm/bigcomp.rs:243:55
    |
243 |     let nlz = den.leading_zeros().wrapping_sub(wlz) & (u32::BITS - 1);
    |                                                       ^^^^^^^^^^^^^^^ expected `usize`, found `u32`

error[E0277]: no implementation for `usize & u32`
   --> /build/scryer-prolog-0.8.127-vendor.tar.gz/lexical-core/src/atof/algorithm/bigcomp.rs:243:53
    |
243 |     let nlz = den.leading_zeros().wrapping_sub(wlz) & (u32::BITS - 1);
    |                                                     ^ no implementation for `usize & u32`
    |
    = help: the trait `BitAnd<u32>` is not implemented for `usize`
[...]

Notify maintainers

@malbarbo
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 5.11.0-27-generic, elementary OS, 6 Odin`
 - multi-user?: `no`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.4pre20210802_47e96bb`
 - channels(samarth): `"nixpkgs-21.11pre308173.10bb0364861"`
 - nixpkgs: `/home/samarth/.nix-defexpr/channels/nixpkgs`

Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:

its a distro-agnostic issue
the reason it happens in because the lexical core that the latest scryer-prolog release uses is old and incompatible with new rust releases.
Could you file a issue upstream about maybe releasing a new version?

authors: Artturin samarthkishor


text:
Ocenaudio fails due to bad hash

Describe the bug
When trying to install Ocenaudio, the installation fails due to a sha256 hash mismatch.
hash mismatch in fixed-output derivation '/nix/store/jp2dv1x05fxd1w8hgjhq0p43zjcswpwf-ocenaudio_debian9_64.deb?version=3.10.6':
  wanted: sha256:0fgvm1xw2kgrqj3w6slpfxbb3pw9k8i0dz16q9d5d8gyyvr2mh8g
  got:    sha256:1yflpyl0d1mi0zxdyrlbg0px95s2c945ahy0agc8rha01ccf7jwy
cannot build derivation '/nix/store/4jy1ckxhq4axayamhim56hw8x0c0wxbj-ocenaudio-3.10.6.drv': 1 dependencies couldn't be built

Steps To Reproduce
Steps to reproduce the behavior:

Add ocenaudio to my NixOS config
sudo nixos-rebuild switch

Expected behavior
I expected the program to be installed.
Notify maintainers

@onny
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 5.10.79, NixOS, 21.05.4381.3bea86e918d (Okapi)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.16`
 - channels(miki): `"nixpkgs-21.11pre330734.5cb226a06c4"`
 - channels(root): `"nixos-21.05.4381.3bea86e918d"`
 - nixpkgs: `/home/miki/.nix-defexpr/channels/nixpkgs`

Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:
ocenaudio

looks like aur has the same problem
https://aur.archlinux.org/packages/ocenaudio-bin/

The checksum is correct, but the version is not. And since ocenaudio download is not versioned (that's an upstream problem), the checksum from 2.9.4 does not match the new version 2.9.5.

authors: Artturin MikulasVanousek


text:
thermald is broken due to use of deprecated functions

Describe the bug
see here: https://github.com/intel/thermal_daemon/issues/340 and https://github.com/intel/thermal_daemon/pull/338
I'm patching locally for now, hopefully they merge it and tag a release.

thermald is pulled into a number of systems via nixos-hardware

I guess #162568 fixed this in the meantime.


text:
Feature Request:  define firefox settings from about:config declaratively

Hello.
Firefox provides a way of customizing it further than the settings page in the gui: When you type about:config (second link) into your browser, you can view lots of its settings - which i would love to describe declaratively via configuration.nix

If I'm not wrong, is not something nix can do, since firefox configuration is per-profile and resides under the user folder.
However, you can achieve it by following this:
http://askubuntu.com/questions/313483/how-do-i-change-firefoxs-aboutconfig-from-a-shell-script
The file user.js can be generated from nix with
pkgs.writeText "user.js" ''
configuration example
''

And then linked/copied to the firefox profile dir.
Correct me if I'm wrong

If I'm not wrong, is not something nix can do, since firefox configuration is per-profile and resides under the user folder.
However, you can achieve it by following this:
http://askubuntu.com/questions/313483/how-do-i-change-firefoxs-aboutconfig-from-a-shell-script
The file user.js can be generated from nix with
pkgs.writeText "user.js" ''
configuration example
''

And then linked/copied to the firefox profile dir.
Correct me if I'm wrong

I missed that feature, so thank you. I'll try it the next weeks or so.

On Ubuntu there is /usr/lib/firefox/browser/defaults/preferences/syspref.js, not sure what is an equivalent on NixOS.

Apparently, Firefox only reads the default preferences from /usr/lib/firefox making the configuration change impossible without recompiling Firefox. There exists a patch but it was not accepted very warmly, see bug 1170092. We could apply the patch locally, as RHEL probably does; it would not be very useful for -bin packages, though.

See the tor browser bundle for an idea of how to do this: https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/networking/browsers/tor-browser-bundle/default.nix#L134

I'd say it needs to be done in firefoxWithPackages. So, this is related to #15959.

On a related note, there is policies.json.
https://support.mozilla.org/en-US/kb/customizing-firefox-using-policiesjson
https://github.com/mozilla/policy-templates/
This is kept in the install directory, so it might be easier to nixify.

That was probably the only missing piece, why I was using chromium, declarative policies. I didn't know they exist in Firefox.

Policies seem to be rather experimental still.
Another (older?) option seems to be
https://support.mozilla.org/en-US/kb/customizing-firefox-using-autoconfig

@xaverdh see the issue linked above for discussion of such a solution.

Hmm. Unlike the tor-browser-bundle, the standard firefox wrapper does not have an extraPrefs option as far as I can see.

Looks like programs.firefox.preferences and programs.firefox.policies are in nixpkgs. Home-manager has more options starting at programs.firefox.enable
  programs.firefox = {
    enable = true;
    preferences = {
      # force hardware decoding
      "media.ffmpeg.vaapi.enabled" = true;
      "gfx.webrender.all" = true;
    };
  };

https://github.com/nix-community/home-manager/issues/606 has more discussion on the topic.
I believe this issue can be closed.

Or if you want to stick with Nixpkgs, you can override the wrapper arguments:
pkgs.firefox.override (args: args // {
  cfg = args.cfg or {} // {
    enableGnomeExtensions = true;
  };

  extraPrefs = ''
    // Downloading random PDFs from http website is super annoing with this.
    lockPref("dom.block_download_insecure", false);

    // Always use XDG portals for stuff
    lockPref("widget.use-xdg-desktop-portal.file-picker", 1);

    // Enable userChrome.css
    lockPref("toolkit.legacyUserProfileCustomizations.stylesheets", true);

    // Avoid cluttering ~/Downloads for the “Open” action on a file to download.
    lockPref("browser.download.start_downloads_in_tmp_dir", true);
  '';
});

authors: anund joachifm jtojnar nico202 offlinehacker oxij toogley xaverdh


text:
thunderbird + enigmail fails decrypt/encrypt/sign message

Issue description
When trying to sign, encrypt or decrypt a message with a gnupg key that is not open in the active gpg agent, thunderbird/enigmail displays a pop-up with an error stating that it failed to encrypt/decrypt the message.
Steps to reproduce

Flush your keychain/gpg-agent to ensure all keys are unloaded/removed.
Run thunderbird.
Install the enigmail addon and configure it to use a private key
Restart thunderbird
In enigmail's settings, ensure it locates the gpg2 binary correctly
Create a new private key if necessary
Start a new message, select to sign and encrypted message.
Send the message to yourself. (this should fail or prompt for a password before sending)

In the last step I don't see a password prompt and I see the pop-up error almost immediately.
Notes
I'm currently not sure if the issue is caused by gpg2 failing to display a password prompt (failing to start pinentry-gtk or anything gui?) or some other reason.

Using gpg2 directly from the terminal shows a graphical (GUI) pinentry.
I don't have any explicit pinentry binary on my gpg-agent.conf or gpg.conf.

Technical details

System: (NixOS: 16.09.1512.6b28bd0 (Flounder))
Nix version: (1.11.6)

Enigmail seems to work OK for me, popping up for passphrase if needed, but perhaps there's some significant detail different in my setup, e.g. I have additionally gnupg1compat package.

Works for me, I don't have gnupg1compat. I don't have an explicit pinentry configured either.

What kind of X desktop/window manager do you have? I have awesomewm if that matters.
I've come to notice that gpg-agent as well as ssh-agent get initialized by systemd. I used to use keychain but this also seems to have issues interacting with the gpg-agent.
On another note, if I kill the running gpg-agent and then start it manually thunderbird then shows me the password prompt and doesn't ask for a while which I understand as it using the new agent.
Could it somehow be that the environment used by systemd to spawn the agent is somehow incorrect leading to an inability to open the password dialog or to default to a console only pinentry which immediately fails?
Any suggestions on how to debug this further?

I have xfce4-session (with XMonad), but I don't remember now how the agent(s) are started.

I'm on i3. I also just realised that I have no idea when my gpg agent is spawned; I don't see it mentioned in any of the files that start up my session. I suspect that it might be started by the client on demand. @Unode, what happens if you kill the running agent then try to use clients without manually restarting it? And do you know where the initially started agent keeps its sockets? (try lsof -p $(pgrep gpg-agent))

I forgot to mention that I use slim as graphical login manager. It's the default after installation.
lsof -c gpg-agent gives me /run/user/1000/gnupg/S.gpg-agent in both cases (login and after kill).
One thing I also noticed is that after killing gpg-agent and confirming that no process is running nor started automatically, the moment I select an encrypted or signed message in Thunderbird, I see a password prompt and at this point a new gpg-agent is already running.
I don't know if this is a new feature with gnupg2 or some other systemd or otherwise magic.
I though gpg-agent was started by systemd but after further inspection it turns out that only ssh-agent is actually spawned. I don't know what spawns gpg-agent the first time.
I haven't tested it but considering the above, I may be able to workaround the issue by simply killing the agent moments after login.

Had the exact same symptoms. Not using keychain to auto-start gpg-agent fixed the issue.

Indeed with the newer gnupg it gets started on demand as @lheckemann mentioned.
The issue seems to be that if the gpg-agent gets spawned in a non-X environment it doesn't know where to show the pinentry dialog.
Not starting the agent immediately after login and delaying it until its needed is usually sufficient since at that time X is likely running. I still get some issues if I login first on the console but I can workaround those.
In any case this seems more of a gnupg issue not specific to NixOS.
Thanks everyone and @jbgi for confirming.

authors: Unode jbgi lheckemann vcunat


text:
CUDA-Team: discuss binary distribution via Hydra or otherwise

Issue to track discussion and thoughts on binary distribution.
One potential way forward is continuing the petition to allow Hydra to build and cache unfree redistributables, which would allow redistributing CUDA-accelerated binaries.
There are also other ways forward -- custom binary caches, maintaining our own branch of Nixpkgs, and many others.
Let's hear your thoughts!

@SomeoneSerge you had good thoughts on maintaining our own cache and having a cuda-stable branch. Would you mind sharing those here?

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/cuda-team-roadmap-and-call-for-sponsors/29495/1

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/cuda-team-roadmap-update-2023-08-29/32379/1

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/community-calendar/18589/103

Since this has been linked from discourse, here are some additional references to the past discussions:

https://github.com/NixOS/nixpkgs/pull/76233
https://github.com/NVIDIA/build-system-archive-import-examples/issues/10

One more thing to note is that technically there's no reason not to cache the redist FODs, other than that it'd be weird to expose them in separate attributes just for hydra. They're explicitly redistributable and we don't patch their contents. Related: https://github.com/NixOS/nixpkgs/issues/106471


text:
Gnome: Keyboard layout issues since 3.26

Issue description
I do not know how to describe this or how to pinpoint this issue.
But, probably since gnome 3.26 I have weird issues regarding keyboard layouts.
Some keys (mostly special keys) register as other keys than expected.

Key Pressed
Event Registred
Comment

Left Arrow
ISO_Level3_Shift
Captured by xev

Down Arrow
Super_R
Captured by xev

Up Arrow
Screenshot
Not actually captured by xev, but that's the effect

Right Arrow
NoSymbol
Captured by xev

ISO_Level3_Shift
KP_Enter
Captured by xev

Page Up
/
Captured by xev

Page Down
Menu
Captured by xev

I can also note here: Both my keyboards works as expected outside of gnome (tty for example). I haven't tested with other window environments.
Steps to reproduce
Running on the latest checkout of nixos-unstable. Which happens to be on this commit at the moment: 4cbbecc85dbc5a040f2e4111093d30337718996a
This machines config is here: https://github.com/etu/nixconfig/blob/master/hosts/phouchg/configuration.nix
Here is my configs related to non-graphical stuff (like creating users and such): https://github.com/etu/nixconfig/blob/master/profiles/common.nix
Here is my configs related to graphical stuff not related to gnome: https://github.com/etu/nixconfig/blob/master/profiles/common-graphical.nix
Here is my configs related to gnome: https://github.com/etu/nixconfig/blob/master/profiles/desktop-gnome.nix
Technical details

system: "x86_64-linux"
host os: Linux 4.14.2, NixOS, 18.03.git.4cbbecc85dbM (Impala)
multi-user?: yes
sandbox: no
version: nix-env (Nix) 1.11.15
channels(root): "nixos-18.03pre120398.aeff3080d0"
nixpkgs: /etc/nixos/nixpkgs

cc @jtojnar (probably?)

We are using libinput for handling keyboard events (https://github.com/NixOS/nixpkgs/pull/31995) and it does not like Option "XkbRules" "base". You can remove the whole Xorg configuration block in https://github.com/etu/nixconfig/blob/deabec5bfd7210a8b3d607a16ed4874dc60025aa/profiles/desktop-gnome.nix#L14-L26, the GSettings override should be sufficient for both GNOME session and GDM thanks to #31683.

@jtojnar Oh, thanks. That works. 👍

authors: etu jtojnar


text:
Update request: gnome-shell 46.4 → 46.5

Package name: gnome-shell
Latest released version: 46.5

Current version on the unstable channel: 46.4
Current version on the stable/release channel: 46.2

[x] Checked the nixpkgs pull requests

Notify maintainers
@bobby285271 @hedning @jtojnar @dasj19

Note for maintainers: Please tag this issue in your PR.

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

We are working on GNOME 47 bump in #333911, we do not have the resources to bump to 46.5.

authors: Anifyuli jtojnar


text:
KDE / KOrganizer Dependencies Missing

Issue description
Kontact / KOrganizer / KDE-PIM, when installed, crashes upon use:
i.e. In KOrganizer, adding an event/task/journal, causes a crash. (see Technical details)
KOrganizer only works after installing everything from nixos.kdeApplications and nixos.kdeFrameworks
nix-env -iA nixos.kdeApplications nixos.kdeFrameworks
I attempted to compare Debian's dependency graph for KOrganizer and install the equivalently named  packages in NixOS, to no avail.
Steps to reproduce
nano /etc/nixos/configuration.nix
Add korganizer to systemPackages, use Plasma5 as Desktop-Manager & SDDM as Display-Manager
nixos-rebuild switch
korganizer
Add new event, type Title, hit OK, crashes with output below
There is not a proper DrKonqi / KCrash report to associate with this, as neither system are considered dependencies of any other package, as far as I can tell, and must be installed manually.
Technical details
TTY Output:
org.kde.pim.kidentitymanagement: IdentityManager: There was no default identity. Marking first one as default.
kf5.kservice.services: KServiceTypeTrader: serviceType "KOrganizer/Part" not found
org.kde.pim.kidentitymanagement: IdentityManager: There was no default identity. Marking first one as default.
org.kde.pim.incidenceeditor: free slot calculation: invalid range. range(  0 ) / mSlotResolutionSeconds( 900 ) =  0
terminate called after throwing an instance of 'Akonadi::PayloadException'
  what():  Akonadi::PayloadException: Wrong payload type (requested: sp(0)<QByteArray>; present: sp(2)<KCalCore::Incidence*>
org.kde.pim.akonadiserver: Protocol exception: Socket disconnected

nix-shell -p nix-info --run "nix-info -m" Results:

system: "x86_64-linux"
host os: Linux 4.14.32, NixOS, 18.03.131802.4b4bbce199d (Impala)
multi-user?: yes
sandbox: no
version: nix-env (Nix) 2.0
channels(shor): ""
channels(root): "nixos-18.03"
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs

After a long debugging session I found out that kdeApplications.akonadi-mime was missing.
In my case it was not only required to install it into my own profile (~/.nix-profile) but also in environment.systemPackages since it looked into /run/current-system/sw/share/mime/types before it checks the other directory.

I confirm that following Mic92's suggestion to install kdeApplication.akonadi-mime in the environment.systemPackages fixes the Korganizer crashing issue when making calendar entries on my system too (18.03).  Doing so adds the following entries to /run/current-system/sw/share/mime/types:
application/x-vnd.akonadi.calendar.event
application/x-vnd.akonadi.calendar.freebusy
application/x-vnd.akonadi.calendar.journal
application/x-vnd.akonadi.calendar.todo
application/x-vnd.akonadi.collection.virtual
application/x-vnd.kde.contactgroup
Thanks for taking the time to figure out a solution Mic92!
John

Still receiving this error message after above suggestion:
terminate called after throwing an instance of 'Akonadi::PayloadException'
  what():  Akonadi::PayloadException: Wrong payload type (requested: sp(0)<QByteArray>; present: sp(2)<KCalCore::Incidence*>

@ttuegel @vandenoever There doesn't seem to be any documentation on how to properly install KDE applications.  Would it make sense to have meta-packages like kontact that installed all necessary dependencies?

not stale

I had the same issue. After having spend a bit too much time, I was able to isolate the issue.
(if this help someone: setting QT_LOGGING_RULES=org.kde.pim.akonadicore=true logged many useful information)
The issue is that kontact wasn't able to find the serializer for the agenda (in my case, todo element), more exactly it was missing the serializer for application/x-vnd.akonadi.calendar.todo. This serializer seems to be present in akonadi-calendar, so I added it to the system package (like the @Mic92 change), and it worked. It should be missing as a build input somewhere.

@ttuegel @vandenoever @nyanloutre
Hi! Any ideas about this? This issue is biting me too. It seems like it could just be a simple case of missing dependencies but actually figuring out what those are is proving rather difficult...

This is frustrating. I just want to use the KDE PIM suite in peace.
$ kmail
QSocketNotifier: Can only be used with threads started with QThread
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
We have an error during reading password  "Entry not found"
org.kde.pim.akonadicore: Job error:  "" for collection: QVector()
org.kde.pim.akonadicore: Job error:  "" for collection: QVector()
org.kde.pim.messagelist: Failed to load tags  ""
org.kde.pim.mailcommon: failed to retrieve tags  ""

Does the above contain any hint explaining why Akonadi fails to run properly?

As mentionned in https://discourse.nixos.org/t/kaddressbook-kontact-akonadi-cannot-add-address-book/25227 I am having issues with kontact and kaddressbook.
In the first post @Meizikyn states that installing nixos.kdeApplications and nixos.kdeFrameworks helped, but in NixOS 22.11 I am not finding these. Can anyone help?

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/kaddressbook-kontact-akonadi-cannot-add-address-book/25227/5

Merging this into #266565

authors: Meizikyn Mic92 Narice Obikawa SuperSandro2000 Zahrun alexdewar johnalotoski marius851000 nixos-discourse pjones


text:
Package request: LAPACKE

It is strange that this is not packaged yet (!). There is a haskell version called jalla which has a description of
       description = "Higher level functions for linear algebra. Wraps BLAS and LAPACKE.";

but the LAPACKE itself doesn't have a package, while it is present in Ubuntu as liblapacke-dev.

We already have the LAPACK
https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/science/math/liblapack/default.nix
The "lapacke" must be some sort of quirk of debian packaging and not a different software.
https://packages.debian.org/sid/liblapacke-dev

LAPACKE provides the C library version of LAPACK. I would recommend taking look at openblas first, which comes with a C interface per default. Morever, openblas is highly optimized  for performance the preferred choice the days.
However, if you want LAPACKE specifically you can just use a override of lapack which enables LAPACKE:
liblapacke = liblapack.overrrideAttrs(x: { cmakeFlags = x.cmakeFlags ++ [ "-DLAPACKE=on" ]; })

I am not sure why debian creates a seperate package for it since it looks like lapacke just creates an additional library and some C header files. We could  just add the cmake flag to liblapack in nixpkgs.

Thanks for solving this @markuskowa !

authors: markuskowa rht veprbl


text:
GHC 8.8.1 haskell package set refers to undefined variables

Describe the bug
The Haskell package set for GHC 8.8.1 refers to things in the configuration which don't exist.
To Reproduce
$ nix-shell -p '(import <unstable> {}).haskell.packages.ghc881.ghcWithPackages (hs: [ hs.comonad ])'
error: attribute 'cabal-doctest_1_0_7' missing

Expected behavior
For the example above, a shell is entered where comonad is usable.
Metadata
Please run nix run nixpkgs.nix-info -c nix-info -m and paste the result.
Maintainer information:
- system: `"x86_64-linux"`
 - host os: `Linux 4.19.72, NixOS, 19.03.173481.8a30e242181 (Koi)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.2.2`
 - channels(root): `"nixos-19.03.173506.2dfae8e22fd, nixos-hardware, unstable-20.03pre193309.c4196cca9ac"`
 - channels(ollie): `""`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

@vaibhavsagar looks like you added this change in https://github.com/NixOS/nixpkgs/commit/5e91bfa80acea3dabca7034f8a517044965b6270 - is there anything missing from that commit?

Hmm, maybe the package set has been updated since I made that change so that cabal-doctest_1_0_7 should now be cabal-doctest instead?

I think the correct solution here is just to remove the following line:
https://github.com/NixOS/nixpkgs/blob/054f01ee1ba7ea86f8442b7dcc9d99b8aece5427/pkgs/development/haskell-modules/configuration-ghc-8.8.x.nix#L77

I ran into the same problem and tried fixing it: https://github.com/NixOS/nixpkgs/pull/68935
This probably needs some cleaning up, but it can build ghc881.

@ocharles this should be fixed now on haskell-updates branch.

This was originally about ghc881, but we're now up to ghc883, and it is used in the main haskell package set, so I imagine this is no longer a problem.

authors: cdepillabout luc-tielen ocharles vaibhavsagar


text:
linuxPackages_latest.hid-playstation: init at unstable-2021-02-07

Motivation for this change
PS5 controller (DualSense) support.
I don't think it makes sense to merge this pr since hid-playstation is likely going to be merged into the kernel soon.
I'm opening this as a draft for people who want to use the controller right now.
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)
[x] 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.

Result of nixpkgs-review pr 113321 at a3ed3248 run on aarch64-linux 1

1 package marked as broken and skipped:

linuxPackages_latest-libre.hid-playstation

4 packages built:

linuxPackages_5_10.hid-playstation (linuxPackages_latest.hid-playstation ,linuxPackages_latest_xen_dom0.hid-playstation)
linuxPackages_latest_hardened.hid-playstation (linuxPackages_latest_xen_dom0_hardened.hid-playstation)
linuxPackages_lqx.hid-playstation
linuxPackages_zen.hid-playstation

2 suggestions:

warning: missing-patch-comment
Please add a comment on the line above, explaining the purpose of this patch.
Near pkgs/os-specific/linux/hid-playstation/default.nix:13:15:
   |
13 |   patches = [ "${src}/disable-ff-enabled-check.patch" ];
   |               ^

warning: unclear-gpl
gpl2 is a deprecated license, check if project uses gpl2Plus or gpl2Only and change meta.license accordingly.
Near pkgs/os-specific/linux/hid-playstation/default.nix:27:5:
   |
27 |     license = licenses.gpl2;
   |     ^

Closing because this has been merged into Linux version 5.12.

authors: r-rmcgibbo samuelgrf


text:
operator-sdk: 1.4.2 -> 1.5.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/operator-sdk/versions.
meta.description for operator-sdk is: "SDK for building Kubernetes applications. Provides high level APIs, useful abstractions, and project scaffolding"
meta.homepage for operator-sdk is: "https://github.com/operator-framework/operator-sdk"
meta.changelog for operator-sdk is: ""
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

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 1.5.0 with grep in /nix/store/ahgnhy0v7nxw49lf3hkmr57wgainrb9p-operator-sdk-1.5.0

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

du listing: https://gist.github.com/94fe829ff12a09d2f724e938688d6030

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
operator-sdk

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/ahgnhy0v7nxw49lf3hkmr57wgainrb9p-operator-sdk-1.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 operator-sdk https://github.com/r-ryantm/nixpkgs/archive/14a5e515e9866cf893e433873002e6493f6ddeb7.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/ahgnhy0v7nxw49lf3hkmr57wgainrb9p-operator-sdk-1.5.0
ls -la /nix/store/ahgnhy0v7nxw49lf3hkmr57wgainrb9p-operator-sdk-1.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

1 package built:

operator-sdk

Maintainer pings
cc @arnarg @kalbasit for testing.

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

1 package built:

operator-sdk

authors: fabaff r-ryantm


text:
ell: 0.38 -> 0.40, iwd: 1.12 -> 1.14

Motivation for this change
ell, https://git.kernel.org/pub/scm/libs/ell/ell.git/tree/ChangeLog?h=0.40
ver 0.40:
	Fix issue with handling failure from missing CA certificates.
	Fix issue with handling DBus.Introspectable queries.

ver 0.39:
	Add support for serialized test execution framework.

iwd, https://git.kernel.org/pub/scm/network/wireless/iwd.git/tree/ChangeLog?h=1.14
ver 1.14:
	Fix issue with scanning property and quick scan cancellation.
	Fix issue with handling authentication timeouts from SAE.
	Fix issue with handling association timeouts and retries.
	Fix issue with handling roaming frequencies after roaming.
	Fix issue with requesting neighbor report after roaming.
	Add support for handling PSK offload connections.

ver 1.13:
	Fix issue with EAPoL protocol version 2010 handling.
	Fix issue with authenticator method logic handling.
	Fix issue with getting scan results from firmware.
	Add support for handling SAE offload connections.
	Add support for roaming with FullMAC devices.

iwd needs to have ell/useful.h to build now. I've opted for symlinking it in (not sure if that's the best/most nix way to do it?), the alternative is just using release tarballs - but they do not contain the doc directory. I went for the option that changed the fewest things, though it feels more correct to use the release tarballs for both ell/iwd to me.
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
[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 122881 at c018ef9f run on aarch64-linux 1

2 packages failed to build:

modem-manager-gui
ofono

2 packages built successfully:

ell
iwd

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.

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

2 packages failed to build:

modem-manager-gui
ofono

2 packages built:

ell
iwd

ofono needs a bump to 1.32 as well.

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

4 packages built:

ell
iwd
modem-manager-gui
ofono

That sounds like a bug in iwd to me – according to readme:

When using --enable-external-ell build option, it is not required that the
Embedded Linux library source code is available in the top level directory.

I would probably go with linking the header too.

@jtojnar As currently done in upstream, even with --enable-external-ell it expects to build ell/useful.h (at least as far as I understand the makefile). I'll keep an eye on it when bumping in the future to see if it's fixed.

authors: jtojnar maxeaubrey r-rmcgibbo


text:
pass: 1.7.3 -> 1.7.4

Mostly bug fixes, the following changes were required in the package:

set-correct-program-name-for-sleep.patch needed to be rebased,
b08781e2a6e183986eb1c24f51cdeff879b7a6af partially implemented
the changes done in this patch, so we don't need to touch
password-store.sh anymore.

Remove wayland patch since it is part of the release now

Reworked assert logic wrt to x11-/wayland- and dmenuSupport:
passmenu now supports wayland as well via dmenu-wayland. Sadly
the choice of menu is not changeable, pending
https://lists.zx2c4.com/pipermail/password-store/2021-January/004363.html

Rebased no-darwin-getopt.patch

Note that f.el is no longer required

Reviews would be appreciated, I might've missed something.

Motivation for this change
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"
[ ] Tested execution of all binary files (usually in ./result/bin/)
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

[x] Fits CONTRIBUTING.md.

Unless I'm missing something, the wayland compat patch-file can be removed from nixpkgs now. Also, do you think that's suitable for backport?

Unless I'm missing something, the wayland compat patch-file can be removed from nixpkgs now. Also, do you think that's suitable for backport?

Yes, just forgot that, thanks!
I think this should be safe to backport, however we maybe should test it on unstable for a bit, I personally haven't reviewed the entire diff between the releases and pass feels a bit fragile, so I'm not confident there'd be no runtime problems.

I'll have to take a closer look at the diff (both here and upstream) first, but after that I could test this on my machine (heavy pass user, on 21.05).

Sounds good, I'll also try to retire my local wayland patches and test on unstable with this commit cherry picked.

Result of nixpkgs-review pr 126616 at 9b794eb2 run on aarch64-linux 1

8 packages built successfully:

krunner-pass
pass
pass-nodmenu
pass-wayland
passExtensions.pass-audit
passExtensions.pass-import
qtpass
rofi-pass

3 suggestions:

warning: unused-argument
Unused argument: symlinkJoin.
Near pkgs/tools/security/pass/default.nix:3:49:
  |
3 | , which, procps , qrencode , makeWrapper, pass, symlinkJoin
  |                                                 ^

warning: missing-patch-comment
Consider adding a comment explaining the purpose of this patch on the line preceeding.
Near pkgs/tools/security/pass/default.nix:67:5:
   |
67 |     ./set-correct-program-name-for-sleep.patch
   |     ^

warning: missing-patch-comment
Consider adding a comment explaining the purpose of this patch on the line preceeding.
Near pkgs/tools/security/pass/default.nix:68:5:
   |
68 |     ./extension-dir.patch
   |     ^

Seems to work fine for me, LGTM :+1:

Seems to work fine for me, LGTM +1

Also no obvious problems for me so far.

authors: Ma27 r-rmcgibbo sternenseemann


text:
csound: 6.16.0 -> 6.16.2

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/csound/csound/releases.
meta.description for csound is: "Sound design, audio synthesis, and signal processing system, providing facilities for music composition and performance on all major operating systems and platforms"
meta.homepage for csound is: "http://www.csounds.com/"
meta.changelog for csound 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/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2/bin/csound passed the binary check.

/nix/store/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2/bin/csbeats passed the binary check.

/nix/store/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2/bin/csdebugger passed the binary check.

Warning: no invocation of /nix/store/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2/bin/atsa had a zero exit code or showed the expected version

/nix/store/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2/bin/csanalyze passed the binary check.

Warning: no invocation of /nix/store/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2/bin/cvanal had a zero exit code or showed the expected version

Warning: no invocation of /nix/store/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2/bin/dnoise had a zero exit code or showed the expected version

Warning: no invocation of /nix/store/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2/bin/envext had a zero exit code or showed the expected version

Warning: no invocation of /nix/store/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2/bin/extractor had a zero exit code or showed the expected version

Warning: no invocation of /nix/store/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2/bin/het_export had a zero exit code or showed the expected version

Warning: no invocation of /nix/store/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2/bin/het_import had a zero exit code or showed the expected version

Warning: no invocation of /nix/store/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2/bin/hetro had a zero exit code or showed the expected version

Warning: no invocation of /nix/store/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2/bin/lpanal had a zero exit code or showed the expected version

Warning: no invocation of /nix/store/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2/bin/lpc_export had a zero exit code or showed the expected version

Warning: no invocation of /nix/store/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2/bin/lpc_import had a zero exit code or showed the expected version

Warning: no invocation of /nix/store/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2/bin/mixer had a zero exit code or showed the expected version

Warning: no invocation of /nix/store/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2/bin/pvanal had a zero exit code or showed the expected version

Warning: no invocation of /nix/store/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2/bin/pvlook had a zero exit code or showed the expected version

Warning: no invocation of /nix/store/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2/bin/pv_export had a zero exit code or showed the expected version

Warning: no invocation of /nix/store/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2/bin/pv_import had a zero exit code or showed the expected version

Warning: no invocation of /nix/store/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2/bin/scale had a zero exit code or showed the expected version

/nix/store/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2/bin/sndinfo passed the binary check.

Warning: no invocation of /nix/store/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2/bin/srconv had a zero exit code or showed the expected version

Warning: no invocation of /nix/store/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2/bin/src_conv had a zero exit code or showed the expected version

Warning: no invocation of /nix/store/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2/bin/sdif2ad had a zero exit code or showed the expected version

/nix/store/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2/bin/scsort passed the binary check.

/nix/store/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2/bin/extract passed the binary check.

Warning: no invocation of /nix/store/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2/bin/cs had a zero exit code or showed the expected version

Warning: no invocation of /nix/store/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2/bin/csb64enc had a zero exit code or showed the expected version

Warning: no invocation of /nix/store/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2/bin/makecsd had a zero exit code or showed the expected version

Warning: no invocation of /nix/store/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2/bin/scot had a zero exit code or showed the expected version

5 of 31 passed binary check by having a zero exit code.

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

found 6.16.2 with grep in /nix/store/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2

found 6.16.2 in filename of file in /nix/store/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2

directory tree listing: https://gist.github.com/1dc7aedb31a36b87af491dee31fa77a4

du listing: https://gist.github.com/0f9fa542862b128a502eaad07d95e148

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

16 total rebuild path(s)

6 package rebuild(s)

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

First fifty rebuilds by attrpath
csound
csound-qt
faust2csound
hyper-haskell
liquidwar
solfege

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2 \
  --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 csound https://github.com/r-ryantm/nixpkgs/archive/ca2db83adcfbeda9e3edc38e1a206bfbda9fa280.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/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2
ls -la /nix/store/mkpna64g6yzkqg7w280x75nlh0lyb2ch-csound-6.16.2/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:

csound
csound-qt
faust2csound
hyper-haskell
liquidwar
solfege

Maintainer pings
cc @marcweber for testing.

Result of nixpkgs-review pr 130684 at ca2db83a run on aarch64-linux 1

5 packages built successfully:

csound
csound-qt
faust2csound
liquidwar
solfege

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

6 packages built:

csound
csound-qt
faust2csound
hyper-haskell
liquidwar
solfege

authors: r-rmcgibbo r-ryantm siraben


text:
emacsPackagesNg: remove old, overlapping emacs package declarations

Perhaps this is premature---I don't know exactly what the transition plan is for the emacs infrastructure.  But I found myself looking for something mindless to do, so I identified all but 20 entries in emacs-packages.nix that appeared superseded by the expressions in the elpa/melpa/melpaStable lists; the ones I left either seemed to have additional configuration that might render them unsuitable for using autogenerated info---though I suspect they could be change to be overrides---or where it appeared we had a more up-to-date version than was present in the generated files.
There were also some "emacs-modes" entries that appeared similarly out of date, though I did not drive that list to anywhere near completion.
If there are suggestions for ways to improve this, I'm happy to work on pushing it forward, though I would appreciate guidance.
cc @ttuegel

cc @oxij

I resolved this with a simple reordering of repositories, such that the generated repositories take precedence:
hand-rolled < melpa < elpa < melpa-stable
instead of
melpa < elpa < melpa-stable < hand-rolled
https://github.com/bendlas/nixpkgs/commit/c4f657a469fbd92aab3dd4a5602618a8443faf13
It seems to work out, and FWIW, I think this would make for a good transition.

It seems to work out, and FWIW, I think this would make for a good transition.

It should always work because the package sets are rigged to have consistent dependencies. I'm not sure it would make a good transition strategy: we need to override the derived expressions from the custom build steps in the hand-rolled expressions, but demoting the hand-rolled expressions simply removes the customized versions.

Always is a strong word in the face of package authors that never seem to get tired of hacking elisp ;)
But yeah, I get that we need to override incompatible packages from (m)elpa, thus my reordering is probably not a wise thing to do in general. To me it was a good step up from directly managing .emacs.d/elpa. Despite reordering, the newScope should lead to consistent deps anyway, no?
So, does removing everything hand-rolled, that's also in elpa or melpa-stable and then only introducing overrides for incompatibility or stuff that we want to pin from melpa, sound like a better plan to you?

Always is a strong word in the face of package authors that never seem to get tired of hacking elisp ;)

Heh, that's quite right. At least, the dependency set will always be consistent. It should be impossible to have two packages try to pull in different versions of a dependency. That's the most we can guarantee from the Nix side.

So, does removing everything hand-rolled, that's also in elpa or melpa-stable and then only introducing overrides for incompatibility or stuff that we want to pin from melpa, sound like a better plan to you?

Yes, I think that's the way to go.

@ttuegel I believe what you just said you thought was the way to go is basically what this PR does---not all of it, but a large chunk of it.
I see that it is now conflicting; I can resolve that, and I have at least one additional thing to remove, and I can probably find some more stuff, and I'm happy to do that work---but I would appreciate some active feedback to this PR as to whether you find it acceptable, before I spend more time on it.

@mdorman Unfortunately, I don't think this is ready in its current form. It doesn't seem that you made package overrides for the packages that have custom build phases, so I think it's unlikely that any of those packages will work. Also, unless you can test the new versions of all these packages, I think it would be better to remove one package per commit so that the package maintainers can quickly revert/evaluate if there is a problem. I realize that this is significantly more work; that's why I haven't done it yet myself. :frowning:

OK.

authors: bendlas jagajaga mdorman ttuegel


text:
mit-scheme: set MITSCHEME_LIBRARY_PATH properly

by changing its path and wrapping the correct binary
all the other binaries in bin/ are symlinks to bin/mit-scheme${arch}-${version}
therefore its easier to just wrap that one instead of all the others

Motivation for this change
Closes #137916
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)
[ ] 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 137950 at e9afd042 run on aarch64-linux 1

2 packages built successfully:

mitscheme
mitschemeX11

authors: Artturin r-rmcgibbo


text:
pythonPackages.bleak: 0.12.1 -> 0.13.0

Motivation for this change
Bump bleak to its latest 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)
[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 wip"
[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

[x] Fits CONTRIBUTING.md.

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

11 packages built:

home-assistant
idasen (python39Packages.idasen)
python38Packages.bleak
python38Packages.fjaraskupan
python38Packages.idasen
python38Packages.pykulersky
python38Packages.pyzerproc
python39Packages.bleak
python39Packages.fjaraskupan
python39Packages.pykulersky
python39Packages.pyzerproc


text:
python3Packages.asyncio-nats-client: 0.11.4 -> 0.11.5

Motivation for this change
Update to latest upstream release 0.11.5
Change log: https://github.com/nats-io/nats.py/releases/tag/v0.11.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, 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/)
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.

Will be part of #147426


text:
nixos/nextcloud: update warning for MariaDB >= 10.6

Motivation for this change
MariaDB 10.6 is not supported by Nextcloud 23 (https://github.com/nextcloud/server/issues/25436).
Things done
This PR updates the existing warning to include Nextcloud 23.

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.

@Ma27


text:
mime-types: drop, gentoo replaced it with mailcap, marked for removal

Motivation for this change
https://github.com/cachix/nixpkgs-unfree-redistributable
https://packages.gentoo.org/packages/app-misc/mime-types
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.

@jonringer can you take a look at this?

since this change causes over 500 rebuilds, do you mind targeting the staging branch
# finding the common merge base will avoid pinging all CODEOWNERs
common=$(git merge-base origin/master origin/staging)
git rebase --onto=$common HEAD~1 # or however many commits you want to pull
git push .. ... --force

then change the base branch in the github PR from master -> staging
See https://nixos.org/nixpkgs/manual/#submitting-changes-staging-branch for more details on staging branch

looks like go uses this package

since this change causes over 500 rebuilds, do you mind targeting the staging branch
# finding the common merge base will avoid pinging all CODEOWNERs
common=$(git merge-base origin/master origin/staging)
git rebase --onto=$common HEAD~1 # or however many commits you want to pull
git push .. ... --force

then change the base branch in the github PR from master -> staging
See nixos.org/nixpkgs/manual/#submitting-changes-staging-branch for more details on staging branch

That wasn't working because the merge conflict is/was on staging.

looks like go uses this package

go is already using mailcap, yes. They are technically mostly identically and mime-types can be replaced with mailcap. The only difference is that mailcap is more up to date and also has two or three other files.


text:
Groestlcoin: init at 22.0

Motivation for this change
Groestlcoin: init at 22.0
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.

@ofborg eval

@ofborg eval

@GrahamcOfBorg eval

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 156184 run on x86_64-linux 1

2 packages built:

groestlcoin
groestlcoind


text:
python310Packages.pyowm: 3.2.0 -> 3.3.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python310Packages.pyowm is: "Python wrapper around the OpenWeatherMap web API"
meta.homepage for python310Packages.pyowm is: "https://pyowm.readthedocs.io/"
meta.changelog for python310Packages.pyowm 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

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 3.3.0 with grep in /nix/store/ndgbiv252q0m0pck7z71bsccyng2rc6s-python3.10-pyowm-3.3.0

found 3.3.0 in filename of file in /nix/store/ndgbiv252q0m0pck7z71bsccyng2rc6s-python3.10-pyowm-3.3.0

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

5 total rebuild path(s)

3 package rebuild(s)

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

First fifty rebuilds by attrpath
home-assistant-component-tests.openweathermap
python310Packages.pyowm
python39Packages.pyowm

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/ndgbiv252q0m0pck7z71bsccyng2rc6s-python3.10-pyowm-3.3.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.pyowm https://github.com/r-ryantm/nixpkgs/archive/da9c48b2cf38800c8df24fff903cd047473fb742.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/ndgbiv252q0m0pck7z71bsccyng2rc6s-python3.10-pyowm-3.3.0
ls -la /nix/store/ndgbiv252q0m0pck7z71bsccyng2rc6s-python3.10-pyowm-3.3.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

3 packages built:

home-assistant-component-tests.openweathermap
python310Packages.pyowm
python39Packages.pyowm

Maintainer pings
cc @fabaff for testing.

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

3 packages built:

home-assistant-component-tests.openweathermap
python310Packages.pyowm
python39Packages.pyowm


text:
sunvox: 2.0c -> 2.0d

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/SunVox/versions.
meta.description for sunvox is: "Small, fast and powerful modular synthesizer with pattern-based sequencer"
meta.homepage for sunvox is: "http://www.warmplace.ru/soft/sunvox/"
meta.changelog for sunvox is: ""
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
Warning: no invocation of /nix/store/34p5ya7i9fhk9rblj712h8yi7nkhvnxj-SunVox-2.0d/bin/sunvox had a zero exit code or showed the expected version
0 of 1 passed binary check by having a zero exit code.
0 of 1 passed binary check by having the new version present in output.
found 2.0d with grep in /nix/store/34p5ya7i9fhk9rblj712h8yi7nkhvnxj-SunVox-2.0d
found 2.0d in filename of file in /nix/store/34p5ya7i9fhk9rblj712h8yi7nkhvnxj-SunVox-2.0d

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

1 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
0 x86_64-darwin rebuild(s)

First fifty rebuilds by attrpath
sunvox

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/34p5ya7i9fhk9rblj712h8yi7nkhvnxj-SunVox-2.0d \
  --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 sunvox https://github.com/r-ryantm/nixpkgs/archive/fd500214b068f3b0a891e74ad3200be6864813d1.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/34p5ya7i9fhk9rblj712h8yi7nkhvnxj-SunVox-2.0d
ls -la /nix/store/34p5ya7i9fhk9rblj712h8yi7nkhvnxj-SunVox-2.0d/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:

sunvox

Maintainer pings
cc @puffnfresh for testing.

According to the webpage of the project, 2.0e is available

authors: WolfangAukang r-ryantm


text:
thunderbird-unwrapped: 91.7.0 -> 91.8.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for thunderbird-unwrapped is: "A full-featured e-mail client"
meta.homepage for thunderbird-unwrapped is: "https://thunderbird.net/"
meta.changelog for thunderbird-unwrapped is: ""
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
Warning: no invocation of /nix/store/cyiljmr27a8arcxyk4y9p84ykpwk2gyp-thunderbird-unwrapped-91.8.0/bin/thunderbird had a zero exit code or showed the expected version
Warning: no invocation of /nix/store/cyiljmr27a8arcxyk4y9p84ykpwk2gyp-thunderbird-unwrapped-91.8.0/bin/.thunderbird-wrapped had a zero exit code or showed the expected version
0 of 2 passed binary check by having a zero exit code.
0 of 2 passed binary check by having the new version present in output.
found 91.8.0 with grep in /nix/store/cyiljmr27a8arcxyk4y9p84ykpwk2gyp-thunderbird-unwrapped-91.8.0
found 91.8.0 in filename of file in /nix/store/cyiljmr27a8arcxyk4y9p84ykpwk2gyp-thunderbird-unwrapped-91.8.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
thunderbird-unwrapped
thunderbirdPackages.thunderbird

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/cyiljmr27a8arcxyk4y9p84ykpwk2gyp-thunderbird-unwrapped-91.8.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 thunderbird-unwrapped https://github.com/r-ryantm/nixpkgs/archive/4c2a906df5a9657149999038d065417aab39e322.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/cyiljmr27a8arcxyk4y9p84ykpwk2gyp-thunderbird-unwrapped-91.8.0
ls -la /nix/store/cyiljmr27a8arcxyk4y9p84ykpwk2gyp-thunderbird-unwrapped-91.8.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

3 packages built:

thunderbird
thunderbird-unwrapped
thunderbird-wayland

Maintainer pings
cc @edolstra @lovesegfault @nbp @vcunat for testing.

This forces my gmail account to relogin, but that pop-up... doesn't work.  I enter my e-mail address and it asks again for the address (or phone).  Can anyone else test this?

Oh, testers beware. Apparently the upgrade just triggered the logout and the same breakage happens for me even with the previous version :-(

I didn't manage to add the account anew either.  I'd certainly prefer to block merging until more light is shed on this or until other people confirm that their cases aren't broken.

For reference, adding the same account on a fresh profile works well.  I've been reluctant to remove the account inside the old profile, as it has 13 GB (mostly nixpkgs notifications over many years).

So apparently it's my mistake of disabling cookies and others seem unlikely to be affected, but who would've guess that I need them in an e-mail client.

There is a high security vulnerability fixed in this release: https://www.mozilla.org/en-US/security/advisories/mfsa2022-15/

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

1 package built:

thunderbird-unwrapped (thunderbirdPackages.thunderbird)

authors: r-ryantm thiagokokada vcunat


text:
uboot: 2022.01 -> 2022.04

Description of changes

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.

Result of nixpkgs-review pr 170564 run on aarch64-linux 1

19 packages built:

ubootBananaPim64
ubootNanoPCT4
ubootOdroidC2
ubootOlimexA64Olinuxino
ubootOrangePiZero2
ubootOrangePiZeroPlus2H5
ubootPine64
ubootPine64LTS
ubootPinebook
ubootPinebookPro
ubootQemuAarch64
ubootROCPCRK3399
ubootRaspberryPi3_64bit
ubootRaspberryPi4_64bit
ubootRock64
ubootRockPi4
ubootRockPro64
ubootSopine
ubootTools

I did some testing of the cross builds:
$ NIXPKGS_ALLOW_UNFREE=1 nix-build -A pkgsCross.aarch64-multiplatform.ubootOdroidC2 -A pkgsCross.armv7l-hf-multiplatform.ubootOdroidXU3 -A ubootQemuX86
[...]
/nix/store/s97s69klg1drxn9camvrmzssnhnnbqdx-uboot-odroid-c2_defconfig-aarch64-unknown-linux-gnu-2022.04
/nix/store/c96sdvm7d426wrnfwhb05mffji4k4kis-uboot-odroid-xu3_defconfig-armv7l-unknown-linux-gnueabihf-2022.04
/nix/store/ph67wkkarbv0vc399pfb85vgzsdzkz2a-uboot-qemu-x86_defconfig-2022.04

So it looks like U-Boot itself still cross-compiles on AArch32 and 64 just fine. Maybe there are some dependencies which don't; I didn't test every U-Boot.

authors: lovesegfault tpwrules


text:
php.mkExtension: make source name agnostic

Description of changes
PHP obtained from Git contains files directly in the top-level directory, which will be placed in Nix store. The generic builder will then copy it to the /build sandbox as its basename with hash stripped (e.g. source/). This breaks the assumption of mkExtension, which expects that PHP’s source will be extracted into php-«version»/ directory, since that is what the release tarballs contain.
Let’s unset the sourceRoot, leaving it to unpackPhase to find the source directory. Then, we will be able go to the extension directory from there.
While at it, clean up the expression a bit.
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.

That was something I already encountered when trying to compile PHP from Github, but had no clue on how to fix it, and you did it gracefully !

authors: drupol jtojnar


text:
ps3iso-utils: init at 277db7de

Description of changes
Initialize ps3iso-utils at 277db7de
Related: #182972 (init ps3-disc-dumper)

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.

Superseded by https://github.com/NixOS/nixpkgs/pull/251696

authors: evanjs tomberek


text:
rng-tools: remove redundant null checks & with lib over entire file

Description of changes

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

[ ] Fits CONTRIBUTING.md.

@ofborg build rng-tools

No description, no context, no rationale, no linked issue?
And self-merged without review.

The PR/commit title is the description and the motivation is to update older packages to current standards and increase the quality of the code. In NixOS we do not create issues for every little bit just for the issue creating.  Also you had 3 weeks to react and since this does not trigger a rebuild it is safe to merge.


text:
cbfmt: 0.1.4 -> 0.2.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/lukas-reineke/cbfmt/releases.
meta.description for cbfmt is: "A tool to format codeblocks inside markdown and org documents"
meta.homepage for cbfmt is: "https://github.com/lukas-reineke/cbfmt"
meta.changelog for cbfmt is: ""
Updates performed

Rust 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
found 0.2.0 with grep in /nix/store/jmhz3bx48dsaxdx303g5b1343px03g3z-cbfmt-0.2.0
found 0.2.0 in filename of file in /nix/store/jmhz3bx48dsaxdx303g5b1343px03g3z-cbfmt-0.2.0

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

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
cbfmt

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/jmhz3bx48dsaxdx303g5b1343px03g3z-cbfmt-0.2.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 cbfmt https://github.com/r-ryantm/nixpkgs/archive/b598372fd4b46e41da5b759cdd02b73921b8ad67.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/jmhz3bx48dsaxdx303g5b1343px03g3z-cbfmt-0.2.0
ls -la /nix/store/jmhz3bx48dsaxdx303g5b1343px03g3z-cbfmt-0.2.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

1 package built:

cbfmt

Maintainer pings
cc @stehessel for testing.

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

1 package built:

cbfmt

authors: r-ryantm superherointj