Advice needed: Pantheon desktop broken on Fedora 37 (yes, worse than usual)
by Fabio Valentini
Hello all,
I'm not quite sure how to approach this problem, but as it stands, the
packages for the Pantheon DE and associated "elementary" applications
will probably be mostly broken when Fedora 37 will be released.
Every major GNOME update comes with problems for Pantheon (especially
due to mutter API changes), but this time is *much* worse due to the
additional libsoup 2 -> 3 transition.
Upstream development of the Pantheon / elementary projects is now
focused on finally getting elementary OS 7 out the door (which was
already supposed to have happened, it will be based on ubuntu 22.04
LTS, after all). Support for things that are in the far-off future
(like libsoup3, webkit2gtk-4.1, etc.) are low priority for them,
especially given their diminished manpower.
(The list of currently broken or "in danger of being broken on Fedora
38+" applications and components is included below, including links to
upstream tickets.)
I am already at my limit with the time that I can invest into Fedora,
and GObject C is the bane of my existence - so I can't really help
with these porting efforts, and upstream development is (rightfully
so) focused on their own, more important problems right now.
I doubt that these problems will be fixed in time for the release of
Fedora 37. And because many of these problems result in outdated,
crashing, failing-to-install or failing-to-build packages, I don't
think this is a good outcome at all, least for my users. Rather than
leave the DE available, but in an utterly broken and useless state,
I'd rather remove it from Fedora 37 altogether.
This set of packages also has at least some sentimental value to me,
because they were my first contributions to Fedora - first in COPR,
then getting them through package review (my first review request was
for the granite GTK widget library for elementary applications, which
was reviewed by rathann and ngompa).
The Pantheon components and elementary apps are also probably the
packages with the biggest number of actual users (the combination of
"Pantheon on Fedora" is quite popular for something that's not
available as an official Spin), maybe except for Syncthing, among all
the packages that I maintain.
So, I don't see any "good" way to handle this right now. If somebody
can give me any advice for what to do in this situation, I would be
grateful (even if the advice is: "yes, retire the packages, rather
than leave them broken, they can be added back once they have been
fixed").
Thanks,
Fabio
------------------------------------------------------------------------
Some critical Pantheon DE components that are currently broken:
- gala (window manager): https://github.com/elementary/gala/issues/1447
broken due to mutter API changes between 43.alpha and 43.beta
fails to build + fails to install on Fedora 37+
- elementary-greeter (LightDM greeter):
https://github.com/elementary/greeter/issues/617
broken due to mutter API changes
fails to build + fails to install on Fedora 37+
- wingpanel (top panel, application launcher, indicators, etc.):
https://github.com/elementary/wingpanel/issues/462
broken due to broken gala, and also because of mutter API changes
fails to build + fails to install on Fedora 37+
Creating a compat package for older versions of mutter has previously
worked to work around the worst problems, but it comes with its own
can of worms (i.e. you need to backport upstream patches for
compatibility with the latest gnome-settings-daemon version, etc.),
and this is not something that I can commit to doing again.
Additionally, some applications are broken:
- elementary-calendar: https://github.com/elementary/calendar/issues/756
broken because it directly links libsoup2, but also
evolution-data-server, which has transitioned to libsoup3, and
geocode-glib-1.0, which is the libsoup-2 version
fails to build / install on Fedora 37+
- elementary-mail: https://github.com/elementary/mail/issues/793
broken because it uses webkit2gtk-4.0, but also evolution-data-server,
which has moved to libsoup3
fails to build / install on Fedora 37+
- elementary-tasks: https://github.com/elementary/tasks/issues/340
broken because it uses libsoup2, but also evolution-data-server, and
geocode-glib-1.0, which is the libsoup-2 versionfails to build /
install on Fedora 37+
fails to build / install on Fedora 37+
Other applications aren't broken *yet*, but they will need to be
ported to new library versions at some point (for Fedora 38, or Fedora
39 at the latest, according to current plans for the removal of
libsoup2):
- elementary-photos: https://github.com/elementary/photos/issues/718
needs to be ported to webkit2gtk-4.1 / rest-1 / libsoup-3
- elementary-capnet-assist:
https://github.com/elementary/capnet-assist/issues/84 and 85
needs to be ported to webkit2gtk-4.1 and gcr-4.0
- switchboard-plug-onlineaccounts:
https://github.com/elementary/switchboard-plug-onlineaccounts/issues/243
needs to be ported evolution-data-server 3.45+ / libsoup-3
1 year, 8 months
Self Introduction: Sébastien Le Roux
by Sébastien Le Roux
Dear all,
my name is Sébastien Le Roux, I just join the mailing list today.
I am a computational material scientist,
my work can be separated in two parts: studying the physico-chemical
properties
of materials using computational/theoretical methods, and developing
tools to help
scientists in this field of expertise.
I am the author of several open source programs, so far none being packaged
by Fedora, but I recently released a new software named 'Atomes' and I
would
like to propose Atomes for packaging, and then providing that it can be
packaged
maintain it.
Atomes is a Free (Open Source) cross-platform toolbox developed to analyze,
to visualize and to create/edit three-dimensional atomistic models.
Among the possibilities offered by Atomes:
* Analysis of 3D atomistic model: neutron and x-rays diffraction,
rings statistics, chain statistics, bond order, MSD ...
* Visualization: measures, coordination polyhedras, advanced coloring,
advanced design
* Edition: molecular library, crystal builder, cell edition, surface
creation and passivation ...
* Molecular Dynamics input preparation systems:
o Classical MD: DLPOLY
<https://www.scd.stfc.ac.uk/Pages/DL_POLY.aspx> and LAMMPS
<https://lammps.sandia.gov/>
o ab-initio MD: CPMD <http://www.cpmd.org> and CP2K
<http://cp2k.berlios.de>
o QM-MM MD: CPMD <http://www.cpmd.org> and CP2K
<http://cp2k.berlios.de>
More info about me here: https://www.ipcms.fr/sebastien-le-roux/
More information about Atomes here: https://atomes.ipcms.fr/
So hello world ;-)
Best regards.
Sébastien Le Roux
PS: using Fedora since FC2
--
===========================================================
Dr. Sébastien Le Roux
Ingénieur de Recherche CNRS
Institut de Physique et Chimie des Matériaux de Strasbourg
Département des Matériaux Organiques
23, rue du Loess
BP 43
F-67034 Strasbourg Cedex 2, France
E-mail:sebastien.leroux@ipcms.unistra.fr
Webpage:https://www.ipcms.fr/sebastien-le-roux/
ATOMES project:https://atomes.ipcms.fr/
RINGS project:http://rings-code.sourceforge.net/
ISAACS project:http://isaacs.sourceforge.net/
Fax: +33 3 88 10 72 46
Phone: +33 3 88 10 71 58
===========================================================
1 year, 8 months
status update on "ostree native containers"
by Colin Walters
We shipped https://fedoraproject.org/wiki/Changes/OstreeNativeContainer in Fedora 36 and a lot has happened since then.
One of the biggest things is that rpm-ostree now knows how to intelligently generate reproducible "chunked" container images.
I'll describe this by also highlighting another big change; Fedora CoreOS is now shipped as a properly manifest listed container image alongside the other Fedora images on quay.io:
https://quay.io/repository/fedora/fedora-coreos
And if you dig into the tags, on the UI, clicking through to the stable/amd64 image, check out e.g.
https://quay.io/repository/fedora/fedora-coreos/manifest/sha256:0d100d21b...
Note that e.g. linux-firmware (by far the largest single chunk) is split into its own layer - and this layer is generated in a reproducible fashion (ostree canonicalizes all timestamps to zero in particular). What this means is that these images share storage on the registry and client side.
Another way to say this is that it means you get a natural "delta-like" flow; if e.g. there's a security update to podman, you only download the layer containing podman (plus a metadata layer), not everything else.
This isn't the same as more proper deltas (as e.g. ostree static deltas enable) but it has the powerful benefit of applying everywhere that Docker/OCI containers go (e.g. when you pull the image via podman/docker or Kubernetes, that *also* applies there).
You may see this effort sometimes called "CoreOS Layering" but it really has little to do with "CoreOS", and https://pagure.io/releng/issue/11047 is a ticket which proposes shipping e.g. quay.io/fedora/fedora-silverblue for example. (I know for a number of people I've talked to this idea of building your desktop as an container image server side is powerfully appealing, and this makes it real)
On that topic there's also https://bugzilla.redhat.com/show_bug.cgi?id=2125655 which shouldn't be too hard to put together.
But back to Fedora CoreOS, another thing that's happened recently is https://github.com/coreos/coreos-layering-examples has matured and has many functional examples of using this.
We're getting increasingly close to the point where I want to call this all stable, so it's a great time if you haven't to kick the tires and try it out!
1 year, 8 months
F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_1
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 ==
Transition from Fedora's short name of licenses to standardized
[https://spdx.org/licenses/ SPDX license]
[https://spdx.dev/specifications/ formula].
== Owner ==
* Name: [[User:msuchy| Miroslav Suchý]]
* Name: [[User:jlovejoy| Jilayne Lovejoy]]
* Name: [[User:ngompa| Neal Gompa]]
* Name: [[User:dcantrell| David Cantrell]]
* Name: [[User:rfontanaref| Richard Fontana]]
* Name: [[User:mattdm| Matthew Miller]]
<!-- Include you email address that you can be reached should people
want to contact you about helping with your change, status is
requested, or technical issues need to be resolved. If the change
proposal is owned by a SIG, please also add a primary contact person.
-->
* Email: msuchy(a)redhat.com, dcantrell(a)redhat.com, jlovejoy(a)redhat.com,
ngompa13(a)gmail.com, rfontana(a)redhat.com
== Detailed Description ==
In the past, Fedora decided to use short names for licenses. Although
we documented the short names very well. The identifiers were never
standard. In the meantime, SPDX identifiers become standard, and
[https://wiki.spdx.org/view/Business_Team/Adoption other SW vendors
start using it].
In this phase, we want to provide documentation and tooling to allow
maintainers to begin using SPDX license ids instead of the old Fedora
short names. This move is opt-in. There will be
[[Changes/SPDX_Licenses_Phase_2|Phase 2]], where we identify the
remaining packages and help them to migrate to the SPDX formula.
== Feedback ==
Ancient [https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.o...
feedback from SPDX organization].
Summary from [https://lists.fedoraproject.org/archives/search?q=spdx&page=1&mlist=legal...
fedora-legal mailing list]: we want this to happen, but this is big
scope and likely will happen over more than one release.
Summary from packaging-committee:
* [https://pagure.io/packaging-committee/pull-request/971#]: older PR
to change packaging guidelines
* [https://pagure.io/packaging-committee/pull-request/1142]: present
PR that needs more updating
Summary from devel-list: TBD
== Benefit to Fedora ==
The use of a standardized identifier for license will align Fedora
with other distributions. And allows efficient and reliable
identification of licenses.
== Scope ==
* Proposal owners (things sorted by done/todo and by priorities):
** Miroslav Suchý: license-fedora2spdx - done
** Jilayne Lovejoy: map rest of Fedora licenses to SPDX ids - done
** David Cantrell: create machine-readable format and new repo - done
** David Cantrell: merge mapping of Fedora licenses to SPDX ids to new
data format/repo - done
** Richard Fontana & Jilayne Lovejoy: review update all licensing info
and legal pages in wiki - in process
** Jilayne Lovejoy & Richard Fontana: create and populate new Docs
pages for legal and licensing info - in process
** Miroslav Suchy - create
[https://gitlab.com/fedora/legal/fedora-license-data
fedora-license-data package] (with data from rpminspect-data-fedora) -
TODO
** David Cantrell: separate licenses from rpminspect-data-fedora
[https://bugzilla.redhat.com/show_bug.cgi?id=2077914 BZ 2077914] -
TODO
** Miroslav Suchý: allow `license-validate` to use spdx - TODO
** David Cantrell: generate from license data to new Docs page similar
to [https://fedoraproject.org/wiki/Licensing:Main#Software_License_List
Licensing:Main]
** SOMEBODY: create a webhook that updates Docs page after the merge
to fedora-license-data - TODO
** Jilayne Lovejoy: prepare PR for updates to packaging guidelines -
in the process [https://pagure.io/packaging-committee/pull-request/1142]
** SOMEBODY: help maintainers who want to change license string to
SPDX identifiers proactively.
* Out of Scope: In this phase, we do not target to move **all**
packages to SPDX identifiers. That will be done in
[[Changes/SPDX_Licenses_Phase_2|Phase 2]]. In
[[Changes/SPDX_Licenses_Phase_2|Phase 2]] we will identify the
remaining packages and open BZ or PR.
* Other developers:
Early adopters can migrate their License tag to the SPDX identifiers.
Proposal owners will gather feedback and will work on potential
problems.
We want to have all bits ready so that maintainers can start changing
the spec files just after Fedora 37 branching (summer 2022).
* Release engineering:
* Policies and guidelines: Licensing page, packaging guidelines has to
be altered.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
License strings are not used anything in run time. This change will
not affect the upgrade or runtime of Fedora.
During the transition period, developer tools like rpminspect,
licensecheck, etc. may produce false negatives. And we have to define
a date where we flip these tools from old Fedora's short names to the
SPDX formula.
== How To Test ==
Users should not need any testing. These steps are for package maintainers:
* Fetch your license string from `License` tag in SPEC file.
* Test that your current Fedora's short name is correct. E.g.
$ license-validate -v 'MIT or GPLv1'
Approved license
* Convert license string to SPDX formula:
$ license-fedora2spdx 'MIT or GPLv1'
Warning: more options how to interpret MIT. Possible options:
['Adobe-Glyph', 'MIT-CMU', 'MIT-CMU', 'HPND', 'HPND', 'no-spdx-yet
(MIT license (also X11))', 'SGI-B-2.0', 'SGI-B-2.0', 'SMLNJ',
'MIT-enna', 'MIT-feh', 'mpich2']
mpich2 or GPL-1.0-only
In this example, the short name `GPLv1` can be converted straight to
`GPL-1.0-only`. But short name `MIT` stands for several licenses with
different [https://spdx.org/licenses/ SPDX identifiers]. You have to
examine what license is package actually using. `license-fedora2spdx`
will try to convert the formula and use one of the options but without
any heuristics. You need to manually review the license.
You can check if SPDX formula is correct using:
$ license-validate -v --file FIXME "MIT-CMU or GPL-1.0-only"
== User Experience ==
Users should be able to use standard software tools that audit
licenses. E.g. for Software Bills of Materials.
== Dependencies ==
No other dependencies.
== Contingency Plan ==
* Contingency mechanism: In this first phase, if something goes wrong,
we can 'git revert' each change in dist-git. It is expected that in
the first phase, there will be only a few packages altered. It may be
a few hundred, but it is still doable to revert.
* Contingency deadline: Beta freeze. But it is expected that not all
packages will be converted by that time and the change will continue
in the next release.
* Blocks release? No. This change has no impact on runtime of any package.
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 8 months
Explicit dependency on systemd-rpm-macros now required?
by Florian Weimer
I see some new build failures in rawhide related to systemd RPM macros:
Processing files: opencryptoki-3.18.0-4.fc38.s390x
error: File must begin with "/": %{_tmpfilesdir}/opencryptoki.conf
error: File must begin with "/": %{_unitdir}/pkcsslotd.service
[…]
RPM build errors:
File must begin with "/": %{_tmpfilesdir}/opencryptoki.conf
File must begin with "/": %{_unitdir}/pkcsslotd.service
Child return code was: 1
EXCEPTION: [Error()]
Is this a package problem (missing dependency on systemd-rpm-macros), or
is this something that should be fixed at the buildroot level?
Thanks,
Florian
1 year, 8 months
Request for help: Package downgrades on upgrade from F36 to F37
by Fabio Valentini
Hi all,
Yup, it's that time of the semi-year again. Included below is the list
of package downgrades from Fedora 36 -> Fedora 37 as of today (split
into two lists: one only considering the package's Version tag, and
one looking at the entire NEVR).
There's a lot of golang and python downgrades, these might be caused
by FTBFS issues, but I haven't checked. There's also, as always, the
cases where package maintainers didn't build for an update for F37
after the branch point, or didn't submit bodhi updates after
updates-testing activation point.
Please take a look at this list, and if there's one of your packages
on it, ensure it's up-to-date on Fedora 37. For example, it looks like
the certbot 1.30.0 update was pushed to stable on all Fedora releases
and EPEL 9 but not on F37, where it was unpushed without explanation.
I don't have time to go through these lists and check and categorize
entries one-by-one this time round, so please, help me out here, and
help ensure that Fedora 37 ships with all the updates that should be
there :)
Thanks,
Fabio
PS: There can also be false-positives in this list caused by "race
conditions" caused by timing differences of f36 and f37 composes and
mirror updates etc. - these cases can be ignored as they should
eventually resolve themselves.
======================================================================
Downgraded packages (only considering Version): (42)
- asciigraph-0:0.5.5-3.fc36 > asciigraph-0:0.5.4-5.fc37
- certbot-0:1.30.0-1.fc36 > certbot-0:1.29.0-1.fc37
- cockpit-composer-0:41-1.fc36 > cockpit-composer-0:39-1.fc37
- conmon-2:2.1.4-2.fc36 > conmon-2:2.1.3-1.fc37
- devilspie2-0:0.44-1.fc36 > devilspie2-0:0.43-13.fc37
- dh-make-0:2.202202-1.fc36 > dh-make-0:2.202201-2.fc37
- dotnet6.0-0:6.0.108-1.fc36 > dotnet6.0-0:6.0.107-2.fc37
- erlang-luerl-0:1.0-1.fc36 > erlang-luerl-0:0.3-10.fc37
- exaile-0:4.1.2-1.fc36 > exaile-0:4.1.1-9.fc37
- hdparm-0:9.63-1.fc36 > hdparm-0:9.62-4.fc37
- kweathercore-0:21.05-4.fc35 > kweathercore-0:0.6-1.fc37
- lutris-0:0.5.11-1.fc36 > lutris-0:0.5.10.1-8.fc37
- matrix-synapse-0:1.66.0-1.fc36 > matrix-synapse-0:1.63.1-2.fc37
- netdata-0:1.36.1-1.fc36 > netdata-0:1.35.1-3.fc37
- obs-build-0:20220812-393.9.1.fc36 > obs-build-0:20211125-376.1.3.fc37
- osbuild-0:67-1.fc36 > osbuild-0:65-1.fc37
- osbuild-composer-0:64-1.fc36 > osbuild-composer-0:61-1.fc37
- php-doctrine-doctrine-bundle2-0:2.7.0-1.fc36 >
php-doctrine-doctrine-bundle2-0:2.6.3-1.fc37
- python-acme-0:1.30.0-1.fc36 > python-acme-0:1.29.0-2.fc37
- python-canonicaljson-0:1.6.2-1.fc36 > python-canonicaljson-0:1.4.0-7.fc37
- python-certbot-apache-0:1.30.0-1.fc36 > python-certbot-apache-0:1.29.0-1.fc37
- python-certbot-dns-cloudflare-0:1.30.0-1.fc36 >
python-certbot-dns-cloudflare-0:1.29.0-1.fc37
- python-certbot-dns-cloudxns-0:1.30.0-1.fc36 >
python-certbot-dns-cloudxns-0:1.29.0-2.fc37
- python-certbot-dns-digitalocean-0:1.30.0-1.fc36 >
python-certbot-dns-digitalocean-0:1.29.0-2.fc37
- python-certbot-dns-dnsimple-0:1.30.0-1.fc36 >
python-certbot-dns-dnsimple-0:1.29.0-2.fc37
- python-certbot-dns-dnsmadeeasy-0:1.30.0-1.fc36 >
python-certbot-dns-dnsmadeeasy-0:1.29.0-2.fc37
- python-certbot-dns-gehirn-0:1.30.0-1.fc36 >
python-certbot-dns-gehirn-0:1.29.0-2.fc37
- python-certbot-dns-google-0:1.30.0-1.fc36 >
python-certbot-dns-google-0:1.29.0-2.fc37
- python-certbot-dns-linode-0:1.30.0-1.fc36 >
python-certbot-dns-linode-0:1.29.0-2.fc37
- python-certbot-dns-luadns-0:1.30.0-1.fc36 >
python-certbot-dns-luadns-0:1.29.0-2.fc37
- python-certbot-dns-nsone-0:1.30.0-1.fc36 >
python-certbot-dns-nsone-0:1.29.0-2.fc37
- python-certbot-dns-ovh-0:1.30.0-1.fc36 >
python-certbot-dns-ovh-0:1.29.0-2.fc37
- python-certbot-dns-route53-0:1.30.0-1.fc36 >
python-certbot-dns-route53-0:1.29.0-2.fc37
- python-certbot-dns-sakuracloud-0:1.30.0-1.fc36 >
python-certbot-dns-sakuracloud-0:1.29.0-2.fc37
- python-certbot-nginx-0:1.30.0-1.fc36 > python-certbot-nginx-0:1.29.0-5.fc37
- python-funcparserlib-0:1.0.0a0-2.prerelease.fc36 >
python-funcparserlib-0:1.0.0-1.fc37
- python-niaaml-0:1.1.11-2.fc36 > python-niaaml-0:1.1.10-1.fc37
- python-pikepdf-0:5.5.0-1.fc36 > python-pikepdf-0:5.3.0-1.fc37
- python-pysword-0:0.2.8-0.fc36 > python-pysword-0:0.2.7-10.fc37
- python-xarray-0:2022.6.0-1.fc36 > python-xarray-0:2022.3.0-2.fc37
- srm-ifce-0:1.24.5-1.fc36 > srm-ifce-0:1.24.3-14.fc37
- zathura-pdf-mupdf-0:0.3.9-1.fc36 > zathura-pdf-mupdf-0:0.3.8-8.fc37
Downgraded packages (considering Release tag): (105)
- asciigraph-0:0.5.5-3.fc36 > asciigraph-0:0.5.4-5.fc37
- cadvisor-0:0.44.1-4.fc36 > cadvisor-0:0.44.1-3.fc37
- certbot-0:1.30.0-1.fc36 > certbot-0:1.29.0-1.fc37
- chisel-0:1.7.7-4.fc36 > chisel-0:1.7.7-2.fc37
- clash-0:1.8.0-5.fc36 > clash-0:1.8.0-4.fc37
- clementine-0:1.4.0-3.rc1.20220107git0be3143.fc36 >
clementine-0:1.4.0-2.rc1.20220107git0be3143.fc36
- cockpit-composer-0:41-1.fc36 > cockpit-composer-0:39-1.fc37
- conmon-2:2.1.4-2.fc36 > conmon-2:2.1.3-1.fc37
- deepin-qt-dbus-factory-0:5.5.22-5.fc36 >
deepin-qt-dbus-factory-0:5.5.22-4.fc37
- devilspie2-0:0.44-1.fc36 > devilspie2-0:0.43-13.fc37
- dh-make-0:2.202202-1.fc36 > dh-make-0:2.202201-2.fc37
- dotnet6.0-0:6.0.108-1.fc36 > dotnet6.0-0:6.0.107-2.fc37
- erlang-luerl-0:1.0-1.fc36 > erlang-luerl-0:0.3-10.fc37
- exaile-0:4.1.2-1.fc36 > exaile-0:4.1.1-9.fc37
- godoctor-0:0.6-13.fc36 > godoctor-0:0.6-11.fc36
- golang-github-apache-beam-2-0:2.33.0~RC1-8.fc36 >
golang-github-apache-beam-2-0:2.33.0~RC1-7.fc37
- golang-github-appc-docker2aci-0:0.17.2-10.fc36 >
golang-github-appc-docker2aci-0:0.17.2-8.fc37
- golang-github-appc-goaci-0:0.1.1-13.fc36 >
golang-github-appc-goaci-0:0.1.1-12.fc37
- golang-github-appc-spec-0:0.8.11-15.fc36 >
golang-github-appc-spec-0:0.8.11-13.fc37
- golang-github-cockroachdb-pebble-0:0-0.9.20210108git48f5530.fc36 >
golang-github-cockroachdb-pebble-0:0-0.8.20210108git48f5530.fc37
- golang-github-containerd-fuse-overlayfs-snapshotter-0:1.0.2-8.fc36 >
golang-github-containerd-fuse-overlayfs-snapshotter-0:1.0.2-7.fc37
- golang-github-coredns-corefile-migration-0:1.0.11-7.fc36 >
golang-github-coredns-corefile-migration-0:1.0.11-6.fc37
- golang-github-docker-libtrust-0:0-0.25.20190501gitaabc10e.fc36 >
golang-github-docker-libtrust-0:0-0.10.20190501gitaabc10e.fc37
- golang-github-francoispqt-gojay-0:1.2.13-8.fc36 >
golang-github-francoispqt-gojay-0:1.2.13-7.fc37
- golang-github-gobwas-pool-0:0.2.1-4.fc35 >
golang-github-gobwas-pool-0:0.2.1-3.fc37
- golang-github-gohugoio-testmodbuilder-0:0-0.11.20201030git72e1e0c.fc36
> golang-github-gohugoio-testmodbuilder-0:0-0.10.20201030git72e1e0c.fc37
- golang-github-google-containerregistry-0:0.5.1-6.fc36 >
golang-github-google-containerregistry-0:0.5.1-5.fc37
- golang-github-howeyc-gopass-0:0-0.24.20210109git7cb4b85.fc35 >
golang-github-howeyc-gopass-0:0-0.13.20210109git7cb4b85.fc37
- golang-github-hpcloud-tail-0:1.0.0-11.20190325gita1dbeea.fc36 >
golang-github-hpcloud-tail-0:1.0.0-10.20190325gita1dbeea.fc37
- golang-github-mattn-gtk-0:0-0.7.20200729gitaf2e013.fc34 >
golang-github-mattn-gtk-0:0-0.5.20200729gitaf2e013.fc37
- golang-github-oklog-0:0.3.2-12.20190701gitca7cdf5.fc36 >
golang-github-oklog-0:0.3.2-11.20190701gitca7cdf5.fc37
- golang-github-opencontainers-runc-0:1.1.4-3.fc36 >
golang-github-opencontainers-runc-0:1.1.4-2.fc37
- golang-github-prometheus-0:2.32.1-7.fc36 >
golang-github-prometheus-0:2.32.1-6.fc37
- golang-github-schollz-croc-0:9.5.2-2.fc36 >
golang-github-schollz-croc-0:9.5.2-1.fc37
- golang-github-shurcool-vfsgen-0:0-0.12.20210113git0d455de.fc36 >
golang-github-shurcool-vfsgen-0:0-0.11.20210113git0d455de.fc37
- golang-github-skynetservices-skydns-0:2.5.3-23.20200802git94b2ea0.fc36
> golang-github-skynetservices-skydns-0:2.5.3-22.20200802git94b2ea0.fc37
- golang-github-xordataexchange-crypt-0:0.0.2-13.20190412gitb2862e3.fc36
> golang-github-xordataexchange-crypt-0:0.0.2-12.20190412gitb2862e3.fc37
- golang-github-zmap-zcrypto-0:0-15.20220225git2d0ffde.fc36 >
golang-github-zmap-zcrypto-0:0-14.20220225git2d0ffde.fc37
- golang-honnef-tools-0:2021.1.2-3.20220304git852a31a.fc36 >
golang-honnef-tools-0:2021.1.2-2.20220304git852a31a.fc37
- golang-k8s-apiextensions-apiserver-0:1.22.0-7.fc36 >
golang-k8s-apiextensions-apiserver-0:1.22.0-6.fc37
- golang-k8s-kube-aggregator-0:1.22.0-5.fc36 >
golang-k8s-kube-aggregator-0:1.22.0-4.fc37
- golang-k8s-pod-security-admission-0:1.22.0-4.fc36 >
golang-k8s-pod-security-admission-0:1.22.0-3.fc37
- golang-k8s-sample-apiserver-0:1.22.0-6.fc36 >
golang-k8s-sample-apiserver-0:1.22.0-5.fc37
- golang-sigs-k8s-aws-iam-authenticator-0:0.5.2-8.fc36 >
golang-sigs-k8s-aws-iam-authenticator-0:0.5.2-6.fc37
- golang-x-crypto-0:0-0.42.20211205git5770296.fc36 >
golang-x-crypto-0:0-0.23.20220918gitc86fa9a.fc37
- golang-x-image-0:0-0.25.20201223git35266b9.fc36 >
golang-x-image-0:0-0.23.20220918gite7cb969.fc37
- golang-x-mod-0:0.6.0~dev-4.20220330git9b9b3d8.fc36 >
golang-x-mod-0:0.6.0~dev-3.20220330git9b9b3d8.fc37
- golang-x-net-0:0-0.62.20210123git5f4716e.fc35 >
golang-x-net-0:0-0.25.20220918gitbea034e.fc37
- golang-x-oauth2-0:0-0.41.20220104gitd3ed0bb.fc36 >
golang-x-oauth2-0:0-0.14.20220806git128564f.fc37
- golang-x-perf-0:0-0.16.20210123gitbdcc622.fc36 >
golang-x-perf-0:0-0.15.20210123gitbdcc622.fc37
- golang-x-time-0:0-0.23.20210123git7e3f01d.fc36 >
golang-x-time-0:0-0.14.20220807gite5dcc9c.fc37
- google-guest-agent-0:20201217.02-5.fc36 >
google-guest-agent-0:20201217.02-4.fc37
- gpart-0:0.3-16.fc36 > gpart-0:0.3-15.fc37
- grubby-0:8.40-67.fc36 > grubby-0:8.40-66.fc37
- hdparm-0:9.63-1.fc36 > hdparm-0:9.62-4.fc37
- java-latest-openjdk-1:19.0.0.0.36-3.rolling.fc36 >
java-latest-openjdk-1:19.0.0.0.36-2.rolling.fc37
- kweathercore-0:21.05-4.fc35 > kweathercore-0:0.6-1.fc37
- libdigidocpp-0:3.14.10-2.fc36 > libdigidocpp-0:3.14.10-1.fc37
- libretro-pcsx-rearmed-0:15-14.20211004gitf5b7bb8.fc36 >
libretro-pcsx-rearmed-0:15-0.17.20220905gita0d4a8f.22.fc37
- lutris-0:0.5.11-1.fc36 > lutris-0:0.5.10.1-8.fc37
- matrix-synapse-0:1.66.0-1.fc36 > matrix-synapse-0:1.63.1-2.fc37
- msitools-0:0.101.32-5.fc36 > msitools-0:0.101.32-3.fc36
- nekovm-0:2.3.0-10.fc36 > nekovm-0:2.3.0-9.fc36
- netdata-0:1.36.1-1.fc36 > netdata-0:1.35.1-3.fc37
- obs-build-0:20220812-393.9.1.fc36 > obs-build-0:20211125-376.1.3.fc37
- openjfx-3:17.0.0.1-5.fc36 > openjfx-3:17.0.0.1-4.fc37
- openssl-pkcs11-0:0.4.12-2.fc36 > openssl-pkcs11-0:0.4.12-1.fc37
- osbuild-0:67-1.fc36 > osbuild-0:65-1.fc37
- osbuild-composer-0:64-1.fc36 > osbuild-composer-0:61-1.fc37
- percona-xtrabackup-0:8.0.25_17-4.fc36 > percona-xtrabackup-0:8.0.25_17-1.fc35
- php-doctrine-doctrine-bundle2-0:2.7.0-1.fc36 >
php-doctrine-doctrine-bundle2-0:2.6.3-1.fc37
- psi4-1:1.3.2-15.fc36 > psi4-1:1.3.2-14.fc37
- python-acme-0:1.30.0-1.fc36 > python-acme-0:1.29.0-2.fc37
- python-canonicaljson-0:1.6.2-1.fc36 > python-canonicaljson-0:1.4.0-7.fc37
- python-cerberus-0:1.3.2-5.fc36 > python-cerberus-0:1.3.2-1.fc37
- python-certbot-apache-0:1.30.0-1.fc36 > python-certbot-apache-0:1.29.0-1.fc37
- python-certbot-dns-cloudflare-0:1.30.0-1.fc36 >
python-certbot-dns-cloudflare-0:1.29.0-1.fc37
- python-certbot-dns-cloudxns-0:1.30.0-1.fc36 >
python-certbot-dns-cloudxns-0:1.29.0-2.fc37
- python-certbot-dns-digitalocean-0:1.30.0-1.fc36 >
python-certbot-dns-digitalocean-0:1.29.0-2.fc37
- python-certbot-dns-dnsimple-0:1.30.0-1.fc36 >
python-certbot-dns-dnsimple-0:1.29.0-2.fc37
- python-certbot-dns-dnsmadeeasy-0:1.30.0-1.fc36 >
python-certbot-dns-dnsmadeeasy-0:1.29.0-2.fc37
- python-certbot-dns-gehirn-0:1.30.0-1.fc36 >
python-certbot-dns-gehirn-0:1.29.0-2.fc37
- python-certbot-dns-google-0:1.30.0-1.fc36 >
python-certbot-dns-google-0:1.29.0-2.fc37
- python-certbot-dns-linode-0:1.30.0-1.fc36 >
python-certbot-dns-linode-0:1.29.0-2.fc37
- python-certbot-dns-luadns-0:1.30.0-1.fc36 >
python-certbot-dns-luadns-0:1.29.0-2.fc37
- python-certbot-dns-nsone-0:1.30.0-1.fc36 >
python-certbot-dns-nsone-0:1.29.0-2.fc37
- python-certbot-dns-ovh-0:1.30.0-1.fc36 >
python-certbot-dns-ovh-0:1.29.0-2.fc37
- python-certbot-dns-route53-0:1.30.0-1.fc36 >
python-certbot-dns-route53-0:1.29.0-2.fc37
- python-certbot-dns-sakuracloud-0:1.30.0-1.fc36 >
python-certbot-dns-sakuracloud-0:1.29.0-2.fc37
- python-certbot-nginx-0:1.30.0-1.fc36 > python-certbot-nginx-0:1.29.0-5.fc37
- python-funcparserlib-0:1.0.0a0-2.prerelease.fc36 >
python-funcparserlib-0:1.0.0-1.fc37
- python-niaaml-0:1.1.11-2.fc36 > python-niaaml-0:1.1.10-1.fc37
- python-pep8-naming-0:0.13.2-2.fc36 > python-pep8-naming-0:0.13.2-1.fc37
- python-pikepdf-0:5.5.0-1.fc36 > python-pikepdf-0:5.3.0-1.fc37
- python-pysword-0:0.2.8-0.fc36 > python-pysword-0:0.2.7-10.fc37
- python-xarray-0:2022.6.0-1.fc36 > python-xarray-0:2022.3.0-2.fc37
- python-zope-hookable-0:5.1.0-2.fc36 > python-zope-hookable-0:5.1.0-1.fc37
- qt6-qtwayland-0:6.3.1-5.fc36 > qt6-qtwayland-0:6.3.1-4.fc37
- rcssserver3d-0:0.7.4-4.fc36 > rcssserver3d-0:0.7.4-3.fc37
- restic-0:0.12.1-4.fc36 > restic-0:0.12.1-3.fc37
- rust-fatfs-0:0.3.5-4.fc36 > rust-fatfs-0:0.3.5-3.fc37
- srm-ifce-0:1.24.5-1.fc36 > srm-ifce-0:1.24.3-14.fc37
- texmaker-1:5.1.3-6.fc36 > texmaker-1:5.1.3-4.fc37
- vakzination-0:22.06-2.fc36 > vakzination-0:22.06-1.fc37
- zathura-pdf-mupdf-0:0.3.9-1.fc36 > zathura-pdf-mupdf-0:0.3.8-8.fc37
1 year, 8 months
limiting the (systemd) journal size
by Chris Murphy
Hi,
Fedora uses systemd-journald for system logging. By default it is a persistent log kept on /var, and uses up to 4G disk space, although in certain circumstances it can go a bit higher. See 'man journald.conf' for details.
Example:
>Sep 27 07:26:05 fovo.local systemd-journald[602]: System Journal (/var/log/journal/$machine_id) is 385.9M, max 4.0G, 3.6G free.
In this example Fedora 37 Workstation system, logging is happening since August 20, is about 10M/day of journal accumulation, or 1.12 years of journals before garbage collection begins.
Exactly what will trigger garbage collection depends on the system. There are quite a few knobs for adjusting various aspects of retention and how granular the garbage collection will be. e.g. it's common to see 64M system journal files that contain weeks of entries. It's also possible to limit the journal file size, thus improving granularity whether to retain a bit more or less than the ideal amount.
Some folks use services with verbose or debug logging. 4G might only be a few months of logs in such a case. Whereas other folks have a small root device in which even the smaller of 10% or 4G can be quite a lot and in certain cases is not a hard limit.
Also note that on Btrfs with compression enabled, the stored amount is quite a bit less. Like all of user space, systemd-journald sees the uncompressed file sizes, so its retention behavior hasn't changed as a result of btrfs compression. What has changed is we're only (physically) storing about 1/3 of whatever the max retention is on a given system.
The obvious bike-shedding questions are:
Is 4G is too much or too little? If so what amount it should be? Is size still the correct approach? Or should we consider a max retention time? And if so, what would it be and how granular should it be?
Also, what's the scope? Is a change needed Fedora-wide, in a manner that's upstreamable? That could prove difficult because any change will negatively impact other use cases, not least of which is what the upgrade behavior should be if it'll involve trimming journals. Are the current defaults optimal for most use cases most of the time? There will be a higher burden of persuasion to get a Fedora-wide change, rather than optimizing for just desktops.
But that isn't intended to limit the discussion to just the desktop case. Just to be aware that the broader and grander the change, the more consideration of the consequences there needs to be, i.e. less bike shedding.
More background and discussion upstream and Workstation working group issues. [1]
[1]
https://pagure.io/fedora-workstation/issue/213
https://github.com/systemd/systemd/issues/17382
--
Chris Murphy
1 year, 8 months
Karma swaps
by Jerry James
I have two updates for F37 that will not be stable by final freeze
based on time alone, but that I think should be stable to avoid
disruptions to users. I could wait and ask for freeze exceptions, but
I would first like to ask the community to give karma to these
updates. I am willing to test and give karma to your updates, too.
Let me know what updates to test, and how to test them.
The two updates are:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-a6d8261b07 - sympy
https://bodhi.fedoraproject.org/updates/FEDORA-2022-21f6ca9264 - gap,
pari, & friends
The sympy update deals with the disappearance of the JDK on i386.
Sympy uses the antlr4 package, a Java package, to generate some
grammar files. Since there is no JDK on i386, there is no antlr4
package either. This makes one of the BuildRequires for the package
unresolvable. The ideal solution would be to stop building sympy on
i386. However, sympy is consumed by a number of packages that still
build for i386. I think that is the right long-term goal, and will
work toward that in the coming months. This update is a stop-gap
measure. It switches sympy from a noarch package to an archful
package so that we can omit the problematic BuildRequires on i386.
This will leave sympy partially broken on i386 (it is still mostly
functional), but that is unavoidable at this point. I think this
should go stable so that the noarch -> archful change happens at a
release boundary, rather than after F37 is released. (And hopefully
we can change back for F38!)
For testing purposes, this build of sympy should function identically
to the previous build. Install the python3-sympy and python3-ipython
packages, then verify that it starts and runs at all, perhaps like
this:
```
$ isympy
[snip sympy banner]
In [1]: import math
In [2]: math.sqrt(9)
Out[2]: 3.0
In [3]: from sympy import symbols
In [4]: x, y = symbols('x y')
In [5]: expr = x + 2*y
In [6]: expr
Out[6]: x + 2⋅y
```
The second update is large, containing 100 package builds. It
contains an update of gap to version 4.12.0, and an update of pari to
version 2.15.0. Both new versions come with significant performance
improvements. The gap update in particular drops i386 builds for all
packages named gap-pkg-*, as well as gap, GAPDoc, and xgap. I think
this should go stable before release so that the i386 disappearing act
doesn't happen post-release, and also because the gap and pari updates
both contain a few backwards incompatibilities, which should be
introduced at release boundaries.
Almost every package in this update has a test suite that is run at
build time, so they have been tested quite well already, and I have
been testing them also. To test the gap part, install the gap and
gap-pkg-xmod packages. (The gap-pkg-xmod package pulls in several
other gap-pkg-* packages, so we can show they all work together.)
Then do a few things with gap-pkg-xmod, like this:
```
$ gap
[snip gap banner]
gap> LoadPackage("xmod");
[snip package loading messages]
gap> c5 := Group( (5,6,7,8,9) );
Group([ (5,6,7,8,9) ])
gap> SetName( c5, "c5" );
gap> id5 := IdentityMapping( c5 );
IdentityMapping( c5 )
gap> ac5 := AutomorphismGroup( c5 );
<group with 1 generator>
gap> act := MappingToOne( c5, ac5 );
[ (5,6,7,8,9) ] -> [ IdentityMapping( c5 ) ]
gap> XMod( id5, act ) = XModByBoundaryAndAction( id5, act );
true
gap> H12 := SmallCatOneGroup( 12, 4, 3 );
Cat-1-group with underlying group Group( [ f1, f2, f3 ] ) .
gap> C12 := SmallCat1Group( 12, 4, 3 );
[Group( [ f1, f2, f3 ] ) => Group( [ f1, f2, <identity> of ... ] )]
gap> C12 := CatOneGroupToXMod( H12 );
[Group( [ f1, f2, f3 ] ) => Group( [ f1, f2, <identity> of ... ] )]
gap> C18 := Cat1Select( 18, 4, 3 );
[(C3 x C3) : C2 => Group( [ f1, <identity> of ..., <identity> of ... ] )]
gap> H18 := Cat1GroupToHAP( C18 );
Cat-1-group with underlying group (C3 x C3) : C2 .
gap> IdCatOneGroup( H18 );
[ 18, 4, 3 ]
gap> IdCat1Group( C18 );
[ 18, 4, 3 ]
```
To test the pari part, install the pari-gp package and try a few calculations,
like this:
```
$ gp
[snip pari banner]
? 1 + 1
%1 = 2
? (x+1)^(-2)
%2 = 1/(x^2 + 2*x + 1)
? Mod(x, x^2+x*y+y^2)^3
%3 = Mod(y^3, x^2 + y*x + y^2)
? T = x^2 + 1;
? factor(T*(1 + O(5^3)))
%5 =
[ (1 + O(5^3))*x + (2 + 5 + 2*5^2 + O(5^3)) 1]
[(1 + O(5^3))*x + (3 + 3*5 + 2*5^2 + O(5^3)) 1]
? R(x) = {
my(s);
s = zeta(2) * sum(a=1, sqrt(x), moebius(a)*(x\a^2));
(s - x) / x^0.4;
}
? R(10^7)
%7 = 0.052092560787004188970344062406837112269
? R(10^12)
%8 = 0.010948893958117048274619354741656931605
? R(10^15)
%9 = 0.00012562581350676279794919752938422775380
```
Warning: you'll notice a slight pause when computing R(10^12), and a
significant pause when computing R(10^15). Pari hasn't hung. Wait a
minute and it will be back with the answer.
Sorry for the epistle. I will be very grateful for any testing and
karma help you can give me. Let me know what I can test and give
karma to for you.
--
Jerry James
http://www.jamezone.org/
1 year, 8 months
Fwd: Fwd: CVE Tracking Bugs
by Maxwell G
Hi Huzaifa,
Thank you for your response and for getting it to me despite the issues
with the mailing list.
You have to subscribe[1] to the devel list to post to it. There
has been a lot of good discussion about this on the ML since my
original post[2].
I am forwarding this to the list to keep the community in the
loop. I will respond in more detail later.
[1]: https://lists.fedoraproject.org/admin/lists/devel.lists.fedoraproject.org/
[2]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
Best,
Maxwell
Forwarded message from Huzaifa Sidhpurwala on Sat Sep 17, 2022:
Hello Max,
Pete tried to send this email to devel list, but it got rejected, so i
thought i will forward this to you directly.
---------- Forwarded message ---------
From: Pete Allor <pallor(a)redhat.com>
Date: Wed, Sep 14, 2022 at 6:47 AM
Subject: Fwd: CVE Tracking Bugs
To: Huzaifa Sidhpurwala <huzaifas(a)redhat.com>, Przemyslaw Roguski <proguski(a)redhat.com>, Clifford Perry <cperry(a)redhat.com>
Can you all get this email to Maxwell?????
---------- Forwarded message ---------
From: <devel-owner(a)lists.fedoraproject.org>
Date: Tue, Sep 13, 2022 at 9:13 PM
Subject: Re: CVE Tracking Bugs
To: <pallor(a)redhat.com>
Your message to the devel mailing-list was rejected for the following
reasons:
The message is not from a list member
The original message as received by Mailman is attached.
---------- Forwarded message ----------
From: Pete Allor <pallor(a)redhat.com>
To: devel(a)lists.fedoraproject.org
Cc:
Bcc:
Date: Tue, 13 Sep 2022 20:49:04 -0400
Subject: Re: CVE Tracking Bugs
Maxwell,
One of my folks pointed this post out to me today. From a ProdSec
perspective, you can reach out directly to me.
The PSIRT Team and their work on CVEs report up through me, so I will be
glad to have a discussion with you and why my folks are not supporting you
fully and how to fix that.
I think the main thrust you are pointing to is that as the CNA for Fedora,
we should not be mixing all Red Hat errata into the Fedora project.
Meaning keeping them more separated and distinct. That may not address
all concerns, but I think it would be a good starting point to keep the
focus correct and distinct, not overload on messages and bring attention to
what is critical / important so they are not missed.
I am traveling this week. Can we set a meeting next week to discuss
further?
Pete
***********************
Hi Fedorians,
I think the security tracking bug filing process needs to be amended. The
current process is quite frustrating for me and other contributors. This
is especially bad for Go CVEs, which there are lot of.
Red Hat Product Security creates a single tracking bug for Fedora{, EPEL}
_and_ all Red Hat products and CCs a bunch of Fedora maintainers. They
then create separate bugs for each package that they deem affected. The
affected packages are oftened determined in a manner that appears
overzealous and arbitrary.
After the bugs are created, we get spammed with a bunch of notifications
about private bugs, RH product errata, and various other things that are
completely irrelevant to Fedora. These messages flood my Bugzilla mailbox
and obscure actual issues that I need to address. I do not really care
whether a Go CVE has been mitigated in Red Hat Advanced Cluster
Management for Kubernetes 2.4 for RHEL 8"
or "Red Hat Advanced Cluster Management for Kubernetes 2.5 for RHEL 8"
or "Red Hat Advanced Cluster Management for Kubernetes 2.6 for RHEL 8."
---
Some particularly egregious examples:
I maintain an Ansible kubernetes collection, and they reported it as
vulnerable to some CVE with a specific Openshift component. The
collection not vulnerable. They provided no actionable information, and
the description was unclear. When I asked why it was reported, they said
that the package "used OpenShift."
A couple Go CVEs ago[^1], they created bugs against hundreds of Go
libraries. They arbitrarily chose branches and packages. The bugs were
not actionable by packagers of individual go libraries. Only applications
that provide binaries need to be rebuilt. They were reported shortly
before the F34 EOL, so we got a huge amount of emails after the bugs were
automatically closed. In fact, a Go packager reported that these messages
from the _security_ team DOSed their mail server. To their credit, they
have fixed this issue after one of the other Go SIG people talked to
them. Now, these bugs are only filed against the golang component.
[^1]: Really, it was a couple Go releases ago. There are multiple CVEs
reported with each Go release these days.
Another time, their automation posted the exact same comment over 200
times.
---
First and foremost, there needs to be a clear way for packagers to report
problems with this process to prodsec.
I don't think Fedora packagers should be CCed on these global trackers.
We could create a separate "Security Response" component under the
"Fedora" Bugzilla product to create tracker bugs for CVEs that affect
multiple Fedora components, or we could ask prodsec to only CC Fedora
maintainers on the child, package-level bugs. I guess I could acomplish
what I'm proposing by filtering out mails with "X-Bugzilla-Product:
Security Response" headers and not have gone on this rant, but I still
think this needs to be addressed.
Does anyone know how to reach prodsec about this?
--
Best,
Maxwell G (@gotmax23)
Pronouns: He/Him/His
******************************
--
Pete Allor, Director, Red Hat Product Security - Secure Engineering
(m) 1-404-200-4630
--
Pete Allor, Director, Red Hat Product Security - Secure Engineering
(m) 1-404-200-4630
--
Regards,
Huzaifa Sidhpurwala
Senior Principal Product Security Engineer / Red Hat Product Security
1 year, 8 months