!UNVBThoJtlIiVwiDjU:nixos.org

Staging

316 Members
Staging merges | Running staging cycles: https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+head%3Astaging-next+head%3Astaging-next-25.05 | Review Reports: https://malob.github.io/nix-review-tools-reports/107 Servers

Load older messages


SenderMessageTime
19 Dec 2025
@robert:funklause.dedotlambdahttps://github.com/NixOS/nixpkgs/pull/47245719:44:39
@ghpzin:envs.netghpzin Noticed that all graphical xserver tests seem to be broken on staging-next.
wayland is fine, tests for gnome,sway,xfce-wayland, cinnamon-wayland (and plasma6 if you switch test to wayland) pass.
lightdm does not tell much, just that display-manager.service fails:
systemd[1]: display-manager.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: display-manager.service: Failed with result 'exit-code'.
sddm and ly in tests show errors from xorg-server:
xserver-wrapper[823]: (II) LoadModule: "modesetting"
xserver-wrapper[823]: (II) Loading /nix/store/lrbawv4ccl0x12nwrmbbzpxmzjj1z5r6-xorg-server-21.1.20/lib/xorg/modules/drivers/modesetting_drv.so
xserver-wrapper[823]: (EE) Failed to load /nix/store/lrbawv4ccl0x12nwrmbbzpxmzjj1z5r6-xorg-server-21.1.20/lib/xorg/modules/drivers/modesetting_drv.so: /nix/store/lrbawv4ccl0x12nwrmbbzpxmzjj1z5r6-xorg-server-21.1.20/lib/xorg/modules/drivers/modesetting_drv.so: undefined symbol: gbm_bo_get_plane_count
xserver-wrapper[823]: (EE) Failed to load module "modesetting" (loader failed, 0)
xserver-wrapper[823]: (EE) No drivers available.
Changing this to "--disable-glamor" fixes it:
https://github.com/NixOS/nixpkgs/blob/fd720f4fd4e78cce030a72026d1b7cadf6454f29/pkgs/by-name/xo/xorg-server/package.nix#L185
I thought it may be related to 21.1.18 -> 21.1.20 update, similar to:
https://github.com/NixOS/nixpkgs/issues/471620
but reverting version to 21.1.18 does not help, neither does updating to 21.1.21
There were a few xorg refactors merged to staging, maybe one of them did something unintentional.
19:52:10
@k900:0upti.meK900 Can you check if modesetting_drv links libgbm correctly 20:15:25
@k900:0upti.meK900 gbmbogetplanecount should be exported by libgbm 20:15:47
@ghpzin:envs.netghpzin It doesn't link directly right, something else there should link to that ?
Unless I misunderstand what you mean, ie on both staging-next and master it does not link to libgbm:
ldd ./result-master/lib/xorg/modules/drivers/modesetting_drv.so
        linux-vdso.so.1 (0x00007fb435c72000)
        libudev.so.1 => /nix/store/q5fmjr9s9968bkv5bm3al5517x27bm19-systemd-minimal-libs-258.2/lib/libudev.so.1 (0x00007fb435b03000)
        libm.so.6 => /nix/store/xx7cm72qy2c0643cm1ipngd87aqwkcdp-glibc-2.40-66/lib/libm.so.6 (0x00007fb435a1b000)
        libc.so.6 => /nix/store/xx7cm72qy2c0643cm1ipngd87aqwkcdp-glibc-2.40-66/lib/libc.so.6 (0x00007fb435800000)
        libcap.so.2 => /nix/store/l486byj55nq10ys3jbgszd2hywkxbq7l-libcap-2.77-lib/lib/libcap.so.2 (0x00007fb435a0e000)
        /nix/store/j193mfi0f921y0kfs8vjc1znnr45ispv-glibc-2.40-66/lib64/ld-linux-x86-64.so.2 (0x00007fb435c74000)
