Gentlemen
This message might be slightly off topic.
This message is about Gnome 3.22 and 3.24 and later versions.
Background.
I am using Fedora 25 and Fedora 26 Linux.For specific reasons, (SSD
installations) the underlying file system is btrfs. (minimized writes to the
SSD).
The good news1) With lvm, ext4, xfs Gnome behaves ideally --I have not
experienced any problems
2) With btrfs -- half the time when logging to the system, the session will
not start. Looking at it with /root, I see
gnome-session running at 99%. Its in a tight loop.
2.1) After killing the loop, if I am lucky, one chance in 5, I can get the
session to load. If zero extensions, that is, not one extension is loaded
within /usr/share/gnome-shell/extensions, or with
$HOME/.local/share-gnome-extensions/extensiions, I can run the session, log
out and log in frequently, and the action is as it is for the EXT4
installation.
3) If I move $HOME to a new partition, out from /btrfs, extensions placed in
$HOME/local/share/extensions will function correctly, and things work out OK,
as they do for the EXT4 situation.
If I move $HOME, as above, but there are extensions residing within
/usr/share/gnome-shell/extensions, I may be lucky, after a fresh boot, to log
in and things are fine. But if I log out and I try to log back in, I will not
be able to return. It is as mentioned in 2)
So, what is my "gripe" to Q/A people? Test with btrfs. For a typical
function that causes problems,
take a copy of TaskBar by zyper as the single extension (I can provide others,
but one extension is enough to do Q/A) and resolve this issue since Gnome 3.22
(or before).
Desktop users are purchasing SSD's and not rotating disks. SSD users are
advised to install Linux using btrfs to prolong the life of the SSD.
This is why:
Ext4 = write_data+meta_data+journal+(atime update) = 4 updates.
Btrfs = (copy on write) = 1 meta_data +1 data = 2 writes
For your QA people.
Test with ssd and nossd parameter
UUID=28615a60-5669-4be2-8546-93985254af07 / btrfs
subvol=root,noatime,ssd 0 0 /dev/sdc4 fedora_f26c
or
UUID=28615a60-5669-4be2-8546-93985254af07 / btrfs
subvol=root,noatime,nossd 0 0 /dev/sdc4 fedora_f26c
This bug is more than 1 year old. Last year hard disks outsold SSD's. Today it
is not so. Its time to fix up gnome-shell.
I did raise a bug report. But who takes action if there is only one individual
raising the bug?
Regards
Leslie
Leslie Satenstein, retired software engineer.
Montréal Québec, Canada
55+ years in IT as software engineer.
From: "mcatanz...@gnome.org" <mcatanz...@gnome.org>
To: Arun Raghavan <a...@accosted.net>
Cc: desktop-devel-list <desktop-devel-list@gnome.org>
Sent: Monday, July 31, 2017 8:14 AM
Subject: Re: Too many broken modules
On Mon, Jul 31, 2017 at 12:36 PM, Arun Raghavan <a...@accosted.net> wrote:
Is there some place we can look at logs of the current build? I don'thave a
jhbuild-y setup here, but I'd be happy to look at the gst-*failures.
Nope, got to ask Javier if he remembers why it failed. Sorry. We know we need
way better release infrastructure. Alternatively you could download the 3.25.4
modulesets from the release announcement and try building that.
In the past, I had to change GStreamer to build from Autotools instead of meson
because the tarballs did not contain meson.build. That's the first thing I
would check.
Michael_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
