[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 week, 2 days
`ansible` Package License Change
by Maxwell G
The license of `ansible` 2.9.x has been corrected from `GPLv3+` to `GPLv3+ and BSD and Python and MIT and ASL 2.0`. The previous `License:` tag did not properly account for the multi-licensing.
Please note that this only applies to EPEL and Fedora 34 and 35. The license of `ansible` 5.x (the collections bundle), which is available on Fedora 36 and above, remains the same.
--
Thanks,
Maxwell G (@gotmax23)
Pronouns: He/Him/Him
1 week, 5 days
Heads up: openjpeg2-2.5.0 and gdal-3.5.0 coming to rawhide
by Sandro Mani
Hi
I'll build openjpeg2-2.5.0 and gdal-3.5.0 for rawhide in the side tag
f37-build-side-53899. I've switched gdal to the new cmake based build,
and at the same time merged the mingw package with the native one. I'll
rebuild affected packages as listed below.
Thanks
Sandro
---
lizams
bes
blender
cloudcompare
compat-ffmpeg4
darktable
dcm2niix
eccodes
efl
engauge-digitizer
ffmpeg
freeimage
gazebo
gdal
gdcm
geeqie
ghostscript
gimp
GMT
gpac
grass
gstreamer1-plugins-bad-free
ImageMagick
liblas
librasterlite2
mapnik
mapserver
merkaartor
mingw-freeimage
mingw-gstreamer1-plugins-bad-free
mingw-opencv
mingw-poppler
mtpaint
mupdf
ncl
opencv
OpenImageIO
OpenSceneGraph
openslide
osgearth
paraview
PDAL
poppler
postgis
python-fiona
python-pillow
python-PyMuPDF
python-rasterio
qgis
qmapshack
qsstv
R-rgdal
saga
vfrnav
vips
vtk
webkit2gtk3
zathura-pdf-mupdf
2 weeks
PSA: openQA failures in tests using Firefox
by Adam Williamson
Hi, folks. You may be noticing more failures than usual in openQA tests
that use Firefox. This is caused by a rather vexing combination of
Firefox wanting to show "helpful" popups on startup:
https://bugzilla.mozilla.org/show_bug.cgi?id=1703903
and what I think is some kind of odd regression in Firefox 100 which
makes typing into some text entry boxes in the Cockpit and FreeIPA web
UIs not work reliably (this affects realmd_join_cockpit and
upgrade_realmd_client).
I *think* I've figured out a way to deal with the popups for now (touch
wood, testing it right now). I'm still kinda stuck on the typing
problem. It's very late here now and I'll look into it more tomorrow. I
do apologize if an update is blocked on such a failure, I've been
restarting failed tests constantly all day but they keep hitting these
failure modes. I'll do my best to have it sorted by tomorrow one way or
another, and if I can't, I'll adjust the greenwave policy to
temporarily disable gating on the problematic tests.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
2 weeks, 6 days
News from printing world aka PWG May 2022 meetup
by Zdenek Dohnal
Hi all,
it is another year and we have an aggregated report of what changed in
the printing world since the last year.
The whole notes are as the attachment, but highlights are:
- myself (Zdenek Dohnal) being release manager for CUPS 2.4.x series
- Till Kamppeter wrote printer applications which covers all printer
drivers in Debian distribution - we don't have any additional printer
driver package in Fedora, so all our driver packages are covered as well
- printer applications (the solution for driver-only printers how to
work with IPP-only CUPS) are available as SNAPs in Fedora (feel free to
try them and leave feedback at the respective OpenPrinting project
https://github.com/orgs/OpenPrinting/repositories ), packaging them as
RPMs is blocked due dependency on cups-filters 2.0, which is not
released yet (though IIRC someone from Fedora community - maybe Brandon
Nielsen - has them in copr)
- in case of proprietary drivers which aren't packaged in OS there is a
legacy printer application inside of pappl-retrofit project, which, once
you install the printer in this printer application with the proprietary
driver you need, gives the printer IPP Everywhere interface, which makes
it visible for CUPS
- flatpak isn't designed for system services such as CUPS and printer
applications, so Till will investigate shipping containerized printer
applications via OCI containers on dockerhub
Enjoy!
--
Zdenek Dohnal
Software Engineer
Red Hat, BRQ-TPBC
3 weeks, 1 day
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
3 weeks, 3 days
Minizip pull requests
by Julian Sikorski
Hello,
I have created two PRs against minizip which are yet to be merged:
- https://src.fedoraproject.org/rpms/minizip/pull-request/3
- https://src.fedoraproject.org/rpms/minizip/pull-request/4
The first one should be a low risk one and should allow pkg-config using
dependencies like (shameless self-interest plug) to build against system
minizip again.
The second one needs support from a provenpackager. I tried rebuilding
the 18 dependencies of minizip and this is a bit tricky for two reasons:
- libsmbl and libspatialite need to be rebuilt before the other dependencies
- I cannot figure out how to get fedpkg srpm to work with libspatialite,
I am getting a Package already exists: %package debuginfo error from the
%{?mingw_debug_package} line. I am sure this is something someone
familiar with mingw can fix in a shortest amount of time.
Other than that, I can confirm that 13 dependencies can be rebuilt with
no changes. How can we move this forward?
Best regards,
Julian
3 weeks, 4 days
