Closed issue by gc-user on void-packages repository

https://github.com/void-linux/void-packages/issues/53073

Description:
### Is this a new report?

Yes

### System Info

Void 6.6.60_1 x86_64 GenuineIntel uptodate hold rrmDDDDDDDDFFFFFFFFF

### Package(s) Affected

xfce4-session-4.18.4_1.x86_64.xbps

### Does a report exist for this bug with the project's home (upstream) and/or another distro?

Yes, [here}(https://gitlab.xfce.org/xfce/xfce4-session/-/issues/200). But it seems to be a "building issue" of this package rather than a "code issue" of the package.

At first and for a long time, I thought this to be a problem with the code of v4.18.4 of this package.

As this issue doesn't occur at every boot and I haven't found a way to make it show up reliably / at will, this issue is hard to bisect / debug. One can never be sure if the issue doesn't occur because "it was not that boot" or because "the code is fine".

After months of just using v4.18.3, I recently went back to v4.18.4 and tried to bisect the issue from source, without success, i.e., I couldn't find a bad commit, i.e. the issue never occurred when compiling from source via make.

Therefore I compiled it via xbps-src. This self-compiled xbps-package seems not to have this issue, either.

It is thus my conclusion that something when wrong when the xbps-package that is available on the voidlinux mirrors was built - either in the build process itself or because a particular version of some dependency at the time of the build of xfce4-session v4.18.4 had an issue which wasn't present anymore at the time I built the package myself, months later.

Now, as I have the package already built and installed, there would be no need to re-build on the voidlinux side from my part if no one else encountered this issue (as there seems to be no other issue report), and the issue will resolve itself once v4.20 is released, but I still wanted to report this issue. just in case. Also, other packages that were built around the same time / with the same (unknown) issue causing dependency version might be affected in some (other?) way.

### Expected behaviour

Since updating this package from v4.18.3 to v4.18.4, I often got asked for my password when starting a chrome-based browser. Apparently, in those instances, gnome-keyring was not unlocked at login. Downgrading to v4.18.3 made this issue go away.

### Actual behaviour

gnome-keyring should be unlocked automatically at login and thus chrome-based browsers should never have to ask for a password at start.

### Steps to reproduce

Note:

As stated above, this issue is hard to test for, as it does not occur at every boot. It might even need a shutdown before boot (not just a reboot) or even having the system totally drained of any voltage (except for the bios battery) - because that's what my system does overnight, as my laptop has all batteries disconnected / removed, as I predominantly use it in desktop mode.

1. Install xfce4.session v4.18.4 from voidlinux mirror.
2. Reboot / shutdown & boot. This step might have to be done several time until the issue occurs.
3. Start chrome-based browser and notice to get asked for password. Alternatively, use seahorse (or some other method) to check whether gnome-keyring was unlocked at login.

4. Build xfce-session v4.18.4 using xbps-src and install that package instead of the one from the voidlinux mirrors.
5. Notice that gnome-keyring apparently always gets unlocked at login every time, just as it does / did with v4.18.3.