Schedule for Thursday's FESCo Meeting (2023-09-21)
by Zbigniew Jędrzejewski-Szmek
Note: this announcement is very late, I know. But we didn't assign
any chair for this meeting, so setting of the agenda slipped through
the cracks.
Following is the list of topics that will be discussed in the
FESCo meeting Thursday at 17:00UTC in #fedora-meeting-2 on
irc.libera.chat.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/UTCHowto
or run:
date -d '2023-09-21 17:00 UTC'
Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda
= Discussed and Voted in the Ticket =
#3057 Migrate official FESCo chat and meetings to Matrix
https://pagure.io/fesco/issue/3057
We will wait for the missing functionality in Matrix to implemented (+3, 0, 0).
= Followups =
#3059 F39 incomplete changes: 100% complete deadline
https://pagure.io/fesco/issue/3059
= New business =
#3063 Should we remove Systemd-boot support from Anaconda
https://pagure.io/fesco/issue/3063
#3068 Ongoing problems with ELN contributions
https://pagure.io/fesco/issue/3068
= Open Floor =
For more complete details, please visit each individual
issue. The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda
If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
6 months, 1 week
Update for ddcutil and for dependent package (powerdevil)
by Qiyu Yan
Hi all,
I am planning to update package ddcutil to latest upstream release
2.0.0. This will introduce a soname bump for libddcutil.so from
libddcutil.4 to libddcutil.5. I checked that the only affected package
due to this update will be powerdevil.
dnf repoquery --whatrequires "libddcutil.so.4()(64bit)" --release=40
...
powerdevil-0:5.27.8-1.fc40.x86_64
I have built ddcutil in following side-tags:
* f38-build-side-74742
* f39-build-side-74740
* f40-build-side-74738
If possible, please built powerdevil in those side-tags that we can push
the update together.
Cheers,
Qiyu
6 months, 2 weeks
Packaging guidelines - validation of AppStream metadata files
by Alexander Ploumistos
Hello,
According to our packaging guidelines[1], "you MUST run appstream-util
validate-relax (in %check or %install) and have BuildRequires:
libappstream-glib, to help ensure the validity and safety of the
appdata files you’re installing".
For quite some time now, I've been seeing references to another tool,
appstreamcli (provided by the appstream[2] package), being used
instead of appstream-util. Debian guidelines recommend it[3], it's
documented upstream[4] and apparently there are a few fedora packages
that use it already[5] (google found 10, I know of a couple more). By
the way, if you take a closer look, some of these packages appear to
use the "--nonet" flag from appstream-util instead of "--no-net",
which is used by appstreamcli.
Furthermore, on the web page of AppStream-Glib there's a warning that
it is in heavy maintenance mode and to use appstream instead[6].
By all indications, appstream will replace appstream-glib and in the
case of the corresponding validator utilities, this has already begun.
However, at least on this list, I was unable to find any clue that
this was happening and there are zero mentions of appstreamcli on
docs.fedoraproject org, hence this message. Could someone involved
with AppStream please provide some information? Shouldn't our
documentation be changed to reflect these changes? Does the FPC need
to decide on this?
Best regards,
Alexander
1. https://docs.fedoraproject.org/en-US/packaging-guidelines/AppData/
2. https://github.com/ximion/appstream
3. https://wiki.debian.org/AppStream/Guidelines
4. https://www.freedesktop.org/software/appstream/docs/api/re32.html
5. https://www.google.com/search?q=%22appstreamcli+validate%22+site%3Asrc.fe...
6. https://github.com/hughsie/appstream-glib
6 months, 2 weeks
F38 proposal: Rpmautospec by Default (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
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 ==
Rpmautospec (`%autorelease` and `%autochangelog`) is recommended as
the default approach.
Packaging Guidelines and other documentation are adjusted to describe
this approach first.
Various tools that provide spec file templates are adjusted.
== Owner ==
* Name: [[User:Nphilipp| Nils Philippsen]], [[User:Zbyszek| Zbigniew
Jędrzejewski-Szmek]]
* Email: nphilipp - at - redhat.com, zbyszek - at - in.waw.pl
== Detailed Description ==
{{admon/note|Brief reminder about rpmautospec|
The spec file contains:
<pre>
Version: 1.2.3
Release: %autorelease
...
%changelog
%autochangelog
</pre>
Rpmautospec uses git history. Whenever the package is built
(`.src.rpm` is generated), rpmautospec tooling will replace the
`%autorelease` macro with the number of commits since the last commit
that changed the `Version` field, and the `%autochangelog` macro with
a text generated from `git log`.
For details see the
[https://docs.pagure.org/fedora-infra.rpmautospec/principle.html
docs].
}}
Rpmautospec has been deployed in Fedora since F35
([[Changes/rpmautospec]]), and 3423/23045 packages use it (15%).
But it is still a "second-class citizen": most documentation doesn't
mention it, and many packagers know that it exists but don't use it in
their packages. We think that it's reasonable to switch to
`%autorelease`+`%autochangelog` for almost all packages and that
Packaging Guidelines and various packaging howtos should recommend
that approach to packagers. The "traditional" approach of
manually-managed `Release` and `%changelog` will remain valid and will
be documented as a fallback.
This change is targeted at Fedora 38, but it will actually apply to
all releases. The goal is to update the Packaging Guidelines and other
prominent documentation and tools now, and other docs and tools
possibly at a later time. Changing packages is out of scope.
It is worth mentioning that `rust2rpm` uses
`%autorelease`+`%autochangelog` since a few releases, so most rust
packages have switched. (Generally, rust spec files are recreated
using the generator for each new version, so the switch would happen
whenever a new version is packaged unless the packager opts out.)
== Feedback ==
* Thread on fedora-devel in August 2022:
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
rpmautospec by default]
** open issues: a bunch have been fixed.
** maintenance: Nils will add some co-maintainers.
** compatibility with rpmdevtools, fedpkg/rpkg, fedora-review: see
Scope section.
== Benefit to Fedora ==
Various packaging workflows become smoother for packagers and contributors:
* packagers don't need to touch the `Release` field on updates
* packagers describe changes just once in the git commit message, the
`%changelog` entry is autogenerated
* patches to the spec file can be cherry-picked between branches
without trivial conflicts
* pull requests on src.fedoraproject.org can be merged without trivial conflicts
* in workflows that regenerate the spec file (rust2rpm, pip2rpm, …)
`%changelog` section doesn't need to be copied over
== Scope ==
* Proposal owners:
** provide pull requests to Packaging Guidelines and other docs to
make `%autorelease`+`%autochangelog` the default
** implement fixes for issues reported by packagers
** make semi-regular releases of rpmautospec
([https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
0.3.1 was released on November 17th, and should be deployed to
production in about two weeks])
* Other developers:
** provide pull requests to other docs as appropriate
** accept the changes to documentation
** update other spec file generators (pip2rpm, others?)
* Somebody (TBD):
** `fedora-review` — https://pagure.io/rpkg/issue/641
** `fedpkg import` — with https://pagure.io/rpkg/c/3087dd7, the
command will fail. A replacement workflow that instead restores
`%autorelease`+`%autochangelog` in the file committed to dist-git
needs to be implemented.
* Related work
** https://pagure.io/rpkg/c/3087dd7
** https://src.fedoraproject.org/rpms/fedora-packager/pull-request/4
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: a list of places to be updated
** https://docs.fedoraproject.org/en-US/packaging-guidelines/#changelogs
** https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning
** https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutori...
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
Rpmautospec is already used by a decent number of packages, so any
issues are already being seen and need to be fixed anyway.
== How To Test ==
* Convert an existing package: `rpmautospec convert`. Ideally this
step is done right before a version bump so that the release numbers
restart at `-1`.
* Do local builds (`fedpkg local`, `fedpkg mockbuild`). Verify
correctness of version-release (`rpm -qpi`) and the changelog (`rpm
-qp --changelog`).
* Do builds in koji. Verify correctness of version-release and the changelog.
* For new packages, use `%autorelease`+`%autochangelog`. Repeat all
the tests listed above.
* Assume you are a newbie packager. Read the packaging docs and check
that the workflow is clear and the intructions are sufficient to use
rpmautospec tooling correctly.
== User Experience ==
No changes visible to end users.
== Dependencies ==
None.
== Contingency Plan ==
If it turns out that the rpmautospec workflows have unknown problems,
we can revert changes to documentation.
* Contingency mechanism: Revert changes to documentation by reverting
the appropriate commits. This can be done easily by FPC.
* Contingency deadline: Any time.
* Blocks release? No.
== Documentation ==
This page and any changes to Packaging Guidelines and other documents.
== Release Notes ==
Not needed.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
6 months, 2 weeks
zlib-ng as a compat replacement for zlib
by Richard W.M. Jones
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-com...
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
6 months, 3 weeks