Re: Debugging fun (wrt C modernization change)

[Owen Taylor]

On Tue, May 14, 2024 at 6:50 AM Panu Matilainen  wrote:

>
> Patch and source numbers start from zero, that goes for automatically
> numbered patches too. So there's an off by one in the application, and
> the latter %autopatch which is supposed to apply patches >= 2 simply has
> nothing to do, and falls through silently. That's a bug of course in
> itself, filed now:
> https://github.com/rpm-software-management/rpm/issues/3093
>

One thing that is quite difficult to do with %autopatch/%autosetup is
conditionally applied patches, since I've always understood it to be bad
practice to conditionalize the Patch: lines

The evolution-data-server spec file currently has:


# 0-99: General patches

# 100-199: Flatpak-specific patches
# https://gitlab.gnome.org/GNOME/evolution-data-server/-/merge_requests/144
Patch100: Make-DBUS_SERVICES_PREFIX-runtime-configurable.patch

[...]

%prep
%autosetup -p1 -S gendiff -N

# General patches
%autopatch -p1 -m 0 -M 99

# Flatpak-specific patches
%if 0%{?flatpak}
%autopatch -p1 -m 100 -M 199
%endif


which will warn if you add a warning about empty %autopatch. Not sure if
there's a better way of handling that.

- Owen
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl] PR #1: Make builds for inclusion in an application Flatpak work

[Owen Taylor]

otaylor commented on the pull-request: `Make builds for inclusion in an 
application Flatpak work` that you are following:
``
Closing in favor of #6
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: zlib-ng as a compat replacement for zlib

[Owen Taylor]

One practical example - the process of creating an OCI container image of
the Fedora Flatpak runtime does a *lot* of zlib compression and
decompression. (https://pagure.io/flatpak-module-tools/issue/22). A lot of
that is temporary to save disk space and IO bandwidth and could be switched
to zstd or a lower zlib compression level, but without any changes,
dropping in zlib-ng for the system zlib on my system reduced the wall time
for building the runtime from 9m13s to 6m49s. I suspect a lot of developer
tasks would get noticeably faster with a faster zlib, if not by that margin.

Regards,
Owen


On Sat, Aug 5, 2023 at 11:12 AM Richard W.M. Jones 
wrote:

> The background to this is I've spent far too long trying to optimize
> the conversion of qcow2 files to raw files.  Most existing qcow2 files
> that you can find online are zlib compressed, including the qcow2
> images provided by Fedora.  Each cluster in the file is separately
> compressed as a zlib stream, and qemu uses zlib library functions to
> decompress them.  When downloading and decompressing these files, I
> measured 40%+ of the total CPU time is doing zlib decompression.
>
> [You don't need to tell me how great Zstd is, qcow2 supports this for
> compression also, but it is not widely used by existing content.]
>
> I was looking around for alternative zlib implementations and there
> are several.  This AWS blog is a decent summary:
>
>
> https://aws.amazon.com/blogs/opensource/improving-zlib-cloudflare-and-comparing-performance-with-other-zlib-forks/
>
> We already package zlib-ng in Fedora:
>
>   https://src.fedoraproject.org/rpms/zlib-ng/blob/rawhide/f/zlib-ng.spec
>   https://github.com/zlib-ng/zlib-ng
>
> In my test zlib-ng is about 40% faster.
>
> Sadly zlib-ng is not compiled with the ZLIB_COMPAT option.  What this
> means in practice is that the zlib functions have different names
> (eg. zng_inflateInit instead of inflateInit).  It is not a drop-in
> replacement for zlib and software would need to be adjusted to use it.
>
> However there is this bug / RFE to package the compat library.
>
>   https://bugzilla.redhat.com/show_bug.cgi?id=2145239
>
> It literally replaces /usr/lib64/libz.so.1, so pretty high stakes.  It
> has the appropriate Provides/Conflicts.
>
> Anyway, 40% (or whatever, but significant) performance improvement
> sounds good for a very widely used operation.
>
> So I'd like to ask Fedora ...
>
> What do we think about the opt in approach of adding a patch similar
> to the one proposed in bug 2145239, where I think you could "simply"
> install zlib-ng to get better performance with existing software?
> ("simply" because it seems high risk of going wrong)
>
> What about replacing zlib with zlib-ng?
>
> Other ideas ...?  Does anyone know what other distros are doing?
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-p2v converts physical machines to virtual machines.  Boot with a
> live CD or over the network (PXE) and turn machines into KVM guests.
> http://libguestfs.org/virt-v2v
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Owen Taylor]

On Sun, Jul 2, 2023 at 5:01 PM Demi Marie Obenour 
wrote:

> On 6/3/23 08:42, Michael Catanzaro wrote:
> > On Sat, Jun 3 2023 at 10:26:07 AM -, John Iliopoulos <
> jxftw2...@gmail.com> wrote:
> >> Hello,
> >>
> >> While i completely understand why you do this i do think that it is
> >> important for desktop/workstation oriented devices to have some
> >> optional access to Office directly from the image file. Have you
> >> considered shipping the LibreOffice flatpak via the ISO much like
> >> Fedora Silverblue does with various other applications?
> >>
> >> This is the first time i reply to a mailing list so i hope i have not
> >> done anything wrong.
> >
> > Hi. Welcome to the list. You haven't done anything wrong.
> >
> > For Fedora Workstation, the mid-term plan is to ship all preinstalled
> > apps as Fedora Flatpaks. We cannot ship anything from Flathub because
> > FESCo will not allow it. I don't *like* this FESCo requirement, but I
> > also don't expect that to change. Accordingly, since Fedora Flatpaks
> > are built from Fedora RPMs, maintaining the LibreOffice RPMs is
> > essential to keep LibreOffice preinstalled. (I think that applies to
> > Silverblue as well?)
>
> Fedora Flatpaks are also a security disaster: they are shipped in OCI
> format instead of OSTree format, but they aren’t signed by anyone.
> I’ve disabled the Fedora remote and recommend that others do the same.
>

I think the words "security disaster" are painting a  too strong picture
here. When you install a Fedora Flatpak, the digest of the content being
installed is checked against the checksums embedded in the index downloaded
from (e.g.
https://registry.fedoraproject.org/index/static?label:org.flatpak.ref:exists=1=linux=amd64=latest).
These indexes are statically generated from data queried from Bodhi and
Koji and downloaded from a static web server directly from Fedora bypassing
the CDN.

The most obvious way to get malicious content into this index would be to
inject it at build time, by adding it upstream, infiltrating the Fedora
project, hacking a Fedora contributor, etc. In all of these cases, if we
had container signatures, robosignatory would happily sign it when the
update was created.

Yes, someone could hack the server hosting the index, get write-access to
the mount hosting the indexes, or find some specific way to exploit the
indexing process. And in those cases, having checked signatures would help.
The first two cases would seem to imply a widespread breach of Fedora
infrastructure that would likely affect security of builds as well.

What would be needed to implement signatures would be roughly:
 - Implement container signatures in robosignatory/sigul
 - Implement distribution of signatures (probably easiest if we move
registry.fedoraproject.org to quay.io as planned for a while)
 - Implement checkingo of container signatures in the Flatpak client

 One thing that helps now is that for a long time there was a lot of
uncertainty in where signatures were going in the container world, but at
this point, at least Red Hat parts of the container world seems to be
solidly behind the approach of https://github.com/sigstore/cosign. (Still a
lot of details / moving parts that would have to be researched.)

- Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Owen Taylor]

On Tue, Jun 6, 2023 at 7:50 AM Leon Fauster via devel <
devel@lists.fedoraproject.org> wrote:

> Is the Fedora OCI flatpak approach not about the trust into the chain of
> flatpak creation? src -> signed rpm -> flatpak? So, even in an ideal world
> where RHEL is immutable and the best workstation experience is based on
> flatpaks - RPMs are the building block. This is completly different to the
> Flathub approach ...
> https://fedoraproject.org/wiki/Flatpak#Fedora_flatpaks
>

In both cases, the build is fixed to a cryptographic hash of the source
tarball. For Flathub, that is done in the manifest file.. (
https://github.com/flathub/org.libreoffice.LibreOffice/blob/master/org.libreoffice.LibreOffice.json)
In Fedora, by the SOURCES file. In both cases, the exact tools versions
used to build the binary from the source are recorded. For Flathub, that is
done by embedding an extended version of the manifest in the application
(at /app/manifest.json). For Fedora, that information is recorded by the
buildroot information saved by koji.

You could look for more - does the hash in the SOURCES file actually
correspond to the published upstream tarball? Is there a signature on that
tarball? Do you trust that signature? But I don't see much of a difference
in this aspect. Building an intermediate RPM doesn't make the source =>
Flatpak pipeline more secure.

- Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

[Owen Taylor]

On Mon, Jun 5, 2023 at 8:35 AM Josh Boyer  wrote:

> On Mon, Jun 5, 2023 at 6:28 AM Debarshi Ray via devel
>  wrote:
>
> I wanted to wrap up this sub-thread on-list, after Owen and I chatted
> > about it off-list.
> >
> > I am fine with having the fedora-toolbox OCI images being defined as
> > kickstart files in the Fedora infrastructure and built by ImageFactory
> > and published as another base image, just like the fedora base image
> > currently is.
>
> Just an FYI, but we're trying to move away from ImageFactory in the
> general sense.  I'm not sure if/how that will manifest itself in
> Fedora, but ImageFactory is pretty terrible for debugging things when
> it goes wrong.  The options we're looking at elsewhere are Image
> Builder, OSBS2, and RHTAP.
>

If we want to move Fedora images to ImageBuilder, then the right thing to
do here is still to merge the toolbox image into fedora-kickstarts and then
work on migrating that, rather than have it be a one-off outlier. (*)

- Owen

(*) Yes, I know Fedora-IOT uses ImageBuilder. but in the context of the
main Fedora compose.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

[Owen Taylor]

On Tue, May 30, 2023 at 9:47 AM Debarshi Ray  wrote:

> Hey Owen,
>
> On Mon, 2023-05-29 at 12:39 -0400, Owen Taylor wrote:
> > On Mon, May 29, 2023 at 8:16 AM Debarshi Ray via devel
> >  wrote:
> > >
> > > My main concern, which I had brought up in the Release Engineering
> > > tickets before [1,2] is whether the fedora-toolbox images would
> > > continue to be defined as a Docker/Containerfile.  I am asking
> > > because the fedora base images are defined as kickstart files [3].
> > >
> > > There's some value in continuing to use a Docker/Containerfile
> > > because it's widely known and leads to a common workflow.  It is
> > > used for the official Toolbx images for other distributions like
> > > Arch Linux, RHEL and Ubuntu, and a growing list of third-party
> > > Toolbx images [4].  A Docker/Containerfile is easy to use with
> > > 'podman build' as part of the upstream CI, which makes it easier to
> > > test all the different parts.
> >
> > Unfortunately, if we switched to using ImageFactory or pretty much
> > anything other than OSBS, we'd no longer be able to define the Fedora
> > toolbox image as a Dockerfile. It certainly is a disadvantage that
> > it's no longer connected to the way that the other toolbox images are
> > defined,
>
> It's an advantage to have the Fedora images be defined in the same
> source language as the Arch Linux and Ubuntu images, and certainly the
> RHEL images.  However, ultimately, I see it only as a convenience.
> Folks can take the Fedora images as a reference and tweak them to fit
> their own distribution, or copy paste the files across Git
> repositories, etc..  If we lose that, then I would learn to live with
> it.  :)
>

I guess in this scenario, the Fedora images are no longer the reference for
creating things for other distributions and something else (RHEL, Ubuntu,
...) would have to take over that role. For "tweaking", I'd think we'd
definitely want to promote "FROM fedora-toolbox:latest".


> If we do move away from Container/Dockerfiles, then my main question
> would be whether it'll still be easy to locally build the images.  Will
> we need something a lot more elaborate than the simplicity of a 'podman
> build'?
>

I haven't actually tried building the Fedora container images locally, but
it it looks relatively documented and straightforward, and someone could
write a shell script to automate it pretty easily. But it is still going to
require tools (ImageFactory) that people don't have installed and probably
take a while to run. It seems like more of a "want to contribute to the the
Fedora toolbox image" thing than a "would do it to run tests when
contributing to Toolbx" thing.

Toolbx has two parts.  A somewhat distro-agnostic toolbox(1) binary,
> and an OCI image for a distribution.  Both work together to provide an
> interactive CLI environment, and hence both should be tested together.
>
> If a contributor attempts to change one or both of those two, then it
> should be easy for them to verify whether both would continue to work
> together.  Currently, they can do that by doing a local 'podman build'
> on the image definitions in toolbox.git and try to use them with their
> modified toolbox(1) binary.  I want to formalize this by making the
> upstream CI run against both:
>   (a) images that are currently published on the OCI registries and
>   (b) images that are built on-the-fly from the sources in toolbox.git
>

In this scenario the Fedora Toolbx image definition would live in
fedora-kickstarts, so it doesn't really make sense for me that Toolbox CI
would *recreate it*, rather than just using the version from the repository.

Ideally, we'd run the Toolbox tests against the newly built Toolbx image as
part of QE for the Fedora compose.


> ... so that it will validate any changes to the image sources in
> toolbox.git, and alert us to any changes in the underlying distribution
> (eg., packages, dependencies, base images, etc.) that could break
> future image rebuilds.
>
> Currently, the upstream CI runs only against (a).
>
> If we lose the simplicity of a 'podman build' then we lose the testing.
> That's my main worry.
>
> If the new set-up offers a similarly simple way of building the images
> from source, then I am happy.
>
> > but maybe that's bearable if we can substantially improve the
> > workflow?
>
> The phrase "we can substantially improve the workflow" makes me
> curious.  Any details or pointers?
>

What I mean by this was simply the obvious - that the Toolbx image is built
as part of the compose, and can be tested as part of the compose
validation. That nobody is sitting there manual

Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

[Owen Taylor]

On Mon, May 29, 2023 at 8:16 AM Debarshi Ray via devel <
devel@lists.fedoraproject.org> wrote:

> Hey Owen,
>
> On Wed, 2023-05-24 at 13:50 -0400, Owen Taylor wrote:
> >
> > What if we made the Toolbox container image just one more base image
> > and built it with ImageFactory?
> >
> >  - Integrated into the compose process
> >  - Across all architectures
> >  - No OSBS dependency
> >
> > The main disadvantage is that it is no longer layered, so *if* you
> > happen to have the exact same Fedora image version around for some
> > other reason (a big if), you save a fraction of space:
> >
> > Fedora 38 container - 71M compressed, 201M uncompressed
> > Toolbox add-on layer -  232M compressed, 753M uncompressed
> > Toolbox squashed  - 291M compressed, 884M uncompressed
>
> I am not too attached to the bandwidth or space savings due to the
> fedora-toolbox image being a layered image.
>
> [ In future, I would like to  explore if we can ship the fedora-toolbox
> image as part of the Silverblue and Workstation ISOs, to avoid the need
> for a sizable download just to set up the default Toolbx.  That could
> unlock things like defaulting to a Toolbx shell or generally help
> promoting Toolbx as a primary interactive CLI environment.  Anyway,
> that's a big 'if'.  ]
>
> My main concern, which I had brought up in the Release Engineering
> tickets before [1,2] is whether the fedora-toolbox images would
> continue to be defined as a Docker/Containerfile.  I am asking because
> the fedora base images are defined as kickstart files [3].
>
> There's some value in continuing to use a Docker/Containerfile because
> it's widely known and leads to a common workflow.  It is used for the
> official Toolbx images for other distributions like Arch Linux, RHEL
> and Ubuntu, and a growing list of third-party Toolbx images [4].  A
> Docker/Containerfile is easy to use with 'podman build' as part of the
> upstream CI, which makes it easier to test all the different parts.


Unfortunately, if we switched to using ImageFactory or pretty much anything
other than OSBS, we'd no longer be able to define the Fedora toolbox image
as a Dockerfile. It certainly is a disadvantage that it's no longer
connected to the way that the other toolbox images are defined, but maybe
that's bearable if we can substantially improve the workflow?

With some refactoring of the kickstarts for Fedora containers, we could
also remove some of the hackiness in the Dockerfile where it is undoing
choices in the base image.

When I ask this question, I do have a hidden agenda - I'm thinking that it
might be possible to move Flatpak generation to a Koji plugin that runs
directly on the builders, but that would leave the toolbox as the sole user
of the OSBS cluster, which seems
dubiously sustainable. So maybe we can take Toolbox off of OSBS as well and
retire OSBS?

Now, if we could instead move to OSBS 2 and have that actively maintained
and across architecture, that could be better, but I don't really see where
the resources are going to come from to do that.

- Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Flatpaks without Modules (System-Wide Change)

[Owen Taylor]

On Thu, May 25, 2023 at 6:57 AM Petr Pisar  wrote:

> V Thu, May 25, 2023 at 06:04:51AM -0400, Owen Taylor napsal(a):
> >  * We need to rebuild files that can contain data from both parts
> > (/etc/ld.so.conf, /usr/lib/fontconfig/cache, etc.)
>
> How does splitting files from /usr to /app helps with this item?  Or is it
> that application flatpaks are not supposed to deliver their own libraries
> and
> fonts and if they do, they have to vendor them in a specific way (e.g.
> storing a location of the application libraries into application
> executables
> with RPATH)?
>

Generally, if the runtime includes a library (like fontconfig) where it's
useful for an application to drop data into /app, the runtime is expected
to set the necessary configuration files, environment variables, or
whatever so that they are found:

For example, fontconfig is handled by:


https://src.fedoraproject.org/rpms/flatpak-runtime-config/blob/f38/f/50-flatpak.conf

which is installed in all Fedora runtime images. Setting LD_LIBRARY_PATH is
handled by the Flatpak core.

- Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Flatpaks without Modules (System-Wide Change)

[Owen Taylor]

On Thu, May 25, 2023 at 4:02 AM Florian Weimer  wrote:

> * Owen Taylor:
>
> > On Fri, May 12, 2023 at 1:34 PM Florian Weimer 
> wrote:
>
> >  Do you have a pointer where I can read up on the current approach?
> >
> > Some references that I found quickly:
> >
> > https://docs.fedoraproject.org/en-US/flatpak/concepts/
> > https://docs.flatpak.org/en/latest/basic-concepts.html
> >
> > But neither goes into a lot of detail to motivation. I'm certainly
> > willing to describe things in more detail or look around further if
> > you still have questions.
>
> As far as I can see, it doesn't explain why we need rebuilds.
>
> Toolbx seems to be able achieve something similar without rebuilds.


 In the docker/oci ecosystem, layers are explicitly dependent on the exact
underlying layers. If I modify a base image to upgrade one library, I have
to rebuild images that depend on it. Similarly, once you've created a
Toolbx container based on a  verison of the image, you can't replace the
image without recreating the container and losing local modifications.

If Flatpak was based on docker/oci, then every time a single library in the
runtime was modified, all 2000+ apps on Flathub would need to be rebuilt
and the upgraded versions downloaded by every single user. In the ideal
case, the upgraded application layers delta-compress well, but we're still
talking about a huge amount of wasted resources. It works better for
server-side containers because of datacenter-level networking and
resources, and because server-side container images are often simpler and
are based on simpler base images.

So, we need to preserve the ability to separately upgrade the application
and the runtime. This is currently achieved in Flatpak by the "low-tech"
way that the runtime is in /usr and the application in /app and we mount
those together into final namespace. If we want to achieve the same thing
with everything in /usr, then we have a series of technical challenges to
overcome. Among others:

 * We need a way to merge filesystems (fuse-overlayfs, composefs, huge
quantities of bind mounts, hardlink trees...)
 * We need to rebuild files that can contain data from both parts
(/etc/ld.so.conf, /usr/lib/fontconfig/cache, etc.)
 * We have to handle the case where the application layer needs to bundle a
newer/different version of a library than the runtme

These aren't impossible to solve, but to come up with solutions, implement
them in the Flatpak codebase, validate them with real applications, update
all the build infrastructure is a large (year or years scale) project.
Beyond that, you have to convince upstream Flatpak that this is worthwhile
- to add a whole second mode of operation for Flatpak when the current mode
of putting application code in /app largely works fine in the "normal" case
where the application is rebuilt from source code.

So, to recap, Flatpak separates out /usr and /app because that allows the
runtime and application to be separately upgraded. Modifying Flatpak to
solve that problem in a different way would be a technically difficult and
long process that, even if we had the resources to do it, would not solve
immediate problems with our dependency on modularity.

- Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

[Owen Taylor]

On Tue, May 9, 2023 at 11:52 AM Kevin Fenzi  wrote:

> Just a general answer/info here at the bottom of the thread...
>
> I realize our container build pipeline is not great, but it's currently
> working and I will keep it working until we replace it.
>
> I agree we should replace it, and there's lots of options, but I don't
> think this thread is the place to go back and forth about them.
>
> I know of at least kiwi, osbuild, some other build systems that don't
> fully exist yet, switching to use quay.io, osbs2 (based on openshift4),
> and probibly others.
>

What if we made the Toolbox container image just one more base image and
built it with ImageFactory?

 - Integrated into the compose process
 - Across all architectures
 - No OSBS dependency

The main disadvantage is that it is no longer layered, so *if* you happen
to have the exact same Fedora image version around for some other reason (a
big if), you save a fraction of space:

Fedora 38 container - 71M compressed, 201M uncompressed
Toolbox add-on layer -  232M compressed, 753M uncompressed
Toolbox squashed  - 291M compressed, 884M uncompressed

But generally seems like it would be a win. osbuild/kiwi/whatever can be
left as a separate project.

- Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Flatpaks without Modules (System-Wide Change)

[Owen Taylor]

On Wed, May 17, 2023 at 4:42 AM Petr Pisar  wrote:

> [...]
> > Any Fedora packager can rebuild a package into f39-app using 'fepdkg
> > build --target=f39-app'.
> >
> [...]
> > Once a package exists in f39-app or f38-app, then
> > [[
> https://gitlab.com/redhat/centos-stream/ci-cd/distrosync/distrobuildsync
> > distrobuildsync]] will be used to do a build into f39-app each time a
> > standard build completes.
> >
> Do I understand correctly that flapaks containing the same package actually
> reuses the same package build? E.g. if a flatpak for Firefox requires a nss
> package and a flatpak for Thunderbird requires the same nss package, then
> nss
> is built into f39-app only once and both Firefox and Thunderbird flapaks
> are
> created from the same nss package build?
>

Yes, that's the idea. While we had the theoretical ability to build
libraries differently when bundling into different Flatpaks, in the vast
majority of cases, we did not use that capability.


> Because if there were a need for rebuilding the same package for different
> flapaks differently, using a single Koji target would not not work. A Koji
> tag
> only presents the latest build of a package.
>

Yep. The side tag mechanism could possibly be used if a situation arose
where we *did* need different builds, but I don't see that need.

- Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Flatpaks without Modules (System-Wide Change)

[Owen Taylor]

On Mon, May 15, 2023 at 1:51 AM Milan Crha  wrote:

> On Wed, 2023-05-10 at 09:30 -0400, Owen Taylor wrote:
> > Does that sound workable? Are there better ways we could do it?
>
> Hi,
> if I recall correctly, using the custom D-Bus prefix is there to match
> application's D-Bus prefix defined for the flatpak, thus:
> a) the services run independently from the system, inside the sandbox;
> b) they can be started without any additional effort on the Flatpak
>configuration side (because the services share the app's D-Bus
>prefix).
>
> I briefly grepped the evolution-data-server sources and it seems that
> most of the places in the .c files can be changed in runtime, but there
> are places where the things can break, like the `evolution-data-
> server.pc` file or the D-Bus .service files, which both reference the
> D-Bus name from the compile time and those .service files are also
> named by the service (otherwise there's a runtime warning in the
> journal about the file not matching the service name). Those might not
> be show stoppers, I guess.
>

The idea is that we'd substitute the name and contents of the service files
at container creation time. The .pc file is tricker, since it is build
time. Those variables aren't used much.
I found two examples:
 - libfolks uses it when setting up a private bus for test cases -
shouldn't matter
 - You use it in to fix bus names in flatpak-evolution-wrapper.sh - those
could just be hardcoded since the bus name will be always the same for the
Evolution Flatpak

By the way, when people install Evolution flatpak, they have
> preinstalled evolution-ews inside it. How will they install it after
> this change?
>

The idea is that the container.yaml can list any number of packages to be
installed in the Flatpak. The first one is the "main" one, but that only
means that the name/version of the Flatpak come from it by default. Adding
evolution-ews as an additional package will work fine.

- Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Flatpaks without Modules (System-Wide Change)

[Owen Taylor]

On Sat, May 13, 2023, 4:24 AM Mattia Verga via devel <
devel@lists.fedoraproject.org> wrote:

> Il 13/05/23 03:04, Owen Tay rt I look
>
> On Fri, May 12, 2023, 1:03 PM Mattia Verga via devel <
> devel@lists.fedoraproject.org> wrote:
>
>> Il 10/05/23 12:54, Aoife Moloney ha scritto:
>> M kk kk kk kk o kk kk kk I I'll k>
>> https://fedoraproject.org/wiki/Changes/FlatpaksWithoutModules
>> >
>> >
>> I've never tried to make a flatpak because I was scared by the need of
>> firstly build modules and I'm really happy to see this change moving on.
>>
>> However, there's something I can't understand: AFAIK, a flatpak is
>> platform independent, so a flatpak built on F39 can be installed on any
>> Fedora version or even on other Linux distributions... right?
>> So, why having all those "Fedora Containers" releases in Bodhi which
>> follow Fedora branches? Isn't just one Fedora Containers release enough?
>> What happens if one builds the same flatpak on multiple Fedora
>> Containers releases?
>> infrastructure/new_issue
>> 
>
>
> The "F38 Flatpaks" release in Bodhi represents Flatpaks built with the F38
> package set against the F8 runtime. But, yes, as you say we handle Flatpaks
> as a single stream. Once we release Firefox into "F39 Flatpaks", everybody
> on all releases gets that and we never do an update in "F38 Flatpaks" again.
>
> If updates *do* get pushed on multiple releases, last pushed wins. Might
> be useful if we found that we pushed something to early or broken - but
> isn't normal.
>
> I was wondering if that was due to have the ability of building the
> flatpak against a specific runtime. I mean, as I understand how a flatpak
> works, a flatpak created from a koji build for f39 will be built against a
> specific runtime (say, KDE available in f39 stable tags), but when we build
> the same koji build for f40 we will be using a different runtime which may
> not be compatible... so still having a Fedora Containers 39 release will
> make the maintainer able to continue using the f39 runtime... I know I'm
> quite confused, aren't I?
>
> If I search for fedora-toolbox updates in Bodhi, I now see there are
> multiple updates released alongside each others at the same time
>
I think some of the confusion comes from the fact that fedora-toolbox is
not a Flatpak at all and we have different bodhi releases and policies for
Flatpaks and other containers. We naturally do want parallel versions of
the toolbox container - you should be able to create a F37 Toolbox or a F38
Toolbox or ...

> But what if we had a single release instead?
>
> On a technical level, we rely on separate releases because Bodhi is using
> that to know what koji tag to pull from. So to merge them, we'd probably
> need a single dest tag in Koji as well. But would it be more convenient and
> less confusing for packagers and users? Would there be any performance or
> UI problems from having a release in Bodhi that extends indefinitely?
>
> Would be simpler to have a single Koji dest tag which doesn't change
> alongside Fedora branches, so that packagers only have to remember that
> one? (provided that we don't want the ability to build multiple updates as
> discussed above)
>
fedpkg automatically determined the target based on the runtime specified
in container.yaml. We'd need separate targets in any case because the build
tag where the packages installed in the container come from needs to be
different based on the runtime version / fedora release. But the different
targets could potentially share a single dest tag.

One thing that would need to change in this model would be the name of the
runtime container in koji/bodhi. We'd probably need to have it be
flatpak-runtime-f38 or something like that, or it would be confusing to be
doing parallel updates into a single dest tag and bodhi release.

(The runtime needs security updates as long as we have any applications
still using it.)

> From a Bodhi POV, I don't think there would be any problem in extending a
> release indefinitely... we currently have Fedora ELN running since 2020 and
> with something like 80K updates and nothing as blown up (yet...)
>
Well, that answers that question :-)

I've created:
https://gitlab.com/fedora/sigs/flatpak/fedora-flatpaks/-/issues/15 to track
this idea, and will bring it up in the next Fedora Flatpaks SIG meeting.

Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Flatpaks without Modules (System-Wide Change)

[Owen Taylor]

On Fri, May 12, 2023 at 1:34 PM Florian Weimer  wrote:

> * Owen Taylor:
>
> > On Wed, May 10, 2023 at 9:48 AM Florian Weimer 
> wrote:
> >
> >  * Aoife Moloney:
> >
> >  > There are two types of Flatpak containers -
> >  > runtimes - which contain unmodified Fedora packages,
> >  > and applications - which contain Fedora packages rebuilt to relocate
> >  > them from /usr to /app.
> >
> >  Is this relocation still required?
> >
> > Yes - the /app vs. /usr split is pretty fundamental to the operation
> > of Flatpak, and this Change doesn't propose any changes to how Flatpak
> > works, just how Flatpaks are built in Fedora.
>
> Do you have a pointer where I can read up on the current approach?
>

Some references that I found quickly:

https://docs.fedoraproject.org/en-US/flatpak/concepts/
https://docs.flatpak.org/en/latest/basic-concepts.html

But neither goes into a lot of detail to motivation. I'm certainly willing
to describe things in more detail or look around further if you still have
questions.


> I'm concerned that this is just like Software Collections with a
> different path, which I believe where previously banned in Fedora (and
> are generally a huge hassle on the releng side, I think).


The big distinction here is that there is no idea that these RPMs will be
installed directly on a Fedora system. They are used only when building
Flatpak containers. So I don't think there is much similarity to SCL's
other than "built with a different prefix".

- Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Flatpaks without Modules (System-Wide Change)

[Owen Taylor]

On Fri, May 12, 2023, 1:03 PM Mattia Verga via devel <
devel@lists.fedoraproject.org> wrote:

> Il 10/05/23 12:54, Aoife Moloney ha scritto:
> > https://fedoraproject.org/wiki/Changes/FlatpaksWithoutModules
> >
> >
> I've never tried to make a flatpak because I was scared by the need of
> firstly build modules and I'm really happy to see this change moving on.
>
> However, there's something I can't understand: AFAIK, a flatpak is
> platform independent, so a flatpak built on F39 can be installed on any
> Fedora version or even on other Linux distributions... right?
> So, why having all those "Fedora Containers" releases in Bodhi which
> follow Fedora branches? Isn't just one Fedora Containers release enough?
> What happens if one builds the same flatpak on multiple Fedora
> Containers releases?
> infrastructure/new_issue
> 


The "F38 Flatpaks" release in Bodhi represents Flatpaks built with the F38
package set against the F8 runtime. But, yes, as you say we handle Flatpaks
as a single stream. Once we release Firefox into "F39 Flatpaks", everybody
on all releases gets that and we never do an update in "F38 Flatpaks" again.

If updates *do* get pushed on multiple releases, last pushed wins. Might be
useful if we found that we pushed something to early or broken - but isn't
normal.

But what if we had a single release instead?

On a technical level, we rely on separate releases because Bodhi is using
that to know what koji tag to pull from. So to merge them, we'd probably
need a single dest tag in Koji as well. But would it be more convenient and
less confusing for packagers and users? Would there be any performance or
UI problems from having a release in Bodhi that extends indefinitely?

In any case, a change to how we handle Flatpak releases in Koji could be
done separately from this change proposal :-)

- Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Flatpaks without Modules (System-Wide Change)

[Owen Taylor]

On Thu, May 11, 2023 at 2:31 PM Dan Čermák 
wrote:

> Hi,
>
> Aoife Moloney  writes:
>
> > https://fedoraproject.org/wiki/Changes/FlatpaksWithoutModules
> >
> snip
> >
> > There is considerable implementation complexity within OSBS to implement
> this,
> > because the N/V/R need to be written into generated Dockerfile as
> > labels ''before'' building it,
> > but it should be manageable. If not, we'll need to switch to a different
> scheme.
> > (Running dnf with --best when building the container will
> > help make this reliable
> > and would be a general improvement.)
>
> Just out of interest, has this complicated part been already implemented
> or is it still on the todo list? Would using a different container build
> system reduce the complexity here?
>

I have a fairly strong sense of what needs to be done, and have written
similar code before, but haven't actually written the patches for the
atomic-reactor component of OSBS.

Honestly, the "complexity" here is dwarfed both by the complexity of
maintaining OSBS in Fedora *and* by the complexity of switching to a
different container build system. I don't think it factors in to whether
Fedora switches and on what timescale.

- Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Flatpaks without Modules (System-Wide Change)

[Owen Taylor]

> I'm just wondering whether the name suffix is the right place to put
"flatpak" as if it were a subpackage - can we use the dist tag instead, say
`fi39` for "fedora immutable based on fedora 39" or something like that? Or
`fp39` for `fedora flatpak ...`?

The main difference is what happens when you type firefox into koji - do
you see

  firefox-112.0.2-1.fc38 [the RPM]
  firefox-112.0.2-1.flatpak [the Flatpak]

Or do you just see the RPM build  and you have to type firefox-flatpak to
see the container build? Which one is clearer? Which one is most useful? I
don't honestly have a big opinion here. I'll bring this and some other
naming issues up in the Fedora Flatpaks SIG next Monday.

- Owen


On Thu, May 11, 2023 at 7:44 AM Michael J Gruber 
wrote:

> Makes a lot of sense and improves the information value of the version
> greatly.
>
> I'm just wondering whether the name suffix is the right place to put
> "flatpak" as if it were a subpackage - can we use the dist tag instead, say
> `fi39` for "fedora immutable based on fedora 39" or something like that? Or
> `fp39` for `fedora flatpak ...`?
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Owen Taylor]

On Wed, May 10, 2023 at 5:34 PM Chris Murphy 
wrote:

>
>
> On Wed, May 10, 2023, at 2:24 PM, Owen Taylor wrote:
>
>
>
> On Wed, May 10, 2023 at 12:02 PM Neal Gompa  wrote:
>
>
> Now, there's a second problem with reading everything from the ESP - it's
> slow for two reasons. First, because read speeds when going through the
> firmware are much slower than the Linux NVMe stack. And second, because we
> have to read everything in order to checksum and verify it.
>
> For that reason, Demi's suggestion of moving things onto a dm-verity
> protected partition is intriguing. Could that even be a loopback file on
> the ESP? It would be like a lazy-read system extension.
>
> The performance geek in me thinks "we could see exciting speedups from
> that!" - the practical side of me thinks "it might be a few second faster.
> And much more complex! Let's just go with efifb, keep the initramfs small,
> and accept any minor regressions".
>
>
> GRUB doesn't support dm-verity, but I don't know if it would make a
> difference if it did. Once the kernel has the ability to interact with
> physical storage, understand partitions, initialize dm-verity, and read a
> file systemt... it could just mount `/` . I think the only way the current
> initial root file system works with the kernel is for the bootloader to
> read an entire initrd file into RAM, and then the kernel can randomly
> access things in that RAM disk.
>

In this idea, the dm-verity parition/file would only be accessed from the
initrd, once we have enough kernel to ability to interact with physical
storage, understand partitions, initialize dm-verity, and read *a*
partition, but potentially not enough to read from a bluetooth keyboard,
show a graphical prompt, mount / from the network, etc.

What dm-verity provides here is a way to trust content without requiring it
to be read ahead of time, checksumed, signature checked and put into ram.

To be clear, I don't think this is necessarily the right way to go - I
think using efifb, not prompting for a passphrase when possible, etc, are
simpler approaches.

>
> It's early still for UKI details but I assume we will need both a
> universal UKI (all use cases), and much smaller use case focused UKIs. I
> say that because the desktops in the default installation configuration are
> the largest single use case. With Btrfs built-into the kernel, we don't
> need that much in the initrd to setup block devices, discover their
> contents, and perform switch root.
>
> The next most common use case(s), device-mapper and md based, require a
> pile of user space programs running to do all the work setting things up.
> Maybe we can just get away with two images, a simple fast one and the
> universal.
>

The elephant in the room is whether the "desktops in the default
installation" UKI requires piles of graphics firmware. It might not be at
all small in that case.

- Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Owen Taylor]

On Wed, May 10, 2023 at 12:02 PM Neal Gompa  wrote:

>
> This proposal isn't better. Neither Windows nor macOS put critical
> operating system code in the ESP, and we shouldn't either. But you
> want to put kernels in the ESP? That's the wrong approach too.
>
> As soon as you throw UKIs in the mix, you've completely broken that
> because now the absolutely most valuable code for your system is in a
> "hostile" environment. At least we can make /boot authenticated and
> tamper resistant as a Btrfs subvolume.
>

As other people have mentioned, we have a solution for the ESP being
untrusted - secure boot. As far as I understand, there's no tamper
resistance for /boot on btrfs unless it's encrypted, and that would be a
whole other barrel of snakes :-)

Now, there's a second problem with reading everything from the ESP - it's
slow for two reasons. First, because read speeds when going through the
firmware are much slower than the Linux NVMe stack. And second, because we
have to read everything in order to checksum and verify it.

For that reason, Demi's suggestion of moving things onto a dm-verity
protected partition is intriguing. Could that even be a loopback file on
the ESP? It would be like a lazy-read system extension.

The performance geek in me thinks "we could see exciting speedups from
that!" - the practical side of me thinks "it might be a few second faster.
And much more complex! Let's just go with efifb, keep the initramfs small,
and accept any minor regressions".

I would rather have a multi-stage boot process, where the first stage
> does just enough to unlock and load the OS volume to load the real
> boot environment.
>

"unlock and load the OS volume" is pretty much what the initramfs does,
right?

- Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Flatpaks without Modules (System-Wide Change)

[Owen Taylor]

On Wed, May 10, 2023 at 9:48 AM Florian Weimer  wrote:

> * Aoife Moloney:
>
> > There are two types of Flatpak containers -
> > runtimes - which contain unmodified Fedora packages,
> > and applications - which contain Fedora packages rebuilt to relocate
> > them from /usr to /app.
>
> Is this relocation still required?
>

Yes - the /app vs. /usr split is pretty fundamental to the operation of
Flatpak, and this Change doesn't propose any changes to how Flatpak works,
just how Flatpaks are built in Fedora.

- Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Flatpaks without Modules (System-Wide Change)

[Owen Taylor]

On Wed, May 10, 2023 at 8:06 AM Milan Crha  wrote:

> On Wed, 2023-05-10 at 11:54 +0100, Aoife Moloney wrote:
> > Additionally a couple of packages (evolution-data-services and
> > tracker-miners) are set up so they can be
> > built with an application-specific D-Bus prefix. Evolution has:
> >
> >   buildopts:
> > rpms:
> >   macros: |
> > %_eds_dbus_services_prefix org.gnome.Evolution
> >
> > This will need to be redone so that evolution-data-services doesn't
> > need recompilation
> > and the prefixing can be done by changing configuration files at
> > container build time.
>
> Hi,
> I cannot speak for the tracker-miners, but in case of the Evolution, it
> runs in its own sandbox, separated from the host system, with bundled
> evolution-data-server (eds) services, thus when the user installs the
> Flatpak version, he/she gets the expected Evolution and eds versions,
> independent of what the host system has installed. Advantage: the user
> gets all fixes, not only client-side (Evolution) fixes. It's important,
> from my point of view.
>

We'll still have an evolution-data-server that runs inside the sandbox and
has prefixed names, it will just have to be done a different way. My best
current idea is that for the (single) Flatpak build, the
evolution-data-services would have

-DDBUS_SERVICES_PREFIX=com.example.FlatpakApp

Then we'd change things (preferably upstream) so instead of building
DBUS_SERVICES_PREFIX into the source code,


com.example.FlatpakApp.org.gnome.evolution.dataserver.AddressBook10.service

would have:

 Exec=/app/libexec/evolution-addressbook-factory
--dbus-services-prefix=com.example.FlatpakApp

Then container.yaml would have something like:

 dbus-service-substitute=com.example.FlatpakApp:org.gnome.evolution

And that would do that substitution in the names and contents of any
service files when building the container. Does that sound workable? Are
there better ways we could do it?

> In many cases, this should consist of just a few minor changes to
> > container.yaml.
>
> Do you mean the `evolution.yaml` is gone with this change and the
> dependencies are taken directly from the .spec file? The eds dependency
> is a problem here, as you noted, not talking that not everything from
> the .spec file requires a rebuild for the flatpak (most dependencies
> are part of the runtime).
>

Yeah, evolution.yaml is gone with the change. Any dependency that is not
part of the runtime will have to have been rebuilt in the f39-app target,
or the container build will fail. Then we'll have some convenience at the
fedpkg level to make that not too painful. ('fedpkg flatpak-build' will
check that things seem ok before starting the build, and there will be
'fedpkg flatpak-build-rpms --all-missing' to rebuild the missing
dependencies.)

- Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Owen Taylor]

On Tue, May 9, 2023 at 2:31 PM Chris Adams  wrote:

> Once upon a time, Chris Murphy  said:
> > What about the increasing growth in linux-firmware and in particular the
> NVIDIA firmware requirements? My reading suggests it's significant and the
> future growth also significant.
>
> Could we use a dumb framebuffer in initrd and get rid of all the GPU
> firmware from the image?
>

The main concern about using efifb during the initrd is handling situations
like:

 - Laptop has the lid closed
 - External monitor is connected to a HDMI port that is only connected to
the discrete GPU or otherwise not lit up by EFI
 - We need to prompt for the passphrase to unlock the root partition

It *mostly* would work fine - and maybe we're OK with that (especially if
we can reduce interaction with the initrd).

- Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: BiggerESP (Self-Contained Change proposal)

[Owen Taylor]

On Tue, May 9, 2023 at 12:39 PM Neal Gompa  wrote:

> On Tue, May 9, 2023 at 12:31 PM Lennart Poettering 
> wrote:
> >
> > On Di, 09.05.23 08:22, Neal Gompa (ngomp...@gmail.com) wrote:
> >
> > > I've been asked to consider converting /boot to a Btrfs subvolume so
> > > that it no longer has a fixed space allocation to deal with the ever
> > > increasing amount of firmware required for NVIDIA GPUs[1]. This is
> > > currently incompatible with how systemd views the world, because the
> > > "discoverable partition spec" is wired to partitions, and there is no
> > > equivalent spec for subvolumes of a volume. And I imagine that
> > > XBOOTLDR (whatever that is) also would have a problem with this.
> >
> > This makese no sense. If you want /boot to just be a subvolume of the
> > rootfs btrfs, then this would imply it's also covered by the same
> > security choices, i.e. encryption. We want to bind that sooner or
> > later to things like TPM2, FIDO2, PKCS11. And that's simply not
> > feasible from a boot loader environment.
> >
> > Hence, the place the kernel is loaded from (regardless if you call it
> > /efi or /boot or /boot/efi, and regardless what fs it is) must be
> > accessible from the boot loader easily, without requiring
> > implementation of TPM2/FIDO2/PKCS11 hookup in the boot loader.
> >
> > Hence: btrfs subvols won't work for this
>
> If we're not using LUKS for encryption, then this is not a problem.
> We're generally looking toward encrypting subvolumes individually
> using the upcoming Btrfs native encryption capability rather than
> using LUKS. That allows us to
>
> 1. Pick which subvolumes are encrypted
> 2. Pick the security binding method per subvolume
>
> For example, the root and home subvolumes would use TPM or some other
> non-interactive binding. The user subvolume in home would decrypt with
> user login.
>
> While this is true, and it would be nice if we could just make "size of
/boot" go away, if we can separate out "future of encryption" from "future
of /boot", we're going to make our lives easier.

And even if the preferred path for encryption for Workstation ends up being
btrfs+fscrypt, that won't be the *only* path for Fedora and derivatives;
another reason to try and sort this out independently.

For the giant firmware problem, we have several ways to attack it:
 - Moderately increase boot/efi partition size as discussed here
 - Share firmware between multiple UKI's using system extensions (don't
quite see how this works, but knowledgeable people think it should)
 - Use efifb at boot time (eliminates need for giant firmware, some
possible regression of complicated screen scenarios)
 - Stop prompting for passphrases from the initrd (future of encryption,
makes those regressions more palatable)

Avoiding giant UKI's will likely also be a win from a performance point of
view.

- Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Future of encryption in Fedora

[Owen Taylor]

On Fri, Apr 7, 2023 at 5:12 AM Simo Sorce  wrote:

> On Thu, 2023-04-06 at 12:56 -0400, Owen Taylor wrote:
> > On Thu, Apr 6, 2023 at 12:32 PM Simo Sorce  wrote:
> >
> > > On Mon, 2023-04-03 at 16:18 -0500, Michael Catanzaro wrote:
> > > > On Mon, Apr 3 2023 at 01:41:48 PM -0700, Brian C. Lane <
> b...@redhat.com>
> > > > wrote:
> > > > > This seems like exactly the kind of discussion that belongs on the
> > > > > devel
> > > > > list, not on a website that I have to remember to visit for
> updates.
> > > >
> > > > There is a notification bell in the right sidebar. Click it. ;)
> > > >
> > >
> > > Or we can simply ignore that discussion until it lands in devel with a
> > > change proposal.
> > >
> >
> > Discussing on the forum was a suggestion from zbyszek and I think he
> > proposed it in the same spirit that I agreed to the proposal - as an
> > experiment in trying to align technical discussions more closely with the
> > overall direction of the Fedora project for communication.
> >
> > I think we can see both pros and cons in how it's gone - on the good
> side,
> > people are involved that might not be involved otherwise, there's an
> easily
> > accessible public record of the conversation that is more readable than
> > even a good mailing list archive, and having richer markup available is
> > genuinely useful.
> >
> > On the downside, spam limits on new posters have gotten in the way in
> some
> > cases, and people have had some trouble figuring out how to use the
> quoting
> > features, resulting in disconnected responses.
> >
> > Yes, there will eventually be change proposals, which will be discussed
> > here (unless anything changes...) but I would strongly encourage people
> to
> > get involved now in the discussion if they care about the topic  - the
> more
> > we can get things right early, the better.
>
> Sorry Owen,
> discourse is too disruptive for me to spend time on.
>
> I did try to skim the discussion and I think you have quite a few hints
> already that this is not an easy path.
> What I would recommend though, is to split this monster of a proposal
> in smaller progressive steps.
>

There already *are* a lot of smaller progressive steps that are proposed
for Fedora, or underway upstream, or already completed. But without at
least a fuzzy big-picture story of where we're trying to get to, it's
really hard to see how they relate to each other, or know what steps are
missing. That's where I'm trying to get to.


