GNOME Calendar is working for me on Budgie, fully updated (on Unstable). Are you on the Stable repository (eopkg lr)? If so it might be something that will be fixed for you on next sync (currently scheduled for Tuesday).

Solus [active]

https://mirrors.rit.edu/solus/packages/shannon/eopkg-index.xml.xz

It used to work but must have broke on the last update or so. My Solus is fully up to date using the above repo which I guess is stable. Also on Budgie.

It is also useful to do sudo eopkg check when an app fails, and do sudo eopkg it --reinstall {appname} if any shows up as broken.

I can confirm that GNOME Calendar works as expected (not very well, however that is due to GNOME devs' stance in regards to libadwaita and GTK4) here, and I am on a fully updated build here with the Shannon channel as well.

Now this is quite a shot in the dark, but somebody on the forums tracked their issues back to the mesalib package. Could you try if sudo eopkg it --reinstall mesalib (probably best followed by a restart) fixes this issue for you?

sudo eopkg check found 1 broken ttl font package which I fixed. Also tried the mesalib suggestion but still the same issue. I can confirm this fault also exists on my other laptop of a different brand that has a fairly recent new install of Solus. I will see if it gets fixed on some update.

I use the Gnome version of Solus and this looks much like the issue I had. Mesalib 22.0.4 is broken. In my case it does not only effect gnome-calendar. It also crashes gnome-control-center and gnome-extensions on startup. Which is a hug pain point to me.

See the release notes of version 22.0.5, where it states: "Bugs fixed : Signal 6 (Aborted) when opening GTK3 applications" (https://docs.mesa3d.org/relnotes/22.0.5.html). My workaround is to downgrade the mesalib package to version 21.3.8-172-1-x86_64 (or anything below 22.0.4). Unfortunately there's no way (I know of ) to downgrade a single package. So I did this :

# Get the history nr where mesalib was updated
eopkg hs
# Downgrade to the "snapshot" befor the update
sudo eopkg hs -t <history nr. - 1>
#Update all packages except mesalib
sudo eopkg up -x mesalib --ignore-dependency

Ultimately this can only be fixed if someone upgrade the package to at least version 22.0.5. Would be much appreciated from my side.

sorry for creating a duplicate task earlier.

I can report that on one machine the gnome-calendar works, but on the second one it doesn't. there are two differences. the first machine (the one that still segfaults gnome-calendar) has a builtin intel gpu and has very long solus installation (has been on the machine for something like 3 years or so - though I don't know if that's significant). The one that has it working has got ryzen apu (so a different graphics card and I installed solus just two days ago). The reason I mention graphics card is that in my original bug report when I installed debug symbols the last line that had appeared there was:

0x00007fffc1cf14f7 in ?? () from /usr/lib64/dri/iris_dri.so

In T10302#196678, @dms wrote:

Still getting the same seg fault and now running on the updated mesalib 22.0.5. For info I do not have the 32 bit version installed.

gnome-calendar

(gnome-calendar:1410): GLib-GObject-WARNING **: 20:13:55.963: ../gobject/gsignal.c:2510: signal 'size-allocate' is invalid for instance '0x56516b130360' of type 'GcalWindow'
Segmentation fault (core dumped)

Can confirm, still the same segfault error. With gnome-control-center, too.

Some further info. This fault occurs on both my laptops with built in intel GPU. One is an old install of Solus of a few years rolling updates. My second is a fresh install a few months ago due to a SSD drive upgrade. Both are fully updated. Both the same fault.

My desktop PC uses an AMD PCI-E GPU and this is fine. No faults. Again fully updated. So I do not think age of install has anything to do with this issue. My desktop does run in 1920x1080 mode were-as both laptops are a lower resolution being older so the screen area is smaller...

In T10302#196701, @toudi wrote:

sorry for creating a duplicate task earlier.

Absolutely no need to apologize! The original task was already closed by the time you created yours (I think) and it was just merged into this one to keep everything together in one place. Too bad the issue wasn't fixed by mesalib though.

So it seems like this might be an Intel GPU-exclusive bug. Do you also use an Intel GPU @d0nj0w?

Confirmed, Intel Core i5 2500K with integrated HD 3000 graphics.

@d0nj0w: If you're up for it, and since I saw you know how to roll back updates and so on, can you try and see if it works for you with the following two updated packages (have to link them from my Google Drive because I don't want to push the changes just yet, in case it turns out to be for nothing):

[LINK REDACTED, Doesn't work]
(download to a folder and install with sudo eopkg it *.eopkg)

If they don't work, just sudo eopkg it --reinstall mesalib libxcb to change back to the current version of those packages.

Hm,

those 2 packages depend on glibc Release 78. But the newest version in the standard repository is 77.

Sorry, seems I accidentally built them against the Unstable repo. Will update them this evening when I get to my PC.

Absolutely no need to apologize ;-). Would have loved to build the package on my own if my packaging skills were ... well existent.

@d0nj0w Okay, updated the packages under the original link. Now they're actually compatible with the stable repository ^^

Hi @Staudey , intalled the package this morning. Unfortunatly with no luck, the error is still present. Same error message.

maybe we should install each of the dependencies of gnome-calendar debugging symbols and then we could run it with gdb and see where the code explodes ? how could we generate a list of such debug package names?

I had unfortunately missed last week's sync on my laptop (my previous report was from my desktop, where I am using an AMD dGPU, and I did not have time to test until now), however I did not install the .eopkg from the Googler Drive link.

After updating Solus last night, I had tested GNOME Calendar launching on my laptop (IdeaPad 300-15ISK, Intel i5-6200U), and there are no issues whatsoever.

Those of you with issues, can you please run eopkg check | grep Broken (you may need to use sudo, some packages don't show up if I do not do so)? Since it may simply be due to a broken package (not necessarily mesalib). I believe I had issues launching GNOME Calendar a few weeks ago (I fail to remember on which device) due to one of the GNOME core packages being broken (also GNOME Control Center failed to launch then, until I force reinstalled the offending package, and after everything was back to normal, I removed GNOME Control Center, since Budgie Control Center was already installed without me noticing until then).

Unrelated, however if there is no replacement, I'd like to see a Budgie Calendar fork, due to the latest GNOME Calendar not respecting the system theme (as expected of a GTK4/libadwaita app), and being far more sluggish (again, expected) (I tried to package the last version before these changes, however this proved to be futile, due to to one of the dependencies needing to be older than what is in the Solus repositories).

@moriel5 If you want to see something like a Budgie Calendar, you would need to report it at Budgie's bugtracker, not here.
Also, they did run sudo eopkg check already, this problem is not due to broken packages. But it really is weird that on your Intel machine it is working.
Could it be that on newer Intel graphics using "Iris" driver (Broadwell 5th-gen and up) it works, but this bug only concerns the old i915 driver? Maybe Mesa update to 22.0.5 fixed it for newer processors but not the older? If that is true, then switching to "Crocus" driver on older processors would fix it, as it uses newer driver code.

@moriel5 : I did the procedure you wrote about:

sudo eopkg check | grep Broken
Checking integrity of pysolfc-cardsets                               Broken

so doesn't seem to be the issue

as for gnome-calendar not being dark, you need to set it in gnome-control-center (as opposed to budgie-control-center). the calendar still won't match the system dark theme but at least it will be dark ;-) as I understand it, it has something to do with the fact that gnome 42 completely blocked user themes.

Just for reference, I'm pasting info about my system here:

grep 'model name' /proc/cpuinfo  | head -1
model name	: Intel(R) Core(TM) i3-10100 CPU @ 3.60GHz

lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation CometLake-S GT2 [UHD Graphics 630] (rev 03)

lsmod | grep "kms\|drm"
drm_vram_helper        24576  1 vboxvideo
drm_ttm_helper         16384  2 drm_vram_helper,vboxvideo
ttm                    77824  3 drm_vram_helper,drm_ttm_helper,i915
drm_kms_helper        319488  3 drm_vram_helper,vboxvideo,i915
syscopyarea            16384  1 drm_kms_helper
sysfillrect            16384  1 drm_kms_helper
sysimgblt              16384  1 drm_kms_helper
fb_sys_fops            16384  1 drm_kms_helper
cec                    61440  2 drm_kms_helper,i915
drm                   651264  12 drm_kms_helper,drm_vram_helper,vboxvideo,drm_ttm_helper,i915,ttm

glxinfo | grep -i "vendor\|rendering"
direct rendering: Yes
server glx vendor string: SGI
client glx vendor string: Mesa Project and SGI
    Vendor: Intel (0x8086)
OpenGL vendor string: Intel


grep LoadModule /var/log/Xorg.0.log
[     2.675] (II) LoadModule: "glx"
[     2.694] (II) LoadModule: "modesetting"
[     2.699] (II) LoadModule: "fbdev"
[     2.700] (II) LoadModule: "vesa"
[     2.707] (II) LoadModule: "fbdevhw"
[     2.708] (II) LoadModule: "glamoregl"
[     3.123] (II) LoadModule: "fb"
[     3.308] (II) LoadModule: "libinput"

and again, last lines from the gdb run:

gdb gnome-calendar
Reading symbols from gnome-calendar...
Reading symbols from /usr/lib64/debug/.build-id/7d/5cabfcbfa0e08263fbdd767ec1330902b0acd8.debug...
(gdb) run
( ... )
Thread 1 "gnome-calendar" received signal SIGSEGV, Segmentation fault.
0x00007fffc1cf15b7 in ?? () from /usr/lib64/dri/iris_dri.so

I have then installed dbginfo for mesalib (sudo eopkg it mesalib-dbginfo) and rebooted the machine, however it still doesn't show me what function is exploding

In T10302#196719, @Jacek wrote:

@moriel5 If you want to see something like a Budgie Calendar, you would need to report it at Budgie's bugtracker, not here.

True, I had simply pointed this out.

Also, they did run sudo eopkg check already, this problem is not due to broken packages. But it really is weird that on your Intel machine it is working.
Could it be that on newer Intel graphics using "Iris" driver (Broadwell 5th-gen and up) it works, but this bug only concerns the old i915 driver? Maybe Mesa update to 22.0.5 fixed it for newer processors but not the older? If that is true, then switching to "Crocus" driver on older processors would fix it, as it uses newer driver code.

That is certainly possible, and would be backed up by the fact that it runs without any issues on my sister's BayTrail-laptop, which relies on Crocus.

In T10302#196728, @toudi wrote:

@moriel5 : I did the procedure you wrote about:

sudo eopkg check | grep Broken
Checking integrity of pysolfc-cardsets                               Broken

so doesn't seem to be the issue

Hmm... It would certainly seem like that.

as for gnome-calendar not being dark, you need to set it in gnome-control-center (as opposed to budgie-control-center). the calendar still won't match the system dark theme but at least it will be dark ;-) as I understand it, it has something to do with the fact that gnome 42 completely blocked user themes.

I'm not a dark theme user, however I use the Arc theme that used to be the default on Linux, and yes, it is due to GNOME devs trying to pull an Apple (you the user do not get to choose what is enjoyable to you, only we, the devs, get to choose for you).

Just for reference, I'm pasting info about my system here:

grep 'model name' /proc/cpuinfo  | head -1
model name	: Intel(R) Core(TM) i3-10100 CPU @ 3.60GHz

lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation CometLake-S GT2 [UHD Graphics 630] (rev 03)

lsmod | grep "kms\|drm"
drm_vram_helper        24576  1 vboxvideo
drm_ttm_helper         16384  2 drm_vram_helper,vboxvideo
ttm                    77824  3 drm_vram_helper,drm_ttm_helper,i915
drm_kms_helper        319488  3 drm_vram_helper,vboxvideo,i915
syscopyarea            16384  1 drm_kms_helper
sysfillrect            16384  1 drm_kms_helper
sysimgblt              16384  1 drm_kms_helper
fb_sys_fops            16384  1 drm_kms_helper
cec                    61440  2 drm_kms_helper,i915
drm                   651264  12 drm_kms_helper,drm_vram_helper,vboxvideo,drm_ttm_helper,i915,ttm

glxinfo | grep -i "vendor\|rendering"
direct rendering: Yes
server glx vendor string: SGI
client glx vendor string: Mesa Project and SGI
    Vendor: Intel (0x8086)
OpenGL vendor string: Intel


grep LoadModule /var/log/Xorg.0.log
[     2.675] (II) LoadModule: "glx"
[     2.694] (II) LoadModule: "modesetting"
[     2.699] (II) LoadModule: "fbdev"
[     2.700] (II) LoadModule: "vesa"
[     2.707] (II) LoadModule: "fbdevhw"
[     2.708] (II) LoadModule: "glamoregl"
[     3.123] (II) LoadModule: "fb"
[     3.308] (II) LoadModule: "libinput"

and again, last lines from the gdb run:

gdb gnome-calendar
Reading symbols from gnome-calendar...
Reading symbols from /usr/lib64/debug/.build-id/7d/5cabfcbfa0e08263fbdd767ec1330902b0acd8.debug...
(gdb) run
( ... )
Thread 1 "gnome-calendar" received signal SIGSEGV, Segmentation fault.
0x00007fffc1cf15b7 in ?? () from /usr/lib64/dri/iris_dri.so

I have then installed dbginfo for mesalib (sudo eopkg it mesalib-dbginfo) and rebooted the machine, however it still doesn't show me what function is exploding

Try using strace, although the waterfall of information, of which only the end should be important, may confuse you (I barely understand any of it myself, not yet having learned how code of that level is constructed).

Hi guys,

sorry for not having reported such a long time. But, I resumed my investigation today and may have found something. @Jacek said

In T10302#196719, @Jacek wrote:

Could it be that on newer Intel graphics using "Iris" driver (Broadwell 5th-gen and up) it works, but this bug only concerns the old i915 driver? Maybe Mesa update to 22.0.5 fixed it for newer processors but not the older?

I found that very interesting and tried some of the mesa parameters for the userspace driver like

MESA_LOADER_DRIVER_OVERRIDE=iris gnome-control-center

Surprisingly this gives me a running gnome-control-center and no segfault (no matter if I put "iris" or some random other text there). So I checked the mesa driver folder befor

ls /usr/lib64/dri/

i830_dri.so            kms_swrast_dri.so      r200_dri.so            radeon_dri.so          virtio_gpu_dri.so
i915_dri.so            nouveau_dri.so         r300_dri.so            radeonsi_dri.so        vmwgfx_dri.so
i965_dri.so            nouveau_drv_video.so   r600_dri.so            radeonsi_drv_video.so  
iris_dri.so            nouveau_vieux_dri.so   r600_drv_video.so      swrast_dri.so

and after the libmesa update

ls /usr/lib64/dri/

crocus_dri.so          nouveau_dri.so         r600_dri.so            radeonsi_drv_video.so  vmwgfx_dri.so
iris_dri.so            nouveau_drv_video.so   r600_drv_video.so      swrast_dri.so          
kms_swrast_dri.so      r300_dri.so            radeonsi_dri.so        virtio_gpu_dri.so

Looks like the old i915, i965, ... drivers have been deleted or better replaced by crocus_dri.so. And guess what gives me the segfault again

MESA_LOADER_DRIVER_OVERRIDE=crocus gnome-control-center

So crocus doesn't work for older Intel integrated GPUs like my HD3000 obviously. But I'm running out of ideas what would be the right fix or if there's any.

Well, the solution is to build i915 again for now on Solus side, and report this issue upstream, on Mesa or gnome calendar bugtracker.

In T10302#196781, @d0nj0w wrote:

Hi guys,

sorry for not having reported such a long time. But, I resumed my investigation today and may have found something. @Jacek said

In T10302#196719, @Jacek wrote:

Could it be that on newer Intel graphics using "Iris" driver (Broadwell 5th-gen and up) it works, but this bug only concerns the old i915 driver? Maybe Mesa update to 22.0.5 fixed it for newer processors but not the older?

I found that very interesting and tried some of the mesa parameters for the userspace driver like

MESA_LOADER_DRIVER_OVERRIDE=iris gnome-control-center

Surprisingly this gives me a running gnome-control-center and no segfault (no matter if I put "iris" or some random other text there). So I checked the mesa driver folder befor

ls /usr/lib64/dri/

i830_dri.so            kms_swrast_dri.so      r200_dri.so            radeon_dri.so          virtio_gpu_dri.so
i915_dri.so            nouveau_dri.so         r300_dri.so            radeonsi_dri.so        vmwgfx_dri.so
i965_dri.so            nouveau_drv_video.so   r600_dri.so            radeonsi_drv_video.so  
iris_dri.so            nouveau_vieux_dri.so   r600_drv_video.so      swrast_dri.so

and after the libmesa update

ls /usr/lib64/dri/

crocus_dri.so          nouveau_dri.so         r600_dri.so            radeonsi_drv_video.so  vmwgfx_dri.so
iris_dri.so            nouveau_drv_video.so   r600_drv_video.so      swrast_dri.so          
kms_swrast_dri.so      r300_dri.so            radeonsi_dri.so        virtio_gpu_dri.so

Looks like the old i915, i965, ... drivers have been deleted or better replaced by crocus_dri.so. And guess what gives me the segfault again

MESA_LOADER_DRIVER_OVERRIDE=crocus gnome-control-center

So crocus doesn't work for older Intel integrated GPUs like my HD3000 obviously. But I'm running out of ideas what would be the right fix or if there's any.

Something certainly seems wrong, as the mesalib update did not get rid of i965_dri.so for me, only i915_dri,so.

I've tried the solution posted by @d0nj0w :

MESA_LOADER_DRIVER_OVERRIDE=crocus gnome-calendar
libEGL warning: DRI2: failed to create dri screen
libEGL warning: DRI2: failed to create dri screen
libGL error: failed to create dri screen
libGL error: failed to load driver: crocus
libGL error: failed to create dri screen
libGL error: failed to load driver: crocus

(gnome-calendar:33802): GLib-GObject-WARNING **: 13:00:15.492: ../gobject/gsignal.c:2510: signal 'size-allocate' is invalid for instance '0x559794dde2c0' of type 'GcalWindow'

(no segfault, gnome-calendar shows up). However it should also be noted that as @d0nj0w has observed, I can type any random set of characters in order to get running gnome-calendar

MESA_LOADER_DRIVER_OVERRIDE=iris gnome-calendar

(gnome-calendar:33945): GLib-GObject-WARNING **: 13:00:22.765: ../gobject/gsignal.c:2510: signal 'size-allocate' is invalid for instance '0x562147430280' of type 'GcalWindow'

(segfaults); it also segfaults when I don't override the MESA_LOADER_DRIVER variable with anything.

again, I think my situation might be slightly different as I've got a tad newer intel cpu (10100) and it would seem that in my case the`iris` driver does not work.

I also noticed that I've got this file inside lib64/dri:

-rwxr-xr-x   1 root root  36M 04-08 18:13 iHD_drv_video.so

however it's very old as you can see, so maybe a leftover from one of the previous updates

So I think when it can't mach the set of characters it must be falling back to some other driver, maybe LLVMPipe? So clearly Intel video drivers, both for new GPUs and the old ones are the problem. Could any of you report that on Gnome callendar's bug tracker, or maybe even Mesa bugtracker?

Oh, forgot to mention. The fallback for me is swrast_dri.so. I can see that when I start with the debug option

MESA_LOADER_DRIVER_OVERRIDE=iris LIBGL_DEBUG=verbose gnome-control-center

I would prefer to do a test with the latest mesa version befor reporting to their bugtracker.

@d0nj0w that's hilarious but gnome-control-center works for me regardless of the parameter, I only have problems with gnome-calendar :D however, thanks to your debug flag, what I did notice was that when I launch gnome-control-center it loads up iris driver, like so:

LIBGL_DEBUG=verbose gnome-control-center

libGL: using driver i915 for 8
libGL: Can't open configuration file /etc/drirc: Nie ma takiego pliku ani katalogu.
libGL: Can't open configuration file /home/toudi/.drirc: Nie ma takiego pliku ani katalogu.
libGL: using driver i915 for 8
libGL: pci id for fd 8: 8086:9bc8, driver iris
libGL: MESA-LOADER: dlopen(/usr/lib64/dri/iris_dri.so)
libGL: Can't open configuration file /etc/drirc: Nie ma takiego pliku ani katalogu.
libGL: Can't open configuration file /home/toudi/.drirc: Nie ma takiego pliku ani katalogu.
libGL: Can't open configuration file /etc/drirc: Nie ma takiego pliku ani katalogu.
libGL: Can't open configuration file /home/toudi/.drirc: Nie ma takiego pliku ani katalogu.
libGL: Can't open configuration file /etc/drirc: Nie ma takiego pliku ani katalogu.
libGL: Can't open configuration file /home/toudi/.drirc: Nie ma takiego pliku ani katalogu.
libGL: Using DRI3 for screen 0

and when I launch gnome-calendar with a non-existing driver it falls back to swrast_dri.so as in your example:

MESA_LOADER_DRIVER_OVERRIDE=foobar LIBGL_DEBUG=verbose gnome-calendar

libGL: Can't open configuration file /etc/drirc: Nie ma takiego pliku ani katalogu.
libGL: Can't open configuration file /home/toudi/.drirc: Nie ma takiego pliku ani katalogu.
libEGL warning: MESA-LOADER: failed to open foobar: /usr/lib64/dri/foobar_dri.so: nie można otworzyć pliku obiektu dzielonego: Nie ma takiego pliku ani katalogu (search paths /usr/lib64/dri, suffix _dri)

libEGL warning: MESA-LOADER: failed to open foobar: /usr/lib64/dri/foobar_dri.so: nie można otworzyć pliku obiektu dzielonego: Nie ma takiego pliku ani katalogu (search paths /usr/lib64/dri, suffix _dri)

libGL: Can't open configuration file /etc/drirc: Nie ma takiego pliku ani katalogu.
libGL: Can't open configuration file /home/toudi/.drirc: Nie ma takiego pliku ani katalogu.
libGL: Can't open configuration file /etc/drirc: Nie ma takiego pliku ani katalogu.
libGL: Can't open configuration file /home/toudi/.drirc: Nie ma takiego pliku ani katalogu.
libGL: Can't open configuration file /etc/drirc: Nie ma takiego pliku ani katalogu.
libGL: Can't open configuration file /home/toudi/.drirc: Nie ma takiego pliku ani katalogu.
libGL: MESA-LOADER: failed to open /usr/lib64/dri/foobar_dri.so: /usr/lib64/dri/foobar_dri.so: nie można otworzyć pliku obiektu dzielonego: Nie ma takiego pliku ani katalogu
libGL error: MESA-LOADER: failed to open foobar: /usr/lib64/dri/foobar_dri.so: nie można otworzyć pliku obiektu dzielonego: Nie ma takiego pliku ani katalogu (search paths /usr/lib64/dri, suffix _dri)
libGL error: failed to load driver: foobar
libGL: MESA-LOADER: failed to open /usr/lib64/dri/foobar_dri.so: /usr/lib64/dri/foobar_dri.so: nie można otworzyć pliku obiektu dzielonego: Nie ma takiego pliku ani katalogu
libGL error: MESA-LOADER: failed to open foobar: /usr/lib64/dri/foobar_dri.so: nie można otworzyć pliku obiektu dzielonego: Nie ma takiego pliku ani katalogu (search paths /usr/lib64/dri, suffix _dri)
libGL error: failed to load driver: foobar
libGL: MESA-LOADER: dlopen(/usr/lib64/dri/swrast_dri.so)
libGL: Can't open configuration file /etc/drirc: Nie ma takiego pliku ani katalogu.
libGL: Can't open configuration file /home/toudi/.drirc: Nie ma takiego pliku ani katalogu.
libGL: Can't open configuration file /etc/drirc: Nie ma takiego pliku ani katalogu.
libGL: Can't open configuration file /home/toudi/.drirc: Nie ma takiego pliku ani katalogu.

(gnome-calendar:34749): GLib-GObject-WARNING **: 15:58:49.771: ../gobject/gsignal.c:2510: signal 'size-allocate' is invalid for instance '0x5568f78f42b0' of type 'GcalWindow'

(and after that I get gnome-calendar without segfault)

I also noticed that I've got this file inside lib64/dri:

-rwxr-xr-x 1 root root 36M 04-08 18:13 iHD_drv_video.so

This is actually provided by the intel-media-driver package, and is probably unrelated to the issue.

Can someone with the issue please try the following and see if that segfaults?

LD_PRELOAD=/usr/lib64/dri/crocus_dri.so LIBGL_DEBUG=verbose gnome-calendar

If that doesn't segfault and the logs indicate that the crocus driver is being used then the issue is most likely this one, which can be fixed in our mesalib by either trying the Arch workaround or by using these upstream patches if they can be backported to 22.0.x.

Hi @ReillyBrogan ,

thanks, this seems to be it. As gnome-calendar does work for me since the last mesalib update, I tried with gnome-control-center and it worked

$ LD_PRELOAD=/usr/lib64/dri/crocus_dri.so LIBGL_DEBUG=verbose gnome-control-center 
libGL: Can't open configuration file /etc/drirc: Datei oder Verzeichnis nicht gefunden.
libGL: Can't open configuration file /home/user/.drirc: Datei oder Verzeichnis nicht gefunden.
libGL: Can't open configuration file /etc/drirc: Datei oder Verzeichnis nicht gefunden.
libGL: Can't open configuration file /home/user/.drirc: Datei oder Verzeichnis nicht gefunden.
libGL: Can't open configuration file /etc/drirc: Datei oder Verzeichnis nicht gefunden.
libGL: Can't open configuration file /home/user/.drirc: Datei oder Verzeichnis nicht gefunden.
libGL: Can't open configuration file /etc/drirc: Datei oder Verzeichnis nicht gefunden.
libGL: Can't open configuration file /home/user/.drirc: Datei oder Verzeichnis nicht gefunden.
libGL: Can't open configuration file /etc/drirc: Datei oder Verzeichnis nicht gefunden.
libGL: Can't open configuration file /home/user/.drirc: Datei oder Verzeichnis nicht gefunden.
libGL: Can't open configuration file /etc/drirc: Datei oder Verzeichnis nicht gefunden.
libGL: Can't open configuration file /home/user/.drirc: Datei oder Verzeichnis nicht gefunden.
libGL: using driver i915 for 8
libGL: Can't open configuration file /etc/drirc: Datei oder Verzeichnis nicht gefunden.
libGL: Can't open configuration file /home/user/.drirc: Datei oder Verzeichnis nicht gefunden.
libGL: pci id for fd 8: 8086:0112, driver crocus
libGL: MESA-LOADER: dlopen(/usr/lib64/dri/crocus_dri.so)
libGL: Can't open configuration file /etc/drirc: Datei oder Verzeichnis nicht gefunden.
libGL: Can't open configuration file /home/user/.drirc: Datei oder Verzeichnis nicht gefunden.
libGL: Can't open configuration file /etc/drirc: Datei oder Verzeichnis nicht gefunden.
libGL: Can't open configuration file /home/user/.drirc: Datei oder Verzeichnis nicht gefunden.
libGL: Can't open configuration file /etc/drirc: Datei oder Verzeichnis nicht gefunden.
libGL: Can't open configuration file /home/user/.drirc: Datei oder Verzeichnis nicht gefunden.
libGL: Using DRI3 for screen 0

(gnome-control-center:2761): Gtk-CRITICAL **: 08:58:44.000: gtk_image_set_from_resource: assertion 'GTK_IS_IMAGE (image)' failed

(gnome-control-center:2761): Gtk-CRITICAL **: 08:58:44.000: gtk_image_set_pixel_size: assertion 'GTK_IS_IMAGE (image)' failed

Are you on unstable? If so I can give you a test mesalib package with the Arch workaround so we can see if that's effective at fixing it (it probably is). Upon further examination of the upstream patches for this issue I think that it's probably not a good idea to try to use them as they touch a ton of places in the mesa source code and probably wouldn't apply cleanly on our older mesa version anyway. We'll most likely just use the Arch workaround until a newer version of mesa with those patches integrated comes out (probably Mesa 22.2 or so).

If you're not already on unstable definitely don't switch to unstable right now to help us test this. There's a bunch of stack updates going on right now and it's not a good time to switch from stable to unstable.

:-) No i'm on stable. It's my daily driver. Would prefer not to do the switch If possible.

Try running this command:

sudo eopkg it https://solus.reillybrogan.com:8443/mesa-tls/mesalib-22.0.5-175-1-x86_64.eopkg

This should install a patched version of Mesa with the Arch workaround included. This package is built against stable and should be safe for you to install. Note that the next time sync happens your system will detect that mesalib is out of date and try to install the updated version from the stable repo which may or may not have the fix depending on whether the fix makes it to unstable before the next sync, this is intentional because mesalib needs to stay in sync with the rest of your system packages or you'll encounter worse issues.

Hi @ReillyBrogan,

installed the package and it works. Thanks a lot for the quick fix.

Matthias

@joebonrichie Can you add the following to the environment section of the mesalib package?

# https://gitlab.freedesktop.org/mesa/mesa/-/issues/6229
export CFLAGS="$CFLAGS -mtls-dialect=gnu"
export CXXFLAGS="$CXXFLAGS -mtls-dialect=gnu"

Oh wait, my system hangs on startup after reboot.

Run sudo eopkg it mesalib --reinstall from a tty and then reboot again. Most likely I should have had install all the other mesalib packages as well, I'll provide instructions for that tomorrow.

I can confirm that after latest update gnome-calendar works again :) thanks!

Hi guys, sorry for the late reply. My issues are fixed too since the mesalib update. Thanks alot.

Good to hear! Thanks for reporting back ?

I can also confirm that none of our devices at home had any regressions with this update.