text:
AssertionError: Feature file for image 16395 does not exist.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Traceback (most recent call last):
File "train_uniter.py", line 181, in
config['test_loader'].append(test_data_loader(os.path.join(config['data_path'], test_file)))
File "train_uniter.py", line 176, in test_data_loader
confidence_threshold=config['object_conf_thresh'])
File "/content/drive/My Drive/meme_challenge/data/dataset_template.py", line 66, in init
self._prepare_data_list()
File "/content/drive/My Drive/meme_challenge/data/meme_dataset.py", line 38, in _prepare_data_list
self._load_dataset()
File "/content/drive/My Drive/meme_challenge/data/meme_dataset.py", line 71, in _load_dataset
assert os.path.isfile(feature_file_name), "Feature file for image {} does not exist.".format(img_id)
AssertionError: Feature file for image 16395 does not exist.
This is showing me the feature file does not exist for image 16395  but i have feature file with 16395.npy and 16395_info.npy in own_feature.
can you please help me out

I have the same issue.

I have met the same issue. Could you tell me how you solved it? My email: 15984767192@163.com. Thx a lot!

I have met the same issue. Could you tell me how you solved it? My email: [15984767195@163.com]. Thx a lot!


text:
Switching channels.nixos.org to Fastly

An issue to track the progress.

[x] configure fastly service
[x] configure TLS subscription
[ ] update DNS record

Old CNAME value: d1xrxbai5t99bx.cloudfront.net

source: gharchive/issue

repo: NixOS/nixos-org-configurations

license: MIT

license_type: permissive

license_source: github-api


text:
Aliza

