text:
旧版本拉取最新版本后f2fpay无法使用的bug

我确认我已经阅读了 (使用 "x" 选择)

[x ] 项目 Wiki
[x ] 项目其他 issue

我确认我做到了 (使用 "x" 选择)

[x ] 将项目升级到当前分支最新版本
[ ] 在项目演示站成功复现问题

我正在申请  (使用 "x" 选择)

[x ] 反馈一个 bug
[ ] 申请添加新的特性或功能或者好的想法

反馈BUG
1.请在面板路径下运行git show HEAD，然后贴出输出内容
2.如果是页面问题（500 或 Slim Application Error )，请在 config 开启 debug 模式后截图或贴出输出内容，如果是某个按钮点击没反应，请打开浏览器开发者控制台（通常为 F12 ) ，贴出 console 输出内容

旧版本拉取最新版本后，支付提示错误，开发者模式下显示500错误和Slim Application Error

我也出现一样的问题，你解决了吗？


text:
Update nethsm dependency

This update pulls in multiple relevant changes, mainly:

The auto-generated client is only loaded if required.  This improves execution times significantly, especially for simple commands.
Key certificates are now always stored as raw bytes, not as strings, so the get-certificate and set-certificate commands had to be updated.
Changing the backup and unlock passphrases now requires passing the current passphrase.
Using enums instead of strings.
Using stronger types and dataclasses for some methods.
NetHSM API changes that are not visible in the public Python API.

On my machine, this reduces the execution time for simple commands like version or --help from 0.9 s to 0.3 s.

This also enables strict typing checks for the nethsm CLI module so that updates will hopefully be easier in the future.

The latest API Spec contains three warnings. Could these or similar warnings be shown when calling the appropriate commands?

source: gharchive/pull-request

repo: Nitrokey/pynitrokey

license_type: permissive

license_source: github-api


text:
Include a custom .profile and/or .mksh file

Although we do mostly focus on the end-user that uses graphical software, it's not a bad idea to also make the Terminal look and feel beautiful too.
Some custom features to include where appropriate:

Try to adapt Powerline to work with mksh.
Pre-configured Linuxbrew paths.

# Linuxbrew setup.
if [ -d /home/linuxbrew/.linuxbrew ]; then
    LINUXBREW=/home/linuxbrew/.linuxbrew
else
    LINUXBREW=$HOME/.linuxbrew
fi

export PATH="$LINUXBREW/bin:$PATH"
export MANPATH="$LINUXBREW/share/man:$MANPATH"
export INFOPATH="$LINUXBREW/share/info:$INFOPATH"

export PATH=$HOME/go/bin:$PATH

mksh autocomplete (necessary)
Others?

We switched to zsh for the interactive user shell, and we include a default zshrc configuration file.

source: gharchive/issue

repo: Nitrux/nitrux-iso-tool


text:
Lowest Common Ancestor of a Binary Tree

Problem Link
https://leetcode.com/problems/lowest-common-ancestor-of-a-binary-tree/
Coding platform
LeetCode
Programming language

[ ] C
[x] C++
[x] Java
[ ] Python

Additional context (OPTIONAL)
A Tree Problem

Assign me in C++.

Hi @Nivedita967
I would like to solve it in Java as part of CrossWoc'21. Please assign it to me.

If it is open for Java. Please assign it to me

@Nivedita967 can I work using python??

@Nivedita967 can I work using python??

Sure @Amit366 Go for it.

license: MIT


text:
Search only works in Firefox incognito

If I load up search.nixos.org on my browser, any attempt to search results in Uncaught TypeError: n is undefined in bundle.js. Interestingly, this issue goes away if I open the same in incognito mode, but persists if I disable the cache via the network tab in FF. Any ideas as to what's going on? Thanks!

fwiw cannot reproduce

Yeah, I didn't expect it to be easily reproducible. When I load the page outside of incognito, the console prints a warning that the page is compiled in dev mode. In the network inspector, there's no difference in which assets are queried nor does there seem to be any difference in the response. The error outside of incognito seems to have changed though: TypeError: e.llRecoveryInstitute is undefined.
Disabling and enabling all my extensions one-by-one to pinpoint a cause doesn't show anything either. Honestly, I'm quite mystified. I have no idea what else varies between incognito and normal.

The problem fixed itself some time over the past few months. Feel free to close the issue (especially if no one else has experienced this). Thanks!

Hi, I seem to have the same problem. There is one small difference though: I only have the first error (Uncaught TypeError: n is undefined). It appears one time on each keystroke, and when I hit search it starts repeating endlessly.
The search results are actually there, by the way. I can see them in Developer Mode -> Network -> Response -> hits
I've been having this problem for something like a month now but haven't seen anyone taking about this.
If anyone has the same problem and stumbles across this issue, I've been using nix-search-cli and can recommend it.