The only thing in both cases that does is /lib/xorg/modules/libglamoregl.so:
ldd ./result-master/lib/xorg/modules/libglamoregl.so
        linux-vdso.so.1 (0x00007fa0653d5000)
        libgbm.so.1 => /nix/store/pw8v6hlrg7lz2d3x115x3zy80bbhx1x9-mesa-libgbm-25.1.0/lib/libgbm.so.1 (0x00007fa065344000)
        libepoxy.so.0 => /nix/store/1r61lw1k35085way0cgl3pxz9cm9awjs-libepoxy-1.5.10/lib/libepoxy.so.0 (0x00007fa06521e000)
        libm.so.6 => /nix/store/xx7cm72qy2c0643cm1ipngd87aqwkcdp-glibc-2.40-66/lib/libm.so.6 (0x00007fa065136000)
        libc.so.6 => /nix/store/xx7cm72qy2c0643cm1ipngd87aqwkcdp-glibc-2.40-66/lib/libc.so.6 (0x00007fa064e00000)
        libdrm.so.2 => /nix/store/p4fk8qb6cy0zs65j6h50rh9bs7hnsgif-libdrm-2.4.128/lib/libdrm.so.2 (0x00007fa06511b000)
        /nix/store/j193mfi0f921y0kfs8vjc1znnr45ispv-glibc-2.40-66/lib64/ld-linux-x86-64.so.2 (0x00007fa0653d7000)
ldd ./result-staging-next/lib/xorg/modules/libglamoregl.so
        linux-vdso.so.1 (0x00007f8e1c2d2000)
        libgbm.so.1 => /nix/store/24w3s75aa2lrvvxsybficn8y3zxd27kp-mesa-libgbm-25.1.0/lib/libgbm.so.1 (0x00007f8e1c23f000)
        libepoxy.so.0 => /nix/store/kzl2j4nxwr6c0f2xbd44zjmgh8kqxr57-libepoxy-1.5.10/lib/libepoxy.so.0 (0x00007f8e1c11c000)
        libm.so.6 => /nix/store/j193mfi0f921y0kfs8vjc1znnr45ispv-glibc-2.40-66/lib/libm.so.6 (0x00007f8e1c034000)
        libc.so.6 => /nix/store/j193mfi0f921y0kfs8vjc1znnr45ispv-glibc-2.40-66/lib/libc.so.6 (0x00007f8e1be00000)
        libdrm.so.2 => /nix/store/sixic8a4adxz72swww4fcls0h5sabjdf-libdrm-2.4.129/lib/libdrm.so.2 (0x00007f8e1c019000)
        /nix/store/j193mfi0f921y0kfs8vjc1znnr45ispv-glibc-2.40-66/lib64/ld-linux-x86-64.so.2 (0x00007f8e1c2d4000)
