Agreed, the test seems too brittle. Can we just turn the test off for now?

https://github.com/Debian/debiman/issues/127 tracks updating mdocml on
manpages.d.o,
which I intend to do as time permits.

I wonder whether it makes sense to have debiman packaged in Debian itself,
though.
Personally, I’m not maintaining that package, and I’m not sure if there are
any users of the package.

Anyway, any help welcome to sort this out on the package level.
I don’t have time to help, sorry:
https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/

On Tue, Feb 23, 2021 at 12:45 PM Ivo De Decker <iv...@debian.org> wrote:

> Control: reassign -1 debiman 0.0~git20200217.fc82521-1
>
> Hi,
>
> On Thu, Feb 18, 2021 at 07:31:32AM +0100, Paul Gevers wrote:
> > With a recent upload of mdocml the autopkgtest of debiman fails in
> > testing when that autopkgtest is run with the binary packages of mdocml
> > from unstable. It passes when run with only packages from testing. In
> > tabular form:
>
> [...]
>
> > === CONT  TestToHTML/i3lock
> >     convert_test.go:92: unexpected conversion result: (diff from want →
> > got):
> >         --- /tmp/debiman-849248825    2021-02-18 04:13:33.034473409 +0000
> >         +++ /tmp/debiman-376692162    2021-02-18 04:13:33.034473409 +0000
> >         @@ -7,67 +7,76 @@
> >            </tr>
> >          </tbody></table>
> >          <div class="manual-text">
> >         -<div class="Pp"></div>
> >         -<div class="Pp"></div>
> >         +<p class="Pp"></p>
> >         +<p class="Pp"></p>
> >         +<section class="Sh">
> [...]
>
> Hard-coding the exact html output of a dependency that generates html, and
> expecting that not to change doesn't seem like a robust way to test it
> functionality, so I think it's clear that the bug is in the autopkgtest of
> debiman. It's perfectly acceptable for mdocml to generate different html
> output to represent the data (whether the upload of the new upstream
> version
> should have happened during the soft freeze is a different matter, but
> that's
> unrelated to this bug).
>
> Testing that the html is valid, and contains certain parts of the input
> might
> be a more useful test.
>
> Cheers,
>
> Ivo
>


-- 
Best regards,
Michael

Reply via email to