2:57 p.m.
Is only my installation broken?
Do any of the (GNOME) developers run Fedora 21 actually?
Where is the menu of Evince? Its Help system refers to it ("top right
corner"), but I can't find it. Searching for it with various clicks of the
right mouse-button, I managed to freeze the GNOME Shell and get more than
one black "Minimize Maximize Move ..." popup menu.
What's the reason for other changes? GNOME Shell's "Favourites" bar at
the
left: Why do I need to press'n'hold the right mouse button now in order to
select something from the popup menu? Why is it no longer possible to
open new gnome-terminal windows but only be offered access to the single
open one? Am I really supposed to "Launch" more instances via the
"Show Details" feature? That would be odd.
3:02 p.m.
On Tue, Aug 26, 2014 at 9:57 PM, Michael Schwendt <mschwendt(a)gmail.com> wrote:
Is only my installation broken?
Do any of the (GNOME) developers run Fedora 21 actually?
Some do ...
Where is the menu of Evince? Its Help system refers to it ("top
right
corner"), but I can't find it. Searching for it with various clicks of the
right mouse-button, I managed to freeze the GNOME Shell and get more than
one black "Minimize Maximize Move ..." popup menu.
What's the reason for other changes? GNOME Shell's "Favourites" bar at
the
left: Why do I need to press'n'hold the right mouse button now in order to
select something from the popup menu?
That sounds like a bug.
Why is it no longer possible to
open new gnome-terminal windows but only be offered access to the single
open one? Am I really supposed to "Launch" more instances via the
"Show Details" feature? That would be odd.
Looks like fallout from
https://git.gnome.org/browse/gnome-shell/commit/?id=3182aba744e7d64ecf71d...
3:11 p.m.
On Tue, Aug 26, 2014 at 10:02 PM, drago01 <drago01(a)gmail.com> wrote:
On Tue, Aug 26, 2014 at 9:57 PM, Michael Schwendt
<mschwendt(a)gmail.com> wrote:
> Is only my installation broken?
>
> Do any of the (GNOME) developers run Fedora 21 actually?
Some do ...
> Where is the menu of Evince? Its Help system refers to it ("top right
> corner"), but I can't find it. Searching for it with various clicks of the
> right mouse-button, I managed to freeze the GNOME Shell and get more than
> one black "Minimize Maximize Move ..." popup menu.
>
> What's the reason for other changes? GNOME Shell's "Favourites" bar
at the
> left: Why do I need to press'n'hold the right mouse button now in order to
> select something from the popup menu?
That sounds like a bug.
> Why is it no longer possible to
> open new gnome-terminal windows but only be offered access to the single
> open one? Am I really supposed to "Launch" more instances via the
> "Show Details" feature? That would be odd.
Looks like fallout from
https://git.gnome.org/browse/gnome-shell/commit/?id=3182aba744e7d64ecf71d...
Filed https://bugzilla.gnome.org/show_bug.cgi?id=735479
8:46 a.m.
New subject: X-GNOME-SingleWindow=true
On Tue, 26 Aug 2014 22:11:23 +0200, drago01 wrote:
>> Why is it no longer possible to
>> open new gnome-terminal windows but only be offered access to the single
>> open one? Am I really supposed to "Launch" more instances via the
>> "Show Details" feature? That would be odd.
>
> Looks like fallout from
>
https://git.gnome.org/browse/gnome-shell/commit/?id=3182aba744e7d64ecf71d...
Filed https://bugzilla.gnome.org/show_bug.cgi?id=735479
Seems we (at Fedora) need to take action then and modify the .desktop
files appropriately and request the modification to be applied upstream,
too. Not all upstreams use the GNOME Shell, and not all upstreams would
learn about the needed/useful desktop file modification either.
9:06 a.m.
New subject: X-GNOME-SingleWindow=true
On Thu, 2014-08-28 at 15:46 +0200, Michael Schwendt wrote:
Seems we (at Fedora) need to take action then and modify the
.desktop
files appropriately and request the modification to be applied
upstream,
too. Not all upstreams use the GNOME Shell, and not all upstreams
would
learn about the needed/useful desktop file modification either.
The heuristic to decide whether to show the New Window button is
implemented in such a way that it's probably going to guess correctly
for non-GNOME apps. Off the top of my head, I think we assume that New
Window will work unless the app is a single-instance app using
GtkApplication (I'm not aware of any non-GNOME app that fits this bill).
These apps are supposed to provide their own New Window option in the
app menu for it to be possible to create a new window anyway, and GNOME
Terminal unfortunately named it New Terminal instead of New Window,
which confused the heuristic.
Or something like that. TL;DR: don't worry about it. Probably.
Cheers,
Michael
3:20 p.m.
On 08/26/2014 09:57 PM, Michael Schwendt wrote:
Where is the menu of Evince? Its Help system refers to it ("top
right
corner"), but I can't find it.
I filed this earlier today at
https://bugzilla.gnome.org/show_bug.cgi?id=735446
--
Kalev
4:06 a.m.
On Tue, 26 Aug 2014 22:20:39 +0200, Kalev Lember wrote:
> Where is the menu of Evince? Its Help system refers to it
("top right
> corner"), but I can't find it.
I filed this earlier today at
https://bugzilla.gnome.org/show_bug.cgi?id=735446
Ah, I see. Another case of a mass-build for both Rawhide and F21 at the
same time. Preferably, builds of upgrades enter Rawhide several days
before F21. Only that gives the minimal chance to find bugs in Rawhide
first -- unless hardly any users/developers run Rawhide.
I would really like to evaluate F21 daily, but without a flood of
updates destabilizing the installation (up to the point that it doesn't
boot anymore - aka various forms of systemd/plymouth/gdm breakage, or
regression which developers know about already but which haven't been
prevented from entering F21).
4:15 a.m.
> > Where is the menu of Evince? Its Help system refers to it
("top right
> > corner"), but I can't find it.
>
> I filed this earlier today at
> https://bugzilla.gnome.org/show_bug.cgi?id=735446
Ah, I see. Another case of a mass-build for both Rawhide and F21 at the
same time. Preferably, builds of upgrades enter Rawhide several days
before F21. Only that gives the minimal chance to find bugs in Rawhide
first -- unless hardly any users/developers run Rawhide.
I would really like to evaluate F21 daily, but without a flood of
updates destabilizing the installation (up to the point that it doesn't
boot anymore - aka various forms of systemd/plymouth/gdm breakage, or
regression which developers know about already but which haven't been
prevented from entering F21).
I actually originally pinged Kalev about the evince with no icons
issue, it was entirely usable by going into full screen mode with
F-11, not ideal, but still usable.
I've been running gnome on what will become F-21 using my "production
work laptop" since mid April with out any major issues WRT to booting
or any of the core functionality. That includes mass rebuilds and
branching. Occasionally there's a blip surrounding soname bumps etc
but nothing that's not easily dealt with either --skip-broken or
waiting a day for the next round of fixes.
In terms of "various forms of systemd/plymouth/gdm breakage" I don't
remember ever in this cycle having my laptop being unable to boot. I
do have a fairly generic widespread Lenovo x220 and that might help,
ultimately it hasn't been "perfect" and there's been issues like
virt-manager being unable to run, certain apps that have occasionally
needed to be backed out but all in all it's been very smooth.
I don't think you really can comment unless you actually have been
evaluating daily.
Peter
4:49 a.m.
On Wed, 27 Aug 2014 10:15:06 +0100, Peter Robinson wrote:
I've been running gnome on what will become F-21 using my
"production
work laptop" since mid April with out any major issues WRT to booting
or any of the core functionality.
Compare that with several attempts at trying to upgrade F20 to F21 since
early July. Is any script still checking for and reporting upgrade path
violations? I'm not convinced that a distro-sync upgrade is bullet-proof.
Rawhide has broken into pieces regularly before that. It's still a dumping
ground, where packagers release builds they haven't even tried to start
themselves.
In terms of "various forms of systemd/plymouth/gdm
breakage" I don't
remember ever in this cycle having my laptop being unable to boot.
Symptoms not present with F20:
- the gray X login screen appears, but no users are displayed at the centre
(some race or stale state after shutdown problems?)
- systemd is stuck in a loop waiting for 4-5 items, such as devices during
shutdown or reboot - no patience to wait for more than two minutes!
- the small fedora logo animation fills up till its completely white, then
nothing happens because systemd is waiting for something, pressing reboot
keys doesn't lead to anything
- a freshly upgrade F20-to-F21 only booted to the maintenance prompt or
couldn't decrypt the LUKS home -> upgrading from non-updated F20 to F21
has helped more than once
I don't think you really can comment unless you actually have
been
evaluating daily.
Please don't say that. My latest installation is from Aug 14th. Still I fear
the risk that it will destabilize further. While writing this in Emacs and
moving windows, suddenly the Emacs window (with focus) was stuck behind
Claws Mail and could not be moved in front. Switching virtual desktops
back and forth, eventually it worked again.
$ rpm -qa --last|tail -3
gpg-pubkey-246110c1-51954fca Thu 14 Aug 2014 06:37:50 PM CEST
prelink-0.5.0-1.fc20.x86_64 Thu 14 Aug 2014 06:24:18 PM CEST
aic94xx-firmware-30-6.fc20.noarch Thu 14 Aug 2014 06:24:13 PM CEST
$ rpm -qa --last|grep fc21|tail -3
gnu-free-fonts-common-20120503-9.fc21.noarch Thu 14 Aug 2014 06:46:55 PM CEST
dejavu-fonts-common-2.34-3.fc21.noarch Thu 14 Aug 2014 06:46:55 PM CEST
fontpackages-filesystem-1.44-10.fc21.noarch Thu 14 Aug 2014 06:46:54 PM CEST
10:06 a.m.
On Wed, 27 Aug 2014 11:49:23 +0200
Michael Schwendt <mschwendt(a)gmail.com> wrote:
On Wed, 27 Aug 2014 10:15:06 +0100, Peter Robinson wrote:
> I've been running gnome on what will become F-21 using my
> "production work laptop" since mid April with out any major issues
> WRT to booting or any of the core functionality.
Compare that with several attempts at trying to upgrade F20 to F21
since early July. Is any script still checking for and reporting
upgrade path violations? I'm not convinced that a distro-sync upgrade
is bullet-proof.
Not that I know of.
We could definitely do such a run now...
Rawhide has broken into pieces regularly before that. It's still
a
dumping ground, where packagers release builds they haven't even
tried to start themselves.
Well, I have been running rawhide full time here, and I wouldn't say
that. There has been breakage, but IMHO it's all be reasonably minor
and easy to work around. Perhaps it's more so with your HW?
Without more details it's hard to say more here...
> In terms of "various forms of systemd/plymouth/gdm
breakage" I don't
> remember ever in this cycle having my laptop being unable to boot.
Yeah, same here. I have been using gdm lately, but before that was
using lightdm and it worked fine.
Symptoms not present with F20:
- the gray X login screen appears, but no users are displayed at the
centre (some race or stale state after shutdown problems?)
- systemd is stuck in a loop waiting for 4-5 items, such as devices
during shutdown or reboot - no patience to wait for more than two
minutes!
Adam and I both hit this:
https://bugzilla.redhat.com/show_bug.cgi?id=1123170
I'm seeing it only sometimes. ;( It needs someone seeing it to help
debug.
- the small fedora logo animation fills up till its completely
white, then nothing happens because systemd is waiting for something,
pressing reboot keys doesn't lead to anything
I've seen this here on debug kernels. It's the touchscreen on this
laptop bouncing on and off the usb bus. systemd is waiting for it which
sometimes takes a minute. Upstream is aware and working on it.
Bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1133349
- a freshly upgrade F20-to-F21 only booted to the maintenance
prompt
or couldn't decrypt the LUKS home -> upgrading from non-updated F20
to F21 has helped more than once
No idea there.
kevin
10:41 a.m.
On Wed, 27 Aug 2014 09:06:47 -0600
Kevin Fenzi wrote:
> - systemd is stuck in a loop waiting for 4-5 items, such as
devices
> during shutdown or reboot - no patience to wait for more than two
> minutes!
One of the issues I once ran into was the network going down
before the NFS filesystems were unmounted, at which point it
would take hours to time out on one unmount, more hours to
time out on the next, etc. If you turn off rhgb and quiet
in the kernel boot options, you can see messages about NFS
when it is shutting down which is how I discovered my problem.
Ironically, my problem was caused by trying to get systemd
to ignore NFS filesystems by using the "force" option
on reboot, but all that did was shut down network early,
then try to unmount the NFS systems anyway :-).
12:27 p.m.
On Wed, 27 Aug 2014 09:06:47 -0600, Kevin Fenzi wrote:
> Rawhide has broken into pieces regularly before that. It's
still a
> dumping ground, where packagers release builds they haven't even
> tried to start themselves.
Well, I have been running rawhide full time here, and I wouldn't say
that. There has been breakage, but IMHO it's all be reasonably minor
and easy to work around. Perhaps it's more so with your HW?
There's no reason to believe my HW is the culprit.
Without more details it's hard to say more here...
The primary problem with Rawhide and repository mirror propagation times
is: you can get the "wrong" builds, e.g. a set of updates that breaks your
system, while developers (or packagers) have submitted a new build (or
even a hot-fix) already that is supposed to fix a problem after the next
compose. But you don't receive that one fast enough, or you get a mix of
"bad" updates while those that can update daily without delays probably
won't see the problem. Similarly, if one doesn't update daily, there's the
risk that one updates an installation at a "wrong" point of time and
receives the bad stuff.
3:02 p.m.
On Wed, 27 Aug 2014 19:27:01 +0200
Michael Schwendt <mschwendt(a)gmail.com> wrote:
On Wed, 27 Aug 2014 09:06:47 -0600, Kevin Fenzi wrote:
> > Rawhide has broken into pieces regularly before that. It's still a
> > dumping ground, where packagers release builds they haven't even
> > tried to start themselves.
>
> Well, I have been running rawhide full time here, and I wouldn't say
> that. There has been breakage, but IMHO it's all be reasonably minor
> and easy to work around. Perhaps it's more so with your HW?
There's no reason to believe my HW is the culprit.
You're right. IMHO, there's not enough information here for me
speculate.
> Without more details it's hard to say more here...
The primary problem with Rawhide and repository mirror propagation
times is: you can get the "wrong" builds, e.g. a set of updates that
breaks your system, while developers (or packagers) have submitted a
new build (or even a hot-fix) already that is supposed to fix a
problem after the next compose.
So you get it in the next compose?
If a maintainer noticed the problem before the build went out in a
compose, you would only see the fixed one. If they saw it only after
the compose, you should see the fixed one after that?
But you don't receive that one fast
enough, or you get a mix of "bad" updates while those that can update
daily without delays probably won't see the problem. Similarly, if
one doesn't update daily, there's the risk that one updates an
installation at a "wrong" point of time and receives the bad stuff.
I usually do update daily, but at times I do not. I didn't update for a
week or so around flock, and had no particular problems.
I have another rawhide machine at home that I sometimes don't update
for days/weeks at a time anymore, and it's only had the occasional dep
issue that was pretty easy to fix up/work around.
Anyhow, if you have suggestions for improvement, I'm all ears.
kevin
4:18 a.m.
On Wed, 27 Aug 2014 14:02:12 -0600, Kevin Fenzi wrote:
> The primary problem with Rawhide and repository mirror
propagation
> times is: you can get the "wrong" builds, e.g. a set of updates that
> breaks your system, while developers (or packagers) have submitted a
> new build (or even a hot-fix) already that is supposed to fix a
> problem after the next compose.
So you get it in the next compose?
Sometimes. Provided that the issue did not corrupt anything, does not lead
to boot problems and does not prevent from updating (aka Yum breakage).
For instance, some scriptlet mistakes mess with symlinks, with file
contents, with config files, and with alternatives -- they cause damage.
The fix in a next compose will no longer cause damage, but doesn't
_repair_ the damage that has been caused earlier.
If a maintainer noticed the problem before the build went out in a
compose, you would only see the fixed one. If they saw it only after
the compose, you should see the fixed one after that?
It's not that easy. There are more factors that are relevant, such as
errors during boot, crashes during login, broken dependencies (will
--skip-broken lead to trouble because of unversioned deps?), mirror
propagation times (it takes multiple days for updates to become available
at a nearby mirror, whereas some people install packages from koji/copr as
well as from private repos that are ahead of Rawhide).
I usually do update daily, but at times I do not. I didn't update
for a
week or so around flock, and had no particular problems.
I have another rawhide machine at home that I sometimes don't update
for days/weeks at a time anymore, and it's only had the occasional dep
issue that was pretty easy to fix up/work around.
Well, experience differs. My experience is that over time, Rawhide breaks
into pieces either slowly or all of a sudden. Up to the point that a
reinstall would result in something that works better, because reporting
strange symptoms seldomly is fruitful.
Anyhow, if you have suggestions for improvement, I'm all ears.
There are still packagers, who don't
- build for Rawhide before building for F20/F21,
(i.e. don't violate the upgrade paths)
- smoke-test your builds on a local installation before releasing them
(i.e. notice whether a program segfaults immediately!)
and for library upgrades
- examine the effort it takes to perform library ABI/API upgrades,
(i.e. talk to all dependency owners before breaking dependencies).
--
Fedora release 21 (Twenty One) - Linux 3.16.1-300.fc21.x86_64
loadavg: 0.13 0.17 0.19
5:57 a.m.
On Wed, 2014-08-27 at 11:49 +0200, Michael Schwendt wrote:
On Wed, 27 Aug 2014 10:15:06 +0100, Peter Robinson wrote:
> I've been running gnome on what will become F-21 using my "production
> work laptop" since mid April with out any major issues WRT to booting
> or any of the core functionality.
Compare that with several attempts at trying to upgrade F20 to F21 since
early July. Is any script still checking for and reporting upgrade path
violations?
upgradepath runs, but I believe it only runs on updates, and Bodhi is
not enabled for F21 yet.
Symptoms not present with F20:
- the gray X login screen appears, but no users are displayed at the centre
(some race or stale state after shutdown problems?)
- systemd is stuck in a loop waiting for 4-5 items, such as devices during
shutdown or reboot - no patience to wait for more than two minutes!
- the small fedora logo animation fills up till its completely white, then
nothing happens because systemd is waiting for something, pressing reboot
keys doesn't lead to anything
- a freshly upgrade F20-to-F21 only booted to the maintenance prompt or
couldn't decrypt the LUKS home -> upgrading from non-updated F20 to F21
has helped more than once
FWIW I've been running 21 since 20 came out, and my experience is pretty
close to Peter's. Stuff goes wrong here and there, but broadly it's
fine. There is a known issue with shutdown delaying,
https://bugzilla.redhat.com/show_bug.cgi?id=1088619 .
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
6:04 a.m.
On 08/26/2014 10:20 PM, Kalev Lember wrote:
On 08/26/2014 09:57 PM, Michael Schwendt wrote:
> Where is the menu of Evince? Its Help system refers to it ("top right
> corner"), but I can't find it.
I filed this earlier today at
https://bugzilla.gnome.org/show_bug.cgi?id=735446
Should be fixed in
https://admin.fedoraproject.org/updates/FEDORA-2014-10210
Testing much appreciated!
Thanks,
Kalev
3519
days inactive
3530
days old
15 comments
8 participants
participants (8)
-
Adam Williamson -
drago01 -
Kalev Lember -
Kevin Fenzi -
Michael Catanzaro -
Michael Schwendt -
Peter Robinson -
Tom Horsley