text:
Day counter counts incorrectly

Describe the bug
The day only gets +1 when it becomes 06:00, not at 00:00.
To Reproduce
Steps to reproduce the behavior:
Change the time in the config to 24H
use24HourClock=true
Screenshots

Server (please complete the following information):

OS: Debian 12
Minecraft: 1.20.2
Fabric: 0.15.3
Mod: 4.2.1

That is how Minecraft counts days. The day number doesn't roll over at midnight. It rolls over after the sun is up for a bit. https://minecraft.wiki/w/Daylight_cycle#Daytime

Okay, I didn't know that. Then everything works fine now, thank you very much.

repo: Nincodedo/mc-server-description


text:
Modern Mesos can't do CommandInfo & ExecutorCommandInfo

It used to be that you could pass both a CommandInfo and an ExecutorCommandInfo at the same time. That hasn't worked for awhile. In order to pass custom commands to our executor we need another mechanism. We could use EXECUTOR env vars, but then the command lives in a part of the config far away from the container info. Instead, this PR creates a new Docker label that will not be sent to Docker called executor.ShellCommand that will get put into the Docker container's Cmd field as a string.

nice, do you have an example of how to use it in the nmesos config file?

nice, do you have an example of how to use it in the nmesos config file?

Not yet, but will do

source: gharchive/pull-request

authors: danpilch relistan

repo: Nitro/sidecar-executor

license: mit

license_type: permissive

license_source: bigquery


text:
provisioner-app: Make T1 intermediate key length and type dynamic

In upstream solo2, the T1 intermediate key is a 32-byte Ed255 key.  In 8e70f9d88924e3ead105f9c60aee13b9b1516ef6, we changed it to a 64-byte P256 key.  We should have a more flexible solution that allows 32 or 64 bytes and lets the user specify the key type.

As we’re no longer a fork of solo2, this is not necessary any more.

source: gharchive/issue

license_source: github-api


text:
embedded/lpc55: Gracefully handle EFS errors

Instead of panicking if the communication with the EFS fails, we set an
error flag and use RAM as a fallback.

This can be simulated by replacing into_output_high with into_output_low here:
https://github.com/Nitrokey/nitrokey-3-firmware/blob/c728fae23e8d31a6f514e80e0755c5193e402ca9/runners/embedded/src/soc_lpc55/init.rs#L546
@daringer Do we need something similar for NRF52?
Based on https://github.com/Nitrokey/nitrokey-3-firmware/pull/172

Can you invoke the failure case in the firmware somehow for tests? Or have you done so already?

Can you invoke the failure case in the firmware somehow for tests? Or have you done so already?

I’ve tested it by just not powering the external flash, see the PR description.

Ah, I've missed that this was a test case description. Good!

authors: robin-nitrokey szszszsz


text:
C code issue #739

Related Issue
Closes: #739
Describe the changes you've made
Migratory Birds Solution for Hackkerank with Time Complexity O(n)
Describe if there is any unusual behaviour of your code(Write NA if there isn't)
NA
Language used for coding
C
Checklist:

[x] My code follows the style guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] I have documented the code.
[x] New and existing unit tests pass locally with my changes.

Problem name is "Migratory Birds" so your folder name should be same as this.

license: MIT


text:
Vulnerability roundup 97: brave-1.15.76: 1 advisory [5.5]

search, files

[ ] CVE-2020-8276 CVSSv3=5.5 (nixos-20.09)

Scanned versions: nixos-20.09: 50c8d1e0deb.
Cc @jefflabonte
Cc @rht
Cc @uskudnik

https://github.com/NixOS/nixpkgs/issues/106186#issuecomment-739958330

authors: JeffLabonte ckauhaus

repo: NixOS/nixpkgs


text:
networking.extraHosts is overwritten by containers

On NixOS 15.09.660.ca8f159 (Dingo) I set networking.extraHosts in one of my configuration files. But the value set there is not propagated to /etc/hosts. The only entries I have in said file are the entries needed to reach my containers. The containers themselves are configured the declarative way.

My fault it actually works. I simply forgot to import the file where I defined networking.extraHosts.


text:
GNUnet service doesn't work

Describe the bug
After enabling the GNUnet service with services.gnunet.enable = true;, it prints a lot of errors at startup:
Aug 11 17:54:58 nixos gnunet-service-arm[15492]: Aug 11 17:54:58-360075 gns-15492 ERROR Configuration specifies invalid value for option `.pin' in section `gns': Pr>
Aug 11 17:54:58 nixos systemd[1]: Started GNUnet.
Aug 11 17:54:58 nixos gnunet-service-arm[15520]: Aug 11 17:54:58-369385 vpn-15520 ERROR `/nix/store/k8lq1hxqiyf2slnxj6mnw3hkym5vyd0r-gnunet-0.14.1/lib//gnunet/libex>
Aug 11 17:54:58 nixos gnunet-service-arm[15510]: Aug 11 17:54:58-376256 ats-15510 ERROR Assertion failed at plugin_ats_proportional.c:290.
Aug 11 17:54:58 nixos gnunet-service-arm[15510]: Aug 11 17:54:58-376303 ats-15510 ERROR Assertion failed at plugin_ats_proportional.c:290.
Aug 11 17:54:58 nixos gnunet-service-arm[15510]: Aug 11 17:54:58-376332 ats-15510 ERROR Assertion failed at plugin_ats_proportional.c:290.
Aug 11 17:54:58 nixos gnunet-service-arm[15510]: Aug 11 17:54:58-376358 ats-15510 ERROR Assertion failed at plugin_ats_proportional.c:290.
Aug 11 17:54:58 nixos gnunet-service-arm[15517]: Aug 11 17:54:58-376330 transport-tcp-15517 WARNING Unexpected address length: 24 bytes
Aug 11 17:54:58 nixos gnunet-service-arm[15517]: Aug 11 17:54:58-376366 transport-15517 ERROR Assertion failed at gnunet-service-transport_validation.c:902.
Aug 11 17:54:58 nixos gnunet-service-arm[15510]: Aug 11 17:54:58-376380 ats-15510 ERROR Assertion failed at plugin_ats_proportional.c:290.
Aug 11 17:54:58 nixos gnunet-service-arm[15517]: Aug 11 17:54:58-376383 transport-15517 ERROR Address with 24 bytes for plugin tcp and peer DSTJ is malformed
Aug 11 17:54:58 nixos gnunet-service-arm[15517]: Aug 11 17:54:58-376390 transport-tcp-15517 WARNING Unexpected address length: 12 bytes
Aug 11 17:54:58 nixos gnunet-service-arm[15517]: Aug 11 17:54:58-376404 transport-15517 ERROR Assertion failed at gnunet-service-transport_validation.c:902.
Aug 11 17:54:58 nixos gnunet-service-arm[15510]: Aug 11 17:54:58-376405 ats-15510 ERROR Assertion failed at plugin_ats_proportional.c:290.
Aug 11 17:54:58 nixos gnunet-service-arm[15517]: Aug 11 17:54:58-376409 transport-15517 ERROR Address with 12 bytes for plugin tcp and peer DSTJ is malformed
Aug 11 17:54:58 nixos gnunet-service-arm[15510]: Aug 11 17:54:58-376428 ats-15510 ERROR Assertion failed at plugin_ats_proportional.c:290.
Aug 11 17:54:58 nixos gnunet-service-arm[15510]: Aug 11 17:54:58-376451 ats-15510 ERROR Assertion failed at plugin_ats_proportional.c:290.

Additionally, attempting to stop the deamon with gnunet-arm -e reveals that it is apparently not even running:
Aug 11 20:21:58-538831 gnunet-arm-19435 WARNING GNUnet not running, cannot stop the peer

Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
 - system: `"x86_64-linux"`
 - host os: `Linux 5.10.42, NixOS, 21.11.20210610.432fc2d (Porcupine)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.4pre20210601_5985b8b`
 - channels(root): `"nixos-21.05pre279456.04a2b269d89, release-20.09.tar.gz-20.09"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

After merging this, the CLI utilities can be used as follows: sudo -u gnunet sh -c 'TMPDIR=/tmp gnunet-arm -I'


text:
dwarf-fortress: cannot open libz

Issue description
Running dwarf-fortress causes libz error message. It also happens if I don't do a pure shell and have zlib installed.
Steps to reproduce
ryantm@nixos ~/p/nixpkgs (1603)$ nix-shell --pure -I nixpkgs=~/p/nixpkgs -p dwarf_fortress
[nix-shell:~/p/nixpkgs]$ dwarf-fortress
Using /home/ryantm/.local/share/df_linux as Dwarf Fortress overlay directory.
If you do any changes in it, don't forget to clean it when updating the game version!
We try to detect changes based on data directories being symbolic links -- keep this in mind.
/nix/store/246rjsdfq04jf12yikpfyf0iqzs0k22i-dwarf-fortress-env-0.42.05/libs/Dwarf_Fortress: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory
Technical details

System: (NixOS: nixos-version, Ubuntu/Fedora: lsb_release -a, ...)

nixos-version
16.03.git.e843b35M (Emu)

Nix version: (run nix-env --version)

nix-shell --pure -I nixpkgs=~/p/nixpkgs -p dwarf_fortress

Nixpkgs version: (run nix-instantiate --eval '<nixpkgs>' -A lib.nixpkgsVersion)
nixpkgs git e843b35

This was fixed in bdf714c3039411bcaa942822cfc7c039a391a552. You can cherry-pick the patch (do you need help with this?).

authors: abbradar ryantm


text:
nixUnstable 2.7.0 will not build on aarch64-darwin

