Unfortunately I'm having some issues getting everything to run properly though.
Whilst I do get a GDM screen on startup, when logging in the GDM screen goes away, but the actual GNOME session never starts.
Now whilst trying to debug this from a second virtual terminal I noticed that if I login using the second virtual terminal before I login using GDM the GNOME session does start (after some delay).
Any idea where I can best start to look for pointers what's causing this? I have a nvidia graphics card if that matters btw.

I've added elogind to the default runlevel and this is the list of packages I have which have the elogind USE flag (all of them are built with elogind enabled):

Did it pull in an updated dev-libs/totem-pl-parser (as building against an incompatible version was how I reproduced your build failure)?

Link your new build log.

simonvanderveldt wrote:

Unfortunately I'm having some issues getting everything to run properly though.

Is sys-auth/consolekit uninstalled?

simonvanderveldt wrote:

Any idea where I can best start to look for pointers what's causing this? I have a nvidia graphics card if that matters btw.

I test by building on a recent stage 3 tarball. Everything works because everything is pristine. This makes it hard to diagnose what went wrong on individual systems that have seen use since I can't always reproduce the issues.

P.S. I also test with NVIDIA so I am reasonably certain it's not that either._________________Dantrell B.

Any idea where I can best start to look for pointers what's causing this? I have a nvidia graphics card if that matters btw.

I test by building on a recent stage 3 tarball. Everything works because everything is pristine. This makes it hard to diagnose what went wrong on individual systems that have seen use since I can't always reproduce the issues.

P.S. I also test with NVIDIA so I am reasonably certain it's not that either.

OK, np. I'll do some more digging first.

These are the log lines I think are relevant, hope it might ring a bell.

I use the elogin gnome 3.24 option.
I can't seem to figure out to how execute a script after suspend.
Atm, I'm getting around this by disabling power button from gnome power settings and bind pm-suspend to it with xbindkeys.
That's not very clean and as a result sometimes wallpaper gets corrupted during waking up(from pm-suspend).
If there is no way to execute a script with elogin, is there a cli way of notifying gnome that pc will enter suspend or a command to refresh gnome wallpaper?

These are the log lines I think are relevant, hope it might ring a bell.

Unfortunately nothing there rings a bell.

I have repeatedly spun up test installs and I just can't reproduce this issue (or the old one).

I get the feeling that something is wrong locally but I can't imagine what. Of course this isn't a very strong feeling since the timing of your issues started when elogind support was backported (although that initially affected your ConsoleKit setup).

saboya wrote:

Just reporting that I successfully migrated to the new profile successfully, just a couple rough edges:

Had to rebuild totem-pl-parser and gnome-core-libs manually before emerging @world. No big deal

Spargeltarzan wrote:

For me your 17.0 profile upgrade went fully fine too.

Glad to hear that things went well for others.

Corhonio wrote:

I can't seem to figure out to how execute a script after suspend.

For ConsoleKit implemenations, you use /etc/pm/sleep.d/ for sleep and shutdown hooks.

For elogind implemenations you use /lib/elogind/system-sleep/ for sleep hooks and /lib/elogind/system-shutdown/ for shutdown hooks.

Corhonio wrote:

Atm, I'm getting around this by disabling power button from gnome power settings and bind pm-suspend to it with xbindkeys.
That's not very clean and as a result sometimes wallpaper gets corrupted during waking up(from pm-suspend).

Wallpaper corruption when resuming from suspend is a known issue. If you experience it the solution is to enable the deprecated-background USE flag on gnome-base/gnome-shell and x11-wm/mutter (as described in the project documentation) which restores the old background code:

For elogind implemenations you use /lib/elogind/system-sleep/ for sleep hooks and /lib/elogind/system-shutdown/ for shutdown hooks.

At least for elogind 227.4 installed from the overlay ebuild, the relevant path is /usr/lib/elogind/system-sleep
For elogind 234.4-r1, which was pulled during an update as a dependency, paths are as dantrell mentioned.

dantrell wrote:

Wallpaper corruption when resuming from suspend is a known issue. If you experience it the solution is to enable the deprecated-background USE flag on gnome-base/gnome-shell and x11-wm/mutter (as described in the project documentation) which restores the old background code:

These are the log lines I think are relevant, hope it might ring a bell.

Unfortunately nothing there rings a bell.

I have repeatedly spun up test installs and I just can't reproduce this issue (or the old one).

I get the feeling that something is wrong locally but I can't imagine what. Of course this isn't a very strong feeling since the timing of your issues started when elogind support was backported (although that initially affected your ConsoleKit setup).

Thanks for checking. Hate it when these random differences appear. I'll do some more digging, if I figure out what's causing it I'll let you know.

[edit] In case someone else runs into the same issue, this might be useful, though I haven't been able to fix it yet.

These are the messages I get in gdm.log for a non-working GNOME session that I don't get for a working session.

The whole NVIDIA block except for the last line happens 4 times for the working session, but only 3 times for the failed session. So I'm starting to suspect this is an nvidia issue again, maybe similar to the one GDM/GNOME shell had when it would not work either because nvidia turn the GPU off (or something like that) because the screen was blank for a second.
Now why this doesn't happen when I login from a virtual console I don't know.

@dantrell, which version of the nvidia drivers did you use in your testing? I'm still on 381.22-r1.

