Created attachment 1902246 [details]
build.log

file build.log too big, will only attach last 32768 bytes

Created attachment 1902247 [details]
root.log

file root.log too big, will only attach last 32768 bytes

Created attachment 1902248 [details]
state.log

What is the compiler version?

Looking a build issue:

testsuite/vec_pwr9_dummy.c:1036:3: error: '__builtin_vsx_scalar_test_data_class_dp' requires the '-mcpu=power9' and '-mvsx' options

My configure provides (the required):

-mcpu=power9 -mfloat128 -m64 -O3

But some other script is adding:

-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mcpu=power8 -mtune=power8 -fasynchronous-unwind-tables -fstack-clash-protection

It is the trailing (and gratuitous) "-m64 -mcpu=power8 -mtune=power8" causing the error (last command line target wins :-/ )

The testsuite/vec_pwr9_dummy.c requires the -mcpu=power9 target to compile correctly and my configure goes to extreme lengths to make this so.

So who/what is adding to extra compile options. Need to remove (at least) the "-O2 -mcpu=power8 -mtune=power8" bits to fix this.

optflags in the redhat-rpm-macros package sets this. See:

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags

I think fedora still supports power8, so I don't know that power9 specific code is acceptable here. 

Adding Dan Horak for more input.

The package itself should build with the Fedora default flags, it fails in the testsuite where it explicitly asks for "power9", which is acceptable IMO. The build failure is an outcome of https://fedoraproject.org/wiki/Changes/SetBuildFlagsBuildCheck, I believe. Let me look closer ...

I think we are seeing multiple issues here
- pveclib doesn't build/compile on Fedora 36 when doing just "configure && make"
  -> this might be related to https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition

- due the special nature of pveclib I think it is OK to remove the -mcpu options from the distro compiler flags, it can be done either by editing the flag variable in the spec or more cleanly by

diff --git a/pveclib.spec b/pveclib.spec
index 2ee98e9..4488062 100644
--- a/pveclib.spec
+++ b/pveclib.spec
@@ -39,6 +39,8 @@ So far only constant vectors used in conversions.
 %autosetup
 
 %build
+%define __cflags_arch_ppc64le %{nil}
+
 %{?el7:source /opt/rh/devtoolset-9/enable}
 %configure --docdir=%{_docdir}/%{name}
 %make_build


Steven, do you have access to a ppc64le system running F-36? If not, you can use the one from https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers

This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle.
Changing version to 37.

Sorry I have been busy in the real world and could not address this until now.

From my perspective this is a build system error. The Build system is applying CFLAGS that it did not before and should not ever.

PVECLIB has to build for multiple -mcpu targets. Yes I know that power8 is the default for ppcle64. I was there! It also needs to build for power9 and power10. Power7 is Big Endian only, so is not an issue for fedora, but might be for el7?

This both as a compile test (verify that the compiler will not fail for non-default targets). And to build power8/9/10 specific code as for IFUNC dynamic selection.

The sources testsuite/vec_pwr9_dummy.c and testsuite/vec_pwr10_dummy.c are compile tests.

The src/vec_int512_runtime.c is compiled multiple times for different targets. The next release of PVECLIB with add more code like this for float128.

Putting -mcpu=power8 in the configure CFLAGS interferes with both.

Also adding -O2 to CFLAGS is very bad. I also need to eliminate this.