> You do not need to get everything super-tight-secure on the first try
> (you won't be able to anyway), and building it in steps will allow you
> to also (hopefully) offer a more fine-grained choice/configuration
> later on.


There's at least a need to know what the *recommended* combinations of
options are, or it will be impossible to know whether super-tight-secure
(or medium-tight-secure) has been achieved.

- Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Future of encryption in Fedora

[Owen Taylor]

On Thu, Apr 6, 2023 at 12:32 PM Simo Sorce  wrote:

> On Mon, 2023-04-03 at 16:18 -0500, Michael Catanzaro wrote:
> > On Mon, Apr 3 2023 at 01:41:48 PM -0700, Brian C. Lane 
> > wrote:
> > > This seems like exactly the kind of discussion that belongs on the
> > > devel
> > > list, not on a website that I have to remember to visit for updates.
> >
> > There is a notification bell in the right sidebar. Click it. ;)
> >
>
> Or we can simply ignore that discussion until it lands in devel with a
> change proposal.
>

Discussing on the forum was a suggestion from zbyszek and I think he
proposed it in the same spirit that I agreed to the proposal - as an
experiment in trying to align technical discussions more closely with the
overall direction of the Fedora project for communication.

I think we can see both pros and cons in how it's gone - on the good side,
people are involved that might not be involved otherwise, there's an easily
accessible public record of the conversation that is more readable than
even a good mailing list archive, and having richer markup available is
genuinely useful.

On the downside, spam limits on new posters have gotten in the way in some
cases, and people have had some trouble figuring out how to use the quoting
features, resulting in disconnected responses.

Yes, there will eventually be change proposals, which will be discussed
here (unless anything changes...) but I would strongly encourage people to
get involved now in the discussion if they care about the topic  - the more
we can get things right early, the better.

- Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Future of encryption in Fedora

[Owen Taylor]

I just posted a thread on discussion.fedoraproject.org:

 https://discussion.fedoraproject.org/t/future-of-encryption-in-fedora/80397

to invite discussion of a requirements document and draft plan about what
we might do for encrypting Fedora Workstation systems in the future. Please
follow up there, but for convenience, the message is reproduced below:



For quite a while, the Workstation Working Group has had open tickets to
improve the state of encryption in Fedora - and in particular get to the
point where we can make the installer encrypt systems by default.

In order to move that forward, I’ve been working on a requirements document
and draft plan. In very brief summary, the plan is:

   Use the upcoming btrfs fscrypt support to encrypt both the system
   and home directories. The system by default will be encrypted with
   an encryption key stored in the TPM and bound to the signatures
   used to sign the bootloader/kernel/initrd, providing protection against
   tampering, while home directories will be encrypted using the user’s
login
   password.

This plan is dependent on the on-going Unified Kernel Image support, since
currently Fedora uses unsigned initrds, and substituting the initrd would
allow an attacker to bypass all encryption. It represents a big change
where we go from having secure boot be something we spend a lot of effort
on, but actually doesn’t do much, to something we’re depending on in a big
way to provide an extra layer of security to the user.

I’d be interested in hearing, among other things:

* Are there requirements that the document doesn’t capture?
* Are there other threats that we should be trying to address?
* Is the focus on integrity a good idea?
* Do we actually need to separately encrypt home directories?
* Do we need to support a model where we bind the encryption key to the
current kernel and initrd without having the combination signed by Fedora?
* Should we be more seriously considering systemd-homed? What advantages
would we get by doing that?

Thanks for any feedback!
– Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Python installation paths, pip, F36

[Owen Taylor]

On Thu, Jun 9, 2022, 8:01 AM Miro Hrončok  wrote:

>
> > Unfortunately, I need to take time off from work for personal reasons
> for a
> > while, so if you could go ahead and make whatever changes are needed and
> merge
> > them, that would be greatly appreciated. Stephan Bergmann can help you
> if you
> > want confirmation that these are actually fixing the Flatpak build
> issues that
> > we were running into.
>
> This is the Fedora 36 update:
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2022-5eaabfc110
>
> Stephan, could you please verify?
>

Thanks, Miro!

Stephan - here's how I would test

* Modify flatpak-rpm-macros to remove all the python-specific overrides,
and build it locally.
* Install that and the new python and pyobject macros in a throwaway
container (or remove afterwards)
* Dnf builddep and rebuild the affected package. If it rebuilds
successfully and everything is under /app, we should be all set.

I don't think trying to rebuild locally under MBS with packages from
updates-testing is going to be feasible.

Thanks!
Owen
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Python installation paths, pip, F36

[Owen Taylor]

On Thu, May 26, 2022 at 5:24 PM Miro Hrončok  wrote:

> On 26. 05. 22 22:08, Owen Taylor wrote:
>
> > OK, I'll work on coming up with some patches. Do you have an opinion
> about
> > whether it makes sense to make the %_prefix support complete with
> something like:
> >
> > - %python3_sitelib %(RPM_BUILD_ROOT= %{__python3} -Ic "import sysconfig;
> > print(sysconfig.get_path('purelib'))")
> > +%python3_sitelib %(RPM_BUILD_ROOT= %{__python3} -Ic "import sysconfig;
> > print(sysconfig.get_path('purelib', sysconfig.get_default_scheme(),
> > {'platbase': '%{_prefix}', 'base': '%{_prefix}')})
> >
> > Without that, the --prefix %{_prefix} additions won't work in isolation,
> and
> > will require something else to redefine python3_sitelib/python3_sitearch.
>
> Using vars={'platbase': '%{_prefix}', 'base': '%{_prefix}')} makes sense
> to me
> (you can omit the second parameter (scheme) if you pass vars by name).
>
> Ah, yes, thanks.

I made a pair of pull requests:
   https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/135
   https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/288

that I believe have all the necessary changes, and did some testing
(there's also a test added in pyproject/rpm-macros/tests, which seems to
work following the instructions for local testing in the README.md)

Unfortunately, I need to take time off from work for personal reasons for a
while, so if you could go ahead and make whatever changes are needed and
merge them, that would be greatly appreciated. Stephan Bergmann can help
you if you want confirmation that these are actually fixing the Flatpak
build issues that we were running into.

Thanks!
Owen


- Owen
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Python installation paths, pip, F36

[Owen Taylor]

On Thu, May 26, 2022 at 1:07 PM Miro Hrončok  wrote:

> On 26. 05. 22 17:13, Owen Taylor wrote:
>
> > A pip with a backported patch (or a rebase) + this approach sounds most
> > maintainable for Fedora 36. But if we think that the --prefix %{_prefix}
> > approach actually works, then perhaps we can either:
> >
> >   A) Just update python-rpm-macros and pygobject-rpm-macros in F36
> >   B) Build a stream-branch (or even the f37 branch) in the
> flatpak-runtime
> > module for F36 and reconverge for F37 - I'm less worried about carrying
> a
> > stream branch for macros packages, since they are unlikely to have
> security fixes.
> >
> > What do you think?
>
> Definitively A. There is no reason to fork the macros, the change should
> be
> perfectly backwards compatible.
>
> The lines are:
>
>
> https://src.fedoraproject.org/rpms/python-rpm-macros/blob/f36/f/macros.python#_61
>
> https://src.fedoraproject.org/rpms/python-rpm-macros/blob/f36/f/macros.python3#_59
>
> https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/rawhide/f/macros.pyproject#_57
>

OK, I'll work on coming up with some patches. Do you have an opinion about
whether it makes sense to make the %_prefix support complete with something
like:

