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
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
2 years, 2 months
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
2 years, 2 months
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
2 years, 2 months
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
2 years, 2 months
RFE: CMake AutoRequires?
by Kevin Kofler
Hi,
when working on finally fixing Trojitá to build (it had been FTBFS since
F34, so removal was impending), I have noticed that the Akonadi contacts
plugin was not getting built because of missing transitive build
dependencies:
https://bugzilla.redhat.com/show_bug.cgi?id=2046299
https://bugzilla.redhat.com/show_bug.cgi?id=2046310
https://bugzilla.redhat.com/show_bug.cgi?id=2046574
They all have in common that FooConfig.cmake wants the CMake package Bar,
but foo-devel does not Require bar-devel. So building against Foo does not
work out of the box, only when manually BRing also bar-devel.
The thing is, we have had for a while AutoProvides scripts for CMake that
automatically let bar-devel Provide cmake(Bar). This is already used in many
places. What is missing, though, is corresponding AutoRequires, so that foo-
devel automatically Requires: cmake(Bar) if FooConfig.cmake requires Bar.
Would it not make sense to add such an AutoRequires script?
Kevin Kofler
2 years, 2 months
Carla compilation fails with: /usr/bin/ld: warning: libgraphite2.so.3,
needed by /lib/libharfbuzz.so.0
by Martin Gansser
Hi,
I'am trying to compile Carla [1] on f35, but this fails with this eror message [2]:
/usr/bin/ld: warning: libgraphite2.so.3, needed by /lib/libharfbuzz.so.0, not found (try using -rpath or -rpath-link)
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_seg_advance_X'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_face_featureval_for_lang'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_face_find_fref'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_seg_destroy'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_seg_first_slot'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_seg_n_slots'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_slot_can_insert_before'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_slot_origin_Y'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_slot_next_in_segment'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_make_face_with_ops'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_make_seg'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_slot_after'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_slot_origin_X'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_face_destroy'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_fref_set_feature_value'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_slot_gid'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_featureval_destroy'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_slot_before'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_slot_advance_Y'
collect2: error: ld returned 1 exit status
files are existing:
$ rpm -qf /usr/lib/libgraphite2.so.3 /usr/lib64/libgraphite2.so.3
graphite2-1.3.14-8.fc35.i686
graphite2-1.3.14-8.fc35.x86_64
How can i fix this ?
[1] https://martinkg.fedorapeople.org/Packages/Carla/Carla.spec
[2] https://martinkg.fedorapeople.org/Packages/Carla/carla-compile-erros.txt
Regards
Martin
2 years, 2 months
