I using Gnome as main and only DE from time when OLM 4.3 is released.
All troubles was manageable and after some love applied to Gnome it now work well.
But two scratches on my polished desktop is still bothered me.
One is tracker-miner, which constantly cauch segfault, and very-very long start of GDM.
And if tracker can be ignored, but starting time of GDM is very annoying.
I hope this problem gone with new Gnome version, but is still in cooker…
Ok, now long story short:
Delay in GDM loading is caused by awaiting response from at-spi2-registryd service, which must start by GDM.
Launch chain is: gdm → gdm-x-session → dbus-daemon → at-spi-bus-launcher → dbus-daemon (one more instance) → at-spi2-registryd
And all broke on at-spi-bus-launcher, which, if started by GDM, can’t start dbus-daemon or dbus-daemon, started by at-spi-bus-launcher, can’t start at-spi2-registryd.
But after successful login into gnome-shell, at-spi2-registryd, launched by systemd, work well.
After many hours trying I don’t know how solve this puzzle…
Now I surrended and found cheap solution: because I don’t need a11y services, then I just swithed it off by setting NO_AT_BRIDGE=1 in pam_env.conf
Thanks for being with us and using OpenMandriva.
I am familiar with the GDM problem. I myself noticed a longer loading time than, for example, in LightDM or SDDM.
However, this was not a very important problem for me because even in the case of ISO with gnome we use SDDM as the default for now.
However, I myself would like to change this to GDM, but so far it has not been achieved due some issues related to GDM.
I will try to look at the GDM problem again, maybe also I can talk again to the creators from gnome team and maybe they will give me some idea about the cause of the problem.
As for the tracker. Do you have any stackdump? It would be nice to collect a crash log along with debug symbols from GDB.
Regarding the gnome and gtk status here, it is more treated as an unwanted child. While I try to change that, I’m basically myself taking care of both gtk, gnome and other gtk related desktops.
For several years myself, I’ve basically been using gnome as the default desktop here.
It is worth adding that we are also looking for people who could help us with gtk and based desktops. Perhaps we will be able to officially release the gnome ISO for the first time. but with some extra help we could do it better and we could certainly think of other desktops like xfce and mate as well.
If you had the time, possibilities and willingness to help us with gtk and desktops, we would like to invite you to join the team.
GDM is vital part of Gnome, and SDDM can’t fully replace it.
I think I found case why at-spi2-registry don’t want to start.
It’s because at-spi-bus-launcher builded without dbus-daemon support, only with dbus-broker.
Which dbus services must be supported by launcher decided by meson at compile time, if it not defined by options.
It’s looks like meson don’t find dbus-daemon, because, if look at meson.build file in /bus/ dir in at-spi2-core sources package, there is no ‘/usr/bin/dbus-daemon’ in list of possible paths (line ~52).
And I think adding “-Ddbus_daemon=/usr/bin/dbus_daemon” to meson’s exec params in spec file can resolve this problem. A brave experiment is needed.
About problem with tracker-miner.
I think it is some problem as described there:
But if coredump still needed I try to make it. At least I can copy backtrace from system journal.
Thank you for invitating.
But I doubt I will be a valued member of the team. I can’t do maintainer’s daily job and very bad in packaging.
Anyway, I will be glad to help with issues which I can handle.
OpenMandriva does not have docs that I am aware of for building packages locally. I am not expert on this, more like the village idiot of this department. I think it would go something like this:
Account at GitHub > Not sure but one may need to also join here.
git clone what ever package you wish to work on from here.
cd to the directory git clone created. Make whatever changes you wish to try.
Build with abb build. If successful this builds SRPM and RPMS.
If successful you can make Pull Request on OMA GitHub and let 'em know in OpenMandriva Cooker matrix channel. (bridged with Telegram and Libera.chat).
(Optional) If one is going to do this you may also want an Account at OpenMandriva ABF > As I recall one has to ask on OpenMandriva Cooker matrix channel to have password approved.
Obviously there are docs for Git, GitHub, and ABF. One can also build packages and do other things with abf. There are a few other things abb can do besides abb build.
I don’t really know git commands well but I do local builds like this. What I don’t know I can look up.
Thanks for PR, I merged them.
I also built fixed at-spi and gdm packages for the cooker.
Also, on your advice, I’m trying to compile fixed tracker-miners. I added the -0o parameter, which, according to the attached error reports, fixes the problem.
If you can please test the new tracker-miners package, I hope it will fix the problem. https://abf.openmandriva.org/build_lists/227730
I test your changes to tracker-miner-3 and it fix the crashes of tracker-miner-fs-3.
Please add the same option and in tracker2-miners (GitHub - OpenMandrivaAssociation/tracker2-miners) spec-file, because it also suffer from same problem.
After updating both the rpm miner trackers, I noticed some emergency lights belonging to the extract tracker, but this was due to the MSWord file parsing module.
I also download 1341 build of cooker iso for testing and it works very well.
Further testing show next. Tracker version 3 work with out crashes.
But tracker-extract start crashing on literally each start during initial filling of db:
Thread 17 "single" received signal SIGSYS, Bad system call.
[Switching to Thread 0x7fffbcaae640 (LWP 28128)]
0x00007ffff79a57ea in fstatat64 () from /lib64/libc.so.6
(gdb) bt
#0 0x00007ffff79a57ea in fstatat64 () from /lib64/libc.so.6
#1 0x00007ffff7bf6c57 in g_key_file_load_from_fd () from /usr/lib64/libglib-2.0.so.0
#2 0x00007ffff7bf6b3a in g_key_file_load_from_file () from /usr/lib64/libglib-2.0.so.0
#3 0x00007ffff03afb3b in get_desktop_key_file () from /usr/lib64/tracker-miners-2.0/extract-modules/libextract-desktop.so
#4 0x00007ffff03af5ce in process_desktop_file () from /usr/lib64/tracker-miners-2.0/extract-modules/libextract-desktop.so
#5 0x00007ffff03af50e in tracker_extract_get_metadata () from /usr/lib64/tracker-miners-2.0/extract-modules/libextract-desktop.so
#6 0x0000000000215924 in get_file_metadata ()
#7 0x00000000002154c9 in get_metadata ()
#8 0x0000000000215d3b in single_thread_get_metadata ()
#9 0x00007ffff7c38d2f in g_thread_proxy () from /usr/lib64/libglib-2.0.so.0
#10 0x00007ffff7c6b504 in linux_pthread_proxy () from /usr/lib64/libglib-2.0.so.0
#11 0x00007ffff792ae77 in start_thread () from /lib64/libc.so.6
#12 0x00007ffff79b7b2c in clone3 () from /lib64/libc.so.6
But then it start work without any sign of crash…
And if the problem with tracker-miner-fs is clearly related to clang (accessing a global variable that was initiated in the calling function, but turned out to be equal to nullptr at the place of the call), then there seems to be something related to glib.
Hi. @bero add some fixes to tracker3-miners which should allow to collect better data in the event of another crash.
Me and bero unfortunately failed to reproduce this crash. So we hope that if it reappears, it will provide more data to successfully locate and fix the problem.
PS. do you have any way to force this crash? In other words, what steps should I take to get a crash?
Hi!
As I write early tracker3 work fine. Problem was with tracker2.
Currently I can’t check changes in rolling because I break my VM with installed OM trying switching from cooker to rolling and can’t now reinstall it from 4.3 iso image: VBox’s screen just going black after installation start…
Anyway, steps to reproduce tracker’s crashes is simple.
Ensure ~/.cache/tracker is not exists and tracker daemon say that no modules is running.
exec tracker index -f {any dir with many files}
And start looking at how the tracker-extract’s crash dumps start appearing in the log.
