Toshio Kuratomi wrote:
Florian Festi wrote:
> Please add the packages you changed or plan to change to
>
https://fedoraproject.org/wiki/Features/NoarchSubpackages/PackagesChanged
> Put the later in parenthesis. That way it will be easier to justify a
> release note entry and to argue that the Feature is (at least a bit)
> finished.
>
I explored what would be changed if we enabled a lenient-hash check on
these files I discovered these things:
1) Asking reviewers to check this is pretty hard. I'll add the steps at
the end.
It's actually very easy to script given a few calls to the xmlrpc interface.
2) If reviewers are expected to do this, we need to get our user
interface changes to rpmdiff merged upstream. rpmlint's rpmdiff can
only ignore timestamp. Reviewers are going to want to have something
like lenient-hash as well.
3) devhelp documentation should be marked as %doc
4) It might be reasonable for --lenient-hash to not check
f.startswith('/usr/share')... I'm on the fence about this.
5) Most of these would have checked fine even if we used a full hash
check instead of lenient
6) I discoverd a package with architecture specific differences.
Luckily, it's just a problem in documentation.
Check results with:
./rpmdiff.mine -iS -iT --lenient-hash
Script attached.
I noticed your lenient-hash changes special-case .pyc and .pyo files.
It's this kind of special-casing that worries me. What about other
types of bytecode, Java, OCaml, haskell? What about firmwares? What
about game datafiles? We can't be having build system outages every
time we realize there's another special-case we need to handle in the
rpmdiff script. I think we need to trust packagers to review their
packages and only convert to noarch where appropriate.
And if someone wants to setup a more rigorous package checker outside of
the build system and file bugs against packages with problems, noarch or
otherwise, more power to them.
Summary:
23 packages listed
14 actually built with noarch subpackages
1 false positive (dbus) (files should have been marked %doc)
1 actual problem detected (dbus)
13 problem free runs
So the net change would have been one package. Not sure if the
maintainer would have caught the noarch vs arch specific difference as
it is an error within documentation and they might have just added %doc
without exploring further.
ConsoleKit: package has failed rebuild
dbus: package has false positives that would be fixed by marking devhelp
as %doc
- the dbus documentation is not arch-independent:
* /usr/share/devhelp/books/dbus/api/dbus-arch-deps_8h-source.html
* /usr/share/devhelp/books/dbus/api/group__DBusTypes.html
em8300: no false positives
evolution: no false positives
evolution-data-server: No false positives
festival: package has failed rebuild
gdl: failed rebuild
gmt: No false positives
gnome-games: No false positives
gnome-session: Latest version reverts noarch subpackage
gtk2: No false positives
javasqlite: not built with noarch subpackage
kst: not rebuilt with noarch subpackage
libtheora: no false positives
libxcb: no false positives with --lenient-hash
* There is a harmless difference in two png files used in documentation
ncl: no false positives
nted: failed rebuild
PackageKit: no false positives
paraview: no false positives
PolicyKit: no false positives with --lenient-hash
pygobject2: hasn't been rebuilt
pygtk2: no false positives
xemacs: hasn't been rebuilt
Steps a reviewer would have to take:
1) Submit SRPM as a scratch build in koji.
2) Go to the package page
3) Go to the build page for the scratch build.
4) Go to the task page for the build
5) For at least two dissimilar architectures, click on the task for that
arch.
6) For each of those tasks, download any noarch packages that were built
(minimum 2 clicks)
7) run /usr/bin/rpmdiff --ignore-times on each of those pairs of packages.
8) For each of the many differences, decide whether the problem is an
actual problem.
-Toshio