- %python3_sitelib %(RPM_BUILD_ROOT= %{__python3} -Ic "import sysconfig;
print(sysconfig.get_path('purelib'))")
+%python3_sitelib %(RPM_BUILD_ROOT= %{__python3} -Ic "import sysconfig;
print(sysconfig.get_path('purelib', sysconfig.get_default_scheme(),
{'platbase': '%{_prefix}', 'base': '%{_prefix}')})

Without that, the --prefix %{_prefix} additions won't work in isolation,
and will require something else to redefine
python3_sitelib/python3_sitearch.

Thanks!
Owen
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Python installation paths, pip, F36

[Owen Taylor]

Thanks for the detailed response!

To start with your final questions:

>   - Why is Python itself not installed in the /app prefix?
>  - Where and how is pip install invoked?

The way that Flatpaks work is that there are *two* filesystem images, one
mounted on /usr and one mounted on /app. The image mounted on /usr is
called the "runtime" and contains libraries and other files shared between
different applications. In Fedora, this is made out of standard
distribution packages - glibc, libjpeg, and so forth. It also contains
Python 3  and some modules.

The filesystem image at /app contains packages specific to a specific
application - the application itself and libraries. In Fedora, we create
the /app filesystem by rebuilding packages inside a module that is
configured to have a special RPM macros package installed in the buildroot
- https://src.fedoraproject.org/rpms/flatpak-rpm-macros/tree/f36 (installed
at /etc/rpm/macros.flatpak so that it has higher priority than the macros
from /usr/lib/rpm)

(The advantage of this split over the docker layer system is that
applications don't need to be rebuilt every time the base layer is updated.)

macros.flatpak redefines %_prefix to /app, and then does various more and
less hacky things to make that actual work within the Fedora RPM ecosystem
- in particular for Python, it overrides
%python3_sitelib and %python3_sitearch. The distutils.cfg I mentioned is
installed from the same package. This combination worked pretty well for
F35 for Python.

pip install is being invoked is by %pyproject_install or %py_install_wheel
out of an RPM build - the particular breakage that triggered this
investigation was the Python bindings for zxing-cpp , but I think it would
apply to pretty much anything that has moved to the %pyproject macros.

On Thu, May 26, 2022 at 4:04 AM Miro Hrončok  wrote:
[...]

> To read what changed in Fedora 36, I suggest reading the release notes:
>
>
> https://docs.fedoraproject.org/en-US/fedora/latest/release-notes/developers/Development_Python/#sect-install_scheme
>
> And this email thread:
>
>
> https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/thread/AAGUFQZ4RZDU7KUN4HA43KQJCMSFR3GW/
>
> When we did this, we have dropped sysconfig._PIP_USE_SYSCONFIG in Fedora
> 36+.
>
> The change in our patching also caused a naughty UX-nightmare:
> https://bugzilla.redhat.com/show_bug.cgi?id=2026979
>
> However, when $RPM_BUILD_ROOT is set, this should not matter. As long as
> you
> call `pip install` from the specfile (how *exactly* are you using pip
> install?)
> you should be not impacted (much). I am just mentioning this for
> completeness,
> as I am unaware of how you use pip exactly.
>

The fact that sysconfig behaves differently when $RPM_BUILD_ROOT is set
wasn't something I was expecting, and explains quite a bit :-)


> I have dedicated my time in the upcoming months to try to rework this
> entirely
> for Fedora 37+, as it seems I rather screwed this up in the effort to try
> to
> make it better. The new approach will however also patch sysconfig and not
> distutils. Using distutils for anything has no future.
>
> (My new idea is about distro-customizable default sysconfig installation
> prefix
> value, and I am happy to brag about it more -- we could possibly use it as
> a
> future-proof solution for /app as well, depending on what you want to
> achieve.)
>

Having some standard way to configure a system by environment variable or
drop in file would definitely be nice ... and sounds like something we
could leverage.

Though I'm also wondering now if we could just change %py_install variants
and %pyproject variants to have --prefix %{_prefix} on the install command
line - that should have no effect for standard builds and make Flatpak
builds work?

As a hotfix, you could probably set sysconfig._PIP_USE_SYSCONFIG back to
> False.
> RPM-packaged pip in Fedora 36 is 21.3 so we would need to backport my
> change
> that reads this value to make it work (I have no problem doing that).
>
> Those are the ideas that come to my mind about how to set that attribute:
>
>   - build your own forked Python package that sets this
>   - build your own forked pip package that defaults to this
>

We definitely have the *ability* to use a stream branch for python3 or
python-pip, and build it in the flatpak-runtime package. But I'd really
prefer to avoid that, since that creates a fork we need to maintain every
time that these packages are updated in Fedora 36, and there's a
possibility of missing security updates.


>   - set it via a Python module that is imported from
>/usr/lib/python3.10/site-packages/_pip_use_sysconfig.pth
>
> However, forcing pip to use distutils is the opposite of future-proof.
> When looking for a permanent solution, you need to avoid distutils
> entirely.
>

A pip with a backported patch (or a rebase) + this approach sounds most
maintainable for Fedora 36. But if we think that the --prefix %{_prefix}

Python installation paths, pip, F36

[Owen Taylor]

[ At Miro's request, resending this to python-devel so the discussion can
be public ]

Hi Miro -

When rebuilding a package to include in a Flatpak, we want to install
*everything* under prefix=/app - that includes Python modules. (Paths will
be adjusted properly when running the Flatpak.)

For years, the way we did that is by installing a
/usr/lib64/python3.10/distutils/distutils.cfg:
===
[install]
prefix=/app
===

This is part of the flatpak-rpm-macros package that gets installed in the
buildroot for Flatpak rebuilds

In Fedora 36, this no longer works for 'pip install' - it seems that pip
unconditionally uses 'sysconfig' rather than 'distutils' to determine
install paths for Python >= 3.10.

I see that you filed https://github.com/pypa/pip/issues/10647 which landed
in pip for pip-22, but Fedora 36 / pip-21 this isn't present? And in any
case, that seems like it's something for 'sudo pip install' rather than
package installation. I actually don't really follow how the Python macros
are getting things installed into /usr/lib rather than /usr/local/lib.

Any advice about how we can make the installation into /app work? Hopefully
in a future-proof way...

Thanks!!!
Owen
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

What happened to umask?

[Owen Taylor]

For years, Red Hat Linux / Fedora systems have had a umask of 0002 for
regular users as part of the "user private group" scheme [*]. Basically the
idea is that you can set a directory group-sticky and use it as a common
work area for a group of users.

A change a couple of years ago seems to have partially changed this - the
code in /etc/profile was removed with the idea that it should be controlled
by pam_umask / login.defs instead.


https://pagure.io/setup/c/102b349c39e196cc1e34e645c9310acdab7afeef?branch=master
 https://bugzilla.redhat.com/show_bug.cgi?id=1722387

However, the corresponding code in /etc/bashrc was left .This means that
for a *login* shell (VT, ssh session, etc.) the umask is 0022 but for an
interactive *non-login* shell (e.g., gnome-terminal with default settings)
the umask stayed 0002.

I'm not sure how much the change from 0002 to 0022 was thought through -
that idea first appears in
https://bugzilla.redhat.com/show_bug.cgi?id=1722387#c4 with Tomas Mraz
saying:  I do not think that the default umask should be 002 for regular
users." - I would have expected a short change proposal, honestly.

It seems like we need to do one of two things:

 - Go back to the old behavior, maybe by using the usergroups option to
pam_umask and removing the code from /etc/bashrc
 - Or just go fully to 0022 by removing the code from /etc/bashrc.

What do people think? If the current situation has lasted for several
years, it clearly isn't *that* much of a concern to most people :-)

- Owen

[*]
https://docs.fedoraproject.org/en-US/fedora/latest/system-administrators-guide/basic-system-configuration/Managing_Users_and_Groups/#s2-users-groups-private-groups
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Make pkexec and pkla-compat optional (Self-Contained Change proposal)

[Owen Taylor]

On Wed, Feb 16, 2022 at 12:14 PM Ben Cotton  wrote:

> https://fedoraproject.org/wiki/Changes/polkit_recommends_pkla_pkexec
> [..]
> `pkexec` and `pkla-compat`
> ([https://src.fedoraproject.org/rpms/polkit-pkla-compat package]) are
> legacy tools that are no longer needed on a desktop and increase the
> attack surface as they are SetUID binaries (`pkexec`) or not
> maintained anymore (`pkla-compat`).


For pkexec, "no longer needed on a desktop" definitely does not reflect the
situation for Fedora Workstation and GNOME. If you run:

 grep org.freedesktop.policykit.exec.path /usr/share/polkit-1/actions/*

there is considerable usage - there are config files using pkexec provided
by, among others:

 gamemode, fedora-third-party, systemd, gnome-control-center,
gnome-system-monitor, gnome-settings-daemon, gvfs,

Would it be possible to rewrite all of the usage as D-Bus services? Yes -
but it would be considerable work and risk of new bugs and regressions.
(fedora-third-party is a recent addition by me - I considered not using
pkexec and writing a service instead, but it seemed like extra work and
complexity for little gain.)

If KDE or another desktop doesn't use pkexec, and there's a desire to split
pkexec out in packaging and add explicit dependencies on it, I'm not
opposed to that, but I don't think we should be calling pkexec legacy, and
it would require considerable (upstream, not just Fedora) changes to remove
the usage in Workstation.

- Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Make pkexec and pkla-compat optional (Self-Contained Change proposal)

[Owen Taylor]

On Thu, Feb 17, 2022 at 2:28 PM Adam Williamson 
wrote:

> On Wed, 2022-02-16 at 13:55 -0500, Neal Gompa wrote:
> > On Wed, Feb 16, 2022 at 12:38 PM Lennart Poettering
> >  wrote:
> > >
> > > On Mi, 16.02.22 12:12, Ben Cotton (bcot...@redhat.com) wrote:
> > >
> > > > `pkexec` and `pkla-compat`
> > > > ([https://src.fedoraproject.org/rpms/polkit-pkla-compat package])
> are
> > > > legacy tools that are no longer needed on a desktop and increase the
> > > > attack surface as they are SetUID binaries (`pkexec`) or not
> > > > maintained anymore (`pkla-compat`).
> > >
> > > I find this wording weird... I seriously doubt we should consider
> > > "pkexec" legacy. It's the much nicer approach to the "sudo" problem,
> > > as mentioned in earlier discussions...
> > >
> > > Splitting it off into a separate package might be OK, but claiming
> > > that the fact that it is a suid binary makes it "legacy" sounds really
> > > strange to me, by that means we should also mark "sudo", "su", "ping",
> > > "mount", "umount", "write", "passwd", … and so on "legacy", but I
> > > doubt we are at that point, are we?
> > >
> > > hence I am not against the feature but please tone down the wording
> > > regarding pkexec, it's misleading. Say you want to split it out to
> > > reduce the attack surface, but don't use the word "legacy" in its
> > > context.
> > >
> > > (dropping "pkla-compat" given its unmaintained state is Ok to be
> > > called "legacy" i guess)
> > >
> >
> > I think I'd go stronger and say I don't really see the value in
> > splitting out pkexec at all. I'd rather people have a default path to
> > do safer privilege escalation, and pkexec is way better than
> > sudo/doas/etc in that regard.
>
> This feels a bit unrealistic to me. In the real world, I can recall off
> the top of my head exactly zero docs, guides, articles, howtos etc.
> that use pkexec. They all use sudo. Like it or not, sudo is what people
> use. The sensible thing to do there is devote attention to making sure
> sudo is as secure as possible, or actually make some kind of big effort
> to convince people to use pkexec instead.
>
> But just shipping pkexec as well as sudo by default is IMHO not helping
> anything, all it does is add unnecessary attack surface. I bet you
> could shoulder-surf for an entire weekend at Flock and not see a single
> person type 'pkexec'.
>

Perhaps it actually works well that pkexec is used for "behind-the-scenes"
privilege escalation, and sudo is what people are familiar with for
interactive and sysadmin-configured use. PolKit and hence pkexec can make
decisions on things that sudo doesn't have an idea about like the idea of
"logged in at a graphical console", but they aren't really useful if you
just want to quickly run a command as root with authentication.

I just tried this, actually, for giggles. Two reasons it's a non-
> starter: it prompts for the root password, not for my user password (my
> user is an 'admin' so far as sudo etc. are concerned, but apparently
> not an 'admin' so far as interactive pkexec is concerned). I do not
> know the root password, it is intentionally a 24-character random
> string I would have to look up. And it prompts with one of those
> goddamn 'secure' GNOME popovers which prevents you accessing your
> password manager, so every time you hit one, you have to cancel it, go
> to your password manager, copy the password it wants, then trigger it
> again.
>

I think you misinterpreted the prompt. Assuming your user is in the wheel
group:

 "Authentication is needed to run '' as the superuser'

Isn't asking for the root password, but rather your password to do
something as root.

- Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Third-party Software Mechanism (System-Wide Change proposal)

[Owen Taylor]

On Sat, Jul 3, 2021 at 4:39 PM Mark Otaris  wrote:
>
> I don’t agree with this change, as it seems obvious that many users who do 
> not want proprietary software installed do not want repositories with 
> proprietary software in them installed either (whether or not these 
> repositories are enabled) and would want to have to opt-in to that too. 
> Additionally, disabled repositories show up from time to time, bugs allowing, 
> so they are not as inactive as the name implies. Not having them installed 
> serves as a safeguard.

Hi Mark, thanks for the feedback!

While there can be bugs of any type, I don't see any reason to
*expect* a bug that would make dnf or PackageKit show search results
or listings from disabled repositories.Wouldn't that be noticed and
fixed quickly?

Is the number of users who don't even want a text file mentioning the
existence of third-party software on their system significant? If
FESCO feels that people wanting to remove the package entirely is a
concern, we could soften the proposed fedora-release-workstation
Requires: on fedora-workstation-repositories to a Recommends, to allow
removing the package. I'd personally prefer to leave the Requires to
prevent silent breakage.

> Also, users who use some software from the third-party repositories likely 
> *do not* want all of them enabled

It will be possible to opt-out and then enable individual
repositories, or opt-in and disable individual repositories. What it
doesn't provide is protection against a repository accidentally or
intentionally offering an upgrade to a system package. I think this
was one of the things that the disabled=1, disabled_metadata=0 system
was meant to make better, but the dnf mainainers have explicitly
expressed disinterested in implementing this in the past. As a
PackageKit-only thing, we're providing users a fragmented and strange
user experience. And there's even plans to eventually retire and
remove PackageKit in favor of using dnf everywhere.

Perhaps a more productive approach to this issue would be to allow a
repository to be marked "LeafOnly" - meaning the packages it contains
should not be used to satisfy dependencies of other repositories, and
should not be considered for upgrades of packages installed from other
repositories. Not considering how hard that would be to actually
implement via libsolv and what corner cases would be a problem:-)

> The stated benefit of the proposed change (“the removal of the state where 
> the user has opted in to third party repositories but they are not actually 
> enabled”) is not the benefit; the actual benefit that is wanted is an 
> improvement to the user experience that is made easier to provide by 
> installing the repos by default.

Well, true - if it didn't affect either the cli or gui user
experience, this state wouldn't be a problem! :-)

Thanks!
Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Filtered Flathub Applications (System-Wide Change proposal)

[Owen Taylor]

On Sat, Jul 3, 2021 at 6:14 PM Fabio Valentini  wrote:
>
> On Tue, Jun 29, 2021 at 10:26 PM Ben Cotton  wrote:
> >
> > https://fedoraproject.org/wiki/Changes/Filtered_Flathub_Applications
> >
> > == Summary ==
> > Enabling third-party repositories will now create a Flathub remote
> > that is a filtered view of Flathub.
>
> I have a few questions / concerns with this proposal, primarily these two:
>
> 1. I wonder if this might be a possible source of confusion /
> frustration for users. Examples:
> - "Why are my local search results not showing application X from flathub?"
> - "Why can't I install application X when I have flathub repo enabled?
> It is listed on the flathub website."

Yes, this is a bit of a concern. It would be nice to be able to show
that the repo is the Fedora-filtered version in the 'flatpak-remotes'
list and in the GNOME Software dialog.  We'll think about if there is
some way to handle this nicely. Maybe we could get a patch upstream to
add a 'FilterNote=Fedora Selections' that gets removed along with the
Filter (see below).

> 2. How is the replacement with unfiltered flathub remote implemented?
> Looking at the instructions on flathub.org, this adds a new remote
> with the "--if-not-exists" flag.
> If the remote already exists, wouldn't that command just do nothing,
> and leave the filtered, existing remote in place?
> Is this done with ugly hard-coded non-upstreamable hackery in the
> "flatpak remote-add" command on Fedora? I hope not ...

No, there's code for this already upstream. Quoting from the
flatpak-flatpakrepo(5) man page:

   Filter (string)
   The path of a local file to use to filter remote refs. See
flatpak-remote-add(1) for details on the format of the file.

   Note: This field is treated a bit special by flatpak
remote-add. If you install a remote with --if-not-exists then and the
remote
   is already configured, then the filter field of the remote
configuration will be update anyway. And, if the filter field is *not*
   specified then any existing filters are cleared. The goal
here is to allow a pre-configured filtered remote to be replaced with
the
   regular one if you add the normal upstream (unfiltered)
flatpakrepo file.

Regards,
Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Filtered Flathub Applications (System-Wide Change proposal)

[Owen Taylor]

On Wed, Jun 30, 2021 at 9:26 AM Vitaly Zaitsev via devel
 wrote:
>
> On 30/06/2021 14:44, Owen Taylor wrote:
> > Setting up an independent non-profit, and maintaining it's non-profit
> > status is a quite involved activity. (details depend on the country,
> > of course!)
>
> If Flathub want to be a trustworthy repository, it should be done.
>
> > Hopefully this
> > provides some assurance that Flathub won't suddenly start doing
> > something entirely different.
>
> No, it doesn't. FreeNode situation is an example.

While the GNOME Foundation could license or transfer the Flathub name
to a commercial entity if it determined it was in the public's best
interest, so could a hypothetical Flathub Foundation. In the end,
Fedora doesn't have a lot of leverage to demand that the Flathub
community organize itself as an independent non-profit! That being
said, if we get some Flathub maintainers to come to the FESCO meeting,
I'm sure they would be happy to answer questions about how Flathub is
run and decisions are made.

> > If we lost trust in Flathub, Fedora would also have the ability to
> > update the filter to have *no* applications in it.
>
> Every application with --filesystem=host or --filesystem=home can drop
> all filters, enable new repositories, etc.

There's a distinction to be made between dubious behavior (inserting
ads in applications, say) and out-and-out malware. My comment was
aimed at the former - different things would need to be done in the
latter case. I don't see any reason to expect Flathub to be knowingly
engaging in either. We currently offer various third-party RPM
repositories where the packages run without any sandboxing at all.

> > Flathub is a packaging community, like Fedora. Being a professional is
> > definitely not a criteria for contributing to Fedora.
>
> All Fedora packagers must be sponsored first and they know at least
> Fedora packaging guidelines. On Flathub anyone can add anything.
>
> > This is something that definitely can be and will be examined when
> > reviewing applications for inclusion in the Fedora filter.
>
> This is not a panacea. Some Flathub maintainers added --filesystem=host
> or --filesystem=home after the initial review.

I would imagine that when it happens, it's typically not because the
maintainer is trying to sneak something over on their users (and users
will get prompted on upgrade), but because it turned out there were
issues with the more restrictive permissions.

The main point of sandboxing is not to protect the users against the
Flathub maintainers, or the app authors. It's to protect the users
from malicious actors exploiting vulnerabilities in the application.
By checking that the application has reasonable permissions at review
time, we can get some idea of whether the Flathub maintainer knows how
to use permissions, but yes, we are delegating some trust to Flathub
here in the case where this changes.

The Flatpak and Flathub communities would definitely appreciate help
in figuring out how to nudge Flatpak packagers and application authors
towards more restrictive permissions.

- Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Third-party Software Mechanism (System-Wide Change proposal)

[Owen Taylor]

On Wed, Jun 30, 2021 at 7:53 AM Zbigniew Jędrzejewski-Szmek
 wrote:

> > * There is a fedora-third-party package with a
> > fedora-third-party script with
> > enable/disable/refresh/query subcommands. The status is
> > stored in /etc/fedora-third-party.conf
> > * Packages like fedora-workstation-repositories that
> > include third-party repositories will drop config files into
> > /etc/fedora-third-party.d/*.conf. There will be a
> > post-transaction file trigger to run fedora-third-party
> > refresh, which applies the users opt-in status to newly
> > installed repository files.
>
> For packaged stuff, please do:
>
>   s|/etc/fedora-third-party.conf|/usr/lib/fedora-third-party.conf|
>
> We shouldn't add yet more stuff in /etc/.

Yes, agreed. Thanks for the suggestion!

Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Filtered Flathub Applications (System-Wide Change proposal)

[Owen Taylor]

On Wed, Jun 30, 2021 at 7:44 AM Ian McInerney  wrote:

>> Roughly speaking, the criteria for including software is a) will not
>> cause legal or other problems for Fedora to point to b) does not
>> overlap Fedora Flatpaks or software in Fedora that could easily be
>> made into a Flatpak c) works reasonably well. For Fedora 35, We expect
>> to include all software from the top 50 most popular applications on
>> Flathub that meet these criteria plus selected other software of
>> interest to the Fedora target audience - Fedora community members are
>> welcome to propose additions.
>
> Does this mean that FESCO is now forcing Fedora packagers to maintain Fedora 
> Flatpaks and respond to their related issues when many of them seem to be 
> created without the packagers' knowledge/consent, and there is no 
> documentation in the packaging guidelines/wiki about how to actually do 
> anything for them, or information about where the manifests for them actually 
> live?

This proposal doesn't really change anything with respect to Fedora
Flatpaks. (Docs for Fedora Flatpaks:
https://docs.fedoraproject.org/en-US/flatpak/)

Are you concerned that there's some implicit threat that if you don't
create a Fedora Flatpak for your Fedora RPM, users will be directed to
the Flathub version? We're really not anticipating overlap between the
set of applications packaged in Fedora and the set included in the
filtered-view of Flathub. Any exceptions to that would definitely have
to be coordinated closely with the relevant package maintainer.

Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Filtered Flathub Applications (System-Wide Change proposal)

[Owen Taylor]

On Wed, Jun 30, 2021 at 6:42 AM Vitaly Zaitsev via devel
 wrote:
>
> On 29/06/2021 22:25, Ben Cotton wrote:
> > Enabling third-party repositories will now create a Flathub remote
> > that is a filtered view of Flathub.
>
> I don't trust Flathub at all, because they don't want to register a
> non-profit organization. They can easily sell their business like
> FreeNode did recently.

Setting up an independent non-profit, and maintaining it's non-profit
status is a quite involved activity. (details depend on the country,
of course!)

Flathub's non-donated hardware resources are owned by the GNOME
Foundation (a registered non-profit) and the GNOME Foundation also
owns the Flathub trademark (See:
https://foundation.gnome.org/logo-and-trademarks/). Hopefully this
provides some assurance that Flathub won't suddenly start doing
something entirely different.

If we lost trust in Flathub, Fedora would also have the ability to
update the filter to have *no* applications in it.

> Flathub relies on upstreams, not professional maintainers. Most of
> upstream developers don't know how to package software properly. They
> bundle lots of libraries, don't use C/C++ build hardening flags, etc.

Flathub is a packaging community, like Fedora. Being a professional is
definitely not a criteria for contributing to Fedora. :-)

> A lot of applications from Flathub uses --filesystem=host or
> --filesystem=home, which means they don't use Flatpak isolation at all.

This is something that definitely can be and will be examined when
reviewing applications for inclusion in the Fedora filter.
Unfortunately, a lot of interesting software can't be completely
sandboxed - because it, say, uses X11 rather than Wayland. But where
thing *can* be sandboxed they should be sandboxed.

> Due to the bundling of a large number of libraries, some applications
> have critical vulnerabilities with assigned CVE numbers: CVE-2020-12284,
> CVE-2019-17498, CVE-2018-11235, CVE-2018-17456, CVE-2017-9780.

There are definitely improvements that could be made to CVE response
policies in Flathub, and I know automated scanning was being worked
on. If we were activitely looking to delegate software that is
packaged in Fedora to Flathub, I think we'd need to have a very high
bar here. But as a source of *additional* software, I think the
standard should be comparison to wherever the Fedora user would get
the software from otherwise. When this is scheduled for FESCO
discussion, I'll try to see if we can get some Flathub maintainers to
attend in case people have questions in this area (or other areas).

> > Roughly speaking, the criteria for including software is a) will not
> > cause legal or other problems for Fedora to point to b) does not
> > overlap Fedora Flatpaks or software in Fedora that could easily be
> > made into a Flatpak c) works reasonably well.
>
> Should be added also:
>
> d) doesn't exists in Fedora RPM repositories.

The text you qouoted said "or software in Fedora that could easily be
made into a Flatpak" - I left some wiggle room there, but certainly if
we were including anything that overlapped Fedora RPMs, one of two
things would need to be true:

 * Installation from Flathub would need to be prioritized after
installation from Fedora RPMs
 * Fedora Silverblue would need it's own filter list with additional
applications

In the immediate future, our plan is to avoid any such overlap.

> > Fedora users who opt-in to third-party software repositories will have
> > immediate access to more software out-of-the-box.
>
> Fedora Silverblue must have its own Flatpaks and do not rely on third-party 
> repositories.

This is not about replacing software that is included in Fedora. It's
about providing access to software *not* included in Fedora.

Thanks for the feedback!
Owen


- Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Third-party Software Mechanism (System-Wide Change proposal)

[Owen Taylor]

On Wed, Jun 30, 2021 at 6:50 AM Lars Seipel  wrote:
> >[Find out 
> >more...](https://fedoraproject.org/wiki/Workstation/Third_Party_Software_Repositories)
> >* If the user leaves the box checked, GNOME Initial setup runs
> >`fedora-third-party enable`.
>
> Leaves the box checked? Either I'm misunderstanding or this contradicts
> the remaining text which talks about "opt-in".

Thanks for noticing the discrepancy!

The current mockup for how the page in GNOME Initial Setup should look
is at the top of:

 https://hackmd.io/@owtaylor/fedora-third-party-repos

and is in-fact a classic opt-in. (*)

The mockup tries to reduce the risk of an inexperienced user being
confused by terms like "third party" and "repository" by mentioning
specific software.I'll look at embedding that in the change proposal
and will make sure that the text is consistent.

- Owen

(*) The text of the Third-Party Repository policy is "the user must
explicitly enable third-party repositories to install from them" - I
don't think a checked-by-default box would be in agreement with that.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+

[Owen Taylor]

On Fri, May 7, 2021 at 12:17 PM Jerry James  wrote:
>
> On Fri, May 7, 2021 at 9:45 AM Michael Catanzaro  wrote:
> > Um... not that I know of.
> >
> > Honestly, I don't know anything about GLib 1 other than that it's very
> > old. I think if I were trying to port Sagemath, I would just upgrade
> > the build system to GLib 2 and see how many compiler errors you get
>
> It turns out that surf-geometry is the only package on that list that
> directly depends on glib 1.  The others depend on surf-geometry,
> directly or transitively.  That's a very old (and, frankly, buggy)
> piece of software there.  I'll see what can be done with it.

GLib 2 was quite compatible with GLib 1 - there were lots of additions
but few breaking changes. But it looks like the dependency in
surf-geometry is a GTK 1 user interface (written in C++ with a bit of
custom glue, with Xlib usage mixed in.) and a GTK 1 to GTK 2 port is
more work. Not that hard for someone experienced in the GTK *of that
time* , but at this point, it would be like translating Chaucer into
Elizabethan English. And porting to GTK 3 or GTK 4 would be a bigger
job. I think this pretty clearly falls into the "if someone cared
about this GUI, they would have ported it from GTK 1 long ago" bucket.

But it also looks like it could just be disabled without affecting
anything else.

Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Flatpak install and DNF removal

[Owen Taylor]

On Sun, May 2, 2021 at 9:46 PM Ian McInerney  wrote:
[...]
> This is how to reproduce it:
> 1) Use the Cinnamon live CD
> 2) Install a random flatpak (note, since this is on live you have to deal 
> with the space issue first)
> sudo ostree --repo=/var/lib/flatpak/repo/ config set 
> core.min-free-space-size 0MB
> sudo flatpak install org.gnome.Mahjongg
> 3) Remove xdg-desktop-portal-gtk
>
> In step 3 it will also want to remove flatpak, but in step 2 I made a 
> conscious choice to install a flatpak - so this will then mean I lose access 
> to that flatpak I had installed. This can of course be prevented by doing 
> "dnf mark install flatpak", but that is another manual step you have to do.
>
> This leads to the question: how can this be handled? When a user uses Flatpak 
> to install a program, I would assume their expectation is that flatpak 
> shouldn't be removed unless the user requests it explicitly (so not this 
> behavior). I guess there are 2 ways to really fix this:
> 1) Mark flatpak as being user installed once at least one flatpak is 
> installed.
> 2) Add flatpak as an explicit program on all live CDs it is included on right 
> now.
>
> The cleanest would probably be 1, but can that even be done?

Anything can be done (in this case, probably as a DNF plugin), but
yes, that would involve mixing layers in a way we don't typically do,
and which could be confusing to users.

I think 2) is sufficient - whether Flatpak is present or not is a
pretty fundamental system level decision, and not something that
should happen as the result of a dependency chain.  For the Cinnamon
desktop, xdg-desktop-portal-gtk should also be an explicit package,
since having some portal implementation is necessary for the correct
operation of Flatpaks.

Owen


Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: GNOME only: KeepassXC quirks

[Owen Taylor]

On Sat, May 1, 2021 at 10:09 AM Neal Gompa  wrote:
>
> On Sat, May 1, 2021 at 9:48 AM Owen Taylor  wrote:
> >
> > On Sat, May 1, 2021, 7:51 AM Neal Gompa  wrote:
> >>
> >> In general, I'd like to see if we can figure out *why* Mutter isn't
> >> doing the right thing for Qt applications and why they're breaking
> >> this way, because the fact that they're fine in Plasma Wayland and not
> >> on GNOME Wayland points to Mutter needing work here.
> >
> >
> > That doesn't make any more logical sense than "the fact that GTK 
> > applications work fine with Mutter points to Qt needing work here." Without 
> > a diagnosis, it's impossible to say.
> >
>
> GTK applications work fine on KWin (modulo some missing Wayland
> protocols not being implemented in GTK3), so I'm reasonably confident
> that the problem is in Mutter.

How is that relevant? Qt is making some assumptions about the
compositor behavior which don't hold with mutter - and we don't know
whether it's Qt relying on things that accidentally work with Kwin, or
Mutter not properly implementing parts of the Wayland protocol that
GTK doesn't use. [roughly speaking ... not comprehensively listing all
possibilities]

> > If we can put someone who understands Qt together with someone who 
> > understands Mutter it should be possible to figure out what is going on. If 
> > the fix is hard, then reverting the Qt change until F35 might be needed, 
> > but patching a reversion to X into Qt apps one-by-one doesn't seem like 
> > something we'd want to do: it would leave unpatched apps affected, we might 
> > forget to remove some of the patches, and it's going to make things 
> > altogether more confusing.

> I agree, do we know anyone who understands Mutter that could work with
> someone who understands Qt to figure this out? I've got a couple of
> folks in mind who could help on the KDE side (who I've CC'd to this
> email).

Added Jonas Adahl (all things output), Carlos Garnacho (all things
input) and Oliver Fourdan (compat problems expert) to the Cc:- one of
them should be able to help.

Since the context is trimmed, the thread here is:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/PZCV4KM5W2PI34GT2PK6QUGOVODVA6HW/

Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: GNOME only: KeepassXC quirks

[Owen Taylor]

On Sat, May 1, 2021, 7:51 AM Neal Gompa  wrote:

>
> Note it only looks fine as long as you're not using fractional
> scaling. Once framebuffer/fractional scaling is enabled in Mutter, it
> looks absolutely terrible, because X11 applications are not scaled
> properly. There are also other glitches if Qt5 applications run as X11
> apps, and I'm not sure if some prominent Qt5 applications expose the
> correct functionality in X11 mode (e.g. OBS Studio uses PipeWire for
> screencasting when it is in Wayland mode).
>
> In general, I'd like to see if we can figure out *why* Mutter isn't
> doing the right thing for Qt applications and why they're breaking
> this way, because the fact that they're fine in Plasma Wayland and not
> on GNOME Wayland points to Mutter needing work here.
>

That doesn't make any more logical sense than "the fact that GTK
applications work fine with Mutter points to Qt needing work here." Without
a diagnosis, it's impossible to say.

If we can put someone who understands Qt together with someone who
understands Mutter it should be possible to figure out what is going on. If
the fix is hard, then reverting the Qt change until F35 might be needed,
but patching a reversion to X into Qt apps one-by-one doesn't seem like
something we'd want to do: it would leave unpatched apps affected, we might
forget to remove some of the patches, and it's going to make things
altogether more confusing.

Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Debuginfod By Default (Self-Contained Change proposal)

[Owen Taylor]

On Wed, Apr 21, 2021 at 4:09 PM Frank Ch. Eigler  wrote:

> A direct way would be for someone to koji-download the given rpm, and
> hand-extract/compare the files.  (It's obviously not economical.)
>
> > Thus, the debuginfod server becomes a juicy target.
>
> Yes.  The Changes FAQ section discusses this topic.
>
> Unfortunately, in the absence of per-file signatures generated by the
> build system, and securely distributed out-of-band, I can't think of any
> way to provide client-side verifiability of a debuginfod type service.
> That's independent of any particular level of server code robustness.

I think there *are* solutions that reduce the attack surface so that
the public facing server no longer needs to be trusted.

Service 1: indexes signed debuginfo files in Fedora, verifying RPM
signatures, puts the object IDs and hashes into a Merkle tree
[Root node of Merkle tree is signed]
Service 2: serves out those debuginfo files to clients, along with
root signature and the nodes from the root to the file of interest

But I don't want to see this proposal blocked on implementing
something that technically complex - I think it offers big benefits to
Fedora users as is. Certainly there are other programs that are
typically run without sandboxing by developers and connect to network
services -  even entirely untrusted network services - and we
typically consider that acceptable.

Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Debuginfod By Default (Self-Contained Change proposal)

[Owen Taylor]

On Sun, Apr 11, 2021 at 1:52 PM Owen Taylor  wrote:

>
>
> On Sat, Apr 10, 2021 at 9:55 AM Michael Catanzaro 
> wrote:
>
>> On Sat, Apr 10 2021 at 08:03:09 AM -0400, Owen Taylor
>>  wrote:
>> > Did you notice that it also works for the Fedora Flatpaks (thanks,
>> > Frank!) - basic proof of concept:
>> >
>> >   $ flatpak run --command=sh --filesystem=home --share=network --devel
>> > org.gnome.Aisleriot
>> >   [ org.gnome.Aisleriot ~]$
>> > DEBUGINFOD_URLS=https://debuginfod.stg.fedoraproject.org/
>> > DEBUGINFOD_CACHE_PATH=~/.cache/debuginfod_client gdb /app/bin/sol
>> >
>> > (Without the --filesystem=home and DEBUGINFOD_CACHE_PATH, the cache
>> > ends up in ~/.var/app/org.gnome.Aisleriot/cache/debuginfod_client/)
>>
>> I think that's OK for a manual debugging workflow, since it's pretty
>> rare to want to do that under flatpak in my experience. Normally what's
>> most important to me is being able to easily generate a backtrace for a
>> previous crash using 'flatpak-coredumpctl'. Ideally
>> 'flatpak-coredumpctl' would handle setting the right environment
>> variables and executing flatpak with the right permissions to make it
>> work. (In the future, ABRT could do something similar.)
>>
>
> I think we could store the debuginfo urls in repository metadata (ostree
> summary / oci json index) and have flatpak automatically set things up for
> 'flatpak run --devel'. This isn't Fedora specific - e.g. there's an
> eventual goal to have a debuginfo server for Flathub as well.
>

Filed an upstream pull-request for this (still needs some work):

https://github.com/flatpak/flatpak/pull/4222

- Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Debuginfod By Default (Self-Contained Change proposal)

[Owen Taylor]

On Sat, Apr 10, 2021 at 9:55 AM Michael Catanzaro 
wrote:

> On Sat, Apr 10 2021 at 08:03:09 AM -0400, Owen Taylor
>  wrote:
> > Did you notice that it also works for the Fedora Flatpaks (thanks,
> > Frank!) - basic proof of concept:
> >
> >   $ flatpak run --command=sh --filesystem=home --share=network --devel
> > org.gnome.Aisleriot
> >   [ org.gnome.Aisleriot ~]$
> > DEBUGINFOD_URLS=https://debuginfod.stg.fedoraproject.org/
> > DEBUGINFOD_CACHE_PATH=~/.cache/debuginfod_client gdb /app/bin/sol
> >
> > (Without the --filesystem=home and DEBUGINFOD_CACHE_PATH, the cache
> > ends up in ~/.var/app/org.gnome.Aisleriot/cache/debuginfod_client/)
>
> I think that's OK for a manual debugging workflow, since it's pretty
> rare to want to do that under flatpak in my experience. Normally what's
> most important to me is being able to easily generate a backtrace for a
> previous crash using 'flatpak-coredumpctl'. Ideally
> 'flatpak-coredumpctl' would handle setting the right environment
> variables and executing flatpak with the right permissions to make it
> work. (In the future, ABRT could do something similar.)
>

I think we could store the debuginfo urls in repository metadata (ostree
summary / oci json index) and have flatpak automatically set things up for
'flatpak run --devel'. This isn't Fedora specific - e.g. there's an
eventual goal to have a debuginfo server for Flathub as well.

For coredump+debuginfod you can actually do the backtrace with a system (or
toolbox) gdb instead of downloading the SDK ... if we want to deal with
that complexity, we could add a mode like that into flatpak-coredumpctl.

One gap here is that it's a little hard to figure out what exact revision
of the Flatpak and runtime coredumped - you can reverse-engineer that out
of COREDUMP_PROC_MOUNTINFO information in the journal.

As you say, the eventual goal would be ABRT support.

Regards,
Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Debuginfod By Default (Self-Contained Change proposal)

[Owen Taylor]

On Fri, Apr 9, 2021 at 11:01 AM Michael Catanzaro  wrote:
>
> On Fri, Apr 9 2021 at 04:19:31 PM +0200, Lars Seipel 
> wrote:
> > Really cool. Thanks for making it happen.
>
> I started testing the staging server yesterday. It seems a little slow
> -- I worry for anyone debugging anything that links to WebKit, which on
> the desktop is a lot -- but otherwise it works *very* well. I'm
> impressed. Very nice.

Did you notice that it also works for the Fedora Flatpaks (thanks,
Frank!) - basic proof of concept:

  $ flatpak run --command=sh --filesystem=home --share=network --devel
org.gnome.Aisleriot
  [ org.gnome.Aisleriot ~]$
DEBUGINFOD_URLS=https://debuginfod.stg.fedoraproject.org/
DEBUGINFOD_CACHE_PATH=~/.cache/debuginfod_client gdb /app/bin/sol

(Without the --filesystem=home and DEBUGINFOD_CACHE_PATH, the cache
ends up in ~/.var/app/org.gnome.Aisleriot/cache/debuginfod_client/)

- Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora GNOME Shell rendering problem

[Owen Taylor]

On Tue, Dec 22, 2020 at 5:31 AM Michael Schwendt  wrote:
>
> On Mon, 21 Dec 2020 08:09:50 -0500, Owen Taylor wrote:
>
> > Most likely the GPU driver. This is a symptom of a corrupted Xft glyph
> > cache inside the Xwayland X server.
> >
> > (It's not impossible that the glyph was corrupted before upload by
> > some other component, but that's much less likely - especially if it
> > seems to be hardware dependent.)
>
> It's been observed on Nouveau driver based installations / with no Nvidia
> related packages from RPM Fusion as to test whether default installations
> of Fedora Workstation would work acceptably out of the box.

I'd suggest filing an issue against:

 https://gitlab.freedesktop.org/xorg/xserver

Even though the fix is more likely to be in Mesa - because it's not
going to be possible to investigate this just in Mesa alone - the
first step would be for a developer to figure out a working reproducer
with the X server. Make sure, however, that your bug report includes
the specific kernel and mesa versions, and the details of the video
hardware (lspci -v)

Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora GNOME Shell rendering problem

[Owen Taylor]

On Mon, Dec 21, 2020 at 4:37 AM Michael Schwendt  wrote:
>
> In the attached screenshot excerpt it's the bold "a" character that is
> missing everywhere within the entire main window of Claws Mail. In other
> cases, it's a different character. Sometimes it is not missing but
> visually corrupted, looking like random "garbage" data.
>
> Fedora 33 x86_64 GNOME Shell on Wayland, and Claws Mail is based on GTK+ 2.
>
> What part of the rendering process could be the culprit? Pango?

Most likely the GPU driver. This is a symptom of a corrupted Xft glyph
cache inside the Xwayland X server.

(It's not impossible that the glyph was corrupted before upload by
some other component, but that's much less likely - especially if it
seems to be hardware dependent.)

Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal

[Owen Taylor]

So, this was discussed quite a bit in
https://pagure.io/fedora-workstation/issue/71 and the conclusion that
the Workstatopn Working Group came to 3 months ago was that we didn't
want to do this. We basically understood that main way of using
thermald was to use the proprietary dptfxtract tool to extract a
profile from ACPI - and as such, thermald wasn't something Fedora
should install by default. This functionality can't be properly
integrated into Fedora and "just work" for users if it requires a
proprietary tool and extra steps.

After seeing the submission this morning, we talked to Benjamin Berg
on our call today, and he said that the main reason that he submitted
this despite the earlier discussion was that he recently was told by
an OEM that when run without a profile it made a big difference on
some of their models. We asked Benjamin if he could provide more
details about what models and the difference in performance - he will
go back to the OEM and ask for more information, and we'll discuss
this again at our call next week.

- Owen


On Tue, Jun 30, 2020 at 9:27 AM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/ThermalManagementWS
>
> == Summary ==
> Better thermal management and peak performance on Intel CPUs by including 
> thermald in the default install.
>
> == Owner ==
> * Name: [[User:benzea| Benjamin Berg]]
> * Email: bb...@redhat.com
>
> * Name: [[User:ckellner| Christian J. Kellner]]
> * Email: ckell...@redhat.com
>
> * Product: Workstation
> * Responsible WG: Workstation
>
>
> == Detailed Description ==
>
> Modern Intel-based systems provide sensors and methods to monitor and control 
> temperature of its CPUs. The Thermal daemon will use those sensors to monitor 
> the temperature and use the best available method to keep the CPU in the 
> right temperature envelop. On certain systems this is needed to reach the 
> maximal performance. thermald will for example use the PPCC power table to 
> set power limits (when available, see for example 
> https://www.mail-archive.com/kernel-packages@lists.launchpad.net/msg411614.html).
>  This is for example the case on Ice Lake, where thermald can increase the 
> performance of the out-of-the-box behaviour of Fedora.
>
> Not strictly necessary, but *further* improvements can be achieved by using 
> per-model thermald configurations. The most straight forward way of using 
> those is for the user to install dptfxtract (available from rpmfusion). At 
> least parts of what dptfxtract can already do may be integrated into thermald 
> in the future thanks to the reverse engineering work done by Matthew Garret 
> (see https://github.com/intel/thermal_daemon/tree/mg_patches_test, 
> https://github.com/intel/thermal_daemon/pull/224). Should the reverse 
> engineering effort be merged, or if the user installs dptfxtract, then they 
> can expect a performance boost on some machines.
>
> Theoretically one could ship appropriate per-machine configurations as a 
> separate package (or inside thermald). However, this is not part of the 
> proposal for a number of reasons:
>  1. It is not clear how the configuration data can be collected
>  2. We do not currently have an implementation to load such configuration data
>  3. This may become obsolete with if the reverse-engineering effort continues 
> and is merged (or picked up by Fedora)
>
> For a more details explanation please consult Intel's 
> [https://01.org/linux-thermal-daemon/documentation/introduction-thermal-daemon
>  introduction] to thermald.
>
> == Benefit to Fedora ==
> Better out-of-the-box experience due to improved cooling methods and 
> performance on Intel systems. This affects many modern laptops (e.g. the Ice 
> Lake platform). On affected machines, Fedora would continue to have poorer 
> performance compared to other distributions.
>
> == Scope ==
> * Proposal owners:
>  - Include the thermald package in the default Workstation install
>
> * Other developers: N/A (not a System Wide Change)
> * Release engineering:
> * Policies and guidelines: N/A (not a System Wide Change)
> * Trademark approval: N/A (not needed for this Change)
>
> == Upgrade/compatibility impact ==
> N/A (not a System Wide Change)
>
> == How To Test ==
>
> Install the packages and use e.g. turbostat to monitor the performance. 
> Improvements may only be visible if the non-free dptfxtract package is also 
> installed.
>
> == User Experience ==
>  - Better performance on certain hardware
>  - Better cooling of CPUs on certain hardware
>
> == Dependencies ==
> N/A (not a System Wide Change)
>
> == Contingency Plan ==
> * Contingency mechanism: Don't ship package by default
> * Contingency deadline: N/A (not a System Wide Change)
> * Blocks release? N/A
>
>
> --
> Ben Cotton
> He / Him / His
> Senior Program Manager, Fedora & CentOS Stream
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an 

Re: Disappearing mouse pointer

[Owen Taylor]

On Thu, Aug 8, 2019 at 2:34 PM Antonio M 
wrote:

> I am the reporter of bug
> https://bugzilla.redhat.com/show_bug.cgi?id=1738614
> I have never such an issue before kernels 5..2.x and it is not always true
> that clicking on notation bar solves the issue
>

Do you think you could try downgrading your system to an older kernel? If
that fixes the issue, that woudl make it clear that it's not some other
package that was coincidentally upgraded at the same time as the kernel.

Thanks!
Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Disappearing mouse pointer

[Owen Taylor]

Recently filed bugs about similar issues:

https://bugzilla.redhat.com/show_bug.cgi?id=1738614
https://bugzilla.redhat.com/show_bug.cgi?id=1739169

Not sure if they are the *same* problem or different problems. They
look like the same issue (cursor only visible over application
windows) - but one reporter claims is started with a kernel upgrade,
and the other reporter reports an associated shell backtrace in their
log. And while a kernel upgrade could cause this (some problem with
overlays in the intel driver, perhaps), or the backtrace could
potentially cause this (shell is confused about what is an application
window and what is not), it's unexpected that a kernel upgrade would
cause the backtrace!

More information about a) whether that backtrace occurs for everybody
who is seeing the problem b) whether it was associated with a kernel
upgrade, and whether downgrading to an older kernel helps would
definitely be useful!

Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Owen Taylor]

On Fri, Mar 22, 2019 at 1:04 PM Japheth Cleaver  wrote:
>
> On 3/21/2019 3:23 PM, Richard W.M. Jones wrote:
>
> So what?  On Fedora /bin/sh is bash, and bash is a fine shell.
>
> All this nonsense of using dash for /bin/sh on Debian is IMO a
> pointless bunch of make-work.
>
> Fedora has certainly made a lot of make-work projects over the last decade, 
> under arguably more questionable reasoning.

Assuming that Fedora *has* had make-work projects, that's not a
justification to create more of them!

> IMO the situation that we're in now ("Assume you're running in bash, but 
> called as -/bin/sh") is a worst-of-both-worlds middle ground, somewhat akin 
> to mandating webpages be written in IE Quirks Mode for all time. It's neither 
> pedantically correct, nor flexible for users and downstreams. And the 
> resolution from all of this last time remains lacking in the guarantees that 
> an independent spec should have:

Any change here would need some strong justification - and allowing
users or derived distributions to replace /bin/sh with non-bash is not
something that I think there's any interest in. An argument could be
made for spec-file portability, but considering the amount of
Fedora-specific macros that we *want* packagers to use, that's not
obviously that convincing either.

Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Idea to add defaultfont(:lang=xx) rpm Provides to default font packages

[Owen Taylor]

On Thu, Feb 21, 2019 at 3:04 AM Peng Wu  wrote:
>   When the langpack packages Requires font(:lang=xx), it will pull in
> one random font package choose from several fonts packages which
> Provides font(:lang=xx).
>
>   To fix random fonts dependencies problem, I think maybe we can
> manually add "defaultfont(:lang=xx)" Provides to default font packages.
> And Requires "defaultfont(:lang=xx)" in langpack packages.

Would it work better if the langpack packages required a specific
font? Them, to change the default font for lang-xx, we can just edit
the langpack package, rather than having to move the virtual provide
from one package to another package.

Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Can't figure out how to build flatpaks

[Owen Taylor]

On Thu, Jan 31, 2019 at 12:23 PM Pete Walter  wrote:
> I've noticed that someone created a flatpak build for one of my packages 
> (feedreader), but it's horribly out of date: flatpak has 2.5.1 vs rpm has 
> 2.7.0. I've been trying to update the flatpak build, but not much luck here. 
> The documentation is pretty verbose, but seems to miss some crucial steps and 
> nothing really works.

Thanks for trying it out, and sorry that you are having problems!

[...]
> Up until here everything seems to check out and download correctly, but then 
> when I do:
>
> $ flatpak-module local-build --install
[...]
> module_build_service.errors.UnprocessableEntity: None of the base module 
> (platform) streams in the buildrequires section could be found

This is a poor error message. What it means is that your buildrequires
is missing:

 platform: [f29]

(for other modules, you may want platform: [] to build against all
streams, but that doesn't make so much sense for Flatpaks, where a
single build will work on multiple Fedora versions.)

Requiring all modules to depend directly on platform instead of just
indirectly through (in this case, flatpak-runtime) is a change in MBS
as aof a few months ago, 'fedmod rpm2flatpak' will now add this
dependency automatically but the feedreader.yaml modulemd file is old.
You can  run
'fedmod rpm2flatpak --force --flatpak-common --flathub=feedreader
feedreader' to update the files in modules/feedreader, and commit the
changes if they look good. (I've turned over modules/feedreader to you
in src.fedoraproject.org.)

>   - buildrequires:
>   flatpak-runtime: [f29]
> requires:
>   flatpak-runtime: [f29]
>
> so I've tried to do 'dnf install flatpak-runtime' but the package doesn't 
> seem to be available.

These are module buildrequires, not package buildrequires. But as
above, it's just a really confusing error message.

> Next, I thought I'd try building it in koji. Not sure how to do that, the 
> docs are fairly vague, mentioning 'git push origin master' but I don't have 
> anything really to push, the existing git doesn't seem to refer to package 
> versions or anything. I figured that maybe it somehow magically connects it 
> to dist-git rpms/feedreader and gets the sources there

If you look at feedreader.yaml, the different components have 'ref:
f29' - this means "use the f29 branch of dist-git/rpms/". The way
that the module-build-service works however, the *first time* a
particular git commit of modules/ is done, the
module-build-service code freezes the versions of all components
remembers them if you try to build the same commit again. So building
again without a change would have built 2.5.1 again. A useful thing to
know is:

 git commit --allow-empty -m "Rebuild for newer feedreader" ; git push origin

Note that you do need to fix up the platform dependency of
feedreader.yaml, so it's not important here.

> so I've tried just 'fedpkg module-build' without pushing anything to 
> modules/flatpak, but that fails again with the familiar missing buildrequires 
> error:
>
> $ fedpkg module-build
> Submitting the module build...
> Could not execute module_build: The build failed with:
> None of the base module (platform or bootstrap) streams in the buildrequires 
> section could be found

Yes, that's the same error.

> Is the flatpak building actually working for anyone? What am I doing wrong? 
> How do I specify what version to actually build?

It is currently working, yes. And rebuilding it (with fixes) will
automatically use the latest versions of the branch. I'm trying to
work now on a small application to show a status page for the Flatpaks
in Fedora that will highlight cases where the RPMs are newer than
what's in the Flatpaks.

Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F30 Self-Contained Change proposal: Ibus-typing-booster default for Indian languages

[Owen Taylor]

OK, so trying it out, I note the following:

 * The top panel shows a full-color rocket where the current language
would normally be indicated (this needs to be monochromatic, but it
also needs to be meaningful)
 *  There is no I can find to use ibus-typing-booster to type in
something other than the current locale. I'd imagine that typing in
more than one Indian script is a real use case? In any case, the
design is that input sources are per-language and you switch input
source to switch input language.
 * Under wayland (at least), there is severe flashing where the
candidate window disappears and appears for every keystroke.

Presumably we have feedback from native speakers that the
ibus-typing-booster makes things better for them - but I think we need
to address the above issues to make the switch over.

Owen




I don't have any

Owen

On Mon, Jan 28, 2019 at 4:57 AM Jens-Ulrik Petersen  wrote:
>
> On Mon, Jan 28, 2019 at 8:04 AM Owen Taylor  wrote:
>>
>> I see that I have ibus-typing-booster installed, but I don't see any
>> sign of it in the GNOME "Region & Language" panel input source
>> selection. Does ibus-typing-booster look like one input support for
>> each supported language, or does it look like a single input source?
>
>
> ibus Typing Booster used to expose separate Input Sources for each language 
> it supports, but in 2.0 we unified it to a single Input Source under Other 
> languages.
>
> Hope that helps, Jens
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F30 Self-Contained Change proposal: Ibus-typing-booster default for Indian languages

[Owen Taylor]

> Currently, ibus-m17n is the default input method for Indian languages
> in Fedora.  ibus-typing-booster uses the same libm17n used by
> ibus-m17n to support input for Indian languages and thus it can do
> everything ibus-m17n can do. But on top of that, ibus-typing-booster
> supports predictive input by remembering user input and by using words
> from dictionaries.  Therefore, ibus-typing-booster is a more useful input 
> method
> for these languages.
>
> == Benefit to Fedora ==
> A better input experience for users of Indian languages.

How would I try this out in Fedora 29?

I see that I have ibus-typing-booster installed, but I don't see any
sign of it in the GNOME "Region & Language" panel input source
selection. Does ibus-typing-booster look like one input support for
each supported language, or does it look like a single input source?

Thanks!
Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F30 System-Wide Change proposal: Replace Comps Language Group With Langpacks

[Owen Taylor]

If I understand the proposal, I'm slightly concerned that the proposed
use of Supplements: means that there will be no longer any single
place where we declare "this is our recommended font for LangX, this
is our recommended input method for LangX" - the history of this will
be collectively over all of dist-git and hard to extract. (And it will
be necessary to go to packages we stop using and remove Supplemenets)

What is the reason for the use of Supplements instead of just adding
Recommends: to the langpacks packages?

Owen

On Wed, Jan 9, 2019 at 2:58 PM Ben Cotton  wrote:
>
> Congratulations to the last System-Wide Change proposal of F30!
>
> https://fedoraproject.org/wiki/Changes/Replace_Comps_Language_Group_With_Langpacks
>
> == Summary ==
> Language support groups in Comps file will get replaced by langpacks
> package. With this Change we want meta-packages like langpacks-ja to
> also install required fonts and input-methods for the given language.
>
> == Owner ==
> * Name: [[User:petersen| Jens Petersen]]
> * Email:  petersen at fedoraproject dot org
> * Name: [[User:pnemade| Parag Nemade]]
> * Email: pnemade at fedoraproject dot org
>
> == Detailed Description ==
> This change will remove the need of having the language specific comps
> groups in Fedora.
>
> We already have ''langpacks-*'' packages in Fedora since F24.
> Currently they are installing language packages for translations,
> dictionaries etc. but not fonts or input-methods. With this Change we
> will try to install fonts and input-methods as well.
> E.g. if you net-install Fedora in Japanese language then installation
> of any base package like libreoffice-core or man-pages are installing
> automatically libreoffice-langpack-ja or man-pages-ja but langpacks-ja
> is not installing any Japanese font or input-method.
> But now with using RPM tags or weak dependencies like Supplements, we
> can get font as well as input-method packages installed as well on the
> system.
> There is no need of language comps groups to exist, they will be
> replaced by langpacks.
>
> This Change is originally submitted at https://pagure.io/i18n/issue/97
>
> == Benefit to Fedora ==
> Users can install complete language support now using langpacks only.
> This will also help to remove the language support groups from the
> comps file.
>
> == Scope ==
> * Proposal owners: Check all langpacks providing packages (like fonts,
> input-methods) add Supplements tag in their SPEC file and build them.
> We will track the progress of this Change in
> [https://copr.fedorainfracloud.org/coprs/pnemade/langpacks/ Langpacks
> Copr] project.
> * Other developers: To all other developers of packages who provides
> langpacks, they need to add the Supplements tag as given in this
> [https://fedoraproject.org/wiki/Packaging:Langpacks Langpacks
> guideline] to each langpack subpackage.
> * Release engineering: none
> * Policies and guidelines: none
>
> == Upgrade/compatibility impact ==
> None.
>
> == How To Test ==
>
> * [[QA:Langpacks]]
>
> == User Experience ==
> Currently users can get complete language support installed only using
> "''dnf group install ''" command. After this Change gets
> implemented end users can get language support installed using
> meta-packages "''langpacks-"'' only
>
> == Dependencies ==
> No Other Change depend on this.
>
> == Contingency Plan ==
> * Contingency mechanism: If this change is not completed by final
> development freeze then we need to target this for F31. We are just
> proposing to add additional information in langpacks packages that is
> Supplements tag. This should not affect individual langpacks packages
> installation by dnf.
> * Contingency deadline: I don't think we will need anything to revert
> or apply any contingency plan here if this is not completed by beta
> freeze.
> * Blocks release? No
> * Blocks product? N/A
>
> == Documentation ==
> * Need to add about this in the Release notes
>
>
> --
> Ben Cotton
> Fedora Program Manager
> TZ=America/Indiana/Indianapolis
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal: Add a separate “flatpaks/” namespace.

[Owen Taylor]

On Tue, Jan 8, 2019 at 12:28 PM Owen Taylor  wrote:
>  * In fedscm_admin: Map flatpaks namespace to the ‘module’ PDC branch
> type when storing the SLA into the PDC, to avoid PDC changes, and
> because the SLA really is a module SLA.

Digging into this, I don't think this is right - it would break the
1:1 mapping between pagure branches and "component branches" in PDC
that we currently have and the scripts count on. I think the right
thing is:

 * Modify the ReleaseComponentType table in the PDC database to add 'flatpak'

[ Or could be done by adding a migration to the PDC codebase, adding
the redeploying, but considering that we're working on replacing the
PDC, doesn't seem worthwhile.]

Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Proposal: Add a separate “flatpaks/” namespace.

[Owen Taylor]

Currently, the content for a Flatpak in Fedora can be found in
modules/. E.g.:
https://src.fedoraproject.org/modules/quadrapassel/tree/master - I’d
like to propose creating a separate namespace in src.fedoraproject.org
- flatpaks/

Benefits:
 * Allow automation to easily distinguish Flatpaks from other modules.
(https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ANZRNH75N7MHRO6VEUNT4WOMHO5PNXGW/
)
 * Make it easy to browse through the source of available Flatpaks
 * Reduce some confusion. A Flatpak is a module, but it’s *also* a
container, and the dist-git repository will include files for both.

Downsides:
 * We have a few graphical applications that are available as standard
loose-rpm macros (gimp, rawtherapee, skychart). While it should work
to have flatpaks/gimp and modules/gimp build different streams of the
gimp module, it’s going to be more confusing than different branches
in the same repository. (There are even possibilities for using the
*same* branch using module-stream-expansion, though that’s not
something I’d encourage at the moment.)

Needed steps:
 * Remove special casing of flatpak => modules in Bodhi
   
https://github.com/fedora-infra/bodhi/blob/develop/bodhi/server/models.py#L1061
 * Adjust namespace special-casing in fedpkg
   https://pagure.io/fedpkg/blob/master/f/fedpkg/cli.py
 * Adjust namespace special-casing in fedscm_admin
   https://pagure.io/fedscm-admin/blob/master/f/fedscm_admin/utils.py
 * In fedscm_admin: Map flatpaks namespace to the ‘module’ PDC branch
type when storing the SLA into the PDC, to avoid PDC changes, and
because the SLA really is a module SLA.
 * Adjust distgit pagure configuration to add flatpaks to
ALLOWED_PREFIX and REQUIRED_GROUPS
  
https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/distgit/pagure/templates/pagure.cfg
 * Add flatpaks/ to the kojid allowed_scms configuration
  
https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/koji_builder/templates/kojid.conf
 * Add flatpaks/ to the module-build-service SCMS configuration
   
https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/mbs/common/templates/config.py
 * Adjust the owner-sync-pagure script to handle flatpaks/
   
https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/bodhi2/backend/templates/owner-sync-pagure.j2
* Move or reimport existing Flatpak repositories
  (modules/eog, modules/feedreader, modules/flatpak-common,
modules/flatpak-runtime,
   modules/gnome-clocks, modules/gnome-tetravex, modules/quadrapassel)

Potential issues:
 * We should probably move flatpak-common to the flatpaks/ namespace
for ease of discovery, but it isn’t in any way a flatpak, it’s just a
module that Flatpaks can depend on.
 * The ability of modules to include other modules won’t work without
further adjustments to the MBS config.py (MODULES_ALLOW_REPOSITORY) -
I don't see this as useful functionality for Flatpaks.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F30: System-Wide Change proposal: DNF UUID

[Owen Taylor]

On Tue, Jan 8, 2019 at 7:17 AM Benjamin Berg  wrote:
>
> On Tue, 2019-01-08 at 12:33 +0100, Miroslav Suchý wrote:
> > Dne 08. 01. 19 v 11:35 Nicolas Mailhot napsal(a):
> > > *which* *do* *not* *permit* *or* *no* *longer* *permit* *the*
> > > *identification* *of* *data* *subjects*
> >
> > How do you identify data subject solely on UUID?
>
> You also inherently collect information such as the IP and the
> timestamp of the request which in principle permits identification. You
> could for example collect the IP from Fedora account logins and one of
> these pings. This way you can de-anonymise the data collected for the
> UUID.

We can certainly implement a setup that does not collect or store the
UUID together with the IP address or timestamp. Send the UUID as a
HTTP header, don't log it, send the UUID off to a counting service
(*). If we make sure the UUID is protected in transit, sent only to
our own servers (or servers configured by the user), and not collected
or stored in a personally identifiable way, I suspect that we're
meeting our obligations under the GDPR, though we'd need to
double-check any selected solution carefully.

That being said, certainly some users might still have an issue with
having a UUID sent to Fedora servers even if we are meeting our legal
obligations. What we say we are doing with the data might not
correspond to reality in case of a security breach or court order. For
this reason, the first_time_this_week=1 option that Lennart and
Benjamin mentioned has some appeal to me - it would avoid the need for
extra opt-in/out screens, confusing text, etc. It would also allow any
yum repository to do counting the same way - not just our own
repositories.

Owen

(*) implementation left to your imagination. Store a hash of the UUID
for a week then discard. Use HyperLogLog. Etc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: /usr/include/GL/glext.h:467:10: fatal error: KHR/khrplatform.h: No such file or directory

[Owen Taylor]

On Mon, Dec 10, 2018, 4:24 AM Samuel Rakitničan <
srakitni...@fedoraproject.org wrote:

> Hi,
>
> Got an e-mail from Koschei [1] with a notice that camotics package is
> starting to fail to build. The reason for this seems to be that something
> that used to pull mesa-libEGL-devel doesn't do so anymore.
>
> /usr/include/GL/glext.h:467:10: fatal error: KHR/khrplatform.h: No such
> file or directory
>
> Since /usr/include/GL/glext.h belongs to mesa-libGL-devel and not camotics
> I think it would be more appropriate to put the dependency there. Thoughts?
>

https://bugzilla.redhat.com/show_bug.cgi?id=1657356

Adam Jackson, the Mesa maintainer in Fedora, has been on vacation, getting
back tomorrow, so should take care of it then, if nobody fixes it first.

Including mesa-libEGL-devel as a buildrequire is a harmless workaround, but
certainly shouldn't be necessary

Owen

>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal: Move to an annual platform release starting at F30

[Owen Taylor]

On Wed, Nov 28, 2018 at 12:40 PM Stephen John Smoogen  wrote:
> On Wed, 28 Nov 2018 at 11:37, Owen Taylor  wrote:

> > Fedora needs to be an operating system provider, not just an operating
> > system toolbox provider. 
>
> I feel like we have been saying this for 15+ years even before Fedora
> was Fedora. Even back in the RHL days, we would argue over whether
> what we were providing was an 'OS' or not versus a toolkit for someone
> else to work with.

I don't think we've just been saying this, I think we've been steadily
improving in this area - both in our focus and in our processes. The
move to editions was particularly helpful.

Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal: Move to an annual platform release starting at F30

[Owen Taylor]

On Wed, Nov 28, 2018 at 3:07 AM Brian (bex) Exelbierd
 wrote:

> I think that Fedora's role as an innovater in the OS space means we
> should be aggressively exploring this.  Rolling Releases, Tech-Driven
> Releases and Time-Based Releases all have well known positives and
> negatives.  All of the work that has been done on Modularity,
> containers, flatpaks, OSTree, and more, gives us the opportunity to
> really re-think this.  While it is true there are dozens (or more)
> additional solutions to the too-fast/too-slow and the
> incompatible-libraries problems, these technologies seem to be gaining
> the most adoption across a variety of use cases.  They are all also
> generally well supported in Fedora and we need to aggressively push
> them to achieve this goal or determine where the dead-end is so we can
> move to the next innovation.

We have a lot of flexibility with all these technologies. What we need
to achieve through our processes - CI, the release process, etc, is to
enable users to take advantage of the technologies to achieve their
goals - to get their work done - without having new problems thrown at
them - excessive complexity, instability, etc.

> I personal am hugely in favor of us adopting a bootable-base model
> that allows us to iterate the kernel and the various user-space pieces
> at the speed of the upstream, the user's desires and the builder's
> desires[^0] all at the same time.  While this will require us to do
> some level of NxM matrix building and testing, a base that didn't have
> to change often for most use cases reduces the matrix considerably.

The term "bootable-base" concerns me - because it could be interpreted
to mean a minimal bootable set - just enough to get systemd and dnf
running, perhaps. In another mail, you explained what you meant as
"light up the machine level [...] and get containers/flatpaks/etc
running". What does it take to get containers running usefully? It
probably looks quite a bit like Fedora CoreOS. What does it take to
get Flatpaks running in a useful way to users? - you need a full
desktop environment - something like Fedora Silverblue (or the default
install set of Fedora Workstation if you prefer loose packages).

While the Fedora release today contains a lot more software than this
"core operating system" - generally our release processes today are
targeted at trying to release a stable core operating system - and
this is something we can't lose if we start changing around how things
work. It's not that I don't think the maintenance of glibc and gcc is
really important, but if we refocus our release processes only on
that, and one day a broken wpa-supplicant rebase lands and half our
users lose networking - that would be a really poor outcome for
Fedora.

> I'd push Brendans' concept further and suggest that we try to
> eliminate as many of the compilers, libraries and core system tools as
> possible from this bootable-base so that those can iterate at their
> own speed, perhaps 4 year for a laptop vendor and 30 day for a
> experimental ARM device.  Fedora as a project might not build output
> for the whole range, but a build system that allowed us to help others
> be successful would be a huge help here.

Fedora needs to be an operating system provider, not just an operating
system toolbox provider. There are a lot of use cases for the
"operating system toolbox"

 - To build the operating systems that Fedora releases - CoreOS,
Workstation, etc.
 - To create the containers, Flatpak runtimes, and Flatpaks that Fedora releases
 - For users to create application containers
 - To create development environments (pet containers)
 - For adventurous users to create new, customized operating systems

but you can't do integration testing on operating system toolbox,
because the whole point is that you can integrated it any way you want
and only the end user defines what is broken and what is working.
Producing a *quality* operating system requires us to focus our
processes on the integrated operating systems that we produce, on the
applications we produce - and that's what our processes should be
around.

Could we replace the current 6 month release processes with an
alternate set of processes around multiple rolling branches? It's
certainly a possibility, but it's going to be very difficult to get a
high level of stability - a level of stability that is acceptable to
all end users - without a process where the *entire operating system*
gets beta tested before being pushed out.

If we want to move in the direction of rolling releases, the first
step is to get the continuous integration testing and gating in place
to make rawhide consumable by a broader set of people. That would be
incredibly useful even if we keep the current 6 month tempo, but
essential if we want to move to a rolling stable model. Until we can
demonstrate that, it seems really premature to talk about rolling
stable models.

Owen
___
devel 

Re: Proposal: Move to an annual platform release starting at F30

[Owen Taylor]

We can definitely talk about whether moving to a slower cadence for
certain parts of the base platform. But people don't judge Fedora on
how beautifully we maintain glibc and gcc - they mostly judge it by
installing it on a laptop and seeing how well it works. And it doesn't
really matter how reliably we can create minimal container images if
the workstation image doesn't compose or doesn't log in.

We need clear naming for the workstation releases we do. If we want to
call them F30, F30.1, F31, F31.1 we can, but that doesn't inherently
reduce load on releng or remove the need for infrastructure freezes
... my assumption was that the idea of delaying F31 is to actually
*not* do an operating system release for a year, and that's something
that I don't think we should do on an ongoing basis.

Owen

On Tue, Nov 27, 2018 at 1:19 PM Brendan Conoboy  wrote:
>
> On 11/27/18 10:13 AM, Josh Boyer wrote:
> > On Tue, Nov 27, 2018 at 11:21 AM Owen Taylor  wrote:
> >>
> >> On Tue, Nov 27, 2018 at 11:05 AM Josh Boyer  
> >> wrote:
> >>> On Tue, Nov 27, 2018 at 10:13 AM Owen Taylor  wrote:
> >>>> But for the next thousand or so Fedora developers, the release cycle
> >>>> is actually not a big deal - not something that takes much of their
> >>>> time - and it gives them a regular place to land feature work. And
> >>>> Fedora users appreciate a timely updated operating system (without
> >>>> having random rebases trickle in.)
> >>>
> >>> It's not a big deal because they don't participate in making the
> >>> release nor do they really know about all the duct tape and bailing
> >>> wire holding all the machinery in place.  Just like most of them don't
> >>> appreciate the heroics involved from Fedora QA and rel-eng and the
> >>> dozen or so people that regularly go well beyond the extra mile to get
> >>> it out the door.  This isn't done out of malice on their part.  It's
> >>> mostly that they just don't see it.
> >>
> >> If we distribute this work out across the 1000 developers, we'll make
> >> life better for heroes, and it's *still* not going to be a big deal
> >> for the 1000 developers.
> >
> > I would say it will be a learning curve and there will be complaints
> > because it's change and people seem to only want change if it's the
> > change they want or otherwise doesn't impact them.  That's going to be
> > a big deal to some :)  Generally though, yes.  We need to distribute
> > the burden to the package sets and whomever maintains them.
> >
> >>>> In other words, the "technical debt" we are trying to solve here is
> >>>> not project wide and doesn't justify slowing down the whole project
> >>>> permanently.
> >>>
> >>> I completely disagree.  Our release process and tooling is built on
> >>> heroism and tech debt.  At some point, that is going to cause
> >>> significant burnout and then people will just wonder what happened
> >>> when those people stop doing releases.  I think it's better to raise
> >>> awareness at the project level, and build something that is
> >>> sustainable rather than predicated on "small group of people killing
> >>> themselves for the greater good".  That starts with individual package
> >>> CI gating, and goes all the way through integration testing between
> >>> packages in a gated manner, into how we actually *create* all of that
> >>> plus the things we deem worth of releasing.
> >>
> >> I think you are misunderstanding me somehow. I'm 100% on-board with
> >> improving the processes, catching compose problems in an automated and
> >> early fashion, making developers fix their own problems, and generally
> >> making releases a less heroic process. And if that requires a
> >> temporary cadence chance to get the retooling done, then it's worth
> >> it.
> >
> > Ah, good!
> >
> >> But Brendan's proposal to permanently slow down the cadence seems to
> >> make the assumption that the current release cycle is a heroic effort
> >> for the entire project - that we're moving too fast to stay on our
> >> feet. And I don't think that's the case.
> >
> > That would be a concern to me as well, assuming we stuck with a
> > *single* cadence and a *single* platform.  With the lifecycle
> > Objective, aren't we targeting multiple cadences and lifecycles?  I
> > mean, we have this today with Fedora Atomic/CoreOS vs. "regular"
> > Fedora.  Maybe Brendan wa

Re: What does delaying F31 mean for packagers/users?

[Owen Taylor]

On Tue, Nov 27, 2018 at 10:51 AM Stephen Gallagher  wrote:
> As came up in another part of the earlier thread, I think this is an
> opportunity for Modularity. For those things like GNOME that want to
> rev mid-release, if they shipped the 3.34 release as new stream, those
> that want to move to it will have that option, and those who fear
> change can remain on the 3.32 release, even if it's not getting
> support. This would have to be something communicated at release-time
> of course.

If we want to offer optional GNOME-3.34, a module is probably a better
alternative to using a copr - which is what we did last time.
(https://copr.fedorainfracloud.org/coprs/rhughes/f20-gnome-3-12/) But
we have to recognize that if we create such a module we are
effectively creating a Fedora 30.1 - because libraries in that module
will replace system libraries. From the point where we release such a
module, any RPM-packaged applications that use GNOME libraries will
have to be tested against *both* F30 and F30+gnome-3-34.

It's also a minimally scalable approach - we wouldn't want to have a
GNOME 3.34 module and a NetworkManager-1.16 module and support
arbitrary combinations.

And we'd have to figure out some strategy for not breaking F31 updates
when you have the desktop:3.34 module enabled.

Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal: Move to an annual platform release starting at F30

[Owen Taylor]

On Tue, Nov 27, 2018 at 11:05 AM Josh Boyer  wrote:
> On Tue, Nov 27, 2018 at 10:13 AM Owen Taylor  wrote:
> > But for the next thousand or so Fedora developers, the release cycle
> > is actually not a big deal - not something that takes much of their
> > time - and it gives them a regular place to land feature work. And
> > Fedora users appreciate a timely updated operating system (without
> > having random rebases trickle in.)
>
> It's not a big deal because they don't participate in making the
> release nor do they really know about all the duct tape and bailing
> wire holding all the machinery in place.  Just like most of them don't
> appreciate the heroics involved from Fedora QA and rel-eng and the
> dozen or so people that regularly go well beyond the extra mile to get
> it out the door.  This isn't done out of malice on their part.  It's
> mostly that they just don't see it.

If we distribute this work out across the 1000 developers, we'll make
life better for heroes, and it's *still* not going to be a big deal
for the 1000 developers.

> > In other words, the "technical debt" we are trying to solve here is
> > not project wide and doesn't justify slowing down the whole project
> > permanently.
>
> I completely disagree.  Our release process and tooling is built on
> heroism and tech debt.  At some point, that is going to cause
> significant burnout and then people will just wonder what happened
> when those people stop doing releases.  I think it's better to raise
> awareness at the project level, and build something that is
> sustainable rather than predicated on "small group of people killing
> themselves for the greater good".  That starts with individual package
> CI gating, and goes all the way through integration testing between
> packages in a gated manner, into how we actually *create* all of that
> plus the things we deem worth of releasing.

I think you are misunderstanding me somehow. I'm 100% on-board with
improving the processes, catching compose problems in an automated and
early fashion, making developers fix their own problems, and generally
making releases a less heroic process. And if that requires a
temporary cadence chance to get the retooling done, then it's worth
it.

But Brendan's proposal to permanently slow down the cadence seems to
make the assumption that the current release cycle is a heroic effort
for the entire project - that we're moving too fast to stay on our
feet. And I don't think that's the case.

Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

What does delaying F31 mean for packagers/users?

[Owen Taylor]

One of the key parts of making a decision to delay/skip F31 is
figuring out, ahead of the decision, what the expected experience is
for users and packagers. Does F30 have normal stability, or do we try
to keep users happy by moving things forward with ad-hoc updates and
cross-our-fingers and hope nothing breaks?

I tend to think about this in terms of GNOME - would we rebase to
GNOME 3.34 in the middle of F30 or not? But there's a lot of other
pieces of software where similar considerations apply: container
tools, cockpit, NetworkManager, etc.

And if we did do updates like that, would we consider respinning media
and making a "F30.1"?

Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Improving the compose: leave the current compose in place

[Owen Taylor]

On Tue, Nov 27, 2018 at 10:12 AM Stephen John Smoogen  wrote:
> Define what a compose is? Currently it is a word which covers a
> multitude of different processes and reasons for those processes. We
> can't 'fix' or even 'replace' or parallel them without actually
> knowing why someone duct taped this tool to that widget during a 2 am
> release window.

Yes, that's a good point, and something I wanted to say - one of the
starting points is defining exactly what output is needed for a
particular use case and figure out how to get *that* output as fast as
possible. (Probably the normal case will be taking a new build, and
producing a single testable ostree or image containing that build.)

Being able to optimize along a single path is how you get *much*
faster than the current global compose. And why the problem is
probably not best formulated as "speed up the global compose".

Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal: Move to an annual platform release starting at F30

[Owen Taylor]

On Mon, Nov 26, 2018 at 9:26 PM Brendan Conoboy  wrote:>
> On 11/16/18 7:50 AM, Paul Frields wrote:
> [snip]
> > We should skip the F31 release cycle and leave F30 in place longer in
> > order to focus on improving the tooling and testing changes. These
> > tooling changes will improve the overall reliability of Fedora, and
> > will decrease the manual effort and complexities involved in producing
> > the distribution artifacts. Although we’ve done this before to make
> > “editions” happen, the intent is to track this multi-team effort more
> > actively so we can (1) use the time as well as possible, and (2) give
> > the work maximum transparency.
>
> If there is going to be a pause F30 seems like a good place to do it:
> New glibc, new compiler- and a full year for them to mature.  It's a
> nice basis for a stable platform.  What would the update policy be for
> this year- same as today?  It seems like you're proposing this as a
> one-time event to pay down technical debt, which is great, but would
> you perhaps consider doing the same thing for F31, F32, etc?  The
> basic reasons for technical debt will continue- why not plan to
> service the debt regularly?

If we go ahead and skip the F31 release, I see this as a (perhaps
necessary) desperation move - there is a small group of a dozen or so
people who would be key to improving our release processes, but those
people are always busy making releases.

But for the next thousand or so Fedora developers, the release cycle
is actually not a big deal - not something that takes much of their
time - and it gives them a regular place to land feature work. And
Fedora users appreciate a timely updated operating system (without
having random rebases trickle in.)

In other words, the "technical debt" we are trying to solve here is
not project wide and doesn't justify slowing down the whole project
permanently.

- Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Improving the compose: leave the current compose in place

[Owen Taylor]

A lot of discussion about improving the compose process seem to end up
with a "reality check" - that ideas have already been tried but don't
work because of requirements a) b) c) d). You can't have the pony, but
maybe if a lot of effort is put into it, you can have a faster rocking
horse.

If want to fundamentally improve the Fedora workflow we need compose
ponies, we can't just have rocking horses!

Perhaps it would make sense to leave the current 8-10 hour compose in
place for the forseeable future, and work on a new system in parallel
where the primary constraint is to be as fast as possible. Hopefully
most problems with the slow compose will get sorted out in the fast
composes, and the slow compose will become more reliable. Perhaps in a
distant future, we can make the new system do everything

I don't know what the system would look like exactly, but you could
imagine things like:

 * Composed of several micro-composes (micro-compose-services?) to
avoid blocking on everything completing successfully.

 * Able to do speculative composes for CI

 * Either x86_64-only, or with decoupled architectures so that we can
throw x86_64 hardware (or cloud resources) at it, and make it super
fast.

 * No IO /mnt/koji during the compose - having a big network share be
central to the process creates a performance bottleneck, makes it hard
to move to the cloud, and potentially adds a lot of "noise" to
figuring out what is going on where things are slow because of some
other entirely different thing is goin gon.

Add your own bullet points :-)

Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Last dbus upgrade issues

[Owen Taylor]

On Mon, Nov 26, 2018 at 9:59 AM Tomasz Kłoczko  wrote:
> 1) if dbus service crashes/is not availaible temporary IMO it wold be
> good to prepare whole desktop apps code to not crash but handle dbus
> disconnection and maybe display centered message that it is not
> possible to connect to dbus. Crashing everything looks really *bad*.

The design of D-Bus is that it is the central point of lifecycle
management for your desktop - when the session bus goes away,
everything on it should go away. Trying to make things survive bus
restart compromises that, and makes it more likely you'll get stray
processes after exit. Now with systemd user sessions, cgroups, etc, we
have other mechanisms for session cleanup, but removing the older
concept of exit-with-the-bus would require major rethinking.

Plus, when the connection to the bus is lost, all assumptions that the
app has about the state of the system are invalid. (Normally, with
D-Bus you reliably get messages, or you reliably get notification when
your communication partner goes away.) So the app state needs to be
reinitialized from scratch. There's significant code complexity there
which will be exercised in only very rare circumstance.

In general, I don't think being able to replace the bus implementation
on a running system is *that* interesting - sometimes the user will
have to reboot, and if that's too disruptive, we need to work on
making it less disruptive.

Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

[Owen Taylor]

Thanks for starting this discussion, Matthew!

A few notes:

 * My personal long-term dream is that all Fedora users are running
Silverblue, we do great automated QA testing, and upgrading from one
Fedora to the next is a non-event, and opt-out rather than opt-in, and
long term support would not be needed. We aren't there yet. :-)
 * If we have a long-term support branch, the stuff that's in the
default install / the stuff that would be in a Silverblue image -
should be rebased very sparingly. I think we'd have to define this set
- it's bigger than the current "critical path".
 * As we move higher up the stack, it's more reasonable for
maintainers to take an approach of maintaining a single version across
active Fedora branches - and we have various mechanism to make that
easier: packages.cfg, module stream expansion, Flatpaks.
 * The kernel is a big question mark - our kernel maintenance strategy
really *assumes* that we can aggressively rebase, but if the Fedora
project is working with a hardware vendor, the kernel is the component
that the hardware vendor is probably going to be squeamish about. Not
sure what the solution here is - sync to a LTS kernel? Presumably part
of Fedora working with hardware vendors would be figuring a good
testing strategy so that updates get testing on the actual hardware
before going out.
 * If we are offering a long term branch as a strategy to work with
hardware vendors, what happens when users *choose* to upgrade to a
newer stable Fedora?

- Owen

On Tue, Nov 13, 2018 at 6:37 PM Matthew Miller  wrote:
>
>
> Hi everyone! Let's talk about something new and exciting. Since its
> first release fifteen years ago, Fedora has had a 13-month lifecycle
> (give or take). That works awesomely for many cases (like, hey, we're
> all here), but not for everyone. Let's talk about how we might address
> some of the users and use cases we're missing out on.
>
> When I talk to people about this, I often get "hey, you should do LTS
> or go to rolling releases.” As I've said before, on the surface that's
> a weird thing to say, since the actual user impact of those two
> different things is mostly _opposite_. So, digging in, it often really
> means "I don't want the pain and fear of big OS upgrades".
>
> We've addressed that in several ways: first, making upgrades better.
> (Thanks everyone who has worked on that.) A Fedora release-to-release
> update is normally not much more trouble than you might get some random
> Tuesday with a rolling release. Second, we have some things like Fedora
> Atomic Host and upcoming Fedora CoreOS and IoT which both implement a
> rolling stream on top of the Fedora release base. And finally, there's
> the coming-someday plans for gating Rawhide, making that a better
> proposition for people who really want to live on the edge.
>
> But there are some good cases for a longer lifecycle. For one thing,
> this has been a really big blocker for getting Fedora shipped on
> hardware. Second, there are people who really could be happily running
> Fedora but since we don't check the tickbox, they don't even look at us
> seriously. I'd love to change these things. To do that, we need
> something that lasts for 36-48 months.
>
> So, what would this look like? I have some ideas, but, really, there
> are many possibilities. That's what this thread is for. Let's figure it
> out. How would we structure repositories? How would we make sure we're
> not overworked? How would we balance this with getting people new stuff
> fast as well?
>
>
>
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[rpms/perl] PR #1: Make builds for inclusion in an application Flatpak work

[Owen Taylor]

otaylor commented on the pull-request: `Make builds for inclusion in an 
application Flatpak work` that you are following:
``
It may be a little confusing: why do we need to handle mixed environements with 
some perl modules in /app and some in /usr? This is for build time in the 
buildroot of a Flatpak module (flatpak-common or an application module.)

BuildRequires might either be straight up Fedora packages, or they may be 
themselves rebuilds with prefix=/app. If a package BuildRequires: gcc, that can 
be a normal Fedora packages, but if it BuildRequires: libfontenc-devel, then 
that should be the libfontenc-devel from a rebuild libfontenc.

Perl is somewhere in the middle - generally when perl is being used to run 
automake, etc, it could be used just like gcc. But we *also* want to rebuild it 
so we can bundle it into an application RPM. Once we rebuild it, the rebuilt 
package will be used to satisfy BuildRequires:, so we need to make sure that we 
can have a mixed environment with some perl modules in /usr and some perl 
modules in /app.
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[rpms/perl] PR #1: Make builds for inclusion in an application Flatpak work

[Owen Taylor]

otaylor opened a new pull-request against the project: `perl` that you are 
following:
``
Make builds for inclusion in an application Flatpak work
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: python2-matplotlib needs a maintainer (was: matplotlib 3 (no Python 2 support) in rawhide)

[Owen Taylor]

On Mon, Sep 24, 2018 at 10:15 AM Miro Hrončok  wrote:

> On 21.9.2018 12:19, Miro Hrončok wrote:
> > We updated python-matplotlib to 3.0.0. It only supports Python 3. This
> > was done in Rawhide only.
> >
> > The python2-matplotlib* subpackages were moved to a new SRPM,
> > python2-matplotlib (remains at 2.2.x), as plenty of cruft still needs
> > them :(
> >
> > If you experience some relevant trouble (conflicts between packages,
> > blocked updates, unresolved deps, matplotlib not working, your plots
> > exploding...) please file bugs or let me know.
> >
> > python2-matplotlib needs a maintainer. Volunteer at your local animal
> > shelter (e-mail me). I'll orphan in ~1 week.
>
> Nobody?
>
> It's needed by:
> [...]
>reinteract
>

The threat of python2-matplotlib maintenance has inspired me to retire the
reinteract package ;-)
[I actually stopped upstream development 7 years ago - it was well past
time to retire the Fedora package.]

Owen


Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Managing stream (arbitrary) branch and module lifecycles

[Owen Taylor]

On Mon, Sep 24, 2018 at 7:04 AM Adam Samalik  wrote:

> I thought about this for a while, and I can see some conceptual
> similarities between upgrading a major Fedora release and changing a module
> stream. I tried to think about major Fedora releases (I mean f28, f29, etc)
> as "streams" of Fedora, the same way as streams of modules, with stable API.
>
> Until now, there was a single type of upgrade in Fedora — the major
> release upgrade. But with Modularity, there is more than that. It's no
> longer single monolithic upgrade of the whole OS. People can now upgrade
> (== change streams) different parts of the OS potentially independently. We
> need to think how to present this to users. Will it require a change of
> mindset?
>

I think we have to be very careful about making the default experience have
too much complexity to it. For graphical applications we are using Flatpaks
to get this separation of OS upgrade and application upgrade, *but* we're
planning to have applications be single stream - so applications just roll
forward with upstream stable releases. So the total complexity stays low.

Also, with the effort of separating apps and the OS we've discussed at
> Flock, will the goal be to get the "OS part" upgradable at any time, and,
> independently on that, users will choose to upgrade (again, change streams)
> individual parts of the system (modules) for new features? That probably
> will require a change of mindset. It sounds similar how a phone works. Do
> we need to develop a whole new UX around this?
>

We have no current plans to create a *graphical* user experience around
installation of modules as loose packages. Even creating a decent command
line experience around it seems very difficult, since if you allow
independent module maintenance, two modules can start conflicting at any
time (even without a branch switch!).

 "Updated versions of reviewboard and sagemath have different versions of
python2-, do you want to"
  A) Remove reviewboard
  B) Remove sagemath
  C) Use the version of python2- from reviewboard and hope for
the best
  D) Use the version of python2- from sagemath and hope for the
best
  E) Find a nearby brick wall to bang your head against

On the other hand, if you don't allow independent module maintenance and
enforce compatible versions across the entire set of modules included in
the modular compose, you've lost some of the point of modularity... still,
that's better, in my opinion than presenting the user with lose-lose
options.

Owen


> On Thu, Sep 20, 2018 at 11:01 PM Randy Barlow <
> bowlofe...@fedoraproject.org> wrote:
>
>> On 9/20/18 1:56 PM, Matthew Miller wrote:
>> > If it's "they'll find out when dnf system-upgrade errors out!", then see
>> > above. I'm ... not enthused. Something in dnf system-upgrade needs to
>> do it;
>> > possibly a "dnf system-upgrade prep" step before "download".
>>
>> I agree. Would it be feasible for the system-upgrade plugin to prompt
>> the user with "hey, you are using 1.7 but you need to switch to 1.8 to
>> upgrade. Proceed? (y/N)".
>>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>
>
>
> --
>
> Adam Šamalík
> ---
> Software Engineer
> Red Hat
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: What to do about sagemath

[Owen Taylor]

Using modules for this purpose will take some care for parallel
installability - unless you are happy with sagemath only being runnable
from within a container.

Unless I'm missing something, to restore a python2 subpackage that has been
removed in the main Fedora, you'd need to:

 - Create a stream branch
 - Modify the spec file in that branch to *only* build the python2
subpackage
 - Include that stream branch in your module

Regards,
Owen


On Sun, Sep 23, 2018 at 12:07 AM Jerry James  wrote:

> On Sat, Sep 22, 2018 at 4:55 PM Miro Hrončok  wrote:
> > I never thought I would ever ask this, but would it make sense to get
> > sagemath into a module? We could pin all the necessary python2 packages
> > in the module to the current (or even older?) versions (and don't update
> > them to newer versions that possibly drop py2 support). The rest of
> > Fedora could move forward and sagemath would keep going on.
>
> H, that might make sense, at that.  I have to admit now that I
> haven't really been following the development of modules, and don't
> really know how they work.  I'll try to read up on them next week.
>
> Thanks for the suggestion.
> --
> Jerry James
> http://www.jamezone.org/
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Call for participation: Fedora Flatpaks

[Owen Taylor]

Hi Bastien,

Here are some of the benefits I see of this effort as compared to simply
telling users to consume Flatpaks from Flathub or independent repositories:

* Benefit to Flaptak users on all distributions: more applications are
available more quickly. Some applications will be much easier to create
Flatpaks of this way because of their build dependencies. For lightly
maintained, older applications, building a Flatpak of an RPM within Fedora
is simple and avoids creating another independent place that someone has to
keep an eye on.
* Benefit to Flatpak users on all distributions: this works towards having
a runtime (whether Fedora or RHEL/CentOS based) that has a  long lifetime
and strong security update guarantees
* Benefit to Fedora users: they can get Flatpaks and runtimes from a source
they already have trust in.
* Benefit to Fedora users: this is a repository of Flaptaks we can enable
by default (there are ongoing discussions of splitting up Flathub, but
currently it combines both content that Fedora can point users to, and
content that is problematical from a legal or Free Software point of view,
all mixed together.)
* Benefit to Fedora contributors: they can work within the community and
infrastructure they are already familiar with to fill gaps in the set of
available Flatpaks.
* Benefit to Fedora contributors: they can make their packaging work
available across distributions and distribution versions.
* Benefit to upstream: if they already have a good relationship with Fedora
and their application is well maintained there, they can point users on all
distributions to a  Fedora Flatpak.
* Benefit to Red Hat: We build infrastructure technology and content that
we can take into the RHEL context and make runtimes and Flatpaks available
to our customers with the type of guarantees that we are already providing
for RPM content.

LIke many things we do in Fedora, the benefit to RHEL is a big reason that
we've been doing this work, and was an influence in some of decisions about
how things were implemented, but I think the work does stand on its own as
useful to the Fedora and Flatpak communities.

Regards,
Owen



On Fri, Sep 7, 2018 at 10:44 AM, Bastien Nocera  wrote:

> Hey Owen,
>
> - Original Message -
> > I'd like to invite Fedora contributors to start creating Flatpaks of
> > graphical applications in Fedora. We're still working on putting the
> final
> > pieces into place to have a complete story from end to end, but it's
> > definitely close enough to get started.
>
> As discussed earlier in both mailing-lists and face-to-face, I'd like to
> know
> why this is interesting for either upstream or downstream developers.
>
> Who is the target for this feature, why does it make sense for packagers to
> package within Fedora (or eventually CentOS, or RHEL), rather than
> upstream,
> whether in Flathub or an independent repository?
>
> I can expand on what I think are the benefits for Fedora, and its
> downstreams,
> but that would require making guesses at roadmaps that I don't have a view
> into.
>
> Cheers
> ___
> desktop mailing list -- desk...@lists.fedoraproject.org
> To unsubscribe send an email to desktop-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/desktop@
> lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Call for participation: Fedora Flatpaks

[Owen Taylor]

On Fri, Sep 7, 2018 at 5:29 AM, Martin Kolman  wrote:

> On Fri, 2018-09-07 at 05:06 -0400, Owen Taylor wrote:
>
[...]

> That's *very* nice & something I have been calling for basically from day
> one with flatpacks.
>
> Not everyone wants to become a release engineer & build all the
> dependencies of their application by hand, especially when
> all this is already available via RPM packages in Fedora. :)
>
> BTW, it is (at least) to me not really apparent from the original email
> that we (finally!) have the Fedora Flatpak runtimes availble for use.
>

Well, sort of. :-) What I've created so far is a Flatpak runtime to run
packages against - there's no corresponding SDK to use with
flatpak-builder. There's an initial definition of packages for such a SDK,
but I haven't actually tried creating the SDK, much less building anything
against it.

Also, the Flatpak runtime is not yet installable and updateable from a
Flatpak remote - we're still working on the last infrastructure pieces to
have that working.

But very soon!


> Some advantages this has over building and using Flatpaks on Flathub:
>
>  - In most cases, it's easier to create a Flatpak from an existing RPM
> rather than creating a flatpak-builder manifest from scratch.
>  - We're able to reuse the Fedora updates infrastructure and automate
> rebuilding and releasing Flatpaks and the runtime for security or other bug
> fixes
>
> Is there a listing of what is already part of the Fedora runtime ? I tried
> cliking about in the linked documentation, but was not able to find it.
>

That information is stored in from:


https://src.fedoraproject.org/modules/flatpak-runtime/blob/master/f/flatpak-runtime.yaml

It's hard to read because there are *four* list of packages in thre:
 - A base runtime corresponding to org.freedesktop.Platform
 - The corresponding SDK
 - A full runtime (similar to org.gnome.Platform, but with Qt5 and other
useful additions)
 - The corresponding SDK

So packages can be listed 4 times. The contents can also be explored
interactively at:

 https://fishsoup.net/misc/flatpak-runtime-reports/runtime.html

(The tabs at the top take you to other reports.)

Also, how long will the runtimes be supported by security fixes ? I guess
> just as long as the corresponding Fedora releases, or maybe longer ?
>

Exactly - the lifetime of the runtime is determined by the lifetime of the
Fedora release, unless we decide at a Fedora project level to support it
longer. I don't think that's immediately interesting, but maybe eventually.


>  - Applications with complicated build dependencies are easier to handle.
> Any RPM in Fedora can be used as a build-time dependency. Only run-time
> dependencies that aren't already in the runtime need to be rebuilt and
> bundled, and even there it's a mostly automatic process.
>
> (On the other hand, for an upstream application developer who knows
> nothing about RPMs and specfiles and so forth, and just wants to create a
> Flatpak of their application, flatpak-builder and Flathub is likely more
> attractive than creating a Flatpak via Fedora packaging.)
>
> It's not exclusive - you can use Flatpaks from Flathub and from this
> effort together - even on a non-Fedora system. And, of course, you can
> contribute to both Fedora and Flathub!
>
> Do I understand things correctly that Flatpaks built for Fedora should
> still work fine on other distros such as say Debian, ArchLinux or even
> CentOS ? I guess the user adds the Fedora generated Flatpak repo,
> this pulls in the Fedora runtime (and keeps it updated) and then installs
> the corresponding Flatpak and all just works seamlessly ?
>

Yes, you understand correctly.

[There's a wrinkle here in that the plan is to distribute the Fedora
flatpaks via registry.fedoraproject.org as OCI container images, rather
than via an ostree repository, but the support for that is in Flatpak 1.0
on all distros - 'flatpak remote add fedora oci+
https://registry.fedoraproject.org' will be all that is needed, and the
difference is handled by Flatpak behind the scenes.]

Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Call for participation: Fedora Flatpaks

[Owen Taylor]

On Fri, Sep 7, 2018 at 3:36 AM, Vít Ondruch  wrote:

> Dne 7.9.2018 v 03:45 Owen Taylor napsal(a):
>
> [...]
>
> If you maintain a graphical application, please try creating a Flatpak of
> it. Your experience will vary - some applications are quite easy, but if
> your application, for example:
>
>  * Uses qt5-qtwebengine
>  * Uses many KDE libraries
>  * Uses many Perl or Python packages
>  * Uses texlive
>
> etc, then you may want to wait - we will eventually be creating shared
> builds to make bundling these easier.
>
>
> 
> Ah, make bundling easier, right. Finally we can bundle!
> 
>
> Honestly, I fail to see how this can be promoted as good for Fedora. It
> might be good for upstream but not for Fedora.
>

To be clear, bundling here is *not* the same as simply including the
sources for a library into the application. What bundling means here is
including a particular build of a library into the application Flatpak so
that it is tested, deployed, and upgraded as a unit. But the library is
defined independently in Fedora, and is visible to our tooling.
Applications share libraries (beyond those included in the Flatpak runtime)
either:

 - At the source level, by including a reference to a src.fedoraproject.org
branch
 - A the binary level by depending on a module that includes a Flatpak
rebuild of the library

We haven't yet created such shared modules - we want to get some experience
first at creating Flatpaks to figure out what makes sense. But clearly they
are useful for dependencies that take a long time to rebuild and are shared
by many applications. (On the other hand, of the 3600 dependencies of
graphical applications in Fedora, almost half are a dependency of only
*one* graphical application.)

Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Call for participation: Fedora Flatpaks

[Owen Taylor]

On Fri, Sep 7, 2018 at 4:03 AM, Michal Konečný  wrote:

> I thought there will be some automatic building script for flatpaks, so
> the maintainers doesn't need to do it by themselves.
> Is this automatization now dropped?
>

One level of automation is 'fedmod rpm2flatpak' which automatically figure
out dependencies and creates a module definition file which says what
Fedora packages need to be rebuilt for inclusion in your Flatpak. This
module definition file can often be used without any further editing.
'fedmod rpm2flatpak' also creates a container definition file
(container.yaml) which includes, among other things, the permissions for
the application. This does require manual editing, and, unless the
permission settings can be copied from an existing Flatpak of the
application, usually some testing to get right.

There's really no way to get around that level of human involvement - to
define the permissions for the app and check that the result works.

The other planned type of automation is automated rebuilds. We want to be
to the point where when there is an update for an included package, the
Flatpak is automatically rebuilt, a Bodhi update for the updated Flatpak is
filed, and email is sent to the maintainer requesting that they test the
new Flatpak. This does not exist yet, but the plan is to have it before
Fedora 30. For now, we need to build out the set of Flatpaks so we
understand how the system is working for maintainers and users.

Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Call for participation: Fedora Flatpaks

[Owen Taylor]

On Fri, Sep 7, 2018 at 2:52 AM, Robin Lee 
wrote:

> What does it mean for 'Fedora' Flatpaks?
> - Flatpaks that run on a Fedora runtime? Then, what's the benifit to
> use Fedora runtime instead of freedesktop ones?
> - Flatpaks that maintained by Fedora community? Then, why not
> encourage people to contribute to Flathub directly?
>

What is meant here is "a runtime and Flatpaks built out of the Fedora RPMs
on Fedora infrastructure".

Some advantages this has over building and using Flatpaks on Flathub:

 - In most cases, it's easier to create a Flatpak from an existing RPM
rather than creating a flatpak-builder manifest from scratch.
 - We're able to reuse the Fedora updates infrastructure and automate
rebuilding and releasing Flatpaks and the runtime for security or other bug
fixes
 - Applications with complicated build dependencies are easier to handle.
Any RPM in Fedora can be used as a build-time dependency. Only run-time
dependencies that aren't already in the runtime need to be rebuilt and
bundled, and even there it's a mostly automatic process.

(On the other hand, for an upstream application developer who knows nothing
about RPMs and specfiles and so forth, and just wants to create a Flatpak
of their application, flatpak-builder and Flathub is likely more attractive
than creating a Flatpak via Fedora packaging.)

It's not exclusive - you can use Flatpaks from Flathub and from this effort
together - even on a non-Fedora system. And, of course, you can contribute
to both Fedora and Flathub!

Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Call for participation: Fedora Flatpaks

[Owen Taylor]

I'd like to invite Fedora contributors to start creating Flatpaks of
graphical applications in Fedora. We're still working on putting the final
pieces into place to have a complete story from end to end, but it's
definitely close enough to get started.

If you maintain a graphical application, please try creating a Flatpak of
it. Your experience will vary - some applications are quite easy, but if
your application, for example:

 * Uses qt5-qtwebengine
 * Uses many KDE libraries
 * Uses many Perl or Python packages
 * Uses texlive

etc, then you may want to wait - we will eventually be creating shared
builds to make bundling these easier. Also, if your application has a
system service, installs a polkit policy, or otherwise is not
self-contained, then it's not a good candidate for a Flatpak.

Or you can pick one of 280+ applications that have been identfied as easy
to Flatpak:

   https://fedoraproject.org/wiki/Flatpak:Easy

and assist out the application package maintainer by creating a Flatpak of
that.

An introduction, draft tutorial and other documentation can be found at:

  https://fishsoup.net/misc/fedora-docs-flatpak/flatpak/

(The plan is to integrate this into docs.fedoraproject.org. For now, the
documentation source
is at: https://github.com/owtaylor/fedora-docs-flatpak)

For help, please ask on #fedora-workstation on Freenode, or mail
desk...@lists.fedoraproject.org.

Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Flatpaks in src.fedproject.org - a namespace conumdrum

[Owen Taylor]

On Tue, Sep 4, 2018, 11:54 PM Ray Strode  wrote:

> Hi,
>
> On Tue, Sep 4, 2018 at 4:00 PM Owen Taylor  wrote:
> I haven't dealt with modularity yet, really, so tell me if i wrong (i'm
> kind of guessing a little bit from briefly snooping around). module
> building is like so, right?
>
> 1) user runs `fedpkg module-build` in a the module git repo
> 2) this gets submitted to a service to build the module
> 3) the service reads a metadata file with a list of rpms to build
> 4) the service submits those builds to koji
> 5) sometime later owner-sync-koji runs and does a massive
> loop over all modules and finds all packages associated
> with each module and tags them all with f29-modular-updates
>

Not quite. First, owner-sync-koji is about adding
packages/containers/modules to a tag - basically allowing a build of the
object to be tagged into that tag. Not actually tagging builds. Second,
what would eventually be tagged here is a complete module build or a
Flatpak container build, not package builds.

>
> so assuming i have the gist of things captured above, my question
> is…why doesn't the service that submits the builds, also do the
> tagging ?  it just seems strange to have the huge loop doing extra
> work.  if the service did the tagging, then it could also do the flatpak
> detecting, and do the additional tagging.  judging from the koji
> command line, it seems koji even allows tagging multiple builds at
> the same time, so i guess the build service could do them all in
> one swoop
>

MBS (that service) does do the actual tagging of the module build.
Component builds don't get tagged into f29-modular-updates.

Anyway, take my suggestions with a grain of salt because i have
> an incomplete understanding of the architecture, MBS, koji, etc.
>

A complete understanding is much rarer :-) I wouldn't claim to have that
either.

Things are especially confusing because support for non-package builds in
Koji is visibly after-the-fact.

Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Flatpaks in src.fedproject.org - a namespace conumdrum

[Owen Taylor]

The current idea
=

A Flatpak is a module. The way that the module is deployed is by creating a
Flatpak container from the module. (Other modules might be deployed by
installing by RPMs directly or creating a server container.)

Because Flatpaks are a module, they share the modules/ namespace on
src.fedoraproject.org with other modules.

Flatpaks are also containers - but to keep things simpler, we don't require
a separate git project in the container/ namespace - the container.yaml is
kept in the same git project and OSBS builds the Flatpak container directly
from there.

The problem
==
Each flatpak needs to be tagged into two koji tags:

  f29-modular-updates (this is the destination for the module build)
  f29-flatpak (this is the destination for the Flatpak container build)

The package list for each koji tag is populated from pagure by the
owner-sync-pagure script (*). But that script has no way of knowing what
repositories under modules/ in src.fedoraproject.org are just modules and
what modules are also Flatpaks, so it has no way to populate the
f29-flatpak tag package list correctly.

(*)
https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/bodhi2/backend/templates/owner-sync-pagure.j2

Solution 1 - separate namespace
==
We could put flatpaks into their own namespace in src.fedoraproject.org.
The MBS configuration would have to be changed to also allow building
modules from the flatpaks/ namespace, the Bodhi code that just landed would
need to change, and there are doubtless other places where we'd need to
change things to extend the list of namespaces, but it would mostly be
straightforward.

Upsides: would make the handling of flatpaks in the infrastructure code a
bit more regular, and also make it easy to see a list of all Flatpaks.
Downsides: obscures the relationship between Flatpaks and other modules.

Solution 2 - project tags
===
The owner-sync-koji code could be adapted so that to find the set of
packages for f29-flatpak it looks for projects in modules/ with a project
tag of 'flatpak'.

Upsides: have to change nothing but owner-sync-koji and the fedpkg
request-repo/fedscm_admin code path.
Downsides: obscure. project tags are modifiable by the owner - so things
could get out of sync.

Solution 3 - look at module contents

If a branch under src.fedoraproject.org/modules has a container.yaml file
with a flatpak: key at the toplevel, then we know it's a flatpak module.
owner-sync-koji could potentially just check this.

Upsides: nothing else to worry about beyond what has to be set up for
building Flatpaks.
Downsides: per-branch - not per-repository, would be wrong on initial
repository creation, which is when owner-sync-koji is run.

Solution 4 - 
=
[ your proposal goes here]
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [modularity] Managing module lifecycles — let's talk!

[Owen Taylor]

What are the possibilities for how a stream is maintained? The cases I can
think of:

 * Indefinite - rolling forward with upstream - "master" "stable" etc.
 * Tied to an upstream version and it's EOL -  a "2.1" stream of django
 * [less common] tied to a particular version of Fedora - the "29" stream
of flatpak-runtime

How do your proposed mechanisms handle these cases?

It seems like by trying to automatically determine an EOL, the intent of
module maintainer might not be respected - e.g. you might include a package
with a short EOL intending to rebase to newer versions as necessary.

What if we just had a streams.yaml file checked into the master branch of
git and gave the maintainer the flexibility to set an EOL (with defaults if
no streams.yaml is present, perhaps.) We could still write tools to check
the EOL against that of dependencies and components, but that would just be
used to flag problems.

Owen


On Wed, Aug 22, 2018 at 6:39 AM, Adam Samalik  wrote:

> During the Modularity WG meeting yesterday [1], we've touched the topic of
> module lifecycles. Even though there are some ideas in the air as well as
> some code written, we haven't reached a state in which we would know how
> exactly to deal with it. So I'd like to discuss it here with a wider
> audience, and review it again in the next Modularity WG meeting.
>
> == Introduction: (feel free to skip this if you know what I'm talking
> about)
>
> In concept, modules live more or less independently from the Fedora
> release. So while traditional packages in Fedora are branched for each
> Fedora release (such as f27, f28, etc.), and each branch is maintained for
> the lifetime of its release (~13 months), modular packages and modules
> themselves are branched in any way it makes most sense for the software
> (mostly major version, such as nodejs 6, nodejs 8, nodejs 10, etc.) — we
> call these "stream branches" in dist-git and "streams" when we talk about
> modules. This has two implications, one of which is the topic of this email:
>
> 1) One module stream can be built and maintained for multiple Fedora
> releases — that means it's lifecycle can be longer than just a single
> Fedora release — and that's what this email is about
> 2) One Fedora release can have multiple streams of modules — also cool,
> but not discussed in this email
>
> If you're a visual type, watch this short animation (38 seconds):
> https://www.youtube.com/watch?v=5VQljp1p_ok
>
> == The problem + what we've decided already
>
> Simply put, we need to have a way of indicating how long each module
> stream lives. This should be probably defined at the package level, because
> packages the actual software that is being maintained.
>
> At Flock 2017 we've discussed this topic and reached a following decision:
> Module stream's lifecycles should be somehow aligned with Fedora releases —
> in particular, they should be retired only at the end of a release. That
> way we prevent a situation where different module streams could be retired
> at any point in time, which would be pretty messy. On the other hand,
> introducing new streams at any time should be possible, the same way as we
> add new packages today.
>
> == Approaches
>
> Option 1: The current, yet unfinished approach
>
> We specify an EOL (end of life) date for each stream branch of individual
> packages. This is done when requesting a new stream branch for a package
> [2] by passing "--sl rawhide:2020-12-01" to fedpkg. This value is stored,
> but not yet consumed by anything.
>
> The next step would be having the build system to be smart enough to:
>
> 1) Figure out the module's EOL based on its packages' EOLs.
> 2) Only build the module for the Fedora releases that have their EOL
> before the module stream's EOL.
>
> There is a caveat, however:  Giving dates like this might be hard for the
> maintainer. The upstream project might not have one, etc. In that case the
> maintainer needs to come up with a date — even one closer in the future,
> and increase it gradually (and think about it, and do it for all the
> packages), or one much further in the future which could imply promises the
> maintainer had no intention to make.
>
> Option 2: More dynamic, based on rawhide
>
> Simply put, we wouldn't specify an EOL as a date, but as a Fedora release.
> And if a maintainer indicates that a certain stream branch of a package is
> maintained in rawhide, it would mean it's maintained for all active Fedora
> releases + the next one + potentially forever or until it's retired in
> rawhide.
>
> The build system would then do the same thing as above:
>
> 1) Figure out the module's EOL based on its packages' EOLs.
> 2) Only build the module for the Fedora releases that have their EOL
> before the module stream's EOL.
>
>
> Let's discuss the overall concept, the two approaches above or propose
> your own, or anything else that you think is relevant.
>
> Cheers!
> Adam
>
> [1] 

Perl dependencies of KDE libraries

[Owen Taylor]

Hi Rex,

As part of my Flaptak efforts, I've been looking what libraries and other
packages are used by our most popular applications and I noticed that all
applications using KDE libraries are pulling in a pile of perl packages. As
far as I can tell, this is only because of the two scripts:

 /usr/share/kf5/kjs/create_hash_table (kf5-kconfigwidgets)
 /usr/bin/preparetips5 (kf5-kjs)

Are there other reasons that Perl is needed? What if we moved the scripts
to the corresponding -devel packages? They seem to be developer focused and
not needed at application run time.

Thanks!
Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OIQRMKH6GWQJMY2EVBH3RCSWN6FRHZTR/

RFC: Flatpak application versioning: rolling stable

[Owen Taylor]

The Fedora today, there was a presentation about a vision for how
applications should have a different life cycle than the operating system:

 https://flock2018.sched.com/event/Fjdk/at-long-last-rings-split-lifecycles

For Flatpaks, the future is now - as soon as we start building them, I'd
like to start immediately in a model where the application lifecycle is not
tied to the traditional release cadence.

My basic idea is that applications consumed as Flatpaks should have a
"rolling stable" model - there is a *single* default version of the
application for all Fedora users, and that version is the latest upstream
stable release (once the Fedora Flatpak has passed automatic and manual
testing.)

In more detail:

 * The rolling stable version is maintained as the master branch of
modules/MyApp (this git repository contains both the module definition and
the container definition) - this also ends up as the stream of the built
module
 * It should use the Flatpak runtime corresponding to the latest stable
release of Fedora - e.g., flatpak-runtime:f28 at the moment.
 * The Flatpak branch name should be "stable", to correspond to Flatpak
conventions

Questions, possible answers
==

Isn't 'master' == 'rawhide' == unstable?

  This is certainly the Fedora tradition, but since the stable branch is
the *default* branch, and since it will often be the *only maintained
branch*, I think it works better on master.

What about packaging *unstable* upstream releases?

   If the packager desires, they can create a 'devel' branch, but they need
to rename the application in the desktop file and rename the application
ID, so that the devel releases can be parallel installed with the standard
releases. [There's some work that needs to be done to enable this either in
Bodhi since currently both branches of MyApp will end up tagged by Bodhi as
MyApp:latest with the latest updated one winning.]

What about packaging old stable upstream releases?

   This should be done only in exceptional circumstances, such as a
complete rewrite upstream that produces a new stable version that (at least
originally) doesn't have all the features of the old stable version. In
this case you would use a upstream-versioned branch in dist-git, and also
be expected to change the desktop file name and application ID to enable
parallel installs.

How does this affect rpms/MyApp

   The branch structure of rpms/MyApp does *not* have to match that of
modules/MyApp. If a new major release of MyApp comes out in the middle of
F29, the package maintainer would have various choices a) ask for a stream
branch of rpms/MyApp to put the new version on and change their module to
reference the stream branch b) update the f29 branch to the new major
version and upgrade rpm consumers as well c) update the master branch to
the new major version and change the module to reference the master branch
- the spec file would need to work against both the f29 and f30 platforms,
but that usually isn't hard.

How does this relate to server containers?

 I registry.fedoraproject.org/MyContainer:latest should be "rolling stable"
in the same sense. It should be the latest upstream revision, and should be
based on the latest Fedora release. But server admin's often don't want to
wake up one morning with their apps upgraded to a different major version
(or wake up one middle of the night to a phone call), so perhaps we need to
have stream branches and tags *up front* - so that you can use
MyContainer:10 [needs the same Bodhi work referenced above to avoid
fighting over 'latest' and 'testing']. We'd also need to figure out when
it's permissible for a stream branch to rebase to a different Fedora base
image.

Do you have documentation for how Flatpaks will work?

 Nothing very up-to-date. I hope to have comprehensive Flatpak packager
docs posted within the next few days, hopefully they will clarify this a bit
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JXIPPQ4WKYNUSSVBQ3M5VQ56YY4INBM6/

Re: [atomic-devel] Starting a Container SIG

[Owen Taylor]

I'm interested in participating with a special interest in Flatpaks - the
other type of Fedora container ;-) - I want to keep things aligned as much
as possible. And also from the perspective of using containers for
development within Fedora Workstation.

I can contribute a certain familiarity with OCI images, OSBS, the image
registry, etc.

Owen


On Wed, Jul 25, 2018 at 1:09 PM, Clement Verna 
wrote:

> Greeting all,
>
> The container effort in Fedora has until now been looked after by the
> Atomic WG, since this Working Group is now going to focus mostly on
> Fedora CoreOS, I propose to create a new container SIG to regroup
> people interested in the maintenance of application containers in
> Fedora.
>
> This SIG would look after the container guidelines [0], the container
> review process [1] and also the release process and tooling.
>
> Please Reply if you're interested with helping out making the
> Container story great in Fedora. If there is a good response, I will
> create a Container SIG wiki page, and I guess we can ask for
> container-devel mailing list for SIG discussions.
>
> Regards,
> Clément
>
> [0] - https://fedoraproject.org/wiki/Container:Guidelines
> [1] - https://fedoraproject.org/wiki/Container:Review_Process
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IH7ETUX3VHOP3MSE4WMSYIAXMICRJT5C/

Re: Guideline change: glibc malloc as the C/C++/Rust allocator

[Owen Taylor]

On Fri, Jul 27, 2018 at 9:44 AM, Florian Weimer  wrote:

> On 07/27/2018 03:33 PM, John Reiser wrote:The key principle is that
> sizeof(foo) must be the stride of an array of foo,
>
> and the array must guarantee alignment of each element in the array.
>>
>
> Why do you think that?  If some documentation claims this is the case for
> individual objects, we need to fix it.


struct sizes *do* have this property - they are rounded up so that arrays
have the correct alignment.
But that certainly doesn't imply that malloc(7) is allowed to give you
unaligned memory.

Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PVZ3KXKN2IQGGI2DI2KQSJWZOZPYIIRV/

Re: F29 System Wide Change: Modules for Everyone

[Owen Taylor]

I'm not sure it needs to be mentioned in the change proposal - but there
are some caveats to this as it applies to the workstation:

 * There are no plans to add any user interface to enable/disable modules
in the GNOME Software user interface.
 * If we even want graphical applications from enabled modules to appear in
GNOME Software, someone is going to have to put work into appstream
enabling modules, and into filtering the appstream data based on enabled
modules.
 * For Fedora Silverblue, if we want users to be able to layer rpms from
modules, then rpm-ostree will likely need work.

For the Workstation in general we want to move to a model where the system
install set is stable and enables basic functionality, and containers are
where you do sysadmin experimentation and development. Silverblue is the
long-term version of this, but we encourage this way of working even for
RPM-based installations.

So ideally documentation about trying out modularity on Fedora Workstation
for something like a different version of nodejs would show doing that
inside a container. (With the caveat that we're still figuring out what the
recommended best practices are for pet containers.)

Owen

On Wed, Jun 20, 2018 at 1:14 PM, Jan Kurik  wrote:

> = Proposed System Wide Change: Modules for Everyone =
> https://fedoraproject.org/wiki/Changes/ModulesForEveryone
>
>
> Owner(s):
>   * Stephen Gallagher 
>   * Langdon White 
>
>
> All Fedora installations will have modular repositories enabled by
> default, previously available, by default, only to Server Edition.
>
>
> == Detailed description ==
> In Fedora 28, the Server Edition debuted new modular functionality,
> allowing end-users access to alternative versions of popular software. Due
> to technical limitations with package-management software, it was not
> available for non-Server deployments of Fedora. Beginning with Fedora 29,
> all installations of Fedora will have modules available for installation
> and update. This will be done by merging the `fedora-repos-modular`
> sub-package back into the `fedora-repos` package.
>
>
> == Scope ==
> * Proposal owners:
> The proposal owners need to coordinate the work of the DNF team and
> release-engineering to make sure that the repo subpackage merge only
> happens once the libdnf enhancements are stable. We will also need to
> prepare and run a Fedora Test Day with the QA team.
>
> * Other developers:
> The DNF team is already committed to providing the necessary changes for
> libdnf in Fedora 29.
>
> * Release engineering:
> #7561 [https://pagure.io/releng/issue/7561]
>
> ** List of deliverables:
> All Fedora installations
>
> * Policies and guidelines:
> No alterations to packaging guidelines are required specifically for this
> change
>
> * Trademark approval:
> N/A (not needed for this Change)
> --
> Jan Kuřík
> JBoss EAP Program Manager
> Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.
> fedoraproject.org/message/NBD45XW5275VWVTLEYH5IHAJBK5T35ZF/
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OJ5Q3B7OAU5TAUBJPG3FGALEYZCJNVMM/

Re: Looking up module information via Koji

[Owen Taylor]

[ Broadening the audience to include devel@lists.fedoraproject.org ]

Anybody have thoughts about my question below? some examples of places
which will need logic like this to replace PDC usage:

 ODCS
Resolve a module name:stream to a particular build, and do dependency
expansion
 fedmod
   Get the flatpak-runtime modulemd to find what packages aren't in the
runtime and need to be bundled
atomic-reactor
   Load the modulemd for particular module builds to get profile
information and figure out what to install in a container
 flatpak-module-tools
   Load modulemd and do dependency expansion to build a container locally
 rpkg
Load the modulemd  module we are building into a flatpak to find what
runtime it is using, and hence the right build target

Thanks!
Owen


On Mon, May 21, 2018 at 1:29 PM, Owen Taylor  wrote:

> My understanding is that with the planned retirement of the PDC:
>
>  https://lists.fedoraproject.org/archives/list/infrastructure@lists.
> fedoraproject.org/thread/JHKHWYU5XK7H2P2QZZCCQR4ZRCTY3OSB/
>
> Querying for module information should be done using the MBS and/or Koji
> APIs.
>
> Various code that I maintain (in OSBS, fedmod, and random tooling) wants
> to do module build lookups - different variations of  "look up the modulemd
> for latest build of a NAME:STREAM[:VERSION]". Variations generally being
> exactly what "latest" means here.
>
> The code generally already is using Koji and the MBS api is quite limited,
> so I've chosen to do the lookups via Koji.
>
>  https://fishsoup.net/misc/get-module-builds
>
> Is a test tool that incorporates most of the capability that I needed
> across my uses. It's distinctly more than a couple of lines of code - I can
> cut-and-paste it for now, but what's the right long-term home? Is there a
> simpler way?
>
> My best idea right now is that if the 'base_version' and'status' part of
> my code was simplified to simply be "tag" and avoid reliance on the tag
> structure of Fedora, then this might make a reasonable addition to the Koji
> CLI and API - there are some things that using raw tags for the query makes
> trickier, but it's probably workable.
>
> Thanks for any input!
> Owen
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DXJEL6SJZH4XQQBBX7Z3RAX33S6B6OZB/

Re: Unacceptable size increase to ALL live images in F28: Noto CJK Fonts

[Owen Taylor]

It sounds like what we are doing is shipping the "regional subset" fonts
for all 4 CJK scripts. I wonder if we would do better to ship one unified
font - I believe that at least with the GNOME stack, the rendered results
will be equivalent, since Pango+Harfbuzz should set appropriate 'locl' tags
(https://www.google.com/get/noto/help/cjk/).

Investigation would be required:
 * Am I right about GNOME?
 * Do you also get the right behavior under Qt, LibreOffice, Web browsers -
they use harfbuzz, but do they set locl tags based on $LANG?
 * How much smaller is this
 * What if the user wants to get Korean fonts in LibreOffice with
$LANG=ja_JP, or whatever?

But there would be an issue that in a font list the font would probably
show up with a name that sounds language specific, which is bad.

Could also investigate whether installing the fonts in TTC form is broadly
enough supported in the different rendering stacks and whether it gives
space saving.

I do think we need to ship enough fonts to get the user through GDM and
gnome-initial-setup to render correctly for major languages, but if we want
to start installing additional weights/style variants after installation,
there's a related issue at:

 https://pagure.io/fedora-workstation/issue/27

Owen


On Thu, Mar 29, 2018 at 12:06 PM, Adam Williamson <
adamw...@fedoraproject.org> wrote:

> On Thu, 2018-03-29 at 15:57 +, Stephen Gallagher wrote:
> > On Thu, Mar 29, 2018 at 10:12 AM Kevin Kofler 
> > wrote:
> >
> > > Hi,
> > >
> > > we did more debugging on #fedora-kde (thanks in particular to lupinix)
> and
> > > we found what seems to be the primary source of the bloat: CJK fonts!
> > >
> > > CJK fonts are by far the largest of all fonts due to the huge number of
> > > characters used in those languages.
> > >
> > > Up to Fedora 26, Fedora shipped 4 CJK fonts:
> > >> > type="default">adobe-source-han-sans-cn-fonts
> > >> > type="default">adobe-source-han-sans-tw-fonts
> > >   naver-nanum-gothic-fonts
> > >   vlgothic-fonts
> > > The KDE and LXQt Spins actually opted to blacklist these fonts in their
> > > kickstart, and ship one compact CJK font instead: wqy-microhei-fonts.
> > >
> > > In Fedora 27, this Change:
> > > https://fedoraproject.org/wiki/Changes/ChineseSerifFonts
> > > added 2 additional fonts (for a total of 6):
> > >> > type="default">adobe-source-han-serif-cn-fonts
> > >> > type="default">adobe-source-han-serif-tw-fonts
> > > which were unfortunately missing from the blacklist:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1530006
> > > already increasing the size of the image.
> > >
> > > But now in Fedora 28, after:
> > > https://fedoraproject.org/wiki/Changes/JPDefaultFontsToNoto
> > > https://fedoraproject.org/wiki/Changes/KRDefaultFontsToNoto
> > > https://fedoraproject.org/wiki/Changes/ChineseDefaultFontsToNoto
> > > we actually ship a whopping 12 CJK fonts:
> > >   google-noto-
> sans-jp-fonts
> > >   google-noto-
> sans-kr-fonts
> > >> > type="default">google-noto-sans-mono-cjk-jp-fonts
> > >> > type="default">google-noto-sans-mono-cjk-kr-fonts
> > >> > type="default">google-noto-sans-mono-cjk-sc-fonts
> > >> > type="default">google-noto-sans-mono-cjk-tc-fonts
> > >   google-noto-
> sans-sc-fonts
> > >   google-noto-
> sans-tc-fonts
> > >   google-noto-
> serif-jp-fonts
> > >   google-noto-
> serif-kr-fonts
> > >   google-noto-
> serif-sc-fonts
> > >   google-noto-
> serif-tc-fonts
> > > none of which are blacklisted in the Spins! According to lupinix, these
> > > amount to a download size (and thus an xz-compressed size, which is
> also
> > > the
> > > compression algorithm used for the live images) of 364 MiB!
> > >
> > > The fix is to update the blacklists in the KDE and LXQt spin
> kickstarts, as
> > > per the discussion under:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1530006
> > > IMHO, this needs to be implemented, urgently.
> > >
> > > But I think we also need to generally consider whether it makes sense
> to
> > > force 3 font variants for each CJK language on all users worldwide, and
> > > whether there are smaller fonts that could be used. (E.g.,
> > > wqy-microhei-fonts is very effective, but unfortunately it only covers
> > > Simplified Chinese and the syllabic parts of Japanese and Korean, not
> the
> > > Traditional Chinese, Japanese or Korean renderings of the CJK Unified
> > > Ideographs.)
> > >
> > >
> >
> > Kevin, thanks for the investigation and the detailed analysis. Great work
> > tracking this down!
> >
> > I think our font strategy is a bit complicated, because we do strive to
> be
> > an international distribution, but I feel like there must be better ways
> to
> > accomplish this goal than to simply install all possible fonts by
> default.
>
> Well, I don't think this really is "all possible fonts". Just looking
> at the list, one obvious improvement is that there now 

Re: Goodbye nvr.rsplit('-', 2), hello modularity

[Owen Taylor]

On Fri, Mar 16, 2018 at 4:04 PM, Dennis Gregorovic 
wrote:

> The challenge here is that those module builds are squeezed into a N-V-R
> format when imported into Koji.  The N-V-R format is used for all build
> types in Koji and it works well for its purpose, but it's also not
> realistic to expect that all content types are going to natively use N-V-R
> outside of Koji. My suggestion is that we consider the N-V-R format of
> modules to be a representation internal to koji and that N:S:V:C is the
> format used to represent modules to users.  If that means tweaking the Koji
> UI we can look into that.
>

There's also a terminology problem that gets less confusing with the :
separator. When compared to

 Name-VERSION-Release.DistTag

it would be fairly confusing to have:

 Name-Stream-VERSION.Context

while:

  Name:Stream:VERSION:Context

is slightly less confusing. of course, it might have been better to call
'Version' in a module version Build or something, but I think that ship has
sailed.

In the end, modules are not packages, and it's necessarily required or good
if they are named in the same format. I'd also like to see Koji's
representation of a module version stay inside Koji as much as possible.

Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Fedora-packaging] Re: Proposed Fedora packaging guideline: More Go packaging

[Owen Taylor]

Hi Nicolas,

I'm embarrassed to admit that before I sent my mail I carefully read over
... the old PackageDrafts/Go :-( My only excuse is that it was in my
browser history.

Having actually read the relevant parts of "More Go Packaging", the
explanation of compat packages and notification procedures does make the
intended operation clearer, though the social and technical barrier to a
packager new to Fedora will still be high if packaging their target package
requires creating a compat package and fixing multiple other packages. As
you say, once Fedora packaging catches up to the modern state, things will
be better, because the onus won't be on the new packager to do the  work of
updating old libraries.

I still worry that Fedora is not big enough to move the status-quo in the
Go world - to get the point where Go programs require github.com/foo/bar >=
1.2.3 and actually have been tested with a multiple versions in that range,
not exactly the one vendored version shipped with the program. Sp we might
end up with lots of Fedora-specific bugs that the upstream doesn't care
about. But if the Fedora Go community can get some size and momentum and
start pushing fixes upstream, that will certainly be a positive force for
reducing Go programs stuck on random old versions of dependencies!

I haven't had time to read through the entire proposal, but it certainly
looks like a major step forward!

Owen



On Thu, Feb 1, 2018 at 5:21 AM, <nicolas.mail...@laposte.net> wrote:

>
>
> - Mail original -
> De: "Owen Taylor"
>
> Hi Owen,
>
> > Is there a guide for Fedora packagers about how to handle unbundling for
> > golang packages? The draft guidelines don't seem to go into any details.
>
> I don't think there is, nor that it is necessarily needed. The posted
> guidelines should be sufficient technically, there are no magic I know of I
> didn't document, the rest is just a lot of work (but see ↓)
>
> > I've looked at packaging a few golang packages unbundled, and have
> > immediately run into:
> >
> > A) lots of unpackaged dependencies
> > B) dependencies that are packaged in Fedora with different, often much
> > older versions
>
> Yes the state of Go packages in Fedora is pretty sad right now. I wouldn't
> expect anyone to be able to package anything but the most trivial app in
> unbundled mode. Too many common parts are missing, when they are not
> missing they are too old, trying to update an existing Go package is an
> exercise in frustration (too much package-specific shell code, that is
> difficult to understand and does not really work with new code versions),
> and trying to update or add missing parts just reveals more breakage and
> work to be done.
>
> However, accepting to package complex Go apps in bundled mode is how
> Fedora got to this state in the first place. In plain speak, bundling
> (vendoring in Go linguo) just does not scale. You need an awful lot of
> manpower to audit the hundreds of other projects each app bundles, bundling
> removes all the package tooling that may help you to do so, and the result
> is not shared with any other package, or with other versions of the same
> package, so you get zero positive network effects. Worse, big bundled apps
> that do not actually try to work in unbundled mode, do not actually test
> the code they export (they are bundling, remember) so the result is toxic
> to small Go packages that try to work with them.
>
> So bundling parts is a direct road to bundling everything, bundling
> everything is a direct road to bundling everything blindly, bundling
> everything blindly is error-prone and dangerous (because upstreams are only
> human and do make lots of mistakes), and pretty much removes any value
> Fedora can add to end users, to other parts of Fedora that would like to
> integrate with Go software, or to the upstream projects themselves (no
> Fedora QA, no stream of Fedora-originated fixes, no Fedora pressure to
> stabilize parts when upstream is lost in tunnel effect mode and does not
> realize that it is wasting everyone's time starting with its own).
>
> Therefore, trying to get all this it a better state, requires the
> following steps IMHO:
>
> 1. completely refactor our Go packaging style it's less painful to update
> Go packages and they do not need a packager with deep knowledge of
> package-specific shell glue. That takes documentation, and factoring out
> common Go packaging functions in shared rpm code (macros and autodeps) →
> that's what I posted
>
> 2. using the new documentation and tooling to clean up years of Fedora
> technical debt, and create a new set of up-to-date Go packages that can
> serve as new baseline → I have hundreds of specs that I'm waiting for step
> 1 to complete to submit.

Re: [Fedora-packaging] Re: Proposed Fedora packaging guideline: More Go packaging

[Owen Taylor]

Hi Nicolas,

Is there a guide for Fedora packagers about how to handle unbundling for
golang packages? The draft guidelines don't seem to go into any details.
I've looked at packaging a few golang packages unbundled, and have
immediately run into:

 A) lots of unpackaged dependencies
 B) dependencies that are packaged in Fedora with different, often much
older versions

A) is a pretty known quantity for any type of package, but I found B) more
intimidating. It seems like to package the new package, I have to get the
maintainer of the library to upgrade the version, and someone needs to
rebuild everything that depends on the rebuilt library and test that the
rebuilt packages work.

Some tutorial showing a practical example of packaging a golang package for
the first time I think would be very helpful.

Owen


On Wed, Jan 31, 2018 at 5:30 AM,  wrote:

> >De: "Neal Gompa"
>
> > The only thing I see that might be missing is autogenerating
> > bundled(golang()) Provides when a vendor tree exists (with the
> > appropriate automatic filters on Requires).
>
> I had though a little about doing it but first, as many Go elements,
> vendoring relies on conventions not standards. The nasty thing about
> conventions is that they are not applied 100% the same way by everyone,
> making automation a PITA. And second interactions with autodeps can be
> nasty: you can filter out provides, but do you filter out requires? What
> about all the junk code many projects ship as testing and examples and
> which is vendored with the rest?
>
> I don't say it can't be done, or that it would be difficult to do once the
> rest is merged, but I'll live it to someone that absolutely want to ship a
> Go package with vendored parts.
>
> Right now we sidestep the issue in our packages by rm -fr ing anything
> that looks like vendored code in %prep. Unbundling takes time but it has a
> positive cumulative effect: the more you unbundle the less you need to
> worry about in other packages with the same requirements. And unbundling
> reveals code/legal problems that it would take about as much work to solve
> by auditing the vendored code manually.
>
> Regards,
>
> --
> Nicolas mAilhot
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org