Backwards-incompatible RPM format change in Fedora 34?
by Florian Weimer
With rpm-4.15.1-3.fc32.1.x86_64, I get this error:
$ rpm -qip https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everyth...
error: /var/tmp/rpm-tmp.6iU66n: signature hdr data: BAD, no. of bytes(88084) out of range
error: https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everyth...: not an rpm package (or package manifest)
Is this expected?
It seems that rpm-4.16.1.2-1.fc33.x86_64 can parse the RPM just fine.
But rpm-4.14.3-4.el8.x86_64 does not like it, either.
Thanks,
Florian
--
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
1 hour, 25 minutes
Policy proposal (draft): Don't push knowingly broken or
work-in-progress work to dist git
by Miro Hrončok
Hello,
When we work on rebuilding Python packages with new Python version and when
other provenpackagers rebuild multiple packages at once, I've seen several
problems with packages failing to build from source and/or creating unexpected
breakage in rawhide when built. Usually, some of the following happens:
1. Untested changes
Packager pushes a "simple update" to dist git without checking if it even
builds. It doesn't. Packager has no time to fix this, so they move on for now.
Or they submit a build but never check if it actually built. Provenpackagers who
need to rebuild the package need to figure this out and fix the problem if it is
trivial, or revert the recent commit, when the failure blocks them.
IMHO Provenpackagers should not need to worry about this. Changes should be at
least smoke tested by a mock/scratch build and installation check before
shipping them.
2. Changes that work but are waiting on external factors
Packager pushes a breaking change to dist git (such as a soname bump) before
coordinating the change with the dependent packages, not intending to
immediately build it. A provenpackager rebuilds the package for a different
reason (such as a different soname bump), accidentally shipping the
not-yet-wanted upgrade to rawhide.
IMHO Provenpackagers should not need to worry about this. Commits should land in
dist git only when they are intended to be built (close to) immediately. The
only reasonable exception is when building the pushed changes in a side tag and
even then, packagers should communicate their intentions.
3. Work-in-progress changes
Packager works on a package. They have a work in progress solution to their
problem, but no time to finish. They push a "WIP" commit that either breaks the
build or produces a broken package. The symptoms are similar to (1) or (2). I've
heard packagers saying "but this is rawhide, this is where development happens,
so this is expected" - I disagree.
---
I'd like to explicitly say that neither of this is considered a good behavior.
I'd like to have a policy that more or less says:
1. Packagers MUST NOT push changes that are not considered ready to be built and
shipped at the time of the push. Using Pull Requests (clearly marked as not
ready to be merged) is a better place to present/save changes that are not ready
yet.
2. Packagers SHOULD preemptively check if the changes they intend to push work.
At least checking if the intended change builds and the package installs with it
is strongly recommended. In cases where the check is skipped for time reasons
(e.g. when a testing build takes several hours and the changes are urgent),
packagers SHOULD be ready to fix the build/installation failure in timely manner
after it is discovered by the actual build.
Before I try to word it more carefully I'd like to hear some feedback on this.
What do you think?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 hour, 27 minutes
Re: PackageKit-gtk3-module i686 (x86_32) is missing in Fedora 33 repositories
by Kamil Paral
On Mon, Jan 25, 2021 at 11:17 AM Graham White <graham_alton(a)hotmail.com>
wrote:
> Hi,
>
> I'm trying to get to the bottom of bug #1901065 -
> https://bugzilla.redhat.com/show_bug.cgi?id=1901065
>
> Anyone know why PackageKit-gtk3-module.i686 has been removed from the
> Fedora 33 repositories? This package was there for Fedora 32 and checking
> Koji it looks like the 32-bit version is still being built. However, for
> some reason it's not appearing in the F33 repositories for the x86_64
> architecture. We have some packages that rely on the 32-bit version so it
> would be good to have it re-included in the repo.
>
Multilib detection (which i686 packages should end up in x86_64 repos) is
done in Pungi. There is some heuristics which I haven't found documented
anywhere (one would think it should be in the packaging docs). A
whitelisting of some package can be requested here:
https://pagure.io/pungi-fedora/issues
However, as you can see, the maintainers don't respond much to such
requests :-( Perhaps Mohan, Kevin or others could shed a light here how to
best make sure those requests are noticed? Thanks.
1 hour, 38 minutes
32bit arm builder issues
by Kevin Fenzi
Greetings.
As some of you may know we have been having issues with our 32bit arm
buildvm's the last few days. ;(
I had moved them to f33, and increased memory on them (from 24GB to
40GB). We then ran into a number of issues:
* vm's started 'pausing' (which requires a full reboot). This was
tracked to a kernel config change we made in f29 getting lost along
the way. A new f33 kernel build fixed this issue.
* Then, the vm's seemed to just build things more slowly than before.
I tried reducing the memory to 32GB, and then finally back to 24GB and
things seem back to where they were before from my simple testing.
So, since 2021-01-22 04:00UTC or so (when they were last rebooted) has
anyone seen any big slowdowns? My reference build (python3.8 + tests
enabled) takes about 45min, which is close to what it took before
(40min).
kevin
1 hour, 48 minutes
How to change FAS username and email
by Andrew Toskin
I'm having a hard time finding anything about this...
1. I need to change my email address. As I recall, when my Fedora account was first created, it was supposed to automatically link to my existing Red Hat Bugzilla account as long as they both used the same email. Right? I just want to confirm that the accounts will stay linked when updating my email.
2. I'm also considering changing my FAS nick/username; it's an oblique reference to something that I don't want to use as my name anymore. I asume this would require submitting a ticket to Pagure, but I'm not sure which section to file it under.
1 hour, 50 minutes
Fedora 35 Change: Add Fedora Kinoite as a variant (Self-Contained
Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Fedora_Kinoite
== Summary ==
Introduce Fedora Kinoite as a variant of Fedora alongside Fedora Silverblue.
== Owner ==
* Name: [[User:siosm| Timothée Ravier]] (travier AT redhat DOT com)
* FESCo shepherd: [[User:Ngompa| Neal Gompa]] (ngompa13 A gmail D com)
* SIG: [[SIGs/KDE|KDE SIG]]
== Detailed Description ==
Fedora Kinoite is an immutable desktop operating system featuring the
KDE Plasma desktop. It is based on the same technologies as Fedora
Silverblue (rpm-ostree, Flatpak, podman). Fedora Kinoite is to the
Fedora KDE Spin what Fedora Silverblue is to Fedora Workstation.
We chose the Kinoite name for the following reasons:
* KDE based projects traditionally start with a 'K'
* Kinoite is a blue mineral (https://en.wikipedia.org/wiki/Kinoite),
thus referring to both the 'silver' and 'blue' part of Silverblue and
the blue color of the KDE logo.
* "Kinoite" means "There is a tree" in Japanese
(https://translate.google.com/?sl=auto&tl=en&text=kinoite&op=translate),
thus referring to the 'tree' in 'ostree'.
== Benefit to Fedora ==
This will make Fedora more attractive to users that are interested in
immutable OSes and underlying technologies but would prefer to use the
KDE desktop environment. This should also strengthen Silverblue as
more effort may be put into fixing the issues in the shared
technologies.
== Scope ==
* Proposal owners:
** The KDE SIG will submit the [https://pagure.io/pungi-fedora Pungi
changes] needed to add this new variant to the compose.
** The KDE SIG will submit the changes to add a new sub-package to
[https://src.fedoraproject.org/rpms/fedora-release fedora-release].
** The KDE SIG will maintain the Kinoite specific rpm-ostree config in
the [https://pagure.io/workstation-ostree-config
workstation-ostree-config repo].
* Other developers: N/A (not a System Wide Change)
* Release engineering: Submitted as [https://pagure.io/releng/issue/9952 #9952].
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: The "Fedora Kinoite" trademark has been
[https://pagure.io/Fedora-Council/tickets/issue/344 approved]
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
This edition has been built and made available as an unofficial
preview and can be tested with the instructions from this
[https://fedoramagazine.org/discover-fedora-kinoite/ Fedora Magazine
article].
== User Experience ==
Current limitations (last updated 2021-01-18):
* No rpm-ostree support in Discover (graphical package and update
manager). A Season of KDE is in progress to work on that.
* Partial Flatpak support in Discover.
* [https://pagure.io/fedora-kde/SIG/issue/13 KDE applications are not
yet available as Flatpak from the Fedora registry].
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
Report to the next release.
* Contingency mechanism: N/A (not a System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
* Blocks product? N/A
== Documentation ==
A lot of the known issues impacting Fedora Kinoite are shared with
Silverblue and their resolution is the same:
https://docs.fedoraproject.org/en-US/fedora-silverblue/troubleshooting/.
It is not clear for now if Kinoite specific documentation is needed
but a landing page with pointer to known issues might be good.
== Release Notes ==
Fedora Kinoite has been introduced as a new variant of Fedora Linux
featuring the KDE desktop environment and the same technologies as
Silverblue (rpm-ostree, Flatpak, podman).
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 hours, 21 minutes
Fedora 34 Change: PostgreSQL 13 (Self-Contained Change)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/PostgreSQL_13
== Summary ==
Update of PostgreSQL (`postgresql` and `libpq` components) in Fedora
from version 12 to version 13 in the non-modular (main) builds.
Also, there will be a design change in postgresql modular packaging
regarding the external libpq library ensuring future build time
compatibility. More information in the Detailed Description section.
== Owner ==
* Name: [[User:panovotn| Patrik Novotny]]
* Email: panovotn(a)redhat.com
== Detailed Description ==
Update of PostgreSQL (`postgresql` and `libpq` components) in Fedora
from version 12 to version 13 in the non-modular (main) builds.
This also involves updating and rebuilding the PostgreSQL plugins that
depend on postgresql server.
There will also be a change to the packaging of postgresql modules, as
with those, the external libpq library can be potentially problematic
upon upstream releases.
As postgresql packages are built against the separated libpq package,
an incompatibility between major versions can occur with new minor
upstream releases. For example, when building postgresql version 12.4
against libpq version 13.1.
To keep the benefits of having separately maintained libpq library,
libpq stays as a separate package.
However, to solve the potential issues with the postgresql builds, we
will bundle libpq with a downstream changed SONAME within each
postgresql release. The postgresql will be built against this libpq.
This bundled libpq will always be the same version as the
corresponding postgresql as they will share the same codebase. As the
libpq SONAME will be changed downstream to a non-standard SONAME, and
separate libpq package with standard SONAME will be provided, this
change won't affect the user experience for those components.
=== Plan ===
* Prepare Libpq 13, PostgreSQL 13 (both rawhide and module) and
PostgreSQL 12 module
* Rebuild dependencies in Copr
** By 2021-01-15
* Debug and fix compatibility issues found in dependencies (reasonable
amount of non-critical in FTBFS state might be tolerable)
** By 2021-01-22
* Prepare builds in a side-tag
* Merge side-tag into Rawhide
** By 2021-01-29
== Benefit to Fedora ==
Latest stable software is used by Fedora users.
== Scope ==
* Proposal owners:
<!-- What work do the feature owners have to accomplish to complete
the feature in time for release? Is it a large change affecting many
parts of the distribution or is it a very isolated change? What are
those changes?-->
**Prepare PostgreSQL 13 as a module for Rawhide and at least one
stable Fedora release (including the design change and symbol
versioning fix)
**Prepare PostgreSQL 12 as a module for Rawhide
**Check software that requires or depends on `postgresql-server` or
`libpq` packages for incompatibilities
**Build PostgreSQL 13 (postgresql and libpq) to Rawhide in a side-tag
(https://fedoraproject.org/wiki/Package_update_HOWTO#Creating_a_side-tag)
**Rebuild depended packages against PostgreSQL 13 in the side-tag (see
Dependencies)
**Merge the side-tag to Rawhide
**Gather user input on the changes between PostgreSQL 12 and PostgreSQL 13
* Other developers: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
The PostgreSQL client library (libpq component) is compatible, but
there is an issue with symbol versioning (originally reported
https://bugzilla.redhat.com/show_bug.cgi?id=1893324 was reverted, but
there is a plan to fix this properly together with this PostgreSQL
update tracked in
https://bugzilla.redhat.com/show_bug.cgi?id=1908268). So, there
shouldn't be any issues with API compatibility, but rebuild of the
depended components is necessary.
Server plugins might require a newer version update, because they
sometimes have explicit server requirements. PostgreSQL maintainer
will help fixing/rebuilding any issues in the plugins.
== How To Test ==
Usual testing as when upgrading between major PostgreSQL versions,
running `postgresql-setup --upgrade` is necessary between major
versions.
Test that all other software runs well with PostgreSQL 13.
== User Experience ==
The users will have to upgrade their databases the same way as between
major PostgreSQL versions, aka `postgresql-setup --upgrade` after
installing PostgreSQL 13 server packages.
If users want to stick with PostgreSQL 12 for a little longer, there
will be PostgreSQL 12 module
== Dependencies ==
There are some packages (mostly server plugins), that build on top of
PostgreSQL. Since the separation of PostgreSQL client library (libpq
component), only packages that build server plugins should use
postgresql package in BuildRequires, others should use libpq. In both
the cases, rebuild should be done to make sure all potential binary
incompatibilities are handled.
* Critical dependecies - components with higher importance, will be
prioritised during the rebase
** apr-util
** bacula
** bind
** cyrus-imapd
** cyrus-sasl
** dovecot
** freeradius
** gdal
** libecpg
** nagios-plugins
** opendbx
** perl-DBD-Pg
** php
** pgaudit
** postfix
** qt
** qt3
** qt5-qtbase
** redland
** rsyslog
** rubygem-pg
** postgres-decoderbufs
The rest of the dependencies is not considered critical. Though, those
will need to be rebuild as well.
* libpq
** EMBOSS
** Io-language
** PDAL
** PyGreSQL
** asterisk
** biboumi
** clisp
** collectd
** dpsearch
** exim
** flow-tools
** freight-tools
** gambas3
** gammu
** gawk-pgsql
** gearmand
** gnatcoll-db
** gnokii
** grass
** hydra
** jabberd
** kdb
** kea
** libdbi-drivers
** libgda
** libnss-pgsql
** libpqxx
** libpreludedb
** libzdb
** lua-dbi
** lua-sql
** mapnik
** mapserver
** medusa
** minetestmapper
** ocaml-postgresql
** opensips
** openvas-manager
** osm2pgsql
** pdns
** perl-pgsql_perl5
** pg_top
** pgadmin3
** pgcenter
** pgmodeler
** php-pecl-pq
** player
** postgis
** postgresql
** postgresql-pgpool-II
** proftpd
** pspp
** pure-ftpd
** rdkit
** rhdb-utils
** root
** saga
** soci
** spatialite-gui
** sphinx
** sysbench
** tcl-pgtcl
** unicornscan
** virtualpg
** vtk
** zabbix
* postgresql-server
** gambas3
** kdb
** kea
** libpqxx
** openvas-manager
** orafce
** pg-semver
** pgRouting
** pgadmin3
** pgsphere
** postgis
** postgresql-ip4r
** postgresql-pgpool-II
** qt3
** rdkit
** rhdb-utils
** timescaledb
== Contingency Plan ==
Revert changes in the non-modular packages and provide PostgreSQL 13
as a module stream only.
Soft contingency plan deadline: Before Mass Rebuild (scheduled on Wed
2021-01-20)
Hard contingency plan deadline: Before Branch Fedora 34 from Rawhide
(scheduled on Tue 2021-02-09)
== Documentation ==
Upgrade startegy: https://www.postgresql.org/docs/13/upgrading.html
== Release Notes ==
Release notes for PostgreSQL 13 release:
https://www.postgresql.org/docs/13/index.html
Overall overview of the changes and improvements:
https://www.postgresql.org/docs/13/release-13.html
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 hours, 33 minutes
Fedora 34 Change: Localization measurement and tooling
(Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/LocalizationMeasurementAndTooling
== Summary ==
Provide a public website for end users and contributors, containing
Fedora Workstation translation progress and useful files for
translators (as an example: translation memories).
== Owner ==
* Name: [[User:jibecfed|Jean-Baptiste Holcroft]],
[[User:darknao|Francois Andrieu]]
* Email: <jean-baptiste(a)holcroft.fr>
== Detailed Description ==
Language support is a transversal activity, there is no way to know
the actual language support provided by Fedora as an Operating System.
Because language support and translations are part of each upstream
software, the Linux language community is as spread as the Free Libre
and Open Source community is.
The ability to share efforts is limited (with data, tools, etc.):
* because of the complexity to get an overview of the current
localization status of the Linux community,
* because translators often have a low level of technical knowledge,
* because development experts are more keen to use English by default,
and don't know much about languages support requirements.
Debian did something similar (20 years ago)
https://www.debian.org/international/l10n/ . But this work:
* is limited in terms of features (no translation memories there)
* is too deeply integrated with Debian infrastructure (data
extraction, computation and website generation are 100% debian
specific)
* is using a programming language that doesn't allow to share easily
with existing i18n/l10n libraries (it did not exist 20 years ago)
== Benefit to Fedora ==
It is a progress for the project: provide a new tool to translator community.
It helps the Linux community to better understand the language support
challenges.
It increases contributors effectiveness by providing translation
memories and other tools.
These translation memories open new possibilities:
* to train machines to suggest new translations?
* to detect quality issues (spellcheck, linters, etc)?
* the change the way we ship translations to users? (Ubuntu does it,
but never bring back translation to main project)
* to advertise user that Linux is available in many languages?
== Scope ==
All of the work is isolated, as long as dnf works, the automation
works. The closer to mirror the cheaper it is for network cost (all
Fedora is downloaded at each execution).
* Proposal owners:
** [[User:Darknao|Francois Andrieu]] integrate the existing scripts
into containers to allow execution into openshift
** Infra team:
*** provide some space for script execution (50 GB per release)
*** provide the languages.fedoraproject.org domain name
*** provide a location for static website (about 2 GB per release, may
increase over time)
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with mission: ''In our community, contributors of all
kinds come together to advance the ecosystem for the benefit of
everyone.''
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
== Documentation ==
A draft with simplistic template is there:
https://jibecfed.fedorapeople.org/partage/fedora-localization-statistics/...
Code and "documentation" are there:
https://pagure.io/fedora-localization-statistics
About other project:
* Debian's code to build website with language progress:
https://salsa.debian.org/webmaster-team/webwml/-/commits/master/english/i...
* Ubuntu's code to build langpacks:
https://bazaar.launchpad.net/~ubuntu-langpack/langpack-o-matic/main/files
** Note: ubuntu does provide language progress in launchpad:
https://translations.launchpad.net/ubuntu and some useful
documentation is there: https://dev.launchpad.net/Translations
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 hours, 36 minutes