Describe the bug
As the title says.  Build log attached.
Steps To Reproduce
Steps to reproduce the behavior:
nix build "nixpkgs#nixUnstable" on an aarch64-darwin machine.
Expected behavior
The package should build.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
See attached build log.
nixUnstable-build-failure.log
Notify maintainers
@edolstra
@NixOS/darwin-maintainers
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: `"aarch64-darwin"`
 - host os: `Darwin 20.6.0, macOS 11.6`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.5pre20211007_844dd90`
 - channels(matthew): `"darwin, home-manager, nixpkgs-21.11pre330079.bf346b557b7"`
 - channels(root): `"home-manager, nixpkgs-21.11pre328902.2606cb0fc24"`
 - nixpkgs: `/nix/store/08yiicpdx3y7j6b6g6p1ghipllxbrcy2-pnwyi8fcq1v0b9i4905b3yxkaw29dmly-source`

AFAICT, this may be from the c++ version being c++11 for darwin's stdenv. Where as some c++14 usage is occuring:
src/libstore/realisation.hh:22:5: error: no matching function for call to 'make_tuple'
    GENERATE_CMP(DrvOutput, me->drvHash, me->outputName);
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/libutil/comparator.hh:31:5: note: expanded from macro 'GENERATE_CMP'
    GENERATE_LEQ(args) \
    ^~~~~~~~~~~~~~~~~~
src/libutil/comparator.hh:27:31: note: expanded from macro 'GENERATE_LEQ'
#define GENERATE_LEQ(args...) GENERATE_ONE_CMP(<, args)
                              ^~~~~~~~~~~~~~~~~~~~~~~~~
src/libutil/comparator.hh:23:22: note: expanded from macro 'GENERATE_ONE_CMP'
      auto fields2 = std::make_tuple( FIELDS ); \

https://en.cppreference.com/w/cpp/utility/tuple/make_tuple

Likely the same error for nix 2.6.0 on both darwin platforms as well.

Would forcing the usage of a sufficiently new llvmPackages on Darwin be sufficient?
I do not have access to the necessary hardware to test/debug this, someone will need to help.

I believe aarch64 darwin is on a very recent version of llvm

I've just confirmed that this problem also exists on x86_64-darwin too.  I've renamed the issue to reflect this.

I believe aarch64 darwin is on a very recent version of llvm

Both darwin platforms are on llvm 11.

I've just confirmed that this problem exists on x86_64-darwin too. I've renamed the issue to reflect this.

I checked and it is the same error for 2.6.0 also so I've renamed the issue again.

https://hydra.nixos.org/project/nix
Apart from some flaky tests the nix repo hydra jobset seems to be building >= 2.6.0 and it looks to be using a nixpkgs revision from 21.05?

FWIW I'm able to build it from the upstream repo's flake but not from nixpkgs

I've managed to get a fix which is up for review in  #157596.

authors: hexagonal-sun jonringer kubukoz lovesegfault zowoq


text:
Package request: CODELITE

Project description
CodeLite is an open source, free, cross platform IDE, specialized in C, C++, Rust, Python, PHP and JavaScript (mainly for backend developers using Node.js) programming languages which runs best on all major Platforms ( OSX, Windows and Linux )
Metadata

homepage URL: https://codelite.org/
source URL: https://github.com/eranif/codelite
license: gpl2+
platforms: OSX, Windows, Linux

Duplicate of https://github.com/NixOS/nixpkgs/issues/238337

authors: EilTalrent romildo


text:
Build failure: gaphor (2.8.2)

Steps To Reproduce
Steps to reproduce the behavior:

build gaphor

Build log
Sourcing python-remove-tests-dir-hook
Sourcing python-catch-conflicts-hook.sh
Sourcing python-remove-bin-bytecode-hook.sh
Sourcing pypa-build-hook
Using pypaBuildPhase
Sourcing python-runtime-deps-check-hook
Using pythonRuntimeDepsCheckHook
Sourcing pypa-install-hook
Using pypaInstallPhase
Sourcing python-imports-check-hook.sh
Using pythonImportsCheckPhase
Sourcing python-namespaces-hook
Sourcing python-catch-conflicts-hook.sh
@nix { "action": "setPhase", "phase": "unpackPhase" }
Running phase: unpackPhase
unpacking source archive /nix/store/w07w8hahc26aaf87qdnln1zwr8h3ds8h-gaphor-2.8.2.tar.gz
source root is gaphor-2.8.2
setting SOURCE_DATE_EPOCH to timestamp 1643581293 of file gaphor-2.8.2/PKG-INFO
@nix { "action": "setPhase", "phase": "patchPhase" }
Running phase: patchPhase
@nix { "action": "setPhase", "phase": "updateAutotoolsGnuConfigScriptsPhase" }
Running phase: updateAutotoolsGnuConfigScriptsPhase
@nix { "action": "setPhase", "phase": "configurePhase" }
Running phase: configurePhase
no configure script, doing nothing
@nix { "action": "setPhase", "phase": "buildPhase" }
Running phase: buildPhase
Executing pypaBuildPhase
Creating a wheel...
* Getting build dependencies for wheel...
* Building wheel...
2mSuccessfully built gaphor-2.8.2-py3-none-any.whl2m
Finished creating a wheel...
Finished executing pypaBuildPhase
@nix { "action": "setPhase", "phase": "pythonRuntimeDepsCheckHook" }
Running phase: pythonRuntimeDepsCheckHook
Executing pythonRuntimeDepsCheck
Checking runtime dependencies for gaphor-2.8.2-py3-none-any.whl
  - gaphas<4.0.0,>=3.1.0 not satisfied by version 4.0.0
  - jedi<0.19.0,>=0.18.1 not satisfied by version 0.19.1

Notify maintainers
@WolfangAukang
Metadata

system: "x86_64-linux"
host os: Linux 6.9.2, NixOS, 24.11 (Vicuña), 24.11.20240529.ad57eef
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.18.2
nixpkgs: /nix/store/qgbn0imyridkb9527v6gnv6z3jzzprb9-source

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

Duplicate of https://github.com/NixOS/nixpkgs/issues/291281


text:
Some Steam games using Steamworks fail to connect

Describe the bug
As the title entails, certain games, namely Ground Branch, Dungeon Defenders and Grocery Store Simulator fail to gather information from Steam, such as my friend list or trigger the overlay's invite window.
I cannot for the life of me understand why, I have attempted to wipe Steam's local contents to no avail and ended up re-installing my system which has fixed my issue. Here's the caveat of all this: My laptop which has basically the same configuration (minus the services and open ports) does not presents the same issues, this issue only has occurred after weeks of use so I am now unsure whether it is a problem with NixOS or Steam - however as I mentioned, cleaning files from Steam does not fixes the issue so I'm inclined to think it's an issue in the NixOS side.
Steps To Reproduce
I do not know how to reproduce this behaviour, but my configuration is public if that helps.
Expected behavior
I should be able under these games to connect to Steam's API and invite friends, inside them my hostname usually gets assigned as my username.
Screenshots

(Ground Branch) I should be able to see servers here, friends are able to see a few. Same case in Dungeon Defenders.

(Grocery Store Simulator) My name should not be my hostname and the icon not white - the invite friends should also open the steam overlay.

Additional context

Ground Branch logs
Grocery Story Simulator logs

Notify maintainers
@atemu @eclairevoyant @k900 @mkg20001

Metadata
 - system: `"x86_64-linux"`
 - host os: `Linux 6.10.1-zen1, NixOS, 24.11 (Vicuna), 24.11.20240802.d049530`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.5`
 - channels(root): `"nixos-24.05"`
 - nixpkgs: `/nix/store/920a6ivyd50598z8djw9x3mr33gys0j5-source`

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

I apologise for the lack of context, I truly don't know where to go from here. If I can get directions on how to debug this it would be be greatly appreciated.

$ rg -i '\bport\b' steam-16900.log
249272:2596.793:0130:0134:warn:seh:OutputDebugStringW L"[2024.03.23-07.34.26:378][807]LogNet: Created socket for bind address: 0.0.0.0 on port 7777\r\n"
249278:2596.793:0130:0134:warn:seh:dispatch_exception L"[2024.03.23-07.34.26:378][807]LogNet: Created socket for bind address: 0.0.0.0 on port 7777\r\n"
249404:2596.793:0130:0134:warn:seh:OutputDebugStringA "[2024.03.23-07.34.26:378][807]LogNet: Created socket for bind address: 0.0.0.0 on port 7777\r\n"
249408:2596.793:0130:0134:warn:seh:dispatch_exception "[2024.03.23-07.34.26:378][807]LogNet: Created socket for bind address: 0.0.0.0 on port 7777\r\n"
249806:2596.795:0130:0134:warn:seh:OutputDebugStringW L"[2024.03.23-07.34.26:380][807]LogNet: GameNetDriver IpNetDriver_2147480525 IpNetDriver listening on port 7777\r\n"
249812:2596.795:0130:0134:warn:seh:dispatch_exception L"[2024.03.23-07.34.26:380][807]LogNet: GameNetDriver IpNetDriver_2147480525 IpNetDriver listening on port 7777\r\n"
249938:2596.795:0130:0134:warn:seh:OutputDebugStringA "[2024.03.23-07.34.26:380][807]LogNet: GameNetDriver IpNetDriver_2147480525 IpNetDriver listening on port 7777\r\n"
249942:2596.795:0130:0134:warn:seh:dispatch_exception "[2024.03.23-07.34.26:380][807]LogNet: GameNetDriver IpNetDriver_2147480525 IpNetDriver listening on port 7777\r\n"

Seems like you need port 7777 opened up.

That's for hosting a dedicated server, doesn't impedes me from finding servers or opening one through UPnP. o7

In that case, I'd try removing all the log lines with :trace: and looking at the remaining lines for errors. Sorry, don't think I can help further since I don't have your games, hardware, or knowledge about the logs.

My main question really is how to reset the "state" of Steam, considering that removing Steam local files did not solve the issue but re-installing the system with the same configuration does.

Nix/nixpkgs/NixOS does not control how Steam stores its state, so that's not really a question for this repo.

I understand that, just weird how removing every trace of Steam doesn't fixes the issue - so I had to assume it could've been a NixOS problem. Will be closing this issue then.

authors: eclairevoyant wizardlink


text:
Update request: fwupd: 1.9.25 → 2.0.0

Package name: fwupd
Latest released version: 2.0.0

Current version on the unstable channel: 1.9.25
Current version on the stable/release channel: 1.9.19

[x] Checked the nixpkgs pull requests

Notify maintainers
@r-vdp

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

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

Yeah, it's on my list, but it will take a bit more time because I need to adapt our nix expression to upstream the  changes.

Completed in #351772

authors: antonmosich r-vdp


text:
How are you supposed to use fetchpatch?

