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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 months
[ELN] Rebuild ordering and side-tag support
by Stephen Gallagher
Summary: I think we can fix the ELN side-tag rebuild problems and make
the composes more reliable if we change the mechanism for kicking off
rebuilds. I'm soliciting feedback to help identify potential issues
with this proposed approach.
## Background Information ##
Currently in ELN, merging a side-tag into Rawhide results in all of
the packages from that side-tag being rebuilt concurrently in ELN.
This leads to two problems:
1. Side-tags containing large numbers of package builds will trigger
many ELN builds at the same time, possibly overwhelming available
resources on the ELN automation systems.
2. Many (most?) side-tags exist to ensure that packages are built in
a particular order so as to ensure that they are built after their
dependencies. Launching all the rebuilds concurrently means that many
of the builds may succeed *and still be wrong* (such as if they are
built against an older soname).
## Proposed Solution ##
I had a discussion with Miro Hrončok this morning where we tackled
this problem and may have come up with a workable solution for 99% of
cases. Instead of treating side-tags as a special event and trying to
sort the builds such that they are built in the same order, we can
instead tag in the Rawhide packages first, then issue the rebuilds
together. With the Rawhide packages available, we won't need to worry
about the ordering, because the dependencies will already be present
in a sufficiently-recent version. As a bonus, we'll reduce the
likelihood of broken ELN composes, since if an ELN rebuild fails, the
Rawhide version will still be present to satisfy dependencies.
In greater detail:
Whenever a build is tagged into the 'f35' tag (later, whatever tag
matches Rawhide), ELN automation would take the following steps:
* Identify whether this package is on the list of packages that ELN rebuilds[1]
* Tag the Rawhide build into the 'eln' tag (so it is now tagged with
both 'f35' and 'eln')
* Enqueue a Koji build against the 'eln' target from the same Git commit
The queue mentioned above should be maintained in a separate thread
and used to submit tasks in batches to avoid overloading the
infrastructure. If the Koji build against the 'eln' target fails, the
Rawhide build will remain as the most-recently-tagged version of the
package in ELN and become part of the compose until the ELN rebuild
can be fixed.
Note that this process would apply to ALL builds in Rawhide, not just
those coming from side-tags. There would be no difference in behavior
between standard direct builds and side-tag merged builds.
## Known potential issues ##
* Some packages may auto-detect functionality based on functionality
made available by one of their dependencies. If the Rawhide and ELN
versions of that dependency differ in visible functionality, then
building an ELN package with a Rawhide version of its dependency could
result in unexpected behavior. I believe this issue to be rare and
generally best handled by the packager as the subject matter expert.
They'd just need to bump the release number and rebuild the package in
ELN. Alternatively, if this is known to be regularly problematic for a
package, the maintainer can opt out of the automatic rebuild and work
out a strategy with the ELN SIG for dealing with it.
[1] This will be the set of packages provided by
https://tiny.distro.builders/view--view-eln.html minus any packages
that have opted out of automatic rebuilds (they perform manual
rebuilds for ELN).
2 years, 9 months
