One of main questions that we need to settle before implementing building Flatpaks in Koji is whether there is a module-per-Flatpak or not. At the working group meeting last Monday I was leaning towards "no", to keep things simpler for contributors. I had a long conversation with Langdon and Matthias about the current state of Modularity and flatpaks and that changed my mind to lean towards "yes"
One reason is that if we don't create a module-per-flatpak, we need to write a "flatpak build service" that looks something like the Module Build Service and get that deployed in Fedora infrastructure. This is a lot higher overhead than whatever tweaks we would need for the Module Build Service.
But just as importantly, if the goal of the Fedora project is to start taking packages off the F2<x> release train, spending effort on something that only makes sense in the context of that release train doesn't make a lot of sense.
That is, currently, the LCMS color management library has a f26 branch that points to lcms-1.19. GIMP in F26 will use the LCMS in F26. But the goal of Modularity is that there will instead by a 1.19 branch of lcms. For a core library like nss, we can say that the "f27 version of nss is 3.29" because the base-runtime or generational-core modulemd file will list the branch. But there is no obvious way of saying what version of LCMS is "part of" F27.
With a no-module approach to flatpaks - saying that "BuildRequires: lcms2" in the GIMP Spec file is sufficient and our tooling figures out everything from there - we'd have to "reinvent the F27 branch" by having a mega-module listing branches of everything that is used by every application. It's probably better to simply start with the GIMP module that lists the branch of lcms that it needs.
There are definitely serious work items that we will need to make building Flatpaks as modules not a nightmare for package maintainers, but these are at least partially the *same* work items as needed for other module maintainers, and often things that that Modularity WG already are planning for.
* There needs to be autobuilding on changes to constituent packages
* There needs to be bodhi integration
* There needs to be an easy way to create a Flatpak module and build definition. You could imagine that if rpms/gedit exists, running 'fedpkg flatpak-init gedit' creates modules/gedit with a template metadata.yaml, and flatpak/gedit with a template 'gedit.json'.
* There needs to be a generation process for modulemd file, where the very detailed list of included rpms is generated from something higher level as part of the build process.
* There needs to be tooling to help module maintainers deal with updating their branches.
* There needs to be standards around branch lifetimes so that the GIMP maintainer doesn't get blindsided when the LCMS maintainer decides they no longer want to support the 1.19 branch.
1) Figure out how we can get the RPM macros for /app into the buildroot for a module. It may be possible to use the 'buildrequires:' tag to pull in a flatpak-build module that has the necessary macros.
2) Settle on an approach for building Flatpaks out of packages. Direct code in a koji plugin is simplest, but putting it into OSBS/Atomic Reactor would have the advantage of more closely following the container path, allowing reuse of the logic for pushing OCI images around.
3) Figure out where Flatpak metadata lives in dist-git. Container build instructions will live in docker/ and be *referenced* by the modules in modules/. Putting flatpak metadata into docker/ seems bizarre, so a separate dist-git namespace is the obvious approach. A different approach would be to put it alongside the SPEC file or modulemd file in the same git repository.
4) Review how close we are to being able to point GNOME Software at an OCI container registry to find flatpaks.
I have a touch screen which generates a plethora of event types
according to libinput-debug-events (including what seems to be
multi-touch events). I can even see distinct events for the digitizer
However, further up the stack, all this is gone. I don't get any
two-finger scrolling, for instance. There is no right-button
emulation in Firefox, either. I can still generate primary button
click events and (single-finger) drag events, but that's about it.
With Wayland, the pen appears to be completely dead. With X, I get
some reaction to the pen in Xournal (some pointer indication moves),
but Xournal does not put any ink on the screen.
How can I help to improve matters in this area?
This is with current Fedora rawhide and the 4.9.9 kernel (4.11 seems
to have Wifi issues).
Unfortunately the change deadline has passed, but our coredumpctl
change is not testable due to . Additionally, ABRT is broken due to
. We have workarounds for both issues, but it requires running
SELinux commands locally. Accordingly, is likely that FESCo will reject
the change at its next meeting.
I'm tired of prodding the SELinux developers via email and Bugzilla.
This saga has been ongoing since last summer, which is way too long. I
now have very, very serious doubts as to whether we should continue to
ship with SELinux enabled in the Workstation product. We clearly cannot
fix it even when it's breaking a critical developer feature that's a
priority for the WG... so what happens when it breaks anything less
Hey, so I'd like to keep pushing forward on
(Which is related to:
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:
Now let's back up; the current state is we
have two efforts, one in:
which lives in CentOS CI currently, and
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
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:
Version: 25.2017.34 (2017-02-15 20:26:05)
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