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, 10 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: 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
upgrading RH 9 system->Fedora with iso files and apt only
by Didier Casse
I have the yarrow's iso files on my HD in a RH9 system. Let's say I want
to upgrade selected packages using an "apt-get install" pointing to my
iso-mounted files, how do I do it?
i.e I mount the iso into some /mnt/yarrow1, /mnt/yarrow 2 etc..
Then what is the complete procedure to make my apt look into my own HD to
upgrade packages. Can anybody redirect me to the correct
resource or some literature hanging on the web? Thanks.
Assume also that I do not wish to burn CDs! I do not want to use
apt-cdrom. Thanks.
With kind regards,
Didier.
---
PhD student
Singapore Synchrotron Light Source (SSLS)
5 Research Link,
Singapore 117603
Email: slsbdfc at nus dot edu dot sg \or\
didierbe at sps dot nus dot edu dot sg
Website: http://ssls.nus.edu.sg
2 years, 3 months
Self Introduction: Jan Baudisch
by Jan Baudisch
Hi,
I am a computer science student from Germany and have used Fedora for
at least 2 years by now.
Using COPR I gained some experience in buidling packages but recently I
wanted to try building packages conforming to the guidelines and
getting them into Fedora. My interest is mostly in Rust and that is why
I would like to contribute Rust packages. I already got started here:
https://copr.fedorainfracloud.org/coprs/janbaudisch/rust/packages
For now my main interest would be to get the Rocket framework packaged,
as many projects rely on it and on the way I discovered some key Rust
crates not packaged yet.
I feel like some of them are ready for submission and will file the
first review requests soon.
Looking forward to working on this!
Jan
2 years, 3 months
Orphaning luit
by Peter Hutterer
I've orphaned luit. The only user of it was xterm and it recently dropped
support for luit so there are no users left. Whether there are *any* users
left is unclear too :)
The luit package we shipped is still the freedesktop.org one which has been
unmaintained for about a decade now. Upstream now points to
Thomas Dickey's fork at http://invisible-island.net/luit/ so if anyone
wants to take this, I advise switching to that version as part of the first
steps.
Cheers,
Peter
2 years, 3 months