Experienced this today.
macOS Monterey 12.7.5
Firefox 126.0
I opened https://search.nixos.org/packages and searched for "beyondcompare" results page loaded, a few seconds later went blank.
Page info (lock icon > Connection secure > Security tab "is this website storing information on my computer": Yes 9 bytes
"Clear Cookies and site data" fixed the issue for me. Also after repeated successful searches (including "beyondcompare") "is this website storing information on my computer": No

Later the problem reappeared. Still "is this website storing information on my computer": No

A possible reproduction:
macOS Monterey 12.7.5
Firefox 126.0
System Preferences > General > Appearance "Dark" selected

Open a new tab and paste https://search.nixos.org/packages Enter. The normal search page appears.
Add a trailing slash https://search.nixos.org/packages/ Enter. A blank white page appears.
Remove the trailing slash https://search.nixos.org/packages Enter. A blank black page with footer "Please help us improve the search ..." appears.
A few seconds later the footer disappears.

Can't reproduce with that on Linux w/ FF 125. Dark mode may be a common denominator, though.

Same behavior with light auto or dark mode.
Safari displays blank screen from "https://search.nixos.org/packages/" but recovers as expected with "https://search.nixos.org/packages".
It seems odd that a trailing slash would cause a blank display. That is true in Safari as well, but in Safari the page display recovers when the trailing slash is removed.

The trailing slash issue isn't too hard, i don't think: The returned html asks for the relative path "bundle.js". If the user agent is on "https://search.nixos.org/packages", that becomes "https://search.nixos.org/bundle.js". Contrarily, if the trailing slash is given, the request for "https://search.nixos.org/packages/bundle.js" 404's. I'd expect the trailing slash version of the URL ("/packages/") to 404 in the first place, but maybe that's just a quirk of the hosting service... Strange how this may contribute to the issue.

authors: atalii gihrig hraban ugur-a

repo: NixOS/nixos-search


text:
Plasma on wayland apps doesn't work properly

Describe the bug
A clear and concise description of what the bug is.

plasmashell tasklist widget doesn't show anything
yakuake can't position itself correctly
spectacle can't take screenshots
some others apps (which takes screenshots, injects input, looks at active window list) are broken too

To Reproduce
Steps to reproduce the behavior:

Run nixos on master with those patches applied: #107472 #107476 (required for startplasma-wayland to work)
Start plasma with

export QT_LOGGING_RULES="kwin_*.debug=true" # For logging, doesn't required for reproduction
dbus-run-session startplasma-wayland

See some apps doesn't work correctly

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.
There are error lines in logs:
KWIN_UTILS: Could not find the desktop file for "/nix/store/v24qakxc15pnj60i7ydqzsd9svdjdjp6-plasma-workspace-5.20.4/bin/.plasmashell-wrapped"
KWIN_UTILS: Could not find the desktop file for "/nix/store/0kbrkb257806lgx5q46gw59scgd2vhqm-yakuake/bin/.yakuake-wrapped"
KWIN_UTILS: Could not find the desktop file for "/nix/store/rabb2qzn14fvq4ksvd063fwcj6d9hwq8-spectacle/bin/.spectacle-wrapped"

But spectacle and yakuake DO have .desktop files, probally it can't be found because of wrappers?
.desktop files are required, because kwin enforces security by using them, i.e for seeing active windows
X-KDE-Wayland-Interfaces=org_kde_plasma_window_management

should be present in .desktop file
Notify maintainers

@worldofpeace @ttuegel
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute:
  - plasma5.plasma-workspace
  - yakuake
  - spectacle
  - kdeFrameworks.krunner
# a list of nixos modules affected by the problem
module:

Workaround for permissions issue: https://gist.github.com/CertainLach/93196d19b5f2f13ffc829a53d75e2b2c
Warning: after adding this patch to kwin, security features of wayland will be disabled, so this workaround shouldn't be included in NixOS

Workaround for permissions issue: https://gist.github.com/CertainLach/93196d19b5f2f13ffc829a53d75e2b2c
Warning: after adding this patch to kwin, security features of wayland will be disabled, so this workaround shouldn't be included in NixOS

Is this still the case with latest unstable?

I suspect this should have been solved with this patch.

Fixed by https://github.com/NixOS/nixpkgs/commit/1ba208004689ecc15872b974dab1124916760be9

authors: CertainLach peterhoeg samueldr

repo: NixOS/nixpkgs


text:
kernelPatches - patches don't apply? "diff: no such file or directory"

Describe the bug
{ pkgs, lib, config, ...}:
{
    config = {
      # ...
      boot.kernelPackages = lib.mkForce pkgs.linuxPackages_latest;
      boot.kernelPatches = [{
        name = "pinebook-disable-dp";

        # https://patchwork.kernel.org/project/linux-rockchip/patch/20200924063042.41545-1-jhp@endlessos.org/
        patch = ''
          diff --git a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts b/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
          index 06d48338c836..d624c595c533 100644
          --- a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
          +++ b/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
          @@ -380,7 +380,7 @@  mains_charger: dc-charger {
          };

          &cdn_dp {
          -	status = "okay";
          +	status = "disabled";
          };

          &cpu_b0 {
        '';
      }];
    };
}

results in:
linux-config> patching script interpreter paths in scripts/ld-version.sh
linux-config> scripts/ld-version.sh: interpreter directive changed from "#!/usr/bin/awk -f" to "/nix/store/lr892zp6955x0ggk5z17ccl0wi7
96r9b-gawk-5.1.0/bin/awk -f"
linux-config> applying patch /nix/store/mnlqwys9dxznjcvq4w3s0435s9ql8qv8-bridge-stp-helper.patch
linux-config> patching file net/bridge/br_private.h
linux-config> Hunk #1 succeeded at 46 with fuzz 2 (offset 7 lines).
linux-config> applying patch /nix/store/mbz5gln1q4swlzmqs2399br98qjif9kn-request-key-helper.patch
linux-config> patching file security/keys/request_key.c
linux-config> applying patch diff
linux-config> /nix/store/7prnyvk0p8i298b7171bkbdr1kj192kn-stdenv-linux/setup: line 960: diff: No such file or directory
error: --- Error --- nix-daemon
builder for '/nix/store/3mfwpy1kmywhb04kkz87mnqmfi9kilb2-linux-config-5.11.2.drv' failed with exit code 1; last 10 log lines:
  stripping FHS paths in `./sound/Makefile'...
  patching script interpreter paths in scripts/ld-version.sh
  scripts/ld-version.sh: interpreter directive changed from "#!/usr/bin/awk -f" to "/nix/store/lr892zp6955x0ggk5z17ccl0wi796r9b-gawk-5
.1.0/bin/awk -f"
  applying patch /nix/store/mnlqwys9dxznjcvq4w3s0435s9ql8qv8-bridge-stp-helper.patch
  patching file net/bridge/br_private.h
  Hunk #1 succeeded at 46 with fuzz 2 (offset 7 lines).
  applying patch /nix/store/mbz5gln1q4swlzmqs2399br98qjif9kn-request-key-helper.patch
  patching file security/keys/request_key.c
  applying patch diff
  /nix/store/7prnyvk0p8i298b7171bkbdr1kj192kn-stdenv-linux/setup: line 960: diff: No such file or director

To Reproduce
Steps to reproduce the behavior:

Try to specify a patch in boot.kernelPatches

Expected behavior
It works.
This is on nixos-unstable-small: e061350a361df9667490c5914fb72a58dd927bca but I see IRC logs of people hitting this in 2019 and 2020.

It's meant to be a path to a patch, not the patch contents....


text:
setting xorg keyboard layout doesn't work anymore with linux latest kernel 5.12

Describe the bug
Alright so this one is a bit weird. I just bisected the issue in my personal configuration to this commit, so I'm pretty sure it's indeed some kernel behavior that's changed in between the 5.10 LTS and 5.12 (the commit switches my configuration to 5.12).
Basically setting services.xserver.layout doesn't take effect anymore. Typing setxkbmap -query or setxkbmap -print does show the layout I've picked, but it's evident when typing that my current keyboard is still in default QWERTY US layout.
Honestly I don't think this is a NixOS bug, just a weird interaction between more recent kernels and the Xorg device layout settings, but I had no idea of where to complain about this other than here.
I'm guessing the problem has to do with the keyboard being loaded as a device later, after the layout configuration has already been set; I've often had problems with keyboards that were just plugged in and defaulted to the qwerty us layout even though all other keyboards on the machine were set to another layout.
Any clue on how I might bisect the Linux kernel to the exact commit that changed this behavior on my NixOS config?
To Reproduce
Steps to reproduce the behavior:

set boot.kernelPackages = pkgs.linuxPackages_latest;
reboot
use your keyboard, it defaults to QWERTY US even with services.xserver.layout = "fr"; set for example
typing setxkbmap -query does show the correct layout selected though:rules:      evdev
model:      pc104
layout:     fr
options:    terminate:ctrl_alt_bksp

Expected behavior
The keyboard uses the selected layout
Additional context
I'm using sddm and i3wm, though I could also reproduce the problem with the default gdm.
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
 - system: `"x86_64-linux"`
 - host os: `Linux 5.12.4, NixOS, 21.05.20210604.aa57635 (Okapi)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.4pre20210601_5985b8b`
 - channels(root): `"nixos-21.05beta555.d25ea6a0d2a"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Testing on pkgs.linuxPackages_5_11: can't reproduce, so the problem appeared somewhere in 5.12.
I'm suspecting this is also related to the keyboard I'm using, a Keyboardio.
Indeed, here's the output of xinput list on 5.10 and 5.11:
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ Keyboardio Model 01                     	id=8	[slave  pointer  (2)]
⎜   ↳ Keyboardio Model 01 Consumer Control    	id=11	[slave  pointer  (2)]
⎜   ↳ Keyboardio Model 01 Mouse               	id=12	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ Power Button                            	id=6	[slave  keyboard (3)]
    ↳ Power Button                            	id=7	[slave  keyboard (3)]
    ↳ Keyboardio Model 01 System Control      	id=9	[slave  keyboard (3)]
    ↳ Keyboardio Model 01 Keyboard            	id=10	[slave  keyboard (3)]
    ↳ Keyboardio Model 01                     	id=13	[slave  keyboard (3)]
    ↳ ASRock LED Controller                   	id=14	[slave  keyboard (3)]

And on 5.12:
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ Keyboardio Model 01                     	id=8	[slave  pointer  (2)]
⎜   ↳ Keyboardio Model 01 Keyboard            	id=10	[slave  pointer  (2)]
⎜   ↳ Keyboardio Model 01 Mouse               	id=11	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ Power Button                            	id=6	[slave  keyboard (3)]
    ↳ Power Button                            	id=7	[slave  keyboard (3)]
    ↳ Keyboardio Model 01 System Control      	id=9	[slave  keyboard (3)]
    ↳ Keyboardio Model 01                     	id=12	[slave  keyboard (3)]
    ↳ ASRock LED Controller                   	id=13	[slave  keyboard (3)]

Notice how the Keyboardio Model 01 Consumer Control line disappears, and the Keyboardio Model 01 Keyboard line moves from Virtual core keyboard to Virtual core pointer.

So this issue definitely doesn't have anything to do with NixOS, except that it allowed me to bisect the root cause efficiently :D. Feel free to close if needed.
If anyone has tips on how to bisect individual kernel commits on my flakes setup, I'm all ears!

I seem to have the same issue #151462

authors: MikulasVanousek alarsyo


text:
Packaging request: osp-tracker

Project description
Tracker is a video analysis and modeling tool built on the Open Source Physics (OSP) Java framework. It analyses the motion of objects inside a video and extract the mechanical variables such as position, orientation, etc..
It would be useful for students doing mechanical experiments.
For the (missing) build instructions, see https://github.com/OpenSourcePhysics/tracker/issues/23
There's an AUR package:
https://aur.archlinux.org/packages/osp-tracker/
Metadata

homepage URL: https://tracker.physlets.org/
source URL: https://github.com/OpenSourcePhysics/tracker https://github.com/fschuett/osptracker-build
license: gpl3
platforms: unix, windows

It would still be great to package it.


text:
Update kanidm to v1.1.0-alpha.9

Checklist

[x] Checked the nixpkgs master branch

[x] Checked the nixpkgs pull requests

Project name
nix search name: kanidm

current version: v1.1.0-alpha.8
desired version: v1.1.0-alpha.9
Notify maintainers

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

Closed through https://github.com/NixOS/nixpkgs/pull/189847

authors: erictapen mweinelt


text:
Package request: vscode-with-profile

Project description
Declaratively manage a VSCode instance's profile
The problem

When opening up multiple instances of VSCode, each with their own extension overrides using vscode-with-extensions, only the extensions found for the first instance are persisted and all the other instances use those instead of overriding their own. This is likely due to vscode-with-extensions using a common extensions path here:

https://github.com/NixOS/nixpkgs/blob/5e4c2ada4fcd54b99d56d7bd62f384511a7e2593/pkgs/applications/editors/vscode/with-extensions.nix#L60-L62

There is no declarative way of defining custom settings for VSCode (I can use .vscode/settings.json within each folder, but that's not ideal)
The same goes for snippets.

This would better fit as a NixOS module rather than a package (so would vscode-with-extensions IMO). Closing.


text:
Build failure: thefuck 3.32

Steps To Reproduce
Steps to reproduce the behavior:

use nixpkgs-unstable
build thefuck

Build log
https://gist.github.com/isabelroses/ae50c2cd2bfc469c35efce193b541604
Additional context
Notify maintainers
@marcusramberg
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
- system: `"x86_64-linux"`
 - host os: `Linux 6.9.7, NixOS, 24.11 (Vicuna), 24.11.20240703.9f4128e`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Lix, like Nix) 2.91.0-devpre20240707_d461cc1
System type: x86_64-linux
Additional system types:
Features: gc, signed-caches
System configuration file: /etc/nix/nix.conf
User configuration files: /home/isabel/.config/nix/nix.conf:/etc/xdg/nix/nix.conf:/home/isabel/.local/share/flatpak/exports/etc/xdg/nix/nix.conf:/var/lib/flatpak/exports/etc/xdg/nix/nix.conf:/home/isabel/.nix-profile/etc/xdg/nix/nix.conf:/nix/profile/etc/xdg/nix/nix.conf:/home/isabel/.local/state/nix/profile/etc/xdg/nix/nix.conf:/etc/profiles/per-user/isabel/etc/xdg/nix/nix.conf:/nix/var/nix/profiles/default/etc/xdg/nix/nix.conf:/run/current-system/sw/etc/xdg/nix/nix.conf
Store directory: /nix/store
State directory: /nix/var/nix
Data directory: /nix/store/2s37fjh67f3p4k2ga5cmn1mi173z2lld-lix-2.91.0-devpre20240707_d461cc1/share`
 - nixpkgs: `/nix/store/dk2rpyb6ndvfbf19bkb2plcz5y3k8i5v-source`

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

Seems fixable by moving to an unstable rev https://github.com/nvbn/thefuck/commit/0420442e778dd7bc53bdbdb50278eea2c207dc74

Also related https://github.com/nvbn/thefuck/issues/1444.

Same behavior here on MacOS using home-manager.

I'm currently on vacation, so a bit limited time.  I guess our options are either pinning it to python11 until there's a release, moving to unstable or adding that commit as a patch.

This happened due to recent shift to Python 3.12 in Nixpkgs.

Seems fixable by moving to an unstable rev nvbn/thefuck@0420442

Mind backporting it then?

authors: JohnRTitor isabelroses marcusramberg mayersj1


text:
Update request: cling 1.0 → 1.1

Package name: cling
Latest released version: 1.1

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

[x] Checked the nixpkgs pull requests

Notify maintainers
@thomasjm

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

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

need to fix some paths
./result/bin/cling
#include <stdio.h>
In file included from input_line_3:1:
/nix/store/wlavaybjbzgllhq11lib6qgr7rm8imgp-glibc-2.39-52-dev/include/stdio.h:34:10: fatal error: 'stddef.h' file not found
#include <stddef.h>
         ^~~~~~~~~~

./result/bin/cling -isystem /nix/store/x8rg4vhgd20i8vzykm1196f9qdb8klhh-gcc-13.3.0/lib/gcc/x86_64-unknown-linux-gnu/
13.3.0/include/

****************** CLING ******************
* Type C++ code and press enter to run it *
*             Type .q to exit             *
*******************************************
[cling]$ ERROR in cling::CIFactory::createCI():
  resource directory /nix/lib/clang/16 not found!
^C
[cling]$ #include <stdio.h>
[cling]$ printf("1")
1(int) 1
[cling]$

{ cmake
, fetchFromGitHub
, git
, lib
, libffi
, llvmPackages_16
, makeWrapper
, ncurses
, python3
, zlib
, breakpointHook
# *NOT* from LLVM 9!
# The compiler used to compile Cling may affect the runtime include and lib
# directories it expects to be run with. Cling builds against (a fork of) Clang,
# so we prefer to use Clang as the compiler as well for consistency.
# It would be cleanest to use LLVM 9's clang, but it errors. So, we use a later
# version of Clang to compile, but we check out the Cling fork of Clang 9 to
# build Cling against.
, clangStdenv

# For runtime C++ standard library
, gcc-unwrapped

# Build with debug symbols
, debug ? false

# Build with libc++ (LLVM) rather than stdlibc++ (GCC).
# This is experimental and not all features work.
, useLLVMLibcxx ? clangStdenv.hostPlatform.isDarwin
}:

let
  stdenv = clangStdenv;

  # The patched clang lives in the LLVM megarepo
  clangSrc = fetchFromGitHub {
    owner = "root-project";
    repo = "llvm-project";
    # cling-llvm16 branch
    rev = "9291db05e95225a5576c014128a4cb15487fb95f";
    sha256 = "sha256-ltavDYeuD0BXQ1RTVfYE3mqvizdP/vWpkCNtg6dqA3E=";
    sparseCheckout = ["clang" "cmake"];
  };

  unwrapped = stdenv.mkDerivation rec {
    pname = "cling-unwrapped";
    version = "1.1";

    src = "${clangSrc}";

    clingSrc = fetchFromGitHub {
      owner = "root-project";
      repo = "cling";
      rev = "refs/tags/v${version}";
      sha256 = "sha256-MBkHU4B1qPTmfLjBh0Kvt58A+3s9TfcknHXteyVe8I0=";
    };

    prePatch = ''
      echo "add_llvm_external_project(cling)" >> clang/tools/CMakeLists.txt

      cp -r $clingSrc clang/tools/cling
      chmod -R a+w clang/tools/cling

    '';
    preConfigure = ''
      #FIXME
      cd clang
    '';

    patches = [
       ./no-clang-cpp.patch
    ];

    nativeBuildInputs = [ python3 git cmake breakpointHook ];
    buildInputs = [ libffi ncurses zlib];

    strictDeps = true;

    cmakeFlags = [
      "-DLLVM_DIR=${llvmPackages_16.llvm.dev}/lib/cmake/llvm" #FIXME
      "-DLLVM_BINARY_DIR=${llvmPackages_16.llvm.out}"
      "-DLLVM_CONFIG=${llvmPackages_16.llvm.dev}/bin/llvm-config"
      "-DLLVM_LIBRARY_DIR=${llvmPackages_16.llvm.lib}/lib"
      "-DLLVM_MAIN_INCLUDE_DIR=${llvmPackages_16.llvm.dev}/include"
      "-DLLVM_TABLEGEN_EXE=${llvmPackages_16.llvm.out}/bin/llvm-tblgen"
      "-DLLVM_TOOLS_BINARY_DIR=${llvmPackages_16.llvm.out}/bin"
      "-DLLVM_BUILD_TOOLS=Off"
      "-DLLVM_TOOL_CLING_BUILD=ON"

      "-DLLVM_TARGETS_TO_BUILD=host;NVPTX"
      "-DLLVM_ENABLE_RTTI=ON"

      # Setting -DCLING_INCLUDE_TESTS=ON causes the cling/tools targets to be built;
      # see cling/tools/CMakeLists.txt
      "-DCLING_INCLUDE_TESTS=ON"
      "-DCLANG-TOOLS=OFF"
    ] ++ lib.optionals debug [
      "-DCMAKE_BUILD_TYPE=Debug"
    ] ++ lib.optionals useLLVMLibcxx [
      "-DLLVM_ENABLE_LIBCXX=ON"
      "-DLLVM_ENABLE_LIBCXXABI=ON"
    ];

    CPPFLAGS = if useLLVMLibcxx then [ "-stdlib=libc++" ] else [];

    postInstall = lib.optionalString (!stdenv.hostPlatform.isDarwin) ''
      mkdir -p $out/share/Jupyter
      #cp -r /build/clang/tools/cling/tools/Jupyter/kernel $out/share/Jupyter
    '';

    dontStrip = debug;

    meta = with lib; {
      description = "Interactive C++ Interpreter";
      mainProgram = "cling";
      homepage = "https://root.cern/cling/";
      license = with licenses; [ lgpl21 ncsa ];
      maintainers = with maintainers; [ thomasjm ];
      platforms = platforms.unix;
    };
  };

  # Runtime flags for the C++ standard library
  cxxFlags = if useLLVMLibcxx then [
    "-I" "${lib.getDev llvmPackages_16.libcxx}/include/c++/v1"
    "-L" "${llvmPackages_16.libcxx}/lib"
    "-l" "${llvmPackages_16.libcxx}/lib/libc++${stdenv.hostPlatform.extensions.sharedLibrary}"
  ] else [
    "-I" "${gcc-unwrapped}/include/c++/${gcc-unwrapped.version}"
    "-I" "${gcc-unwrapped}/include/c++/${gcc-unwrapped.version}/${stdenv.hostPlatform.config}"
  ];

  # The flags passed to the wrapped cling should
  # a) prevent it from searching for system include files and libs, and
  # b) provide it with the include files and libs it needs (C and C++ standard library plus
  # its own stuff)

  # These are also exposed as cling.flags because it's handy to be able to pass them to tools
  # that wrap Cling, particularly Jupyter kernels such as xeus-cling and the built-in
  # jupyter-cling-kernel, which use Cling as a library.
  # Thus, if you're packaging a Jupyter kernel, you either need to pass these flags as extra
  # args to xcpp (for xeus-cling) or put them in the environment variable CLING_OPTS
  # (for jupyter-cling-kernel).
  flags = [
    "-nostdinc"
    "-nostdinc++"

    "-resource-dir" "${llvmPackages_16.llvm.lib}/lib"

    "-isystem" "${lib.getLib unwrapped}/lib/clang/${llvmPackages_16.clang.version}/include"
  ]
  ++ cxxFlags
  ++ [
    # System libc
    "-isystem" "${lib.getDev stdenv.cc.libc}/include"

    # cling includes
    "-isystem" "${lib.getDev unwrapped}/include"
  ];

in

stdenv.mkDerivation {
  pname = "cling";
  version = unwrapped.version;

  nativeBuildInputs = [ makeWrapper breakpointHook ];
  inherit unwrapped flags;
  inherit (unwrapped) meta;

  dontUnpack = true;
  dontConfigure = true;

  buildPhase = ''
    runHook preBuild

    makeWrapper $unwrapped/bin/cling $out/bin/cling \
      --add-flags "$flags"

    runHook postBuild
  '';

  doCheck = false;
  checkPhase = ''
    runHook preCheck

    output=$($out/bin/cling <<EOF
    #include <iostream>
    std::cout << "hello world" << std::endl
    EOF
    )

    echo "$output" | grep -q "Type C++ code and press enter to run it"
    echo "$output" | grep -q "hello world"

    runHook postCheck
  '';

  dontInstall = true;
}

master...qwqawawow:nixpkgs:update-cling I made a small commit.

Any reason you used LLVM 18 @qwqawawow? Considering taking this on (and maybe adding myself as maintainer) and saw that the new Cling 1.1 version is using LLVM 16.

master...qwqawawow:nixpkgs:update-cling I made a small commit.

Any reason you used LLVM 18 @qwqawawow? Considering taking this on (and maybe adding myself as maintainer) and saw that the new Cling 1.1 version is using LLVM 16.

@hexadecimalDinosaur  Thank you very much
Because I'm not very familiar with CMake and LLVM,
I casually tested version 18.
You can contribute freely because I'm not familiar with this area. I seem to have done it in a not very elegant or standard way.
I hope I haven't misled you.

Because I'm not very familiar with CMake and LLVM,
I casually tested version 18.
You can contribute freely because I'm not familiar with this area. I seem to have done it in a not very elegant or standard way.
I hope I haven't misled you.

@qwqawawow just was wondering why to see if you had any reason that I should consider when writing an update. Will take a look at updating this later

Hi all -- my general plan is to fix https://github.com/NixOS/nixpkgs/issues/306782 and then address this. Just put up PR #351130 for that.

authors: Kamillaova hexadecimalDinosaur qwqawawow thomasjm


text:
Package request: package-version-server

Project description
https://github.com/zed-industries/package-version-server
package-version-server needs to be stubbed in order to work for zed. zed shows an error whenever you open certain files due to missing a nixpkg version of the language server. i'm unsure if this needs to be part of the zed package but i'd guess it would be.
Language server error: package-version-server

oneshot canceled
-- stderr--
Could not start dynamically linked executable: /home/user/.local/share/zed/languages/package-version-server/package-version-server-v0.0.7
NixOS cannot run dynamically linked executables intended for generic
linux environments out of the box. For more information, see:
https://nix.dev/permalink/stub-ld

Metadata

homepage URL:
source URL: https://github.com/zed-industries/package-version-server
license: mit
platforms: unix, linux, darwin, ...

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

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

#356100 a pr is already in the works


text:
Bazel can't find ar

Issue description
Bazel builds are failing for me with the latest version (0.11.1) installed from nixpkgs HEAD. I also had the same issue with 0.10.1
Steps to reproduce
git clone git@github.com:tweag/rules_haskell_examples.git
cd rules_haskell_examples
bazel build //vector
...
ERROR: /home/ben/dev/haskell/rules_haskell_examples/vector/BUILD:12:1: SkylarkAction vector/libHSvector-1.0.0.a failed (Exit 1)
src/main/tools/process-wrapper-legacy.cc:58: "execvp(/usr/bin/ar, ...)": No such file or directory
Target //vector:vector failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 11.966s, Critical Path: 9.34s
FAILED: Build did NOT complete successfully

Technical details
Please run nix-shell -p nix-info --run "nix-info -m" and paste the
results.
⇒  nix-shell -p nix-info --run "nix-info -m"
these paths will be fetched (0.00 MiB download, 0.00 MiB unpacked):
  /nix/store/nhfgv0xxi9shl5lvl9jaf11vmm9zkv42-nix-info
fetching path ‘/nix/store/nhfgv0xxi9shl5lvl9jaf11vmm9zkv42-nix-info’...

*** Downloading ‘http://cache.nixos.org/nar/0m0hkzniw91kgh4vciarl0332phi8hzljw8n91548hkmghm1b305.nar.xz’ (signed by ‘cache.nixos.org-1’) to ‘/nix/store/nhfgv0xxi9shl5lvl9jaf11vmm9zkv42-nix-info’...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1640  100  1640    0     0  11970      0 --:--:-- --:--:-- --:--:-- 11970

 - system: `"x86_64-linux"`
 - host os: `Linux 4.9.86, NixOS, 17.09.3204.d16ffa15090 (Hummingbird)`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 1.11.8`
 - channels(ben): `""`
 - channels(root): `"nixos-17.09.3204.d16ffa15090"`
 - nixpkgs: `/home/ben/dev/nixpkgs`

nixpkgs is at 9049f8a418b1d29f8066baec681684677fce28c7
See also https://github.com/tweag/rules_haskell/issues/203

This one needs a patch:
src/main/tools/process-wrapper-legacy.cc

You can replace it with $AR that is available in stdenv by using substituteInPlace:
$ nix-shell -p hello --command 'echo $AR'
bash: /run/user/1000/env-vars: cannot overwrite existing file
ar

Ok. the file does not contain this.
Maybe it is decided here somewhere:
https://github.com/bazelbuild/bazel/blob/832a0b193a9a098897781bc6298d0455b3913482/tools/cpp/unix_cc_configure.bzl#L103

This starts working again on a system that has have nix-env -i binutils run...

Probably needs to be in path of bazel then.

@boothead Have you tried adding it to makeBinPath in installPhase?

@abbradar I tried this with this commit: https://github.com/boothead/nixpkgs/commit/a791221178c0b1f7c076da234c193d2de93fda9d It doesn't seem to have made a difference.

@boothead Hm, strange -- exactly this should work in principle. I'll give a better look later; not sure what happens.

Looks like patching scripts that generate scripts helps https://github.com/amckague/nixpkgs/commit/0326835055a5b4e2d2a1074e51e32b0d58136783#diff-4746b81564a01e241a84d455575437e7R89 I'm new to making this kind of change so any suggestions are welcome.

Related https://github.com/NixOS/nixpkgs/issues/24063

Pretty sure I found the root cause of this problem! Turns out bazel provides default locations to standard tools that some bazel rules use. The file I linked is actually auto-generated, which made debugging very confusing. I initially patched that file, without noticing that the build process would just override it with the old one. No idea why they check in the generated file.
Anyway, the tool location is ultimately determined by this function which just uses which to discover the tool locations. So all that is needed is to add bintools to the buildInputs of bazel.
I'll solve this as part of https://github.com/NixOS/nixpkgs/pull/63616.

I was a bit too quick, I'm still not able to properly fix the issue.

Since we are now at bazel 1.1, is this issue fixed?

I am still encountering this issue with Bazel v5.4.0. Adding bintools or binutils to buildInputs or defaultShellUtils did not help. I think this issue needs to be re-opened.

authors: Mic92 Profpatsch abbradar amckague boothead camtauxe commandodev timokau


text:
Optcomp (and probably other camlp4 users) does not compile with ocaml 4.02

At least the package ocamlPackages.ocaml_optcomp does not compile with ocaml 4.02 . This is due to its build system searching for "-I +camlp4/Camlp4Parsers" ie, camlp4 within the compiler's directory. I'm not sure where in the buildsystem stack it gets generated (optcomp itself, oasis, ocamlbuild, …) and I suspect other packages are affected.

Can be closed @jagajaga

authors: FlorentBecker Profpatsch


text:
Plex can't utilize hardware acceleration

Issue description
While I have hardware that supports video processing acceleration, plex can't access it.
Steps to reproduce

Have hardware that supports video acceleration ("Using Hardware-Accelerated Streaming--1. Check the system requirements")
Try to enable "Use hardware acceleration when available" in Plex settings ("Using Hardware-Accelerated Streaming--2. Enable hardware acceleration")

Technical details
these paths will be fetched (0.05 MiB download, 0.28 MiB unpacked):
  /nix/store/zqabb6j60agkcqp5izyqm12gl5k7spcf-bash-interactive-4.4-p23-dev
copying path '/nix/store/zqabb6j60agkcqp5izyqm12gl5k7spcf-bash-interactive-4.4-p23-dev' from 'https://cache.nixos.org'...
 - system: `"x86_64-linux"`
 - host os: `Linux 4.19.56, NixOS, 19.09.git.cc83a0d (Loris)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.2.2`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

The solution to this issue may be the same as adding hardware acceleration to dockerized Plex, possibly just linking /dev/ to the userenv, if that's possible.

Can you give some more information about your setup. What kind of hardward do you have? GPU or Intel QuickSync CPU, etc.?
I remember that I had both working Nvidia GPU and Intel QuickSync. I can confirm that quick sync is still working as I use it daily. I don't use a GPU anymore so I can't check.

My CPU is an i7-3615QM (according to /proc/cpuinfo) which has QuickSync and the /dev/dri device is available from a shell, which from my understanding is used by Plex to access QuickSync. I don't have a dedicated GPU.

It's unfortunately quite easy to confuse graphics acceleration with video (decoding/encoding) acceleration…
Video acceleration is enabled by the VDPAU API, which is configured on NixOS using the hardware.opengl.extraPackages (bit of a misnomer) option. Try setting yours to the example provided and see if that helps.

Also not seeing hardware acceleration using plex. I'm using the configuration below
hardware.opengl = {     driSupport32Bit = true;     extraPackages = with pkgs; [ vaapiIntel libvdpau-va-gl vaapiVdpau intel-ocl ];     extraPackages32 = with pkgs.pkgsi686Linux; [ libva vaapiIntel libvdpau-va-gl vaapiVdpau ];   };   services.plex = {     enable = true;     openFirewall = true;   };
I have a 970gtx which should be capable of NVENC

I think this should be closed, either I misremembered, or Plex's policy changed, but the free version of Plex does not support hardware acceleration.

I have the same problem. I believe hardware acceleration is present in the free version and the problem is due to the lack of VA-API drivers built with Plex libc.

authors: apvodney bachp ilya-fedin lheckemann onajimaru tabitha-vi


text:
TIFF security vulnerabilities

Red Hat bugs all have patches available, hopefully against the same version: CVE-2014-8127, CVE-2014-8128, CVE-2014-8129, CVE-2014-9330 CVE-2014-9655.
It looks like the current expression is set up to fetch patches from the Arch Linux SVN repository. I don't know whether these patches are available three yet.

There's an update in staging f40c885a34c that claims to fix the problems (in upstream changelog), except for 9330 and 9655 which aren't mentioned.

According to linked red-hat info, 9330 has a low impact and 9655 was fixed in that 4.0.4beta version, so the staging version should be fairly secure.

This should be fixed on master and 15.09 for a long time.

authors: falsifian vcunat


text:
Package Photoprism

Project description
PhotoPrism is a server-based application for browsing, organizing and sharing your personal photo collection.
Metadata

homepage URL: https://photoprism.org/
source URL: https://github.com/photoprism/photoprism
license: agpl3
platforms: linux, darwin, windows

I've started a PR at https://github.com/NixOS/nixpkgs/pull/99016. It's basically working, but I would love to have some feedback on some unresolved questions.

There's also https://github.com/andir/infra/tree/master/nix/packages/photoprism

Welp. Didn't see that :/

Still important. @Sohalt any news on the PR?

@mbrgm I'm still waiting on feedback on https://github.com/NixOS/nixpkgs/pull/99016#discussion_r531681435 and I think it would be cleaner to use npmlock2nix instead of node2nix, but I didn't find the time to get that working.

I have this packaged at the 2022-01-21 release based on all the prior work:

package
module

I will pull-request that in a few months if I end up using photoprism long term.
If someone wants to maintain photoprism before then feel free to take over.

I was hoping to run it on my Pi, so here's a package that supports both aarch64 and x86_64 (using photoprism's prebuilt tensorflow .so's): https://github.com/Misterio77/nix-config/tree/c6c37ec16711b6a717587d02c3eb0627aa388c70/pkgs/photoprism

i would be very happy to get this package included in 22.05. Maybe @newAM you could open a PR?

I have not been using photoprism much unfortunately, I am not sure when I will get back to it.

I've been using photoprism daily, thus am interested in upstreaming and maintaining it, if that would be okay :)

Take whatever you need from what I have written!

@Misterio77 opened a PR here: https://github.com/NixOS/nixpkgs/pull/170953
(Mentions do not generate notifications; people subscribed to this issue probably want to review the PR)

Following this with great interest, let me know if I can help!

@Misterio77 Unfortunately the latest commit has rendered the PR unbuildable for me.
I branched of your PR, fixed the issues introduced by the commit, updated to the photoprism version that has been released 2 days ago (221102-905925b4d ) and rebased the PR on a more recent  rev of master (was needed  anyway since the new photoprism version required go 1.19). I also implemented a couple of suggestions by @dotlambda left over in the PR.
https://github.com/NixOS/nixpkgs/compare/master...BeneSim:nixpkgs:photoprism
I'd be willing to take over the PR, you mentioned that you didn't end up using photprism as much. Would be my first contribution to nixpkgs, but I'm interested and willing to contribute ;)
Let me know if that would be okay for you.
Until then, anybody who wants to use  photoprism today with nixpkgs might want to have a look at my branch https://github.com/BeneSim/nixpkgs/tree/photoprism .

@BeneSim, thanks! Sure thing, open up a PR and I'll close mine linking to yours.

authors: BeneSim Misterio77 Sohalt Stunkymonkey ajs124 danielfullmer mbrgm newAM skogsbrus


text:
using mesa iris I get the error "kernel to old"

Describe the bug
I configured my system according to:
https://nixos.wiki/wiki/Intel_Graphics
to use iris.
After a rebuild + reboot I try to start sway.
I get the error message, that my kernel is too old and I should use at least kernel 4.16. I am running 5.7/5.8-zen.
To Reproduce
Steps to reproduce the behavior:

Update system configuration according to https://nixos.wiki/wiki/Intel_Graphics
Rebuild
Reboot
Start sway

Expected behavior
Sway starts or other error messages.
Additional context
This all happened in a try to resolve https://github.com/swaywm/sway/issues/5642 and could be related to #65017
Notify maintainers
@colemickens
@vcunat
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
Will update later.

I configured my system according to:
https://nixos.wiki/wiki/Intel_Graphics
to use iris.

Are you on 20.03? The config changes are only required for 20.03. I've gone ahead and removed that part from the wiki as 20.09 will be released "soon".

I get the error message, that my kernel is too old and I should use at least kernel 4.16. I am running 5.7/5.8-zen.

That error message is missing in your report. It would be helpful to know the exact message.

I am running unstable.
Should I try to retrieve the error message then?
How do I see if I am using iris?
In lsmod I just see the i915 driver
i915                 2494464  24
cec                    49152  1 i915
drm_kms_helper        188416  2 i915,nouveau
drm                   503808  15 drm_kms_helper,i915,ttm,nouveau
intel_gtt              24576  1 i915
i2c_algo_bit           16384  2 i915,nouveau
i2c_core               77824  10 i2c_designware_platform,videodev,i2c_hid,i2c_designware_core,drm_kms_helper,i2c_algo_bit,i2c_i801,i915,nouveau,drm
video                  49152  3 asus_wmi,i915,nouveau
backlight              20480  5 video,asus_wmi,i915,nouveau,drm

I am running unstable.

Then you should remove the config changes from the wiki.

Should I try to retrieve the error message then?

Of course. Without an exact string I don't even know where the message comes from.

How do I see if I am using iris?

i915 is the kernel driver/module. The Mesa user-space driver is more difficult to determine (LIBGL_DEBUG=verbose, strace, etc. - there should be enough online guides).


text:
python3Packages.pdfminer: 20200726 -> 20201018

Motivation for this change
https://github.com/pdfminer/pdfminer.six/releases/tag/20201018
Things done

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

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

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

@GrahamcOfBorg build python3Packages.pdfminer


text:
nixosTests.certmgr: fix systemd test

Motivation for this change
The nixosTests.certmgr.systemd test currently fails on master and release-20.09.
The nginx service fails to start, because it can't read the generated certificate file. This happens because PrivateTmp is set for the service, which makes the system wide /tmp inaccessible.
master build: https://hydra.nixos.org/build/128741218
release-20.09 build: https://hydra.nixos.org/build/128677093
ZHF: #97479
Things done

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

[X] NixOS
[ ] macOS
[ ] other Linux distributions

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

@GrahamcOfBorg test certmgr


text:
docs: convert packages/linux docbook -> commonmark

Motivation for this change
Closes #105257, conversion of Docbook Packages for Linux to CommonMark.
@ryantm
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"
[ ] 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
[ ] Fits CONTRIBUTING.md.

Closing in favor of #105752 where the trailing whitespace is fixed.

@ryantm Odd, thanks for handling it!

authors: mmlb ryantm


text:
libnice: 0.1.16 -> 0.1.18

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)

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

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

@GrahamcOfBorg build gst_all_1.gst-plugins-bad farstream


text:
ocamlPackages.mimic: init at 0.0.1

Motivation for this change
New package which is required for git >= 3.0.0, but is versioned independently from git.
https://github.com/mirage/ocaml-git/releases/tag/mimic-v0.0.1
Things done

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

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

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

@GrahamcOfBorg build ocamlPackages.mimic ocaml-ng.ocamlPackages_4_08.mimic

@GrahamcOfBorg build ocamlPackages.mimic ocaml-ng.ocamlPackages_4_08.mimic


text:
libxc: 5.1.0 -> 5.1.2

Motivation for this change
bugfix release https://tddft.org/programs/libxc/changes/
Things done

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

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

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

Result of nixpkgs-review 1

2 packages built:

libxc
octopus

Result of nixpkgs-review pr 113129 at 32a03ff8 run on x86_64-linux 1

2 packages built:

libxc
octopus

1 suggestion:

warning: unnecessary-parallel-building
Meson, CMake and qmake already set enableParallelBuilding = true by default so it is not necessary.
Near pkgs/development/libraries/libxc/default.nix:31:3:
   |
31 |   enableParallelBuilding = true;
   |   ^

authors: markuskowa r-rmcgibbo


text:
haskellPackages.niv: Try to fix build

Motivation for this change
niv is broken on master right now (compare https://github.com/nmattia/niv/issues/312).
I need help on this one! /cc @peti @sternenseemann @cdepillabout
I am trying to fix this by overriding the optparse-applicative version to something older.
This should be total routine and a 5 minute job, but I have now tried for at least 30 minutes, but no matter what I do my override does not have any effect. It always tries to build with optparse-applicative-0.16.1 not with 0.15.1.
What I have tried:

Doing the override (I know it's crazy) in all-packages.nix
Disabling the completion generation.
Disabling the separate bin output (as configured in configuration-nix.nix).
When I replace the self.optparse_applicative_0_15_1_0 with anything that doesn‘t evaluate I get an error. When I replace it with anything that does evaluate it has no effect.

This is either something really stupid from my side or something really tricky in mkDerivation …
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.

Who knows maybe I screwed up building …
@GrahamcOfBorg build niv

For me, it builds optparse-applicative 0.15, but when configuring:
Dependency optparse-applicative -any: using optparse-applicative-0.16.1.0

I can imagine this is an issue with propagation where some dependency of niv propagates the newer optparse-applicative version.

Might be worth trying overrideScope (compilation still running on my machine…):
diff --git a/pkgs/development/haskell-modules/configuration-common.nix b/pkgs/development/haskell-modules/configuration-common.nix
index 7d71b9e77a1..70f38b3e7f9 100644
--- a/pkgs/development/haskell-modules/configuration-common.nix
+++ b/pkgs/development/haskell-modules/configuration-common.nix
@@ -946,9 +946,9 @@ self: super: {

   # Generate shell completion.
   cabal2nix = generateOptparseApplicativeCompletion "cabal2nix" super.cabal2nix;
-  niv = generateOptparseApplicativeCompletion "niv" (super.niv.override ({
-   # Needs override because of: https://github.com/nmattia/niv/issues/312
-   optparse-applicative = super.optparse-applicative_0_15_1_0;
+  niv = generateOptparseApplicativeCompletion "niv" (super.niv.overrideScope (self: super: {
+    # Needs override because of: https://github.com/nmattia/niv/issues/312
+    optparse-applicative = super.optparse-applicative_0_15_1_0;
   }));
   ormolu = generateOptparseApplicativeCompletion "ormolu" super.ormolu;
   stack = generateOptparseApplicativeCompletion "stack" super.stack;

Yeah, that makes sense. It’s just that I have never witnessed a problem like this before. Normally we get the error about incompatible versions it does not silently choose the "wrong" one.

Yeah, that makes sense. It’s just that I have never witnessed a problem like this before. Normally we get the error about incompatible versions it does not silently choose the "wrong" one.

Normally Haskell packages have pretty strict PVP-based upper bounds which leads to the whole mess that we can often unbreak a build by jailbreaking, but niv has no upper bound which in this case lets ./Setup configure choose 0.16 without creating an incompatibility with anything.

Yeah, that makes sense. It’s just that I have never witnessed a problem like this before. Normally we get the error about incompatible versions it does not silently choose the "wrong" one.

Normally Haskell packages have pretty strict PVP-based upper bounds which leads to the whole mess that we can often unbreak a build by jailbreaking, but niv has no upper bound which in this case lets ./Setup configure choose 0.16 without creating an incompatibility with anything.

Aaaaah, that makes so much sense.

@maralorn niv builds successfully with this: https://github.com/sternenseemann/nixpkgs//commit/0eb47060901

Thank you! I had actually tried it with overrideScope, saw how many rebuilds it required and decided "this must be the wrong solution".

You can get it from cachix if you have it to verify https://app.cachix.org/cache/tmp

It would be great if you could wait for ofborg.

@SuperSandro2000 I think waiting for ofborg makes sense in most cases. But ofBorg should enable devs and no be a burden. In this case two people had tested this very small PR. OfBorg had made checks before my final force push.

In this case two people had tested this very small PR.

Please keep in mind that ofborg uses more restricted rules to eval and what locally passes does not always need to pass ofborg.

authors: SuperSandro2000 maralorn sternenseemann


text:
nixos/plasma5: make it run using systemd and wayland

Motivation for this change
With nixos-unstable as of 2021-03-29, in order to activate the "run with systemd mode", you can either:

execute this once as the user:

kwriteconfig5 --file startkderc --group General --key systemdBoot true

or add this to your configuration.nix (when using this PR):

services.xserver.desktopManager.plasma5.runUsingSystemd = true;

If you want to try out wayland, you need to make the wayland session file available to sddm:
The nicer way:
services.xserver.displayManager.sessionPackages = [
  (pkgs.plasma-workspace.overrideAttrs
    (old: { passthru.providedSessions = [ "plasmawayland" ]; }))
];

Alternatively, override the path to the wayland sessions directory for sddm. This will make all other wayland sessions unavailable:
services.xserver.displayManager.sddm.settings.Wayland.SessionDir =
  "${pkgs.plasma5Packages.plasma-workspace}/share/wayland-sessions";

Please note that you probably want to run the session with systemd if you're trying out the wayland variant.
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.

Cc @ttuegel @sameldr @petabyteboy @ajs124

In order to enable systemd:
kwriteconfig5 --file startkderc --group General --key systemdBoot true

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/plasma-and-systemd/12057/1

I'm guessing that @eliasp is probably interested in this too.

Is it not possible to fix the systemd units in the package with substitution? Also, why doesn't the substitution that CMake does on the units not work https://github.com/KDE/plasma-workspace/blob/master/ksmserver/plasma-restoresession.service.in#L8?

https://github.com/NixOS/nixpkgs/pull/117102/commits/807a6cb8ebcc58f87bfb8760fa98d7ff882313c1 LGTM :+1:

Review per https://nixos.org/manual/nixpkgs/stable/#reviewing-contributions-module-updates
Reviewed points

[x] changes are backward compatible

Comments

Tested branch as it currently is, in virtualbox, with xfce installed besides plasma5.

Tested with a fresh user account:

login with plasma5
execute kwriteconfig5 --file startkderc --group General --key systemdBoot true
logout
kill lingering session with loginctl kill-session (I don't know why this is needed), so that a fresh session can be initiated
login with plasma5

Amazingly, plasma5 starts without any visible problems.

The following systemd user service fails to start
  user2@nixosb:~> systemctl --user status plasma-kcminit-phase1.service
  ● plasma-kcminit-phase1.service
       Loaded: loaded (/nix/store/m0dl46l9zb0axlym5cc23qn0aqx8g0ws-unit-plasma-kcminit-phase1.service/plasma-kcminit-phase1.service; linked-runtime; vendor preset: enabled)
       Active: failed (Result: exit-code) since Sun 2021-03-21 19:51:46 CET; 23min ago
      Process: 5844 ExecStart=/nix/store/2ijmr91zlf2rcggx9bp1q4mcdg6zcm4m-qttools-5.15.2-bin/bin/qdbus org.kde.kcminit /kcminit org.kde.KCMInit.runPhase1 (code=exited, status=2)
     Main PID: 5844 (code=exited, status=2)
          CPU: 50ms

  Mar 21 19:51:45 nixosb systemd[4835]: Started plasma-kcminit-phase1.service.
  Mar 21 19:51:45 nixosb qdbus[5844]: Service 'org.kde.kcminit' does not exist.
  Mar 21 19:51:46 nixosb systemd[4835]: plasma-kcminit-phase1.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
  Mar 21 19:51:46 nixosb systemd[4835]: plasma-kcminit-phase1.service: Failed with result 'exit-code'.

Before switching to systemdBoot, this service didn't even try to start.

Is it not possible to fix the systemd units in the package with substitution?

Yes, and as pointed out in the message, I will basically undo that commit when fixing the package properly - it was just to make it easy for people to test out without having to do any (re)compiling.

Also, why doesn't the substitution that CMake does on the units not work https://github.com/KDE/plasma-workspace/blob/master/ksmserver/plasma-restoresession.service.in#L8?

We have qdbus in qttools while the cmake scripts point at qtbase.

* The following systemd user service fails to start

What does systemctl --user status plasma-kcminit say?

I haven't tried without using systemd to manage the session, but with this PR and a single line of config, you can run a KDE wayland session:
services.xserver.displayManager.sddm.settings.Wayland.SessionDir =
  "${pkgs.plasma5Packages.plasma-workspace}/share/wayland-sessions";

I haven't looked at the proper way to add the session file so this is the quick and dirty. But it works.
Couple of things that don't:

the pager is blank
notifications steal focus (which is a pain...)
and of course, I need to find alternatives to xmodmap and xcape

Otherwise it looks pretty solid.

Giving it a spin as I write this. Works fine¹ although a lot of polishing is clearly still needed. Without the kwriteconfig5 command pipewire wasn't working at all, after running that and rebooting pipewire is fine.
I have two monitors in the following arrangement:

a 24" 4K@60 screen on the top left, set to 200% scaling
a 48" 4K@120 screen with 100% scaling, meant to be the main display

Some problems I ran into straight away:

Plasmashell context menus flicker partially in and out of existence as the cursor moves over them (interestingly application context menus are fine), but only on the 2nd ("main") display and sometimes only when passing over an entry that opens a submenu

First I thought this would be caused by the refresh rate mismatch, but after setting both displays to 60Hz the problem still persists

Context menus aren't transparent although they should (System Settings -> Workspace Behavior -> Desktop Effects -> Translucency)

Firefox context menus (running in xwayland apparently) do have this

Context menu positioning is sometimes wonky
Editing the panel is hard since half of the times it loses focus and exits edit mode for no good reason

plasmashell also frequently crashes when attempting this

Panel defaults to the 1st ("secondary") display (but remembers its position after manually dragging it to the main display)

Like do many games from steam. Some are fine with being dragged to the main display and will remember that on the next launch, some aren't (with various degrees of breakage from not remapping cursor positions correctly to locking up input).

Windows don't show up in the task manager in panels -- can't restore minimized windows (except by alt+tabbing, unless whatever handles that has crashed in which case good luck)
Fcitx5 isn't working in wayland-native applications

works in xwayland applications though, and also logs that it loads a wayland module

Flameshot launches but can't take screenshots

¹for some value of "fine"

What does systemctl --user status plasma-kcminit say?

The service started successfully, then stopped 5 min later:
user2@nixosb:~> systemctl --user status plasma-kcminit
● plasma-kcminit.service - KDE Config Module Initialization
     Loaded: loaded (/nix/store/82zx0kyyy8ch6h2yhhhpxya84cniap6y-plasma-workspace-5.21.1/share/systemd/user/plasma-kcminit.service; linked-runtime; vendor preset: enabled)
     Active: inactive (dead) since Mon 2021-03-22 18:51:06 CET; 1min 20s ago
    Process: 2050 ExecStart=/nix/store/82zx0kyyy8ch6h2yhhhpxya84cniap6y-plasma-workspace-5.21.1/bin/kcminit_startup (code=exited, status=0/SUCCESS)
   Main PID: 2058 (code=exited, status=0/SUCCESS)
        CPU: 11.219s

Mar 22 18:45:54 nixosb systemd[1933]: Starting KDE Config Module Initialization...
Mar 22 18:46:05 nixosb kcminit_startup[2058]: Initializing  "kcm_style" :  "kcminit_style"
Mar 22 18:46:05 nixosb kcminit_startup[2085]: /var/tmp/kcminit.XwgQhJ:0: warning: Unknown encoding: C.UTF-8
Mar 22 18:46:06 nixosb kcminit_startup[2085]:
Mar 22 18:46:06 nixosb kcminit_startup[2058]: QDBusConnection: error: could not send signal to service "" path "//home/user2/.kde/share/config/kdeglobals" interface "org.kde.kconfig.notify" member "ConfigChanged": Invalid object path: //home/user2/.kde/share/config/kdeglobals
Mar 22 18:46:06 nixosb kcminit_startup[2058]: Initializing  "kcm_mouse" :  "kcminit_mouse"
Mar 22 18:46:06 nixosb systemd[1933]: Started KDE Config Module Initialization.
Mar 22 18:51:06 nixosb systemd[1933]: plasma-kcminit.service: Succeeded.
Mar 22 18:51:06 nixosb systemd[1933]: plasma-kcminit.service: Consumed 11.219s CPU time.

I got irritated by the "Unknown encoding" error.  Note that the test system has the NixOS configuration i18n.defaultLocale = "C.UTF-8";.  I changed that to en_US.UTF-8 and tried again (with a fresh user account).  The waring disappears, everything else stays the same.
Regarding the PR's title change, I'd like to add that I didn't enable wayland for this tests.

First post has been updated with the current situation. You might find #100057 interesting as well.

I haven't looked at the proper way to add the session file so this is the quick and dirty. But it works.

I currently have the following in my config:
services.xserver.displayManager.sessionPackages = [
    (pkgs.plasma-workspace.overrideAttrs
      (old: { passthru.providedSessions = [ "plasmawayland" ]; }))
  ];

Still a bit hacky I guess, but it should not make any other sessions unavailable...

@matrss it's how I'm testing https://github.com/NixOS/nixpkgs/pull/100057

@pasqui23 In that case I probably got the code from you at some point and should give you credit for it. Had it sitting around in my config for a while now and could not remember where I got it from, sorry about that.

For some reason, using this, kwin_wayland just crashes when logging in. I've tried:

This PR + #100057 applied to nixos-unstable
This PR + https://github.com/NixOS/nixpkgs/pull/117102#issuecomment-808709522 applied to nixos-unstable
Checking out this PR and applying https://github.com/NixOS/nixpkgs/pull/117102#issuecomment-808709522
#100057 applied to nixos-unstable

From journalctl -b:
Mar 28 11:29:23 girafarig kernel: show_signal_msg: 78 callbacks suppressed
Mar 28 11:29:23 girafarig kernel: kwin_wayland[1339]: segfault at 18 ip 00007f8ccfc6d6d0 sp 00007ffc2cf22dd8 error 6 in libgbm.so.1.0.0[7f8ccfc6d000+7000]
Mar 28 11:29:23 girafarig kernel: Code: 2e 0f 1f 84 00 00 00 00 00 90 ff a7 b8 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 ff a7 c0 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 <83> 6f 18 01 75 0a ff a7 b0 00 00 00 0f 1f>
Mar 28 11:29:23 girafarig systemd[1]: Created slice system-systemd\x2dcoredump.slice.
Mar 28 11:29:23 girafarig systemd[1]: Started Process Core Dump (PID 1343/UID 0).
Mar 28 11:29:23 girafarig systemd-coredump[1344]: Process 1339 (kwin_wayland) of user 1000 dumped core.
Mar 28 11:29:23 girafarig systemd[1]: systemd-coredump@0-1343-0.service: Succeeded.

The above is repeated a couple of times, and then I'm returned to SDDM.
However, kwin_wayland does not segfault when checkout out #100057 (and not rebasing onto nixos-unstable). Which was running Plasma 5.20, so it seems like the upgrade to 5.21 might be why this happens.
The above segfault lies in gbm_device_destroy btw:
00000000000036d0 <gbm_device_destroy>:
    36d0:       83 6f 18 01             subl   $0x1,0x18(%rdi)
    36d4:       75 0a                   jne    36e0 <gbm_device_destroy+0x10>
    36d6:       ff a7 b0 00 00 00       jmpq   *0xb0(%rdi)
    36dc:       0f 1f 40 00             nopl   0x0(%rax)
    36e0:       c3                      retq
    36e1:       66 2e 0f 1f 84 00 00    nopw   %cs:0x0(%rax,%rax,1)
    36e8:       00 00 00
    36eb:       0f 1f 44 00 00          nopl   0x0(%rax,%rax,1)

FWIW, KDE using wayland is good enough to be my daily driver from now on. 2 minor issues:

I need a replacement for xcape
notifications keep taking focus which is annoying

@peterhoeg problem 2 does not appear on other distros?

I haven't tried with other distros, but I haven't been able to find any reports (other than it was an issue back in the early 5.x days) so I'm guessing it's related to nixos.

@peterhoeg should ask the kde devs how they did fix it on other distros.

Is there anything preventing the work on this so far from being merged?

Is there anything preventing the work on this so far from being merged?

Yes, nixos-rebuild test kills the session. But I want to get this sorted ASAP so we can get it into 21.05 (default off).

@peterhoeg I am wondering if I can help test this, as branch off for 21.05 is scheduled for 21st May (2 days from now).
Of course, we are all volunteers so if its not done, it won't really matter.

I'd also like to help getting wayland desktop to a properly usable state asap. So far my main gripes are with the clipboard (screenshots) and IME.

I'd also like to help getting wayland desktop to a properly usable state asap

Plasma wayland is currently unusable until https://github.com/NixOS/nixpkgs/issues/118650 is fixed.
As for the "launched by systemd" bit, switching to a new generation still closes the session. Haven't had time to look
at this yet.

FWIW my session does not die on me when I do nixos-rebuild test on wayland with this PR and the runUsingSystemd option enabled on top of current nixos-unstable (5a82107).

on top of current nixos-unstable (5a82107).

I just thought I'd add that 5a82107 uses Plasma 5.21.5 (not 5.22.4, which was merged just after nixos-unstable updated)

Thanks for pointing that out. I double-checked and it turns out I'd mixed up my branches and this is in fact on top of master at 86340c737053d97e476b1fc96901058494222a63 which has 5.22.4
That said I don't remember the session dying with earlier versions either.

I started trying this out today because I have a new multi-monitor setup that benefits from different scaling on each screen. Here are some problems I ran into:

Notifications steal focus, as mentioned above. This basically makes it unsuitable for daily use.
Window thumbnails are broken in the taskbar, but work in other places like the window switcher (aka Alt-Tab).
Colors are weird in Firefox. "Green" is now more of an "olive" color.
VS Code is blurry under scaling. Workaround: https://github.com/microsoft/vscode/issues/109176#issuecomment-846645377
The taskbar shows a generic icon for X11 applications.
Context menus sometimes disappear.
GTK applications are not themed correctly. Instead of getting Breeze, they fall back to Adwaita and have the wrong window decorations. This also affects the file chooser in Electron applications.

Despite these flaws, I think the situation is definitely good enough that we can consider merging this pull request as long as X11 is still the default Plasma session.

Also worth noting: The "Plasma (X11)" session works just fine with systemd, too!

7\. GTK applications are not themed correctly.

Actually, I think this is due to using systemd and not Wayland. systemd will not run our custom scripts for setting the default theme. Plasma should use the corresponding NixOS options to set the default theme instead.

Found an interesting bit in logs, might explain why pipewire screen capturing, screenshots and fcitx5 are currently not working on my system:
Sep 16 10:17:09 isildur .kded5-wrapped[7560]: failed to commit changes to dconf: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name ca.desrt.dconf was not provided by any .service files
Sep 16 10:17:09 isildur .kded5-wrapped[7560]: failed to commit changes to dconf: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name ca.desrt.dconf was not provided by any .service files
Sep 16 10:17:09 isildur .kded5-wrapped[7560]: failed to commit changes to dconf: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name ca.desrt.dconf was not provided by any .service files
Sep 16 10:17:09 isildur .kded5-wrapped[7560]: failed to commit changes to dconf: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name ca.desrt.dconf was not provided by any .service files
Sep 16 10:17:09 isildur dbus-daemon[7108]: [session uid=XXXX pid=7108] Activating via systemd: service name='org.kde.ActivityManager' unit='plasma-kactivitymanagerd.service' requested by ':1.20' (uid=XXXX pid=8053 comm="/nix/store/www6xnf>
Sep 16 10:17:09 isildur systemd[7090]: Starting KActivityManager Activity manager Service...
Sep 16 10:17:09 isildur plasmashell[8053]: Aborting shell load: The activity manager daemon (kactivitymanagerd) is not running.
Sep 16 10:17:09 isildur plasmashell[8053]: If this Plasma has been installed into a custom prefix, verify that its D-Bus services dir is known to the system for the daemon to be activatable.

sorry about that i had remembered that it after using gh pr checkout it would prompt me for where i want to push

To whoever is tracking this - Plasma with Wayland works wonderfully here with latest unstable and this PR applied. There are a few minor glitches (those are upstream issues) as well as a few non-KDE applications not behaving properly but that's neither our nor KDE's fault. I really want to get this cleaned up properly and submitted for 21.11.

Tried this today and so far so good - Wayland session has appeared and it's been working for the last several hours.
How to make it happen into 21.11? Whom do we need to ping to review?
P.S. If you are new to Nix and want to try the fix, here are the instructions: https://discourse.nixos.org/t/how-to-try-a-pr/15410/6?u=haizaar

It's been rebased - I'd like to do a final test when #100057 hits unstable and then go ahead and get this merged.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/kde-plasma-wayland-still-does-not-behave-correctly/15526/2

Looks like we're good to go.
Any thoughts on making the "run with systemd" default to true?

I vote yes.

@CertainLach is there anything in your powers to get it approved/merged? (apologies if I'm pinging a wrong person)

authors: Artturin Yarny0 e3bc54b2 haizaar jakobrs jansol matrss nixos-discourse pasqui23 peterhoeg remedialchaos ttuegel worldofpeace


text:
update coqPackages.equations

Motivation for this change
This library can be used with the new version of Coq that was released a couple of weeks ago.  I just added the new version numbers and checksums.
Things done
I have made sure it compiles and can be loaded into Coq with
NIX_PATH=~/HACK nix-shell --packages coqPackages_8_13.{coq,equations)
coqtop
From Equations Require Import Equations.

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

[ ] NixOS
[X] 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/)
[ ] 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
[ ] Fits CONTRIBUTING.md.

Please target the master branch. nixpkgs-unstable gets updated automatically after some basic tests passed and though cannot be pushed to.


text:
python3Packages.fabulous: 0.3.0 -> 0.4.0

Motivation for this change
Update to latest upstream release  0.4.0
Change log: https://github.com/jart/fabulous/releases/tag/0.4.0
Things done

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

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

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

5 packages built:

paperwork
python38Packages.fabulous
python38Packages.paperwork-shell
python39Packages.fabulous
python39Packages.paperwork-shell

Result of nixpkgs-review pr 129033 at 73e9987d run on aarch64-linux 1

5 packages built successfully:

paperwork
python38Packages.fabulous
python38Packages.paperwork-shell
python39Packages.fabulous
python39Packages.paperwork-shell

1 suggestion:

warning: missing-patch-comment
Consider adding a comment explaining the purpose of this patch on the line preceeding.
Near pkgs/development/python-modules/fabulous/default.nix:20:5:
   |
20 |     ./relative_import.patch
   |     ^

authors: fabaff r-rmcgibbo


text:
catgirl: fix compiler warning, remove unneeded buildInput

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 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 133942 at 9ad15b39 run on x86_64-linux 1

1 package built successfully:

catgirl

1 suggestion:

warning: missing-patch-comment
Consider adding a comment explaining the purpose of this patch on the line preceeding.
Near pkgs/applications/networking/irc/catgirl/default.nix:13:5:
   |
13 |     (fetchpatch {
   |     ^

authors: r-rmcgibbo sternenseemann


text:
python3Packages.apprise: 0.9.4 -> 0.9.5.1

Motivation for this change
Update to latest upstream release 0.9.5.1
Change log: https://github.com/caronc/apprise/releases/tag/v0.9.5.1
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 138758 run on x86_64-linux 1

3 packages built:

apprise (python39Packages.apprise)
home-assistant
python38Packages.apprise


text:
nixos/modules/services/backup/borgbackup.nix: Add retry on fail

Motivation for this change
This service always fails for me.  I think this is because network isn't up when it gets executed.
I added an option to make it retry the service.
Another fix would be depending on network-online.target.  But this can impact boot time (https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/)
Things done

Built on platform(s)

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

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

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

[ ] Fits CONTRIBUTING.md.

Does this software always fail for other people too? These options don't do anything, just add discoverability. I would be inclined to suggest just modifying the systemd service in your own configuration unless there is evidence to suggest many people a) have this problem, and b) don't know if the systemd options.

doesn't fail here, but there is another PR about this exact thing: #99196

Sorry I should have used the searched fist.

wasn't meaning to imply that, just that there's at least one other person with that problem. :)

@toonn sounds good :+1: I didn't mean to this is invalid - it was a legitimate question because I'm not familiar with the software. I think it is good to ask questions like this and if the answer is "yes, this is valid" then I'm happy.

Np, I was just giving my rationale for why my changes are warranted. I'm hoping this'll cause some movement on that PR of mine or an alternative, I've been overlaying with my patch for over a year now and I think it'd be useful to others.

authors: StillerHarpo aanderse pennae toonn


text:
Workaround Skype segfault

Things done:

[x] Tested using sandboxing (nix-build --option build-use-chroot true or nix.useChroot on NixOS)
Built on platform(s)

[x] NixOS
[ ] OS X
[ ] Linux

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

More
This is one possible solution to the problem. I'm not sure if I've done everything correctly to force Hydra to build qt4-clang only on i686.
Fixes issue #14234
cc @rycee @domenkozar

We had a staging merge just now -- I'll open this against master then ~_^.

Why is 64bit not supported?

@domenkozar We just don't need it -- only Skype needs 32-bit Clang-built Qt4, and I don't see any reasons to build it on x86_64.

@abbradar we should then not disable skype on 64bit linux, but rather always pass 32bit clang-built qt4

Hm, I haven't disabled it -- the idea was to make Hydra build qt4-clang for i686 (for Skype), but not on x86_64. My solution was to add qt4-clang to all-packages (so Hydra would see it), but force it to build only on i686-linux in release.nix. I'm not sure I've done it the right way, though.

Ah, I should also point out that Skype is called through callPackage_i686, so it would get 32-bit version of this package automatically... or wait, it would not.

authors: abbradar domenkozar


text:
nncp: 7.7.0 -> 8.0.2, add NixOS module

Motivation for this change
The NNCP package is out of date and there is no NixOS module.
Some other things:

hjson doesn't work unless python is in PATH, fixed that
hjson is Python and therefore too slow to be called from an activation script, package hjson-go
Add a reference to the man page for systemd sockets to the listenStreams option description.

Things done

Built on platform(s)

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

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

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

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

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

[x] Fits CONTRIBUTING.md.

Great work! My comments:

I do not get why https://github.com/NixOS/nixpkgs/pull/146011/commits/a1dfbf6bec8272196a27717f091a0f60d9f6866c belongs into this PR.
At my first try I get jq: error (at /nix/store/s9…nj-nncp.json:14): null (null) and object ({"self":{"e...) cannot be multiplied when merging my config in build, but the rebuild succeeds, with an empty /etc/nncp.hjson – maybe this should be handled more cleanly, or documented what to do and what not to do.
nixos test succeeds :+1:

@woffs thanks. The configuration mangling and merging was working for me yesterday but now I'm getting similar errors. Maybe it breaks after a certain amount of neighbour complexity. Its a bit unusual that the conversion is happening in an activation script and not as part of a systemd unit, were an error might be more obvious. I think it needs to be thought out some more.
a1dfbf6bec8272196a27717f091a0f60d9f6866c doesn't need to be part this PR, but found myself copy-pasting from documentation from the u9fs module when I should just look at the systemd socket options themselves.
Also, systemd is not passing everything that nncp-daemon expects, but the daemon still works in "pipe" mode.

Maybe you want to change nccp to nncp in the topic :-)

@woffs I tweaked the configuration generator and the error has gone away for me (and I fixed the topic, thanks).

I'm not sure what the "user" should be for the nncp-daemon. My thought was that if there is a spool directory that can be modified by both a service and normal users then a non-dynamic user is appropriate, but systemd complains that using nobody is unsafe (but using root is fine).

I think we have problems with configuring NNCP that should be dicussed upstream before releasing a NixOS module. Package update moved to #151071.

authors: ehmry woffs


text:
python3Packages.oocsi: init at 0.4.2

Motivation for this change
OOCSI library for Python
https://github.com/iddi/oocsi-python
This could become 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, 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

[x] Fits CONTRIBUTING.md.

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

2 packages built:

python38Packages.oocsi
python39Packages.oocsi


text:
python3Packages.python-smarttub: relax aiohttp constraint

Motivation for this change
Fix build (https://hydra.nixos.org/build/159185697)
Things done

Built on platform(s)

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

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

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

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

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

[x] Fits CONTRIBUTING.md.

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

1 package failed to build:

home-assistant

2 packages built:

python38Packages.python-smarttub
python39Packages.python-smarttub


text:
iw: 5.9 -> 5.16

Motivation for this change
https://git.kernel.org/pub/scm/linux/kernel/git/jberg/iw.git/log/?h=v5.16
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, 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 149325 run on x86_64-linux 1

6 packages built:

aircrack-ng
iw
linssid
linux-router
tlp
wifite2

authors: mweinelt thiagokokada


text:
olm: 3.2.6 -> 3.2.8

Motivation for this change
This security release fixes a "high severity issue" that has not yet
been further described.
https://matrix.org/blog/2021/12/03/pre-disclosure-upcoming-security-release-of-libolm-and-matrix-js-sdk
Update: In the meantime, more information were disclosed: https://matrix.org/blog/2021/12/13/disclosure-buffer-overflow-in-libolm-and-matrix-js-sdk
Things done

Built on platform(s)

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

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

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

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

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

[x] Fits CONTRIBUTING.md.

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

24 packages built:

chatty
go-neb
gomuks
matrix-commander
matrixcli
mautrix-facebook
mautrix-signal
mautrix-telegram
mautrix-whatsapp
mirage-im
mtxclient
neochat
nheko
olm
opsdroid
pantalaimon
pantalaimon-headless
purple-matrix
python38Packages.matrix-nio
python38Packages.python-olm
python39Packages.matrix-nio
python39Packages.python-olm
weechatScripts.weechat-matrix
weechatScripts.weechat-matrix-bridge


text:
lziprecover: init at 1.22

Maintainer is absent for the original package that's why I haven't put myself in here. I can add myself to both of them if needed
Motivation for this change
This is a data recovery tool for lzip files. which I am depending on for my current job :)
Things done
Tried cross-building to multiple platform successfully but didn't test any of the crossbuilt output. CFLAGS and co. are directly lifted over from the lzip defivation.

Built on platform(s)

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

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

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

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

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

[x] Fits CONTRIBUTING.md.

We can either put this entire PR onto staging or only move the lzip things there because they cause to many rebuilds

We can either change the entire PR to target staging or only move the lzip changes to staging.

I've retargeted the PR to the staging branch


text:
python3Packages.ruamel-yaml-clib: 0.2.4 -> 0.2.6

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

Built on platform(s)

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

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

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

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

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

[x] Fits CONTRIBUTING.md.

@ofborg build python39Packages.ruamel-yaml-clib python310Packages.ruamel-yaml-clib