20:34:48
@k900:0upti.meK900Hm20:36:34
@k900:0upti.meK900I wonder if it's the xserver itself then20:36:40
@k900:0upti.meK900That is linking it20:36:46
@k900:0upti.meK900Is it just a load order thing20:37:04
@k900:0upti.meK900That would be sad20:37:07
@ghpzin:envs.netghpzin I tried reordering these buildInputs like here on master:
https://github.com/NixOS/nixpkgs/blob/c30b80416b233c3673e573c0821bf96cc83818db/pkgs/servers/x11/xorg/overrides.nix#L452-L457
ie this diff on staging-next:
--- a/pkgs/by-name/xo/xorg-server/package.nix
+++ b/pkgs/by-name/xo/xorg-server/package.nix
@@ -139,10 +139,10 @@
     xtrans
   ]
   ++ lib.optionals (!stdenv.hostPlatform.isDarwin) [
-    dri-pkgconfig-stub
     libdrm
     libgbm
     mesa-gl-headers
+    dri-pkgconfig-stub
   ]
   ++ lib.optionals stdenv.hostPlatform.isDarwin [
     autoconf
but it did not help.
That refactor moved xorg-server into separate by-name so tracking what went where is quite hard.
20:42:35
@ghpzin:envs.netghpzin I tried reordering these buildInputs like here on master:
https://github.com/NixOS/nixpkgs/blob/c30b80416b233c3673e573c0821bf96cc83818db/pkgs/servers/x11/xorg/overrides.nix#L452-L457
ie this diff on staging-next:
--- a/pkgs/by-name/xo/xorg-server/package.nix
+++ b/pkgs/by-name/xo/xorg-server/package.nix
@@ -139,10 +139,10 @@
     xtrans
   ]
   ++ lib.optionals (!stdenv.hostPlatform.isDarwin) [
-    dri-pkgconfig-stub
     libdrm
     libgbm
     mesa-gl-headers
+    dri-pkgconfig-stub
   ]
   ++ lib.optionals stdenv.hostPlatform.isDarwin [
     autoconf
but it did not help.
That refactor from staging moved xorg-server into separate by-name so tracking what went where is quite hard.
20:44:06
@ghpzin:envs.netghpzin I tried reordering these buildInputs like here on master:
https://github.com/NixOS/nixpkgs/blob/c30b80416b233c3673e573c0821bf96cc83818db/pkgs/servers/x11/xorg/overrides.nix#L452-L457
ie this diff on staging-next:
--- a/pkgs/by-name/xo/xorg-server/package.nix
+++ b/pkgs/by-name/xo/xorg-server/package.nix
@@ -139,10 +139,10 @@
     xtrans
   ]
   ++ lib.optionals (!stdenv.hostPlatform.isDarwin) [
-    dri-pkgconfig-stub
     libdrm
     libgbm
     mesa-gl-headers
+    dri-pkgconfig-stub
   ]
   ++ lib.optionals stdenv.hostPlatform.isDarwin [
     autoconf
but it did not help.
That refactor from staging moved xorg-server into separate by-name so tracking what went where is quite hard.
It is quite suspicious that upstream did something with glamor in 21.1.20 that broke other things, and now we get problems related to it too.
Maybe somewhere on staging between refactors somebody did something related to that update, but I could not find it so far.
20:46:11
@fabianhjr:matrix.orgFabián Herediahttps://github.com/NixOS/nixpkgs/pull/472445 Fixes dee in staging-next (dependency of libunity <- Discord)22:36:32
@fabianhjr:matrix.orgFabián Heredia * https://github.com/NixOS/nixpkgs/pull/472445 Fixes dee in staging-next (dependency of libunity <- Discord) due to gcc15 breakage 22:36:48
@fabianhjr:matrix.orgFabián Heredia
error: Cannot build '/nix/store/w2vcan2incrnad11ysbj6xj4w509mf8v-dee-unstable-2017-06-16.drv'.
       Reason: builder failed with exit code 2.
       Output paths:
         /nix/store/3ajwi6lggwj7pjzv6gyx0g095x4sidhp-dee-unstable-2017-06-16
         /nix/store/7is6xw5sxqydjbfrph3c9ix5mg2rg4nj-dee-unstable-2017-06-16-dev
         /nix/store/jvxyifr4yqqgpi5vgc0dc315kvdj5s4n-dee-unstable-2017-06-16-py
       Last 25 log lines:
       >       |   ^~~~~~~~
       > In file included from /nix/store/j359ndglk11v5j47ra66lc1vxlk2dbjw-glib-2.86.3-dev/include/glib-2.0/glib.h:92:
       > /nix/store/j359ndglk11v5j47ra66lc1vxlk2dbjw-glib-2.86.3-dev/include/glib-2.0/glib/gtimer.h:75:10: note: declared here
       >    75 | gchar*   g_time_val_to_iso8601   (GTimeVal    *time_) G_GNUC_MALLOC;
       >       |          ^~~~~~~~~~~~~~~~~~~~~
       > dee-tool.c: In function 'dump_peer':
       > dee-tool.c:242:31: error: passing argument 2 of 'g_timeout_add_seconds' from incompatible pointer type [-Wincompatible-pointer-types]
       >   242 |     g_timeout_add_seconds (1, _timeout_cb, NULL);
       >       |                               ^~~~~~~~~~~
       >       |                               |
       >       |                               gboolean (*)(void) {aka int (*)(void)}
       > /nix/store/j359ndglk11v5j47ra66lc1vxlk2dbjw-glib-2.86.3-dev/include/glib-2.0/glib/gmain.h:949:54: note: expected 'GSourceFunc' {aka 'int (*)(void *)'} but argument is of type 'gboolean (*)(void)' {aka 'int (*)(void)'}
       >   949 |                                      GSourceFunc     function,
       >       |                                      ~~~~~~~~~~~~~~~~^~~~~~~~
       > dee-tool.c:207:1: note: '_timeout_cb' declared here
       >   207 | _timeout_cb ()
       >       | ^~~~~~~~~~~
       > /nix/store/j359ndglk11v5j47ra66lc1vxlk2dbjw-glib-2.86.3-dev/include/glib-2.0/glib/gmain.h:200:20: note: 'GSourceFunc' declared here
       >   200 | typedef gboolean (*GSourceFunc)       (gpointer user_data);
       >       |                    ^~~~~~~~~~~
       > make[2]: *** [Makefile:468: dee-tool.o] Error 1
       > make[2]: Leaving directory '/build/dee/tools'
       > make[1]: *** [Makefile:533: all-recursive] Error 1
       > make[1]: Leaving directory '/build/dee'
       > make: *** [Makefile:439: all] Error 2
       For full logs, run:
         nix log /nix/store/w2vcan2incrnad11ysbj6xj4w509mf8v-dee-unstable-2017-06-16.drv
error: Cannot build '/nix/store/gf57xfm523vm35j0xxr001fald6w6jr4-libunity-unstable-2021-02-01.drv'.
       Reason: 1 dependency failed.
       Output paths:
         /nix/store/isx9q4c8dpbippw32vpjzgymxsw9yz2m-libunity-unstable-2021-02-01
         /nix/store/vswssrm09dz6djws6a69hzmnj4spapcg-libunity-unstable-2021-02-01-dev
         /nix/store/y706fvighhg56gmmwyr8ja5cvqjbhcs1-libunity-unstable-2021-02-01-py
error: Cannot build '/nix/store/2vzim0xvpgv17873p4wbw7n9gaxngac5-discord-0.0.119.drv'.
       Reason: 1 dependency failed.
       Output paths:
         /nix/store/n4li8wz4rnn3jflrjgs30k3w1iz90hrx-discord-0.0.119
22:37:16
@ghpzin:envs.netghpzin So apparently this was load-bearing:
diff --git a/pkgs/by-name/xo/xorg-server/package.nix b/pkgs/by-name/xo/xorg-server/package.nix
index 271d279dd4..dea62e4973 100644
--- a/pkgs/by-name/xo/xorg-server/package.nix
+++ b/pkgs/by-name/xo/xorg-server/package.nix
@@ -151,6 +151,11 @@
     mesa
   ];

