Re: libgdbm transition
Hi Dmitry
> FAIL camldbm_1.0-2.dsc | PATCH
> FAIL courier_0.73.1-1.6.dsc
> FAIL freeradius_2.2.8+dfsg-0.1.dsc | PATCH
> FAIL ifmail_2.14tx8.10-22.dsc | PATCH
> FAIL nis_3.17-34.dsc | FTPFS pre-history debhelper
> FAIL ntop_5.0.1+dfsg1-2.1.dsc | FTBFS issues with rrd
> FAIL ocsigenserver_2.4.0-1.dsc | FTPFS issues with FindLib
> FAIL perdition_2.1-2.dsc | PATCH
> FAIL python3-stdlib-extensions_3.4.2-1.dsc | FTBFS purely virtual
> FAIL qsf_1.2.7-1.dsc | PATCH
> FAIL ruby2.3_2.3.1-5.dsc | FTBFS testsuite
> FAIL sortmail_2.4-2.dsc | PATCH
>It looks as MBF, but I would like someone more experienced to give advice. Also, I am really
>surprised by number of FTBFS packages (not due my libgdbm changes). We do not have automation
>to rebuild packages and file FTBFS bugs, do we?
it isn't an MBF to me. MBF is when >10 packages are affected by the same bug.
Here you have ~5 packages affected by gdbm transition, and ~8 packages affected by other reasons.
So, try to rebuild packages on unstable without picking up gdbm, open RC bugs against them
(like automatic rebuilds do), and then open bugs for the remaining packages if they FTBFS with new gdbm
with patches/severity important.
And when ready open a bug against release.d.o asking a transition slot.
I don't care too much for packages failing for unrelated reasons, because they will probably be kicked
away since the FTBFS RC bugs.
cheers,
G.
Reply to: