| View previous topic :: View next topic |
| Author |
Message |
dantrell
l33t
Joined: 01 Jun 2007
Posts: 915
Location: Earth
|
 Posted: Mon Nov 28, 2016 10:52 pm Post subject: |
 |
|
| davidbrooke wrote: | | I tried the "workspaces to dock" extension on Fedora 25 live and it does work. That is about as far as I can test, without any further knowledge. |
Sounds like the issue is on my end so I'll be looking into this at a later date.
Thanks for checking.
_________________
Dantrell B. |
|
| Back to top |
|
 |
davidbrooke
Guru
Joined: 03 Jan 2015
Posts: 341
|
| Posted: Wed Nov 30, 2016 2:03 am Post subject: |
|
|
Would someone point me to info on how to resize the icons for:
Activities overview
Dash
I found alot of incomplete and older info but nothing that works.
Thanks |
|
| Back to top |
|
|
JohnLM
n00b
Joined: 20 Apr 2009
Posts: 71
Location: LATVIA
|
| Posted: Fri Dec 02, 2016 10:32 am Post subject: |
|
|
I have a weird issue with GNOME 3.20, showing all mount points from mtab in Places (/proc included), and no actual removable drives.
I've created a separate topic: Dantrell GNOME 3.20: wrong mount points in Places
to avoid causing too much noise here.
It happened after migrating to patched GNOME 3.20 from Dantrell's overlays, so I'm posting it here too.
I've no idea where to start digging. 
_________________
"I reject your reality and substitute my own" - A. Savage |
|
| Back to top |
|
|
dantrell
l33t
Joined: 01 Jun 2007
Posts: 915
Location: Earth
|
| Posted: Fri Dec 02, 2016 4:21 pm Post subject: |
|
|
| JohnLM wrote: | | I've no idea where to start digging. |
I'm pretty sure this has nothing to do with my patchset but instead with the migration from GNOME 3.6 to 3.20 (and possibly the configuration of the relevant underlying packages). Just to be sure, I double checked at least one GNOME release version and I have the correct devices listed.
I would venture to guess that if you started a completely new install that you wouldn't have this issue but that's a bit drastic so my first thought (if you migrated your ~) is to test with an empty ~ directory (either by creating a test user or temporarily renaming ~).
If that works, you have your answer. If not, you are going to have wait (unless someone else chimes in) until I get back to my workstation as I'm about to hit the road again.
_________________
Dantrell B. |
|
| Back to top |
|
|
davidbrooke
Guru
Joined: 03 Jan 2015
Posts: 341
|
| Posted: Mon Dec 05, 2016 8:46 pm Post subject: |
|
|
| dantrell wrote: | | davidbrooke wrote: | | I tried the "workspaces to dock" extension on Fedora 25 live and it does work. That is about as far as I can test, without any further knowledge. |
Sounds like the issue is on my end so I'll be looking into this at a later date.
Thanks for checking. |
I loaded Gnome 3.22 systemd and the "workspaces to dock" extension works. |
|
| Back to top |
|
|
dantrell
l33t
Joined: 01 Jun 2007
Posts: 915
Location: Earth
|
| Posted: Thu Jan 19, 2017 11:45 am Post subject: |
|
|
I haven't posted in a while but updates have continued on schedule. To keep it short, the status of GNOME in general is as follows:
- [bug] GDM sometimes requires you to login twice (cannot reproduce)
- [request (abi_x86_32)] gnome-base/gnome-keyring
and GNOME 3.22 specifically:
- [regression] GNOME Session cannot run inside Xephyr without extra work (workaround applied)
- [regression] GNOME Control Center > User Accounts will Segmentation Fault (workaround applied pending GNOME bug #773673)
That said, based on prior feedback and my own research I have categorized the Workspaces to Dock GNOME Shell extension as incompatible with the project overlays and have noted this in the official documentation.
_________________
Dantrell B. |
|
| Back to top |
|
|
simonvanderveldt
Apprentice
Joined: 26 Jan 2016
Posts: 151
|
| Posted: Thu Jan 19, 2017 8:33 pm Post subject: |
|
|
| dantrell wrote: | I haven't posted in a while but updates have continued on schedule. To keep it short, the status of GNOME in general is as follows:
- [bug] GDM sometimes requires you to login twice (cannot reproduce)
- [request (abi_x86_32)] gnome-base/gnome-keyring
and GNOME 3.22 specifically:
- [regression] GNOME Session cannot run inside Xephyr without extra work (workaround applied)
- [regression] GNOME Control Center > User Accounts will Segmentation Fault (workaround applied pending GNOME bug #773673)
That said, based on prior feedback and my own research I have categorized the Workspaces to Dock GNOME Shell extension as incompatible with the project overlays and have noted this in the official documentation. |
Should I create a bug in the Gentoo bugtracker to add abi_x86_32 to gnome-base/gnome-keyring? |
|
| Back to top |
|
|
saboya
Guru
Joined: 28 Nov 2006
Posts: 552
Location: Brazil
|
| Posted: Thu Jan 19, 2017 9:16 pm Post subject: |
|
|
| dantrell wrote: | I haven't posted in a while but updates have continued on schedule. To keep it short, the status of GNOME in general is as follows:
- [bug] GDM sometimes requires you to login twice (cannot reproduce)
|
FYI, after I disabled "Automatic suspend" in the Power menu, the issue never came up again. So probably the system thinks it has to suspend right as I login, don't know why. |
|
| Back to top |
|
|
dantrell
l33t
Joined: 01 Jun 2007
Posts: 915
Location: Earth
|
| Posted: Sun Jan 22, 2017 9:03 am Post subject: |
|
|
| simonvanderveldt wrote: | | Should I create a bug in the Gentoo bugtracker to add abi_x86_32 to gnome-base/gnome-keyring? |
You probably should since that issue is unrelated to the project. In the meanwhile, I added a couple of ebuilds that might resolve matters. To test, try:
| /etc/portage/package.keywords/gnome-keyring: | =app-crypt/gcr-3.20.0-r1 **
=gnome-base/gnome-keyring-3.20.0-r1 ** |
_________________
Dantrell B. |
|
| Back to top |
|
|
JohnLM
n00b
Joined: 20 Apr 2009
Posts: 71
Location: LATVIA
|
| Posted: Sun Jan 22, 2017 11:56 am Post subject: |
|
|
| dantrell wrote: | [...]
I would venture to guess that if you started a completely new install that you wouldn't have this issue but that's a bit drastic so my first thought (if you migrated your ~) is to test with an empty ~ directory (either by creating a test user or temporarily renaming ~).
If that works, you have your answer. [...] |
I created a new test user but still got the same behaviour.
_________________
"I reject your reality and substitute my own" - A. Savage |
|
| Back to top |
|
|
dantrell
l33t
Joined: 01 Jun 2007
Posts: 915
Location: Earth
|
| Posted: Sat Jan 28, 2017 4:19 am Post subject: |
|
|
| JohnLM wrote: | | I created a new test user but still got the same behaviour. |
Then unless it has to do with an recent OpenRC or udev change, I have no idea.
_________________
Dantrell B. |
|
| Back to top |
|
|
JohnLM
n00b
Joined: 20 Apr 2009
Posts: 71
Location: LATVIA
|
| Posted: Sun Jan 29, 2017 7:24 pm Post subject: |
|
|
| JohnLM wrote: | | I have a weird issue with GNOME 3.20, showing all mount points from mtab in Places (/proc included), and no actual removable drives.[...] |
OK, I dug a bit deeper and found it comes down to glib -- particularly -- the default GVolumeMonitor instance returned by g_volume_monitor_get() which is used by both Nemo, Nautilus and etc. It's really an "union" of multiple GVolumeMonitor instances and I wrote a little piece of code to discover the members of the union and their respective mounts and drives. For my Gentoo machine it outputs:
| Code: | vm is instance of GUnionVolumeMonitor
[0] Using GProxyVolumeMonitorGPhoto2 in union
[1] Using GDaemonVolumeMonitor in union
[2] Using GUnixVolumeMonitor in union
[0] mount Filesystem root at file:///
[1] mount shm at file:///dev/shm
[2] mount home at file:///home
[3] mount filedisk at file:///mnt/filedisk
[4] mount megadisk at file:///mnt/megadisk
[5] mount proc at file:///proc
[6] mount tmp at file:///tmp |
Exploring implementation of GUnixVolumeMonitor the "symptoms" gets explained. Firstly, its returned list of mounts (as by g_volume_monitor_get_mounts() ) doesn't filter out "system implementation" mounts (despite being able to check it). Secondly, its g_volume_monitor_get_connected_drives() is a dummy and always returns NULL, thus no unmounted volumes can be detected.
Running the same code on a Linux Mint machine (with Cinnamon) outputs: | Code: | vm is instance of GUnionVolumeMonitor
[0] Using GProxyVolumeMonitorAfc in union
[1] Using GProxyVolumeMonitorGPhoto2 in union
[2] Using GProxyVolumeMonitorMTP in union
[3] Using GDaemonVolumeMonitor in union
[4] Using GProxyVolumeMonitorUDisks2 in union
[0] mount Windows7_OS at file:///media/windisk
[0] connected drive SAMSUNG MZYLF128HCHP-000L2
[1] connected drive HL-DT-ST DVDRAM GUC0N
[2] connected drive Netac OnlyDisk |
which uses a GProxyVolumeMonitorUDisks2 instead of GUnixVolumeMonitor, and is also able to return connected drives (and unmounted volumes via them).
This reveals the symptoms, but not really the root cause.
It appears to me that GUnixVolumeMonitor may be a fallback, but why wouldn't it use GProxyVolumeMonitorUDisks2 if I have udisks installed? 
| Code: | $ equery list dev-libs/glib udisks
* Searching for glib in dev-libs ...
[I-O] [ ] dev-libs/glib-2.50.2:2/50
* Searching for udisks ...
[IP-] [ ] sys-fs/udisks-1.0.5-r1:0
[IP-] [ ] sys-fs/udisks-2.1.8:2 |
_________________
"I reject your reality and substitute my own" - A. Savage |
|
| Back to top |
|
|
JohnLM
n00b
Joined: 20 Apr 2009
Posts: 71
Location: LATVIA
|
| Posted: Mon Jan 30, 2017 6:42 am Post subject: |
|
|
Solved it! And it was embarrassingly simple -- apparently somewhere during GNOME migration gnome-base/gvfs got built with 'udisks' USE flag disabled. 
I reinstalled it with 'udisks' flag and the effect was immediate.
But thanks for looking into it! 
_________________
"I reject your reality and substitute my own" - A. Savage |
|
| Back to top |
|
|
dantrell
l33t
Joined: 01 Jun 2007
Posts: 915
Location: Earth
|
| Posted: Thu Feb 09, 2017 11:29 pm Post subject: |
|
|
Glad to hear it. 
_________________
Dantrell B. |
|
| Back to top |
|
|
Leio
Developer
Joined: 27 Feb 2003
Posts: 494
Location: Estonia
|
| Posted: Mon Feb 13, 2017 7:59 pm Post subject: |
|
|
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.
_________________
GNOME team lead; GStreamer; MIPS/ARM64 |
|
| Back to top |
|
|
dantrell
l33t
Joined: 01 Jun 2007
Posts: 915
Location: Earth
|
| Posted: Mon Feb 13, 2017 9:36 pm Post subject: |
|
|
| 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. |
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.
_________________
Dantrell B. |
|
| Back to top |
|
|
Leio
Developer
Joined: 27 Feb 2003
Posts: 494
Location: Estonia
|
| Posted: Mon Feb 13, 2017 9:47 pm Post subject: |
|
|
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.
_________________
GNOME team lead; GStreamer; MIPS/ARM64 |
|
| Back to top |
|
|
simonvanderveldt
Apprentice
Joined: 26 Jan 2016
Posts: 151
|
| Posted: Sat Feb 25, 2017 11:51 am Post subject: |
|
|
@dantrell, I've been running into this for some time now
| Code: | WARNING: One or more updates/rebuilds have been skipped due to a dependency conflict:
dev-libs/libpcre:3
(dev-libs/libpcre-8.39:3/3::gentoo, ebuild scheduled for merge) conflicts with
>=dev-libs/libpcre-8.13:3[abi_x86_32(-),abi_x86_64(-)] required by (dev-libs/glib-2.48.2:2/48::dantrell-gnome, installed)
|
It's declared here https://github.com/dantrell/gentoo-overlay-dantrell-gnome/blob/master/dev-libs/glib/glib-2.48.2.ebuild#L33 like this
| Code: | | >=dev-libs/libpcre-8.13:3[${MULTILIB_USEDEP},static-libs?] |
Now I'm not sure why this is. Could it be the >= operator doesn't work properly because both a version and a slot are declared?
Is anyone else seeing this issue?
Regarding getting something to support GNOME without systemd in the main tree, that would be awesome! |
|
| Back to top |
|
|
Leio
Developer
Joined: 27 Feb 2003
Posts: 494
Location: Estonia
|
| Posted: Wed Mar 01, 2017 2:10 am Post subject: |
|
|
| simonvanderveldt wrote: |
dev-libs/libpcre:3
(dev-libs/libpcre-8.39:3/3::gentoo, ebuild scheduled for merge) conflicts with
>=dev-libs/libpcre-8.13:3[abi_x86_32(-),abi_x86_64(-)] required by (dev-libs/glib-2.48.2:2/48::dantrell-gnome, installed)
[/code]
Now I'm not sure why this is. Could it be the >= operator doesn't work properly because both a version and a slot are declared?
Is anyone else seeing this issue? |
>= and a slot definition is rather common. It's fine as long as as a satisfying version is present in that slot, which there is.
Maybe you have abi_x86_32 on glib but not libpcre?
| simonvanderveldt wrote: | | Regarding getting something to support GNOME without systemd in the main tree, that would be awesome! |
Someone still needs to do the work
_________________
GNOME team lead; GStreamer; MIPS/ARM64 |
|
| Back to top |
|
|
simonvanderveldt
Apprentice
Joined: 26 Jan 2016
Posts: 151
|
| Posted: Sun Mar 05, 2017 2:31 pm Post subject: |
|
|
| Leio wrote: | >= and a slot definition is rather common. It's fine as long as as a satisfying version is present in that slot, which there is.
Maybe you have abi_x86_32 on glib but not libpcre? |
Sometimes things can be so simple  Somehow I lost my abi_x86_32 USE flag for libpcre, I've re-added it an everything is fine again Thanks for the pointer!
@dantrellb
I just pulled the following ebuild dev-libs/appstream-glib-0.5.19:0/8::dantrell-gnome
This gives me the following error:
| Code: |
as-compose.c: In function ‘get_appdata_filename’:
as-compose.c:256:2: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
for (guint j = 0; dirs[j] != NULL; j++) {
^
as-compose.c:256:2: note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your code
as-compose.c:257:3: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
for (guint i = 0; exts[i] != NULL; i++) {
^
|
So, it seems like something is missing regarding those ebuilds
What's the correct way of passing something like std=gnu11 anyway? The only thing I've found is this https://wiki.gentoo.org/wiki/Project:C%2B%2B/Maintaining_ABI which suggests using the flag-o-matic eclass. Is that correct? |
|
| Back to top |
|
|
dantrell
l33t
Joined: 01 Jun 2007
Posts: 915
Location: Earth
|
| Posted: Sun Mar 05, 2017 8:14 pm Post subject: |
|
|
| simonvanderveldt wrote: | | Leio wrote: | >= and a slot definition is rather common. It's fine as long as as a satisfying version is present in that slot, which there is.
Maybe you have abi_x86_32 on glib but not libpcre? |
Sometimes things can be so simple Somehow I lost my abi_x86_32 USE flag for libpcre, I've re-added it an everything is fine again Thanks for the pointer! |
I was about to say this wasn't my fault. Glad you figured it out.
| simonvanderveldt wrote: | I just pulled the following ebuild dev-libs/appstream-glib-0.5.19:0/8::dantrell-gnome
This gives me the following error:
| Code: |
as-compose.c: In function ‘get_appdata_filename’:
as-compose.c:256:2: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
for (guint j = 0; dirs[j] != NULL; j++) {
^
as-compose.c:256:2: note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your code
as-compose.c:257:3: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
for (guint i = 0; exts[i] != NULL; i++) {
^
|
So, it seems like something is missing regarding those ebuilds |
This one was my fault though.
But be fair, they picked a weird version to break (as earlier and later versions don't have this issue) and I haven't tested with <GCC 5.4.0 in a long time.
Sync up and you should be good to go.
Yep, just inherit flag-o-matic then toss append-cflags or append-cxxflags in src_configure like so.
_________________
Dantrell B. |
|
| Back to top |
|
|
simonvanderveldt
Apprentice
Joined: 26 Jan 2016
Posts: 151
|
| Posted: Mon Mar 06, 2017 1:26 pm Post subject: |
|
|
| dantrell wrote: | This one was my fault though.
But be fair, they picked a weird version to break (as earlier and later versions don't have this issue) and I haven't tested with <GCC 5.4.0 in a long time.
Sync up and you should be good to go.
Yep, just inherit flag-o-matic then toss append-cflags or append-cxxflags in src_configure like so. |
Just tried again and it's working now, thanks for the quick fix and the info on how to fix these things! |
|
| Back to top |
|
|
simonvanderveldt
Apprentice
Joined: 26 Jan 2016
Posts: 151
|
| Posted: Sat Mar 25, 2017 2:15 pm Post subject: |
|
|
Just noticed this when emerging gnome-shell 3.20, not sure if it's a problem?
| Code: | libtool: warning: '/var/tmp/portage/gnome-base/gnome-shell-3.20.4-r1/work/gnome-shell-3.20.4/src/libgnome-shell-menu.la' has not been installed in '/usr/lib64/gnome-shell'
libtool: warning: 'libgnome-shell-js.la' has not been installed in '/usr/lib64/gnome-shell'
libtool: install: /usr/lib/portage/python3.4/ebuild-helpers/xattr/install -c .libs/gnome-shell /var/tmp/portage/gnome-base/gnome-shell-3.20.4-r1/image//usr/bin/gnome-shell
libtool: warning: 'libgnome-shell-js.la' has not been installed in '/usr/lib64/gnome-shell'
|
|
|
| Back to top |
|
|
dantrell
l33t
Joined: 01 Jun 2007
Posts: 915
Location: Earth
|
| Posted: Sat Mar 25, 2017 5:34 pm Post subject: |
|
|
| simonvanderveldt wrote: | | Just noticed this when emerging gnome-shell 3.20, not sure if it's a problem? |
I believe libtool started throwing that warning for packages quite a while ago. It's a frequent occurrence and 99.99% safe to ignore. You can patch libtool if you want to suppress the warnings.
For reference, see this answer or the comments on this answer.
_________________
Dantrell B. |
|
| Back to top |
|
|
simonvanderveldt
Apprentice
Joined: 26 Jan 2016
Posts: 151
|
| Posted: Sat Mar 25, 2017 7:35 pm Post subject: |
|
|
| dantrell wrote: | | simonvanderveldt wrote: | | Just noticed this when emerging gnome-shell 3.20, not sure if it's a problem? |
I believe libtool started throwing that warning for packages quite a while ago. It's a frequent occurrence and 99.99% safe to ignore. You can patch libtool if you want to suppress the warnings.
For reference, see this answer or the comments on this answer. |
Allright, thanks for the info. Kind of annoying/useless from libtool. I'll just ignore it I guess |
|
| Back to top |
|
|
|
Unsupported Software
