https://fedoraproject.org/wiki/Changes/UnfilteredFlathub
Note that I am processing this proposal past the deadline because 1. I
think it could reasonably be considered a Self-Contained Change
proposal and 2. the reasons outlined by Mattias in another thread:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Fedora Workstation's existing
[https://docs.fedoraproject.org/en-US/workstation-working-group/third-party-…
third party repo feature] allows users to enable a selection of
software repos that are hosted by external organizations. This
selection has included a filtered version of Flathub since F35, which
provides access to a small number of Flathub apps. This change would
remove the filtering from our Flathub offering, so that users can
enable a complete version of Flathub using the third party
repositories feature. In the graphical software manager app, Flathub
packages will only be selected by default when no Fedora package is
available.
== Owner ==
* Name: Workstation WG
* Email: mclasen(a)redhat.com
== Detailed Description ==
Since F35, Fedora has included a Flatpak repo definition for Flathub
in the fedora-flathub-remote package. This Flathub remote can be used
by those who enable third-party software repositories through either
GNOME Initial Setup or GNOME Software. Users who do not opt in do not
see any content from Flathub.
The current Flathub remote is filtered by an allowlist, to only make a
limited subset of software from Flathub available.
The unfiltered Flathub change has two parts:
# Remove the allowlist from the Flatpak remote, so that when a user
opts in, they gain access to all Flathub content and not just a small
selection.
# Adjust GNOME Software so that it uses the following priority order
when deciding which package to offer by default:
## Fedora Flatpaks
## RPMs
## Flathub Flatpaks
This will mean that, when using the graphical software manager,
Flathub Flatpaks will only be selected by default when there is no
Fedora Flatpak or RPM.
Other details:
* In GNOME Software, users will continue to be able to manually select
a different source for individual applications.
* The filtering mechanism will remain in place, and it will be
possible to reinstate a filter via a package update, should the need
arise in the future.
* It has been indicated that it is legally acceptable for us to remove
the filtering from the Flathub remote that we make available for users
to opt into.
* The UI for enabling the third party repositories clearly states that
they contain proprietary software.
* GNOME Software shows information about whether apps are open source
or proprietary, so that users can decide whether they want to install
them or not.
== Feedback ==
A previous version of this proposal was rejected by FESCo for Fedora
37. It has subsequently been modified to address the concerns raised:
* GNOME Software will prefer packages that have been through the
Fedora packaging process, over those that have not.
* For developer tools that do not work well in a sandbox, there will
be no Fedora Flatpak, and the RPM will be preferred over the Flathub
Flatpak.
Some other questions and concerns that were raised in the previous discussion:
=== Who owns and runs Flathub? ===
Flathub is owned and run by [https://foundation.gnome.org/ the GNOME
Foundation], which is a 501c(3) organization registered in the USA.
(The GNOME Foundation
[https://foundation.gnome.org/legal-and-trademarks/ owns the Flathub
trademark], and employs one of the sysadmins who works on Flathub.)
As a non-profit, the GNOME Foundation is required to fulfill a
charitable purpose. This is set out in its IRS registration, which
states that the organization's mission is "broadening access to
technology through the development and distribution of... usable free
computer desktop software".
The GNOME Foundation is governed by its Board of Directors, which is
elected by contributors to the GNOME project.
Plans exist to create additional governance around Flathub itself, so
that other desktops and projects have a formal role in the running of
the Flathub service.
=== Isn't Flathub full of repackaged binaries? ===
At present, around 10% of the apps on Flathub have been repackaged
from another format. These other formats include distro packages and
tarballs, as well as binaries. (The previous figure was 12% - the
analysis for this can be read
[https://blogs.gnome.org/wjjt/2022/06/14/how-many-flathub-apps-reuse-other-p…
here].)
Flathub prefers that apps be built from source, and if sources are
available this is what it is expected to be used. Repackaging is only
used when sources aren't available, or when it isn't practical to
build the entire application, due to size constraints.
=== But I don't like Flatpak because ___________ ===
Inevitably, people have opinions about the design choices for Flatpak
- no technology is ever perfect. Nevertheless, Flatpak is a unique
opportunity for Fedora. Some of the key advantages it offers:
* Allows supporting the same app over multiple OS versions
* Is compatible with next-generation image-based operating systems,
like Silverblue
* Vibrant upstream application ecosystem, particularly around Flathub
* Distro and platform neutral with no vendor lock-in
* Support for application confinement/sandboxing
* Fully integrated into the GNOME desktop experience
No other application packaging tool has these qualities and, for all
these reasons, Flatpak is an important part of the long-term plans for
Fedora Workstation.
=== Lack of community presence around Fedora Flatpaks ===
We previously received feedback that there were no good contact points
for Fedora Flatpaks. The newly created
[https://fedoraproject.org/wiki/SIGs/Flatpak Fedora Flatpak SIG] aims
to correct this situation, and will be the group that is responsible
for Fedora Flatpaks in the future.
The SIG will work to improve the general state of Fedora Flatpaks,
including documentation, issue tracking, and coordination.
== Benefit to Fedora ==
Flathub currently hosts nearly 2,000 apps, including many apps which
are not included in the Fedora repositories. This includes popular
proprietary apps, but also many open source apps which are maintained
in Flathub by their developers. This change will make it easier for
Fedora users to access this resource.
For users who already use Flathub, this change will make it easier to setup.
Additionally, out of the box application availability is one of the
key metrics on which Fedora is judged in comparison to other distros.
Having the option to easily enable Flathub will put us in a much more
competitive position with regards to our rivals, and will make it
easier for people to recommend Fedora as a user friendly Linux distro.
This change will also be a significant improvement over the existing
filtered version of Flathub that we offer. This has received a lot of
negative feedback, with users being confused by the limited subset of
Flathub that are included.
== Scope ==
* Proposal owners:
** Remove the allowlist in /usr/share/flatpak/fedora-flathub.filter,
or replace it with one that allows everything
** Adjust the name of the remote to reflect its unfiltered nature
* GNOME Software developers:
** Land this change to fix preference order in g-s:
https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/1511
** Make sure that the preference order works as desired on Silverblue
as well, where we always want to prefer flatpaks over layering rpms.
This is being discussed here:
https://github.com/fedora-silverblue/issue-tracker/issues/354
* Release engineering:
** No work needed
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
Existing Fedora installations with a configured Fedora Flathub remote
will pick up the new, permissive filter.
== How To Test ==
When third-party software is not enabled in GNOME Initial Setup or
GNOME Software, search results from Flathub should not appear in GNOME
Software.
When third-party software is enabled in GNOME Initial Setup or GNOME Software:
* Search results from Flathub should appear.
* The default app selected by GNOME Software should be as follows:
{| class="wikitable" style="margin:auto"
|-
! Fedora Flatpak? !! RPM? !! Flathub Flatpak? !! Default package
|-
| ✓ || ✓ || ✓ || Fedora Flatpak
|-
| ✗ || ✓ || ✓ || RPM
|-
| ✗ || ✗ || ✓ || Flathub Flatpak
|-
| ✓ || ✓ || ✗ || Fedora Flatpak
|-
| ✓ || ✗ || ✗ || Fedora Flatpak
|-
| ✗ || ✓ || ✗ || RPM
|}
== User Experience ==
When opening GNOME Software after opting into 3rd party software, all
the applications that
are available on Flathub will show up in search results.
Where there are overlaps, Fedora content will be preferred over Flathub content.
When opening GNOME Software without opting into 3rd party software,
only Fedora content
will be show up in search results.
== Dependencies ==
No dependencies.
== Contingency Plan ==
* Contingency mechanism: Reinstate the filtering we had in Fedora 36
* Contingency deadline: Beta
* Blocks release? No
== Documentation ==
* [https://pagure.io/fedora-third-party/blob/main/f/doc/fedora-third-party.1.md
fedora-third-party]
* [https://github.com/flathub/flathub/wiki Flathub wiki]
* [https://fedoramagazine.org/comparison-of-fedora-flatpaks-and-flathub-remote…
Comparison of Fedora Flatpaks and Flathub remotes]
== Release Notes ==
The Fedora Flathub remote now exposes all content from Flathub,
instead of only a small subset. Flathub is not enabled by default. To
enable software from Flathub, turn on third-party software in GNOME
Initial Setup or GNOME Software.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Hi there, I want to ask about adding a package to DNF, if it would be accepted, how i may go about doing/helping with it.
I'm not certain if this is the right mailing list to ask, it seemed so from looking at the ones listed below but please let me know if i'm mistaken:
https://fedoraproject.org/wiki/Communicating_and_getting_help#Specific/Non_…
I help maintain BeEF and am trying to understand if more OS's would be interested in adding it as a default package, (like beef-xss in apt)
If anyone can direct me on where to inquire further, please let me know.
Cheers!
Hi all,
I would like to kick of a Fedora Flatpak Packaging SIG that meets
regularly and has IRC meetings.
Our flatpaks have gotten some bad rep recently and I think for a good
reason. We don't have a lot of them and we only have a handful of people
working on them. We also have a fairly obvious conflict of interest with
Flathub and a bunch of Fedora people are doing flatpaks in Flathub
instead of Fedora and advocating against using Fedora flatpaks.
Here's an attempt to try to get more people involved :) The awkward
situation here is that I am not 100% convinced myself that we should
continue doing Fedora flatpaks, but maybe with a bit more organization
around this we can get some more eyes on the problem and solve some of
the issues.
Please put your name in https://fedoraproject.org/wiki/SIGs/Flatpak if
you are interested and I'll try to organize a poll for a weekly meeting
time. I'd suggest to start the meetings on the second week of January
when the holidays are over.
I've added a few people to CC that I thought might be interested in
this, but anyone that has interest in the area is more than welcome to join.
[Edit: the email got rejected from the mailing list due to too many
recipients so I'm re-sending it without the CC list. The CC'd people
hopefully got the message already.]
Some questions I have around organization: Can someone help register the
#fedora-flatpaks IRC channel under the Fedora umbrella? I am not sure
how to best do that. Does matrix need any special sauce to get a room?
What would be a good name for a pagure.io project?
pagure.io/fedora-flatpaks or pagure.io/fedora-flatpak-sig or
pagure.io/flatpak-sig or something else?
Do we need a mailing list? My initial gut feeling is no, but I'm
interested in what other people think.
If you reply to this, please make sure to reply to the
devel(a)lists.fedoraproject.org post as I am cross-posting it to desktop@
as well.
--
Thanks,
Kalev
https://fedoraproject.org/wiki/Changes/ReproducibleBuildsClampMtimes
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
The `%clamp_mtime_to_source_date_epoch` RPM macro will be set to `1`.
When an RPM package is built, mtimes of packaged files will be clamped
to `$SOURCE_DATE_EPOCH` which is already set to the date of the latest
`%changelog` entry. As a result, more RPM packages will be
reproducible: The actual modification time of files that are e.g.
modified in the `%prep` section or built in the `%build` section will
not be reflected in the resulting RPM packages. Files in RPM packages
will have mtimes that are independent of the time of the actual build.
== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]], [[User:Zbyszek|Zbigniew
Jędrzejewski-Szmek]]
* Email: mhroncok at redhat.com, zbyszek at in.waw.pl
== Detailed Description ==
This change exists to make RPM package builds more reproducible. A
common problem that prevents [https://reproducible-builds.org/ build
reproducibility] is the mtime (modification times) of the packaged
files.
Suppose we package an RPM package of software called `skynet` in
version `1.0`. Upstream released this version at datetime A. A Fedora
packager creates the RPM package at datetime B. Unfortunately, the
packager needs to patch the sources in the RPM `%prep` section. When
the build runs at datetime C, the modification datetime of the patched
file is set to C. When the build runs again in an otherwise identical
environment at datetime D, the modification datetime of the patched
file is set to D. As a result, the build is not bit-by-bit
reproducible, because the datetime of the build is saved in the
resulting package.
Patching is not necessary to make this happen. When a source file is
compiled into a binary file, the modification datetime is also set to
the datetime of the build. In practice, the modification datetime of
many files packaged in RPM packages is dependent on when the package
was actually built.
To eliminate this problem, we propose to clamp build mtimes to
`$SOURCE_DATE_EPOCH`. RPM build in Fedora already sets the
`$SOURCE_DATE_EPOCH` environment variable based on the latest
`%changelog` entry because the `%source_date_epoch_from_changelog`
macro is set to `1`. We will also set the
`%clamp_mtime_to_source_date_epoch` macro to `1`. As a result, when
files are packaged to the RPM package, their modification datetimes
will be clamped to `$SOURCE_DATE_EPOCH` (to the latest changelog entry
datetime). Clamping means that all files which would otherwise have a
modification datetime higher than `$SOURCE_DATE_EPOCH` will have the
modification datetime changed to `$SOURCE_DATE_EPOCH`; files with
mtime lower (or equal) to `$SOURCE_DATE_EPOCH` will retain the
original mtimes.
This functionality is already implemented in RPM. We will enable it by
setting `%clamp_mtime_to_source_date_epoch` to `1`.
=== Non-goal ===
We do not aim to make all Fedora packages reproducible (at least not
as part of this change proposal). We just eliminate one problem that
we consider the biggest blocker for reproducible builds.
=== Python bytecode ===
When Python bytecode cache (a `.pyc` file) is built, the mtime of the
corresponding Python source file (`.py`) is included in it for
invalidation purposes. Since the `.pyc` file is created before RPM
clamps the mtime of the `.py` file, the mtime stored in the `.pyc`
file might be higher than the corresponding mtime of the `.py` file.
With the previous example, if `skynet` is written in Python:
# `skynet.py` is modified in `%prep` and hence has mtime set to the
time of the build
# `skynet.pyc` is generated in `%install` and the mtime of `skynet.py`
is saved in it
# RPM clamps the mtime of `skynet.py`
# `skynet.pyc` is considered invalid by Python on runtime, as the
stored and actual mtime of `skynet.py` don't match
To solve this, we will modify Python to clamp the stored mtime to
`$SOURCE_DATE_EPOCH` as well (when building RPM packages). Upstream
Python chooses to invalidate bytecode cache based on hashes instead of
mtimes when `$SOURCE_DATE_EPOCH` is set, but that could cause
performance issues for big files, so Fedora's Python already deviates
from upstream behavior when building RPM packages. To avoid
accidentally breaking the behavior when
`%clamp_mtime_to_source_date_epoch` is not set to `1`, RPM macros and
buildroot policy scripts for creating the Python bytecode cache will
be modified to unset `$SOURCE_DATE_EPOCH` when
`%clamp_mtime_to_source_date_epoch` is not set to `1`.
This behavior might be proposed upstream if it turns out to be
superior to the current upstream choice, in case we
[https://discuss.python.org/t/14594 won't redesign the bytecode-source
relationship entirely] instead.
=== Opting out ===
Packages broken by this new behavior can unset
`%clamp_mtime_to_source_date_epoch` but packagers are encouraged to
fix the problem instead.
== Feedback ==
Enabling this RPM feature was
[https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/126
proposed as a pull request] to {{package|redhat-rpm-config}} in April
2021. It received good feedback with the exception of the following:
* it was said the change needs to be coordinated with the Python maintainers
* it was said the change should be done via a change process for
better coordination and exposure
We believe that by proposing this via the change process and planning
for the changes needed in Python, both issues are addressed.
== Benefit to Fedora ==
We believe that many RPM packages will become reproducible and others
will be more reproducible than before. The benefits of reproducible
builds are better explained at https://reproducible-builds.org/
== Scope ==
* Proposal owners:
** Propose a PR for {{package|redhat-rpm-config}} (set
`%clamp_mtime_to_source_date_epoch` to `1`, possibly only when
`%source_date_epoch_from_changelog` is set)
** Propose a PR for {{package|python-rpm-macros}} (unset
`$SOURCE_DATE_EPOCH` while creating `.pyc` files iff
`%clamp_mtime_to_source_date_epoch` is not `1`)
** Propose a PR for
[https://src.fedoraproject.org/rpms/python3.11/blob/b2d80045f9/f/00328-pyc-t…
the Python's bytecode invalidation mode patch] for all Python versions
that have it
** Backport (the new portion of) the patch to older Pythons
({{package|python2.7}}, {{package|python3.6}} and PyPys)
** Test everything together in Copr and deploy it if it works.
** Optional: Run some reproducibility tests before and after this
change and produce some statistics.
* Other developers:
** Test their packages with the new behavior, report problems, and
opt-out if really needed.
* Release engineering: N/A (not needed for this Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Nothing anticipated.
== How To Test ==
The change owners plan to perform a mass rebuild in Copr to see if
this breaks anything significantly.
If it actually works as anticipated, they also plan to run some
reproducibility tests and hopefully produce some statistics before and
after this change.
Other packages can test by building their packages and verifying they
still work as expected and no packaged files have higher mtimes than
the last `%changelog` entry.
To verify if this change has landed, run: `rpm --eval
'%clamp_mtime_to_source_date_epoch'` on Fedora 38. The result should
be `1`.
== User Experience ==
Users of Fedora Linux on their machines should not be impacted at all.
Users who build RPM packages atop Fedora will be impacted by this
change the same way Fedora is.
== Dependencies ==
* RPM needs to support this (it already does)
* RPM needs to set `$SOURCE_DATE_EPOCH` (it already does)
== Contingency Plan ==
* Contingency mechanism: The change owners or
{{package|redhat-rpm-config}} maintainers or proven packagers will
revert the change in {{package|redhat-rpm-config}}. That should be
enough to undo anything as the changes in Python should be dependent
on that. If not enough, revert everything.
* Contingency deadline: Ideally, we should do this before the Mass
Rebuild. Technically, we can land it any time before the Beta Freeze,
but it would not change all the packages, which is a bit messy. *
Blocks release? No <
== Documentation ==
This page is the documentation.
== Release Notes ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Hello again, as stated before [1], I'm updating cfitsio to 4.2. I have
created a side tag f38-build-side-61457
I have already built cfitsio, CCfits and wcslib. Affected packages are:
astrometry
bes
CCfits
cpl
elements-alexandria
gdal
healpix
indi-3rdparty-gphoto
kstars
kst
LabPlot
libindi
luminance-hdr
perl-Astro-FITS-CFITSIO
phd2
python-astropy
python-fitsio
python-healpy
root
siril
skyviewer
sourcextractor++
ufraw
vips
wcslib
Best regards, Sergio
[1]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
Hi everyone,
I built an update for libmpc in Rawhide a few weeks ago, then didn't
have time to follow up due to holiday-related travel. (I'm one of
those people you saw on TV sitting around in airports due to canceled
flights.) One test failed: fedora-ci.koji-build.tier0.functional. I
have tried rerunning the tests a couple of times in the last few days,
and that test persists in failing. The log says:
Waiting for Testing Farm...
[Pipeline] waitForWebhook
[Pipeline] retry
[Pipeline] {
[Pipeline] httpRequest
[Pipeline] }
[Pipeline] // retry
[Pipeline] echo
The status is now "complete"
[Pipeline] }
[Pipeline] // script
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Declarative: Post Actions)
[Pipeline] catchError
[Pipeline] {
[Pipeline] error
[Pipeline] }
ERROR: Infrastructure Error
I don't know what "Infrastructure Error" means. Can someone explain
that to me? I can waive the test results, but I want to be sure
nothing is really wrong before doing so.
This libmpc update is ABI compatible with the previous version. It
adds some functions, but does not alter ABI of the existing functions.
This is the update:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-8a8a64ee65
Thank you,
--
Jerry James
http://www.jamezone.org/
I am about to update a few packages that use header-only libraries (and which do not use them only for tests that are not installed, as is often the case with e.g. doctest-static) to include the licenses of those libraries in their SPDX license expressions. The rationale is that header-only libraries are otherwise treated as a kind of static library, and their implementations are compiled into the binary RPMs, so the licenses of the header-only libraries should be included too.
The License for c4core will be updated from MIT AND BSL-1.0 to MIT AND BSL-1.0 AND BSD-2-Clause AND (Apache-2.0 OR MIT) because it BuildRequires debugbreak-static, which is BSD-2-Clause, and fast-float-static, which is Apache-2.0 OR MIT.
The License for grpc will be updated from Apache-2.0 AND BSD-3-Clause AND MIT to Apache-2.0 AND BSD-2-Clause AND BSD-3-Clause AND MIT because it BuildRequires xxhash-static, which is BSD-2-Clause. This can be linked as a shared library or used as a header-only library (as in this case) depending on whether XXH_INCLUDE_ALL is defined.
The License for libfplll will be updated from LGPL-2.1-or-later AND MIT to LGPL-2.1-or-later AND MIT AND CC0-1.0 because it BuildRequires json-static, which is MIT AND CC0-1.0 (the latter because it includes hedley, another header-only library; see https://gitlab.com/fedora/legal/fedora-license-data/-/issues/91#note_115194…, https://gitlab.com/fedora/legal/fedora-license-data/-/issues/32#note_104544…, https://gitlab.com/fedora/legal/fedora-license-data/-/issues/32#note_104546…, and https://github.com/nemequ/hedley/issues/56 for the full story on this).
The License for python-graph-tool will be updated from LGPL-3.0-or-later AND BSL-1.0 to LGPL-3.0-or-later AND BSL-1.0 AND GPL-3.0-or-later AND MIT AND (MIT OR Apache-2.0) because it BuildRequires CGAL-static, which hasn’t yet been converted to SPDX but should be LGPL-3.0-or-later AND GPL-3.0-or-later AND BSL-1.0 AND MIT, and pcg-cpp-static, which is MIT OR Apache-2.0.
The License for python-mapbox-earcut will be updated from ISC to ISC AND BSD-3-Clause because it BuildRequires pybind11-static, which is BSD-3-Clause.