Problems with using packages from unstable

I started using Nixos about two weeks ago and everything is going great except for the unstable channel. There are some programs whose versions I would like to use from unstable. For reference I used Installing only a single package from unstable.
Channels in use:

➜  ~ sudo nix-channel --list
home-manager https://github.com/nix-community/home-manager/archive/release-21.11.tar.gz
nixos https://nixos.org/channels/nixos-21.11
nixos-unstable https://nixos.org/channels/nixos-unstable

Imports:

{ config, pkgs, lib, ... }:
let
  unstable = import <nixos-unstable> { config = { allowUnfree = true; }; };
in
{
  imports =
    [
      # Include the results of the hardware scan.
      ./hardware-configuration.nix

      <home-manager/nixos>
    ];

And packages:

home.packages = with pkgs; [
      unstable.alacritty
      unstable.wezterm

      unstable.jetbrains.rider
      unstable.jetbrains.idea-ultimate
      unstable.jetbrains.pycharm-professional
      unstable.jetbrains.clion
    ];

Any program that I tried to use from unstable causes some kind of problem.
Alacritty:

➜  ~ alacritty
Created log file at "/tmp/Alacritty-6123.log"
[0.001503696s] [WARN ] [alacritty_config_derive] Config warning: background_opacity is deprecated; use window.opacity instead
Deleted log file at "/tmp/Alacritty-6123.log"
Error: Error creating GL context; Received multiple errors. Errors: `[OsError("Could not create EGL display object"), OsError("`glXQueryExtensionsString` found no glX extensions")]`

Wezterm with a similar error. out is a bit longer this time. Removed the repeating errors and all sorts of warnings:

➜  ~ wezterm
libEGL warning: MESA-LOADER: failed to open iris: /nix/store/m4g6lswi75b739cpdx8wfxlfmcazyks9-glibc-2.34-115/lib/libpthread.so.0: version `GLIBC_PRIVATE' not fo
und (required by /nix/store/qjgj2642srlbr59wwdihnn66sw97ming-glibc-2.33-123/lib/librt.so.1) (search paths /run/opengl-driver/lib/dri, suffix _dri)

22:00:34.416  ERROR  wezterm_gui::frontend          > Failed to create window: with_egl_lib failed: with_egl_lib(libEGL.so.1) failed: egl Initialize: NOT_INITIALIZED, libEGL.so: libEGL.so: cannot open shared object file: No such file or directory, with_egl_lib(libEGL.so.1) failed: egl Initialize: NOT_INITIALIZED, libEGL.so: libEGL.so: cannot open shared object file: No such file or directory

In the case of jetbrains products. I’ve had time to test PyCharm and IntelliJ IDEA so far. From the first glance, the errors are different, but the source of the errors is the same and is visible in the out.
IntelliJ IDEA terminal. The error will not just affect the terminal, in fact the whole IDEA is tied to Gradle, so the work is simply not possible:

➜  ~ ./gradlew build
/nix/store/b7w29s922lprhvvsg259bdazxg55vqql-openjdk-17.0.3+7/lib/openjdk/bin/java: /nix/store/qjgj2642srlbr59wwdihnn66sw97ming-glibc-2.33-123/lib/libc.so.6: version `GLIBC_2.34' not found (required by /nix/store/69brclzxp7mg927k6986hrfzyd1hpqgd-gcc-11.2.0-lib/lib/libstdc++.so.6)
/nix/store/b7w29s922lprhvvsg259bdazxg55vqql-openjdk-17.0.3+7/lib/openjdk/bin/java: /nix/store/qjgj2642srlbr59wwdihnn66sw97ming-glibc-2.33-123/lib/libc.so.6: version `GLIBC_2.34' not found (required by /nix/store/69brclzxp7mg927k6986hrfzyd1hpqgd-gcc-11.2.0-lib/lib/libgcc_s.so.1)

And the end of Pycharm which throws an error if I try to specify python via system interprater. Which is also set via configuration.nix. Pycharm out:

2022-05-05 22:14:25,091 [  14113]   WARN - #c.j.p.s.f.PythonSdkFlavor - Couldn't get interpreter version: process exited with code 1
/nix/store/wq6s8i407ic4qp1dvd5yhrnd0kflzh6x-python3-3.9.12/bin/python3: /nix/store/qjgj2642srlbr59wwdihnn66sw97ming-glibc-2.33-123/lib/libc.so.6: version `GLIBC_2.34' not found (required by /nix/store/69brclzxp7mg927k6986hrfzyd1hpqgd-gcc-11.2.0-lib/lib/libgcc_s.so.1)

And:
image

All these problems I have observed only with Unstable packages. Stable versions work fine. Therefore, I began to think that the problem was in my configuration and did not write in an issue on github and wrote here.
In all cases, there is some kind of problem with the libraries, which I thought was not possible on this system. Thanks for all the help.

1 Like

The OpenGL issues have to do with the fact that OpenGL is handled impurely. To be more specific, NixOS is providing OpenGL infrastructure (drivers, etc.) from the stable channel and your trying to run “unstable” apps which expect a newer OpenGL infrastructure.

Despite the name, the unstable branch is quite usable. You can always try running everything off unstable, and revert back if you have unsolvable issues. Of course, it’s best to make a backup first.

Personally, I build NixOS from the master branch, but I’m reckless.

3 Likes

Despite my last sentence. I assumed that the drivers are processed impurely. But the question is, can’t Nixos build a package suitable for my system with my drivers? Or is it necessary to manually replace dependencies through overlays (or which method is suitable for this purpose)?

Theoretically you would have been able to provide an updated mesa driver to hardware.opengl.package (assuming that this is the problem) but unfortunately that option is internal.

I think probably you would want to patch it in with an overlay if you don’t want to build your system against the unstable channel, which would have the same effect

(IMO is a little less nice than setting hardware.opengl.package could have been if it was not internal - I wonder if it ought to be public. On the other hand some packages seem to have mesa.drivers in their builds so there could be a reason for it to be restricted)

By the way, you can supply more drivers via hardware.opengl.extraPackages.

Messing with the mesa drivers might be a bit of red herring - I’m guessing you can probably just supply the correct opengl driver for your specific system setup. Just a guess though - I’m not very familiar with driver level opengl details.

Thanks for the clarification, I already added a few packages there to add support for vaapi, like obs was able to grab it and it works great. Although I still don’t quite understand the whole list of packages that I need to work with hardware video and gpu and all this stuff. And I still need to add CUDA somehow.

For CUDA, from memory ~I believe just need~

nixpkgs.config.cudaSupport = true;
nixpkgs.config.allowUnfree = true;

or

import <nixpkgs> { config = { allowUnfree = true; cudaSupport = true; }; };

depending on how you’re doing things.

(This will cause packages with cuda support to rebuild with cuda libraries. Be prepared for some compilation time. You do need to add the nvidia drivers though)

I haven’t super carefully checked this, but I have something like this in one of my headless configs - just in case it saves you some time:

    nixpkgs.config.allowUnfree = true;
    nixpkgs.config.cudaSupport = true;
    nixpkgs.config.cudnnSupport = true; # in case you're doing machine learning stuff

    services.xserver = {
      enable = true;
      displayManager.startx.enable = true; # minimal display manager
      videoDrivers = [
        "nvidia"
      ];
    };

    hardware.opengl = {
      enable = true;
      extraPackages = with pkgs; [
        mpi
        linuxPackages.nvidia_x11
        # can't remember which is needed:
        # cudatoolkit
        # cudatoolkit.lib
      ];
    };

I think I had to reboot for something here to take effect.

1 Like

I tried several times to use overlays. Unfortunately I failed. The syntax still seems strange to me. First I try to start simple and write .nix for my old projects and then try to overlay them. I still have a long way to go. In the meantime, can anyone share an overlay template that will change impure dependencies?

What you’re trying to do is not trivial and a major issue for which even experienced Nix users haven’t found a good solution to yet: Solve the libGL ABI problem · Issue #31189 · NixOS/nixpkgs · GitHub

This has nothing to do with syntax, your inexperience or anything related to you; it’s an issue that goes down to the basics; the way programs are made up and how that meshes with Nix’ model.

It’s not something you can fix from your configuration.

1 Like