[Piuparts-devel] Bug#657740: need a better solution for handling affects
Andreas Beckmann
debian at abeckmann.de
Sat Jan 28 13:27:19 UTC 2012
Package: piuparts
User: debian-qa at lists.debian.org
Usertags: piuparts.d.o
Hi,
while the affects handling I introduced recently fixes some problems, it
is not perfect for the more general cases.
To recall the problem: piuparts test of failing-package fails, but the
problem is actually in a different package: buggy-package (and there is
some (indirect) dependency of failing-package in buggy-package). The
piuparts test of buggy-package by itself succeeds (probably because it
is not getting "used" in a way that fails).
The current solution of setting affects works fine for the case where
buggy-package and failing package are part of the same source, but in
that case a
Package: buggy-package,failing-package
Version: $version
would work as well.
In the general case where buggy-package is from a different source than
failing-package we usually want to do the following
* report bug against buggy-package
* mark failing-package as "affected" by that bug
* wait for new (hopefully fixed) version of buggy-package
* reschedule all failed-package that were affected by that bug
Looks like we need another category "affected" for logs that need to be
ignored by the humans doing log processing, but that gets rescheduled
regularily to see if buggy-package has been fixed.
Currently I have no good idea how to achieve this. The current system
fails to do this properly because setting affects + found statically
moves a log to bugged where it is no longer considered until the next
upload or manual reschedule of bugged/*.log happens.
(For binaries of the same source this is not an issue - fixing
buggy-package with an upload causes a new upload of failing-package,
too).
Abusing usertags is not an option due to the restricted charset ...
$ bts user debian-qa at lists.debian.org . usertag 656291 affects_failing/1.2.3+x~_by_buggy/2:3.4-5 .
bts usertag: "affects_failing/1.2.3+x~_by_buggy/2:3.4-5" contains characters other than alpha-numerics, '@', '.', '+', and '-'.
Hmm, we could use base64 encoded info:
$ bts user debian-qa at lists.debian.org . \
usertag 656291 piuparts-affected-$(echo failing-package/1.2.3+x~ | base64 -w0 | tr = @) . \
usertag 656291 piuparts-affector-$(echo buggy-package/2:3.4-5 | base64 -w0 | tr = @) .
piuparts-analyze could get the usertags and compare piuparts-affected
with the current package and check whether piuparts-affector is
available in the current distribution ...
Andreas
More information about the Piuparts-devel
mailing list