Self Introduction: Stewart Smith
by Stewart Smith
Hi there, I’m Stewart, a Principal Engineer at AWS working on Amazon
Linux, and thanks to our new direction in basing Amazon Linux on Fedora,
also Fedora.
I have a (decently) long time Linux history, remembering Slackware 3.5
on floppies, RedHat (not RHEL) 5 from CD-ROM, MkLinux, and YellowDog
(yay PowerPC). I’ve spent the vast bulk of my carreer around the free
software ecosystem, having spent a long time in the MySQL community, and
more recently OpenPOWER, and now working on Amazon Linux.
I have a few areas of interest that I’d personally love to contribute
around and see progress in the Fedora ecosystem. The idea of atomic
updates and rollback with systems like rpm-ostree is quite fascinating
from an operational point of view (my personal desktop is currently
running Silverblue), and likely fits really well with the versioned (and
version locked) repositories we’re doing with Amazon Linux 2022 and
beyond. I also think there’s a lot of interesting supply chain assurance
we can do to ensure continual and increased confidence in the open source
ecosystem and way of development. Then there’s things like performance,
boot times (including time-to-first-useful-work), image based
deployments (who needs an installer when you can have cloud-init or
similar to init things). So, that's a few areas of interest :)
With my AWS hat on, I’m pretty excited to see what we do over the coming
years with Fedora and Amazon Linux, and growing the number of people who
have working on Fedora as part of their day job (and yes, we're hiring).
3 months, 2 weeks
Orphaning some packages (w3c-markup-validator fallout)
by Nathanael D. Noblet
Hello,
I recently gave ownership of w3c-markup-validator to Sérgio Basto
which reminded me that there are a handful of perl packages that I
probably created/took a hand in as part of that. I haven't touched them
in as long as w3c-markup-validator so probably should also orphan them
as well. There are also some other packages like dspam that were great
at the time and I used to use them but they don't get much if any
development anymore and I don't run mail servers anymore.
The are as follows:
dspam
html401-dtds
perl-Config-General
perl-HTML-Encoding
perl-HTML-Tidy
perl-Mail-MBox-MessageParser
perl-Mail-MBox-MboxParser
perl-SGML-Parser-OpenSP
php-pecl-cairo
wkhtmltopdf
I will orphan them sometime next week if someone does want them. That
or retire but I don't know/remember what depends on them.
Sincerely,
--
Nathanael
3 months, 2 weeks
gcc-12.0.1-0.3.fc36 now in rawhide
by Jakub Jelinek
Hi!
A new gcc with most importantly the https://gcc.gnu.org/PR104172
bug (that caused a lot of ppc64le failures) fixed and various other
fixes (e.g. std::basic_string(std::nullptr_t) = deleted only done
for C++23 etc.) is now in rawhide.
Can rel-eng please retry all FTBS builds that failed on ppc64le?
Thanks
Jakub
3 months, 2 weeks
the meaning of pkgconfig's Libs fields
by Zbigniew Jędrzejewski-Szmek
Hi,
various .pc files that we ship contain a lot of stuff in the Libs and
Libs.private field don't make much sense to me. I started looking at
the documentation, and the documentation is very scarce, and what is
there doesn't seem to have been thought out at all. I'm writing my
observations and questions below.
pc(5) says:
Libs: Required linking flags for this package. Libraries this
package depends on for linking against it, which are not
described as dependencies should be specified here.
Libs.private: Required linking flags for this package that are
only required when linking statically. Libraries this
package depends on for linking against it statically, which
are not described as dependencies should be specified here.
"described as dependencies" here means "not listed in Requires and
Requires.private fields, which are used to specify dependencies on
other pkgconf projects.
On the face, this seems reasonable, but there's other documentation
that has a different spin. E.g.
https://people.freedesktop.org/~dbn/pkg-config-guide.html says:
Libs: The link flags specific to this package and any required
libraries that don't support pkg-config.
Libs.private: The link flags for private libraries required by
this package but not exposed to applications. The same
rule as Cflags applies here.
"required" here refers to using Requires and Requires.private to
list other .pc files.
Neither of the above approaches seems to be consistent with how we
actually use .pc files, and even not much consistent with how they
could be reasonably used:
1. pc(5) talks about "package", as if one would want to link to a
whole "package" instead one of the specific library files provided
by a package. Thankfully most .pc files only list one "-l" in Libs.
(Counterexamples: tbbmalloc_proxy.pc says 'Libs:-ltbbmalloc_proxy -ltbbmalloc',
and mit-krb5.pc says Libs:-lkrb5 -lk5crypto -lcom_err.)
The concept of having multiple libs in Libs in itself is borked:
either the libraries are functional separately, in which case they
would better have separate .pc files, so that the programs using
those libraries can link to the one they need, or if they are not
functional separately, the one that exposes functionality that is
useful externally should be advertised (the others will be pulled
in automatically by the linker).
2. In practice, most .pc files that list multiple things in Libs seem to
be doing exposing their own link dependencies there. For example
mono-2.pc says 'Libs: -L${libdir} -lmono-2.0 -lm -lm -lpthread',
and indeed ldd /usr/lib64/libmono-2.0.so says it is linked to libm.so.6.
Of course this doesn't mean that programs using libmono would need to
be linked to libm themselves.
Items 1 + 2 are promoting overlinking, i.e. adding either unneeded
libraries, or libraries that are used indirectly, to linker flags for
some object being linked.
If we take the pc(5) definition at its word, the Libs.private lines
are even more broken in Fedora, because we almost never provide static
libraries.
Looking at Requires and Requires.private, there is more strangeness.
pc(5):
Requires: Required dependencies that must be met for the package
to be usable. All dependencies must be satisfied or the
pkg-config implementation must not use the package.
Requires.private: Required dependencies that must be met for the
package to be usable for static linking. All dependencies
must be satisfied or the pkg-config implementation must
not use the package for static linking.
To a large extent pkgconfig files are duplicating dependency logic
that is already provided by distro packaging (rpm in our case). This
would seem like an OK idea: upstreams specify which libraries they
need and downstreams use it.
It seems not to work in practice: e.g. atk-bridge-2.0.pc specifies
Requires.private: dbus-1 >= 1.5, atspi-2 >= 2.33.2, atk >= 2.36.0,
glib-2.0 >= 2.32.0, gmodule-2.0 >= 2.0.0, gobject-2.0 >= 2.0.0
which is translated into:
$ rpm -qRf /usr/lib64/pkgconfig/atk-bridge-2.0.pc
/usr/bin/pkg-config
pkgconfig(atk) >= 2.36.0
pkgconfig(atspi-2) >= 2.33.2
pkgconfig(dbus-1) >= 1.5
pkgconfig(glib-2.0) >= 2.32.0
pkgconfig(gmodule-2.0) >= 2.0.0
pkgconfig(gobject-2.0) >= 2.0.0
...
Two problems:
3. We autogenerate a dependency on /usr/bin/pkg-config for -devel.
Logic is reversed here: the -devel package **provides** something
that it consumed by pkg-config. Dependencies are from a consumer to
the providing entity.
4. The -devel subpackage pulls in atk-devel, at-spi2-core-devel,
dbus-devel, glib2-devel, and glib2-devel. Most of those dependencies
are completely pointless. The only reason why one header package
would require another header package is when the headers it provides
#include other headers. at-spi2-atk-devel has a single header file,
with '#include <glib.h>'. It thus should have a dependency on 'pkgconfig(glib-2.0)',
and all the other deps generated from Requires.private just inflate
the build root. (If glib.h or libglib-2.0.so in turn require other
things for themselves, those dependencies will be specified by glib2.rpm.)
And finally, we get to stuff which is included in Libs:
/usr/lib64/pkgconfig/libresample.pc
Libs: -Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -lresample -lm
/usr/lib64/pkgconfig/libpsx.pc
Libs: -L${libdir} -lpsx -lpthread -Wl,-wrap,pthread_create
/usr/lib64/pkgconfig/ruby.pc
DLDFLAGS=-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
Libs: ${DLDFLAGS} ${LIBRUBYARG_SHARED} ${LIBS}
/usr/lib64/pkgconfig/libresample.pc
Libs: -Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -lresample -lm
/usr/lib64/pkgconfig/socket_wrapper.pc
Libs: lib64/libsocket_wrapper.so
/usr/lib/pkgconfig/gmodule-2.0.pc
Libs: -Wl,--export-dynamic
Those seems to be all errors: redhat-hardened-ld is supposed to be
used in package builds, not exposed for user compilations.
lib64/libsocket_wrapper.so cannot be resolved. And other link flags
that change the resulting binary is not the something that libraries
should specify.
To summarize:
- Re 3: drop the generator for the reversed dep?
- Re 2: flat everything that is not -l, -L, in Libs with rpmlint?
Zbyszek
3 months, 2 weeks
conditional require
by przemek klosowski
During recent major version update, some files were moved from
<package>-doc to <package>, and as a result updates of <package> fail
due to a file conflict. Manual update of <package>-doc resolves this, of
course.
A simple solution would be to declare that <package>
Required: package-doc >= 6.0.0
but that would force the install of the docs package if it wasn't
already there.
Is there a way to declare a dependency only if the other package is
present/installed? Would
Obsoletes: package-doc < 6.0.0
be the right thing to do?
3 months, 2 weeks
gcc-12.0.0-0.4.fc36 in rawhide
by Jakub Jelinek
Hi!
gcc 12 snapshot has landed as the system compiler into rawhide today.
GCC 12 is going to enter its stage4 development phase (only regression
and documentation bugfixes allowed) on Monday 17th, so there should be
just those bugfixes and not new features etc. anymore.
https://gcc.gnu.org/gcc-12/changes.html lists important changes,
most important is probably that vectorization is enabled at -O2 now
which is the option with most of the distribution is built with.
https://gcc.gnu.org/gcc-12/porting_to.html is so far incomplete and lists
some cases where people need to adjust their code. Other things
include the usual C++ header changes, where previously some standard
header included some other header as an implementation detail but it doesn't
any longer and so code that relied on such indirect include that isn't
required by the standard needs to include the header that provides whatever
it relies on. Or e.g. packages using -Werror where new warnings are
reported with the newer compiler and -Werror results in build failures.
If there are bugs on the compiler side, please let me know immediately,
so that those bugs can be fixed before the mass rebuild next week.
Another important thing I wanted to say is that we'd like to switch
ppc64le from the numerically problematic IBM extended long double to
IEEE 754 quad long double. This is an ABI change. Some libraries
are already built so that they support both ABIs at the same time,
including glibc, libstdc++, libgcc, libgfortran etc.
For other libraries and binaries, the compiler, assembler and linker
will notice if they use long double and flag them as using either
IBM or IEEE long double and linker (or I think dynamic linker too)
might complain when things are mixed.
Right now the rawhide gcc still defaults to -mabi=ibmlongdouble
but the glibc/gcc libraries are built compatibly with both.
We'd like to configure gcc shortly before the mass rebuild with
--with-long-double-format=ieee so that it will default to
-mabi=ieeelongdouble, probably on a side-tag build first, and it
will be highly desirable to rebuild at least some of the most commonly
used library packages in the order of dependencies there, otherwise
I'd be afraid the mass rebuild could fail for way too many packages
(as the mass rebuild doesn't do dependency order rebuilds but just
goes through packages alphabetically or so).
Any suggestions on which packages have commonly used library packages
that use long double?
readelf -A on libraries on ppc64le prints either nothing (either
the library is thought not to use long double or supports both ABIs
transparently or hasn't been rebuilt for some years), or
Attribute Section: gnu
File Attributes
Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double
for libraries (or binaries or object files) that use IBM long double
only or
Attribute Section: gnu
File Attributes
Tag_GNU_Power_ABI_FP: hard float, 128-bit IEEE long double
for IEEE long doubles.
So I think we want to rebuild on a side-tag packages that
provide shared libraries used by hundreds of other packages that
are
Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double
right now.
Jakub
3 months, 2 weeks
How to handle a few files moving from one package to another?
by Steven A. Falco
When updating from KiCad 5 to KiCad 6, a few files have moved from the kicad-doc package to the main kicad package.
If someone has KiCad 5 and its documentation package installed, and then tries to just upgrade the main package to KiCad 6 (without also updating the docs), they get an error message like:
Error: Transaction test error:
file /usr/share/doc/kicad/scripts/lib_convert.py from install of kicad-1:6.0.1-1.fc35.x86_64 conflicts with file from package kicad-doc-1:5.1.12-1.fc35.noarch
file /usr/share/doc/kicad/scripts/test_kicad_plugin.py from install of kicad-1:6.0.1-1.fc35.x86_64 conflicts with file from package kicad-doc-1:5.1.12-1.fc35.noarch
I think the correct solution is to put this into the main package:
Obsoletes: kicad-docs < 6.0.0
Is that correct, or is there a better way to handle it?
Steve
3 months, 2 weeks
Intent to orphan gnu-efi
by Robbie Harwood
Hello, we plan to orphan gnu-efi shortly after I finish fixing the
FTBFS. There do not appear to be any consumers:
# dnf repoquery --repo=rawhide{,-source} --whatrequires gnu-efi{,-devel} --source
Last metadata expiration check: 0:05:32 ago on Tue 25 Jan 2022 01:09:26 PM EST.
gnu-efi-3.0.11-7.1.fc36.src.rpm
#
Be well,
--Robbie
3 months, 2 weeks
ppc64le build failures in the mass rebuild
by Dan Horák
Hi,
as there are still a number of ppc64le build failures from the mass
rebuild, please make the FTBFS bugs block the "PPCTracker" so we know
about them.
Here is what we know so far
- segfaulting ICE with "during RTL pass: final" or not being able to
assemble the sources, those should be fixed in gcc-12.0.1-0.3.fc36, so
a rebuild should fix them
- issues with "__LDBL_REDIR1_DECL", they are caused by the bundled
gnulib not being compatible with the installed glibc, a fix is to
replace the bundled cdefs.h with more recent one
(https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/cdefs.h;h=...),
seen eg in lftp (https://bugzilla.redhat.com/show_bug.cgi?id=2045780)
or dhcpd-pools (https://bugzilla.redhat.com/show_bug.cgi?id=2045310)
- various "long double" related issues, some might be fixed by building
in proper order, but some will need further investigation, a corner
case in libffi should be fixed in
https://src.fedoraproject.org/rpms/libffi/pull-request/6
- various "vector" related issues/ICE, for example in cantera or mame
- libtool de-duplicating internal libs, when it shouldn't, like
/usr/bin/ld: /usr/lib/gcc/ppc64le-redhat-linux/12/libgcc.a(float128-ifunc.o):
(.data+0x0): undefined reference to
`__parse_hwcap_and_convert_at_platform',
this is a generic problem, a fix is proposed in
https://bugzilla.redhat.com/show_bug.cgi?id=2047389
and workaround is
https://src.fedoraproject.org/rpms/codeblocks/c/c8f36775a26f79d598e886a82...
- something else?
Thanks,
Dan
3 months, 2 weeks
