Holy mother of complexity! They don't make autopkgtest easy to
understand, do they? And no virtual driver for pbuilder/cowdancer,
just to put an extra nail in my wrist (if I may use a seasonal
metaphor.)
Anyway, I believe the upload I've just pushed has correct autopkgtest
support, explicitly
> if the source has such an extensive test suite, doesn't that (at
least partially) qualify for autopkgtesting? Remember that packages that
have substantial testing with autopkgtest *of the installed binaries*
currently don't need to request unblocks if their not a key package.
I think so, yes.
Hi Barak
On 27-03-2021 22:09, Barak A. Pearlmutter wrote:
> I was preparing one, but upstream released an official 2.15 release.
> Which has an exhaustive test suite enabled in the build and passes (by
> upstream standards; there are scary messages but they're expected) on
> all architectures.
>
I was preparing one, but upstream released an official 2.15 release.
Which has an exhaustive test suite enabled in the build and passes (by
upstream standards; there are scary messages but they're expected) on
all architectures.
The delta is too big to sensibly check. But it's a proper release
Control: tags -1 + moreinfo
On 2021-03-22 16:37:43 +, Barak A. Pearlmutter wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
>
> Please unblock package fossil
>
> [ Reason ]
>
> Marked for autoremoval due to #985124.
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package fossil
[ Reason ]
Marked for autoremoval due to #985124.
The issue was fixed upstream. Given the nature of the package, I think
tracking their release candidate is
6 matches
Mail list logo
