For two reviews I did recently, I noticed fedora-review complaining about directories not being owned:
[ ]: Package requires other packages for directories it uses. Note: No known owner of /usr/lib/python3.12, /usr, /usr/share/doc, /usr/share, /usr/lib/python3.12/site-packages, /usr/share/licenses, /usr/lib [ ]: Package must own all directories that it creates. Note: Directories without known owners: /usr/lib/python3.12, /usr, /usr/share/doc, /usr/share, /usr/lib/python3.12/site-packages, /usr/share/licenses, /usr/lib
That's a pretty misleading and worrying message, since those directories shouldn't be owned by individual packages.
The reviews were created by fedora-review 0.10.0 (e79b66b) and can be found on copr:
https://download.copr.fedorainfracloud.org/results/gui1ty/reviews/fedora-rawhide-x86_64/07165139-python-snakemake-storage-plugin-ftp/fedora-review/review.txt https://download.copr.fedorainfracloud.org/results/gui1ty/reviews/fedora-rawhide-x86_64/07165135-python-snakemake-executor-plugin-slurm/fedora-review/review.txt
More precisely, these directories are owned either by filesystem or by the system Python packages, upon which the package under review correctly depends (it’s a very normal and boring modern Python library package).
filesystem
I’ve seen the bogus complaints about Python-owned directories in several recent reviews, but the complaints about filesystem-owned ones are new to me too.
Spurious complaints appear in Rust package reviews, too, e.g. in https://bugzilla.redhat.com/show_bug.cgi?id=2274366:
Note: No known owner of /usr/share/cargo/registry, /usr, /usr/share, /usr/share/cargo
Noticed this as well in https://bugzilla.redhat.com/show_bug.cgi?id=2299655
[ ]: Package requires other packages for directories it uses. Note: No known owner of /usr/share/doc, /usr/share/man, /usr/src/debug, /usr, /usr/src, /usr/share, /usr/lib, /usr/bin, /usr/share/licenses [ ]: Package must own all directories that it creates. Note: Directories without known owners: /usr/share/doc, /usr/share/man, /usr/lib, /usr/src/debug, /usr, /usr/src, /usr/share, /usr/bin, /usr/share/licenses
In this case it's a false positive as repoquery --requires vhost-device-vsock-0.2.0-1.fc41.x86_64.rpm --tree shows:
repoquery --requires vhost-device-vsock-0.2.0-1.fc41.x86_64.rpm --tree
vhost-device-vsock-0:0.2.0-1.fc41.x86_64 \_ glibc-0:2.39.9000-35.fc41.x86_64 [5: basesystem, libgcc(x86-64), glibc-common = 2.39.9000-35.fc41, glibc-langpack = 2.39.9000-35.fc41, (glibc-gconv-extra(x86-64) = 2.39.9000-35.fc41 if redhat-rpm-config)] | \_ basesystem-0:11-21.fc41.noarch [2: filesystem, setup] | | \_ filesystem-0:3.18-23.fc41.x86_64 [1: setup] ...
and filesystem package owns above listed directories.
glibc is not explicitly required within the spec file but the requirement is automatically generated. May that be the issue?
glibc
After digging a bit into it it seems caused by the usage of -qn option while running mock for running repoquery via --pm-cmd which suppresses completely the output of the command.
-qn
repoquery
--pm-cmd
I think this is a change of behaviour in mock that requires an update of deps module. Please note
deps
$ mock -r fedora-rawhide-x86_64 --no-cleanup-after --no-clean -qn --enable-network --pm-cmd -- repoquery -q -C --whatprovides "libc.so.6(GLIBC_2.9)(64bit)"
ends up with nothing on the output while:
$ mock -r fedora-rawhide-x86_64 --no-cleanup-after --no-clean -qn --enable-network --shell 'dnf5 repoquery -q -C --whatprovides "libc.so.6(GLIBC_2.9)(64bit)"' glibc-0:2.39.9000-35.fc41.x86_64
correctly outputs glibc-0:2.39.9000-35.fc41.x86_64 as expected.
glibc-0:2.39.9000-35.fc41.x86_64
Proposed a fix in #521
#521 has been merged, I think we can close this one.
Log in to comment on this ticket.