Issue description
It seems unclear exactly how you are supposed to use fetchpatch. I can't find anything by searching.
Specifically, how are you supposed to determine the sha256 value in advance, as you use nix-prefetch-url to determine it for fetchurl?
Also, what really is purpose, above fetchurl? Git's commit hashes never change, so, any URL pointing to a GitHub commit will be immutable. Or at least, as immutable as any URL you might point something to. Right?
Finally, if you provide the wrong hash to fetchpatch inside a package derivation, that package fails to install with an error message – but only the first time you try it. The second time it will silently work.
Is all this documented somewhere? The contributor guide mentions fetchpatch but doesn't answer these questions I think.

You can use nix-prefetch-url to determine sha256.
Or, when building, Nix errors with wrong sha256, it throws error:
fixed-output derivation produced path '/nix/store/8x6gjhdp9yww8cb589q0cqlg9wz1amaj-at-spi2-atk-2.26.2.tar.xz' with sha256 hash '0vkan52ab9vrkknnv8y4f1cspk8x7xd10qx92xk9ys71p851z2b1' instead of the expected hash '00akn52ab9vrkknnv8y4f1cspk8x7xd10qx92xk9ys71p851z200'
cannot build derivation '/nix/store/fnrv8b63wqy3p60yrdwgvg9hcrcy2giw-at-spi2-atk-2.26.2.drv': 1 dependencies couldn't be built
error: build of '/nix/store/fnrv8b63wqy3p60yrdwgvg9hcrcy2giw-at-spi2-atk-2.26.2.drv' failed

So it says that he got: '0vkan52ab9vrkknnv8y4f1cspk8x7xd10qx92xk9ys71p851z2b1
But I provided: 00akn52ab9vrkknnv8y4f1cspk8x7xd10qx92xk9ys71p851z200
So you can change it.

You can revive https://github.com/NixOS/nixpkgs/issues/39392 discussion with fresh look perspective.

@qolii To get a hash for fetchpatch, you can not use nix-prefetch-url because it does not postprocess the patch before computing the hash. You have to use the second method described by @Anton-Latukha: write a wrong hash, then copy the right hash from the error that is printed when you attempt to build the package.
We should document this in the manual near https://nixos.org/nixpkgs/manual/#sec-patches

I'll take a look at #39392, thanks.
It seems like an oversight to have to construct a failing build in order to get at the hashes. And, as I found out in my recent PRs, if you've already downloaded patches with fetchurl, fetchpatch will find those and not even check the hashes you give it, making it very easy to PR incorrect hashes.
Would it be possible to make a fetchpatch equivalent of nix-prefetch-url? Or, since it doesn't exist already, nobody must want it very much. Am I missing something?

if you've already downloaded patches with fetchurl, fetchpatch will find those and not even check the hashes you give it

It is the other way around – it will check the hash and see that a content with such hash was already downloaded, skipping the second download. It worked for you because the uncleaned patch still applies. It failed on othersʼ computers since they did not have any content with such hash in their store and after they downloaded it, the hashes did not match.

@orivej, indeed! Does nobody else find this to be a problem?

(triage) Ugh what? @qolii or @orivej , can you provide a reproducer? That seems very weird.

@qolii well, that is how fixed-output derivations are supposed to work – the hash of the derivation is based solely on the value of its sha256 attribute. The only way we could ensure the hash matches the expression would be to build (download) the expression during every evaluation, which would defeat the purpose of fixed-output derivations.

For the sake of persistence: I suggested a change to the fixed-output mechanics on IRC which would make them more intuitive and fix the fetchpatch problem. My proposition would be to handle FO derivations just the same as regular derivations (i.e. hashing based on inputs), and then just check the output against the provided hash (but not using that hash for the $out name, or maybe only using it as an alias).
That way the usual nix semantics apply: If you change an input (curl, patchutils, url, excludes etc.) the derivation is rebuilt. The hash is still checked though, containing the impurity. A simple nix-review could check if a change invalidated any hashes.
The counter arguments were

this would blow up the nix cache, since every change to e.g. git would generate a whole bunch of now distinct fixed output derivations. That should be fixable with deduplication.
it may get hydra ratelimited/banned on upstream platforms, since it would refetch all sources every now and then

(2) probably makes this infeasible :/

Sorry, meant to post that to https://github.com/NixOS/nixpkgs/issues/48567

I think this discussion should be continued on https://discourse.nixos.org/

authors: Anton-Latukha Ekleog ckauhaus jtojnar orivej qolii timokau


text:
git pull fails with libc linking error in combinations with PKCS11 support for SSH

