Re: Fedora Rawhide-20161025.n.0 compose check report
by Adam Williamson
On Tue, 2016-10-25 at 17:07 +0000, Fedora compose checker wrote:
> Missing expected images:
>
> Workstation live i386
> Workstation live x86_64
>
> Failed openQA tests: 8/90 (x86_64), 2/16 (i386), 1/2 (arm)
>
> New failures (same test did not fail in Rawhide-20161024.n.0):
>
> ID: 44083 Test: x86_64 Workstation-boot-iso install_default@uefi
> URL: https://openqa.fedoraproject.org/tests/44083
This hit a failure in the g-s-d color plugin:
Oct 25 06:17:35 localhost.localdomain gnome-shell[1592]: GNOME Shell started at Tue Oct 25 2016 09:17:31 GMT-0400 (EDT)
Oct 25 06:17:54 localhost.localdomain pulseaudio[1619]: [pulseaudio] bluez5-util.c: GetManagedObjects() failed: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Oct 25 06:19:01 localhost.localdomain gnome-session[1543]: gnome-session-binary[1543]: WARNING: Application 'org.gnome.SettingsDaemon.Color.desktop' failed to register before timeout
Oct 25 06:19:01 localhost.localdomain gnome-session-binary[1543]: WARNING: Application 'org.gnome.SettingsDaemon.Color.desktop' failed to register before timeout
Oct 25 06:19:01 localhost.localdomain gnome-session-binary[1543]: Unrecoverable failure in required component org.gnome.SettingsDaemon.Color.desktop
The same test passed on staging, though, so it doesn't look to be a
completely reproducible bug. We can keep an eye out and see if it
happens again...
> ID: 44163 Test: x86_64 universal upgrade_2_kde_64bit
> URL: https://openqa.fedoraproject.org/tests/44163
This timed out again, but I actually think there may be something wacky
going on in the upgrade process to Rawhide: tests that time out don't
seem to be running smoothly but just running out of time, they seem to
actually get stuck at the same point for a long time until they time
out. I haven't had time to look into this in detail yet, though.
> Old failures (same test failed in Rawhide-20161024.n.0):
>
> ID: 44097 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload
> URL: https://openqa.fedoraproject.org/tests/44097
Boot is failing here, somehow, and winding up in dracut emergency
shell. Don't know what's wrong with it yet. Anyone have time to look
into it?
> ID: 44113 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
> URL: https://openqa.fedoraproject.org/tests/44113
ipa-server-install crashed.
https://bugzilla.redhat.com/show_bug.cgi?id=1388640
> ID: 44156 Test: x86_64 universal upgrade_desktop_64bit
> URL: https://openqa.fedoraproject.org/tests/44156
> ID: 44159 Test: x86_64 universal upgrade_desktop_encrypted_64bit
> URL: https://openqa.fedoraproject.org/tests/44159
> ID: 44161 Test: x86_64 universal upgrade_2_desktop_64bit
> URL: https://openqa.fedoraproject.org/tests/44161
> ID: 44164 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
> URL: https://openqa.fedoraproject.org/tests/44164
> ID: 44184 Test: i386 universal upgrade_desktop_32bit
> URL: https://openqa.fedoraproject.org/tests/44184
> ID: 44185 Test: i386 universal upgrade_2_desktop_32bit
> URL: https://openqa.fedoraproject.org/tests/44185
Aside from the 'getting stuck and timing out' problem there's a
dep issue affecting a lot of these tests - looks like firebird-
libfbembed requires a rebuild for an ICU soname bump. I haven't looked
into the details yet (to see if anyone's tried to fix it).
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
7 years, 6 months
Wayland drag and drop question?
by Norman L Smith
Fedora Workstation 25 Beta...
I have found a difference between Xorg and Wayland drag and drop
behavior in Gnome Shell.
In Wayland you cannot drag the icon through the hot corner and paste
into an application in a
different workspace.
The Xorg drag and drop is intuitive. You hold the mouse button down
through the entire
operation until you reach the target and then release to drop.
The Wayland drag and drop works but it is not obvious what to do. You
must drag the object
into the hot corner. When the Overview is displayed, move cursor into
the Overview. The
icon is detached from the cursor and remains at the corner. You then
release the mouse
button and move the cursor to the workspace with the target. Press and release the mouse
button to select the target. The target will be moved from the
workspace to the body
of the Overview. Move the mouse button to the target and press and
release the mouse
button. The Overview will close and the icon appears and reconnects to
the cursor. Click
the target and the object will be dropped.
I have placed a compressed file with two short videos of Xorg and
Wayland drags from an
application to an application in a different workspace at:
https://drive.google.com/file/d/0B52Y4vnjoV74WDVaQ1F6TjlXSk0/view?usp=s
haring
My question: Is the Wayland behavior intended by design or should I
report a bug?
Thanks,
Norman
7 years, 6 months
screen lock shield
by Chuck Anderson
When I lock the screen in Gnome Shell, a shield screen appears when I
hit any key (including e.g. Shift). This is good.
However, when the screen saver/monitor power save kicks in, but the
lock is set to a higher timeout, e.g. 30 minutes, no shield screen
appears after hitting a key. Instead, whatever key you typed is sent
to the application that has focus, but you can't know what application
that is ahead of time because the screen is in power save. I find
myself accidentally typing my password into random windows because I
assume the screen is fully "locked" but it is just in power save mode.
I.e. it is hard to distinguish between these two cases.
Proposal: invoke the shield screen even when the screen isn't fully
"locked" yet, just in power save, to prevent keystrokes from being
erroneously sent to applications when waking up the screen.
7 years, 6 months
Atomic Workstation development work
by Colin Walters
Hey, so we've talked about this a lot, and there
are now two change pages:
https://fedoraproject.org/wiki/Changes/WorkstationOstree
This is in Fedora release engineering, and the scope is basically
rpm-ostree + flatpak
https://fedoraproject.org/wiki/Workstation/AtomicWorkstation
But I'd like to revisit this, since I want to argue strongly for adding
Docker to the mix. I now use "pet" Docker containers for most of my
random software building/hacking, and I think this use case is
not really covered by flatpak, and installing build tools on the host
system I believe should be an explicit anti-pattern.
I've set up https://pagure.io/atomic-ws
which is running in CentOS CI. This specifically configures Docker
in a useful way (overlayfs), and starts by default.
Basically, by adding Docker, I think this feels closer to Project Atomic,
hence the rebranding.
Besides the link on the pagure page, I copied a snapshot of the ISO
here: https://fedorapeople.org/~walters/atomicws-installer-25.2016.61.iso
There are hence a few things to do to merge this into Fedora:
- Decide on tooling emphasis (and management; does PackageKit
need to learn anything about docker?)
- Decide on the branding
- Merge in the partitioning changes I made in https://pagure.io/atomic-ws/blob/master/f/overlay.yml#_46
(switch to something similar to Server - xfs by default, no split /home, but overlayfs for docker)
- Fix the ostree management in Fedora (right now at-most-once-a-day
is far too slow for development and far too fast for most users, I think it
could make sense to do a two-week cadence (+async security) as
we're planning for Atomic Host). This will also enable static deltas
and make the experience more pleasant; see https://fedorahosted.org/rel-eng/ticket/6313
In CentOS for Atomic Host we use a "promotion" model.
7 years, 6 months
coredumpctl integration for F25
by Michael Catanzaro
Hi,
Currently we have coredumpctl installed by default, but it doesn't work
because core dumps are consumed by ABRT instead. I'd like to get
coredumpctl working out-of-the-box. We can do this by changing our
systemd presets [1] to disable abrt-ccpp.service.
ABRT will continue to function thanks to the ABRT developers' work on
coredumpctl integration via abrt-vmcore.service. There is a somewhat-
reduced feature set, but I've been running this for several months
happily and I haven't noticed any issues; my crashes are being reported
to FAF, and I can manually report to Bugzilla. See [2] for details.
This might be slightly controversial for two reasons. First, the big
change here is that core dumps will appear in the magical and super-
awesome coredumpctl tool in addition to ABRT, but would no longer be
created in the cwd when ulimit is set appropriately (we would need to
feature that in the release notes). This aligns us with upstream
systemd behavior, but diverges from Debian and Ubuntu, which still
create the old-style coredumps in the cwd. Second, my understanding is
that the ABRT developers prefer to improve abrt-cli and tell people to
use that rather than coredumpctl. But as coredumpctl is very mature
(nicer) and cross-distro so it gets many more contributors, I
definitely prefer to instruct people to use coredumpctl instead for
C/C++ crashes.
We could totally do this change for F24 as well as it should be just a
one-line change, but in the spirit of beta freeze I figure it's
probably best left for F25.
Michael
[1] https://pagure.io/fedora-release/blob/master/f/90-default.preset
[2] https://github.com/abrt/abrt/issues/1108
7 years, 6 months
