Rebase of fmt to 7.0.0
by Vitaly Zaitsev
Hello all.
Fmt package will be rebased in Rawhide from version 6.2.1 to 7.0.0 next
week.
This will include soversion bump from 6 to 7. All dependent packages
must be rebuilt.
Please check your packages, because there are some breaking API changes:
https://github.com/fmtlib/fmt/releases/tag/7.0.0
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
3 years, 9 months
Re: No debugsource generated, weird DWARF errors
by Mark Wielaard
Hi Xavier,
On Wed, 2020-07-29 at 18:50 +0200, Xavier Leroy wrote:
> If we need to add a directive to the generated assembly, or pass a `-g`
> option to the assembler, or use `gcc -c -g` as the assembler, let us know
> and we'll see what we can do.
>
> However, please keep backward compatibility in mind: from the Info manual
> it looks like gas version 2.34 has no `-g` option and no directives to
> control the generation of DWARF information. So there should be reasonable
> defaults for gas 2.35 to behave roughly like gas 2.34.
I think the change in binutils/gas 2.35 was supposed to be backward
compatible. I am pretty sure it was just an oversight that the DWARF
version (dwarf_level) was not set in the none -g case.
Lets see what Nick (the binutils maintainer) says. My patch is just the
first thing I came up with. I am sure there are other ways to fix this.
Cheers,
Mark
> > But... in 2.35 you can give the DWARF level you want.
> > The problem with not supplying -g (or --gdwarf-[VERSION]) is that the
> > dwarf_level is never set! And then gas will happily create an
> > .debug_info section with DWARF CUs that have a version of zero (!).
> >
> > This, defaulting to version 4. Fixes it for me:
> >
> > diff --git a/gas/as.c b/gas/as.c
> > index 4c5881abd88..c2da78870ef 100644
> > --- a/gas/as.c
> > +++ b/gas/as.c
> > @@ -103,7 +103,7 @@ int verbose = 0;
> > int flag_dwarf_cie_version = -1;
> >
> > /* The maximum level of DWARF DEBUG information we should
> > manufacture. */
> > -unsigned int dwarf_level = 0;
> > +unsigned int dwarf_level = 4;
> >
> > #if defined OBJ_ELF || defined OBJ_MAYBE_ELF
> > int flag_use_elf_stt_common = DEFAULT_GENERATE_ELF_STT_COMMON;
3 years, 9 months
Re: No debugsource generated, weird DWARF errors
by Richard W.M. Jones
On Wed, Jul 29, 2020 at 06:50:43PM +0200, Xavier Leroy wrote:
> However, please keep backward compatibility in mind: from the Info manual
> it looks like gas version 2.34 has no `-g` option and no directives to
> control the generation of DWARF information. So there should be reasonable
> defaults for gas 2.35 to behave roughly like gas 2.34.
It might be that the info file is out of date (my copy of the info
file doesn't even mention "as"!), but gas even back to 2.27 has the -g
option:
$ as --version
GNU assembler version 2.27-43.base.el7
Copyright (C) 2016 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-redhat-linux'.
$ echo 'nothing: ret' | as -g
$ file a.out
a.out: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
$ eu-readelf --debug-dump a.out
DWARF section [ 6] '.debug_info' at offset 0x83:
[Offset]
[...lots of stuff...]
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
3 years, 9 months
ceph -> qemu -> lots failing in the mass rebuild
by Richard W.M. Jones
qemu is uninstallable at the moment because ceph is uninstallable
because fmt was upgraded from 6 to 7 in the middle of the build
(resulting in an soname bump - it was announced).
There are quite a few things failing in the mass rebuild as a result.
I've kicked off a new build of ceph, and will follow up with qemu if
that's necessary, but note that ceph takes ~ 24 hours to build, so
it'll be a while ...
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
3 years, 9 months
Fedora 33 System-Wide Change proposal: swap on zram
by Ben Cotton
https://fedoraproject.org/wiki/Changes/SwapOnZRAM
== Summary ==
Swap is useful, except when it's slow. zram is a RAM drive that uses
compression. Create a swap-on-zram during start-up. And no longer use
swap partitions by default.
== Owner ==
* Name: [[User:chrismurphy| Chris Murphy]]
* Email: chrismurphy(a)fedoraproject.org
== Detailed Description ==
==== zram Basic function ====
The zram† device, typically <span style=color:brown>/dev/zram0</span>,
has a size set at create time during early boot, by zram-generator†
per its configuration file. The memory used is not preallocated. It's
dynamically allocated and deallocated, on demand. Due to compression,
a full <span style=color:brown>/dev/zram0</span> uses half as much
memory as its size.
The <span style=color:brown>/dev/zram0</span> behaves like any other
block device. It can be formatted with a file system, or mkswap, which
is the intention with this change proposal.
The system will use RAM normally up until it's full, and then start
paging out to swap-on-zram, same as a conventional swap-on-drive. The
zram driver starts to allocate memory at roughly 1/2 the rate of page
outs, due to compression. But, there is no free lunch. This means
swap-on-zram is not as effective at page eviction as swap-on-drive,
the eviction rate is ~50% instead of 100%. But it is at least an order
of magnitude faster than drive based swap.
zram has about 0.1% overhead or ~1MiB/1GiB. If the workload never
touches swap, this overhead is the sole cost. In practice when not
used at all, feature owner has experienced ~0.04% overhead.
Example: A system has 16 GiB RAM. The proposed defaults suggest the
<span style=color:brown>/dev/zram0</span> device will be 4 GiB. If the
workload completely fills up swap with 4 GiB of anonymous pages,
what's happened? The <span style=color:red>zramctl</span> command will
display the true compression ratio. If 2:1 is really obtained, it
means 4GiB swap data is compressed to 2GiB. Therefore 2GiB is the
actual RAM usage, and is also the net effective eviction. i.e. 4 GiB
anonymous pages are evicted, but are then compressed and pinned into 2
GiB RAM, for a net memory savings of 2 GiB.
†</br >
[https://www.kernel.org/doc/Documentation/blockdev/zram.txt kernel.org zram.txt]
[https://github.com/systemd/zram-generator Github zram-generator project]
==== Overview of the Feature ====
Using swap is a good idea†, but no one likes it when it's slow.
Anaconda and Fedora IoT have been using swap-on-zram by default for
years. This builds on their prior effort.
There are three components to the change:
# Install systemd rust-zram-generator† package. This does not enable
swap-on-zram, it only makes the generator available.</br >
# Install a default zram-generator configuration. When present,
swap-on-zram is set-up during startup.</br >
# Do not create swap partition/LV with default installations.
This proposal aims to apply all three, for all Fedora editions and
spins, by default.
It further aims to apply the first two, for upgrades and custom installations.
It might be useful to only make the generator available (1), should an
edition/spin wish to opt out, or as a fallback if applying the feature
to upgrades fails to withstand scrutiny.
†</br >
There is a tl;dr section at the top. Highly recommend reading the
whole article. [https://chrisdown.name/2018/01/02/in-defence-of-swap.html
In defence of swap: common misconceptions]
==== Default zram device configuration: ====
During startup, create a zram device <span
style=color:brown>/dev/zram0</span>, with a size equal to 50% RAM, but
capped† to 4 GiB, and with a higher than typical swap priority†.
These values seem reasonably conservative, and are based on prior work
in Fedora. Anaconda sets swap-on-drive sized to 50% RAM in the no
hibernation case, common outside x86. Fedora IoT's implementation also
sets swap-on-zram size to 50% RAM.
†</br >
[https://github.com/systemd/zram-generator/issues/10 RFE: should be
able to set a cap on zram device size #10]
[https://github.com/systemd/zram-generator/issues/8 RFE: should set priority #8]
==== Default installer behavior ====
The installer is currently responsible for creating a swap-on-drive
device. This will be dropped. The zram-generator + configuration file
will trigger the setup and activation of swap-on-zram. This means
hibernation isn't possible, even on systems that could support it.
Please see [https://pagure.io/fedora-workstation/blob/master/f/hibernationstatus.md
Supporting hibernation in Workstation edition] for much more detailed
information, including why it's increasingly likely hibernation isn't
possible anyway, and a path to improving hibernation support.
==== Custom/Advance partitioning installer behavior ====
The user can add swap using Custom partitioning at install time. This
is swap-on-drive. And the installer will also include the <span
style=color:red> resume=UUID </span> kernel parameter for this swap
device. No change in behavior here.
Since swap-on-zram is still enabled by default, there will be two
swaps: swap-on-zram, and swap-on-drive. The swap-on-zram will have
higher priority, thus being favored over drive based swap. The kernel
is smart enough to know it can't hibernate to a zram device, and will
instead use drive based swap.
==== How can it be disabled? ====
Immediately:</br >
<span style=color:red>swapoff /dev/zram0</span>
Permanently:</br >
<span style=color:red>rm /etc/systemd/zram-generator.conf</span>
== Feedback ==
==== You're enabling it on upgrades? ====
That's the current plan. As a technical matter, feature owner is
confident this feature will improve the experience of all users
regardless of configuration. As a non-technical matter, it's
recognized that (a) ''hey pal, you're messing with my customizations,
not cool!'' and (b) ''swap always stinks, I don't care if it has a 'Z'
in the name!'' may need more convincing.
There are possible risks.
* Workloads that expect full use of memory, and depend on 100% page
eviction. These may run slower if they really need full use of memory,
but some memory is used for the zram device instead. Such workloads
might favor zswap.
* Workloads with low compressible pages. In the worst case, this means
unnecessary work merely moving pages around.
* Workloads with memory full, and hibernation. Hibernation is already
stressful to memory-management subsystem and prone to bailing out in
such cases. The swap-on-zram will be favored for evictions in the
attempt to free memory to create the hibernation image. It could
increase instances of hibernation entry failure. This isn't a crash,
it just means the attempt doesn't succeed, and the system resumes
operation instead of hibernating.
While possible, it's difficult to estimate their probability. But this
is a significant consideration in the conservative default zram size.
Users can easily increase zram size as needed for their use case,
simply by editing <span
style=color:red>/etc/systemd/zram-generator.conf</span> and the change
takes effect at next boot.
==== Why systemd zram-generator? ====
It's the most upstream implementation to date, is fast and
lightweight. The zram-generator uses existing systemd infrastructure
to setup the zram block device, format it as swap, and swapon - all
during early boot. It's very similar in behavior to fstab-generator,
gpt-auto-generator, and cryptsetup-generator†.
Converging on one implementation avoids user confusion. And while the
alternatives are nice and work fine, a systemd generator is
particularly well suited for this use case compared to a systemd
service unit.†
Also, it's an reference implementation of a system generator written in Rust.
†</br >
[https://www.freedesktop.org/software/systemd/man/systemd.generator.html
freedesktop.org About systemd generators.]</br >
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
devel@ ''Re: swap-on-zram by default'' Zbigniew Jędrzejewski-Szmek,
systemd zram-generator author/maintainer]
==== Why not a bigger zram device? ====
The main idea of being conservative is to address concerns about
upgrades. It's possible some workloads will have less compressible
data. Hence, not going with <span style=color:brown>/dev/zram0</span>
sized to 100% of RAM at this time. Even a <span
style=color:brown>/dev/zram0</span> of 200% RAM is not unreasonable
*if* the compression ratio is at least 2:1. However, it's possible a
system can get "stuck" in a kind of swap thrashing similar to
conventional swap-on-drive, except it's CPU and memory bound, rather
than IO bound. Feature owner thinks it's better to just oom, instead
of getting overly aggressive with the zram device size.
Conversely it's possible to be too conservative with the size, and
result in more instances of OOM kill. If applying the feature to
upgrades is rejected, it's probably reasonable to increase the cap to
~8GiB. Of course more feedback and testing is needed, and it will be
taken into consideration.
Note that the kernel zram doc says an excessively sized zram device
does come with overhead. Users's can increase the size easily
post-install, a capability they don't easily have with swap-on-drive.
The goal for Fedora 33 is a default that's useful and safe for the
vast majority of use cases.
==== Why not zswap? ====
Zswap† is a similar idea, but with a totally different implementation.
It is swap specific, uses a RAM cache, and requires a conventional
swap partition existing already. It might be true certain workloads
are better suited for using zswap. But swap-on-zram depends only on
volatile storage. This is simpler and it's more secure. Whereas zswap
"spills over" into swap-on-drive and will leak user data if that swap
device isn't encrypted. Some workloads may do better with zswap, and
it's a valid future feature for a new generator, or possibly extend
zram-generator to support it via the configuration file. Maybe the
generator could favor zswap when swap-on-drive already exists; and
fallback to swap-on-zram?
†</br >
[https://www.kernel.org/doc/Documentation/vm/zswap.txt kernel.org zswap.txt]
== Benefit to Fedora ==
* significantly improves system responsiveness, especially when swap
is under pressure;
* more secure, user data leaks into swap are on volatile media;
* without swap-on-drive, there's better utilization of a limited
resource: benefit of swap without the drive space consumption;
* complements on-going resource control work, including earlyoom;
* further reduces the time to out-of-memory kill, when workloads exceed limits;
* improves performance for both "no swap" and "existing swap" setups;
== Scope ==
* Proposal owners:
** add zram-generator package to comps and kickstarts as appropriate
** obsolete zram package (used by Fedora IoT)
** means of per edition/spin configurations, if needed
** coordinate a test day
* Other developers:
**Anaconda are agreeable to deprecating their built-in implementation
in favor of swap-on-zram
**RFE's for zram-generator: users are not worse off if they don't
happen. Open request for help, to make it possible. It's much
appreciated.</br >
[https://github.com/systemd/zram-generator/issues/10 RFE: should be
able to set a cap on zram device size #10]</br >
[https://github.com/systemd/zram-generator/issues/8 RFE: should set priority #8]
* Release engineering: [https://pagure.io/releng/issues #9495]
* Policies and guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
Add Supplements:fedora-release-common to zram-generator to pull it in
on upgrades.
Existing systems without swap will have swap-on-zram enabled.
Existing systems with swap-on-drive, will also have swap-on-zram
enabled (two swap devices), with higher priority for the zram device.
Existing swap-on-drive will not be removed.
'zram' package contains zram-swap.service and associated bash scripts,
and is currently used by Fedora IoT and ARM spins. It will be
obsoleted to avoid conflicting/duplicative swap-on-zram
implementations.
== How To Test ==
Any hardware. Any version of Fedora.
# dnf install zram-generator
# cp /usr/share/doc/zram-generator/zram-generator.conf.example
/etc/systemd/zram-generator.conf
# Edit the configuration
# Reboot
# Check that swap is on a zram device: zramctl, swapon
# Detailed check: journalctl -b -o short-monotonic | grep 'swap\|zram'
# Check that priority is higher than existing swap if two or more are
listed. ## (Enhancement is needed for this.)
Suggested configuration file values:</br >
<span style=color:red>[zram0]</span></br >
<span style=color:red>memory-limit = none</span></br >
<span style=color:red>zram-fraction = 0.5</span></br >
Feel free to run your usual workloads more aggressively or in
parallel. Suspend-to-RAM and suspend-to-drive are expected to continue
to work too (or at least hit all the same bugs as without zram being
used).
Also, you can see the actual compression ratio achieved with the
following command:</br >
<span style=color:red> zramctl </span>
==== Test Day ====
[https://pagure.io/fedora-qa/issue/632 QA: SwapOnzram Test Day] to
discover edge cases, and tweak the default configuration if necessary
to establish a good one-size-fits all approach.
== User Experience ==
The user won't notice anything displeasing. If their usual workload
causes them to dread swap thrashing, they'll be surprised that
thrashing doesn't happen. The user might get curious if they don't
find a swap entry in /etc/fstab. Or if they 'swapon' and see swap
pointing to <span style=color:brown>/dev/zram0</span> instead of a
drive partition or LV.
== Dependencies ==
N/A
== Contingency Plan ==
* Contingency mechanism: Don't ship the generator = big hammer, but
easy. Preferable to ship the generator, but only selectively ship
configuration files = scalpel, pretty easy.
* Contingency deadline: Beta freeze
* Blocks release? No.
* Blocks product? No.
== Documentation ==
Consider adding a hint in an /etc/fstab comment? There is no man page
for this, and the documentation is also minimal, besides what's in
this feature proposal. It's an open question how the user should get
more information on how to configure and tweak it. But then, they
don't have that for swap today either. There's just institutional
knowledge.
Hence, a strong test day, with a lot of people and press coverage of
the feature, might help spread the word for institutional knowledge
changes coming.
Ideas welcome.
== Release Notes ==
Pending feedback and test day.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 9 months
Summary/Minutes from today's FESCo Meeting (2020-07-29)
by Fabio Valentini
=====================================
#fedora-meeting-2: FESCo (2020-07-29)
=====================================
Meeting started by decathorpe at 14:00:24 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-07-29/fesco.2020-...
.
Meeting summary
---------------
* Init Process (decathorpe, 14:00:52)
* LINK:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
Schedule (decathorpe, 14:05:34)
* #2446 What to do with the 33 packagers/watchers who do not have a
valid bugzilla account? (decathorpe, 14:06:01)
* AGREED: APPROVED (P1: (+5, 0, -1); P2+P3: (+6, 0, -0)) (decathorpe,
14:23:30)
* Next week's chair (decathorpe, 14:24:43)
* ACTION: ngompa will chair next week's meeting (decathorpe,
14:27:51)
* Open Floor (decathorpe, 14:28:05)
* LINK: https://src.fedoraproject.org/rpms/postgresql/commits/master
suggest 2 years of postgresql maintanance (mhroncok, 14:50:26)
* ACTION: zbyszek to comment in PostgreSQL ticket with questions /
missing details in Change Proposal (decathorpe, 14:59:20)
* #2416 Update 3rd party repo policy (decathorpe, 15:00:59)
* ACTION: everybody will read tickets and proposed docs changes and
vote in ticket (decathorpe, 15:04:32)
* Council is voting on an actual process for promoting deliverables to
Edition status
https://fedoraproject.org/wiki/Editions/Promotion_Process (bcotton,
15:06:11)
Meeting ended at 15:16:25 UTC.
Action Items
------------
* ngompa will chair next week's meeting
* zbyszek to comment in PostgreSQL ticket with questions / missing
details in Change Proposal
* everybody will read tickets and proposed docs changes and vote in
ticket
Action Items, by person
-----------------------
* zbyszek
* zbyszek to comment in PostgreSQL ticket with questions / missing
details in Change Proposal
* **UNASSIGNED**
* ngompa will chair next week's meeting
* everybody will read tickets and proposed docs changes and vote in
ticket
People Present (lines said)
---------------------------
* King_InuYasha (67)
* decathorpe (59)
* mhroncok (46)
* zbyszek (39)
* bcotton (25)
* sgallagh (24)
* nirik (24)
* dcantrell (24)
* zodbot (16)
* pingou (6)
* ignatenkobrain (0)
* Conan_Kudo (0)
* Eighth_Doctor (0)
* cverna (0)
* Sir_Gallantmon (0)
* Son_Goku (0)
* Pharaoh_Atem (0)
3 years, 9 months
DWARF version 0 unhandled
by Jerry James
Here's a bit of fallout from the mass rebuild. The alt-ergo build failed:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1548139
Everything seems fine up until debuginfo processing begins, then this happens:
/usr/lib/rpm/debugedit:
/builddir/build/BUILDROOT/alt-ergo-2.2.0-2.fc33.x86_64/usr/lib64/ocaml/alt-ergo/plugins/fm-simplex-plugin.cmxs:
DWARF version 0 unhandled
/usr/lib/rpm/debugedit:
/builddir/build/BUILDROOT/alt-ergo-2.2.0-2.fc33.x86_64/usr/bin/altgr-ergo:
DWARF version 0 unhandled
/usr/lib/rpm/debugedit:
/builddir/build/BUILDROOT/alt-ergo-2.2.0-2.fc33.x86_64/usr/bin/alt-ergo:
DWARF version 0 unhandled
/usr/lib/rpm/debugedit:
/builddir/build/BUILDROOT/alt-ergo-2.2.0-2.fc33.x86_64/usr/lib64/ocaml/alt-ergo/altErgoLib.cmxs:
DWARF version 0 unhandled
Dwarf Error: wrong version in compilation unit header (is 0, should be
2, 3, 4 or 5) [in module
/builddir/build/BUILDROOT/alt-ergo-2.2.0-2.fc33.x86_64/usr/lib64/ocaml/alt-ergo/plugins/fm-simplex-plugin.cmxs]
gdb-add-index: No index was created for
/builddir/build/BUILDROOT/alt-ergo-2.2.0-2.fc33.x86_64/usr/lib64/ocaml/alt-ergo/plugins/fm-simplex-plugin.cmxs
gdb-add-index: [Was there no debuginfo? Was there already an index?]
Dwarf Error: wrong version in compilation unit header (is 0, should be
2, 3, 4 or 5) [in module
/builddir/build/BUILDROOT/alt-ergo-2.2.0-2.fc33.x86_64/usr/lib64/ocaml/alt-ergo/altErgoLib.cmxs]
gdb-add-index: No index was created for
/builddir/build/BUILDROOT/alt-ergo-2.2.0-2.fc33.x86_64/usr/lib64/ocaml/alt-ergo/altErgoLib.cmxs
gdb-add-index: [Was there no debuginfo? Was there already an index?]
Dwarf Error: wrong version in compilation unit header (is 0, should be
2, 3, 4 or 5) [in module
/builddir/build/BUILDROOT/alt-ergo-2.2.0-2.fc33.x86_64/usr/bin/alt-ergo]
gdb-add-index: No index was created for
/builddir/build/BUILDROOT/alt-ergo-2.2.0-2.fc33.x86_64/usr/bin/alt-ergo
gdb-add-index: [Was there no debuginfo? Was there already an index?]
Dwarf Error: wrong version in compilation unit header (is 0, should be
2, 3, 4 or 5) [in module
/builddir/build/BUILDROOT/alt-ergo-2.2.0-2.fc33.x86_64/usr/bin/altgr-ergo]
gdb-add-index: No index was created for
/builddir/build/BUILDROOT/alt-ergo-2.2.0-2.fc33.x86_64/usr/bin/altgr-ergo
gdb-add-index: [Was there no debuginfo? Was there already an index?]
dwz: ./usr/bin/alt-ergo-2.2.0-2.fc33.x86_64.debug: DWARF version 0 unhandled
dwz: ./usr/bin/altgr-ergo-2.2.0-2.fc33.x86_64.debug: DWARF version 0 unhandled
dwz: ./usr/lib64/ocaml/alt-ergo/altErgoLib.cmxs-2.2.0-2.fc33.x86_64.debug:
DWARF version 0 unhandled
dwz: ./usr/lib64/ocaml/alt-ergo/plugins/fm-simplex-plugin.cmxs-2.2.0-2.fc33.x86_64.debug:
DWARF version 0 unhandled
dwz: Too few files for multifile optimization
original debug info size: 6720kB, size after compression: 6724kB
That leads to the actual fatal error:
Processing files: alt-ergo-debugsource-2.2.0-2.fc33.x86_64
RPM build errors:
error: Empty %files file
/builddir/build/BUILD/alt-ergo-2.2.0/debugsourcefiles.list
Empty %files file /builddir/build/BUILD/alt-ergo-2.2.0/debugsourcefiles.list
Child return code was: 1
A mock -r fedora-rawhide-x86_64 build succeeds, so everything was
working as expected at the time of the last Rawhide compose. (I admit
that I do not know how long ago that was.) If I build in mock with
--enablerepo=local, I see the same failure. The packages that are
different in the two mock chroots are as follows.
"Old" packages that work:
annobin-9.23-1.fc33.x86_64
binutils-2.34.0-8.fc33.x86_64
binutils-gold-2.34.0-8.fc33.x86_64
bzip2-1.0.8-2.fc32.x86_64
bzip2-devel-1.0.8-2.fc32.x86_64
bzip2-libs-1.0.8-2.fc32.x86_64
coreutils-8.32-7.fc33.x86_64
coreutils-common-8.32-7.fc33.x86_64
cpp-10.1.1-2.fc33.x86_64
curl-7.71.1-2.fc33.x86_64
elfutils-0.180-3.fc33.x86_64
elfutils-debuginfod-client-0.180-3.fc33.x86_64
elfutils-default-yama-scope-0.180-3.fc33.noarch
elfutils-libelf-0.180-3.fc33.x86_64
elfutils-libs-0.180-3.fc33.x86_64
findutils-4.7.0-4.fc33.x86_64
gawk-5.0.1-7.fc32.x86_64
gcc-10.1.1-2.fc33.x86_64
gdbm-libs-1.18.1-3.fc32.x86_64
glibc-2.31.9000-19.fc33.x86_64
glibc-common-2.31.9000-19.fc33.x86_64
glibc-devel-2.31.9000-19.fc33.x86_64
glibc-headers-x86-2.31.9000-19.fc33.noarch
glibc-minimal-langpack-2.31.9000-19.fc33.x86_64
gmp-6.2.0-1.fc33.x86_64
gmp-c++-6.2.0-1.fc33.x86_64
gmp-devel-6.2.0-1.fc33.x86_64
gsettings-desktop-schemas-3.37.1-1.fc33.x86_64
gtkspell-2.0.16-20.fc32.x86_64
json-c-0.14-6.fc33.x86_64
kernel-headers-5.8.0-0.rc5.git0.1.fc33.x86_64
krb5-libs-1.18.2-10.fc33.x86_64
libarchive-3.4.3-1.fc33.x86_64
libblkid-2.35.2-2.fc33.x86_64
libblkid-devel-2.35.2-2.fc33.x86_64
libblockdev-2.24-2.fc33.x86_64
libblockdev-crypto-2.24-2.fc33.x86_64
libblockdev-fs-2.24-2.fc33.x86_64
libblockdev-loop-2.24-2.fc33.x86_64
libblockdev-mdraid-2.24-2.fc33.x86_64
libblockdev-part-2.24-2.fc33.x86_64
libblockdev-swap-2.24-2.fc33.x86_64
libblockdev-utils-2.24-2.fc33.x86_64
libcurl-7.71.1-2.fc33.x86_64
libdb-5.3.28-42.fc33.x86_64
libfdisk-2.35.2-2.fc33.x86_64
libgcc-10.1.1-2.fc33.x86_64
libgomp-10.1.1-2.fc33.x86_64
libicu-67.1-1.fc33.x86_64
libicu-devel-67.1-1.fc33.x86_64
libmount-2.35.2-2.fc33.x86_64
libmount-devel-2.35.2-2.fc33.x86_64
libnghttp2-1.41.0-1.fc33.x86_64
libseccomp-2.4.2-3.fc32.x86_64
libselinux-3.1-1.fc33.x86_64
libselinux-devel-3.1-1.fc33.x86_64
libsemanage-3.1-1.fc33.x86_64
libsepol-3.1-1.fc33.x86_64
libsepol-devel-3.1-1.fc33.x86_64
libsmartcols-2.35.2-2.fc33.x86_64
libstdc++-10.1.1-2.fc33.x86_64
libuuid-2.35.2-2.fc33.x86_64
parted-3.3-3.fc33.x86_64
procps-ng-3.3.15-7.fc32.x86_64
python-srpm-macros-3.9-6.fc33.noarch
python3-3.9.0~b4-2.fc33.x86_64
python3-libs-3.9.0~b4-2.fc33.x86_64
redhat-rpm-config-161-2.fc33.noarch
rpm-4.16.0-0.beta3.2.fc33.x86_64
rpm-build-4.16.0-0.beta3.2.fc33.x86_64
rpm-build-libs-4.16.0-0.beta3.2.fc33.x86_64
rpm-libs-4.16.0-0.beta3.2.fc33.x86_64
sqlite-libs-3.32.3-1.fc33.x86_64
systemd-246~rc1-1.fc33.x86_64
systemd-libs-246~rc1-1.fc33.x86_64
systemd-pam-246~rc1-1.fc33.x86_64
systemd-rpm-macros-246~rc1-1.fc33.noarch
systemd-udev-246~rc1-1.fc33.x86_64
util-linux-2.35.2-2.fc33.x86_64
xfsprogs-5.6.0-2.fc33.x86_64
xxhash-libs-0.7.4-1.fc33.x86_64
"New" packages that lead to the build failure:
annobin-9.24-2.fc33.x86_64
binutils-2.35-3.fc33.x86_64
binutils-gold-2.35-3.fc33.x86_64
bzip2-1.0.8-4.fc33.x86_64
bzip2-devel-1.0.8-4.fc33.x86_64
bzip2-libs-1.0.8-4.fc33.x86_64
coreutils-8.32-9.fc33.x86_64
coreutils-common-8.32-9.fc33.x86_64
cpp-10.2.1-1.fc33.x86_64
curl-7.71.1-3.fc33.x86_64
elfutils-0.180-5.fc33.x86_64
elfutils-debuginfod-client-0.180-5.fc33.x86_64
elfutils-default-yama-scope-0.180-5.fc33.noarch
elfutils-libelf-0.180-5.fc33.x86_64
elfutils-libs-0.180-5.fc33.x86_64
findutils-4.7.0-6.fc33.x86_64
gawk-5.1.0-1.fc33.x86_64
gcc-10.2.1-1.fc33.x86_64
gdbm-libs-1.18.1-4.fc33.x86_64
glibc-2.31.9000-21.fc33.x86_64
glibc-common-2.31.9000-21.fc33.x86_64
glibc-devel-2.31.9000-21.fc33.x86_64
glibc-headers-x86-2.31.9000-21.fc33.noarch
glibc-minimal-langpack-2.31.9000-21.fc33.x86_64
gmp-6.2.0-3.fc33.x86_64
gmp-c++-6.2.0-3.fc33.x86_64
gmp-devel-6.2.0-3.fc33.x86_64
gsettings-desktop-schemas-3.37.2-1.fc33.x86_64
gtkspell-2.0.16-21.fc33.x86_64
json-c-0.14-7.fc33.x86_64
kernel-headers-5.8.0-0.rc7.git0.1.fc33.x86_64
krb5-libs-1.18.2-12.fc33.x86_64
libarchive-3.4.3-2.fc33.x86_64
libblkid-2.36-1.fc33.x86_64
libblkid-devel-2.36-1.fc33.x86_64
libblockdev-2.24-3.fc33.x86_64
libblockdev-crypto-2.24-3.fc33.x86_64
libblockdev-fs-2.24-3.fc33.x86_64
libblockdev-loop-2.24-3.fc33.x86_64
libblockdev-mdraid-2.24-3.fc33.x86_64
libblockdev-part-2.24-3.fc33.x86_64
libblockdev-swap-2.24-3.fc33.x86_64
libblockdev-utils-2.24-3.fc33.x86_64
libcurl-7.71.1-3.fc33.x86_64
libdb-5.3.28-43.fc33.x86_64
libfdisk-2.36-1.fc33.x86_64
libgcc-10.2.1-1.fc33.x86_64
libgomp-10.2.1-1.fc33.x86_64
libicu-67.1-3.fc33.x86_64
libicu-devel-67.1-3.fc33.x86_64
libmount-2.36-1.fc33.x86_64
libmount-devel-2.36-1.fc33.x86_64
libnghttp2-1.41.0-2.fc33.x86_64
libseccomp-2.5.0-1.fc33.x86_64
libselinux-3.1-2.fc33.x86_64
libselinux-devel-3.1-2.fc33.x86_64
libsemanage-3.1-2.fc33.x86_64
libsepol-3.1-3.fc33.x86_64
libsepol-devel-3.1-3.fc33.x86_64
libsmartcols-2.36-1.fc33.x86_64
libstdc++-10.2.1-1.fc33.x86_64
libuuid-2.36-1.fc33.x86_64
parted-3.3-4.fc33.x86_64
procps-ng-3.3.15-8.fc33.x86_64
python-srpm-macros-3.9-8.fc33.noarch
python3-3.9.0~b5-2.fc33.x86_64
python3-libs-3.9.0~b5-2.fc33.x86_64
redhat-rpm-config-165-1.fc33.noarch
rpm-4.16.0-0.beta3.2.fc33.1.x86_64
rpm-build-4.16.0-0.beta3.2.fc33.1.x86_64
rpm-build-libs-4.16.0-0.beta3.2.fc33.1.x86_64
rpm-libs-4.16.0-0.beta3.2.fc33.1.x86_64
sqlite-libs-3.32.3-2.fc33.x86_64
systemd-246~rc2-2.fc33.x86_64
systemd-libs-246~rc2-2.fc33.x86_64
systemd-pam-246~rc2-2.fc33.x86_64
systemd-rpm-macros-246~rc2-2.fc33.noarch
systemd-udev-246~rc2-2.fc33.x86_64
util-linux-2.36-1.fc33.x86_64
xfsprogs-5.7.0-1.fc33.x86_64
xxhash-libs-0.8.0-1.fc33.x86_64
The ocaml package is the same in both. Any ideas on what to check are
greatly appreciated. Regards,
--
Jerry James
http://www.jamezone.org/
3 years, 9 months
