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.

Oh wait, my system hangs on startup after reboot.

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

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

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.

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

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.

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).

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

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.

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

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

@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:

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

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?

I've tried the solution posted by @d0nj0w :

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.

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

Hi guys,

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

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.

@moriel5 : I did the procedure you wrote about:

@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.

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.

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?

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

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

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

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

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

@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):

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

In T10302#196701, @toudi wrote:

sorry for creating a duplicate task earlier.

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.

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)

sorry for creating a duplicate task earlier.

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.

Thanks for providing a lot of info, but this problem should be resolved with the mesalib update. See main task for more details.

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.

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.

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?

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.

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.

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.

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).

Also, on Discord's Github it seems they finally started work on using newer Electron version, so hopefully they will update it in their client soon, and it might fix some of the issues.

we really can't do anything regarding discord, we are allowed to ship it but not modify anything on it

Yay!

What is resolution of video you experience crash?

I tried YT video with 720p resolution, played ok. Need more info reproducing the issue.

• What is resolution of video you experience crash?
• is this DRM enabled video maybe?
• link to the video might help

I'll be looking into it
Edit:

I only looked at this briefly, but it seems that all of the addon stuff in /usr/lib/kodi is not present in the .eopkg (and thus is not installed; they're not in /usr/lib64, either), though they appear in the pspec file. This is the first time I've seen that happen, so I don't know more than that.

I have this issue in at least a couple of machines. These are the specs of one of them:

Please create a separate task for gnome-control-center issue so I can close this one. Pitivi should be working now but only minimally tested.

In T10274#196122, @algent wrote:

This is blocked by T2325

This is blocked by T2325

bruce, I may have auditioned mailspring before the last 2 updates. so trying it again in realtime.

Okay, tested against Lenovo w/newer AMD, 2014 dual core Intel/HP, and 7th gen Intel/Nvidia combo. Mailspring runs fine on all my configurations.

@brucehankins older intel quad core with mt 430 and MSI board. First thing I thought of every time blank, black Mailspring launched unusable was "theming." (Qogir Darl and Korla on Budgie). I wonder if @raenk shares any of these similar variables?

Mailspring 1.10.3-41 has no issues on my laptop. What hardware are you using?

can confirm what raenk said. complete blackout when I auditioned email clients this week. terminal threw a lot of errors. launches from menu black, launches from terminal black. unusable. so uninstalled. if bypass works then disregard, I only posted to say I could replicate OP's problem.

I don't have the exact errors (log) right now as I have downgraded it. But, executing it from CLI, I do remember a bunch of complaints regarding GPU.
In my case, the app simply didn't show. It does execute because the tray icon is there, although not visible (empty space). But I can right click on it and get the options and can quit it from there.

Hmm, I could get it to work by passing the --disable-gpu argument, so it might be related to this fix: https://github.com/Foundry376/Mailspring/commit/a476c230890001ffb11be65e6071bc8985a8ad42

Will this thing ever be able to work again in the future?

This is a Discord issue, sadly. It's been a problem for years at this point, with nothing done about it. There are reports of it across various distros, such as this one.

I also have those crashes, at least since December last year, probably even longer. Also using a USB Headset.
The Flatpak version is also my solution at the moment.

Could you see if it crashes when you are using speakers instead of this USB headset?

Wired USB headset, so not Bluetooth. I did not move to experimental. Crashing started after an update but I don't remember which one as I kept procrastinating on reporting the bug. Until I uninstalled it about a week ago, I was fully up to date according to EOPkg. I'm running the flatpak of it now and it doesn't crash even watching several hour long streams with voice chatting, so I don't think it's strictly a hardware issue.

Could you give more info? Are you using Bluetooth? Did you move to experimental pipewire? Probably not a problem, but what GPU do you have? Are you fully updated?

Thank you for looking into this.

Yes, same here, nothing Happens.