On തിങ്കള് 05 ഡിസംബര് 2016 02:48 വൈകു, Holger Levsen wrote: > On Mon, Dec 05, 2016 at 01:52:44PM +0530, Pirate Praveen wrote: >>> I do not buy that argument. piuparts failures are generally filed as RC >>> bugs. > > there's a notable exception to this: "leaving files behind after > purge"-bugs and also "fails to purge"-bugs are only considered > important, even though the test may fail. > > see https://piuparts.debian.org/templates/mail/ for the templates we are > using. Neils, Does this convince you to allow the migration? >> 12m55.1s ERROR: FAIL: Package purging left files on system: > > however, this is not the real problem with gitlab… > > looking at > https://piuparts.debian.org/sid/fail/gitlab_8.13.6+dfsg2-1.log I see: > > 12m12.4s ERROR: WARN: Processes are running inside chroot: > 12m20.4s ERROR: WARN: Broken symlinks: > 12m55.1s ERROR: FAIL: Package purging left files on system: > > of which I'd consider the processes left running in the chroot to be > seriously broken. It is a WARN and not FAIL. You can't suddenly change meaning of these just before the release to make it RC. > and, btw, #814393 filed against piuparts.d.o "Run redis service for packages > depending on redis-server like gitlab" is *no* reason for gitlab failing > to install. gitlab's postinst MUST exit cleanly even if there is no > redis service available. > (I'm pondering to close #814393 as wontfix.) Its ironic that a software designed to test packages forces maintainers to not ensure the package is working correctly. A running redis-server is required to test gitlab is installed correctly and can use the redis server. piuparts should adapt to requirements of packages, not the other way around.
Attachment:
signature.asc
Description: OpenPGP digital signature