Hi,
We'd like to announce that the Fedora Packager Dashboard passed the testing
period, was properly deployed inside Fedora Infrastructure, got fixes,
improvements and feature additions and is now available for widespread use
among all Fedora Packagers.
For those of you who didn’t hear about the Dashboard yet, It combines all
relevant information for package maintainers into one web application with
searching and both simple and advanced (regex based) filtering
possibilities. You’ll find things like open bug reports, updates,
overrides, FTBFS (from koschei and from Fedora Health Check by decathorpe)
and FTI reports, pull requests and orphan/retire warnings not only for your
packages directly, but even for packages you depend on. It’s designed to
make a packager's life easier and save our packagers some of their time. An
article showing it’s current features is available on Fedora Community
Blog: https://communityblog.fedoraproject.org/fedora-packager-dashboard/
. There
will also be a talk about the Dashboard on DevConf.cz 2021:
https://devconfcz2021.sched.com/event/gmLm/packager-dashboard-life-of-packa…
.
Dashboard itself is available: https://packager-dashboard.fedoraproject.org/
(the Dashboard is automatically pulling new data every 15 minutes, so you
can just leave it open in one of your browser tabs and don’t worry about
reloading it :) )
Fedora Packager Dashboard leverages caching in the Oraculum backend to
significantly speed-up loading times with comparison to querying all the
relevant resources separately. We, of course, can't cache the entire
Bugzilla, Pagure, Bodhi... so we only cache data for users who
visit Packager Dashboard at least once per 14 days. Please keep in mind
that the first load for a “new” user might take a while. Most of the data
sources are refreshed every hour.
You can use the Dashboard for individual accounts as well as for FAS groups.
While the testing period is behind us and we have everything properly
deployed, the work doesn’t end here. We have longer term plans for even
more stuff for the dashboard. On the top of our list currently sit support
for private bugs (visible after you authenticate with FAS), and contextual
schedules and calendars for packages you might be interested in (eg. Do you
maintain some Python packages? You might want to have a Python Release
Calendar on your dashboard.)
Feel free to provide ideas or bug reports at
https://pagure.io/fedora-qa/packager_dashboard or simply send an email
reply to this thread with all kinds of feedback.
The change complete (100% complete) deadline for Fedora 34 changes is
Tuesday 23 February. At that point, changes should be 100% code
complete, along with supporting documentation where appropriate.
Please indicate this by setting the tracker bug for your change to
ON_QA.
Other upcoming schedule milestones:
* 2021-02-23 — Beta freeze begins
* 2021-03-16 — Beta release early target date
* 2021-03-23 — Beta release target date #1
For more information, see the schedule[1]
[1] https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/Power4kPageSize
== Summary ==
On ppc64le, the kernel is currently compiled for 64k page size.
This change proposes using the more common 4k page size.
Some HPC workloads may be disadvantaged slightly. Workstation users
are likely to encounter fewer bugs.
Some things, like the AMD Radeon GPU drivers, firmware or related
code, appear to be completely non-functional on the 64k page size.
Insufficient upstream developers are testing such issues on this
architecture.
== Owner ==
* Name: [[User:pocock|Daniel Pocock]]
* Email: daniel(a)pocock.pro
== Detailed Description ==
== Feedback ==
Discussed several times on devel,
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
latest here]
[https://forums.raptorcs.com/index.php/topic,248.msg1852.html
discussed upstream in the Raptor forum]
== Benefit to Fedora ==
Better first impression for users of ppc64le workstations.
Users can focus on reporting ppc64le bugs without being sidetracked by
page size bugs.
== Scope ==
* Proposal owners: [[DanielPocock]]
* Other developers: please volunteer by adding your name here
* Release engineering: [https://pagure.io/releng/issue/9939 #9939]
** wait for 5.12 kernel, verify that it includes the Btrfs patches for
arbitrary 4k / 64k sector size, independent of the page size
** create a kernel with 4k page size to run on the ppc64le build servers
** ensure the default kernel RPM in the distribution has 4k page size
** perform the mass rebuild running on the 4k page size
** create an installer ISO based on the revised kernel with 4k page size
* Policies and guidelines: no, as it is an arch-specific issues, most
other architectures already have a 4k page size
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: none of the current objectives relate to
this change
== Upgrade/compatibility impact ==
If the user has already formatted their root filesystem with Btrfs and
a 64k sector size, they need to be using a Fedora kernel that supports
both 4k and 64k. This is anticipated in a future kernel release, 5.12
and will hopefully be ready for F34 or
F35[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject….
== User Experience ==
New GPUs are more likely to just work on this non-x86 architecture, as
long as the latest firmware, mesa, llvm are also used.
Btrfs, the default filesystem, will use the sector size identical to
the running kernel's page size. As the 4k page size is more common,
this will ensure Btrfs filesystems created on ppc64le hosts can be
used on x86 and other hosts without hassle.
== Dependencies ==
All RPMs must be rebuilt on a server running the final page size (4k)
== Contingency Plan ==
* Contingency mechanism: Prepare a kernel with the original 64k
config, install it on the build server, rebuild all the packages for
this architecture
* Contingency deadline: whenever the last time for a full rebuild or
kernel change is possible
* Blocks release? Yes, full rebuild of all packages must be completed
before release
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/rpmautospec
== Summary ==
The goal of this change is to deploy in production the
[https://docs.pagure.org/fedora-infra.rpmautospec/ rpmautospec]
project.
With it, the content of the `Release` and `%changelog` fields in spec
files can be auto-generated, either locally or in the builder using
the information present in the git repo (in the form of git tags).
Note: This proposal is about changing the way the `Release` and
`%changelog` sections of the '''spec files''' are filled, not about
removing them from the SRPM or binary RPM.
== Owner ==
* Name: [[User:pingou| Pierre-Yves Chibon]]
* Email: pingou - at - pingoured.fr
* Name: [[User:nphilipp| Nils Philippsen]]
* Email: nphilipp - at - redhat.com
== Detailed Description ==
rpmautospec offers packagers who want to use it the possibility of
replacing the content of the `Release` of their spec file by `Release:
%autorel` and/or replace the content of the `%changelog` section of
their spec file by:
%changelog
%autochangelog
Both `%autorel` and `%autochangelog` are RPM macros that will be
expanded or replaced when the SRPM is built on the build system by
their corresponding values according to rpmautospec.
An overview of how rpmautospec works can be found at:
https://docs.pagure.org/fedora-infra.rpmautospec/principle.html.
We will describe below how each macro works.
=== The %autorel macro ===
To determine the next release information, rpmautospec relies on the
build history of the package.
This information is extracted from the buildsystem when running as a
koji plugin and from git tags when running outside of the buildsystem.
Using the build history of the package (ie a list of NEVRs) as well as
the information provided by the packager in the spec file, rpmautospec
then computes the next best release number for the package.
Once defined, it prepends a suitably defined %autorel macro to the top
of the spec file, freezing the computed value of the release number
and thus allowing reproducible builds of the SRPM.
The [https://docs.pagure.org/fedora-infra.rpmautospec/autorel.html
documentation of the autorel macro] describes how packagers can use it
to provide extra information.
=== The %autochangelog macro ===
The %autochangelog macro is in fact more a placeholder that
rpmautospec fills in during the creation of the SRPM (or when ran
manually on a project).
rpmautospec uses two sources of information to automatically generate
the changelog:
* an optional `changelog` file that packagers can add to the repository
* the git history of the spec file
rpmautospec will include the `changelog` as is in the `%changelog`
section and will use all the commits made to the repository after the
last change of the `changelog` file to generate the changelog.
In other words, if the packager has a repository created on January
10th and works on it for 6 months, adds a `changelog` file on June
1st. All the commits made before that commit of June 1st will be
ignored in favor of the content of the `changelog` file.
Similarly, if the packager then edits the file on July 1st, all the
commits prior to that commit of July 1st will be ignored.
All the commits involving files ending with either ".spec" or ".patch"
(this list can be expended if desired) and made after July 1st will be
used to generate the changelog.
== Benefit to Fedora ==
In short: easier packaging in Fedora for the packagers who opt-in.
The `Release` and `%changelog` fields are the two most conflicting
fields in RPM spec files. They impact most pull requests if they
involve updating the package or if the package is updated/rebuilt
while pull-request are being reviewed.
We currently have three different change logs per package and while
they target different audiences (package maintainer: git, sysadmin:
%changelog and end-user: bodhi notes) they overlap a lot and in most
cases are redundant. With this proposal, package maintainers will only
have to cope with two changelogs: git and bodhi notes.
== Scope ==
* Proposal owners:
** Finish the work on the %autorel macro to support some of the use
cases not implemented currently
** Adjust the packaging so rpmautospec does not live in a specific,
versionized python environment (and thus could be use to bootstrap
python)
** Adjust rpmdev-bumpspec (used by releng for mass-rebuilds) so it
ignores spec files using %autorel/%autochangelog
** Adjust the mass-rebuild script so it only adds a suitable git
commit log message for spec files using %autorel/%autochangelog
** Adjust fedpkg to skip the NEVR check when using rpmautospec
** Add dependency on rpmautospec on redhat-rpm-config
* Other developers:
** Opt-in for those who want to use it
** Test changes in staging
** Provide feedback
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: Packaging guidelines should be adjust to
explain how rpmautospec works and can be used. Documentation at:
https://docs.pagure.org/fedora-infra.rpmautospec/ should provide a
good basis for this
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
Not applicable
== How To Test ==
In staging:
* Use `stg-koji` instead of `koji`
* Use `fedpkg-stage` instead of `fedpkg` (``dnf install fedpkg-stage``)
* Run `kinit <accountname>@STG.FEDORAPROJECT.ORG`
* Test with rawhide as rpmautospec is only available there in staging
at this point
* Install `rpmautospec-rpm-macros` to build packages locally.
* Edit the spec file to use either macro (or both)
* (Optional) Run `rpmautospec` on the git repository of your choice to
see what it does (you may have to run `rpmautospec tag-package` the
first time you run it).
* Build the package
* Check its release or changelog according to the macro set
In production:
* Edit the spec file to use either macro (or both)
* (Optional) Run `rpmautospec` on the git repository of your choice to
see what it does (you may have to run `rpmautospec tag-package` the
first time you run it).
* Build the package
* Check its release or changelog according to the macro set
Issues can be reported at: https://pagure.io/fedora-infra/rpmautospec/issues
Note that using this approach has some peculiarities, we've documented
the ones we've encountered at:
https://docs.pagure.org/fedora-infra.rpmautospec/peculiarities.html
== User Experience ==
Packagers not opting-in should not be affected in any way by this change.
Packagers opting-in should be able to stop worrying (or worry much
less) about the content of the Release/%changelog fields in their spec
file.
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism: rpmautospec is not deployed in koji
* Contingency deadline: N/A (this isn't tied to a Fedora release)
* Blocks release? No
== Documentation ==
All the upstream documentations can be
https://docs.pagure.org/fedora-infra.rpmautospec/
== Release Notes ==
N/A, this change will not affect end-users (except maybe for some
changes in the content of the rpm changelog).
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
Greetings.
We have enabled the koji 'save-failed-tree' plugin in
koji.fedoraproject.org. This plugin allows you to tell koji to bundle up
a failed official builds chroot (either partly or fully) and download it
to investigate it locally.
This plugin should only be used for the case where you cannot determine
the cause of a build failure by any other means and need to examine
specific files in the chroot to do so.
A few things to note:
* This will only work on failed official builds that have failed
recently enough to still have their chroot on the builder where they
failed (default: 1 day) Not scratch builds. Not canceled builds.
The chroot downloads are REALLY LARGE. Please use this sparingly.
* This will only work on buildArch tasks, not images, etc
* Saved tree .tar.gz's are deleted from koji after 14 days.
* You need to have python3-koji-cli-plugins subpackage installed to use
the command.
* You run the command as: koji save-failed-tree <failed-taskid>
I hope that this will be of use to help maintainers track down hard to
isolate bugs when all other means fail.
kevin
https://fedoraproject.org/wiki/Changes/Autoconf_271
== Summary ==
Autoconf upgrade from version 2.69 to the last upstream version 2.71 in Fedora.
== Owner ==
* Name: [[User:odubaj| Ondrej Dubaj]]
* Email: odubaj(a)redhat.com
== Detailed Description ==
Upgrading autoconf from version 2.69 to version 2.71 according to new
upstream release. Version 2.70 is skipped due to multiple ABI
incompatibilities, where some of them were fixed in version 2.71.
Years of development differ these two releases, so problems are
expected.
This change might easily cause fails during builds of multiple
packages, as some of them still require autoconf-2.69. This step must
be properly discussed with maintainers of dependent packages, which
should forward this change proposal to their upstream projects.
== Benefit to Fedora ==
Brings a stable and up-to-date version of autoconf according to
upsteam release. It is expected, that in the future many upstream
development teams will use autoconf-2.71 as their default builder, so
Fedora will be prepared for such a step.
== Scope ==
* Proposal owners:
**Prepare autoconf-2.71 as RPM package for Fedora Rawhide
**Check software that requires `autoconf` or `autoconf-2.69` and
rebuild it with autoconf-2.71
**Build autoconf-2.71 to Rawhide in a side-tag
(https://fedoraproject.org/wiki/Package_update_HOWTO#Creating_a_side-tag)
**Rebuild depended packages with autoconf-2.71 in the side-tag
**Merge the side-tag to Rawhide
* Other developers:
**Check if their packages can be build with autoconf-2.71
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* 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 ==
Problems during build can appear in multiple packages what can lead to
build failure, as multiple packages require autoconf-2.69 as their
upstream dependency. These problems have to be resolved before adding
autoconf-2.71 into Fedora. It seems aprox. 20% of dependent packages
are having problems during build, which could be caused by a problem
with same pattern.
== How To Test ==
Rebuilding your packages with autoconf-2.71 dependency in copr
(https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/)
Mass rebuild of dependent packages in a side tag.
== User Experience ==
Users will be able to use the newer version (2.71) of autoconf, and
building packages with autoconf-2.69 won't be available, as it won't
be present on the specific fedora version. This can affect 3rd partly
packages, which are not part of Fedora.
== Dependencies ==
Hundreds of packages have build dependency on autoconf, therefore it
is a huge step forward for Fedora, what should be properly discussed
and tested. List of dependent packages with their ability to be built
with autoconf-2.71 can be found in the given copr project
(https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/packages/)
We should also look at dependent packages of `libtool` and `automake`
(other critical autotools packages), as there might be some
incompatibilities with the new autoconf version.
== Contingency Plan ==
* Contingency mechanism: moving this change to Fedora 36, if not
successfully finished until Fedora 35 branching from Rawhide
* Contingency deadline: Fedora 35 branching from Rawhide (2021-08-10)
* Blocks release? No
== Documentation ==
Latest autoconf documentation:
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/in…
== Release Notes ==
Release notes for autoconf-2.70:
https://lists.gnu.org/archive/html/autotools-announce/2020-12/msg00001.html
Release notes for autoconf-2.71:
https://lists.gnu.org/archive/html/autotools-announce/2021-01/msg00000.html
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
In accordance with the new FESCo policy[1] the following
provenpackagers will be submitted for removal in two weeks based on a
lack of builds submitted in the last six months. If you received this
directly, you can reply off-list to indicate you believe you should
still have provenpackager status.
This is the first time we have done a regular audit of the
provenpackagers group, so please be patient with any hiccups in the
process. This will be done regularly at the branch point in each
release.
[1] https://pagure.io/fesco/issue/2549
Checked 252 provenpackagers
The following 117 provenpackagers have not submitted a Koji build
since at least 2020-08-05 00:00:00:
alexl
alexlan
arg
athimm
atkac
ausil
averi
awjb
bernie
bkabrda
bpepple
c4chris
caillon
cebbert
chitlesh
codeblock
cweyl
cwickert
davej
dbhole
dcbw
denis
dgregor
dmalcolm
drago01
dsd
dwmw2
echevemaster
ecik
ensc
epienbro
fitzsim
gemi
hguemar
hubbitus
huzaifas
ianweller
iarnell
ilianaw
ishcherb
ivazquez
ixs
jcapik
jhogarth
jkeating
johnp
jpo
jreznik
jspaleta
jstanley
jsteffan
jwilson
kanarip
kasal
katzj
kay
ke4qqq
kengert
kyle
kylev
laxathom
lennart
lkundrak
lmacken
lutter
markmc
maxamillion
mbarnes
mclasen
mef
michich
mjakubicek
mjg59
mmahut
mmaslano
mmcgrath
msimacek
mstuchli
nalin
nim
npmccallum
overholt
paragn
patches
pertusus
pjp
praveenp
pravins
rakesh
rkuska
rvokal
s4504kr
scop
sdake
sdz
skvidal
smooge
sochotni
stahnma
steve
sundaram
thias
thomasvs
thozza
till
tomspur
toshio
tradej
tremble
tstclair
tuxbrewr
vakwetu
vicodan
wart
willb
wolfy
wtogami
The following 1 provenpackagers do not exist in Koji:
gdk
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
Hello All,
Fedora 34 will be branched from rawhide on Feb 09th 2021 as per the
Fedora 34 schedule[1]. The process takes about a day and everything
should be ready by Feb 10th 2021. You can still be able to build
packages normally until then, but after the mass branching, rawhide
and F34 will be separated.
We will send another email once the branching is done.
Thanks,
Mohan Boddu.
[1] https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html