[HEADS UP] -Wl,--as-needed is added in rawhide
by Igor Gnatenko
It's in redhat-rpm-config-118-1.fc30.
If it causes any problems for you - let me know. In the meantime, you can
use `%undefine _ld_as_needed` to disable it.
Thanks for attention!
--
-Igor Gnatenko
1 year, 10 months
Wine MinGW system libraries
by Zebediah Figura
Hello all,
I'm a contributor to the Wine project. To summarize the following mail,
Wine needs special versions of some of its normal dependencies, such as
libfreetype and libgnutls, built using the MinGW cross-compiler, and I'm
sending out a mail to major distributions in order to get some feedback
from our packagers on how these should be built and packaged.
For a long time Wine has built all of its Win32 libraries (DLLs and
EXEs) as ELF binaries. For various reasons related to application
compatibility, we have started building our binaries as PE instead,
using the MinGW cross-compiler. It is our intent to expand this to some
of our dependencies as well. The list of dependencies that we intend to
build using MinGW is not quite fixed yet, but we expect it to include
and be mostly limited to the following:
* libvkd3d
* libFAudio
* libgnutls
* zlib (currently included via manual source import)
* libmpg123
* libgsm
* libpng
* libjpeg-turbo
* libtiff
* libfreetype
* liblcms2
* jxrlib
and dependencies of the above packages (not including CRT dependencies,
which Wine provides).
There is currently some internal discussion about how these dependencies
should be built and linked. There are essentially three questions I see
that need to be resolved, and while these resolutions have a significant
impact on the Wine building and development process, they also have an
impact on distributions, and accordingly I'd like to get input from our
packagers to ensure that their considerations are accurately taken into
account.
(1) Should we build via source import, or link statically, or dynamically?
Static linking and source imports are dispreferred by Fedora [1] [2], as
by many distributions, on the grounds that they cause duplication of
libraries on disk and in memory, and make it harder to update the
libraries in question (see also question 2). They also make building and
bisecting harder.
Note however that if they are linked dynamically, we need to make sure
that we load our packages instead of MinGW builds of open-source
libraries with applications ship with. Accordingly we need each library
to be renamed, and to link to renamed dependencies. For example, if
application X ships with its own copy of libfreetype-6.dll, we need to
make sure that our gdi32.dll links to libwinefreetype-6.dll instead, and
that libwinefreetype-6.dll links to libwineharfbuzz-0.dll and
winezlib.dll. I think, although I haven't completely verified yet, that
this can be done just with build scripts (i.e. no source patches), by
using e.g. --with-zlib=/path/to/winezlib.dll.
Accordingly, although static linking and source imports are generally
disprefered, it may quite likely be preferable in our case. We don't get
the benefits of on-disk deduplication, since Wine is essentially the
only piece of software which needs these libraries.
(2) If we use dynamic libraries, should dependencies be included in the
main wine package, or packaged separately?
This is mostly a question for packagers, although it also relates to (3).
I expect that Fedora (and most distributions) want to answer "packaged
separately" here, on the grounds that this lets them update (say) Wine's
libgnutls separately, and in sync with ELF libgnutls, if some security
fix is needed. There is a snag, though: we need libraries to be copied
into the prefix (there's some internal effort to allow using something
like symlinks instead, but this hard and not done yet). Normally we
perform this copy every time Wine is updated, but if Wine and its
dependencies aren't updated on the same schedule, we may end up loading
an old version of a dependency in the prefix, thus missing the point of
the update.
(3) If dependencies are packaged separately, should Wine build them as
part of its build tree (e.g. using submodules), or find and link
(statically or dynamically) to existing binaries?
Linking to existing binaries is generally preferable: it avoids
duplication on disk; it reduces compile times when compiling a single
package from source (especially the first time). However, we aren't
going to benefit from on-disk duplication. And, most importantly, unlike
with ELF dependencies, there is no standardized way to locate MinGW
libraries—especially if it comes to Wine-specific libraries. We would
need a way for Wine's configure script to find these packages—and
ideally find them automatically, or else fall back to a submodule-based
approach.
If we rely on distributions to provide our dependencies, the best idea I
have here would be something like a x86_64-w64-mingw32-pkg-config. And
if we use shared libraries rather than static, things get worse: we need
to know the exact path of each library and its dependencies so that we
can copy (or symlink) them into a user's WINEPREFIX.
For what it's worth, the current proposed solution (which has the
support of the Wine maintainer) involves source imports and submodules.
There's probably room for changing our approach even after things are
committed, but I'd still like to get early feedback from distributions,
and make sure that their interests are accurately represented, before we
commit. In short, it's not clear whether distributions want their
no-static-library policies to apply to us as well, or whether we're
enough of a special case and would be enough of a pain to package that
they'd rather we deal with the hard parts, and I don't want us to make
any assumptions.
ἔρρωσθε,
Zebediah
[1]
https://docs.fedoraproject.org/en-US/packaging-guidelines/#packaging-stat...
[2] https://fedoraproject.org/wiki/Bundled_Libraries
1 year, 10 months
OpenJDK and unremoved directories
by Vitaly Zaitsev
Hello.
I have a lot of unremoved directories and files in /usr/lib/jvm/:
$ ls -l /usr/lib/jvm/
total 140
drwxr-xr-x. 5 root root 4096 Sep 10 14:32
java-11-openjdk-11.0.12.0.7-4.fc34.x86_64
drwxr-xr-x. 3 root root 4096 Mar 14 2017
java-1.8.0-openjdk-1.8.0.121-10.b14.fc25.x86_64
drwxr-xr-x. 3 root root 4096 Apr 21 2017
java-1.8.0-openjdk-1.8.0.131-1.b12.fc25.x86_64
drwxr-xr-x. 3 root root 4096 Oct 25 2017
java-1.8.0-openjdk-1.8.0.151-1.b12.fc26.x86_64
drwxr-xr-x. 3 root root 4096 Oct 25 2017
java-1.8.0-openjdk-1.8.0.151-1.b12.fc27.x86_64
drwxr-xr-x. 3 root root 4096 Jan 24 2018
java-1.8.0-openjdk-1.8.0.161-0.b14.fc27.x86_64
drwxr-xr-x. 3 root root 4096 Feb 6 2018
java-1.8.0-openjdk-1.8.0.161-5.b14.fc27.x86_64
drwxr-xr-x. 3 root root 4096 Mar 29 2018
java-1.8.0-openjdk-1.8.0.162-3.b12.fc27.x86_64
drwxr-xr-x. 3 root root 4096 Apr 18 2018
java-1.8.0-openjdk-1.8.0.171-1.b10.fc27.x86_64
drwxr-xr-x. 3 root root 4096 Apr 25 2018
java-1.8.0-openjdk-1.8.0.171-4.b10.fc27.x86_64
drwxr-xr-x. 3 root root 4096 Apr 25 2018
java-1.8.0-openjdk-1.8.0.171-4.b10.fc28.x86_64
drwxr-xr-x. 3 root root 4096 Jul 3 2018
java-1.8.0-openjdk-1.8.0.172-12.b11.fc28.x86_64
drwxr-xr-x. 3 root root 4096 Jun 18 2018
java-1.8.0-openjdk-1.8.0.172-9.b11.fc28.x86_64
drwxr-xr-x. 3 root root 4096 Jul 23 2018
java-1.8.0-openjdk-1.8.0.181-7.b13.fc28.x86_64
drwxr-xr-x. 3 root root 4096 Sep 5 2018
java-1.8.0-openjdk-1.8.0.181.b15-0.fc28.x86_64
drwxr-xr-x. 3 root root 4096 Oct 4 2018
java-1.8.0-openjdk-1.8.0.181.b15-5.fc28.x86_64
drwxr-xr-x. 3 root root 4096 Oct 11 2018
java-1.8.0-openjdk-1.8.0.181.b15-6.fc28.x86_64
drwxr-xr-x. 3 root root 4096 Oct 11 2018
java-1.8.0-openjdk-1.8.0.181.b15-6.fc29.x86_64
drwxr-xr-x. 3 root root 4096 Nov 29 2018
java-1.8.0-openjdk-1.8.0.191.b12-11.fc29.x86_64
drwxr-xr-x. 3 root root 4096 Nov 1 2018
java-1.8.0-openjdk-1.8.0.191.b12-8.fc29.x86_64
drwxr-xr-x. 3 root root 4096 Jan 14 2019
java-1.8.0-openjdk-1.8.0.191.b13-0.fc29.x86_64
drwxr-xr-x. 3 root root 4096 Feb 6 2019
java-1.8.0-openjdk-1.8.0.201.b09-2.fc29.x86_64
drwxr-xr-x. 3 root root 4096 Mar 26 2019
java-1.8.0-openjdk-1.8.0.201.b09-6.fc29.x86_64
drwxr-xr-x. 3 root root 4096 Apr 23 2019
java-1.8.0-openjdk-1.8.0.212.b04-0.fc29.x86_64
drwxr-xr-x. 3 root root 4096 Apr 23 2019
java-1.8.0-openjdk-1.8.0.212.b04-0.fc30.x86_64
drwxr-xr-x. 3 root root 4096 Jul 31 2019
java-1.8.0-openjdk-1.8.0.222.b10-0.fc30.x86_64
drwxr-xr-x. 3 root root 4096 Oct 16 2019
java-1.8.0-openjdk-1.8.0.232.b09-0.fc30.x86_64
drwxr-xr-x. 3 root root 4096 Oct 16 2019
java-1.8.0-openjdk-1.8.0.232.b09-0.fc31.x86_64
drwxr-xr-x. 3 root root 4096 Jan 28 2020
java-1.8.0-openjdk-1.8.0.242.b08-0.fc31.x86_64
drwxr-xr-x. 3 root root 4096 Mar 23 2020
java-1.8.0-openjdk-1.8.0.242.b08-1.fc32.x86_64
drwxr-xr-x. 3 root root 4096 May 4 2020
java-1.8.0-openjdk-1.8.0.252.b09-0.fc32.x86_64
drwxr-xr-x. 3 root root 4096 May 22 2020
java-1.8.0-openjdk-1.8.0.252.b09-1.fc32.x86_64
drwxr-xr-x. 3 root root 4096 Jul 17 2020
java-1.8.0-openjdk-1.8.0.262.b10-1.fc32.x86_64
drwxr-xr-x. 3 root root 4096 Jul 28 2020
java-1.8.0-openjdk-1.8.0.265.b01-1.fc32.x86_64
drwxr-xr-x. 3 root root 4096 Oct 21 2020
java-1.8.0-openjdk-1.8.0.272.b10-0.fc32.x86_64
lrwxrwxrwx. 1 root root 21 Sep 10 14:32 jre -> /etc/alternatives/jre
lrwxrwxrwx. 1 root root 24 Sep 10 14:32 jre-11 -> /etc/alternatives/jre_11
lrwxrwxrwx. 1 root root 32 Sep 10 14:32 jre-11-openjdk ->
/etc/alternatives/jre_11_openjdk
lrwxrwxrwx. 1 root root 41 Aug 31 18:50
jre-11-openjdk-11.0.12.0.7-4.fc34.x86_64 ->
java-11-openjdk-11.0.12.0.7-4.fc34.x86_64
lrwxrwxrwx. 1 root root 29 Sep 10 14:32 jre-openjdk ->
/etc/alternatives/jre_openjdk
I think the OpenJDK's scriplets need to be adjusted to remove everything.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
1 year, 11 months
Heads-up: grpc 1.41.0 coming to Rawhide with C (core) and C++ soname
bumps
by Ben Beasley
In one week (October 6), or slightly later, I will build grpc 1.41.0 for
Rawhide (F36). Fedora 35 will remain on 1.39.1.
As is traditional for minor releases of grpc, the C++ ABI was broken
(soversion bumped from 1.40 to 1.41). This time, the C (core) ABI was
also broken (soversion bumped from 18 to 19).
I will coordinate builds in a side tag of packages that use the C (core)
and/or C++ libraries. Maintainers of the following packages should have
received this email directly:
• bear
• frr
• perl-grpc-xs
Packages that use the Python bindings should be unaffected, as there
should be no incompatible API changes:
• buildstream
• python-chirpstack-api
• python-etcd3
• python-google-api-core
• python-google-cloud-core
• python-grpc-google-iam
• python-opencensus (orphaned)
• python-opencensus-proto
• python-opentelemetry
• python-pytest-grpc
• python-xds-protos
1 year, 11 months
Release criteria proposal: networking requirements
by Adam Williamson
Hi folks!
So at this week's blocker review meeting, the fact that we don't have
explicit networking requirements in the release criteria really started
to bite us. In the past we have squeezed networking-related issues in
under other criteria, but for some issues that's really difficult,
notably VPN issues. So, we agreed we should draft some explicit
networking criteria.
This turns out to be a big area and quite hard to cover (who'd've
thought!), but here is at least a first draft for us to start from. My
proposal would be to add this to the Basic criteria. I have left out
some wikitext stuff from the proposal for clarity; I'd add it back in
on actually applying the proposed changes. It's just formatting stuff,
nothing that'd change the meaning. Anyone have thoughts, complaints,
alternative approaches, supplements? Thanks!
=== Network requirements ===
Each of these requirements apply to both installer and installed system
environments. For any given installer environment, the 'default network
configuration tools' are considered to be those the installer documents
as supported ways to configure networking (e.g. for anaconda-based
environments, configuration via kernel command line options, a
kickstart, or interactively in anaconda itself are included).
==== Basic networking ====
It must be possible to establish both IPv4 and IPv6 network connections
using DHCP and static addressing. The default network configuration
tools for the console and for release-blocking desktops must work well
enough to allow typical network connection configuration operations
without major workarounds. Standard network functions such as address
resolution and connections with common protocols such as ping, HTTP and
ssh must work as expected.
Footnote titled "Supported hardware": Supported network hardware is
hardware for which the Fedora kernel includes drivers and, where
necessary, for which a firmware package is available. If support for a
commonly-used piece or type of network hardware that would usually be
present is omitted, that may constitute a violation of this criterion,
after consideration of the [[Blocker_Bug_FAQ|hardware-dependent-
issues|normal factors for hardware-dependent issues]]. Similarly,
violations of this criteria that are hardware or configuration
dependent are, as usual, subject to consideration of those factors when
determining whether they are release-blocking
==== VPN connections ====
Using the default network configuration tools for the console and for
release-blocking desktops, it must be possible to establish a working
connection to common OpenVPN, openconnect-supported and vpnc-supported
VNC servers with typical configurations.
Footnote title "Supported servers and configurations": As there are
many different VPN server applications and configurations, blocker
reviewers must use their best judgment in determining whether
violations of this criterion are likely to be encountered commonly
enough to block a release, and if so, at which milestone. As a general
principle, the more people are likely to use affected servers and the
less complicated the configuration required to hit the bug, the more
likely it is to be a blocker.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
2 years, 1 month
F36 Change: Drop NIS(+) support from PAM (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/drop_NIS_support_from_PAM
== Summary ==
This change is about dropping user-authentication using NIS(+) from PAM.
== Owner ==
* Name: [[User:besser82 | Björn Esser]]
* Email: besser82(a)fedoraproject.org
* Name: [[User:ipedrosa | Iker Pedrosa]]
* Email: ipedrosa(a)redhat.com
== Detailed Description ==
NIS(+) was introduced by Sun/Oracle to easily share files and system
users between UNIX-alike systems within the same network, and has been
around for some decades. Its simplicity though opens a variety of
possible security issues, like not being able the verify whether the
shared information is actually correct and/or trustworthy. That said,
and with several more secure options (LDAP, Kerberos, Samba, etc.) to
achieve the same goal, we should at least remove support for NIS for
user authentication.
== Feedback ==
There was some discussion on
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
the fedora-devel mailing-list]. Some people are reluctant about the
removal of NIS(+) support from PAM, while most are okay with it as
there are more secure alternatives (LDAP, FreeIPA, etc.) available.
== Benefit to Fedora ==
With this change we start directing our users and developers to move
away from NIS(+) to secure alternatives like LDAP and/or FreeIPA.
== Scope ==
* Proposal owners:
** Adapt the pam spec file to build without support for NIS(+).
** Communicate the removal of the PAM configuration for
user-authentication using NIS with the authselect maintainers; also
offer assistance to implement the needed changes.
* Other developers:
** Apply the pull-request to the authselect package.
** Test this change.
* Release engineering: [https://pagure.io/releng/issue/10351 #10351]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
Users that were relying on support for NIS(+) will need to move to
secure alternatives like LDAP and/or FreeIPA.
== How To Test ==
There is no need to test, as when configure switch is removed, support
is dropped.
== User Experience ==
For some users this change may be a bit disruptive and it may require
some learning curve for switching to alternative solutions.
== Dependencies ==
* The authselect package needs to be updated to drop its PAM
configuration for user-authentication using NIS.
* Apart from that there are actually no rpms, that directly depend on
the change of the functionality of the affected PAM module.
== Contingency Plan ==
* Contingency mechanism: Revert the changes made to the affected
packages and rebuild them.
* Contingency deadline: At beta freeze.
* Blocks release? Yes.
== Documentation ==
The documentation about sharing system users and files over NIS should
be dropped, if there even is any.
== Release Notes ==
Support for NIS(+) has been dropped from PAM. Users, who are
currently using NIS(+) to share UNIX users / groups within a network,
should migrate their setups to use LDAP or some other secure service
providing comparable functionalities before updating to Fedora 36.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 2 months
libcurl-minimal
by Zbigniew Jędrzejewski-Szmek
Hi Kamil and everyone,
what is the plan with introduction of libcurl-minimal in Fedora?
IIUC, libcurl and libcurl-minimal both have the same Provides, so libcurl-minimal
can be used to satisfy automatically generated dependencies:
$ dnf repoquery --provides libcurl-minimal
libcurl = 7.78.0-3.fc35
libcurl(x86-32) = 7.78.0-3.fc35
libcurl(x86-64) = 7.78.0-3.fc35
libcurl-minimal = 7.78.0-3.fc35
libcurl-minimal(x86-32) = 7.78.0-3.fc35
libcurl-minimal(x86-64) = 7.78.0-3.fc35
libcurl.so.4
libcurl.so.4()(64bit)
$ dnf repoquery --provides libcurl
libcurl = 7.78.0-3.fc35
libcurl(x86-32) = 7.78.0-3.fc35
libcurl(x86-64) = 7.78.0-3.fc35
libcurl-full = 7.78.0-3.fc35
libcurl-full(x86-32) = 7.78.0-3.fc35
libcurl-full(x86-64) = 7.78.0-3.fc35
libcurl.so.4
libcurl.so.4()(64bit)
AFAICS, no other package makes use of libcurl-{full,minimal}.
In systemd we only care about a narrow subset of protocols, so libcurl-minimal is
perfect. I considered adding Suggests:libcurl-minimal%{_isa} in systemd. IIUC,
that'd bias dnf towards the installation of libcurl-minimal. But the problem
is that if some other package expects libcurl in the full version, it'll be
disappointed.
Hence my question: how to proceed with pulling in libcurl-minimal where
it'd be useful? Should I just add Suggests:libcurl-minimal%{_isa} in systemd
and let the maintainers of other packages add Recommends:libcurl-minimal%{_isa}
or Requires:libcurl-minimal%{_isa} if they need it? What packages would that be?
Another option would be do not do any of this at package level, but instead
pull in libcurl-minimal through comps or kickstart or equivalent when doing
installations.
(Sorry if this is all documented somewhere… I looked around, but didn't see
anything relevant.)
Zbyszek
2 years, 2 months
F36 Change: Enable exclude_from_weak_autodetect by default in LIBDNF
(System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/ExcludeFromWeakAutodetect
== Summary ==
exclude_from_weak_autodetect enables autodetection of unmet weak
dependencies (Recommends or Supplements) of installed packages and
blocks installation of packages satisfying already unmet dependencies.
In other words: When you don't have the recommended package installed,
it won't be automatically installed with future upgrades of the
recommending package.
== Owner ==
* Name: [[User:jmracek| Jaroslav Mracek]]
* Email: jmracek(a)redhat.com
== Detailed Description ==
The feature is designed to prevent an install of removed weak
dependencies from the system by users and to not install weak
dependencies missing after system deployment. It will change the
behavior of DNF, microdnf, and PackageKit. The feature will be
backported to all Fedoras, but in default, the feature will be off.
Additional information: https://bugzilla.redhat.com/show_bug.cgi?id=1699672
The default value for exclude_from_weak_autodetect configuration can
be overridden in `/etc/dnf/dnf.conf`
== Feedback ==
The feature was requested by [[User:Churchyard|Miro Hrončok]] and
supported by many others: See
[https://bugzilla.redhat.com/show_bug.cgi?id=1699672 rhbz#1699672] for
more feedback.
== Benefit to Fedora ==
After the installation of a fresh system, the first upgrade will not
install a lot of weak dependencies. Some of them were excluded from
the kick-start installation set for good reasons (security, image
size, minimal functional set, ...), but after the first update, all
weak dependencies are installed, therefore some features of deployment
simply disappear.
== Scope ==
* Proposal owners:
** The feature is ready in Pull Request -
https://github.com/rpm-software-management/libdnf/pull/1279
** PRs only wait for a release of libsolv
** The Feature will be enabled in upstream as default, therefore from
Fedora 36, we start to release libdnf without a revert patch of
default in comparison to upstream.
* Other developers: The change requires a new release of libsolv.
* Release engineering:
* Policies and guidelines: A packaging guideline should be added that
discourages or forbids weak dependencies on fully versioned
(sub)packages (see
[https://bugzilla.redhat.com/show_bug.cgi?id=1699672#c44 the
details]).
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
No manual changes will be required. After the libdnf update, this
feature will be on by default.
== How To Test ==
1. Install package without satisfied weak dependencies
2. Upgrade the upgrade. With exclude_from_weak_autodetect=true, it
will not install weak dependencies of already installed packages. With
exclude_from_weak_autodetect=false, weak dependencies will be
installed during upgrades.
== User Experience ==
The change in default will help to keep some values for particular
deployments (a minimal system will be still minimal without disabling
weak dependencies).
Users will be able to remove particular weak dependencies and they
will be not installed on the first upgrade.
In case when the feature will not work according to the user
expectation it can be switched off in the dnf configuration file.
== Dependencies ==
libsolv - Required code changes are already in the libsolv upstream.
We only wait for the next libsolv release.
== Contingency Plan ==
There are no external dependencies, therefore we can easily postpone
the feature and the change of default behavior.
* Contingency mechanism: (What to do? Who will do it?)
* Contingency deadline: beta freeze
* Blocks release? No
== Documentation ==
The feature will be documented in dnf man pages.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 2 months
Announcing LLVM Snapshot Packages for Fedora Linux
by Konrad Kleine
Dear Fedora packagers, developers and users,
we have some good news for you:
We are beginning to build nightly snapshot packages of LLVM for the latest
versions of Fedora Linux (currently 34, 35 and rawhide) for a growing list
of
architectures.
You can grab them here:
https://copr.fedorainfracloud.org/coprs/g/fedora-llvm-team/llvm-snapshots/
Feel free to enable the copr repository with
$ dnf copr enable @fedora-llvm-team/llvm-snapshots
and then install the i.e. latest clang with
$ dnf install clang
Beware, that a snapshot release of LLVM is probably more unstable than a
regular release! If you run into a problem, I would kindly ask you to wait
and try it again with the next snapshot.
We hope you enjoy this peek into the next version of LLVM that you can now
try without too much hassle and without compiling it every day on your own.
Regards,
Konrad Kleine
Senior Software Engineer, Platform Tools
Red Hat <https://www.redhat.com>
kkleine(a)redhat.com
M: +49(0)151/21000244
D87A 77F4 2A58 C72D 12A7 203B C0A0 2C32 BCB7 3099
<https://www.redhat.com>
2 years, 2 months