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).
2 years, 2 months
F37 Change: MinGW OpenSSL 3.x update (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/F37MingwOpenSSL3
== Summary ==
Update OpenSSL for MinGW to version 3.x
== Owner ==
* Name: [[User:smani|Sandro Mani]]
* Email: manisandro(a)gmail.com
== Detailed Description ==
mingw-openssl will be updated to version 3.x. The following
dependencies will be rebuilt:
* mingw-spice-gtk (will be updated to version 0.39)
* mingw-spice-protocol (will be updated to 0.14.3)
* mingw-qt6-qtbase
* mingw-qca
* mingw-gstreamer1-plugins-bad-free
* mingw-curl
* mingw-python3
* mingw-postgresql
* mingw-podofo
* mingw-opusfile
* mingw-minizip
* mingw-libssh2
* mingw-gdal
* mingw-openssl
== Benefit to Fedora ==
Ship up-to-date OpenSSL libraries for MinGW.
== Scope ==
* Proposal owners: mingw-openssl will be updated and the mentioned
dependencies rebuilt.
* Other developers: No action required
* Release engineering: Mass rebuild requested
* Policies and guidelines: No policies need to be changed
== Upgrade/compatibility impact ==
No impact
== How To Test ==
If your application uses OpenSSL to communicate via TLS or perform
other tasks that use cryptographic algorithms from OpenSSL, please
test whether it continues to work properly. This should be covered by
the comprehensive upstream testsuite of OpenSSL. However many
dependent packages also provide good test coverage of OpenSSL
functionality.
== User Experience ==
There should be no impact on end-user experience.
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism: Revert to older versions of environment /
toolchain, mass rebuild mingw packages again
* Contingency deadline: Before release
* Blocks release? Yes
* Blocks product? No
== Release Notes ==
Fedora 37 comes with mingw-openssl-3.x.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 2 months
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
2 years, 2 months
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
2 years, 2 months
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
2 years, 2 months
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?
2 years, 2 months