Issue description
Recenttly, I can not use ssh based endpoints anymore with git
It fails with:
[arian@t430s:~/Projects/nixos-stuff]$ git pull
dlopen /nix/store/picsldd7p8gc6rgpaxahjs5xrpz63lzg-yubico-piv-tool-1.6.1/lib/libykcs11.so failed: /nix/store/fg4yq8i8wd08xg3fy58l6q73cjy8hjr2-glibc-2.27/lib/libpthread.so.0: symbol __sigtimedwait, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference
git@ssh.github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Steps to reproduce
Use the following module in NixOS:
https://github.com/arianvp/nixos-stuff/tree/master/modules/yubikey
Try to git pull
ssh itself works fine.
Technical details
[arian@t430s:~/Projects/nixos-stuff]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 4.14.74, NixOS, 18.09.821.4dd9cd3f69e (Jellyfish)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.1.1`
 - channels(root): `"nixos-18.03.133126.4df3426f5a5"`
 - channels(arian): `""`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

A nix-channel --update seems to have fixed it...


text:
GitLab does not pass gitlab:check

Issue description
The NixOS GitLab service does not pass GitLab's gitlab:check application check rule. This rule must pass to receive support from GitLab.
Steps to reproduce
Run:
nix run nixpkgs.gitlab -c sudo -u gitlab  gitlab-rake gitlab:check SANITIZE=true

A number of failures will be reported. These include:

Numerous issues of the form:

3/2 ... wrong or missing hooks
  Try fixing it:
  sudo -u gitlab -H /nix/store/qx227lr5gya6f79v85fpbn2n98kqj2ah-gitlab-shell-8.4.1/bin/create-hooks /var/gitlab/state/repositories
  Check the hooks_path in config/gitlab.yml
  Check your gitlab-shell installation
  For more information see:
  doc/install/installation.md in section "GitLab Shell"
  Please fix the error above and rerun the checks.

Running the indicated command does not fix the issue.

This:

Uploads directory tmp has correct permissions? ... no
  Try fixing it:
  sudo chown -R gitlab /var/gitlab/state/uploads
  sudo find /var/gitlab/state/uploads -type f -exec chmod 0644 {} \;
  sudo find /var/gitlab/state/uploads -type d -not -path /var/gitlab/state/uploads -exec chmod 0700 {} \;
  For more information see:
  doc/install/installation.md in section "GitLab"
  Please fix the error above and rerun the checks.
Init script exists? ... no
  Try fixing it:
  Install the init script
  For more information see:
  doc/install/installation.md in section "Install Init Script"
  Please fix the error above and rerun the checks.
Init script up-to-date? ... can't check because of previous errors

Redis version >= 2.8.0? ... no
Ruby version >= 2.3.5 ? ... no

Technical details

system: "aarch64-linux"
host os: Linux 4.14.76, NixOS, 19.03pre162412.6449501902c (Koi)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.1.3
channels(root): "nixos-19.03pre162412.6449501902c"
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

CC @fpletz @globin @krav

I've been mostly able to reproduce this, but not seeing any errors in the form of "wrong or missing hooks".
Hooks on my system is a symlink to the nix store, so I guess this is a case similar to authorized_keys where upgrading and garbage collection leads to a dead symlink.
The uploads permissions seems easy to fix, same with upgrading Redis and Ruby. Init scripts we don't have AFAIK, unless it refers to the systemd unit and the pre-start script?
I get an additional error, not sure what the "default" SSH configuration is:
Git user has default SSH configuration? ... no
  Try fixing it:
  mkdir ~/gitlab-check-backup-1545132645
  sudo mv /var/gitlab/state/home/.ssh/authorized_keys.bak2 ~/gitlab-check-backup-1545132645
  sudo mv /var/gitlab/state/home/.ssh/authorized_keys.bak ~/gitlab-check-backup-1545132645
  For more information see:
  doc/ssh/README.md in section "SSH on the GitLab server"

Gitlab probably doesn't officially support NixOS, even if we would pass this check.
If you really want to go down that path, best way forward might be to reach out to them, and see what their requirements for getting support on NixOS would be - there's not much we can change downstream at this time.

authors: bgamari flokli krav


text:
Instructions for local haskell packages don't seem to work

I wanted to modify a couple of hackage packages, hsqml, and hsqml-demo-morris which depends on hsqml.
I took a copy of the sources, made my modifications and followed the instructions in the docs to create default.nix, shell.nix and hsqml.nix in /path/to/local/HsQML. and default.nix, shell.nix and hsqml-demo-morris.nix in /path/to/local/hsqml-demo-morris. I also created ~/.config/nixpkgs/config.nix as described in the docs. The only changes I made were to replace the example package names foo and bar with hsqml and hsqml-demo-morris, and to replace ghc7102 with ghc863.
If I run nix build nixpkgs.haskellPackages.hsqml, the override appears to work: It builds the local HsQML sources.
However, if I run nix build nixpkgs.haskellPackages.hsqml-demo-morris, it tries to satisfy the hsqml dependency by building hsqml from nixpkgs, ignoring the override in ~/.config/nixpkgs/config.nix.
(A simple example modification is to change the HsQML version in the local sources, so that it's obvious which sources nix is building)
I don't know why it isn't working, so I can't say whether the docs are incorrect / outdated, or whether the docs are correct and the override is broken.
Results of nix-shell -p nix-info --run "nix-info -m":

system: "aarch64-linux"
host os: Linux 3.10.104, Ubuntu, 18.04.1 LTS (Bionic Beaver)
multi-user?: no
sandbox: yes
version: nix-env (Nix) 2.2
nixpkgs: /home/thrall/nixpkgs

Can you post the precise nix expressions that you have?

Fetch HsQML and hsqml-demo-morris sources:
darcs get https://hub.darcs.net/komadori/HsQML
darcs get https://hub.darcs.net/komadori/hsqml-demo-morris
Edit ~/HsQML/hsqml.cabal to change the version from 0.3.5.1 to 0.3.5.2 (So we can tell which sources it's building)
Additional files in ~/HsQML:
default.nix:
{ nixpkgs ? import <nixpkgs> {}, compiler ? "ghc863" }:
nixpkgs.pkgs.haskell.packages.${compiler}.callPackage ./hsqml.nix { }

hsqml.nix (generated by cabal2nix):
{ mkDerivation, base, c2hs, Cabal, containers, directory, filepath
, qt5, mesa, QuickCheck, stdenv, tagged, template-haskell, text
, transformers
}:
mkDerivation {
  pname = "hsqml";
  version = "0.3.5.2";
  src = ./.;
  setupHaskellDepends = [ base Cabal filepath template-haskell ];
  libraryHaskellDepends = [
    base containers filepath tagged text transformers
  ];
  libraryPkgconfigDepends = [ qt5 mesa ];
  libraryToolDepends = [ c2hs ];
  testHaskellDepends = [
    base containers directory QuickCheck tagged text
  ];
  doCheck = false;
  homepage = "http://www.gekkou.co.uk/software/hsqml/";
  description = "Haskell binding for Qt Quick";
  license = stdenv.lib.licenses.bsd3;
}

shell.nix:
{ nixpkgs ? import <nixpkgs> {}, compiler ? "ghc863" }:
(import ./default.nix { inherit nixpkgs compiler; }).env

Additional files in ~/hsqml-demo-morris:
default.nix:
{ nixpkgs ? import <nixpkgs> {}, compiler ? "ghc863" }:
nixpkgs.pkgs.haskell.packages.${compiler}.callPackage ./hsqml-demo-morris.nix { }

hsqml-demo-morris.nix (generated by cabal2nix):
{ mkDerivation, base, containers, deepseq, directory, hsqml
, OddWord, stdenv, text
}:
mkDerivation {
  pname = "hsqml-demo-morris";
  version = "0.3.1.1";
  src = ./.;
  isLibrary = false;
  isExecutable = true;
  enableSeparateDataOutput = true;
  executableHaskellDepends = [
    base containers deepseq directory hsqml OddWord text
  ];
  homepage = "http://www.gekkou.co.uk/software/hsqml/";
  description = "HsQML-based implementation of Nine Men's Morris";
  license = stdenv.lib.licenses.bsd3;
}

shell.nix:
{ nixpkgs ? import <nixpkgs> {}, compiler ? "ghc863" }:
(import ./default.nix { inherit nixpkgs compiler; }).env

Finally, ~/.config/nixpkgs/config.nix:
{
  packageOverrides = super: let self = super.pkgs; in
  {
    haskellPackages = super.haskellPackages.override {
      overrides = self: super: {
        hsqml = self.callPackage ~/HsQML { qt5 = super.qt5Full; };
        hsqml-demo-morris = self.callPackage ~/hsqml-demo-morris {};
      };
    };
  };
}

Revisiting this, I think it might be something to do with how the command is told about nixpkgs. The docs don't mention nix build at all, only nix-build and nix-shell. I think nix build is getting nixpkgs from the environment variable, NIX_PATH.
These work:
nix-build "<nixpkgs>" -A haskellPackages.hsqml-demo-morris
nix-shell "<nixpkgs>" -A haskellPackages.hsqml-demo-morris.env

Bizarrely, after running those successfully, nix build nixpkgs.haskellPackages.hsqml-demo-morris starts working as well. I have no idea what's going on anymore.

nix build still very WIP MVP, and for today not really replacing nix-build, or in nearest time for the majority.
Also it has puzzling CLI: https://youtu.be/XVIKScU7Uf4?t=417
No wonder you confused by nix-build and nix build. It is also logical that latter is a successor. And it is a successor, but WIP. In Nix world it is a definitive tendency (was a really strong trend) to shadow and overload everything. There were such old contributors that overloaded everything with everything other. In nixpkgs I consider that rewriting a very bad code style, but in tooling, it is much more understandable. Thou that feature probably should had some 0.x version, new-* addition, like done in Cabal, or was done in Docker long ago, or WIP or beta mark somewhere, at least inside --help.
Because nix build --help not helping with information me also.
You are right that nix build mainly designed with NIX_PATH in mind. At least it is how I would use it, env ... nix build ....

authors: Anton-Latukha Thra11 xaverdh


text:
Packaging requests: CadQuery (python module)

Project description
A parametric CAD scripting framework based on PythonOCC
Metadata

homepage URL: https://github.com/CadQuery/cadquery
source URL: https://github.com/CadQuery/cadquery
license: Apache 2.0
platforms: cross-platform python

I've packaged CadQuery in https://github.com/NixOS/nixpkgs/pull/66254, just waiting for it to be merged. I'd appreciate some attention on the PR, it's been open for 3 months now.

https://github.com/marcus7070/nixpkgs/blob/cadquery-and-friends-init/pkgs/development/python-modules/cadquery/default.nix
can't still import cardery with Python module,
but maybe someday :)

I success!!. Import cadquery;;;
Phew~ It was hard. I did it in a slightly different way~*
It's too hard. nixOS but I like it..;
after... I will try to install ifcOpenShell-python...soon.
Darkness. Y,.y
Either way, cadquery & cq-editor
Thank you so much for installing help me.
Thanks a lot. :) good day~*
2019년 11월 20일 (수) 오후 12:07, Marcus Boyd notifications@github.com님이 작성:

I've packaged CadQuery in #66254
https://github.com/NixOS/nixpkgs/pull/66254, just waiting for it to be
merged. I'd appreciate some attention on the PR, it's been open for 3
months now.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/NixOS/nixpkgs/issues/72466?email_source=notifications&email_token=AAJJOPKU5L5JV6XTLJMOXJ3QUSSWPA5CNFSM4JH6M732YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEQRJ6Q#issuecomment-555816186,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJJOPI7ZHZQ3OYSFOIHYVTQUSSWPANCNFSM4JH6M73Q
.

#66254 has been merged, this can be closed.


text:
tensorflow-bin build fails

Describe the bug
Error on installation of tensorflow-bin on nixpkgs master branch
ERROR: Could not find a version that satisfies the requirement tensorboard<1.15.0,>=1.14.0 (from tensorflow==1.14.0) (from versions: none)
ERROR: No matching distribution found for tensorboard<1.15.0,>=1.14.0 (from tensorflow==1.14.0)

To Reproduce
Steps to reproduce the behavior:
nix-env -iA nixos.python37Packages.tensorflow-bin

using unstable channel
Expected behavior
tensorflow-bin should install without an error.
Metadata
Please run nix run nixpkgs.nix-info -c nix-info -m and paste the result.
% nix run nixpkgs.nix-info -c nix-info -m                                                ~
 - system: `"x86_64-linux"`
 - host os: `Linux 4.19.84, NixOS, 20.03pre201791.c1966522d7d (Markhor)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.1`
 - channels(arsleust): `"home-manager"`
 - channels(root): `"nixos-20.03pre201791.c1966522d7d"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

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

the main tensorflow package has been bumped, this should probably be bumped as well

This breaks tensorflow on darwin
cc #71282
cc @timokau
I could not find whl for 0.15.0. This page lists some: https://www.tensorflow.org/install/pip
But 0.15 is not there for some reason.

I'm not maintaining the tensorflow-bin package, but I'm sorry that I forgot to update it along with tensorflow.
Do we even still need it? The source package works pretty well.