Hi , please update medical-applications Aliza --> default.nix
version = "1.98.57-2";
src = fetchurl {
# See https://www.aliza-dicom-viewer.com/download
urls = [
"https://www.dropbox.com/s/py0w8kqg3xjvmac/aliza-1.98.57-2.x86_64.rpm"
];
sha256 = "01qk2gadmc24pmfdnmpiz7vgfiqkvhznyq9rsr153frscg76gc9b";

Please file this to nixos/nixpkgs. This project is just pulling package information from that repo.

authors: mrbitt ysndr

repo: NixOS/nixos-search


text:
Adding r8168 to extraModulePackages fails.

Description of issue
On rebuilding my system I get these errors:
> sudo nixos-rebuild switch --flake '/etc/nixos#amdboi'
warning: Git tree '/etc/nixos' is dirty
building the system configuration...
warning: Git tree '/etc/nixos' is dirty
error: --- Error ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- nix
builder for '/nix/store/n13jpfkwz2gmg2jzp0r0jjmr8ahwxrvc-r8168-5.8.16-8.047.04.drv' failed with exit code 2; last 10 log lines:
  mkdir: cannot create directory '.tmp_222': Permission denied
  mkdir: cannot create directory '.tmp_224': Permission denied
  mkdir: cannot create directory '.tmp_226': Permission denied
  ln: failed to create symbolic link 'source': Permission denied
  make[2]: *** [/nix/store/57mqa0m4irymdpyl60a0sbylkrcbvw4h-linux-5.8.16-dev/lib/modules/5.8.16/source/Makefile:552: outputmakefile] Error 1
  make[1]: *** [/nix/store/57mqa0m4irymdpyl60a0sbylkrcbvw4h-linux-5.8.16-dev/lib/modules/5.8.16/source/Makefile:711: include/config/auto.conf.cmd] Error 2
  make[1]: *** [include/config/auto.conf.cmd] Deleting file 'include/generated/autoconf.h'
  make[1]: unlink: include/generated/autoconf.h: Permission denied
  make: *** [/nix/store/57mqa0m4irymdpyl60a0sbylkrcbvw4h-linux-5.8.16-dev/lib/modules/5.8.16/source/Makefile:185: __sub-make] Error 2
  make: Leaving directory '/nix/store/57mqa0m4irymdpyl60a0sbylkrcbvw4h-linux-5.8.16-dev/lib/modules/5.8.16/build'
error: --- Error ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- nix
1 dependencies of derivation '/nix/store/2adqrvfk7n1x30jh0rw5w8klghz87f9s-kernel-modules.drv' failed to build
error: --- Error ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- nix
1 dependencies of derivation '/nix/store/l525iq3kjpl9qidr2sic407z7yfgw6vb-linux-5.8.16-modules.drv' failed to build
error: --- Error ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- nix
1 dependencies of derivation '/nix/store/2z1cx034mvs3z0rvb5jj7khcxkjl4rrl-nixos-system-amdboi-20.09.20201024.95d26c9.drv' failed to build

To Reproduce
Steps to reproduce the behavior:

have this in conf:

boot.extraModulePackages = [
  config.boot.kernelPackages.r8168
];

Expected behavior
No errors I guess.
Notify maintainers

@timokau
Additional context
I've started managing my system config with flakes. Hopefully I'm doing it right.
Metadata
 - system: `"x86_64-linux"`
 - host os: `Linux 5.8.16, NixOS, 20.09.20201024.95d26c9 (Nightingale)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 3.0pre20201020_e0ca98c`
 - channels(kazimazi): `""`
 - channels(root): `"nixos-20.09beta1411.95d26c9a9f2, nixos-stable-20.03.3158.7c2a362b58a, nixos-unstable-21.03pre248170.007126eef72"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

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

Oops just saw that it's marked as broken: #101736 anyway I leave it open if anyone has some temporary solution.

See https://github.com/NixOS/nixpkgs/pull/93620 (@lovesegfault).

I didn't get around to kernel modules. I wanted a better way to express kernel "variants". This is being done in https://github.com/NixOS/nixpkgs/pull/102005

#93620 is merged, r8168 is able to be built with default linuxPackages.kernel and linuxPackages_latest.kernel, therefore I'm closing this issue.

authors: Kazimazi jonringer kisik21 timokau

repo: NixOS/nixpkgs


text:
GNOME Terminal assumes Dvorak keycodes are QWERTY and converts them to Dvorak for a second time, breaking copy paste and other shortcuts

Describe the bug
My laptop keyboard is a QWERTY keyboard which emits QWERTY keycodes. When I use it, I switch my GNOME input settings to be English (Dvorak).
My desk keyboard is a Kinesis Advantage which I type Dvorak on, and it internally translates them to QWERTY keycodes. When I use it, I switch my GNOME input settings to be English (US).
When I use the Laptop keyboard and type with my input settings set to English (Dvorak), my keystrokes are registered as Dvorak keystrokes. If I type the Dvorak letters for "Hello, v" then the terminal properly records "Hello, v". If I copy some text from another window and paste with Ctrl-Shift-v, it pastes. If I select some text in the terminal and press Ctrl-Shift-c, it copies.
When I use the Kinesis keyboard and type my input settings set to English (US), my keystrokes are registered as Dvorak keystrokes. If I type the Dvorak letters for "Hello, v" then the terminal properly records "Hello, v". Here comes the bug: when I press Ctrl-Shift-v, it does not paste. If I select some text in the terminal and press Ctrl-Shift-c, it does not copy. If I then use my laptop keyboard while the system is still set to English (US) and press Ctrl-Shift-v (where v in this case is the dvorak position of v, and is a period on the keyboard, meaning the keycode for a . is sent) the terminal incorrectly according to my system's input settings interprets it as a v and pastes.
GNOME Terminal appears to be reinterpreting the already-dvorak keystrokes from QWERTY to Dvorak for a second round. If I press Ctrl-Shift-period (on a QWERTY keyboard, the . is in the same physical location as the v is on Dvorak) the terminal pastes.
I am reporting this here because upstream says users shouldn't report bugs, and also that this is not a bug. I believe this is a bug because my opinion is that I should be able to use Ctrl-Shift-v and Ctrl-Shift-c to paste and copy.
Upstream (closed) ticket: https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/189
Notify maintainers
@NixOS/gnome
Metadata

system: "x86_64-linux"
host os: Linux 5.9.16, NixOS, 20.09.2624.1eff582e7ea (Nightingale)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.4pre20201201_5a6ddb3
channels(root): "flox, nixos-20.09.2016.19db3e5ea27, nixos_stage-20.09beta913.81217f0f69a"
channels(grahamc): "flox"
nixpkgs: /etc/nixpkgs

I have had this buggy behavior in other applications as well. VSCode, for example: https://github.com/Microsoft/vscode/issues/23991

I have had this buggy behavior in other applications as well. VSCode, for example: https://github.com/Microsoft/vscode/issues/23991

This issue for vscode haunts me daily 😭

This issue for vscode haunts me daily 😭

If I then use my laptop keyboard while the system is still set to English (US) and press Ctrl-Shift-v (where v in this case is the dvorak position of v, and is a period on the keyboard, meaning the keycode for a . is sent) the terminal incorrectly according to my system's input settings interprets it as a v and pastes.

At least this definitely sounds like a bug if you are pressing a period on QWERTY keyboard with QWERTY layout and it gets recognized as a v.
I assume you added the layouts using Control Center (GNOME’s Settings app) and are switching them using the top panel or a keyboard shortcut. Also could you confirm whether you are running X or Wayland session ($XDG_SESSION_TYPE env var) and if you have IBus NixOS module enabled? And maybe double check the sent keycodes using xev or sudo libinput debug-events --show-keycodes.

If I then use my laptop keyboard while the system is still set to English (US) and press Ctrl-Shift-v (where v in this case is the dvorak position of v, and is a period on the keyboard, meaning the keycode for a . is sent) the terminal incorrectly according to my system's input settings interprets it as a v and pastes.

At least this definitely sounds like a bug if you are pressing a period on QWERTY keyboard with QWERTY layout and it gets recognized as a v.
I assume you added the layouts using Control Center (GNOME’s Settings app) and are switching them using the top panel or a keyboard shortcut. Also could you confirm whether you are running X or Wayland session ($XDG_SESSION_TYPE env var) and if you have IBus NixOS module enabled? And maybe double check the sent keycodes using xev or sudo libinput debug-events --show-keycodes.

Maybe this is the bug: https://gitlab.gnome.org/GNOME/gtk/-/issues/1825#note_558020

Maybe this is the bug: https://gitlab.gnome.org/GNOME/gtk/-/issues/1825#note_558020

I assume you added the layouts using Control Center (GNOME’s Settings app) and are switching them using the top panel or a keyboard shortcut.

Yep!

Also could you confirm whether you are running X or Wayland session ($XDG_SESSION_TYPE env var)

$ echo $XDG_SESSION_TYPE
wayland

and if you have IBus NixOS module enabled?

I don't have anything manually enabled, and:
$ nixos-option i18n.inputMethod.ibus.engines
Value:
[ ]

Default:
[ ]

And maybe double check the sent keycodes using xev or sudo libinput debug-events --show-keycodes.

My machine has is in QWERTY mode -- English (US).
On the laptop keyboard, pressing Ctrl, Shift, I (the symbol on the key says I, which is the Dvorak location for C) individually:
 event0   KEYBOARD_KEY     +0.353s	KEY_LEFTCTRL (29) pressed
 event0   KEYBOARD_KEY     +0.580s	KEY_LEFTCTRL (29) released
 event0   KEYBOARD_KEY     +0.953s	KEY_I (23) pressed
 event0   KEYBOARD_KEY     +1.243s	KEY_I (23) released
 event0   KEYBOARD_KEY     +2.329s	KEY_LEFTCTRL (29) pressed
 event0   KEYBOARD_KEY     +2.453s	KEY_LEFTCTRL (29) released

On the kinesis, pressing Control, Shift, C (which is in the physical location of the I key, but my Kineslis keyboard is configured to internally convert that to Dvorak):
 event256  KEYBOARD_KEY     +0.000s	KEY_LEFTCTRL (29) pressed
 event256  KEYBOARD_KEY     +0.148s	KEY_LEFTCTRL (29) released
 event256  KEYBOARD_KEY     +0.385s	KEY_LEFTSHIFT (42) pressed
 event256  KEYBOARD_KEY     +0.559s	KEY_LEFTSHIFT (42) released
 event256  KEYBOARD_KEY     +0.831s	KEY_C (46) pressed
 event256  KEYBOARD_KEY     +0.944s	KEY_C (46) released

On the laptop keyboard, pressing Ctrl, Shift, I (the symbol on the key says I, which is the Dvorak location for C) together. Note: This correctly copied the text I had selected:
 event0   KEYBOARD_KEY     +2.945s	KEY_LEFTCTRL (29) pressed
 event0   KEYBOARD_KEY     +2.984s	KEY_LEFTSHIFT (42) pressed
 event0   KEYBOARD_KEY     +3.454s	KEY_I (23) pressed
 event0   KEYBOARD_KEY     +3.571s	KEY_I (23) released
 event0   KEYBOARD_KEY     +3.799s	KEY_LEFTSHIFT (42) released
 event0   KEYBOARD_KEY     +3.807s	KEY_LEFTCTRL (29) released

On the kinesis, pressing Control, Shift, C (which is in the physical location of the I key, but my Kineslis keyboard is configured to internally convert that to Dvorak) together. Note: this does not actually copy:
 event256  KEYBOARD_KEY     +2.936s	KEY_LEFTCTRL (29) pressed
 event256  KEYBOARD_KEY     +2.948s	KEY_LEFTSHIFT (42) pressed
 event256  KEYBOARD_KEY     +3.204s	KEY_C (46) pressed
 event256  KEYBOARD_KEY     +3.336s	KEY_C (46) released
 event256  KEYBOARD_KEY     +3.536s	KEY_LEFTCTRL (29) released
 event256  KEYBOARD_KEY     +3.540s	KEY_LEFTSHIFT (42) released

Some weirdness:
On the kinesis, if I instead press Control, Shift, . (which is in the physical location of the E key, but my Kineslis keyboard is configured to internally convert that to Dvorak) together, it does manage to paste:
 event256  KEYBOARD_KEY     +2.218s	KEY_LEFTCTRL (29) pressed
 event256  KEYBOARD_KEY     +2.230s	KEY_LEFTSHIFT (42) pressed
 event256  KEYBOARD_KEY     +3.064s	KEY_DOT (52) pressed
 event256  KEYBOARD_KEY     +3.182s	KEY_DOT (52) released
 event256  KEYBOARD_KEY     +3.220s	KEY_LEFTSHIFT (42) released
 event256  KEYBOARD_KEY     +3.232s	KEY_LEFTCTRL (29) released

Some weirdness which points to this having to do specifically with Shift being involved...:
On the kinesis, if I instead press Control, c (which is in the physical location of the I key, but my Kineslis keyboard is configured to internally convert that to Dvorak) together, it correctly terminates processes:
 event256  KEYBOARD_KEY     +2.890s	KEY_LEFTCTRL (29) pressed
 event256  KEYBOARD_KEY     +3.084s	KEY_C (46) pressed
 event256  KEYBOARD_KEY     +3.182s	KEY_C (46) released
 event256  KEYBOARD_KEY     +3.194s	KEY_LEFTCTRL (29) released

On the laptop keyboard, pressing Ctrl, I (the symbol on the key says I, which is the Dvorak location for C) together, it does not terminate process:
-event0   KEYBOARD_KEY     +11.546s	KEY_LEFTCTRL (29) pressed
 event0   KEYBOARD_KEY     +11.797s	KEY_I (23) pressed
 event0   KEYBOARD_KEY     +11.909s	KEY_I (23) released
 event0   KEYBOARD_KEY     +11.998s	KEY_LEFTCTRL (29) released

I assume you added the layouts using Control Center (GNOME’s Settings app) and are switching them using the top panel or a keyboard shortcut.

Yep!

Also could you confirm whether you are running X or Wayland session ($XDG_SESSION_TYPE env var)

$ echo $XDG_SESSION_TYPE
wayland

and if you have IBus NixOS module enabled?

I don't have anything manually enabled, and:
$ nixos-option i18n.inputMethod.ibus.engines
Value:
[ ]

Default:
[ ]

And maybe double check the sent keycodes using xev or sudo libinput debug-events --show-keycodes.

My machine has is in QWERTY mode -- English (US).
On the laptop keyboard, pressing Ctrl, Shift, I (the symbol on the key says I, which is the Dvorak location for C) individually:
 event0   KEYBOARD_KEY     +0.353s	KEY_LEFTCTRL (29) pressed
 event0   KEYBOARD_KEY     +0.580s	KEY_LEFTCTRL (29) released
 event0   KEYBOARD_KEY     +0.953s	KEY_I (23) pressed
 event0   KEYBOARD_KEY     +1.243s	KEY_I (23) released
 event0   KEYBOARD_KEY     +2.329s	KEY_LEFTCTRL (29) pressed
 event0   KEYBOARD_KEY     +2.453s	KEY_LEFTCTRL (29) released

On the kinesis, pressing Control, Shift, C (which is in the physical location of the I key, but my Kineslis keyboard is configured to internally convert that to Dvorak):
 event256  KEYBOARD_KEY     +0.000s	KEY_LEFTCTRL (29) pressed
 event256  KEYBOARD_KEY     +0.148s	KEY_LEFTCTRL (29) released
 event256  KEYBOARD_KEY     +0.385s	KEY_LEFTSHIFT (42) pressed
 event256  KEYBOARD_KEY     +0.559s	KEY_LEFTSHIFT (42) released
 event256  KEYBOARD_KEY     +0.831s	KEY_C (46) pressed
 event256  KEYBOARD_KEY     +0.944s	KEY_C (46) released

On the laptop keyboard, pressing Ctrl, Shift, I (the symbol on the key says I, which is the Dvorak location for C) together. Note: This correctly copied the text I had selected:
 event0   KEYBOARD_KEY     +2.945s	KEY_LEFTCTRL (29) pressed
 event0   KEYBOARD_KEY     +2.984s	KEY_LEFTSHIFT (42) pressed
 event0   KEYBOARD_KEY     +3.454s	KEY_I (23) pressed
 event0   KEYBOARD_KEY     +3.571s	KEY_I (23) released
 event0   KEYBOARD_KEY     +3.799s	KEY_LEFTSHIFT (42) released
 event0   KEYBOARD_KEY     +3.807s	KEY_LEFTCTRL (29) released

On the kinesis, pressing Control, Shift, C (which is in the physical location of the I key, but my Kineslis keyboard is configured to internally convert that to Dvorak) together. Note: this does not actually copy:
 event256  KEYBOARD_KEY     +2.936s	KEY_LEFTCTRL (29) pressed
 event256  KEYBOARD_KEY     +2.948s	KEY_LEFTSHIFT (42) pressed
 event256  KEYBOARD_KEY     +3.204s	KEY_C (46) pressed
 event256  KEYBOARD_KEY     +3.336s	KEY_C (46) released
 event256  KEYBOARD_KEY     +3.536s	KEY_LEFTCTRL (29) released
 event256  KEYBOARD_KEY     +3.540s	KEY_LEFTSHIFT (42) released

Some weirdness:
On the kinesis, if I instead press Control, Shift, . (which is in the physical location of the E key, but my Kineslis keyboard is configured to internally convert that to Dvorak) together, it does manage to paste:
 event256  KEYBOARD_KEY     +2.218s	KEY_LEFTCTRL (29) pressed
 event256  KEYBOARD_KEY     +2.230s	KEY_LEFTSHIFT (42) pressed
 event256  KEYBOARD_KEY     +3.064s	KEY_DOT (52) pressed
 event256  KEYBOARD_KEY     +3.182s	KEY_DOT (52) released
 event256  KEYBOARD_KEY     +3.220s	KEY_LEFTSHIFT (42) released
 event256  KEYBOARD_KEY     +3.232s	KEY_LEFTCTRL (29) released

Some weirdness which points to this having to do specifically with Shift being involved...:
On the kinesis, if I instead press Control, c (which is in the physical location of the I key, but my Kineslis keyboard is configured to internally convert that to Dvorak) together, it correctly terminates processes:
 event256  KEYBOARD_KEY     +2.890s	KEY_LEFTCTRL (29) pressed
 event256  KEYBOARD_KEY     +3.084s	KEY_C (46) pressed
 event256  KEYBOARD_KEY     +3.182s	KEY_C (46) released
 event256  KEYBOARD_KEY     +3.194s	KEY_LEFTCTRL (29) released

On the laptop keyboard, pressing Ctrl, I (the symbol on the key says I, which is the Dvorak location for C) together, it does not terminate process:
-event0   KEYBOARD_KEY     +11.546s	KEY_LEFTCTRL (29) pressed
 event0   KEYBOARD_KEY     +11.797s	KEY_I (23) pressed
 event0   KEYBOARD_KEY     +11.909s	KEY_I (23) released
 event0   KEYBOARD_KEY     +11.998s	KEY_LEFTCTRL (29) released

This issue for vscode haunts me daily sob

@aanderse you can fix this easily! Add this to your vscode settings:
 "keyboard.dispatch": "keyCode"

This issue for vscode haunts me daily sob

@aanderse you can fix this easily! Add this to your vscode settings:
 "keyboard.dispatch": "keyCode"

You're a wonderful human being @grahamc!

You're a wonderful human being @grahamc!

This appears to be a problem when pasting in to Gnome Calendar as well.

This appears to be a problem when pasting in to Gnome Calendar as well.

According to the issue, it should be a problem in any GTK 3 app.

According to the issue, it should be a problem in any GTK 3 app.

This has been fixed in GTK 3.24.28.

authors: aanderse grahamc jtojnar


text:
Vulnerability roundup 99: coturn-4.5.1.3: 1 advisory [7.2]

search, files

[ ] CVE-2020-26262 CVSSv3=7.2 (nixos-20.09)

Scanned versions: nixos-20.09: 95ce0f52ec1.
Cc @ralith

20.09 is EOL.
@ckauhaus: Could your process notify also maintainers from master?

20.09 is EOL, so the issue can be closed. @0x4A6F's suggestion is a good idea.

authors: 0x4A6F FliegendeWurst ckauhaus


text:
supertag fails to compile

Describe the bug
error: builder for '/nix/store/wxwd5b1zyylvzbjmrs35gy40g3fhb085-supertag-0.1.4.drv' failed with exit code 101;
       last 10 log lines:
       >
       > error: aborting due to 27 previous errors
       >
       > Some errors have detailed explanations: E0277, E0308.
       > For more information about an error, try `rustc --explain E0277`.
       > error: could not compile `lexical-core`
       >
       > To learn more, run the command again with --verbose.
       > warning: build failed, waiting for other jobs to finish...
       > error: build failed
       For full logs, run 'nix log /nix/store/wxwd5b1zyylvzbjmrs35gy40g3fhb085-supertag-0.1.4.drv'.

Notify maintainers
@oxzi
Metadata
 - system: `"x86_64-linux"`
 - host os: `Linux 5.14.5, NixOS, 21.11 (Porcupine)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.4pre20210908_3c56f62`
 - channels(root): `"home-manager, nixos-21.11pre294801.432fc2d9a67"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

this is due to supertag using an old version of lexical-core which is incompatible with new versions of rust, which is fixed upstream in rust-lexical here, but supertag hasn't updated its dependencies and made a new release yet
A easy fix would be to patch its Cargo.lock to use a newer version of lexical-core
hydra failure if anyone is interested

authors: figsoda suhr


text:
pwgen-secure fails to find its word list

Describe the bug
$ spwgen -d w
Debug mode enabled. Verbosity = 11
Arguments:
{'-a': False,
 '-d': True,
 '-n': None,
 '-t': False,
 '-v': 0,
 '<class-option>': None,
 '<class>': 'w'}
Password count: 1
Generating passphrase
Traceback (most recent call last):
  File "/nix/store/78ym0d5b4ik3rrni53cqrfpyky9hxbvh-pwgen-secure-0.9.1/bin/.spwgen-wrapped", line 123, in <module>
    r.render_password()
  File "/nix/store/78ym0d5b4ik3rrni53cqrfpyky9hxbvh-pwgen-secure-0.9.1/lib/python3.9/site-packages/pwgen_secure/rpg.py", line 361, in render_password
    passwords.append(self.generate_password())
  File "/nix/store/78ym0d5b4ik3rrni53cqrfpyky9hxbvh-pwgen-secure-0.9.1/lib/python3.9/site-packages/pwgen_secure/rpg.py", line 352, in generate_password
    return self.generate_pass_phrase()
  File "/nix/store/78ym0d5b4ik3rrni53cqrfpyky9hxbvh-pwgen-secure-0.9.1/lib/python3.9/site-packages/pwgen_secure/rpg.py", line 323, in generate_pass_phrase
    with open(word_list_path) as infile:
FileNotFoundError: [Errno 2] No such file or directory: '/nix/store/78ym0d5b4ik3rrni53cqrfpyky9hxbvh-pwgen-secure-0.9.1/lib/python3.9/site-packages/pwgen_secure/words.txt'

Steps To Reproduce
Steps to reproduce the behavior:

Install pwgen-secure nixpkgs pkg from nixpkgs rev 74b10859829153d5c5d50f7c77b86763759e8654 or later.
Invoke pwgen-secure w in terminal.

Expected behavior
For the tool to output a password (read: passphrase) of words.
Additional context
$ tree -I *.pyc /nix/store/78ym0d5b4ik3rrni53cqrfpyky9hxbvh-pwgen-secure-0.9.1/lib/python3.9/site-packages/pwgen_secure
/nix/store/78ym0d5b4ik3rrni53cqrfpyky9hxbvh-pwgen-secure-0.9.1/lib/python3.9/site-packages/pwgen_secure
├── fileRandomizer.py
├── __init__.py
├── __pycache__
├── rpg.py
└── search_space_calculator.py

Notify maintainers
@peterhoeg
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.16.8, NixOS, 22.05 (Quokka)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.4`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Thanks for the detailed bug report.
If you have any questions about the linked PR with the fix, please shout.
As for the bump to latest master, we typically stick to released versions unless there are show-stopper bugs that are addresses in an unreleased version.

Thanks for the detailed bug report.

Yw, thanks for maintaining the software here at nixpkgs!

If you have any questions about the linked PR with the fix, please shout.

Will do! Will test tomorrow if I remember, getting late here.

As for the bump to latest master, we typically stick to released versions unless there are show-stopper bugs that are addresses in an unreleased version.

Fair!


text:
22.05 Feature Freeze

It's time for another feature freeze!
Let's clarify any blocking concerns for the 22.05 release in this thread, which will go live on May 30th.
Feature Freeze issue of th previous release: #140168
Release Schedule: #165792
Edit: I have crossed out subsystems that have responded that there are no blockers
Nix/nix-cli ecosystem: @Profpatsch @edolstra @grahamc @nbp
Mobile: @samueldr
NixOS Modules / internals: @ericson2314 @infinisil @alyssais @roberth
NixOS tests: @tfc
Marketing: @garbas @tomberek
Docs: @ryantm
Release: @NixOS/nixos-release-managers
Darwin: @NixOS/darwin-maintainers
BEAM: @NixOS/beam @minijackson
C: @matthewbauer @mic92
Coq: @CohenCyril @Zimmi48 @siraben @vbgl
Dhall: @Gabriel439 @ehmry
Emacs: @adisbladis
Vim/Neovim: @jonringer @softinio @teto
Go: @c00w @cstrahan @Frostman @kalbasit @mic92 @orivej @rvolosatovs @zowoq
Haskell: @NixOS/haskell
Python: @fridh @mweinelt @jonringer
Perl: @stigtsp
PHP: @NixOS/php @ma27
Ruby: @marsam
Rust: @andir @lnl7 @mic92 @zowoq
R: @bcdarwin @jbedo
Bazel: @mboes @marsam @uri-canva @avdv @olebedev @groodt @aherrmann @ylecornec
Blockchains: @mmahut @RaghavSood
Cinnamon: @mkg20001
DockerTools: @roberth @utdemir
GNOME: @NixOS/gnome @bobby285271 @dasj19 @maxeaubrey
Pantheon: @NixOS/pantheon
Podman: @NixOS/podman
PostgreSQL: @thoughtpolice
Qt / KDE: @NixOS/qt-kde
systemd: @NixOS/systemd
Everyone else: @NixOS/nixpkgs-committers @NixOS/release-engineers
If you think some subsystem/person/GitHub team should be added or removed for the next release, you can modify the list here.
No issue is too big or too small, but let's remember that we are all working on the project voluntarily in our free time here, so let's focus on the issues that can be realistically addressed by release time. Thanks everyone!

Additional mentions because GitHub seems to stop pinging after I pinged too many people:
Blockchains: @mmahut @RaghavSood
Cinnamon: @mkg20001
DockerTools: @roberth @utdemir
GNOME: @bobby285271 @dasj19 @maxeaubrey
PostgreSQL: @thoughtpolice

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/22-05-feature-freeze/18453/1

For @NixOS/beam i do not think we have anything that could be blocking on the docket.

For Crystal, we have the crystal-lang team.
Two issues that I absolutely want to get in before 22.05 is released:

https://github.com/NixOS/nixpkgs/issues/164648
https://github.com/NixOS/nixpkgs/issues/167044

@peterhoeg Thanks, I added them to the Blockers project. If you want to add the team to the next announcement, you can just set the featureFreezePing flag in the list :)

I'm not really up on what is going on with the docs themselves, but I'm not aware of anything blocking the technical aspect of generating the docs. I don't have much to report on progress with generating the docs either. mmdoc is now packaged in nixpkgs, but it still needs more work to be a polished solution.

No blockers for @NixOS/Pantheon, we are already shipping the latest Pantheon 6.1 and Pantheon 7 is not likely to happen in this release due to upstream delay.

since I've noticed you started crossing topics:

no blocker for the lua ecosystem
for (neo)vim, there will be a neovim release in 2 weeks and I would like to merge https://github.com/NixOS/nixpkgs/pull/166941 . None should be an issue though, I've already updated the required dependencies for neovim master

No blocker for PHP as far as I know :)

No blocker for PHP as far as I know :)

I think we should tackle this at the next version: https://github.com/NixOS/nixpkgs/issues/154774

Python is currently in a good state. We're doing regular package set updates and have one more cycle in #166489 that we'll hopefully get into the next staging cycle.
PyPy3 currently fails to build due a regression after the zlib update.

No blocker for PHP as far as I know :)

I think we should tackle this at the next version: #154774

For sure, but we're too close to a release for that. We can do that right after branchoff which isn't relevant for this thread.

On behalf of the newly created @NixOS/cuda-maintainers, we're finishing an important major bump (cudnn 7.6 -> 8.3, cuda 10.1 -> 11.4) that we'd like to get into the release. There are a few failing packages that hadn't been tested with CUDA until now, that we would like to meet the release in an already fixed state: https://github.com/NixOS/nixpkgs/issues/167068
P.S. Keep in mind we're just getting acquainted with the release process:)

For GNOME, we will want to include

https://github.com/NixOS/nixpkgs/pull/166298
https://github.com/NixOS/nixpkgs/pull/166096

And there are still some annoying regression. For some of them, we expect them to be fixed in GNOME 42.1 (April 23).

One of those makes GNOME Shell crash when clicking close button in window overview (Activities): https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5137 so we would want to update at least Shell and Mutter to 42.1.
Some NetworkManager VPN plug-ins do not support GTK 4 so when one tries to configure them in GNOME Settings, they will only see (Error: unable to load VPN connection editor). Not sure what to do about that. Perhaps we could merge https://github.com/NixOS/nixpkgs/pull/164531 and do not include them by default, since they are unmaintained any way.

For docs, we want:

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

NixOS module system: no blocking issues.
Infinisil and I have made some quality of life improvements that have been merged for some time. We'll take it easy until branch-off, as far as I'm concerned.

dockerTools: also no blocking issues.

No blocking issues for Dhall

The hydra package is currently failing to build which should be considered a blocker. Mostly expecting #160202 to get finished.

No blockers for R

Emacs 28.1 was cut yesterday.
Release tar: https://git.savannah.gnu.org/cgit/emacs.git/snapshot/emacs-28.1.tar.gz
Perhaps @adisbladis can comment on requirement to be in the release.

No blockers for the integration test driver

I'd really like to get #158175 fixed, but I'm not sure how feasible that is

Could we please have MySQL8.0.28 build issue in macOS added to the 22.05 release?

"LXQt 1.1.0 will be released in the second half of April."
https://lxqt-project.org/blog/2022/03/31/lxqt-1.1.0-preview-second-part/
The window for DM changes closes on May 1st.

I'd really like to get #158175 fixed, but I'm not sure how feasible that is

The upstream fix was released, for all programs bundling their own version of electron I guess we'll have to wait until new versions get released containing the corresponding electron versions.
The fix is in electron_17: 17.3.1
electron_18: 18.0.1
but not backported to electron_16 yet.

apache-beam is currently broken: https://github.com/NixOS/nixpkgs/issues/167445 along with some other things in the JAX/TensorFlow ecosystem (treex, optax, tensorflow-datasets, tensorflow-bin, flax, dm-haiku)

Nothing to report for what I maintain.

Any chance we can get #161788 in before release? This would replace the current graphical ISO images with ones containing the calamares installer. @davidak and I have done a decent amount of testing and are currently testing what I hope is the final version. Although before merging we should move calamares-nixos-extensinos to the NixOS org. When merged this could really help make NixOS more accessible to new users.

While I think that calamares should go into 22.05 (and I hope it does), it's still only a draft and I don't see a good reason to block the release on this.

When Calamares is not polished enough in time, it should not go in and not block the release. Agreed!

I'd really like to see #165876 and #165892 in before the feature freeze. People will end up testing them a lot before the actual release, and it will be easy to identify that there's a problem and revert if there's some situation where they break.

Will end up testing them a lot?  Can you explain?  I thought that users don't install so often.
Also, generally I'd like to dissuade people trying to squash as many "large changes" as possible in the last allowed moment.  (As we see such tendencies before every release.)  What's wrong with getting just into nixos-unstable for now?  My understanding is that most of contributors don't use the stable releases anyway.  For almost all packages the freeze is relatively short, just two or three weeks.

I guess I hoped that people would boot the installer in order to make sure all that stuff was working. Especially if the Calamares version makes it in.

We probably need to do something about sway 1.7 and https://github.com/electron/electron/issues/32487. If that doesn't get merged in electron till 22.05, I propose adding a separate derivation for sway 1.6 and defaulting to it.

No big changes blocking a release scheduled for Haskell anymore, but we have some prominent failures / regressions due to recent changes (see also https://github.com/NixOS/nixpkgs/issues/167859):

hasura-graphql-engine
spago
jl

Out of those, at least spago should probably be fixed for 22.05.

At least two packages are breaking at runtime because of an icon related flaw in GTK. #163107 #168381

They sound like bugs, maybe the fixes will be quite simple.  Overall I find it unlikely that the feature freeze applies there, with fixes hopefully possible to backport at any later point.

We should probably ensure that #168303 is in 22.05, as it's a blocker for cross-compilation, in my case riscv64.

We should probably ensure that #168303 is in 22.05, as it's a blocker for cross-compilation, in my case riscv64.

Already part of #168737.

Regarding Emacs:
Emacs 28 was merged in https://github.com/NixOS/nixpkgs/pull/168076 which is great timing for the release. No blockers.

@CohenCyril @vbgl @Zimmi48 should we update the default version of Coq to the latest version (8.15)? No other blockers AFAIK.

Yes. I’m working on it.

Enabling both libcontainer based software such as runc/podman and NixOS containers have been broken for years (https://github.com/NixOS/nixpkgs/issues/77925) and is fixed by moving configuration/state directories.
This is addressed by https://github.com/NixOS/nixpkgs/pull/87268 which should go in 22.05.

Apologies in advance if this is the wrong place to talk about this (whether this is considered a breaking change or a release-worthy topic) as I never participated in a release, but maybe it would be useful to get https://github.com/NixOS/nixpkgs/pull/170655 in? At least for me I couldn't get VAAPI working in Brave without those changes, so it might be useful for other people to have this working OOtB in 22.05?

Java/OpenJDK is pretty much unmaintained. We don't have OpenJDK 18. We do Have 17, 11 and8 (all LTS). But we also Have 16, 15, 14, 13, 12.
https://github.com/NixOS/nixpkgs/issues/170825
@edwtjo @asbachb

We could also really need additional LLVM maintainers as we barely manage to keep things up-to-date and working.
I finally opened a dedicated issue regarding that (this was long overdue): https://github.com/NixOS/nixpkgs/issues/171047
(Sorry for hijacking this issue but this seems relevant in general (LLVM is a release critical package, llvmPackages_latest will already be outdated for 22.05 (https://github.com/NixOS/nixpkgs/pull/165701), and it will probably be worse for the next stable release if we don't find additional maintainers.)

I know we're already in the 3rd stage of the release schedule, but I would highly recommend we include these commits in 22.05, even if breaking.
Not breaking

#169380
#166992

Potentially breaking

#170991
#170121

These will be included.  The minor update wouldn't be considered breaking anyway.  Support for riscv in NixPkgs is... experimental?, so I think there it's fine.  (Though I'm a bit doubtful about which riscv users will use stable?)

A silly question: we branch off master, things that are now in master are included?

Does this need to be fixed before? https://github.com/NixOS/nixpkgs/issues/170897

A silly question: we branch off master, things that are now in master are included?

I think so: according to the release schedule, the branch off is supposed to occur on May 22.

#73404 is blocking installation if config.boot.initrd.secrets is set.

#73404 is blocking installation if config.boot.initrd.secrets is set.

Not sure if it is related, but I also have initrd secrets set, and on latest nixos-unstable I have a strange "not a git repo" error if I call sudo nixos-rebuild, but if I instead pass the --use-remote-sudo flag it rebuilds just fine :shrug:

Seconding the "strange «not a git repo» error", since a while I need my rebuild process has to look like this to work:

run nix build .#nixosConfigurations.host.config.system.build.toplevel (it fails when .git is absent),
move .git folder away,
run sudo nixos-rebuild boot  --flake.#host (it fails when .git is present),
move .git folder back.

Specifically, the errors look like this:
# When `.git` is present
╭─jaen@host /path/to/my/config/flake
╰─$ nix build .#nixosConfigurations.host.config.system.build.toplevel
error: '/path/to/my/config/flake' is not a Git repository

       … while fetching the input 'git+file:///path/to/my/config/flake'

# When `.git` is absent
╭─jaen@host /path/to/my/config/flake <some-branch>
╰─$ sudo nixos-rebuild boot --flake .#host --show-trace
[sudo] password for jaen:
warning: Not a git repository. Use --no-index to compare two paths outside a working tree
usage: git diff --no-index [<options>] <path> <path>

# `git diff` help text follows

error: program 'git' failed with exit code 129

       … while fetching the input 'git+file:///path/to/my/config/flake'

I don't think I'm doing anything out of ordinary in my config flake. The issue is pretty annoying for me, but in the end manageable – for someone new to NixOS it's just gonna scare them away if that's their first upgrade experience.

I have a strange "not a git repo" error if I call sudo nixos-rebuild

See https://github.com/NixOS/nixpkgs/issues/169193

Regarding GNOME, there two more potentially problematic changes:

adwaita-icon-theme removed majority of non-symbolic (colour) icons, which can make apps look inconsistent and in the worst case even make them unusable or crash (so far I have only encountered that in Meld). Probably something to note into ZHF.

webkitgtk 3.36.0 does not render HTML on some systems e.g. in Evolution, gnucash, we need to check if 3.36.1 fixes that. Though that update breaks tests of liferea. And there is also this issue, which might require us to switch back to wpe renderer. I would really appreciate if someone could help with webkitgtk maintenance, as I currently lack time for that.

Does this need to be fixed before? #170897

Whatever is going on with GLIBC here is breaking a lot of packages.

Since a lot of people are (probably) subscribed to this issue due to @NixOS/nixpkgs-committers being pinged, I'd prefer this issue to only have a minimal conversation.
This conversation should be about what issues may or should be blocking the release, issue-specific topics should be discussed in the respective issues/pull requests.
Now about some of these comments:

#170897 is important because I don't know if the next update will be during the 22.05 cycle. This is not blocking imo because documentation can easily be backported or just referenced from the unstable manual
#73404 is important and I think a fix should go into the release while not blocking the release since this is not a regression
#169193 is important to flakes users. I'm not a flake user myself but from what I can gather from the issue, this should be backported in nix and not nixpkgs and is also a problem on 21.11 so not a regression
I have no idea about the adwaita-icon-theme issue, me not caring about how consistent my icons look is a me-topic so the GNOME team should judge how critical the issue is
The webkitgtk issue seems more severe and might be worth blocking the release (at least regarding more widely used tools), again the team should judge this. Some issues regarding this already seem to be resolved

This comment is my judgement on how blocking these issues are to the release. If you disagree with me, feel free to ping me in the respective issues to continue the discussion there rather than here.
Also, not being critical to the release does not mean I think these issues are not important. Something to consider is that we have a very well working backport wokflow now and some issues can be fixed during the release (like the documentation).

I would love to get a new stack release into nixos 22.05: https://github.com/commercialhaskell/stack/issues/5733 :D

I would love to get 22.05 ISOs VM-friendly, but it seems stuck in merge limbo: https://github.com/NixOS/nixpkgs/pull/172668

authors: 0x4A6F DianaOlympos Gabriel439 Madouura NorfairKing SomeoneSerge Synthetica9 adisbladis bhankas bobby285271 cab404 dasJ davidak drupol ehmry etu jaen jbedo jtojnar kjeremy mweinelt ners nixos-discourse nrdxp peterhoeg primeos rnhmjoj roberth ryantm samuela samueldr siraben sternenseemann teto teutat3s tfc tpwrules ulrikstrid vbgl vcunat vlinkz wamserma yeongsheng-tan


text:
Package dsymutil for darwin

Up until recently, Apple didn't release public source for dsymutil, which is needed for proper debug builds on Darwin.
Recently, they contributed work back upstream to llvm for a public dsymutil, which has now made it back out to http://opensource.apple.com/source/clang/clang-703.0.31/src/tools/dsymutil/ (and https://github.com/llvm-mirror/llvm/tree/master/tools/dsymutil).
Once we get it working, dsymutil would also allow us to put debug info into a separate output from the main derivation, which would be cute.

cc @pikajude @gridaphobe

AFAIK we disable the current impure utils like dsymutil in binutils/default.nix, don't we?
However, is there any temporary to use the impure ones until the merge happens?
In my case, i try to build to valgrind for osx and it fails on the install-step, because it tries to dsymutil some shared libraries and the like.

btw, can't we introduce dsymutil like install_name_tool as an opt-in tool in all-packages for those who like to use the impure binaries from apple.

I just push a PR #23393 for discussion on the valgrind case

llvm-dsymutil is available through llvmPackages.llvm. Okay to close?

Is it actually full-featured? For the longest time, llvm-dsymutil was neutered compared to the official Apple one.

And by neutered, I don't mean deliberately, but more that Apple hadn't merged back their changes to LLVM in over a year, which was the period when they replaced their fully homegrown dsymutil with the LLVM version (and thus filled out all the missing features in it). Judging by https://github.com/llvm-mirror/llvm/commits/master/tools/dsymutil it looks like a fair amount has happened since then, but in that case we should probably stop putting a dummy dsymutil into cctools and actually just symlink to the LLVM one.

authors: copumpkin matthewbauer periklis


text:
captive-browser does not start

Describe the bug
captive browser exits with an error message:
2022/11/02 18:26:54 Obtaining DHCP DNS server...
read_config: /etc/dhcpcd.conf: No such file or directory
2022/11/02 18:26:55 Failed to execute dhcp-dns: exit status 1

This is true regardless of whether there is a captive portal on the uplink.
Steps To Reproduce
Steps to reproduce the behavior:

Set programs.captive-browser.enable
Run captive-browser
error message

Expected behavior
No error and a browser starts.
Additional context
It's not immediately obvious to me at what point the dhcpcd module stopped exposing its config file.
This occurred on a network on which I'm pretty certain there is a captive portal. I also tested on my home network with no captive portal, but got the same result.
Notify maintainers
@Ma27 (busy, I know)
@pennae (for dhcpcd)
Metadata
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 5.15.75, NixOS, 22.05 (Quokka), 22.05.20221030.26eb67a`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.8.1`
 - nixpkgs: `/etc/nix/channels/nixos`

Looks like you are right. If I do
sudo cp /nix/store/nbis7f5qqzzv45faqlz67dxbpack5s2r-dhcpcd.conf /etc/dhcpcd.conf
captive-browser

dhcpcd gets SIGSYS.

patch works for me

patch works for me

what would it take to add this patch as a proper PR?  carrying this as overlay is really impractical, as it impacts half the world through NetworkManager etc.

same here, I semi-forgot about it and thought there was already a PR. Doing one right now.

authors: cmm lourkeur


text:
Update request: breitbandmessung 3.1.0 → 3.3.0

Package name: breitbandmessung
Latest released version: 3.3.0

Current version on the unstable channel: 3.1.0
Current version on the stable/release channel: 3.1.0

[X] Checked the nixpkgs pull requests

New release is available. Maybe that fixes the issue with EOL electron.

   Known issues:
    - Electron version 16.2.3 is EOL

Notify maintainers
@b4dm4n

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

This is fixed by the PR above (https://github.com/NixOS/nixpkgs/pull/233841)

authors: davidak pinpox


text:
Upgrading btrfs-progs requires changes in nixos-generate-config.pl & install-grub.pl btrfs logic

Issue description
Running nix-rebuild switch on a system with a btrfs root, would usually produce:
updating GRUB 2 menu...
activating the configuration...
setting up /etc...
setting up tmpfiles

I now get:
building Nix...
building the system configuration...
updating GRUB 2 menu...
Btrfs did not return a path for the subvolume at /
warning: error(s) occurred while switching to the new configuration

Steps to reproduce
If I revert  Ic0cef0425eff1db8ddc07e78ea5aa16eb4a9666b which updated btrfs-tools everything works as expected.
Technical details

System: (NixOS: 17.09.git.2e81962 (Hummingbird))
Nix version: nix-env (Nix) 1.11.8
Nixpkgs version: "17.09.git.2e81962a71"

Meh, I did run one of the btrfs install tests but not the simple one.... So the output of the tools has changed somewhat, btrfs subvolume show used to print:
machine# /mnt is toplevel subvolume

But now in the same case it prints:
machine# /mnt
machine# 	Name: 			<FS_TREE>
machine# 	UUID: 			-
machine# 	Parent UUID: 		-
machine# 	Received UUID: 		-
machine# 	Creation time: 		-
machine# 	Subvolume ID: 		5
machine# 	Generation: 		4
machine# 	Gen at creation: 	0
machine# 	Parent ID: 		0
machine# 	Top level ID: 		0
machine# 	Flags: 			-
machine# 	Snapshot(s):

... which confuses this logic in nixos-generate-config.pl:
399     # Is this a btrfs filesystem?
400     if ($fsType eq "btrfs") {
401         my ($status, @id_info) = runCommand("btrfs subvol show $rootDir$mountPoint");
402         if ($status != 0 || join("", @id_info) =~ /ERROR:/) {
403             die "Failed to retrieve subvolume info for $mountPoint\n";
404         }
405         my @ids = join("", @id_info) =~ m/Subvolume ID:[ \t\n]*([^ \t\n]*)/;
406         if ($#ids > 0) {
407             die "Btrfs subvol name for $mountPoint listed multiple times in mount\n"
408         } elsif ($#ids == 0) {
409             my ($status, @path_info) = runCommand("btrfs subvol list $rootDir$mountPoint");
410             if ($status != 0) {
411                 die "Failed to find $mountPoint subvolume id from btrfs\n";
412             }
413             my @paths = join("", @path_info) =~ m/ID $ids[0] [^\n]* path ([^\n]*)/;
414             if ($#paths > 0) {
415                 die "Btrfs returned multiple paths for a single subvolume id, mountpoint $mountPoint\n";
416             } elsif ($#paths != 0) {
417                 die "Btrfs did not return a path for the subvolume at $mountPoint\n";
418             }
419             push @extraOptions, "subvol=$paths[0]";
420         }
421     }

Reverting it but keeping this open so we can eventually update it.

Fixed by https://github.com/NixOS/nixpkgs/commit/801c920e95642ec663d4aa486c81e5443e25b182.

authors: dezgeg fpletz mdorman


text:
Package request: various ld_preload tools

Add various tools from https://github.com/gaul/awesome-ld-preload its open issues, and its open PRs.
I believe I may have found another list at some point but I don't know where it is now.
There are some other tools at https://news.ycombinator.com/item?id=22151212 as well.
Several more tools listed in https://github.com/gaul/awesome-ld-preload/issues/3
Probably various repositories by https://github.com/yugr

[ ] https://github.com/yugr/valgrind-preload  LD_PRELOAD-able library which runs all spawned processes under Valgrind.

Maybe a few things under https://github.com/topics/preload-library
These can be nice for some quick hacks sometimes.
Ones I've actually used:

[ ] ld-preload-open
[ ] libleakmydata (it may be desirable to disable / patch out the webkit dependency in this by default?)
[x] ip2unix (already packaged)
[ ] https://github.com/ericpruitt/homeishome Override passwd->pw_dir for the current user's password database entry with $HOME.

I would like to add https://gitlab.com/warningnonpotablewater/libinput-config to this list.

authors: CapSel deliciouslytyped


text:
Is 'perl 5.24->5.26' planned ?

Any plans or thoughts to adopt or to reject Perl 5.26 ?
I have no opinion on should we upgrade from 5.24, but some of the changes look breaking (removal "." from @INC, ...), so it would be nice to know in advance.
So far only Archlinux moved to 5.26

@fpletz What does adding 17.09 milestone mean? To upgrade before 17.09 release, to keep old Perl for 17.09 or to make a decision before 17.09 forking ?

I set the milestone to 17.09, because we should try to make the transition IMHO. I'm not sure though if there are any problems because my perl experience is very limited.

cc @edolstra who's probably the reason perl is so widespread in the Nix community 😄

@copumpkin try to simply bump version on staging and see if something fails. nixpkgs has plenty of Perl code so it is a good test by itself.

perl-5.24 is end-of-life upstream
I propose the following migration path:

accept https://github.com/NixOS/nixpkgs/pull/42659
check  that perl526Packages and perl528Packages work
wait few weeks
switch  perlPackages from perl524Packages to perl526Packages (this would change default perl too, because it got to top-level as inherit (perlPackages) perl)
wait few weeks
deprecate perl522Packages and perl524Packages

#42659 is now in staging. Hopefully tomorrow it will go to staging-next, and then in a couple of days it should land in master.

authors: FRidh copumpkin fpletz volth


text:
networking.wireless.environmentFile doesn't accept complicated paths

Describe the bug
The option "networking.wireless.environmentFile" doesn't accept paths with more than one "/".
Steps To Reproduce
Assign ./wireless.env or ../wireless.env to environmentFile (with the files in the correct locations ofc) and rebuild nixos. The rebuild is successful and the environment variables work correctly.
Assign ./secrets/wireless.env or ../../wireless.env to the attribute (from my config: environmentFile = ../secrets/wireless.env;) and rebuild . The rebuild causes a bunch of errors, among them wpa_supplicant.service: Failed to load environment files: No such file or directory.
Expected behavior
The attribute should accept any kind of value with the data type path.
Error Message
restarting the following units: wpa_supplicant.service
Job for wpa_supplicant.service failed because of unavailable resources or another system error.
See "systemctl status wpa_supplicant.service" and "journalctl -xeu wpa_supplicant.service" for details.
warning: the following units failed: wpa_supplicant.service

× wpa_supplicant.service - WPA Supplicant instance
     Loaded: loaded (/etc/systemd/system/wpa_supplicant.service; enabled; preset: enabled)
     Active: failed (Result: resources) since Thu 2024-01-11 22:07:29 CET; 257ms ago
   Duration: 6min 19.172s
         IP: 0B in, 0B out
        CPU: 0

Jan 11 22:07:29 dell-laptop systemd[1]: wpa_supplicant.service: Deactivated successfully.
Jan 11 22:07:29 dell-laptop systemd[1]: Stopped WPA Supplicant instance.
Jan 11 22:07:29 dell-laptop systemd[1]: wpa_supplicant.service: Failed to load environment files: No such file or directory
Jan 11 22:07:29 dell-laptop systemd[1]: wpa_supplicant.service: Failed to run 'start' task: No such file or directory
Jan 11 22:07:29 dell-laptop systemd[1]: wpa_supplicant.service: Failed with result 'resources'.
Jan 11 22:07:29 dell-laptop systemd[1]: Failed to start WPA Supplicant instance.
Jan 11 22:07:29 dell-laptop systemd[1]: wpa_supplicant.service: Failed to load environment files: No such file or directory
Jan 11 22:07:29 dell-laptop systemd[1]: wpa_supplicant.service: Failed to run 'start' task: No such file or directory
Jan 11 22:07:29 dell-laptop systemd[1]: wpa_supplicant.service: Failed with result 'resources'.
Jan 11 22:07:29 dell-laptop systemd[1]: Failed to start WPA Supplicant instance.
warning: error(s) occurred while switching to the new configuration

Side Note
I also noticed, that the documentation falsely says the path should be in quotes: networking.wireless.environmentFile = "/run/secrets/wireless.env";. At least I'm not doing that.
Notify maintainers
@rnhmjoj
Metadata
 - system: `"x86_64-linux"`
 - host os: `Linux 6.1.71, NixOS, 23.11 (Tapir), 23.11.20240110.3dc440f`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.1`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

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

I also noticed, that the documentation falsely says the path should be in quotes: networking.wireless.environmentFile = "/run/secrets/wireless.env";. At least I'm not doing that.

Are you aware of what the path type in the Nix language does?

evaluating "${./foo.txt}" will cause foo.txt in the current directory to be
copied into the Nix store and result in the string "/nix/store/-foo.txt".

Generally if you refer to a file as ./wireless.env it will be copied to the Nix store exposing it to everyone, so you wouldn't do that for environmentFiles, which are in fact meant for sideloading secrets.
That said, the networking.wireless module is actually doing toString cfg.environmentFile and passing the resulting string directly to systemd.
toString prevents the unwanted copying and converts the path value to a usual string.

The rebuild causes a bunch of errors, among them wpa_supplicant.service: Failed to load environment files: No such file or directory.

What you did, even if likely a mistake, should technically work. Are you sure you're specifying the right path?
Note that a relative path is interpreted relative to the directory of the Nix expression being evaluated.

Thanks for the help.
The reason why I want to have the wireless.env near my config is because I am planning to back up my wifi passwords in my nixos-config git repo using git crypt (I'm still working on that). I don't really care that my wifi passwords would exposed to everyone with access the the computers.
The reason why I thought that the quotation marks in the documentation were incorrect was because environmentFile = "./wireless.env"; gives this error: error: A definition for option networking.wireless.environmentFile' is not of type null or path'. and the same without the quatation marks works fine.
I just tried environmentFile = "/run/secrets/wireless.env"; and it works fine so maybe I will just use a different way of backing it up.

I am currently doing it with the absolute path and it's working fine. Should I close this issue? It's a bit weird that relative paths with more than one "/" don't work at all but I agree that it's probably a bad idea anyway.

The reason why I thought that the quotation marks in the documentation were incorrect was because environmentFile = "./wireless.env"; gives this error:

That is because the path must be absolute in order for systemd to load it. A relative path would be interpreted relative to the process cwd (so, proably /), not to your configuration.

and the same without the quotation marks works fine.

This works because the toString call is resolving the path value it into a string containg the absolute path.
To be clear, ./wireless.env would be converted to something like "/home/sebastian/my_nixos_config/wireless.env".
This is a prefectly legitimate way to do it, in fact it's what I do with my secrets. There are two things to note though:

The path may not be accessible to the user/service you are intending to configure. This is not an issue with environment files, because they're handled by systemd and it runs as root, however other users won't be able to traverse your home directory and read it. So, be sure the file is accessible.

If the module does not post-process you value with toString you will leak the secret by copying it to the store. So, remember to always use toString to be sure (calling it two times won't cause any issue).

It's a bit weird that relative paths with more than one "/" don't work at all but I agree that it's probably a bad idea anyway.

Yes, I would be interested in figuring this out, but I can't reproduce it. Can you write a minimal example?

Ok, I just tried to recreate the problem, I even rolled my system back to the stable release, but didn't get the error this time. I am pretty sure I tried everything and did everything right when I tried it 3 weeks ago but apparently not. I am really sorry to have wasted your time. If I somehow do get this error again in the future I will let you know.

No problem. I'll just close the issue for now.

authors: SebastianStork rnhmjoj


text:
Build failure: mysql-workbench

Steps To Reproduce
Steps to reproduce the behavior:

Build mysql-workbench

Build log
https://gist.github.com/toast003/1c61ab22758f4fe72e53e998ea6b63df
Additional context
Stumbled upon this when upgrading my NixOS flake from 317484b1ead87b9c1b8ac5261a8d2dd748a0492d to 9b19f5e77dd906cb52dade0b7bd280339d2a1f3d
Notify maintainers
No maintainers so I'll just ping the last person to touch this
@khaneliman

Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.1.52-valve14, NixOS, 24.05 (Uakari), 24.05.20240108.317484b`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.1`
 - nixpkgs: `/nix/store/0g53xyh39z3y90p4d8r341wbqyjy1zhl-source`

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

Okay, I managed to fix the build, will open a PR shortly.

Thank you for writing the fix and creating the PR. Is something holding up the pull request? It's been open for over a week now.

I guess noone really reviewed the PR. I can maybe ask for a review.

I tried building mysql-workbench again today but it is still failing. Is it building properly for you? Or is it something on my end?
output of nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.7.0, NixOS, 24.05 (Uakari), 24.05pre567746.317484b1ead8`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.1`
 - channels(root): `"nixos"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

@nhasian the pr that fixed this hasn't hit nixpkgs-unstable yet, wait until it does.
You can check here https://nixpk.gs/pr-tracker.html?pr=281207

authors: TomaSajt nhasian toast003


text:
zfs-import services do not wait for LUKS devices to be opened (need a cryptsetup.target)

Note, this is all about non-root zpools, for which adding this to the initrd would be inappropriate (especially since the key to open the devices comprising the zpool is stored on the root fs -- and with the initrd being stored in the EFI system partition, it's not safe to put the key there.)
I have populated a /etc/crypttab and created cryptsetup services via
  systemd.generator-packages = [
    pkgs.systemd-cryptsetup-generator
  ];

  environment.etc = {
    "crypttab" = {
      enable = true;
      text = ''
<name> UUID=<uuid> /etc/crypttab-key luks
...
      '';
    };
  };
}

This will unlock the devices fine upon boot, however the zfs-import-w.service created based on my boot.zfs.extraPools = [ "w" ]; runs before it is done and fails.
It seems like to imitate what is done with the zfsonlinux.org packages for Fedora or Ubuntu, for example, the zfs-import-w.service needs to have cryptsetup.target in its "After" specification.  I've tried that, but there is no cryptsetup.target on NixOS -- I believe because of @edolstra's commit b06cb357, which drops the cryptsetup dependancy in the systemd build.
I have verified that the cyclic dependency still exists:
while evaluating ‘check’ at /etc/nixos/nixpkgs/lib/types.nix:170:15, called from /etc/nixos/nixpkgs/lib/modules.nix:340:10:
while evaluating the attribute ‘buildInputs’ of the derivation ‘systemd-234’ at /etc/nixos/nixpkgs/pkgs/stdenv/generic/make-derivation.nix:98:11:
while evaluating the attribute ‘buildInputs’ of the derivation ‘cryptsetup-1.7.5’ at /etc/nixos/nixpkgs/pkgs/stdenv/generic/make-derivation.nix:98:11:
while evaluating the attribute ‘buildInputs’ of the derivation ‘lvm2-2.02.173’ at /etc/nixos/nixpkgs/pkgs/stdenv/generic/make-derivation.nix:98:11:
infinite recursion encountered, at undefined position

I'm content to continue trying to figure this out when I have free time and will submit a PR if I do, but I'm interested in any pointers as to solving this or discussion about more practical ways to do this.
Technical details

System:
Nix version: 17.09.git.777443c (Hummingbird)
Nixpkgs version: "17.09.git.777443c726M"
Sandboxing enabled: false
(versions may be a little funny since I have my patch to attempt modifying the After on top of 17.09-small)

@jamagin, do you know if this is still an issue?

@benley Sorry, I don't currently have a nixos install or time to try.

This is a duplicate of https://github.com/NixOS/nixpkgs/issues/75540, which should be fixed by https://github.com/NixOS/nixpkgs/pull/66856 - closing.
@benley feel free to open another issue if you're still experiencing problems after this has trickled into nixos-unstable.

Hmm, on a second thought, adding cryptsetup.target to the zfs services might still be necessary - and isn't done currently.

authors: benley flokli jamagin


text:
tracker-miners: not indexing music files

Describe the bug
GNOME Music appears empty, but there are music files in my music folder.
Steps To Reproduce
Steps to reproduce the behavior:

Deploy NixOS with flake gilab:yajoman/minfra/7d6b0bc5cceee0b02be1695a7faa0047f6acbfc6#nixosConfigurations.yajothink
Log in.
Add music files in music folder.
Open GNOME Music.

Expected behavior
Music shows up.
Screenshots

Additional context
> systemctl status --user tracker-miner-fs-3.service
● tracker-miner-fs-3.service - Tracker file system data miner
     Loaded: loaded (/etc/systemd/user/tracker-miner-fs-3.service; linked-runtime; preset: enabled)
     Active: active (running) since Thu 2024-06-13 15:08:41 WEST; 1h 1min ago
   Main PID: 5861 (.tracker-miner-)
      Tasks: 10 (limit: 18759)
     Memory: 22.3M (peak: 95.1M swap: 5.0M swap peak: 12.0M)
        CPU: 1.749s
     CGroup: /user.slice/user-1000.slice/user@1000.service/background.slice/tracker-miner-fs-3.service
             └─5861 /nix/store/5934niqv7svsvnj3f80xgim7dw2x8bbk-tracker-miners-3.7.3/libexec/tracker-miner-fs-3

jun 13 15:08:41 yajothink .tracker-miner-[5861]: Could not launch metadata extractor: Falló al ejecutar el proceso hijo «/nix/store/5934niqv7svsvnj3f80xgim7dw2x8bbk-tracker-miners-3.7.3/libexec/tracker-extract-3» (Permission denied)
jun 13 15:08:48 yajothink .tracker-miner-[5861]: Could not launch metadata extractor: Falló al ejecutar el proceso hijo «/nix/store/5934niqv7svsvnj3f80xgim7dw2x8bbk-tracker-miners-3.7.3/libexec/tracker-extract-3» (Permission denied)
jun 13 15:58:32 yajothink .tracker-miner-[5861]: Could not launch metadata extractor: Falló al ejecutar el proceso hijo «/nix/store/5934niqv7svsvnj3f80xgim7dw2x8bbk-tracker-miners-3.7.3/libexec/tracker-extract-3» (Permission denied)
jun 13 15:58:38 yajothink .tracker-miner-[5861]: Could not launch metadata extractor: Falló al ejecutar el proceso hijo «/nix/store/5934niqv7svsvnj3f80xgim7dw2x8bbk-tracker-miners-3.7.3/libexec/tracker-extract-3» (Permission denied)
jun 13 16:02:44 yajothink .tracker-miner-[5861]: Could not launch metadata extractor: Falló al ejecutar el proceso hijo «/nix/store/5934niqv7svsvnj3f80xgim7dw2x8bbk-tracker-miners-3.7.3/libexec/tracker-extract-3» (Permission denied)
jun 13 16:02:48 yajothink .tracker-miner-[5861]: Could not launch metadata extractor: Falló al ejecutar el proceso hijo «/nix/store/5934niqv7svsvnj3f80xgim7dw2x8bbk-tracker-miners-3.7.3/libexec/tracker-extract-3» (Permission denied)
jun 13 16:09:01 yajothink .tracker-miner-[5861]: Could not launch metadata extractor: Falló al ejecutar el proceso hijo «/nix/store/5934niqv7svsvnj3f80xgim7dw2x8bbk-tracker-miners-3.7.3/libexec/tracker-extract-3» (Permission denied)
jun 13 16:09:01 yajothink .tracker-miner-[5861]: Could not launch metadata extractor: Falló al ejecutar el proceso hijo «/nix/store/5934niqv7svsvnj3f80xgim7dw2x8bbk-tracker-miners-3.7.3/libexec/tracker-extract-3» (Permission denied)
jun 13 16:09:05 yajothink .tracker-miner-[5861]: Could not launch metadata extractor: Falló al ejecutar el proceso hijo «/nix/store/5934niqv7svsvnj3f80xgim7dw2x8bbk-tracker-miners-3.7.3/libexec/tracker-extract-3» (Permission denied)
jun 13 16:09:05 yajothink .tracker-miner-[5861]: Could not launch metadata extractor: Falló al ejecutar el proceso hijo «/nix/store/5934niqv7svsvnj3f80xgim7dw2x8bbk-tracker-miners-3.7.3/libexec/tracker-extract-3» (Permission denied)

One new line of those appears every time I drop a music file on the music folder.
Notify maintainers

@bobby285271 @hedning @jtojnar @dasj19
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.6.32, NixOS, 24.05 (Uakari), 24.05.20240609.2819fff`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.2`
 - nixpkgs: `/nix/store/giq1qbcwfx5gq0g9jf6id0b3m55a860j-source`

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

Sounds like this error is still happening: https://gitlab.gnome.org/GNOME/localsearch/-/issues/321
Probably will want to open a new upstream issue.

Have the same issue

Opened https://gitlab.gnome.org/GNOME/localsearch/-/issues/351

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/gnome-music-doesnt-show-m4a-files/48173/2

Wondering what's the plan given the upstream findings.

No plan currently. Basically waiting for someone to be sufficiently annoyed to fix this. Suggested action in https://gitlab.gnome.org/GNOME/localsearch/-/issues/351#note_2156222

authors: fedeinthemix jtojnar mxkrsv nixos-discourse yajo


text:
Package request: FFMPEG - RIST support

Project description
The NixOS package FFMPEG currently has SRT, but not RIST.  It would be really helpful if RIST was included.
https://www.rist.tv/articles-and-deep-dives/2024/3/7/2024-rist-vs-srt-comparison
Rist library is here
https://code.videolan.org/rist/librist
It's great to see SRT is already included!
https://github.com/NixOS/nixpkgs/blob/74411387f2c763a5c490025ae0595ff4d47e4b03/pkgs/development/libraries/ffmpeg/generic.nix#L111

Metadata

homepage URL: https://code.videolan.org/rist/librist
source URL: https://code.videolan.org/rist/librist
license: BSD2 ( https://code.videolan.org/rist/librist/-/blob/master/COPYING )
platforms: unix, linux, darwin,

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

Added pull request
https://github.com/NixOS/nixpkgs/pull/353473


text:
azure-agent needs to be updated to 2.2.x

Issue description
azure-agent packages walinuxagent (legacy/binary name waagent): https://github.com/Azure/WALinuxAgent
It currently packages waagent-2.0. The currently supported versions are 2.2.x.
I need some advice. Previously waagent was a single executable python script, so packaging was relatively straight-forward.
I'd like to package the latest v2.2.25, which looks like more of a typical python package?
https://github.com/Azure/WALinuxAgent/tree/v2.2.25
But I tried wrapping it as a typical pythonPackage and instead it started executing the actual agent service (this may be due to how their repo/project is setup though... I do not know much about pythong packaging.)

cc: @jbgi due to the recent Azure PR, just as an FYI.

@colemickens We do have a slightly more recent version of waagent package. Did not have time to finish testing it so I did not open the PR. It is based on this branch: https://github.com/jbgi/WALinuxAgent/tree/nixos
Will push my nixpkgs branch shortly.

@colemickens The minimal changes I did to package the above branch: https://github.com/jbgi/nixpkgs/commit/f05acadcdc0040ec5569205c4276dc57706496d6

@jbgi thanks for sharing this. Do you just use the agent for initial provisioning, or is it used for extensions as well (I assume that most or all extensions wouldn't work on NixOS).
I'm just wondering, initial provisioning is pretty straightforward I think, I'm tempted to see if I can replace it with a simple bash script and get my images even smaller (and potentially more stable).

@colemickens I had plan to use some extensions but never got to the point of getting any extension working (cf. https://github.com/Azure/custom-script-extension-linux/pull/123). so yeah mostly given up on using extensions for now.

Anyone works on it?

Hello @khssnv
Here is a try #56986 , but I would need some help to test this.

Any updates?

My opinion? You couldn't possibly pay me to work, or work on packaging, Azure's agent. I rewrote my own in Rust and nixos-azure uses that going forward.

https://www.wiz.io/blog/secret-agent-exposes-azure-customers-to-unauthorized-code-execution
We should be very careful when packaging and running root daemons.

https://github.com/NixOS/nixpkgs/blob/d2c3bf424abb78f3879f5a9f9983e85f1bbaa4aa/pkgs/applications/networking/cluster/waagent/default.nix#L24

authors: Artturin MartinPotier colemickens jbgi khssnv siraben thpham


text:
New wxwidgets/wxGTK for KiCad? Alternative to overlay for master?

Describe the bug
Not a bug per se, more looking for some advice on implementing.
(I was going to post this as comment on #90654 but I didn't want to side-track that issue. #86040 might also be relevant.)
I'm currently working on KiCad for macOS. KiCad requires a number of patches to wxWidgets to work on macOS, to the point where they maintained a branch of wxWidgets with all necessary patches already applied: https://gitlab.com/kicad/code/wxWidgets
My work is currently based on this branch and I use an overlay like so
  overlays = [
    (self: super: {
      wxGTK30 = super.pkgs.callPackage ~/Software/nix/kicad-wxwidgets.nix {
        inherit (super.pkgs.darwin.stubs) setfile;
        inherit (super.pkgs.darwin.apple_sdk.frameworks) AGL Carbon Cocoa Kernel QTKit WebKit AVFoundation AVKit;
      };
    })
  ]

so that wxPython_4_0 and KiCad are built using the same wxWidgets package (and possibly other packages that KiCad depends on and that in turn depend on wxwidgets, but I don't remember for sure)
My question now is how to best integrate these changes so that it acceptable for upstream/master?
Essentially kicad-wxwidgets.nix contains yet another wxGTK version (3.0.4, gtk3, webkit enabled, only macOS because it is only needed there). I don't know in how far the patched wxwidgets version is backwards compatible to an unpatched wxwidgets-3.0.4, if at all. KiCad uses bundle on macOS so their wxwidgets version is not installed as system-wide folder where other packages/build managers could find it.
To Reproduce
Not really something to reproduce, but if you want to play with it/compile it yourself:

fetch/apply #96267
you can find a default.nix and kicad-wxwidgets.nix here: https://gist.github.com/hannesweisbach/e1a9203e3bc2a00f482309cc5a1bfc73

Expected behavior
What would be a way to get this to mainline?
Screenshots
n/a
Additional context
n/a
Notify maintainers

KiCad: @evils @kiwi @berce
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-darwin"`
 - host os: `Darwin 19.6.0, macOS 10.15.6`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.3.7`
 - channels(hannesweisbach): `""`
 - channels(root): `"nixpkgs-20.09pre242465.bd649f4f55c"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixpkgs`

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

I believe, deep overrides might not be suitable for packages in the pkgs scope because that requires more resources to eval. Maintaining a separate scope for kicad would defeat the purpose. So I would suggest concentrating on getting things working with a manual override first.

Ok. As a first step I made a PR for wxWidgets patched for KiCad on macOS, which is maintained by the KiCad people (#98538).

closing this as the associated PR is stale and there has since been some work on the darwin side
(though it's currently marked as broken for presumably reasons unrelated to this issue)

authors: evils hannesweisbach veprbl


text:
rclone: 1.53.2 -> 1.53.3

Motivation for this change
https://forum.rclone.org/t/rclone-1-53-3-release/20569
Things done

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

[x] NixOS
[x] 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.

backported to 20.09 in 698572240315ad29cdc5b86162bd48ecfd30b284

source: gharchive/pull-request


text:
clinfo: 2.2.18.04.06 -> 3.0.20.11.20

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/clinfo/versions.
meta.description for clinfo is: "Print all known information about all available OpenCL platforms and devices in the system"
meta.homepage for clinfo is: "https://github.com/Oblomov/clinfo"
meta.changelog for clinfo is: ""
Updates performed

Version update

To inspect upstream changes

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 3.0.20.11.20 with grep in /nix/store/vbzshpqqivzkpr9c8nk84yd4hlvm37ck-clinfo-3.0.20.11.20

directory tree listing: https://gist.github.com/9ded5632e06a58aa0528644d8bdcc561

du listing: https://gist.github.com/54f9d939111e503162aeb3af1b8f7ef4

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

3 total rebuild path(s)

1 package rebuild(s)

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

First fifty rebuilds by attrpath
clinfo

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/vbzshpqqivzkpr9c8nk84yd4hlvm37ck-clinfo-3.0.20.11.20 \
  --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 clinfo https://github.com/r-ryantm/nixpkgs/archive/60d2f1a232c7a9c7cd5b1cc938aab74b45a11778.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/vbzshpqqivzkpr9c8nk84yd4hlvm37ck-clinfo-3.0.20.11.20
ls -la /nix/store/vbzshpqqivzkpr9c8nk84yd4hlvm37ck-clinfo-3.0.20.11.20/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 1

1 package built:

clinfo

Maintainer pings
cc @athas for testing.

Works for me.

authors: athas r-ryantm


text:
open-policy-agent: 0.25.0 -> 0.25.1

Motivation for this change
open-policy-agent: 0.25.1
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 (x86_64)
[ ] 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"
[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)
[X] Ensured that relevant documentation is up to date
[X] Fits CONTRIBUTING.md.

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

1 package built:

open-policy-agent

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

1 package built:

open-policy-agent

Result of nixpkgs-review pr 106171 run on x86_64-darwin 1

1 package built:

open-policy-agent


text:
tigervnc: 1.10.1 -> 1.11.0 (CVE-2020-26117)

Motivation for this change
ChangeLog: https://github.com/TigerVNC/tigervnc/releases/tag/v1.11.0
Also fixes CVE-2020-26117[1].
[1] https://nvd.nist.gov/vuln/detail/CVE-2020-26117, #100324
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.

This is a semi-automatic executed nixpkgs-review which does not build all packages (e.g. lumo, tensorflow or pytorch)
If you find some bugs or got suggestions for further things to search or run please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 108778 run on x86_64-linux 1

2 packages built:

crowbar
tigervnc

This is a semi-automatic executed nixpkgs-review which does not build all packages (e.g. lumo, tensorflow or pytorch)
If you find some bugs or got suggestions for further things to search or run please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 108778 run on x86_64-linux 1

2 packages built:

crowbar
tigervnc

Result of nixpkgs-review pr 108778 run on x86_64-darwin 1

1 package marked as broken and skipped:

crowbar

Result of nixpkgs-review pr 108778 run on x86_64-darwin 1

1 package marked as broken and skipped:

crowbar

Ported to stable as 2829500ac2bdeb1e09ee9e169a0e72c357c052e5.

Ported to stable as 2829500ac2bdeb1e09ee9e169a0e72c357c052e5.


text:
thunderbird-bin: 38.3.0 -> 38.4.0

Various security fixes
Fixed issue where messages moves of multiple messages from a maildir folder to an mbox folder failed.

https://www.mozilla.org/en-US/thunderbird/38.4.0/releasenotes/
Unfortunately, Mozilla now provides only SHA512SUMS but not SHA1SUMS, and Nix does not support SHA-512 hash yet, so that I have to download all archives to calculate SHA-256 hashes when updating the sources.nix.

cc: @Fuuzetsu

Nix does support sha-512 already https://github.com/NixOS/nix/issues/679, but it's too new to depend on it. (The addition seems to have been spurred by the Mozilla move.)

I didn't notice that. I will update firefox-bin/thunderbird-bin when it is incorporated into stable version of nix.

I think in the next nixos release branch we shall depend on sha-512 support.

@vcunat @taku0 I was thinking that once sha512 support lands in a dependable manner (i.e., nixpkgs refuses to run with an older Nix), we could actually do an import-from-derivation for firefox and thunderbird.
What I'm thinking is that we would bundle a single fixed-output derivation for the SHA512SUMS in every firefox/thunderbird release, then run a simple script that processes that into a JSON/nix file and import that to get the rest of our fixed-output derivation hashes. Is that reasonable? I'd like to reduce the amount of autogenerated code in nixpkgs since it's hard to track where it came from, and we already have a pretty good mechanism in Nix itself for doing that sort of thing.

Does import-from-derivation mean something like follows?
let
  version = "38.5.0";

  hashesDeriv = stdenv.mkDerivation {
    name = "thunderbird-bin-hashes-${version}";

    src = fetchurl {
      url = "http://archive.mozilla.org/pub/thunderbird/releases/${version}/SHA512SUMS";
      sha512 = "...";
    };

    phases = "installPhase";

    installPhase =
      ''
        # generates nix expression of following form from SHA512SUMS
        # [
        #  { locale = "ar"; arch = "linux-i686"; sha512 = "..."; }
        #  ...
        # ]
      '';
  };

  sources = import ${hashesDeriv}/sources.nix;

  ...

  source = ...;

in

stdenv.mkDerivation {
  name = "thunderbird-bin-${version}";

  src = fetchurl {
    url = "http://download-installer.cdn.mozilla.net/pub/thunderbird/releases/${version}/${source.arch}/${source.locale}/thunderbird-${version}.tar.bz2";
    inherit (source) sha512;
  };

  ...
}

It sounds great. Commiting large list of hashes is not nice.

Fetchurl hashes are needed during evaluation time. It's considered impolite in nixpkgs when evaluation depends on some derivation results, as it means "building" happens even when you --dry-run, etc.

@taku0 yup, something like that
@vcunat is it that bad? I don't think nix-env would trigger the download, right? It would only happen if you did things like a dry-run or forced the derivation? Compared to putting tons of autogenerated crap in our source repository (which is getting hard to manage already with just haskellPackages, and will only get worse as we import and autogenerate more package ecosystems), it seems appealing.

Even nix-env -qas would do that.

authors: copumpkin taku0 vcunat


text:
chisel: 1.7.4 -> 1.7.6

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/chisel/versions.
meta.description for chisel is: "TCP/UDP tunnel over HTTP"
meta.homepage for chisel is: "https://github.com/jpillora/chisel"
meta.changelog for chisel 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.7.6 with grep in /nix/store/sfb7b9q95hi1pw7lgisqnsfibmprgb1a-chisel-1.7.6

directory tree listing: https://gist.github.com/142479a9d2102fb370e0eee90a2b9b75

du listing: https://gist.github.com/7e635d34b9d0bb39c3753a06917a3f89

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
chisel

Instructions to test this update (click to expand)

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

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A chisel https://github.com/r-ryantm/nixpkgs/archive/49c360132266ef624845ec59e05ed6b61761b6b5.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/sfb7b9q95hi1pw7lgisqnsfibmprgb1a-chisel-1.7.6
ls -la /nix/store/sfb7b9q95hi1pw7lgisqnsfibmprgb1a-chisel-1.7.6/bin

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

1 package built:

chisel

Maintainer pings
cc @fabaff @kalbasit for testing.

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

1 package built:

chisel

Result of nixpkgs-review pr 113650 at 49c36013 run on aarch64-linux 1

1 package built:

chisel

2 suggestions:

error: no-flags-array
buildFlagsArray is only intended to be used in Bash, not as a Nix attribute.
Near pkgs/tools/networking/chisel/default.nix:20:3:
   |
20 |   buildFlagsArray = [ "-ldflags=-s -w -X github.com/jpillora/chisel/share.BuildVersion=${version}" ];
   |   ^

warning: unused-argument
Unused argument: stdenv.
Near pkgs/tools/networking/chisel/default.nix:4:3:
  |
4 | , stdenv
  |   ^

authors: fabaff r-rmcgibbo r-ryantm


text:
terraform-providers.vultr: 1.5.0 -> 2.1.3

Motivation for this change
The vultr provider has not been updated for a while.
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/)
[ ] 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.

@GrahamcOfBorg build terraform.full

Result of nixpkgs-review pr 114593 at ded490e0 run on aarch64-linux 1

2 packages built:

terraform-full
terraform-providers.vultr

authors: kalbasit r-rmcgibbo


text:
python3Packages.karton-asciimagic: init at 1.0.0

Motivation for this change
Decoders for ascii-encoded executables for the Karton framework
https://github.com/CERT-Polska/karton-asciimagic
Related to #81418
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/)
[ ] 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.

@chivay, perhaps you could give it a try?

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

2 packages built:

python38Packages.karton-asciimagic
python39Packages.karton-asciimagic


text:
reposurgeon: 3.44 -> 4.26

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/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 122854 at bd752b94 run on aarch64-linux 1

1 package built successfully:

reposurgeon

11 suggestions:

warning: unused-argument
Unused argument: monotone.
Near pkgs/applications/version-management/reposurgeon/default.nix:4:21:
  |
4 | , mercurial ? null, monotone ? null, rcs ? null
  |                     ^

warning: unused-argument
Unused argument: cvs_fast_export.
Near pkgs/applications/version-management/reposurgeon/default.nix:5:22:
  |
5 | , subversion ? null, cvs_fast_export ? null }:
  |                      ^

warning: unused-argument
Unused argument: makeWrapper.
Near pkgs/applications/version-management/reposurgeon/default.nix:1:26:
  |
1 | { lib, stdenv, fetchurl, makeWrapper, buildGoModule, git
  |                          ^

warning: unused-argument
Unused argument: cvs.
Near pkgs/applications/version-management/reposurgeon/default.nix:3:18:
  |
3 | , breezy ? null, cvs ? null, darcs ? null, fossil ? null
  |                  ^

warning: unused-argument
Unused argument: subversion.
Near pkgs/applications/version-management/reposurgeon/default.nix:5:3:
  |
5 | , subversion ? null, cvs_fast_export ? null }:
  |   ^

warning: unused-argument
Unused argument: mercurial.
Near pkgs/applications/version-management/reposurgeon/default.nix:4:3:
  |
4 | , mercurial ? null, monotone ? null, rcs ? null
  |   ^

warning: unused-argument
Unused argument: darcs.
Near pkgs/applications/version-management/reposurgeon/default.nix:3:30:
  |
3 | , breezy ? null, cvs ? null, darcs ? null, fossil ? null
  |                              ^

warning: unused-argument
Unused argument: rcs.
Near pkgs/applications/version-management/reposurgeon/default.nix:4:38:
  |
4 | , mercurial ? null, monotone ? null, rcs ? null
  |                                      ^

warning: unused-argument
Unused argument: breezy.
Near pkgs/applications/version-management/reposurgeon/default.nix:3:3:
  |
3 | , breezy ? null, cvs ? null, darcs ? null, fossil ? null
  |   ^

warning: unused-argument
Unused argument: git.
Near pkgs/applications/version-management/reposurgeon/default.nix:1:54:
  |
1 | { lib, stdenv, fetchurl, makeWrapper, buildGoModule, git
  |                                                      ^

warning: unused-argument
Unused argument: fossil.
Near pkgs/applications/version-management/reposurgeon/default.nix:3:44:
  |
3 | , breezy ? null, cvs ? null, darcs ? null, fossil ? null
  |                                            ^

authors: dguibert r-rmcgibbo