https://qa.debian.org/excuses.php?package=glib2.0 says, among other
things:

But https://piuparts.debian.org/sid/source/g/glib2.0.html says that all
binary packages were successfully tested, except for the udeb (which as
far as I know is excluded from piuparts testing).

https://piuparts.debian.org/testing2sid/source/g/glib2.0.html also looks
good.

Is this a problem with the migration machinery, or is there something
I'm not seeing that needs to be addressed in glib2.0?

Thanks,
    smcv

Hi,


Last time we had something like this (bug #1102538) was when we had
older/cruft versions still around in unstable (I think that's a
(unfiled?) piuparts bug) that olasd has on his radar.

Paul

glib2.0 appears to be stuck again:

https://qa.debian.org/excuses.php?package=glib2.0

Thank you,
Jeremy Bícha

Control: affects -1 src:glib2.0
https://qa.debian.org/excuses.php?package=glib2.0

Thank you,
Jeremy Bícha

glib2.0 is stuck again:
https://qa.debian.org/excuses.php?package=glib2.0

Thank you,
Jeremy Bícha

Hi,


Added a hint again. And I cloned this bug to get it tracked on the
piuparts.debian.org bug list.

@Nicolas, I'm pretty sure you are aware of the issue, but I didn't spot
it on the tracker: the data that britney2 gets from piuparts sometimes
reports failure because of cruft versions. We've been needing to help
glib2.0 for each upload last couple of months.

Paul

I've asked the ftp team to remove the old libglib2.0-0 binary package
(#1125096) which is depended on by old xpra binaries (#1125101) and I'm
hoping that will unblock src:glib2.0 a little more permanently.

     smcv

That removal happened and glib2.0 no longer is having migration
difficulties from piuparts.

I don't know if we still need a release.debian.org bug to track the
underlying issue or if the piuparts.debian.org bug is sufficient.

Thank you,
Jeremy Bícha