+  hardeningDisable = [
+    "bindnow"
+    "relro"
+  ];
+
   propagatedBuildInputs = [
     dbus
     libepoxy
and should not have been removed by refactor in https://github.com/NixOS/nixpkgs/pull/446052
Makes nixos tests with xserver work again.
Was there for 10 years before that: https://github.com/NixOS/nixpkgs/commit/27b9f5d65ee452c9a1a49a2e245b2a45ee1d65ab
Probably should have had comment with "Do not remove unless properly tested, without it errors during runtime"
Will send PR tomorrow.
22:52:49
@k900:0upti.meK900H u h22:54:11
@k900:0upti.meK900 Which one is it? 22:54:15
@k900:0upti.meK900 relro should definitely not matter at least 22:54:31
@k900:0upti.meK900bindnow could be it ugh22:56:27
@k900:0upti.meK900 I wonder why it needs that and xwayland does 22:59:05
@k900:0upti.meK900 Oh wait 22:59:07
@k900:0upti.meK900 It's meson isn't it 22:59:09
@k900:0upti.meK900 It's fucking meson 22:59:13
@k900:0upti.meK900Because something something die GNU autotools22:59:41
@k900:0upti.meK900 ...can we switch xorgserver to meson 22:59:41
@ghpzin:envs.netghpzin Yes, rebuilt without "relro" tests pass.
So I guess will PR tomorrow with just "bindnow" and comment above to not remove without properly testing.
23:01:04
@k900:0upti.meK900 Does anyone want to attempt this lol 23:01:35
@k900:0upti.meK900 Or do we just let xorg users suffer 23:01:35

There are no newer messages yet.


Back to Room ListRoom Version: 6