Applications to Flatpak
by Owen Taylor
While waiting on/working on getting Flatpaks building in the Fedora
infrastructure, I took some time to write a tool to collect information
about applications we might want to package as Flatpaks and how they
correlate with the runtime. You can find the result at:
https://fishsoup.net/misc/flatpak-runtime-reports/applications.html
(more reports can be clicked through at the top.)
The data source for this are:
A) The Fedora appstream
B) The Fedora package set
C) The Flathub appstream
D) ODRS reviews (odrs.gnome.org)
[ Scripts are in https://src.fedoraproject.org/modules/flatpak-runtime/ -
but currently depend on only-on-my-computer versions of fedmod. Once the
F28 hybrid compose is sorted out, I can start working on pushing those
changes out. ]
Some initial observations:
* The most popularly reviewed applications on ODRS are either a) packaged
in Fedora or b) can't be packaged in Fedora. This is somewhat circular
because a large fraction of ODRS reviews come from Fedora.
* There are a lot of popularly reviewed applications in Fedora that are
*not* on Flathub. Some are don't make sense or are very hard to Flatpak
(GParted, GNOME Boxes), but plenty of others (qBittorent, Stellarium, etc.)
should be reasonably straightforward.
* Many applications have a *lot* of dependencies that would need to be
bundled given the current runtime contents. But often these are stray -
e.g. gedit pulls 41 dependencies, but if it would only require 4
dependencies if it was fixed to depend on gvfs-client rather than gvfs. Or
as another example, applications that depend on the KDE Frameworks pull in
a pile of perl packages because of /usr/bin/preparetips5 in
kf5-kconfigwidgets which seems marginally useful at runtime.
* A few packages would get bundled into many, many applications - and
should definitely be added to the runtime (qt-settings, glx-utils). But on
the other hand there are a huge set of packages that get bundled into
exactly 1 out of the 800 packages examined here (maybe 1700/3700.)
* I'm not sure yet whether a "flatpak-shared-deps" module with
dependencies built into /app is useful. The pros of it are:
- Things built in it will be shared on disk between different apps because
of ostree deduplication. (But not when downloading via OCI.)
- Things that are hard to build (think perl, texlive) only need to be
worked out once.
* The bulk of the runtime packages get used very broadly, but there is a
short tail of stuff in there that *no* app requires. Some of this I've
already identified as stray and to be removed (krb5-server, say.)
Once we get the building infrastructure going, we can start picking off
some of the low-hanging fruit and looking at the harder cases.
Regards,
Owen
6 years, 1 month
Starting an Atomic Workstation SIG
by Owen Taylor
Hi desktop-list and others,
There was a lot of interest around Atomic Workstation at DevConf.cz - there
were three talks specifically about Atomic Workstation (*), in addition to
quite a few related talks.
We should try to catch some of this momentum and figure out how to move the
project forward. My thought is that it would be useful to set up a regular
IRC meeting, probably every two weeks - more or less an Atomic Workstation
SIG.
Areas of work that come to mind would be:
* Keeping the OSTree and installer composing, installing, and working
* Increasing automated testing done on the OSTree image
* Making sure that open technical questions and pull requests are dealt
with
* Documention, including best practices for development on an OSTree system
* General initiative planning - milestones, promotion, etc.
* Figuring out technical next steps
If you are interested and think you would regularly attend meetings and
participate, please add yourself to:
https://fedoraproject.org/wiki/Workstation/AtomicWorkstation/SIG
or email me. Please include your timezone, and whether you would would be
able to make a meeting opposite weeks from the workstation working group -
Monday 13:00 UTC - that's one time that comes to mind, but I'm not at at
all tied to it.
I can handle agenda and running the meeting for now.
Thanks!
Owen
(*)
Sanja Bonic and Colin Walters - https://www.youtube.com/watch?v=a4IPWlfkJSo
Kalev Lember - https://www.youtube.com/watch?v=Yc7lvkl5atE
Jonathan Lebon - https://www.youtube.com/watch?v=7c3GdfhWzcc
6 years, 1 month
Workstatin WG meeting minutes
by mcatanzaro@gnome.org
Minutes:
https://meetbot.fedoraproject.org/fedora-meeting-2/2018-02-12/workstation...
Minutes (text):
https://meetbot.fedoraproject.org/fedora-meeting-2/2018-02-12/workstation...
Log:
https://meetbot.fedoraproject.org/fedora-meeting-2/2018-02-12/workstation...
=================================
#fedora-meeting-2: Workstation WG
=================================
Meeting started by mcatanzaro at 14:03:06 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-2/2018-02-12/workstation...
.
Meeting summary
---------------
* Reduce initial setup redundancy (mcatanzaro, 14:05:46)
* LINK: https://pagure.io/fedora-workstation/issue/21 (mcatanzaro,
14:05:54)
* LINK: https://pagure.io/fedora-kickstarts/pull-request/328
(mcatanzaro, 14:06:51)
* LINK:
https://jenkins.fedorainfracloud.org/job/fedora-kickstarts/552/
(stickster, 14:08:39)
* LINK:
https://jenkins.fedorainfracloud.org/job/fedora-kickstarts/552/console
<-- failing jenkins build (mcatanzaro, 14:09:31)
* ACTION: mcatanzaro to try to get his fedora-kickstarts PR merged
(mcatanzaro, 14:11:29)
* Noto Colour Emoji (google-noto-emoji-color-fonts) should be installed
by default (mcatanzaro, 14:13:52)
* LINK: https://pagure.io/fedora-workstation/issue/31 (juhp,
14:16:37)
* AGREED: Let's switch to Noto Color Emoji (+5,1,-0) (mcatanzaro,
14:29:22)
* ACTION: juhp to co-ordinate the change to the noto fonts as the
default colour emoji font (ryanlerch, 14:39:37)
* Replace Shotwell with GNOME Photos in default install (ryanlerch,
14:40:05)
* LINK: https://pagure.io/fedora-workstation/issue/32 (ryanlerch,
14:40:21)
* AGREED: GNOME photos to be the default photos app in Fedora
Workstation (6 +1s, 2 0s) (ryanlerch, 14:55:40)
* Replace Rhythmbox with GNOME Music in default install (ryanlerch,
14:58:05)
* LINK: https://pagure.io/fedora-workstation/issue/33 (ryanlerch,
14:58:17)
Meeting ended at 15:02:57 UTC.
Action Items
------------
* mcatanzaro to try to get his fedora-kickstarts PR merged
* juhp to co-ordinate the change to the noto fonts as the default colour
emoji font
Action Items, by person
-----------------------
* juhp
* juhp to co-ordinate the change to the noto fonts as the default
colour emoji font
* mcatanzaro
* mcatanzaro to try to get his fedora-kickstarts PR merged
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* mcatanzaro (52)
* ryanlerch (43)
* stickster (30)
* mclasen (29)
* otaylor (20)
* zodbot (17)
* juhp (17)
* kalev (15)
* ignatenkobrain (10)
* rdieter (5)
* sgallagh (2)
* bt0_ (2)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
6 years, 1 month
some atomic questions
by Matthias Clasen
All this interest in atomic workstation made me dust off my vm.
While upgrading it, I ran into a number of questions that I couldn't find
any answers
for. This might be useful information to put on a new atomic workstation
website.
1) How do I find out what I'm running ?
I guess the answer to this is rpm-ostree status, but what does
it actually tell me ?
● atomicws:atomicws/fedora/x86_64/continuous
Version: 26.447 (2018-01-29 04:58:49)
BaseCommit:
ba986d4649f08705185ba1ce7208e72d149b1e35314d112a86348cb1d61f6f52
LayeredPackages: powerline
It would be nice to explain this output a bit - I assume the first
'atomicws' is a repository name, and 'atomicws/fedora/x86_64/continuous' is
a branch name. Version 26.447 may indicate that I am running some version
of Fedora 26.
Unfortunately, I haven't really seen the gnome-software support
in action yet, but I hope it shows this information as well.
2) How do I get the latest updates ?
rpm-ostree upgrade is easy enough (once I've found it).
3) How do I upgrade to a newer release ?
4) How do I find out what branches are available to rebase to ?
5) Where is the repo configuration stored ?
This is where I got stuck - I could not find any answers to these.
Very frustrating, a normal user would have given up here.
Eventually, Kalev told me to create a file in /etc/ostree/remotes.d/ with
some content, and then I figured out to run
ostree remote refs fedora
to see the branches in the repo, and
rpm-ostree rebase fedora:fedora/27/x86_64/workstation
to upgrade to one of them. I blindly picked this branch, since
I have no idea what the difference between
fedora/27/x86_64/testing/workstation
fedora/27/x86_64/updates/workstation
fedora/27/x86_64/workstation
might be...
Also, I had to disable gpg verification, since I didn't know where
to find the key for that repo.
We need to make the rpm-ostree plugin support distro-upgrades
inside gnome-software. And also make this information available
in some obvious place.
6 years, 1 month
Rotating WG chair
by Paul W. Frields
As we discussed in the meeting earlier this week (sorry for not
following up sooner), I'd like to start a process of rotating the
chair duties for the Workstation working group meeting.
The next meeting is scheduled for Monday, January 29. However, I
believe that many of us (at least Matthias, Christian, Owen, Kalev,
Jens, myself) will be either in meetings or traveling back from the
DevConf.cz event in Brno that day. So we could start this with the
Monday, February 12 meeting.
I'd intended to propose an alphabetical rotation. But if folks would
rather volunteer, that's fine with me. It seems to work well in
FESCo, which also rotates chairs. If you're interested, just reply
here.
--
Paul W. Frields <pfrields(a)redhat.com>
Manager, Fedora Engineering - Emerging Platform
http://redhat.com -- http://opensource.com
6 years, 1 month
Release criteria proposals: Edition branding and installer
customizations
by Adam Williamson
sgallagh and I both noticed that the release criteria do not currently
include any requirements around Edition branding or installer
customizations. We think they probably should. Thus, we're proposing
the following new criteria. They would be in a new section for each
page, something like "Edition requirements" or something like that,
probably with a brief explanation of what "Editions" are outside of any
specific criterion text.
For Beta:
== Installer customization ==
For each Edition, all significant functional customization of installer
behavior that are intended to be a part of that Edition must take
effect on that Edition's installable release-blocking images.
footnote: 'Significant functional?': significant functional
customization would usually include, for e.g., changes to the default
filesystem and firewall configuration. The WG or SIG responsible for
each Edition has the definitive say on what is or is not considered a
'significant functional customization' for that Edition.
For Final:
== Self-identification ==
For each Edition, the installer must be clearly identified as that
Edition in all of that Edition's installable release-blocking images.
Also, for any deployment of that Edition in accordance with the rest of
these criteria, the relevant fields in {{filename|/etc/os-release}}
must include the correct Edition name.
Thoughts, comments, suggestions, flames? Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
6 years, 1 month