Building tensorflow from sources fails for non-sandboxed setups because of its dependency on bazel (https://github.com/NixOS/nixpkgs/issues/66311) so this package is the only way to reliably install tensorflow there.

I could not find whl for 0.15.0. This page lists some: https://www.tensorflow.org/install/pip
But 0.15 is not there for some reason.

I found some 0.15.0 whl's on PyPi:
https://pypi.org/project/tensorflow-cpu/#files
However they seem to require tensorflow-cpu-estimator instead of tensorflow-estimator, so we would need to add that package. Also, this way of downloading would break the patterns used in the current tensorflow-bin, we would have to switch it to use fetchPyPi, probably. I don't think I will take on this.

Do we even still need it? The source package works pretty well.

Yes, another reason is because tensorflow-bin is the tensorflow on darwin.

I'm not maintaining the tensorflow-bin package, but I'm sorry that I forgot to update it along with tensorflow.
Do we even still need it? The source package works pretty well.

Building tensorflow is very, very long. Most people don't want that.
Or maybe I misunderstood something.

Yes, I think that is a misunderstanding. There is a binary cache that will save you from having to build anything yourself unless you choose to.

although, having to do overrides to get old versions does usually cause a rebuild. I ran into a runtime issue with the tensorflow-1.15 package (not sure if issue with 1.15 in general, or just our build), and had to revert it back to when 1.14 still built...

True, but in that case you could revert the whole tree to a known-good state (just as you would with the binary package).

Yes, I think that is a misunderstanding. There is a binary cache that will save you from having to build anything yourself unless you choose to.

Ok thanks. Is it because I want it to support CUDA that the regular tensorflow package does a full build from source on my computer ?

Probably, I think hydra doesn't build unfree packages. Its unfortunate that cuda support has to be present at compiletime and can't just be detected at runtime. Maybe there's some way to achieve that.

Let's update tensorflow-bin to latest 1.x version; that is 1.15

This is still broken now in the 20.03 branch, and an update has other side effects:
py2 support is gone in the latest 1.15, also the naming scheme of the packages changed.
There are also incompatible dependencies (gast==0.2.2, opt-einsum, ...?).
Maybe the easiest fix is a private bundled downgraded tensorboard.

ERROR: Could not find a version that satisfies the requirement tensorflow-estimator<1.15.0rc0,>=1.14.0rc0 (from tensorflow==1.14.0) (from versions: none)
ERROR: No matching distribution found for tensorflow-estimator<1.15.0rc0,>=1.14.0rc0 (from tensorflow==1.14.0)

I think #116496 solved this.

Also relevant #121998

authors: GuillaumeDesforges alexvorobiev averelld jonringer nbren12 prusnak timokau veprbl yorickvP


text:
Cannot update [unstable] due to build dependencies

I'm not quite sure where this comes from:
$ sudo nix-channel --update
$ sudo nixos-rebuild switch
# SOME LINES
*** Downloading
‘https://cache.nixos.org/nar/1m4kw4hr06k782xz0xykl3mvvr6pn099kjkbzd3y7yf1zkqm3xw9.nar.xz’ to ‘/nix/store/h20i09jbp107rk0hwhf9kmkqwffkq2fs-gcc-wrapper-4.8.4’...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  4136  100  4136    0     0   7822      0 --:--:-- --:--:-- --:--:--  7818

building path(s) ‘/nix/store/n10al76m3ad13hh0b1wm6n6xp5w8myla-daq-2.0.4.tar.gz’

++ echo fglrx-14.501.1003/amd-driver-installer-14.501.1003-x86.x86_64.run
+ run_file=fglrx-14.501.1003/amd-driver-installer-14.501.1003-x86.x86_64.run
+ sh fglrx-14.501.1003/amd-driver-installer-14.501.1003-x86.x86_64.run --extract .
Warning: target directory exists .
Verifying archive integrity...
trying http://www.snort.org/downloads/snort/daq-2.0.4.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
 All good.
Uncompressing AMD Catalyst(TM) Proprietary Driver-14.501.1003df: Warning: cannot read table of mounted file systems: No such file or directory
100 2192k  100 2192k    0     0   959k      0  0:00:02  0:00:02 --:--:--  959k

fetching path ‘/nix/store/khni5vkhrczfdwanfrpw5ixnsdsdc6i3-stdenv’...
......
*** Downloading ‘https://cache.nixos.org/nar/0j1ij4jc816hib9514jw6ard69xiw15c80rpaqx54skzrlfai2xv.nar.xz’ to ‘/nix/store/khni5vkhrczfdwanfrpw5ixnsdsdc6i3-stdenv’...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  7352  100  7352    0     0  12945      0 --:--:-- --:--:-- --:--:-- 12966...........

fetching path ‘/nix/store/8f1kfc0xiyam32yx362w4f2mgzndyqfb-mariadb-10.0.18-lib’...
  1  931M    1 17.8M    0     0  1791k      0  0:08:52  0:00:10  0:08:42 2816k
*** Downloading ‘https://cache.nixos.org/nar/0ihbvqlnba4c4fiwh6k361qnj20ss60xj8fn9r01349b1xxkqi46.nar.xz’ to ‘/nix/store/8f1kfc0xiyam32yx362w4f2mgzndyqfb-mariadb-10.0.18-lib’...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  3 98.3M    3 3620k    0     0   251k      0  0:06:39  0:00:14  0:06:25  219k........curl: (22) The requested URL returned error: 404 Not Found
error: cannot download daq-2.0.4.tar.gz from any mirror
builder for ‘/nix/store/rq38fv4p85xlcydhlvnfiqnclxkfx4vn-daq-2.0.4.tar.gz.drv’ failed with exit code 1
fetching path ‘/nix/store/1xxz5zckq78arcyahy53vmm8fkyq9hvz-postgresql-9.2.10’...
cannot build derivation ‘/nix/store/haqw9m20z64n080dhcrckrzy30iz92vm-daq-2.0.4.drv’: 1 dependencies couldn't be built
cannot build derivation ‘/nix/store/ahf9nw5vvlc2k042plvlf1q7q7pjm9xb-snort-2.9.7.2.drv’: 1 dependencies couldn't be built
killing process 21895
killing process 21983
killing process 21968
fetching path ‘/nix/store/f48ikgw3m5idzk366dw2lym61sp5pgvg-python-2.7.9’...
fetching path ‘/nix/store/dfa4a7zp8xkbgx3awjr1c2clc1zr3wnr-trousers-0.3.13’...
building path(s) ‘/nix/store/094x9zwjgrjmj728idqkv0g6xq82adnv-etc-file’
cannot build derivation ‘/nix/store/zc70spnbgkvqk92mp36cylzljj2fpy7i-system-path.drv’: 1 dependencies couldn't be built
killing process 24115
killing process 24107
killing process 21894
killing process 21897
building path(s) ‘/nix/store/0xawm017kzqvxlh6wawr5kg8ncfj578z-udev-path’
building path(s) ‘/nix/store/igm2ws512dqbwpy5h4pcjf8qvlj7zbqz-unit-alsa-store.service’
building path(s) ‘/nix/store/s804an7c69w8qkaqz1bjhid8r24wb7bl-unit-console-getty.service-disabled’
building path(s) ‘/nix/store/g5h1ss9mj837ak4z2c9mrz13404wv890-unit-container-getty-.service’
building path(s) ‘/nix/store/hhkdg72bmxqiqqsjvaj8w0yqqxqzxn6a-unit-cpufreq.service’
killing process 24117
killing process 24116
cannot build derivation ‘/nix/store/4xhz8lpcnn77qqiviplijwmpqv6dlyjc-nixos-15.06pre62649.f93a8ee.drv’: 1 dependencies couldn't be built
error: build of ‘/nix/store/4xhz8lpcnn77qqiviplijwmpqv6dlyjc-nixos-15.06pre62649.f93a8ee.drv’ failed

Do you need any more information?

Upstream removed daq-2.0.4.tar.gz from their servers, hence the build would fail :disappointed:

O_o this was fast.

How long until this will be in the channel?

Several days, I'm afraid. hydra.nixos.org is quite busy, so updates take at least 24 hours, typically longer.

Unfortunately I cannot build my system, still. I'm currently trying to build my system from latest master, which might be a bad idea, but I'm trying it now and if it doesn work I'll roll back.
It is a bit annoying as I'm stuck on 2d8cfe7 (which is from Apr 13th!) since ... well, that date I guess.

authors: matthiasbeyer peti


text:
imagemagick: unable to access configure file `configure.xml'

Describe the bug
I would like to use a shell script which would use the output convert -list configure, however on my nixos, along with some useful text, it prints the error:
convert: unable to access configure file 'configure.xml' @ warning/configure.c/GetConfigureOptions/677.
To Reproduce
Steps to reproduce the behavior:

Run convert -list configure
Look at the output

Expected behavior
No error, and some additional values are printed from the xml (as I cannot produce the correct output, I have no idea how it would look like).
Additional context
I'm trying to run one of the Fred's ImageMagick scripts which can be located at http://www.fmwconcepts.com/imagemagick/textcleaner/index.php.
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
these paths will be fetched (0.05 MiB download, 0.28 MiB unpacked):
/nix/store/5h35s50503spks8gkxdv3kk4szz8vx9g-bash-interactive-4.4-p23-dev
copying path '/nix/store/5h35s50503spks8gkxdv3kk4szz8vx9g-bash-interactive-4.4-p23-dev' from 'https://cache.nixos.org'...

system: "x86_64-linux"
host os: Linux 4.19.109, NixOS, 19.09.2260.3b9b10e49be (Loris)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.3.3
channels(root): "nixos-19.09.2260.3b9b10e49be, nixos-unstable-20.09pre216896.0729b8c55e0"
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

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

the problem persists in windows 10, I would be very grateful if anyone shares any solution

Rather late to the party, but this seems to be due to the half-executed dev output split done in https://github.com/NixOS/nixpkgs/commit/73f1f5eb3969743fe459e7cc36cfb766c7f5318a. Setting the correct path in the ImageMagick binaries would create a circular dependency between dev and out.
A workaround for end users would be:
export MAGICK_CONFIGURE_PATH=$(echo $(nix-build '<nixpkgs>' -A imagemagick.dev --no-out-link)/lib/ImageMagick-*/config-*)
convert -list configure

authors: csernazs juanmachuca95 rhendric


text:
Khronos Vulkan Samples not running

Describe the bug
I am able to build the Khronos Vulkan Samples but not run them.
I get an error: [error] [build/linux/app/main.cpp:75] Failed to initialize volk.
To Reproduce

Download and follow the build instruction form the Khronos Vulkan Sample repo
Run one of the examples as described in the build guide

Expected behavior
With a simple sample application like hello_triangle a multi colored triangle is supposed to show up in a window accelerated by Vulkan.
Additional context
I am extremely new to nix and nixos, I literally installed it yesterday.
So I am extremely sorry if I am posting this issue in the wrong place.
Please do correct me and I will move my question elsewhere.
I used to use Arch Linux before and I was able to get the samples to run on there.
I checked on the volk github page and it says that if it fails to find a vulkan loader it will throw that error.
I am trying to build it in a separate nix-shell with a default.nix:
{ pkgs ? import <nixpkgs> {} }:
pkgs.mkShell {
        buildInputs = [
                pkgs.gcc
                pkgs.cmake
                pkgs.mesa
                pkgs.vulkan-headers
                pkgs.vulkan-loader
                pkgs.vulkan-tools
                pkgs.vulkan-validation-layers
                pkgs.glfw2
                pkgs.libGLU
                pkgs.python3
                pkgs.xorg.libX11
                pkgs.xorg.libXcursor
                pkgs.xorg.libXrandr
                pkgs.xorg.libXinerama
                pkgs.xorg.libXi
                pkgs.xorg.libXext
        ];
}

I also tried installing the vulkan-* packages directly into my system packages but nothing changed.
I read a previous issue #57770 and tried setting the environment variable VK_ICD_FILENAMES and deleting the files in ~/.cache/ but that also did not fix the problem.
Metadata
 - system: `"x86_64-linux"`
 - host os: `Linux 5.6.5, NixOS, 20.09pre222244.22a3bf9fb9e (Nightingale)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.4`
 - channels(root): `"nixos-20.09pre222244.22a3bf9fb9e"`
 - channels(bryan): `"nixpkgs-20.09pre221814.10100a97c89"`
 - nixpkgs: `/home/bryan/.nix-defexpr/channels/nixpkgs`

I ran the program trough strace and noticed a lot of these errors:
uname({sysname="Linux", nodename="nixos", ...}) = 0
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{iov_base="\22\0\10\0\3\0 \1\375\0\0\0\4\0\0\0 \0\1\0\2\0\0\0\373\0\0\0\n\1\0\0"..., iov_len=464}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 464
poll([{fd=3, events=POLLIN}], 1, -1)    = 1 ([{fd=3, revents=POLLIN}])
recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\34\0C\0\3\0 \1\375\0\0\0y\300\270\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 288
poll([{fd=3, events=POLLIN}], 1, -1)    = 1 ([{fd=3, revents=POLLIN}])
recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\34\0L\0\3\0 \1$\0\0\0y\300\270\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 64
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{iov_base="\22\0\7\0\3\0 \1\374\0\0\0\37\0\0\0\10\0\1\0\1\0\0\0C\0\0\0\22\0\n\0"..., iov_len=108}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 108
recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\34\0N\0\3\0 \1\374\0\0\0z\300\270\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\34\0O\0\3\0 \1\10\1\0\0z\300\270\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 64
recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)

These messages happen right before it prints out the line [error] [build/linux/app/main.cpp:75] Failed to initialize volk..
I also tried running it in gdb, it crashes with the following message:
(gdb) file ./build/linux/app/bin/Release/x86_64/vulkan_samples
Reading symbols from ./build/linux/app/bin/Release/x86_64/vulkan_samples...
(gdb) run hello_triangle
Starting program: /home/bryan/Downloads/Vulkan-Samples/build/linux/app/bin/Release/x86_64/vulkan_samples hello_triangle
warning: File "/nix/store/jy89v2q2zv074mvw91jgqcvkmk7yqx69-gcc-9.3.0-lib/lib/libstdc++.so.6.0.28-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load:/nix/store/ihr026g1ijgmjiqn4xn39bk5rr1w379j-gcc-9.3.0-lib".
To enable execution of this file add
	add-auto-load-safe-path /nix/store/jy89v2q2zv074mvw91jgqcvkmk7yqx69-gcc-9.3.0-lib/lib/libstdc++.so.6.0.28-gdb.py
line to your configuration file "/home/bryan/.gdbinit".
To completely disable this security protection add
	set auto-load safe-path /
line to your configuration file "/home/bryan/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
	info "(gdb)Auto-loading safe path"
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/nix/store/v9j0bsl1bv7ngijmvnvnj9h3qrb1p3mf-glibc-2.30/lib/libthread_db.so.1".
[info] Logger initialized
[info] Window created
[info] Initializing vulkan instance.
[error] [build/linux/app/main.cpp:75] Failed to initialize volk.
[info] Closing App (Runtime: 0.0)

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) backtrace
#0  0x0000000000000000 in ?? ()
#1  0x00000000004a261b in HelloTriangle::teardown(HelloTriangle::Context&) ()
#2  0x00000000004a2901 in HelloTriangle::~HelloTriangle() ()
#3  0x00000000004a2a19 in HelloTriangle::~HelloTriangle() ()
#4  0x0000000000507f2a in vkb::Platform::terminate(vkb::ExitCode) ()
#5  0x000000000040f159 in main.cold ()
#6  0x00007ffff797fd8b in __libc_start_main () from /nix/store/an6bdv4phxsz14q2sk57iscl2dc7bnj1-glibc-2.30/lib/libc.so.6
#7  0x000000000047f32a in _start () at ../sysdeps/x86_64/start.S:120

I was able to get the hello triangle to run from vulkan-tutorial.
So I am assuming this is a problem with either volk or the Khronos Vulkan Samples themselves.
I will take this issue over there.

OK, I am posting one last update since I figured out what was wrong.
I am also tagging the vulkan-loader package maintainer, since I am not sure if this is intended to work like this @Ralith.
So, volk opens a vulkan loader with dlopen in this line:
void* module = dlopen("libvulkan.so", RTLD_NOW | RTLD_LOCAL);

but since the libvulkan.so file it is looking for is not included in dlopen's (or ld's) search path it fails.
I first got around this by replacing said line with:
void* module = dlopen("/nix/store/xxxx-vulkan-loader-1.2.131.2/lib/libvulkan.so", RTLD_NOW | RTLD_LOCAL);

But that is a little bit too hacky in my opinion, and if the nix store path changes or disappears, it'll break the program again. so I tried editing my default.nix to this:
with import <nixpkgs> {};
stdenv.mkDerivation rec {
        name = "Vulkan-Samples";
        buildInputs = [
                pkgs.gcc
                pkgs.cmake
                pkgs.mesa
                pkgs.vulkan-headers
                pkgs.vulkan-loader
                pkgs.vulkan-tools
                pkgs.vulkan-validation-layers
                pkgs.glfw
                pkgs.glm
                pkgs.libGLU
                pkgs.python3
                pkgs.xorg.libX11
                pkgs.xorg.libXcursor
                pkgs.xorg.libXrandr
                pkgs.xorg.libXinerama
                pkgs.xorg.libXi
                pkgs.xorg.libXext
                pkgs.xorg.libXrender
                pkgs.xorg.libXxf86vm
                pkgs.xorg.libXdmcp
                pkgs.xorg.libXau
                pkgs.xorg.libxcb
                pkgs.gnutls
                pkgs.xorg.libpthreadstubs
                pkgs.llvm_10
                pkgs.clang_10
                pkgs.pkg-config
        ];

        LD_LIBRARY_PATH="${pkgs.vulkan-loader}/lib";

        shellHook = "echo ${pkgs.vulkan-loader}";
}

I know there probably is a bunch of packages in there right now I do not actually need but those are worries for another time.
The important line here is LD_LIBRARY_PATH="${pkgs.vulkan-loader}/lib";.
When changing to a shell with this default.nix the program builds and runs without any errors or warnings.
Running the hello_triangle sample produces the correct triangle this time :D.

Now I am wondering if this is the correct way to dynamically link with vulkan-loader or if there is an option that I did not see.

You'll frequently run into this problem when using dlopen with nix-packaged libraries. You have a few different reasonable options to address it:

Place the library in LD_LIBRARY_PATH in the runtime environment, as you've done. This is easy, and convenient when initially experimenting with someone else's code, but impermanent, and an ugly hack if you distribute your software that way.
Add the library to the rpath embedded in the binary, either after the fact with patchelf or by telling your linker to do so when building. Because it avoids a wrapper script, this is the preferred approach in nixpkgs when the dlopen can't be avoided, e.g. for proprietary software.
Replace the use of dlopen with conventional dynamic linking. This will allow Nix's usual mechanisms to Just Work, and should be preferred whenever possible.

Place the library in LD_LIBRARY_PATH in the runtime environment, as you've done. This is easy, and convenient when initially experimenting with someone else's code, but impermanent, and an ugly hack if you distribute your software that way.

I think I will stick with this solution for now since my own application will be statically linked, so that shouldn't be a problem.
I am however going to looking into point 2 and 3, just to broaden my knowledge :).
Thanks for the reply, I will close this issue.

You shouldn't statically link the vulkan loader; it's specifically designed to be upgraded independent of applications, for compatibility with future drivers and layers. It's also impossible to have a 100% statically linked application that uses vulkan at all, because video drivers are dynamically loaded, which requires a dynamically linked libc.

authors: Ralith bryanhonof


text:
haskell: Should we should run tests for hspec

Currently hspec has doCheck = false presumably due to infinite recursion.
The culprit is stringbuilder test dependency which depends on hspec in its own test-suite.
For hspec therefore, it might be worthwhile enabling tests and simply setting dontCheck on the stringbuilder used for hspec.
In my dev default.nix for hspec, I just have
  testDepends = [
    base directory hspec-core hspec-meta (hlib.dontCheck stringbuilder)
  ];

It does mean that we end up building stringbuilder twice (once normally and once for hspec) but it's a small package.
What do you think @peti ?

I've made the necessary changes in the haskell-updates branch. Thank you very much for the suggestion! The only risk I see with this kind of trickery is that we don't want stringbuilder ever to become a real dependency of the library, because then it will be propagated to users of the package and we might end up in a situation where builds have two seemingly identical versions of stringbuilder in path without a way to distinguish them.

Awesome, closing.

authors: Fuuzetsu peti


text:
doc: Document a workaround for using an FQDN as hostname

Since #76542 this workaround is required to use a FQDN as hostname. See
#94011 and #94022 for the related discussion. Due to some
potential/unresolved issues (legacy software, backward compatibility,
etc.) we're documenting this workaround 0.

Status
nixos-rebuild works but I couldn't test the NixOS manual due to:
error: a 'aarch64-linux' with features {} is required to build '/nix/store/1pppcxbi7m74j52fziprdx5q6mp1n8rs-options-docbook.xml.drv', but I am a 'x86_64-linux' with features {benchmark, big-parallel, kvm, nixos-test}

Either there must be a regression or nix-build nixos/release.nix -A manual isn't the correct command anymore.
Things done

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

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

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

for the nixos manual, you need to specificy an architecture
nix-build nixos/release.nix -A manual.x86_64-linux

authors: jonringer primeos


text:
nixos/caddy: remove services.caddy.agree

This option is no longer referenced anywhere as of #99371.

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
[x] Fits CONTRIBUTING.md.

Shouldn’t the caddy 2 module still require this (or check security.acme.acceptTerms, which would probably make more sense that a sperrte option meaning the same thing)? It looks like it will still request certificates from letsencrypt automatically by default? cc @sephii

Nope! It's unconditional now. I believe this was introduced in this commit, although I'm not entirely certain.

A port to stable for this would also be nice

@worldofpeace Done.

authors: alyssais deviant worldofpeace


text:
jquery: 1.11.2 -> 1.11.3

Builds locally for me.

Pushed to master (bff59c5f00f6cde0cd00bedf5cc8cd95e23153aa). I added the 2nd hash (for the "uncompressed" download).

authors: bjornfor matthiasbeyer


text:
oraclejdk: 8u60 -> 8u66

Bumping Oracle JDK patch version from 60 to 66.
There is no publicly available download for patch version 60 anymore. The URL given only provides 8u65 and 8u66.

How does this relate to #10510?

Sorry, didn't see that PR. That looks better, withdrawing mine.

authors: chris-martin vbgl


text:
vsh: 0.7.2 -> 0.8.0

Motivation for this change
bump vsh version 0.7.2 -> 0.8.0
Things done

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

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

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] 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.

This is a semi-automatic executed nixpkgs-review which is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 110947 run on x86_64-darwin 1

1 package built:

vsh

This is a semi-automatic executed nixpkgs-review which is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 110947 run on x86_64-darwin 1

1 package built:

vsh


text:
wrapFish: fix singleton expansion in shell init

This fixes the expansion of the configuration path in the pathological
case of a singleton, which would otherwise be used verbatim with the
surrounding braces for lookup.
GitHub: see https://github.com/NixOS/nixpkgs/pull/108491#pullrequestreview-590072603

Motivation for this change
Things done

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

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

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

CC @teehemkay

Result of nixpkgs-review pr 113232 at 9c62b915 run on x86_64-linux 1

2 packages built:

fishPlugins.fishtape
fishPlugins.pure

authors: pacien r-rmcgibbo


text:
ghq: 1.1.5 -> 1.1.6

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/x-motemen/ghq/releases.
meta.description for ghq is: "Remote repository management made easy"
meta.homepage for ghq is: "https://github.com/x-motemen/ghq"
meta.changelog for ghq 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.1.6 with grep in /nix/store/gwgqyy962nig739q5380k9yb1g843my9-ghq-1.1.6

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

du listing: https://gist.github.com/9eece93e234c71e10a7bc4607abc09ec

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
ghq

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/gwgqyy962nig739q5380k9yb1g843my9-ghq-1.1.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 ghq https://github.com/r-ryantm/nixpkgs/archive/d39556b88d7fd344a4361a385483894325a747e4.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/gwgqyy962nig739q5380k9yb1g843my9-ghq-1.1.6
ls -la /nix/store/gwgqyy962nig739q5380k9yb1g843my9-ghq-1.1.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:

ghq

Maintainer pings
cc @sigma @kalbasit for testing.

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

1 package built:

ghq

authors: fabaff r-ryantm


text:
helio-workstation: 3.3 -> 3.4

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"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 117453 at c28c61b7 run on x86_64-linux 1

1 package built successfully:

helio-workstation

1 suggestion:

warning: missing-phase-hooks
installPhase should probably contain runHook preInstall and runHook postInstall.
Near pkgs/applications/audio/helio-workstation/default.nix:31:3:
   |
31 |   installPhase = ''
   |   ^

authors: r-rmcgibbo suhr


text:
charles: 4.2.8 -> 4.6.1

Motivation for this change
upstream changelog

Note that as of 4.5, charles 4 now requires jdk11, and also has a different download path. I've updated that such that charles 3 will still build. (I did also test jdk11 with charles 3 to see if that was functional, but it doesn't appear to be)
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
[ ] macOS
[ ] other Linux distributions

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

Result of nixpkgs-review pr 117939 at 5bbadc0d run on x86_64-linux 1

1 package built successfully:

charles (charles4)

2 suggestions:

warning: missing-phase-hooks
installPhase should probably contain runHook preInstall and runHook postInstall.
Near pkgs/applications/networking/charles/default.nix:34:7:
   |
34 |       installPhase = ''
   |       ^

warning: missing-phase-hooks
installPhase should probably contain runHook preInstall and runHook postInstall.
Near pkgs/applications/networking/charles/default.nix:34:7:
   |
34 |       installPhase = ''
   |       ^

This is a semi-automatic executed nixpkgs-review with nixpkgs-review-checks extension. It is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 117939 run on x86_64-linux 1

1 package built:

charles (charles4)

authors: SuperSandro2000 r-rmcgibbo victorluft


text:
python3Packages.watchdog: 2.1.1 -> 2.1.2

Motivation for this change
Update to latest upstream release 2.1.2
Change log: https://github.com/gorakhargosh/watchdog/releases/tag/v2.1.2
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.

Result of nixpkgs-review pr 123731 at 1495945f run on aarch64-linux 1

58 packages built successfully:

aws-sam-cli
coconut (python38Packages.coconut)
datasette (python38Packages.datasette)
devpi-client
devpi-server
home-assistant
hovercraft
maestral (python38Packages.maestral)
maestral-gui
markdown-pp
octoprint
pympress
python38Packages.Nikola
python38Packages.bpython
python38Packages.cornice
python38Packages.deform
python38Packages.easywatch
python38Packages.hupper
python38Packages.lektor
python38Packages.ndjson
python38Packages.pypugjs
python38Packages.pyramid
python38Packages.pyramid_beaker
python38Packages.pyramid_chameleon
python38Packages.pyramid_exclog
python38Packages.pyramid_hawkauth
python38Packages.pyramid_jinja2
python38Packages.pyramid_mako
python38Packages.pyramid_multiauth
python38Packages.pytest-watch
spyder (python38Packages.spyder)
staticjinja (python38Packages.staticjinja)
python38Packages.watchdog
python39Packages.Nikola
python39Packages.bpython
python39Packages.coconut
python39Packages.cornice
python39Packages.datasette
python39Packages.deform
python39Packages.easywatch
python39Packages.hupper
python39Packages.lektor
python39Packages.maestral
python39Packages.ndjson
python39Packages.pypugjs
python39Packages.pyramid
python39Packages.pyramid_beaker
python39Packages.pyramid_chameleon
python39Packages.pyramid_exclog
python39Packages.pyramid_hawkauth
python39Packages.pyramid_jinja2
python39Packages.pyramid_mako
python39Packages.pyramid_multiauth
python39Packages.pytest-watch
python39Packages.staticjinja
python39Packages.watchdog
streamlit
topydo

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

28 packages failed to build:

home-assistant
python38Packages.Nikola
python39Packages.Nikola
python39Packages.bpython
python39Packages.buildbot
python39Packages.buildbot-full
python39Packages.buildbot-ui
python39Packages.coconut
python39Packages.cornice
python39Packages.datasette
python39Packages.deform
python39Packages.easywatch
python39Packages.hupper
python39Packages.lektor
python39Packages.maestral
python39Packages.ndjson
python39Packages.pypugjs
python39Packages.pyramid
python39Packages.pyramid_beaker
python39Packages.pyramid_chameleon
python39Packages.pyramid_exclog
python39Packages.pyramid_hawkauth
python39Packages.pyramid_jinja2
python39Packages.pyramid_mako
python39Packages.pyramid_multiauth
python39Packages.pytest-watch
python39Packages.staticjinja
python39Packages.watchdog

37 packages built:

aws-sam-cli
buildbot (python38Packages.buildbot)
buildbot-full (python38Packages.buildbot-full)
buildbot-ui (python38Packages.buildbot-ui)
coconut (python38Packages.coconut)
datasette (python38Packages.datasette)
devpi-client
devpi-server
hovercraft
maestral (python38Packages.maestral)
maestral-gui
markdown-pp
octoprint
pympress
python38Packages.bpython
python38Packages.cornice
python38Packages.deform
python38Packages.easywatch
python38Packages.hupper
python38Packages.lektor
python38Packages.ndjson
python38Packages.pypugjs
python38Packages.pyramid
python38Packages.pyramid_beaker
python38Packages.pyramid_chameleon
python38Packages.pyramid_exclog
python38Packages.pyramid_hawkauth
python38Packages.pyramid_jinja2
python38Packages.pyramid_mako
python38Packages.pyramid_multiauth
python38Packages.pytest-watch
spyder (python38Packages.spyder)
staticjinja (python38Packages.staticjinja)
python38Packages.watchdog
streamlit
tests.trivial
topydo

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

31 packages failed to build:

datasette (python38Packages.datasette)
devpi-client
devpi-server
home-assistant
python38Packages.Nikola
python38Packages.cornice
python38Packages.deform
python38Packages.hupper
python38Packages.pypugjs
python38Packages.pyramid
python38Packages.pyramid_beaker
python38Packages.pyramid_chameleon
python38Packages.pyramid_exclog
python38Packages.pyramid_hawkauth
python38Packages.pyramid_jinja2
python38Packages.pyramid_mako
python38Packages.pyramid_multiauth
python39Packages.Nikola
python39Packages.cornice
python39Packages.datasette
python39Packages.deform
python39Packages.hupper
python39Packages.pypugjs
python39Packages.pyramid
python39Packages.pyramid_beaker
python39Packages.pyramid_chameleon
python39Packages.pyramid_exclog
python39Packages.pyramid_hawkauth
python39Packages.pyramid_jinja2
python39Packages.pyramid_mako
python39Packages.pyramid_multiauth

27 packages built:

aws-sam-cli
coconut (python38Packages.coconut)
hovercraft
maestral (python38Packages.maestral)
maestral-gui
markdown-pp
octoprint
pympress
python38Packages.bpython
python38Packages.easywatch
python38Packages.lektor
python38Packages.ndjson
python38Packages.pytest-watch
spyder (python38Packages.spyder)
staticjinja (python38Packages.staticjinja)
python38Packages.watchdog
python39Packages.bpython
python39Packages.coconut
python39Packages.easywatch
python39Packages.lektor
python39Packages.maestral
python39Packages.ndjson
python39Packages.pytest-watch
python39Packages.staticjinja
python39Packages.watchdog
streamlit
topydo

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

2 packages failed to build:

python38Packages.Nikola
python39Packages.Nikola

63 packages built:

aws-sam-cli
buildbot (python38Packages.buildbot)
buildbot-full (python38Packages.buildbot-full)
buildbot-ui (python38Packages.buildbot-ui)
coconut (python38Packages.coconut)
datasette (python38Packages.datasette)
devpi-client
devpi-server
home-assistant
hovercraft
maestral (python38Packages.maestral)
maestral-gui
markdown-pp
octoprint
pympress
python38Packages.bpython
python38Packages.cornice
python38Packages.deform
python38Packages.easywatch
python38Packages.hupper
python38Packages.lektor
python38Packages.ndjson
python38Packages.pypugjs
python38Packages.pyramid
python38Packages.pyramid_beaker
python38Packages.pyramid_chameleon
python38Packages.pyramid_exclog
python38Packages.pyramid_hawkauth
python38Packages.pyramid_jinja2
python38Packages.pyramid_mako
python38Packages.pyramid_multiauth
python38Packages.pytest-watch
spyder (python38Packages.spyder)
staticjinja (python38Packages.staticjinja)
python38Packages.watchdog
python39Packages.bpython
python39Packages.buildbot
python39Packages.buildbot-full
python39Packages.buildbot-ui
python39Packages.coconut
python39Packages.cornice
python39Packages.datasette
python39Packages.deform
python39Packages.easywatch
python39Packages.hupper
python39Packages.lektor
python39Packages.maestral
python39Packages.ndjson
python39Packages.pypugjs
python39Packages.pyramid
python39Packages.pyramid_beaker
python39Packages.pyramid_chameleon
python39Packages.pyramid_exclog
python39Packages.pyramid_hawkauth
python39Packages.pyramid_jinja2
python39Packages.pyramid_mako
python39Packages.pyramid_multiauth
python39Packages.pytest-watch
python39Packages.staticjinja
python39Packages.watchdog
streamlit
tests.trivial
topydo

@fabaff Nikola was fixed in staging-next by fixing libxml2, please remove the commit.

Nikola was fixed in staging-next by fixing libxml2, please remove the commit.

Thanks, removed.

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

2 packages failed to build:

python38Packages.Nikola
python39Packages.Nikola

62 packages built:

aws-sam-cli
buildbot (python38Packages.buildbot)
buildbot-full (python38Packages.buildbot-full)
buildbot-ui (python38Packages.buildbot-ui)
coconut (python38Packages.coconut)
datasette (python38Packages.datasette)
devpi-client
devpi-server
home-assistant
hovercraft
maestral (python38Packages.maestral)
maestral-gui
markdown-pp
octoprint
pympress
python38Packages.bpython
python38Packages.cornice
python38Packages.deform
python38Packages.easywatch
python38Packages.hupper
python38Packages.lektor
python38Packages.ndjson
python38Packages.pypugjs
python38Packages.pyramid
python38Packages.pyramid_beaker
python38Packages.pyramid_chameleon
python38Packages.pyramid_exclog
python38Packages.pyramid_hawkauth
python38Packages.pyramid_jinja2
python38Packages.pyramid_mako
python38Packages.pyramid_multiauth
python38Packages.pytest-watch
spyder (python38Packages.spyder)
staticjinja (python38Packages.staticjinja)
python38Packages.watchdog
python39Packages.bpython
python39Packages.buildbot
python39Packages.buildbot-full
python39Packages.buildbot-ui
python39Packages.coconut
python39Packages.cornice
python39Packages.datasette
python39Packages.deform
python39Packages.easywatch
python39Packages.hupper
python39Packages.lektor
python39Packages.maestral
python39Packages.ndjson
python39Packages.pypugjs
python39Packages.pyramid
python39Packages.pyramid_beaker
python39Packages.pyramid_chameleon
python39Packages.pyramid_exclog
python39Packages.pyramid_hawkauth
python39Packages.pyramid_jinja2
python39Packages.pyramid_mako
python39Packages.pyramid_multiauth
python39Packages.pytest-watch
python39Packages.staticjinja
python39Packages.watchdog
streamlit
topydo

authors: dotlambda fabaff r-rmcgibbo


text:
materia-kde-theme: init at 20210612

Motivation for this change
I plan to switch from archlinux with nix to nixos, so I'm trying to add this pkg to nixpkgs, with some reference to the arc-kde implementation for some work. Please let me know if there are any shortcomings.
Things done

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

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

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes

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

[x] Fits CONTRIBUTING.md.

The problematic part has been revised.


text:
[21.05] mautrix telegram: 0.10.0 -> 0.10.1

Motivation for this change
#134792
Things done

Built on platform(s)

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

[x] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

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

[x] Fits CONTRIBUTING.md.

By the way, this jumped from 0.9.0 to 0.10.1, not from 0.10.0.
This caused some database migration to happen automatically.


text:
python3Packages.dm-tree: init at 0.1.6

Motivation for this change
Add the dm-tree package. This is a dependency of many other packages released by deepmind/google.
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

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

[x] Fits CONTRIBUTING.md.

If there are no objections in the next few days, I'll go ahead and merge this.


text:
Acme: add webroots to ReadWritePaths

Since 7a10478ea7b992ffa1f19f389e53df0fe2aa936d, all /var except
/var/lib/acme gets mounted in a read-only fashion. This behavior
breaks the existing acme deployments having a webroot set outside of
/var/lib/acme.
Collecting the webroots and adding them to the paths read/write
mounted to the systemd service runtime tree.
Fixes #139310
Manually tested on my personal deployment.

@GrahamcOfBorg test acme

It won't be quite as easy as appending to the commonServiceConfig. Ideally:

we dedupe webroots in the list, and
we only add webroots relevant to the respective services for a given cert.

To solve the second point all you really have to do is add the webroots only in serviceConfig around line 243

@GrahamcOfBorg test acme

Mmmh, this new patch does not solve the issue anymore on my test config.
Don't merge that PR yet, I'll have a closer look tonight.

Alright, it seems to work both on my personal deployment and in the NixOS test.
PTAL
@GrahamcOfBorg test acme

The commit message should start with nixos/acme:.

@GrahamcOfBorg test acme

The nixos test isn't failing on my computer. I'm confused, I don't understand what's happening.
I think that's about as far as I'll push this PR. Feel free to push/rebase on my branch to fix this issue.

Okay, I finally found what I was doing wrong here. I was injecting some null values to the ReadWritePaths list by mistake.
Systemd was then unable to parse the whole ReadWritePaths directive. And, as usual, was silently ignoring it instead of throwing an error.
Filtering out the null webroots fixes the issue.
@GrahamcOfBorg test acme

authors: NinjaTrappeur m1cr0man mweinelt


text:
python3Packages.pyefergy: init at 0.1.0

Motivation for this change
An API library for Efergy energy meters
https://github.com/tkdrob/pyefergy
This is a Home Assistant dependency.
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

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

[x] Fits CONTRIBUTING.md.

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

4 packages built:

python38Packages.iso4217
python38Packages.pyefergy
python39Packages.iso4217
python39Packages.pyefergy

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

4 packages built:

python38Packages.iso4217
python38Packages.pyefergy
python39Packages.iso4217
python39Packages.pyefergy


text:
zld: init at 1.3.3

Motivation for this change
zld is a faster linker than Apple's linker.
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

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

[x] Fits CONTRIBUTING.md.

I completely agree that we should build it from source. However in the meanwhile, no one has access to it. Let's merge this for now and then when someone has time and motivation we can improve this.

@rgnns could you just rebase your changes when you have a moment ?

Sorry, I hadn't had time to go back to this. I'll rebase and revisit building it later, I think I was close to getting that done.

Unfortunately, seems like I made some cleanup to my Github forks and must have accidentally deleted nixpkgs which had my work. I created a new pull request with the changes: https://github.com/NixOS/nixpkgs/pull/164663

authors: happysalada rgnns


text:
cbqn-standalone: fix installPhase on darwin

Motivation for this change
ZHF: #144627 @NixOS/nixos-release-managers
I was extremely tempted to change the version string too to the standard unstable-xxxx-xx-xx but I'm sure it's weird for some reason. Problem is it includes characters that require escapes which is nasty.
Things done

Built on platform(s)

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

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

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

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

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

[ ] Fits CONTRIBUTING.md.

@ofborg build cbqn cbqn-standalone

I was extremely tempted to change the version string too to the standard unstable-xxxx-xx-xx but I'm sure it's weird for some reason. Problem is it includes characters that require escapes which is nasty.

Same, but I think @AndersonTorres would insist on it (authored https://github.com/NixOS/rfcs/pull/107 after all). I figured there's no real use in arguing about it.

authors: risicle sternenseemann


text:
python3Packages.qiskit-aqua: disable slow tests

Motivation for this change
These tests were timing out, they pass locally but can overrun the timeout threshold depending on system load and speed.
System load shouldn't cause hydra failures, so disabling.
Things done

Built on platform(s)

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

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

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

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

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

[x] Fits CONTRIBUTING.md.

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

4 packages built:

python38Packages.qiskit
python38Packages.qiskit-aqua
python39Packages.qiskit
python39Packages.qiskit-aqua

authors: drewrisinger fabaff


text:
python3Packages.afdko: fix build against fonttols-4.28

Without the change afdko fails to build in staging as:
$ nix build -f . python3Packages.afdko
...
python3.9-afdko> AttributeError: 'Options' object has no attribute 'allowVID'

Part of #157350

authors: jtojnar trofi


text:
perlPackages.PLS: shorten shebang on Darwin

Description of changes
Shebang is too long to be correctly executed on Darwin, so shorten it during post install.
Things done

Built on platform(s)

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

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

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

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

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

[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg build perlPackages.PLS

authors: pborzenkov stigtsp


text:
ucarp: add -fcommon workaround

Workaround build failure on -fno-common toolchains like upstream
gcc-10. Otherwise build fails as:
ld: daemonize.o:/build/ucarp-1.5.2/src/ip_carp.h:73: multiple definition of
  `__packed'; ucarp.o:/build/ucarp-1.5.2/src/ip_carp.h:73: first defined here

Description of changes

Things done

Built on platform(s)

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

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

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

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

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

[x] Fits CONTRIBUTING.md.

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

1 package built:

ucarp

authors: oxzi trofi


text:
whalebird: 4.5.4 -> 4.6.0

Description of changes

changelog: https://github.com/h3poteto/whalebird-desktop/releases/tag/4.6.0
notable changes:

upgrades vue 2.6.14 -> 3.2.31
fixes spoiler button style

Things done

Built on platform(s)

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

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

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

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

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

[ ] Fits CONTRIBUTING.md.

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

1 package built:

whalebird

closing in favor of #176476

authors: WolfangAukang uninsane


text:
pidging, libmaxminddb, simutrans, tiptop: remove myself

... from meta.maintainers.  I haven't been willing to spend nontrivial effort on these packages in the past year or more.  I don't use them anymore.

GitHub suggests @ajs124, so maybe there's a chance of you being interested in some of these packages and might want to put yourself into meta.maintainers.

Feel free to add me to libmaxminddb. I don't use the rest though, either.


text:
crackmapexec: 5.2.2 -> 5.3.0

Description of changes
https://github.com/Porchetta-Industries/CrackMapExec/releases/tag/v5.3.0

Things done

Built on platform(s)

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

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

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

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

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

[x] Fits CONTRIBUTING.md.

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

5 packages built:

crackmapexec
python310Packages.aardwolf
python310Packages.arc4
python39Packages.aardwolf
python39Packages.arc4


text:
python310Packages.twilio: 7.12.1 -> 7.13.0

Description of changes
https://github.com/twilio/twilio-python/releases/tag/7.13.0

Things done

Built on platform(s)

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

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

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

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

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

[x] Fits CONTRIBUTING.md.

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

3 packages built:

home-assistant-component-tests.twilio
python310Packages.twilio
python39Packages.twilio