As per Changes/Remove GCC from BuildRoot
going to automatically add BuildRequires: gcc and/or BuildRequires: gcc-c++
to packages which fail to build with common messages (like gcc: command not
found, also autotools/cmake/meson are supported).
I'm going to do this tomorrow.
After which, I'm going to ask rel-eng to finally remove it from buildroot.
This will happen before mass rebuild. Stay tuned.
I've just got 20 bugs auto-filed against packages which I co-maintain
and that is just for packages starting with the letter 'a'.
A quick check shows that these are all caused by a missing
BuildRequires on gcc / g++ related to:
I'm not sure if this means that the FTBFS script has been run before
all the automatic fixing which was planned for this was in place;
or if this means that the automatic fixing missed many many
packages, but either way something needs to happen here, the amount
of work now being pushed onto packagers caused by:
Is unacceptable IMHO.
If the FTBFS script has ran too early, all the FTBFS bugs need to be
closed and the FTBFS script has to be run again later.
If the automatic BuildRequires fixing script missed all these, then
I suggest that:
Gets reverted for now and we again close all the FTBFS bugs and
rerun the script for them after doing a fresh build with the
buildroot restored as it was.
as some of you might have recognized, Fedora's LXQt is quite outdated
(we have 0.11, current one for some weeks now is 0.13) and also needs
some rework with respect to theming and the package set (upstream
restructured packaging a bit with respect to common files). When I
joined the Fedora LXQt effort, my job was the creation of the spin while
other maintainers took care of most packages. Unfortunately the core
packager left Fedora. I did the whole update once, but at that time it
was mostly just about bumping the version and rediffing the patches.
Also I had much more free time at that point.
As I recognized that I also really need more time for work on my PhD
stuff, I decided to resign from work on Fedora LXQt. Of course I will
continue my work on Fedora's scientific packages including the Astronomy
Lab, which is closely linked with my PhD stuff. Also my other
contributions like acting as an ambassador will continue as before, so
it is "just" about LXQt.
If you're interested in picking Fedora LXQt up, let me know. Then I'll
also give initial assistance of course. I already started some work on
the update some weeks ago in copr
https://pagure.io/lxqt-testing-copr This is missing the rework on themes
etc., and I did not check all of the older patches. My intention of that
move now is, that there should be still enough time for new maintainers
to get everything up to date again for Fedora 29. Or (hopefully not :( )
to remove it if necessary.
A mostly "behind the scenes" aspect of the Linux wireless LAN
(IEEE802.11) subsystem has changed upstream with some system-level
effects. Replacing an existing package with a cleaner but functionally
equivalent package is an attractive option, but there are questions
regarding the update path, how signing the the regulatory database
should be handled, and how to communicate these changes outward to the
Usage of Radio Frequency (RF) spectrum is generally regulated around
the world. Even unlicensed use of RF spectrum (as with wireless LANs)
is still subject to some level of local regulation. In order to support
lawful use of wireless LAN technology with Linux around the world, the
Linux kernel uses an externally maintained wireless regulatory database
that encodes relevant information about known regulatory (i.e.
legal/governmental) domains. The kernel makes use of this information
in order to enforce wireless regulations for devices under its control,
although some devices further apply their own limitations at the driver
or firmware level as well.
For a long time, the Linux kernel relied on a piece of software known
as the Central Regulatory Domain Agent (CRDA) to feed the kernel with
regulatory information in response to UDEV events that indicate what
regulatory domain's rules are to be enforced. Also, within Fedora, the
setregdomain script runs when a wireless netdev is instantiated. By
default this script attempts to relate a system’s TZ (i.e. Time Zone)
setting to a corresponding country code, which is then used to set the
wireless regulatory domain. The setregdomain script can also use
alternate means to determine which regulatory domain to request, as
detailed in the setregdomain.1 man page.
CRDA is maintained upstream in the crda git repository. The wireless
regulatory database is maintained upstream in the wireless-regdb git
repository. In Fedora, snapshots of both of the above repositories are
built within the single crda RPM. This is done to enable build-time
generation of a key used to sign the wireless-regdb database which is
then embedded in the concurrently built crda binary in order to
validate the integrity of the database at runtime.
As of about the upstream 4.15 version of Linux, the kernel's wireless
developers had determined that future updates to the wireless
regulatory database may require format changes that would be
incompatible with the existing CRDA implementation. Further, Linux
kernel changes over the years now enabled the kernel to load firmware
images without requiring a userland helper like CRDA. So, the Linux
kernel wireless developers implemented an in-kernel replacement for
CRDA. This includes code to validate the wireless regulatory database
against a signature that is built into the kernel itself.
At present, Fedora kernels are configured to use the in-kernel wireless
regulatory database loader. If the database is not found or is not
signed with the key built into the kernel, then boot time messages
appear, creating the appearance of a problem. For now, there is no
actual problem. Fedora systems continue to ship with CRDA, which
continues to perform its original duties with no effective problem as
of yet. The harmless "error" messages during boot are the only symptom.
(NOTE: the latest Fedora CRDA package works around this issue,
eliminating the spurious "error" messages at boot time.)
For now, there is no emergency. We could continue to ship CRDA as-is.
My concern is that eventually, CRDA may no longer be a viable option
for future regulatory database updates. In that case, it would seem to
be better to change now than to do so in a rush later.
Also, replacing the combined CRDA/wireless-regdb "crda" package with a
new "wireless-regdb" package removes a wart from our package collection
and replaces it with a package that is simpler and easier to understand
how it is built. That will be one less "why did they do that?" item
hanging around in Fedora.
ACTION IN PROGRESS
I have created a wireless-regdb package for Fedora. It simply installs
the wireless regulatory database binary into /usr/lib/firmware,
alongside it's pre-existing detached signature. This package includes a
version of the setregdomain script that is virtually identical to what
is in the existing crda package. This package has been approved for
Fedora, but I recently imported the SRPM to the Fedora repository. (htt
I have been testing with the above package for a couple of weeks, and
the user experience is identical to using the crda solution. Given this
success, I believe that the best option will be to push this package
with Obsoletes and Provides for crda. This will facilitate a painless
and nearly silent upgrade for existing Fedora users. I will follow-up
with retiring the crda package itself a bit later. Other required
actions will include replacing any packaging references to the crda
package with an equivalent wireless-regdb reference (or simply
eliminating such a reference) and making the requisite changes to
comps.xml or any future equivalent.
Are there reasons to oppose the Obsolete/Provides upgrade path from
crda to wireless-regdb? Would it be desirable to require users to
manually intervene by installing wireless-regdb by hand? FWIW, I do not
see any benefit from requiring any manual steps.
Is it acceptable to trust the upstream signature of the wireless
regulatory database? Or do we need to use some sort of Fedora
signature? If the latter, can it be a (semi-)permanent (e.g. per
release) signature, which could be maintained in the kernel sources? Or
must it be a per build signature? How can that be accommodated, other
than through another combined package? (My personal preference is to
simply trust the upstream signature that is already being built into
Does the crda to wireless-regdb upgrade effort need a Feature page (or
similar) in Fedora?
Since crda is a "critical path" component, what special considerations
need to be accommodated in order to replace it with wireless-regdb?
John W. Linville “The worst pain...to have insight into much
linville(a)redhat.com and power over nothing.” ― Herodotus
The elfutils tools can demangle C++ symbols through the standard
_cxa_demangle interface. The elfutils tools are written in C and
so simply link with -lstdc++ to get access to __cxa_demangle.
There is a BuildRequires: libstdc++-devel in the elfutils.spec.
But it looks like that isn't enough anymore to pull in libstdc++.so
to build against.
It looks like that is provided through a symlink in gcc-c++.
Should the elfutils.spec just BuildRequires: gcc-c++ instead of
libstdc++-devel? Or is this a packaging/requires issue somewhere
I am occasionally experiencing the following error in my day-to-day dnf use:
Failed to synchronize cache for repo 'fedora'
Failed to synchronize cache for repo 'updates'
I've had that happened even in local mock builds.
Do you also experience this error upon dnf operations like `dnf install` or
`dnf refresh` or in local mock builds?