I've just spotted these when working on Python 3.8.0a1. This happens on 3.7 as
well since GCC 9:
python3-debug.x86_64: E: library-not-linked-against-libc
python3-debug.x86_64: E: library-not-linked-against-libc
python3-libs.x86_64: E: library-not-linked-against-libc
python3-test.x86_64: E: library-not-linked-against-libc
(Note that there are plenty of other extension modules that do not raise this
This doesn't happen with latest python3 built prior to the gcc update to 9.
$ rpmlint -I library-not-linked-against-libc
That isn't helpful either.
I found a similar Debian thing  that says:
> It is theoretically possible to have a library which doesn't use any symbols
> from libc...
Do I care? Should I fix something? I honestly have no idea.
Hey. pep8 is no longer released upstream and its successor is called pycodestyle.
I plan to retire python-pep8, as tracked in , however there are still too
many consumers of python3-pep8. On the other hand, python2-pep8 is only
cachedir - already FTBFS, not dependent upon
genbackupdata - already FTBFS, fails to install, not dependent upon
ovirt-guest-agent - already FTBFS, not dependent upon outside of subpackages
pylast - python2-pylast is not dependent upon
python-cliapp - python2-cliapp is required by:
cmdtest - FTBFS, fails to install, required by:
python-larch - FTBFS, not dependent upon outside of subpackages
Maintainers by package:
ovirt-guest-agent evilissimo nyoxi
Packages by maintainer:
salimma cmdtest genbackupdata python-cliapp python-larch
Would you like to take python2-pep8? I'd advice against, please update to Python
3 and/or pycodestyle instead.
This is my attempt to follow .
[This proposal was submitted after the deadline. I am announcing it
for community discussion and will leave the decision on whether or not
to grant an exception to FESCo]
== Summary ==
Switch GCC in Fedora 30 to 9.x.y, rebuild all packages with it, or
optionally rebuild just some packages with it and rebuild all packages
only in Fedora 31.
== Owner ==
* Name: [[User:jakub| Jakub Jelínek]]
* Email: jakub(a)redhat.com
== Detailed Description ==
GCC 9 is currently in stage4 since January 7th, in prerelease state
with only regression bugfixes and documentation fixes allowed. The
release will happen probably in the middle of April.
rpms have been built are since today in rawhide.
== Benefit to Fedora ==
See http://gcc.gnu.org/gcc-9/changes.html for the list of changes.
== Scope ==
All packages should be rebuilt with the new gcc once it hits f30, or,
if there is not enough time for that, just all packages built after
the new gcc hits the buildroots.
* Proposal owners:
Build gcc in f30, rebuild packages that have direct dependencies on
exact gcc version (libtool, annobin, gcc-python-plugin).
* Other developers: First few days/weeks just voluntary rebuilds using
the new system gcc, if things fail, look at
http://gcc.gnu.org/gcc-9/porting_to.html and fix bugs in packages or,
if there is a gcc bug or suspected gcc bug, analyze and report.
* Release engineering: . Mass rebuild requested for F30.
* Policies and guidelines: No policies need to be changed
== Upgrade/compatibility impact ==
== How To Test ==
GCC has its own testsuite, which is run during the package build, plus
many other packages with automated tests also help to test the new
== User Experience ==
Users will be able to see compiled code improvements and use the newly
Developers will notice a newer compiler, and might need to adjust
their codebases acording to http://gcc.gnu.org/gcc-9/porting_to.html,
or, if they detect a GCC bug, report it.
== Dependencies ==
libtool, annobin, gcc-python-plugin depend on exact gcc version, those
need to be rebuilt.
== Contingency Plan ==
If bugs are discovered, I'd appreciate help from the package owners in
preparing self-contained testcases to speed up analysis and fixing the
bugs. Don't have time to debug issues in
12000+ packages, especially when in many cases it could be caused by
undefined code in the packages etc. I don't expect we'll have to fall
back to the older gcc, we've never had to do it in the past,
but worst case we can mass rebuild everything with older gcc again.
Jeff Law has performed test mass rebuild on x86_64.
* Contingency mechanism: Revert to older gcc, mass rebuild everything again
* Contingency deadline: Before release
* Blocks release? Yes
* Blocks product? No
== Documentation ==
== Release Notes ==
Fedora 30 comes with GCC 9.1 as primary compiler, see
http://gcc.gnu.org/gcc-9/changes.html for user visible changes in it.
Fedora Program Manager
Only one package (fawkes-devenv) requires python2-defusedxml.
It already has broken dependencies on mogodb-server and the source package
(fawkes) doesn't build.
fawkes-devenv is not required by any other package.
If you wish to maintain python2-defusedxml, let me know.
fawkes is maintained by:
timn - Tim Niemueller
thofmann - Till Hofmann
rmattes - Rich Mattes
This is my attempt to follow:
Currently Fedora mailing lists use "From" field from original messages
and if sender's domain use DMARC=reject policy, mailing lists
subscribers cannot receive any messages from such users because their MX
servers follow DMARC procedure and drop them.
Previously I opened ticket in Fedora Infra.
Someone need to fix this because more and more mailing servers starts
Vitaly Zaitsev (vitaly(a)easycoding.org)
I need to install a directory (/afs) that will be a mountpoint that a systemd
service (also installed in the rpm) will mount upon.
What's the best way to encode this in the specfile?
I did have:
but that doesn't upgrade correctly. Someone gave me another way to do it:
# Create /afs directory if it doesn't exist
if [ ! -d /afs ]; then
chown root.root /afs
chmod 0755 /afs
[ -x /usr/sbin/restorecon ] && /usr/sbin/restorecon /afs
%ghost %dir /afs
but rpmlint complains about the chown:
kafs-client.x86_64: W: dangerous-command-in-%post chown
The git repo is here:
The second patch from the top is the one that tries to fix the mountpoint dir
installation issue ("spec: Treat /afs special").
currently, we autogenerate a dependency on pkg-config for all rpms
that ship a .pc file. "dnf repoquery --whatrequires /usr/bin/pkg-config"
returns 4632 entries on my laptop.
This has always felt backward to me: those packages *provide* something
that is used by pkg-config, they don't *require* pkg-config for anything.
As an analogy, packages with headers are read by a C compiler, but
we don't make them require gcc, and if a package ships an .so file, we
don't add a dependency on the linker to it. Instead, anything which wants
to consume .pc files should simply depend on the tools that consume those
files (pkg-config, pkgconf, or a custom re-implementation).
Proposal: let's drop the autogenerated dependency on /usr/bin/pkg-config
(this would require a trivial change in /usr/lib/rpm/pkgconfigdeps.sh).
Note: autogenerated Provides/Requires like pkgconfig(foo) are not
part of this proposal.
- less entries in the dependency graph
- removal of illogical dependency
- less packages installed (pkgconf, pkgconf-m4, pkgconf-pkg-config, libpkgconf)
(Those packages are small, maybe 200k together so this isn't a strong
- stuff that uses pkg-config or pkgconf will need to grow a dependency
(e.g. meson which invokes /usr/bin/pkg-config internally).
so there will be some churn.