Some performance criticisms of F25
by Michael Catanzaro
Hi,
Jiri found this review (among many) of Fedora 25:
http://www.hecticgeek.com/2016/12/fedora-25-review/
It includes a couple recommendations:
* We should restore systemd-readahead to speed boot time by ~30% for
users without SSDs. Endless has a downstream patch for this. Or we
could use Ubuntu's readahead utility.
* We should switch from CFQ to deadline I/O scheduler (which Ubuntu
has been using for years) for subjective massive responsiveness
improvements when the system is under load
Of these, the later seems easier to change and more important. Anyone
know why we're still using CFQ? If the answer is "it's better for
servers" then perhaps we need a mechanism to adjust this on a per-
product basis.
Just wanted to put these issues back on the radar....
Michael
5 years, 8 months
[wayland] Applications are unable to grab input
by Christian Stadelmann
One main difference between x11 and wayland is that in x11 all applications receive all input whereas in wayland the compositor receives input and decides which application may receive it.
This causes a major issue with application which need input grab for running or showing a nested desktop. This affects e.g. GUI virtual machines (SPICE clients), RDP clients, VNC clients, nested kwin/gnome-shell/whatever. See also: https://bugzilla.redhat.com/show_bug.cgi?id=1285770 . Games might also be affected, I don't know.
I'm posting this here to raise attention because
1. to fix this we need another protocol (extension)
2. this issue can't be fixed in a single application, it needs the whole stack (wayland library, compositors, affected applications) to change
Compared to the other bugs in "WaylandRelated" lists [1] [2], these bugs need architecture design, not just fixing bugs in one package.
I don't know whether this mailing list is the right place to discuss an issue like this. If you know better, please tell me.
[1] https://bugzilla.redhat.com/showdependencytree.cgi?id=1277927&hide_resolv...
[2] https://bugzilla.gnome.org/showdependencytree.cgi?id=757579&hide_resolved=1
5 years, 11 months
Atomic (rpm-ostree+flatpak+oc cluster up) workstation
by Colin Walters
Hey, so I'd like to keep pushing forward on
https://fedoraproject.org/wiki/Workstation/AtomicWorkstation
(Which is related to:
https://fedoraproject.org/wiki/Changes/WorkstationOstree )
I actually just revamped the first page completely. One
thing I'd like to propose that's new is that we focus a lot on `oc cluster up`
as a local developer model for *server* applications. I just
installed it by default:
https://pagure.io/atomic-ws/c/c5f77d9b1a9c15c65cf0abbc1490896b85d9ba48?br...
Now let's back up; the current state is we
have two efforts, one in:
https://pagure.io/atomic-ws
which lives in CentOS CI currently, and
https://pagure.io/workstation-ostree-config/commits/master
which is in Fedora, but not as actively maintained.
I'd like to migrate my work into Fedora. This content should be generated
based on Fedora 25, potentially with some overrides.
We should integrate with the existing Fedora tools, such as
https://openqa.fedoraproject.org/
for installer testing. I'd also like this content to be GPG signed
(and ideally transport protected) the same way other content
is. But like Atomic Host we should have both a more agile *and* slower release
process that's decoupled from the 6months base/daily-bodhi model
which I don't really think makes sense. Basically we'd aim for updates
to the core at most once a week (modulo async errata). The auto-generated flatpaks though
would be daily or faster potentially. We need the ability to do async
Firefox security errata quickly.
In the short or potentially medium term, this would be a sidecar
to the Workstation which is based on the "big bag of packages" model.
There is an existing base of people who are interested in this, and I think
with some minimal CI/integration and maintenance we can
produce something that's very different from the package bag,
and has some powerful advantages, but also without distracting
too much from it.
A major milestone for this will be removing firefox from the base
tree, and relying on an autogenerated flatpak.
This email was sent from atomic-ws btw; I do find it practical
today for everyday use, but as you can see I've layered some
things like keepassx that aren't flatpak'd yet:
● atomic-ws:atomicws/fedora/x86_64/continuous
Version: 25.2017.34 (2017-02-15 20:26:05)
BaseCommit: ef0587aa74b1135566c1a0d79bb3c053da55016bd1fa314df3c78332edc79f68
Commit: a49a1417c87cc7495a6d66141effba6bebe4d142f466ba79dce8d47a0d010fa7
OSName: fedora
Packages: ansible emacs fuse-sshfs gdb gimp keepassx krb5-workstation libgit2 libvirt opensc pcsc-lite-ccid powerline strace vagrant-hostmanager vagrant-libvirt vagrant-sshfs virt-manager xchat xsel ykclient ykpers
Unlocked: development
6 years
Re: Fedora Rawhide-20170227.n.0 compose check report
by Kevin Fenzi
On Tue, 28 Feb 2017 09:24:20 -0500
Dusty Mabe <dusty(a)dustymabe.com> wrote:
> On 02/27/2017 09:41 PM, Adam Williamson wrote:
> > On Mon, 2017-02-27 at 17:25 +0000, Fedora compose checker wrote:
> >> Missing expected images:
> >>
> >> Atomic qcow2 x86_64
> >
> > There seems to be some sort of problem in pungi-make-ostree:
> > https://kojipkgs.fedoraproject.org//work/tasks/1386/18091386/root.log
> >
> > DEBUG util.py:435: + pungi-make-ostree tree
> > --repo=/mnt/koji/compose/atomic/rawhide/
> > --log-dir=/mnt/koji/compose/rawhide/Fedora-Rawhide-20170227.n.0/logs/x86_64/Atomic/ostree-2
> > --treefile=/mnt/koji/compose/rawhide/Fedora-Rawhide-20170227.n.0/work/ostree-2/config_repo/fedora-atomic-docker-host.json
> > --extra-config=/mnt/koji/compose/rawhide/Fedora-Rawhide-20170227.n.0/work/ostree-2/extra_config.json
> > DEBUG util.py:435: Traceback (most recent call last): DEBUG
> > util.py:435: File "/usr/bin/pungi-make-ostree", line 15, in
> > <module> DEBUG util.py:435: ostree.main() DEBUG
> > util.py:435: File
> > "/usr/lib/python2.7/site-packages/pungi/ostree/__init__.py", line
> > 85, in main DEBUG util.py:435: func() DEBUG util.py:435:
> > File "/usr/lib/python2.7/site-packages/pungi/ostree/tree.py", line
> > 95, in run DEBUG util.py:435: repos = extra_source_repos +
> > [{'name': 'source_repo_from', 'baseurl': source_repo_from}] DEBUG
> > util.py:435: TypeError: unsupported operand type(s) for +:
> > 'NoneType' and 'list'
>
> I'll try to track this down tomorrow when I'm not AFK, unless someone
> else gets to it first. If you open an issue to track this then please
> link me to it.
I guess I only replied to the desktop list when I replied to this. ;)
This was fixed I think in https://pagure.io/pungi/pull-request/542
but we need a new pungi release/version with the fix on the compose
host(s).
kevin
6 years
Re: Fedora Rawhide-20170227.n.0 compose check report
by Adam Williamson
On Mon, 2017-02-27 at 17:25 +0000, Fedora compose checker wrote:
> Missing expected images:
>
> Atomic qcow2 x86_64
There seems to be some sort of problem in pungi-make-ostree:
https://kojipkgs.fedoraproject.org//work/tasks/1386/18091386/root.log
DEBUG util.py:435: + pungi-make-ostree tree --repo=/mnt/koji/compose/atomic/rawhide/ --log-dir=/mnt/koji/compose/rawhide/Fedora-Rawhide-20170227.n.0/logs/x86_64/Atomic/ostree-2 --treefile=/mnt/koji/compose/rawhide/Fedora-Rawhide-20170227.n.0/work/ostree-2/config_repo/fedora-atomic-docker-host.json --extra-config=/mnt/koji/compose/rawhide/Fedora-Rawhide-20170227.n.0/work/ostree-2/extra_config.json
DEBUG util.py:435: Traceback (most recent call last):
DEBUG util.py:435: File "/usr/bin/pungi-make-ostree", line 15, in <module>
DEBUG util.py:435: ostree.main()
DEBUG util.py:435: File "/usr/lib/python2.7/site-packages/pungi/ostree/__init__.py", line 85, in main
DEBUG util.py:435: func()
DEBUG util.py:435: File "/usr/lib/python2.7/site-packages/pungi/ostree/tree.py", line 95, in run
DEBUG util.py:435: repos = extra_source_repos + [{'name': 'source_repo_from', 'baseurl': source_repo_from}]
DEBUG util.py:435: TypeError: unsupported operand type(s) for +: 'NoneType' and 'list'
> Server dvd i386
Several i386 image composes still failing for the reason Kevin noted
recently:
dnf.exceptions.Error: Will not install a source rpm package (docker-anaconda-addon-0.4-4.fc26.src).
> Xfce raw-xz armhfp
Looks a bit odd:
https://kojipkgs.fedoraproject.org//work/tasks/1563/18091563/root.log
DEBUG util.py:435: Unable to create appliance : Failed to find package 'firefox' : no package matched: firefox
Is there an ARM-specific issue with the firefox package?
> Server boot i386
> Atomic raw-xz x86_64
See above.
> Failed openQA tests: 10/107 (x86_64), 1/2 (arm)
>
> ID: 57880 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
> URL: https://openqa.fedoraproject.org/tests/57880
This is some kinda transient test fail, I think (openQA clicked in the
wrong place or the click got lost or something).
> ID: 57881 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
> URL: https://openqa.fedoraproject.org/tests/57881
This is now failing because of:
https://bugzilla.redhat.com/show_bug.cgi?id=1405790
freeipa-client and freeipa-server can't be installed due to dep issues
with certmonger, and certmonger rebuild is failing.
> ID: 57899 Test: x86_64 Workstation-live-iso desktop_terminal
> URL: https://openqa.fedoraproject.org/tests/57899
> ID: 57907 Test: x86_64 Workstation-live-iso desktop_update_graphical
> URL: https://openqa.fedoraproject.org/tests/57907
These two failed because gnome-color-manager unexpectedly asked for
access to the system location immediately upon login, which the test
can't cope with:
https://bugzilla.gnome.org/show_bug.cgi?id=779343
We could adjust the test, but the GNOME behaviour seems odd, so waiting
for input from the devs on whether it's a bug.
> ID: 57925 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload
> URL: https://openqa.fedoraproject.org/tests/57925
We never get any video output from this test, with a 10 minute (IIRC)
boot timeout. pwhalen reports there's a showstopper with ARM atm
related to module loading:
https://bugzilla.redhat.com/show_bug.cgi?id=1422634
that may be causing this, or it may be something else.
> ID: 57951 Test: x86_64 universal install_iscsi
> URL: https://openqa.fedoraproject.org/tests/57951
This broke between 20170208 and 20170214, my best guess at what
happened is in the new bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1427359
> ID: 57956 Test: x86_64 universal install_software_raid@uefi
> URL: https://openqa.fedoraproject.org/tests/57956
This is an openQA console typing fail (sigh, still happens
occasionally). Test actually worked fine.
> ID: 57978 Test: x86_64 universal install_cyrillic_language
> URL: https://openqa.fedoraproject.org/tests/57978
Still https://bugzilla.redhat.com/show_bug.cgi?id=1413813 . If that
doesn't get any attention soon I may have to make the test work around
it to cover the rest of the test case...
> ID: 57983 Test: x86_64 universal install_rescue_encrypted
> URL: https://openqa.fedoraproject.org/tests/57983
> ID: 57984 Test: x86_64 universal install_rescue_encrypted@uefi
> URL: https://openqa.fedoraproject.org/tests/57984
Still https://bugzilla.redhat.com/show_bug.cgi?id=1376638 . Looks like
there's now a PR to fix this, but it is not yet merged.
> ID: 57986 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall
> URL: https://openqa.fedoraproject.org/tests/57986
This is a hard fail caused by the same SELinux alert that causes all
the soft fails (see below). It's a hard fail because any AVC alert that
triggers a desktop notification on boot is a Final release criteria
violation.
> Soft failed openQA tests: 52/107 (x86_64)
> (Tests completed, but using a workaround for a known bug)
These are all caused by:
https://bugzilla.redhat.com/show_bug.cgi?id=1392161
it may strictly speaking have been best reported as a separate bug, but
basically there's an AVC that shows up on almost all installs,
something being denied 'mounton' action for /proc/mtrr .
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
6 years
Workstation WG meeting recap 2017-Feb-27
by Paul W. Frields
Minutes: https://meetbot.fedoraproject.org/fedora-meeting-2/2017-02-27/workstation...
Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-2/2017-02-27/workstation...
Log: https://meetbot.fedoraproject.org/fedora-meeting-2/2017-02-27/workstation...
* * *
=================================
#fedora-meeting-2: Workstation WG
=================================
Meeting started by stickster at 14:00:04 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-2/2017-02-27/workstation...
.
Meeting summary
---------------
* Roll call (stickster, 14:00:07)
* meeting will end at :55 so chair can get to next meeting :-)
(stickster, 14:02:55)
* Flatpak production (stickster, 14:05:23)
* wide ranging discussion in the meeting log, recommend people read
that since it's not easy to capture in simple meeting minutes
(stickster, 14:33:26)
* ACTION: otaylor write up straw man for flatpaks not using the module
approach; drive discussion with infra team; decide on
modules/no-modules, then move to figuring out implementation details
and where to find people/time to do the work (stickster, 14:34:25)
* Workstation features F26/F27 (stickster, 14:35:06)
* reminder that we will have a call for F26 Talking Points coming in
the next ~month (stickster, 14:45:13)
* Performance tuning follow-up (stickster, 14:45:54)
* LINK: https://pagure.io/fesco/issue/1684 (stickster, 14:45:59)
* topic on hold until we have an owner for the work (stickster,
14:52:44)
Meeting ended at 14:58:16 UTC.
Action Items
------------
* otaylor write up straw man for flatpaks not using the module approach;
drive discussion with infra team; decide on modules/no-modules, then
move to figuring out implementation details and where to find
people/time to do the work
Action Items, by person
-----------------------
* otaylor
* otaylor write up straw man for flatpaks not using the module
approach; drive discussion with infra team; decide on
modules/no-modules, then move to figuring out implementation details
and where to find people/time to do the work
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* stickster (69)
* otaylor (39)
* mcatanzaro (23)
* mclasen (21)
* zodbot (13)
* cschalle_ (13)
* juhp (6)
* kalev (6)
* x3mboy (5)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
6 years
WG meeting call for agenda Mon 2017-Feb-27
by Paul W. Frields
If you have additions or corrections for this agenda, please send by
the end of this weekend. Our meeting will be held as usual on Monday,
2017-Feb-27 at 1400 UTC (09:00 US Eastern).
* Flatpak production (otaylor)
* Outcome from Brno meetings/DevConf.cz, and follow up from Feb-24
* Need follow-up discussion on this
* Any distinguishing Workstation features upcoming for F26/27 beyond
Flatpak development?
* Performance tuning the Workstation
* https://pagure.io/fesco/issue/1684
* No one from Workstation has spoken up to own the benchmarking
task, which gives us particular workloads and results on which to
base a change. Is anyone going to do this?
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
6 years
Re: flatpak UI/Ux, was: Atomic (rpm-ostree+flatpak+oc cluster up) workstation
by Chris Murphy
It'd be nice if there were a direct download + install for flatpak
applications. Either licking on the URL in Firefox causes GNOME
Software to autolaunch and do whatever needs to be done (find and
install runtimes as well as the application); or maybe an included
webextension for Firefox that can do the installation.
At the moment I'm confused about --system vs --user installation
locations. Somehow I have some things that are system and others are
user. This is relevant because a system domain installation means it's
the rootfs volume that takes the storage hit; where user domain
installation means it's the home volume that takes the storage hit.
And if runtime and application are split, then backup and restore
strategy has to account for this split or it's possible the
application ends up "broken" if the runtime is missing.
My gut instinct is that the first user created by g-i-s should be an
admin (in group wheel) by default. And when a user in group wheel is
doing flatpak application installations, that by default they're
installed on rootfs not in home, so that they're available for any
user. I'm not super inclined to applications being stored in
/home/<user>/.
A "neat" option would be a flatpak exported file that describes the
system's flatpak state (all remotes, runtimes, applications) that can
be imported into a clean system, and then ask flatpak to do the
restore or whatever other command means "make it go" and then flatpak
goes out and downloads and installs those items.
Last, I'd rather not have to manage or even be aware of runtimes.
Can't the application flatpak define what runtime(s) it prefers in
order, and then go out and get them? This especially applies to GNOME
Software which shows runtimes separate from the application.
Chris Murphy
6 years
