| View previous topic :: View next topic |
| Author |
Message |
dantrell
l33t
Joined: 01 Jun 2007
Posts: 754
Location: Earth
|
 Posted: Sat Oct 05, 2019 12:41 pm Post subject: |
 |
|
| Elleni wrote: | | So I have put it here |
Fixed (and with luck that was the last one). 
_________________
Dantrell B. |
|
| Back to top |
|
 |
Elleni
Veteran
Joined: 23 May 2006
Posts: 1167
|
| Posted: Sat Oct 05, 2019 2:17 pm Post subject: |
|
|
it was. Everything related to gnome without systemd is up and running. Thanks  |
|
| Back to top |
|
|
dantrell
l33t
Joined: 01 Jun 2007
Posts: 754
Location: Earth
|
| Posted: Thu Oct 10, 2019 9:20 am Post subject: |
|
|
| Shibotto wrote: | | There's a patch upstream, but since there is not yet a stable release of Dash to Dock for 3.34 and mutter-3.34.1 will be out already patched in (probably) less than a week anyway, maybe it's not even worth integrating right now. |
GNOME 3.34.1 (beta) is now available for testing.
Nothing significant has changed since the last announcement post except for the impending End of Life (EOL) for Python 2.
Enjoy.
_________________
Dantrell B. |
|
| Back to top |
|
|
Spargeltarzan
Guru
Joined: 23 Jul 2017
Posts: 312
|
| Posted: Thu Oct 10, 2019 1:24 pm Post subject: |
|
|
| dantrell wrote: |
Nowadays there are (surprisingly so) quite a few users so I wanted to obtain a "majority vote".
2 out of 3 is good enough so sync up and have at it. 
|
Dantrell, I am sorry for the question but I am still relatively new to plasma+gnome profile so therefore I hope for your understanding. What exactly did you switch now and formerly when you asked if the users want an update?
Currently, my profile:
| Code: |
[37] dantrell-gnome:default/linux/amd64/17.1/desktop/gnome+plasma (stable) *
|
doesn't work anymore.
Tried --fetch, re-add (by switching to 3-34 and back to plasma+gnome), etc. but I still get this:
| Code: |
!!! Unable to parse profile: '/etc/portage/make.profile'
!!! ParseError: Parent 'dantrell-gnome-3-34:default/linux/amd64/17.1/desktop/gnome/3.34/extended' not found: '/var/lib/layman/dantrell-gnome/profiles/default/linux/amd64/17.1/desktop/gnome+plasma/parent'
!!! /etc/portage/make.profile is not a symlink and will probably prevent most merges.
!!! It should point into a profile within /usr/portage/profiles/
!!! (You can safely ignore this message when syncing. It's harmless.)
!!! Your current profile is invalid. If you have just changed your profile
!!! configuration, you should revert back to the previous configuration.
!!! Allowed actions are limited to --help, --info, --search, --sync, and
!!! --version.
|
Please advice 
_________________
___________________
Regards
Spargeltarzan
Notebook: Lenovo YOGA 900-13ISK: Gentoo stable amd64, GNOME systemd, KVM/QEMU
Desktop-PC: Intel Core i7-4770K, 8GB Ram, AMD Radeon R9 280X, ZFS Storage, GNOME openrc, Dantrell, Xen |
|
| Back to top |
|
|
dantrell
l33t
Joined: 01 Jun 2007
Posts: 754
Location: Earth
|
| Posted: Thu Oct 10, 2019 1:54 pm Post subject: |
|
|
| Spargeltarzan wrote: | | What exactly did you switch now and formerly when you asked if the users want an update? |
I switched the relevant references from 3-32/3.32 to 3-34/3.34.
| Spargeltarzan wrote: | | Tried --fetch, re-add (by switching to 3-34 and back to plasma+gnome), etc. but I still get this: [...] |
I can reproduce this by "de-linking" GNOME 3.34 from /etc/portage/repos.conf/* so that's where your problem is.
If you are using Layman the following should be enough:
| Code: | layman --fetch
layman --add dantrell-gnome-3-34
grep --quiet --no-messages "\[dantrell-gnome-3-34" /etc/portage/repos.conf/layman.conf && echo "OK" |
_________________
Dantrell B. |
|
| Back to top |
|
|
saboya
Guru
Joined: 28 Nov 2006
Posts: 546
Location: Brazil
|
| Posted: Sat Oct 12, 2019 1:09 pm Post subject: |
|
|
Got a sandbox violation with gnome-base/libgtop:
| Code: |
* --------------------------- ACCESS VIOLATION SUMMARY ---------------------------
* LOG FILE: "/var/log/sandbox/sandbox-4.log"
*
VERSION 1.0
FORMAT: F - Function called
FORMAT: S - Access Status
FORMAT: P - Path as passed to function
FORMAT: A - Absolute Path (not canonical)
FORMAT: R - Canonical Path
FORMAT: C - Command Line
F: fchownat
S: deny
P: /usr/bin/libgtop_server2
A: /usr/bin/libgtop_server2
R: /usr/bin/libgtop_server2
C: chown root /usr/bin/libgtop_server2
|
|
|
| Back to top |
|
|
dantrell
l33t
Joined: 01 Jun 2007
Posts: 754
Location: Earth
|
| Posted: Sun Oct 13, 2019 12:44 am Post subject: |
|
|
| saboya wrote: | | Got a sandbox violation with gnome-base/libgtop: [...] |
Sync up and you should be good to go.
| dantrell wrote: | | But it's another notch towards me forking the main tree so I can slipstream in some changes. |
There have been many times since 2015 where I have encountered an issue regarding the limitations of Portage overlays in relation to the main tree but I have always either: (1) worked around the issue or (2) fixed the issue in my personal overlay and hoped no one else encountered it elsewhere.
Unfortunately, it seems that I have reached the point where partial solutions aren't going to cut it anymore so I have started preparing for the eventuality of forking the main tree.
I want to point out though that, use of the proposed tree is completely unnecessary if you use (and continue to use) the latest GNOME release versions. Only those running older GNOME release versions (e.g. 3.14) will benefit.
That said, if I have it right that there are (currently) ~36000 ebuilds (not packages) in Gentoo, then the proposed tree will be 95% identical to the main tree with a 4.97% divergence being related to GNOME ebuilds and a 0.03% divergence being related to "hotswapped" ebuilds.
Technically, the proposed tree will not be a merger of the main tree and the project overlays but rather I will be deleting 4.97% of the main tree in addition to modifying 0.03% of it in-place (i.e. the project overlays will still be used).
Thoughts? Comments? Criticisms?
_________________
Dantrell B. |
|
| Back to top |
|
|
Shibotto
Tux's lil' helper
Joined: 19 Jun 2015
Posts: 149
Location: CET/CEST
|
| Posted: Mon Oct 21, 2019 3:58 pm Post subject: |
|
|
Sorry for the delay, life happened 
I only use the latest release of GNOME or the previous one for a brief span of time, so if I got it right I shouldn't be affected by this.
Since you asked for thoughts, I see you are currently maintaining 11 releases of GNOME and I've been wondering for a while now: what is your EOL plan (or plan in general)? From my point of view I'd take into account two key factors:
- Functionality
In short, ConsoleKit and elogind. I think it could be nice to provide both alternatives, though ConsoleKit (not 2 [but even 2 it seems, for how little it matters to us]) has been unmaintained for many years.
This is the most obvious to me, maybe there was some other core functionality switch along the way that I forgot about.
- Security
You do a great job maintaining a common up to date base for all your overlays when feasible (like we recently discussed for webkit-gtk), however the old unmaintained bits are bound to become the weak link sooner or later. I was quickly investigating 3-14 (the one I had less faith in ) and found something on evolution which apparently spans through 2.28.2. Debian has it patched for an older version btw (can't link you the exact patch because the browseable SVN of Debian is broken).
With that in mind, if it were me I'd probably consider keeping 3-22 because according to the README as of now it's the last version meeting 1), although ConsoleKit kinda conflicts with 2). Because of 2) I'd drop every other release no longer supported by GNOME or not supported by an LTS distro.
That's what I've been thinking about, although I don't want to step on the toes of anyone using their preferred release, even less I want to tell people how to do their job. It would be interesting knowing how many people are interested in older GNOME releases, so guys make a lot of noise
| dantrell wrote: | | Shibotto, we are splitting the work right? |
Of course, I'm not one bit worried of wrecking the hell out of it  |
|
| Back to top |
|
|
dantrell
l33t
Joined: 01 Jun 2007
Posts: 754
Location: Earth
|
| Posted: Mon Oct 21, 2019 6:22 pm Post subject: |
|
|
| Shibotto wrote: | | I only use the latest release of GNOME or the previous one for a brief span of time, so if I got it right I shouldn't be affected by this. |
This is correct but...
Things won't be as tightly integrated. For instance, overlays overriding the Vala eclass must fork every applicable Vala ebuild for the revised change to apply. With the proposed tree, said forking isn't necessary.
| Shibotto wrote: | | Since you asked for thoughts, I see you are currently maintaining 11 releases of GNOME and I've been wondering for a while now: what is your EOL plan (or plan in general)? |
For me, True™ EOL happens when Chromium (and by extension Google Chrome) and Firefox no longer builds under (or runs in) a particular GNOME release version.
| Shibotto wrote: | | You do a great job maintaining a common up to date base for all your overlays when feasible (like we recently discussed for webkit-gtk), however the old unmaintained bits are bound to become the weak link sooner or later. I was quickly investigating 3-14 (the one I had less faith in ) and found something on evolution which apparently spans through 2.28.2. Debian has it patched for an older version btw (can't link you the exact patch because the browseable SVN of Debian is broken). |
This is an excellent point, one that I'm pretty sure I answered somewhere at some point (but I checked the project documentation is it's not there, which is an oversight).
The short answer is that if your machine is single-user and the affected packages are not used in a web-facing manner, there is no issue.
So if you use GNOME 3.14, you probably shouldn't be using Epiphany 3.14 or Evolution 3.14 in any manner except locally.
The good news is there isn't that many packages you need to be concerned about.
Note, this will be the same case for Python 2 if I proceed with the proposed tree (i.e. there is no issue if you use Python 2 locally to ensure a clean emerge but Python 2 shouldn't be used in a web-facing manner).
| Shibotto wrote: | | With that in mind, if it were me I'd probably consider keeping 3-22 because according to the README as of now it's the last version meeting 1), although ConsoleKit kinda conflicts with 2). Because of 2) I'd drop every other release no longer supported by GNOME or not supported by an LTS distro. |
Which brings us here... even if/when True™ EOL arrives or there are vulnerable package versions you can potentially bypass the entire issue by unmasking the latest GLib (and its accompanying packages) which will most likely allow you to build the latest GLib-dependent packages ergo there is no need to drop support.
So it's possible you could use GNOME 3.14 with Epiphany 3.34 and Evolution 3.34 (in fact there are at least 2 users using an older GNOME release version this way).
I don't support this configuration out-of-the-box because things can subtly go wrong but for the most part, it works. So I can easily, for instance, create hidden profiles with more liberal mask files thereby allowing for this configuration.
Note, as further proof of concept, the main tree typically lets packages from the next GNOME release version in before a full transition takes place.
| Shibotto wrote: | | That's what I've been thinking about, although I don't want to step on the toes of anyone using their preferred release, even less I want to tell people how to do their job. It would be interesting knowing how many people are interested in older GNOME releases, so guys make a lot of noise |
I still use GNOME 3.14 and that's honestly the biggest reason why its still supported.
I included the later versions because it was trivial to do so.
_________________
Dantrell B. |
|
| Back to top |
|
|
vozhyk
n00b
Joined: 18 Nov 2018
Posts: 8
Location: Warsaw, Poland
|
| Posted: Sat Oct 26, 2019 1:55 pm Post subject: |
|
|
I've upgraded to Gnome 3.34 and hit gtk#2157. The issue doesn't appear with the same GTK version (3.24.10) on Gnome 3.32, so I went back to 3.32.
The issue on Gnome 3.34 is fixed in the gtk-3-24 branch, but there is no release yet. I've hacked together a gtk+-3.24.9999 ebuild:
| Code: | --- /var/git/layman/dantrell-gnome/x11-libs/gtk+/gtk+-3.24.12.ebuild 2019-10-16 22:29:49.401260571 +0200
+++ /var/git/local/x11-libs/gtk+/gtk+-3.24.9999.ebuild 2019-10-21 14:53:47.888176983 +0200
@@ -12,6 +12,11 @@
SLOT="3/24" # From WebKit: http://trac.webkit.org/changeset/195811
KEYWORDS="~*"
+inherit git-r3
+EGIT_REPO_URI="https://gitlab.gnome.org/GNOME/gtk.git"
+EGIT_BRANCH="gtk-3-24"
+SRC_URI=""
+
IUSE="aqua broadway cloudprint colord cups examples gtk-doc +introspection test vim-syntax wayland X xinerama"
REQUIRED_USE="
|| ( aqua wayland X )
@@ -110,6 +115,16 @@
replace-flags -O3 -O2
strip-flags
+ # gtk-update-icon-cache is installed by dev-util/gtk-update-icon-cache
+ eapply "${FILESDIR}"/${PN}-3.24.8-update-icon-cache.patch
+
+ # Fix broken autotools logic
+ eapply "${FILESDIR}"/${PN}-3.22.20-libcloudproviders-automagic.patch
+
+ # call eapply_user (implicitly) before eautoreconf
+ gnome2_src_prepare
+ eautoreconf
+
if ! use test ; then
# don't waste time building tests
strip_builddir SRC_SUBDIRS testsuite Makefile.{am,in}
@@ -125,14 +140,6 @@
strip_builddir SRC_SUBDIRS examples Makefile.{am,in}
fi
- # gtk-update-icon-cache is installed by dev-util/gtk-update-icon-cache
- eapply "${FILESDIR}"/${PN}-3.24.8-update-icon-cache.patch
-
- # Fix broken autotools logic
- eapply "${FILESDIR}"/${PN}-3.22.20-libcloudproviders-automagic.patch
-
- # call eapply_user (implicitly) before eautoreconf
- gnome2_src_prepare
eautoreconf
}
|
and installed it (with some problems - I've got the same error as in https://discourse.gnome.org/t/compiling-gtk-3-24-3-22-with-wayland-im-support-fails/901 and had to run "( cd modules/input && make )" and some "ebuild" commands manually to work around that).
Gnome 3.34 with that GTK version (EGIT_VERSION="da90d37b42e1c5f2ca5a7a010cdd2a791c39b303") works fine now. |
|
| Back to top |
|
|
saboya
Guru
Joined: 28 Nov 2006
Posts: 546
Location: Brazil
|
|
| Back to top |
|
|
dantrell
l33t
Joined: 01 Jun 2007
Posts: 754
Location: Earth
|
| Posted: Sun Oct 27, 2019 2:43 am Post subject: |
|
|
| dantrell wrote: | | This is an excellent point, one that I'm pretty sure I answered somewhere at some point (but I checked the project documentation is it's not there, which is an oversight). |
This is now covered in the project documentation.
| vozhyk wrote: | | I've upgraded to Gnome 3.34 and hit gtk#2157. |
It should be enough to backport GTK+ commit e997ef6 to 3.24.11 and 3.24.12 (which I did).
Sync up and you should be good to go.
| saboya wrote: | | Had a compile failure with net-print/cups-filters, and noticed main tree bumped the latest version to stable [...] |
Thanks for the heads up.
Stabilized.
_________________
Dantrell B. |
|
| Back to top |
|
|
Child_of_Sun_24
Guru
Joined: 28 Jul 2004
Posts: 510
|
| Posted: Sun Oct 27, 2019 6:20 pm Post subject: |
|
|
When i try to merge gnome-music-3.34.1 the following error appears:
| Code: | * Package: media-sound/gnome-music-3.34.1
* Repository: dantrell-gnome-3-34
* Maintainer: gnome@gentoo.org
* USE: abi_x86_64 amd64 elibc_glibc kernel_linux python_single_target_python3_6 python_targets_python3_6 userland_GNU
* FEATURES: network-sandbox preserve-libs sandbox userpriv usersandbox
>>> Unpacking source...
>>> Unpacking gnome-music-3.34.1.tar.xz to /var/tmp/portage/media-sound/gnome-music-3.34.1/work
>>> Source unpacked in /var/tmp/portage/media-sound/gnome-music-3.34.1/work
>>> Preparing source in /var/tmp/portage/media-sound/gnome-music-3.34.1/work/gnome-music-3.34.1 ...
* Applying gnome-music-3.34.0-loadfix.patch ...
1 out of 1 hunk FAILED -- saving rejects to file meson.build.rej
[ !! ]
* ERROR: media-sound/gnome-music-3.34.1::dantrell-gnome-3-34 failed (prepare phase):
* patch -p1 failed with /var/tmp/portage/media-sound/gnome-music-3.34.1/files/gnome-music-3.34.0-loadfix.patch
*
* Call stack:
* ebuild.sh, line 125: Called src_prepare
* environment, line 2571: Called xdg_src_prepare
* environment, line 3423: Called default
* phase-functions.sh, line 872: Called default_src_prepare
* phase-functions.sh, line 937: Called __eapi6_src_prepare
* environment, line 282: Called eapply '/var/tmp/portage/media-sound/gnome-music-3.34.1/files/gnome-music-3.34.0-loadfix.patch'
* environment, line 775: Called _eapply_patch '/var/tmp/portage/media-sound/gnome-music-3.34.1/files/gnome-music-3.34.0-loadfix.patch'
* environment, line 713: Called __helpers_die 'patch -p1 failed with /var/tmp/portage/media-sound/gnome-music-3.34.1/files/gnome-music-3.34.0-loadfix.patch'
* isolated-functions.sh, line 112: Called die
* The specific snippet of code:
* die "$@"
*
* If you need support, post the output of `emerge --info '=media-sound/gnome-music-3.34.1::dantrell-gnome-3-34'`,
* the complete build log and the output of `emerge -pqv '=media-sound/gnome-music-3.34.1::dantrell-gnome-3-34'`.
* The complete build log is located at '/var/log/portage/media-sound:gnome-music-3.34.1:20191027-181537.log'.
* For convenience, a symlink to the build log is located at '/var/tmp/portage/media-sound/gnome-music-3.34.1/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/media-sound/gnome-music-3.34.1/temp/environment'.
* Working directory: '/var/tmp/portage/media-sound/gnome-music-3.34.1/work/gnome-music-3.34.1'
* S: '/var/tmp/portage/media-sound/gnome-music-3.34.1/work/gnome-music-3.34.1' |
|
|
| Back to top |
|
|
dantrell
l33t
Joined: 01 Jun 2007
Posts: 754
Location: Earth
|
| Posted: Sun Oct 27, 2019 9:36 pm Post subject: |
|
|
| Child_of_Sun_24 wrote: | | When i try to merge gnome-music-3.34.1 the following error appears: [...] |
Sync up and you should be good to go.
_________________
Dantrell B. |
|
| Back to top |
|
|
Child_of_Sun_24
Guru
Joined: 28 Jul 2004
Posts: 510
|
| Posted: Mon Oct 28, 2019 8:27 am Post subject: |
|
|
| dantrell wrote: | | Sync up and you should be good to go. |
Thank you |
|
| Back to top |
|
|
saboya
Guru
Joined: 28 Nov 2006
Posts: 546
Location: Brazil
|
| Posted: Tue Oct 29, 2019 6:22 pm Post subject: |
|
|
>=gnome-extra/gnome-calculator-3.34.1 depends on dev-libs/libgee
| Code: |
Run-time dependency gee-0.8 found: NO (tried pkgconfig and cmake)
meson.build:28:0: ERROR: Dependency "gee-0.8" not found, tried pkgconfig and cmake
A full log can be found at /var/tmp/portage/gnome-extra/gnome-calculator-3.34.1/work/gnome-calculator-3.34.1-build/meson-logs/meson-log.txt
|
|
|
| Back to top |
|
|
dantrell
l33t
Joined: 01 Jun 2007
Posts: 754
Location: Earth
|
| Posted: Wed Oct 30, 2019 2:09 am Post subject: |
|
|
| saboya wrote: | | >=gnome-extra/gnome-calculator-3.34.1 depends on dev-libs/libgee [...] |
This issue has been corrected.
_________________
Dantrell B. |
|
| Back to top |
|
|
Child_of_Sun_24
Guru
Joined: 28 Jul 2004
Posts: 510
|
|
| Back to top |
|
|
dantrell
l33t
Joined: 01 Jun 2007
Posts: 754
Location: Earth
|
| Posted: Wed Oct 30, 2019 5:08 pm Post subject: |
|
|
| Child_of_Sun_24 wrote: | | Since today net-libs/webkit-gtk-2.26.1-r1 fails during rebuild:[...] |
Looks like this is because of ICU 65.
I figured only WebKitGTK+ <2.25.0 was affected, turns out it was more like <2.27.2. 
Anyway, sync up and you should be good to go.
_________________
Dantrell B. |
|
| Back to top |
|
|
Child_of_Sun_24
Guru
Joined: 28 Jul 2004
Posts: 510
|
| Posted: Wed Oct 30, 2019 5:13 pm Post subject: |
|
|
| dantrell wrote: | | Anyway, sync up and you should be good to go. |
Thanks |
|
| Back to top |
|
|
simonvanderveldt
Tux's lil' helper
Joined: 26 Jan 2016
Posts: 125
|
| Posted: Sat Nov 02, 2019 11:02 am Post subject: |
|
|
I'm having some issues with the lockscreen, would like to check if they are upstream issues or not. If the lockscreen is activated after a timeout (this can be from the desktop or from GDM when keeping it at the login prompt for a while) there's no way to get to the username/password entry with the keyboard (using enter or escape or by starting to type the password) anymore, the only way I've been able to login again is by dragging the fullscreen image + time display (no clue what to call it) from the bottom to the top.
Oddly enough the keyboard still works when locking the screen manually using the keyboard shortcut.
I'm on gnome-base/gdm-3.32.0-r4 (assuming the lockscreen is provided by GDM).
[edit] And ran into something else as well: I got an update to media-libs/gegl-0.4.18::dantrell-gnome, but it depends on media-libs/libnsgif which has no stable version at the moment and that has a dependency on ">=dev-util/netsurf-buildsystem-1.7-r1" which is also not stable at the moment. |
|
| Back to top |
|
|
dantrell
l33t
Joined: 01 Jun 2007
Posts: 754
Location: Earth
|
| Posted: Sun Nov 03, 2019 1:50 am Post subject: |
|
|
| simonvanderveldt wrote: | I'm having some issues with the lockscreen, would like to check if they are upstream issues or not. If the lockscreen is activated after a timeout (this can be from the desktop or from GDM when keeping it at the login prompt for a while) there's no way to get to the username/password entry with the keyboard (using enter or escape or by starting to type the password) anymore, the only way I've been able to login again is by dragging the fullscreen image + time display (no clue what to call it) from the bottom to the top.
Oddly enough the keyboard still works when locking the screen manually using the keyboard shortcut.
I'm on gnome-base/gdm-3.32.0-r4 (assuming the lockscreen is provided by GDM). |
I'm not quite sure where the issue is but the two packages you want to look at are GDM and GNOME Shell.
To rule out my patchset you probably want to build GNOME Shell with USE="vanilla-screen" which seems to be the only QoL patch tangibly related. Of course, all that patch does is use the "Blank Screen" time as the idle delay (but you never know).
| simonvanderveldt wrote: | | [edit] And ran into something else as well: I got an update to media-libs/gegl-0.4.18::dantrell-gnome, but it depends on media-libs/libnsgif which has no stable version at the moment and that has a dependency on ">=dev-util/netsurf-buildsystem-1.7-r1" which is also not stable at the moment. |
Sync up and you should be good to go.
| dantrell wrote: | | This is now covered in the project documentation. |
In other news, I have started preliminary documentation of the packages that users should watch out for even if they are up-to-date:
- Evolution
- GNOME Online Accounts
- GVfs
- WebKitGTK+
- GNOME Web (codename: Epiphany)
_________________
Dantrell B. |
|
| Back to top |
|
|
simonvanderveldt
Tux's lil' helper
Joined: 26 Jan 2016
Posts: 125
|
| Posted: Mon Nov 04, 2019 11:05 pm Post subject: |
|
|
| dantrell wrote: | | simonvanderveldt wrote: | I'm having some issues with the lockscreen, would like to check if they are upstream issues or not. If the lockscreen is activated after a timeout (this can be from the desktop or from GDM when keeping it at the login prompt for a while) there's no way to get to the username/password entry with the keyboard (using enter or escape or by starting to type the password) anymore, the only way I've been able to login again is by dragging the fullscreen image + time display (no clue what to call it) from the bottom to the top.
Oddly enough the keyboard still works when locking the screen manually using the keyboard shortcut.
I'm on gnome-base/gdm-3.32.0-r4 (assuming the lockscreen is provided by GDM). |
I'm not quite sure where the issue is but the two packages you want to look at are GDM and GNOME Shell.
To rule out my patchset you probably want to build GNOME Shell with USE="vanilla-screen" which seems to be the only QoL patch tangibly related. Of course, all that patch does is use the "Blank Screen" time as the idle delay (but you never know). |
Thanks for the info. I've compiled gnome-shell with USE="vanilla-screen" and now it's working as expected. The only other thing that seems to have changed is that when manually locking the screen it blanks immediately which it didn't do before I believe.
| dantrell wrote: | | simonvanderveldt wrote: | | [edit] And ran into something else as well: I got an update to media-libs/gegl-0.4.18::dantrell-gnome, but it depends on media-libs/libnsgif which has no stable version at the moment and that has a dependency on ">=dev-util/netsurf-buildsystem-1.7-r1" which is also not stable at the moment. |
Sync up and you should be good to go.
|
All working now, thanks! |
|
| Back to top |
|
|
saboya
Guru
Joined: 28 Nov 2006
Posts: 546
Location: Brazil
|
| Posted: Mon Nov 04, 2019 11:50 pm Post subject: |
|
|
| I had a weird error with gnome-control-center. It wasn't launching due to missing libhandy, even though it was installed. I re-emerged it and was solved, so I have no idea what happened there. |
|
| Back to top |
|
|
dantrell
l33t
Joined: 01 Jun 2007
Posts: 754
Location: Earth
|
| Posted: Thu Nov 07, 2019 2:26 am Post subject: |
|
|
| simonvanderveldt wrote: | | Thanks for the info. I've compiled gnome-shell with USE="vanilla-screen" and now it's working as expected. The only other thing that seems to have changed is that when manually locking the screen it blanks immediately which it didn't do before I believe. |
A bit odd since that QoL patch has been around since the 3.14 series but not completely unexpected since things change.
It's possible the patch should be excluded from for 3.32+ but we'll see.
| saboya wrote: | | I had a weird error with gnome-control-center. It wasn't launching due to missing libhandy, even though it was installed. I re-emerged it and was solved, so I have no idea what happened there. |
Err, which package did you re-emerge?
_________________
Dantrell B. |
|
| Back to top |
|
|
|
Unsupported Software
