Fedora Source-git SIG report #1 (June 2021)
by Tomas Tomecek
Greetings from the Fedora source-git SIG! We are planning to start
publishing reports of what we are working on so everyone can easily
pay attention and get involved if interested. If you have any ideas,
comments or requests, don’t be shy and let us know :)
Here’s a short list of things which we are working on.
## Choosing git forge to host source-git repositories
We need to find a home for all the source-git repositories. This is
actually a really hard task because we have many options (github.com,
gitlab.com, pagure.io, src.fedoraproject.org, something custom or
on-premise) and different expectations: some projects already have
repos set up on different platforms while Pagure is the primary forge
now. Since the CPE team is investigating GitLab as a forge, it's even
harder for us to figure out the primary forge. We may end up
supporting both actually: pagure.io and gitlab.com. What are your
thoughts on this topic? Would you prefer pagure.io or gitlab.com
More info:
* https://pagure.io/fedora-source-git/sig/issue/1
* https://pagure.io/fedora-source-git/sig/issue/7
## High-level workflow proposal up for review
Hunor proposed a high-level workflow linked below and I strongly
recommend reading it. We have also started discussing many details in
the process, such as getting archives: should we generate one from the
source-git repo or use the official release archive from upstream?
Another big topic in terms of workflows are rebases (= updates to the
latest upstream release, which are very common in Rawhide). Rebases
are straightforward in dist-git, but when your source-git repo has
complete upstream git history, they are no longer trivial, especially
if one wants to get a review of a rebase.
More info:
* https://pagure.io/fedora-source-git/sig/issue/2
* Workflow proposal: https://pagure.io/fedora-source-git/docs/pull-request/2
* https://pagure.io/fedora-source-git/docs/blob/main/f/resources/CommitRule...
* https://pagure.io/fedora-source-git/sig/issue/8
## Tooling
Packit is the tooling which will be used to work with source-git
repos. No surprise there I assume :D
* https://packit.dev/
We've done a lot of work here lately, mainly to polish the process of
creating source-git repos and doing updates of dist-git repositories
based on the source-git content.
* https://packit.dev/docs/source-git/work-with-source-git/
* https://github.com/packit/packit/releases
## Interested?
We meet biweekly on Wednesdays via gmeet, 2:30 - 3:30 UTC, next one is
scheduled for July 7th.
* https://calendar.fedoraproject.org/SIGs/2021/7/5/#m9982
Everyone is welcome to join the SIG or provide any feedback on the
issues and PRs above.
You can always find the latest information over here:
* https://fedoraproject.org/wiki/SIGs/Source-git
* https://pagure.io/fedora-source-git/sig/issues
I'd like to thank all the SIG members for being so active, so happy to
work with all of you!
Cheers,
Tomas
2 years, 11 months
Updating sources file using fedpkg
by Ewoud Kohl van Wijngaarden
Hello everyone,
As someone who just got started, I'm looking for some help.
I'd like to update packages. I'm used to git, so my typical flow is to
make sure I have some clean branch to start working from (clone is just
for completeness):
fedpkg clone mypackage
cd mypackage
git checkout -b rawhide-update-to-new-version
rpmdev-bumpspec -n 1.2.3 mypackage.spec
Now comes the part I'm not sure about. To fetch the new sources I
usually perform:
spectool -g mypackage.spec
After that, I'm looking for a command to update the sources file with
new checksums so I can run:
fedpkg --release f35 mockbuild
I could not find such a command so until now I've been using sha512sum
manually, but there must be a better way :)
Regards,
Ewoud Kohl van Wijngaarden
2 years, 11 months
Additon to the repos - Kubectx + Kubens
by Justin Lamp
Hey there,
I hope I am at the right place: I want to request a new package to be added to the fedora repos.
I'd like kubectx kubens to be added. They are really nice Kubernetes tools to change the cluster or the namespace respectively.
The source can be found under kubectx.dev.
Thank you!
2 years, 11 months
F35 Change: Node.js 16.x by default (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Nodejs16
== Summary ==
The latest release of Node.js to carry a 30-month lifecycle is the
16.x series. As with 14.x, 12.x, 10.x and 8.x before it, Fedora 35
will carry 16.x as the default Node.js interpreter for the system. The
14.x and 12.x interpreters will remain available as non-default module
streams.
== Owner ==
* Name: [[User:zvetlik| Zuzana Svetlikova]]
* Email: zsvetlik(a)redhat.com
* Name: [[User:Sgallagh| Stephen Gallagher]]
* Email: sgallagh(a)fedoraproject.org
* Responsible SIG: Node.js SIG
== Detailed Description ==
Fedora 35 will ship with the latest LTS version of Node.js. '''dnf
install nodejs''' will give users nodejs-16.x and the matching npm
package.
== Benefit to Fedora ==
Node.js is a popular server-side JavaScript engine. Keeping Fedora on
the latest release allows us to continue tracking the state-of-the-art
in that space. For those whose applications do not yet work with the
16.x release, Fedora 35 will also have the 14.x and 12.x releases
available as selectable module streams.
== Scope ==
* Proposal owners: The packages are already built for Fedora 33, 34
and 35 in a non-default module stream. On June 14th, 2021, the
nodejs-16.x packages will be built in the non-modular repository and
thus become the default in Fedora 35.
* Other developers: Any developer with a package that depends on
Node.js at run-time or build-time should test with the 16.x module
stream enabled as soon as possible. Issues should be reported to
nodejs(a)lists.fedoraproject.org
* Release engineering: We will coordinate with the Node.js SIG to
create a side-tag to perform the rebuilds before making 16.x the
default.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
As with previous releases, users running Fedora 33 or Fedora 34 with
the non-modular nodejs-14.x packages will be automatically upgraded to
the 16.x packages when they upgrade to Fedora 35, which may cause
issues. If users are running software known not to support Node.js
16.x yet, they can switch the system to use 14.x with '''dnf module'''
commands.
== How To Test ==
* Confirm that `dnf install nodejs` results in Node.js 16.x being installed.
* Confirm that upgrading from Fedora 33 or Fedora 34 with nodejs-14.x
installed (non-modular) results in an upgrade to nodejs-16.x
* Confirm that upgrading from Fedora 33 or Fedora 34 with the
`nodejs:14` module enabled does *not* result in an upgrade to 16.x and
still has `nodejs:14` enabled on Fedora 35.
* Confirm that upgrading from Fedora 33 or Fedora 34 with the
`nodejs:16` module enabled upgrades successfully and still has
`nodejs:16` enabled on Fedora 33.
== User Experience ==
Users will have the 16.x release of Node.js available by default. See
the "Upgrade/compatibility impact" section for specific details.
== Dependencies ==
All packages prefixed with `nodejs-` depend on this package. If they
do not work with Node.js 16.x, they will need to be updated, made
modular and dependent upon the `nodejs:14` stream or else removed from
Fedora 35.
Prior to the switchover date to Node.js 16.x as the default, packagers
are strongly encouraged to test their existing Node modules with 16.x
via the Modular version by running:
<pre>
dnf module reset nodejs
dnf module install nodejs:16/development
</pre>
Packagers can also test their builds using `mock` by creating the file
`/etc/mock/fedora-rawhide-x86_64-nodejs16.cfg` with the following
contents:
<pre>
config_opts['target_arch'] = 'x86_64'
config_opts['legal_host_arches'] = ('x86_64',)
config_opts['enable_disable_repos'] = ['--enablerepo', 'rawhide-modular']
config_opts['module_install'] = ['nodejs:16/development']
include('templates/fedora-rawhide.tpl')
</pre>
Then call
<pre>
mock -r fedora-rawhide-x86_64-nodejs16 --enablerepo=rawhide-modular nodejs-foo
</pre>
(Note that the `--enablerepo=rawhide-modular` portion looks redundant,
but this is because of
[https://github.com/rpm-software-management/mock/issues/591 a mock
bug])
== Contingency Plan ==
* Contingency mechanism:
Revert to Node.js 14.x as the default Node.js interpreter. This will
require bumping epoch.
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
* https://nodejs.org/dist/latest-v16.x/docs/api/
* https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V16.md
== Release Notes ==
Fedora 35 now ships with Node.js 16.x as the default Node.js
JavaScript server-side engine. If your applications are not yet ready
for this newer version, you can revert to the 14.x series by running
the following commands
<pre>
dnf remove nodejs
dnf module reset nodejs
dnf module install nodejs:14
</pre>
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 11 months
use unit names in systemd output by default?
by Zbigniew Jędrzejewski-Szmek
Hi,
systemd has systemd.status_unit_format= / [Manager].StatusUnitFormat=
/ -Dstatus-unit-format-default= option to use unit names instead of the
Description in messages on the kernel console and in logs:
- Jun 20 22:04:48 krowka systemd[1]: Started Rule-based Manager for Device Events and Files.
+ Jun 20 22:04:48 krowka systemd[1]: Started systemd-udevd.service.
I find this more convenient because it's briefer, so it fits better on
a terminal, but primarily because I can select&paste the unit name for
further lookup. When Description is used, and I'm not familiar with
the unit, I'll often use grep first to figure out what the unit name
actually is. Finally, unit Descriptions are often not very good, and
the name is at least as informative…
Would people be opposed to making this the default (setting
-Dstatus-unit-format-default=name in build options)? People who like
the old default could set StatusUnitFormat=description in systemd.conf
Zbyszek
2 years, 11 months
Attempt to contact "Standard Test Interface" project collaborators
by Michal Schorm
Hello,
I tried to contact the people behind "Standard Test interface" CI.
I sent the e-mail about 3 weeks ago.
Then after about 2 weeks (= ~1 week ago) I reacted to the same email
so it would appear in their inboxes again.
Yet no response came, so i'm trying here.
---------- Original message ---------
From: Michal Schorm <mschorm(a)redhat.com>
Date: Wed, Jun 9, 2021 at 9:42 PM
Subject: Fedora - Standard Test Interface - not enough verbose output
To: <stefw(a)fedoraproject.org>, <pingou(a)fedoraproject.org>,
<sturivny(a)fedoraproject.org>
Hello,
I have a package: 'mariadb-connector-odbc'.
It has a single STI test in it's dist-git repository, under 'tests' directory.
I've made a PR to the package, attempting (amongst other stuff) to fix the test:
https://src.fedoraproject.org/rpms/mariadb-connector-odbc/pull-request/2#
This is the "Fedora CI - dist-git test", which is passing, but I'm not
satisfied with:
https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/dist-git-pi...
The thing is, that the Jenkins only show me a quiet log:
https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/dist-git-pi...
However I want to see the verbose log by default.
(A log that does not only show commands ran, but their output too)
I've ran the STI test manually, in a VM.
I've uploaded all the resulting artifacts here:
https://mschorm.fedorapeople.org/ARCHIVE/Fedora-PR-Standard_Test_Interfac...
One of the artifacts is what I got in Jenkins:
https://mschorm.fedorapeople.org/ARCHIVE/Fedora-PR-Standard_Test_Interfac...
And this is the one I want to see in jenkins:
https://mschorm.fedorapeople.org/ARCHIVE/Fedora-PR-Standard_Test_Interfac...
Is there a way to get the type of the result I want from STI ?
--
The artifact I want seems to be generated by default, so it shouldn't
be difficult to add it to the Jenkins, right ?
Also, it might be just a configuration issue in my own test.
If I remember correctly, I wrote this test as an early adopter, about
3 year back. (git blame says 2018-05-10) and maybe I just need to
update my 'tests.yaml' somehow ...
--
Btw the Jenkins calls it "Standard Output", but when I ran it
manually, that output was actually an error log:
"PASS-mariadb_connection-err.log"
The actual standard log was the verbose one :)
"PASS-mariadb_connection.log"
--
I've found your contacts here:
https://docs.fedoraproject.org/en-US/ci/standard-test-interface/#_contact
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
2 years, 11 months
List of long term FTBFS packages to be retired in August
by Miro Hrončok
Dear maintainers.
Based on the current fail to build from source policy, the following packages
will be retired from Fedora 35 approximately one week before branching (August
2021).
Policy:
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fai...
The packages in rawhide were not successfully built at least since Fedora 32.
This report is based on dist tags.
Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ft...
If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me
know and we can work together to get a FESCo approval for that.
If you see a package that can be rebuilt, please do so.
Package (co)maintainers Latest build
================================================================================
cardpeek kalev Fedora 32
percona-xtrabackup slaanesh, slankes Fedora 32
php-opencloud-openstack lcts Fedora 32
proxyfuzz psklenar Fedora 32
radamsa huzaifas, mrniranjan Fedora 32
sugar-view-slides callkalpa, chimosky, pbrobinson, Fedora 31
tuxbrewr
zram pbrobinson Fedora 32
The following packages require above mentioned packages:
Depending on: percona-xtrabackup (1), status change: 2020-11-22 (31 weeks ago)
holland (maintained by: immanetize, jeffreyness, survient)
holland-xtrabackup-1.2.4-2.fc35.noarch requires /usr/bin/xtrabackup
Affected (co)maintainers
callkalpa: sugar-view-slides
chimosky: sugar-view-slides
huzaifas: radamsa
immanetize: percona-xtrabackup
jeffreyness: percona-xtrabackup
kalev: cardpeek
lcts: php-opencloud-openstack
mrniranjan: radamsa
pbrobinson: zram, sugar-view-slides
psklenar: proxyfuzz
slaanesh: percona-xtrabackup
slankes: percona-xtrabackup
survient: percona-xtrabackup
tuxbrewr: sugar-view-slides
2 years, 11 months
Bumping lapack to 3.10.0 in rawhide
by Tom Callaway
LAPACK & BLAS are going to 3.10.0 in rawhide. The sover on the shared libs
is still at .3, so it _should_ not break anything, but there is a history
of this not always being true.
Please file bugs if things stop building against LAPACK/BLAS.
Thanks,
~spot
2 years, 11 months
Bringing glibc 2.34 snapshots to Fedora 35 and CentOS Stream 9
by Florian Weimer
TL;DR: glibc 2.34 snapshots are coming. libpthread as a separate library
creates problems, so we are removing it. There may be some
hickups. Full updates with “dnf update” are recommended.
We expect that we will soon be able to import glibc upstream snapshots
regularly into Fedora 35 and CentOS Stream 9. We did such regular
imports for the past couple of Fedora rawhide releases, but the
situation will be slightly different, as explained below. The snapshots
will also land in CentOS Stream 9, after a delay as the result of a
different testing pipeline.
glibc 2.33 and earlier accidentally provided an very generic ROP gadget
in the statically linked startup code that is present in every program
(even dynamically linked ones). We have removed the ROP gadget and
moved that particular initialization code into the dynamically linked
part, but that means that the interface between the startup code and the
dynamically loaded glibc parts had to change. As a result, any program
linked against glibc 2.34 will not run with glibc 2.33 or any earlier
version. (Some of you may remember the memcpy(a)GLIBC_2.14 issue, it was
similar.) This version requirement will be properly reflected in RPM
dependencies.
glibc 2.34 removes libpthread as a separate library. This is based on
the observation that most processes load libpthread anyway. (On this
system, I count 141 out of 159 processes that load libpthread.) One
particularly thorny issue is that certain NSS modules depend on
libpthread, and if the main program is not linked (indirectly) against
libpthread, loading such NSS modules effectively loads libpthread via
dlopen, which is something that glibc has never supported well.
Furthermore, the availability of some pthread_* functions without
-lpthread has been a source of confusion to developers, resulting in
both overlinking and underlinking.
We started the libpthread transition in glibc 2.33 when we added the
__libc_single_threaded variable as a replacement for the weak symbol
hacks that some libraries use to detect single-threaded processes. (For
example, libstdc++ used to do this to avoid using atomic instructions in
std::shared_ptr.) Backwards compatibility for dynamically linked
binaries should be preserved (as usual), but we know of one issue on
ppc64le, where the weak symbol hacks resulted in slightly corrupt
binaries. Upstream glibc did not accept the proposed backwards
compatibility enhancement so far. Instead, we will rebuild affected
distribution binaries with a binutils version which handles weak symbols
slightly differently, avoiding the corruption. As we plan to perform
these rebuilds before the new glibc lands in the buildroot, the
requirement to upgrade to the new binaries before or at the same time of
the upgrade to the glibc upstream snapshot will NOT be reflected in RPM
dependencies. A full upgrade using “dnf update” will work, however.
In addition to the removal of libpthread, I also hope to remove libdl
and librt. This means that new GLIBC_2.34 symbols will be added to
libc.so.6 (e.g., timer_create(a)GLIBC_2.34). The librt removal in
particular will probably not land with the first imported snapshot.
This is unfortunate because RPM does not have a way to express this:
there's just a blanket Provides: libc.so.6(GLIBC_2.34), which will
already be included in the first snapshot that adds the symbol
__lib_start_main@(a)GLIBC_2.34 (whether or not the RPM package includes
timer_create(a)GLIBC_2.34 as well). Some tools in the fedpkg/centpkg/mock
sphere try to install builds from the Koji buildroot into installations
from composes, without upgrading everything to the current buildroot, so
it's possible that glibc won't be upgraded to match the requirements of
RPMs directly imported from the buildroot. Developers encountered
similar issues with glibc snapshot imports (e.g., around the symbol
pthread_getattr_np). Our RPM infrastructure does not have per-symbol
dependencies, so there isn't much we can do about it at the packaging
level. It's a transitory issue during rawhide/CentOS Stream 9
development; the finished release will add all GLIBC_2.34 symbols in one
upgrade, so end users won't see it in a Fedora 34 to Fedora 35 upgrade
or a CentOS Stream 8 to CentOS Stream 9 upgrade.
We think there is value in providing access to these snapshots early,
and will try to make the transitions as smooth as possible, within the
constraints outlined above.
Thanks,
Florian
2 years, 11 months