(In reply to Dan Horák from comment #7)
> I think we are seeing multiple issues here
> - pveclib doesn't build/compile on Fedora 36 when doing just "configure &&
> make"
>   -> this might be related to
> https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition
> 
> - due the special nature of pveclib I think it is OK to remove the -mcpu
> options from the distro compiler flags, it can be done either by editing the
> flag variable in the spec or more cleanly by
> 
> diff --git a/pveclib.spec b/pveclib.spec
> index 2ee98e9..4488062 100644
> --- a/pveclib.spec
> +++ b/pveclib.spec
> @@ -39,6 +39,8 @@ So far only constant vectors used in conversions.
>  %autosetup
>  
>  %build
> +%define __cflags_arch_ppc64le %{nil}
> +
>  %{?el7:source /opt/rh/devtoolset-9/enable}
>  %configure --docdir=%{_docdir}/%{name}
>  %make_build
> 
> 
> Steven, do you have access to a ppc64le system running F-36? If not, you can
> use the one from
> https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers

I think I have a Fedora 36 partition on a P8 box. I'll check.

I have access to power9 at OSU but not fedora. 

Power 10 is still simulator based. But hardware is coming. I think I am in the queue for OSU and Travis CI.

Ok I now have a Fedora 36 on PowerPC64le. Of course the upgrade from 35 went sideways due to disk constraints...

Now I have to refresh credentials and remember how to use fedpkg, it has been a while ...

I really hate it when I spend 20 minutes careful typing then loose it all because 1 mistake

I am unsure how the package version numbering works.

Looking at: https://koji.fedoraproject.org/koji/packageinfo?packageID=29760

I see both pveclib-1.0.4.4-8.fc36 and pveclib-1.0.4.4-9.fc37
Since the latter failed I assume that only that version needs to be fixed.

Reading: https://github.com/i386x/pubdocs/blob/master/fedpkg-HOWTO.md

It suggested that I: "fedpkg clone <package>" 

But unsure if I and to update pveclib-1.0.4.4-9.fc37 or create pveclib-1.0.4.4-10.fc37

Is this detail spelled out in <package> on the clone or magic in the pveclib.spec file?

I would like some clarity and coaching (with exact spellings) before I blunder too far.

Actually earlier: https://github.com/i386x/pubdocs/blob/master/fedpkg-HOWTO.md

says: "Fork the package's repo."

Which implies "fedpkg fork" which assumes that I already have a fedpkg clone or chechout?

(In reply to Steven Jay Munroe from comment #13)

> But unsure if I and to update pveclib-1.0.4.4-9.fc37 or create
> pveclib-1.0.4.4-10.fc37

Considering that you're going to have to change the SPEC file, I'd just bump the Release number to 10,
updating the ChangeLog etc.

I think this is aligned with the guidelines from: https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_simple_versioning

> Is this detail spelled out in <package> on the clone or magic in the
> pveclib.spec file?

Are you asking where the Release number is set? i.e.
https://src.fedoraproject.org/rpms/pveclib/blob/rawhide/f/pveclib.spec#_3

If that's the case, remember to set it in the Changelog too, e.g.:
https://src.fedoraproject.org/rpms/pveclib/blob/rawhide/f/pveclib.spec#_80

(In reply to Tulio Magno Quites Machado Filho from comment #15)
> (In reply to Steven Jay Munroe from comment #13)
> 
> > But unsure if I and to update pveclib-1.0.4.4-9.fc37 or create
> > pveclib-1.0.4.4-10.fc37
> 
> Considering that you're going to have to change the SPEC file, I'd just bump
> the Release number to 10,
> updating the ChangeLog etc.
> 
> I think this is aligned with the guidelines from:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/
> #_simple_versioning
> 
> > Is this detail spelled out in <package> on the clone or magic in the
> > pveclib.spec file?
> 
> Are you asking where the Release number is set? i.e.
> https://src.fedoraproject.org/rpms/pveclib/blob/rawhide/f/pveclib.spec#_3
> 
> If that's the case, remember to set it in the Changelog too, e.g.:
> https://src.fedoraproject.org/rpms/pveclib/blob/rawhide/f/pveclib.spec#_80

Thanks Tulio!

But I am still brain locked on "Fork the package's repo."

This text implies that I should do this by: "Login to https://src.fedoraproject.org/."

But I don't see and button to push there?

There is "fedpkg fork" command which I can only run on my F36 powerpc64le instance command line?

So which is it?

Hi Steven, https://docs.fedoraproject.org/en-US/package-maintainers/Package_Maintenance_Guide/ should be the proper guide to do package updates in Fedora. I will look closer in the morning.

Got to the "fedpkg local" stage.

But now a slight pause while I talk to the compiler folks about what GCC12 has done to scalar_test_data_class() built-in.

It seems to have regressed.

(In reply to Steven Jay Munroe from comment #18)
> Got to the "fedpkg local" stage.
> 
> But now a slight pause while I talk to the compiler folks about what GCC12
> has done to scalar_test_data_class() built-in.
> 
> It seems to have regressed.

Dan, I am also seeing unit test failures that I don't see outside fedpgk.
For example:
test_muludq vector multiply quadword, 256-bit product
vec_muludq 2:
        should be: fffffffffffffffffffffffffffffffe 00000000000000000000000000000001
               is: 0000000000000000ffffffffffffffff 00000000000000000000000000000001
vec_muludq 3:
        should be: 00000000000000000000000000000000 0000000000000000002386f26fc10000
               is: 0000000000000000ffffffffffffffff 0000000000000000002386f26fc10000

This looks like an "over optimization" where a necessary instruction was dropped.

I am suspicious of lto, is there a simple way, via a the spec file to drop lto?

Most of PVECLIB is inlined into the application anyway. The exception is the vec_int152_ppc runtime (which should be built just -O3) and the unit tests themselves. No need to built the unit tests lto.

As a distribution we want all packages to be built with a common set of flags for a consistent user experience, they are documented in https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/buildflags.md. But exceptions are possible for cases like pveclib.

# use project's compiler/linker flags for tests
%undefine _auto_set_build_flags
# disable LTO
%global _lto_cflags %nil
# don't use distro -mcpu/-mtune flags, they conflict with the use of IFUNC
%global __cflags_arch_ppc64le %nil
# filter out -O2 as we want to use -O3
%global optflags $(echo %optflags | sed -e 's/-O2//g')

if you put ^^ to the top of the specfile, then it should avoid the conflicting flags in the build. Feel free to reword the comments :-) With these options set/unset I see the same build error as in the upstream pveclib build with "configure && make" (for the v1.0.4.4 tagged code and in the master branch as well).


In file included from testsuite/vec_pwr9_dummy.c:38:
./pveclib/vec_f128_ppc.h: In function 'vec_all_isfinitef128':
./pveclib/vec_f128_ppc.h:537:3: error: invalid parameter combination for AltiVec intrinsic '__builtin_vec_scalar_test_data_class'
  537 |   return !scalar_test_data_class (f128, 0x70);
      |   ^~~~~~
...


With the "f128" issues please keep in mind that we switched the default in the compiler to the ieee128 standard from the classic ibm128 (https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition).

Now from the update process point of view
- I would recommend to work from the "rawhide" branch ("main" is an alias)
- working from F-36 should be OK in my opinion, the compiler hasn't changed much (see the changelog entries for the builds at https://koji.fedoraproject.org/koji/packageinfo?packageID=40)
- when things work locally (fedpkg local) then I would move to rawhide with "fedpkg mockbuild" (it will rebuild the local package in the rawhide environment)
- the last steps should be to commit the changes and doing an official build (git commit; git push; fedpkg build)

The gcc team is still looking into the vec_muludq and scalar_test_data_class regressions.

But also tripped over the vec_cpsgn() "fix" from 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101985

Looking like I will need a small source update to resolve (work around) the vec_cpsgn and scalar_test_data_class issues.

Bug reported and confirmed for GCC-12: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106755

I have a patch and in the process of merging upstream as stable/1.0.4-5.

Created attachment 1909394 [details]
Patch to resolve issues with GCC-12

Proposed changes:

The switch to GCC-12 exposed some latent issues in pveclib-1.0.4-4
1) The (accidental) typedef of __float128 over __ieee128 and the cast
of (vector unsigned int *) constants to (vector unsigned __int128 *)
seems to violate strict-aliasing. But this is not reported unless
-Wstrict-aliasing=2 is used. The result was silently generating
incorrect code. GCC PR 106755.
2) GCC-12 corrected a long latent problem with vec_cpsgn
(swapped operands). PVECLIB followed the implementation from
previous GCC versions (GCC <= 11). This broke vector float/double
unit tests. GCC PR 101984.
3) The implementation of IEEE Float128 is evolving and various types
(__float128, __ieee128, _Float128, ...) are highly dependent on the
compiler version/options used. The implementation (tries again) to
#define/typedef __binary128 to the float128 type that the compiler
supports. The API uses __binary128 and avoids _Float128.

	* src/pveclib/vec_f128_ppc.h (__binary128): Define/typedef to
	the quad-precision float type that the support supports.
	
	* src/pveclib/vec_f32_ppc.h (vec_copysignf32):
	Unless PVECLIB_CPSGN_FIXED is defined, avoid vec_cpsgn.
	* src/pveclib/vec_f64_ppc.h (vec_copysignf64):
	Unless PVECLIB_CPSGN_FIXED is defined, avoid vec_cpsgn.
	
	* src/testsuite/arith128_test_f32.c (test_float_cpsgn):
	Swap operands/results to match GCC12.
	* src/testsuite/arith128_test_f64.c (test_double_cpsgn):
	Swap operands/results to match GCC12.
	
	* src/testsuite/arith128_test_i128.c (test_muludq):
	Change local variable 'l' type to match vec_muludq parameter.
	(test_madduq)
	Change local variable 'l' type to match vec_madduq parameter.
	
	* src/testsuite/vec_f128_dummy.c: Replace all usage of type
	__Float128 with __binary128.

Ok some delay due real life priorities and git confusion.

Now have source update with new tag on: https://github.com/open-power-sdk/pveclib/tree/v1.0.4.5

So need to update the spec for new version make sure it pulls the new tag.

So testing locally with new source and spec file. Now need to move the new pveclib-1.0.4.5.tar.gz to the lookaside cache.

Tried: $ fedpkg new-sources pveclib-1.0.4.5.tar.gz
Could not execute new_sources: Request is unauthorized.

Do I need to renew my credential or something else?

fkinit seems to solve that problem. Sorry for the noise.

fedpkg new-sources pveclib-1.0.4.5.tar.gz
Uploading: pveclib-1.0.4.5.tar.gz
######################################################################## 100.0%
Source upload succeeded. Don't forget to commit the sources file

But now lint is unhappy:
============================ rpmlint session starts ============================
rpmlint: 2.2.0
configuration:
    /usr/lib/python3.10/site-packages/rpmlint/configdefaults.toml
    /etc/xdg/rpmlint/fedora.toml
    /etc/xdg/rpmlint/licenses.toml
    /etc/xdg/rpmlint/scoring.toml
    /etc/xdg/rpmlint/users-groups.toml
    /etc/xdg/rpmlint/warn-on-functions.toml
checks: 32, packages: 7

pveclib-debuginfo.ppc64le: W: unstripped-binary-or-object /usr/lib/debug/.dwz/pveclib-1.0.4.5-11.fc38.ppc64le
pveclib-debuginfo.ppc64le: W: unstripped-binary-or-object /usr/lib/debug/usr/lib64/libpvec.so.1.0.4-1.0.4.5-11.fc38.ppc64le.debug
pveclib-debuginfo.ppc64le: E: statically-linked-binary /usr/lib/debug/.dwz/pveclib-1.0.4.5-11.fc38.ppc64le
pveclib-static.ppc64le: E: static-library-without-debuginfo /usr/lib64/libpvecstatic.a
pveclib-debuginfo.ppc64le: E: shared-library-without-dependency-information /usr/lib/debug/usr/lib64/libpvec.so.1.0.4-1.0.4.5-11.fc38.ppc64le.debug
pveclib-debuginfo.ppc64le: W: no-documentation
pveclib-debugsource.ppc64le: W: no-documentation
pveclib-debuginfo.ppc64le: E: missing-PT_GNU_STACK-section /usr/lib/debug/.dwz/pveclib-1.0.4.5-11.fc38.ppc64le
pveclib-debugsource.ppc64le: E: incorrect-fsf-address /usr/src/debug/pveclib-1.0.4.5-11.fc38.ppc64le/src/decpowof2.c
pveclib-debuginfo.ppc64le: W: hidden-file-or-dir /usr/lib/debug/.dwz
pveclib-debuginfo.ppc64le: W: hidden-file-or-dir /usr/lib/debug/.dwz
pveclib.ppc64le: W: files-duplicate /usr/share/licenses/pveclib/LICENSE /usr/share/doc/pveclib/COPYING:/usr/share/licenses/pveclib/COPYING
pveclib-debuginfo.ppc64le: W: dangling-relative-symlink /usr/lib/debug/.build-id/6a/77c75b62513eb90a7ac1762f666cc821966a7f ../../../.build-id/6a/77c75b62513eb90a7ac1762f666cc821966a7f
 6 packages and 1 specfiles checked; 5 errors, 8 warnings, 5 badness; has taken 1.3 s 
Could not execute lint: Failed to execute command.

I can't tell is this some new requirement for fc38 or general requirements.

This was after I tried to remove the LTO and distro -mcpu/-mtune as suggester in commend #20

I seems to be associate with the extracting debuginfo but I can tell what is happening.

pveclib-debugsource.ppc64le: E: incorrect-fsf-address /usr/src/debug/pveclib-1.0.4.5-11.fc38.ppc64le/src/decpowof2.c

Can I assume that rpmlint is looking for this?

    http://www.apache.org/licenses/LICENSE-2.0

The other errors have me puzzled.

(In reply to Steven Jay Munroe from comment #29)
> pveclib-debugsource.ppc64le: E: incorrect-fsf-address
> /usr/src/debug/pveclib-1.0.4.5-11.fc38.ppc64le/src/decpowof2.c
> 
> Can I assume that rpmlint is looking for this?

Yes. But how are you seeing this if this file comes from libdfp and I don't get this error there.
How are you executing this test?

So, first: needinfo on extras-qa isn't going to do much. That address goes to /dev/null. :) 

On the rpmlint errors: 

pveclib-debuginfo.ppc64le: E: statically-linked-binary /usr/lib/debug/.dwz/pveclib-1.0.4.5-11.fc38.ppc64le

Does this binary need to be staticically linked? It doesn't seem it was even shipped in the previous package?

pveclib-static.ppc64le: E: static-library-without-debuginfo /usr/lib64/libpvecstatic.a

This package produces a -static subpackage, as long as the .a static library is in there, this should be fine.

pveclib-debuginfo.ppc64le: E: shared-library-without-dependency-information /usr/lib/debug/usr/lib64/libpvec.so.1.0.4-1.0.4.5-11.fc38.ppc64le.debug

You can run 'rpmlint -e errorname' and get more info. In this case: 
The listed shared library doesn't include information about which other
libraries the library was linked against.

I am not sure whats going on there. Might ask the devel list?

pveclib-debuginfo.ppc64le: E: missing-PT_GNU_STACK-section /usr/lib/debug/.dwz/pveclib-1.0.4.5-11.fc38.ppc64le

The binary lacks a PT_GNU_STACK section.  This forces the dynamic linker to
make the stack executable.

This is not good, but I have no idea how to fix it. 

pveclib-debugsource.ppc64le: E: incorrect-fsf-address /usr/src/debug/pveclib-1.0.4.5-11.fc38.ppc64le/src/decpowof2.c

This is in the header of that .c file. ie, src/decpowof2.c. You should ask upstream to update it, but it's not a big deal, it shouldn't block updating the package.

(In reply to Tulio Magno Quites Machado Filho from comment #30)
> (In reply to Steven Jay Munroe from comment #29)
> > pveclib-debugsource.ppc64le: E: incorrect-fsf-address
> > /usr/src/debug/pveclib-1.0.4.5-11.fc38.ppc64le/src/decpowof2.c
> > 
> > Can I assume that rpmlint is looking for this?
> 
> Yes. But how are you seeing this if this file comes from libdfp and I don't
> get this error there.
> How are you executing this test?

I pulled the v1.0.4-5 release from github then modified the spec file to point to it.

Then I used:
fedpkg local
fedpkg lint

I'll attach the spec file in sec.

Created attachment 1913037 [details]
pveclib.spec for v1.0.4-5

Comment on attachment 1913037 [details]
pveclib.spec for v1.0.4-5

Ooop wrong version. I'll have to fire up VM to get the latests.

(In reply to Kevin Fenzi from comment #31)
> So, first: needinfo on extras-qa isn't going to do much.
> That address goes to /dev/null. :) 
> 
> On the rpmlint errors: 
> 
> pveclib-debuginfo.ppc64le: E: statically-linked-binary
> /usr/lib/debug/.dwz/pveclib-1.0.4.5-11.fc38.ppc64le
> 
> Does this binary need to be staticically linked? It doesn't seem it was even
> shipped in the previous package?
> 
> pveclib-static.ppc64le: E: static-library-without-debuginfo
> /usr/lib64/libpvecstatic.a
> 
> This package produces a -static subpackage, as long as the .a static library
> is in there, this should be fine.
> 
> pveclib-debuginfo.ppc64le: E: shared-library-without-dependency-information
> /usr/lib/debug/usr/lib64/libpvec.so.1.0.4-1.0.4.5-11.fc38.ppc64le.debug
> 
> You can run 'rpmlint -e errorname' and get more info. In this case: 
> The listed shared library doesn't include information about which other
> libraries the library was linked against.
> 
> I am not sure whats going on there. Might ask the devel list?

This might be a dependency on libdfp. But I would not expect that as all targets for this build have hardware Decimal Floating-point.
> 
> pveclib-debuginfo.ppc64le: E: missing-PT_GNU_STACK-section
> /usr/lib/debug/.dwz/pveclib-1.0.4.5-11.fc38.ppc64le
> 
> The binary lacks a PT_GNU_STACK section.  This forces the dynamic linker to
> make the stack executable.
> 
> This is not good, but I have no idea how to fix it. 
> 

Again this should not happen for ppc64le. We left trampolines and executable stack behind with PPC32.

It would help if someone could tell me what rpmlint is looking for here? (nm with some options?)

> pveclib-debugsource.ppc64le: E: incorrect-fsf-address
> /usr/src/debug/pveclib-1.0.4.5-11.fc38.ppc64le/src/decpowof2.c
> 
> This is in the header of that .c file. ie, src/decpowof2.c. You should ask
> upstream to update it, but it's not a big deal, it shouldn't block updating
> the package.

Just an over-site for an old file. This is fixed upstream but not sure this is worth spinning another v1.0.4 point release.

Created attachment 1913039 [details]
Latest spec file

This is the pveclib.spec file i am using for these fedpkg builds

I have asked the toolchain (compiler/as/ld) team for help with missing-PT_GNU_STACK-section issue.

When I build fedpkg local on fedora 26, No executables that I can find are execstack enabled.

[sjmunroe@homer54 src]$ execstack -q .libs/libpvecstatic.so.0.0.0
- .libs/libpvecstatic.so.0.0.0
[sjmunroe@homer54 src]$ execstack -q .libs/libpvec.so.1.0.4
- .libs/libpvec.so.1.0.4
[sjmunroe@homer54 src]$ execstack -q .libs/vec_dummy 
- .libs/vec_dummy
[sjmunroe@homer54 src]$ execstack -q pveclib_test
- pveclib_test


So the problem is either with the upstream toolchain (27/rawhide) or with rpmlint tool itself.

A family health issue has forced a change in my priorities.

Tulio has volunteered to help with this.

(In reply to Kevin Fenzi from comment #31)
> pveclib-debuginfo.ppc64le: E: missing-PT_GNU_STACK-section
> /usr/lib/debug/.dwz/pveclib-1.0.4.5-11.fc38.ppc64le
> 
> The binary lacks a PT_GNU_STACK section.  This forces the dynamic linker to
> make the stack executable.

Nope.  ppc64 defaults to a non-exec stack if PT_GNU_STACK is missing.
See glibc DEFAULT_STACK_PERMS for ppc64.

> This is not good, but I have no idea how to fix it. 

Fix the buggy tool that is reporting an error.

That would be rpmlint.

But it is reported against the debuginfo subpackage, so it's harmless IMO.

(In reply to Dan Horák from comment #41)
> But it is reported against the debuginfo subpackage, so it's harmless IMO.

Harmless but still confusing. The tool should be fixed.

Opened https://bugzilla.redhat.com/show_bug.cgi?id=2133061

This issue has been fixed in rawhide with pveclib-1.0.4.5-11.fc38.
A backport is pending for f37.

FEDORA-2022-ab92a530a9 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-ab92a530a9

FEDORA-2022-ab92a530a9 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-ab92a530a9`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-ab92a530a9

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2022-ab92a530a9 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.