Hey, just wanted to report that upgrade to 17.0 went without any problems here as well. At the same time I updated to 3.26 and elogind, and noticed that my USB sticks dont automount any more. However as I was starting to search for a solution from Google there was some talk about this in #funtoo IRC channel and someone said you had updated gvfs. And indeed after emerging the newest gvfs with added elogind support USB sticks automount and are accessable by normal users now! So thanks a lot!

Oh well yes my eyes did notice something about deprecated function (gnome.yelp?) in some mason-related package, but everything compiled and everything is working.

SOLVED: this no longer occurs as of GNOME 3.24 with elogind, as expected from dropping ConsoleKit.

Last edited by Shibotto on 2017-05-29, 03:20:17 am; edited 1 time in total

That commitment.

Corhonio wrote:

dantrell wrote:

For elogind implemenations you use /lib/elogind/system-sleep/ for sleep hooks and /lib/elogind/system-shutdown/ for shutdown hooks.

At least for elogind 227.4 installed from the overlay ebuild, the relevant path is /usr/lib/elogind/system-sleep
For elogind 234.4-r1, which was pulled during an update as a dependency, paths are as dantrell mentioned.

Good to know. I'll be noting this in the official documentation.

Does anyone actually read that thing?

Corhonio wrote:

I don't think there is a need for that, I noticed it only when I used pm-suspend with gnome 3.24

I'll leave it as-is then.

Juippisi wrote:

Is this only a rumor, or is it really happening? Gentoo's main portage is still using Gnome-3.24 and your overlay is so much ahead. Are you perhaps doing co-operation with the Gentoo crew now?

If you browse back to earlier in this thread:

Leio wrote:

I would like to note here as well, that the GNOME team would still be happy as before to integrate a proper long-term solution via an alternative logind service and API provider contribution into the main tree.
That probably means something on top of elogind, which is now available in the main tree, but someone has to do the work for GNOME stuff, as it was contributed to main tree for KDE wayland for now.

The current solution from dantrell (unless it has been significantly reworked since) can not work for wayland sessions, while elogind can. To be clear, systemd is NOT needed for elogind, that's the whole point of elogind.

dantrell wrote:

Since we are on this topic, I'd like to iterate that this project has always primarily been a stopgap measure (complete with the benefits and limitations the original code came with) until an actual answer is found. The reason why it continues to be supported is because it is quick and easy to maintain and because the proposed alternatives aren't ready (from my perspective).

Furthermore, in the case of elogind, which is presently my first choice for a long-term solution, the project seems stalled but if it is working for KDE in Gentoo then it'll work for GNOME (as it already works for GNOME in GuixSD).

I plan to duct tape something together sooner or later but if someone gets it done before me, I won't complain.

Leio wrote:

Contributions to get it in the main tree might involve just tweaking the dependencies and such as well. Though I've seen some packages needing e.g configure.ac patches to link against something in elogind instead of systemd.

simonvanderveldt wrote:

Regarding getting something to support GNOME without systemd in the main tree, that would be awesome!

Leio wrote:

Someone still needs to do the work

dantrell wrote:

Also, this time around I'm going to test integration with elogind first instead of the usual suspects, although, the GNOME team might beat me to it.

Shibotto wrote:

My curiosity just became a pressing need.

I'm not saying I won the unofficial, unsanctioned and nonagreed upon race but the cake is not a lie.

In all seriousness though, all the relevant person needs to do is reference my work. There's even a pretty detailed page in the official documentation explaining my methodology.

If that happens, I will continue maintaining the project overlays for as long as I use GNOME as the project's secondary purpose is to allow switching between GNOME release versions (and we have those sweet Quality of Life patches). _________________Dantrell B.

@dantrell, since you like to ensure a good out of the box experience it might make sense to add the colord USE flag to gnome-settings-daemon in 3.26 (And maybe also 3.24?)

Code:

The following USE changes are necessary to proceed:
(see "package.use" in the portage(5) man page for more details)
# required by gnome-base/gnome-control-center-3.26.2::dantrell-gnome-3-26
# required by net-libs/gnome-online-accounts-3.26.2::dantrell-gnome-3-26[gnome]
# required by gnome-extra/evolution-data-server-3.26.4::dantrell-gnome-3-26[gnome-online-accounts]
# required by gnome-extra/gnome-calendar-3.26.2::dantrell-gnome-3-26
# required by @selected
# required by @world (argument)
>=gnome-base/gnome-settings-daemon-3.26.2 colord

When upgrading to Gnome-3.26 the systray disappeard. Any idea how I can get it back? (I mean the part in the bottom left corner where apps like nextcloud, hplip, pulseaudio daemon are running)____________________________________
Regards

When upgrading to Gnome-3.26 the systray disappeard. Any idea how I can get it back? (I mean the part in the bottom left corner where apps like nextcloud, hplip, pulseaudio daemon are running)

That's part of 3.26, the GNOME team has decided that the systray is history, so it's gone. Normally I'd say please file a bug and let the GNOME team know but I don't think they care.
Anyway, you can install topicons plus which restores it and puts the tray in the top bar.

Last edited by simonvanderveldt on Tue Jan 16, 2018 9:17 pm; edited 1 time in total

Installed Topicon Plus (don't see any Pro Version), but it doesn't show any apps. Tried on/off and restarting gnome. On Github it states Topicon is unmaintained...____________________________________
Regards