Hi Sorry for the delay in follow-up, but RL. On 07-11-2019 15:20, Christoph Berg wrote: > Here's the situation as of now, looking at https://qa.debian.org/excuses.php?package=postgresql-common Just wondering, but does that cover the full situation? > Issues preventing migration: > > Fix waiting in NEW: > > autopkgtest for pg-rage-terminator/0.1.7-2: amd64: Regression ♻ > autopkgtest for postgresql-multicorn/1.3.4-18-g99ea772-2: amd64: Regression ♻ > > Fix just uploaded: > > autopkgtest for check-postgres/2.24.0-3: amd64: Regression ♻ > autopkgtest for pgsphere/1.1.1+2018.10.13-1: amd64: Regression ♻ (Fix in postgresql-common) > > Need fixing upstream (and should be ignored and/or removed from > testing until that happens): > > autopkgtest for cstore-fdw/1.6.2-1: amd64: Regression ♻ > autopkgtest for hypopg/1.1.2-1: amd64: Regression ♻ > autopkgtest for pgaudit/1.4.0-1: amd64: Regression ♻ > autopkgtest for pglogical/2.2.2-1: amd64: Regression ♻ > autopkgtest for pglogical-ticker/1.4.0-1: amd64: Regression ♻ > autopkgtest for repmgr/5.0.0-2: amd64: Regression ♻ > autopkgtest for wal2json/1.0-5: amd64: Regression ♻ Are the Debian PostgreSQL Maintainers the maintainers for all the above packages and are they suggesting to drop the packages from testing? How big is the list of reverse dependencies? > To be investigated: > > autopkgtest for postgresql-q3c/1.8.0-1: amd64: Regression ♻ Have you done so in the mean time? > These are OK and need to migrate in parallel with postgresql-common so > the list of supported PG versions is in sync: How is this enforced? If it is by dependency, the autopkgtests would be testing the right combination. At least for either postgresql-common or the reverse dependency, but I am seeing a lot of these packages have failing autopkgtests on their own. > autopkgtest for omnidb/2.16.0+ds-2: amd64: Regression ♻ > autopkgtest for pg-checksums/1.0-1: amd64: Regression ♻ > autopkgtest for pg-repack/1.4.5-2: amd64: Regression ♻ > autopkgtest for pg-similarity/1.0-2: amd64: Regression ♻ ^ This one seems to be in NEW as well. > autopkgtest for pgagent/4.0.0-5: amd64: Regression ♻ > autopkgtest for pgpool2/4.0.6-1: amd64: Regression ♻ > autopkgtest for pgrouting/2.6.3-1: amd64: Regression ♻ ^ I'm not seeing a new version of this one in unstable. There is one in experimental, not sure if you mean that one. > autopkgtest for postgis/3.0.0+dfsg-1: amd64: Regression ♻ > autopkgtest for rdkit/201903.1-2: amd64: Regression ♻ ^ This one seems to be in NEW as well. > autopkgtest for slony1-2/2.2.8-1: amd64: Regression ♻ > > > So the ideal solution would be to have this last bunch tested+migrated > along with postgresql-common. (If that's not possible, one possible > solution could be to just force postgresql-common into testing, and have > that bunch follow on its own because the the tests should pass.) It's not clear to me what this would mean for the status of testing. Most failures seem to hint at problems once we have postgresql-common in testing without all the other packages. And as the autopkgtests show that those are not all forced together, what happens in testing if *only* postgresql-common migrates to testing? I mean in "real" performance, not just autopkgtest. > Most of these also need amd64 "rebuild on buildd" binnmus. Do you want > me to compile a list, or do you have that at hand anyway? I will handle all the ones in your list with only "Not built on buildd: arch amd64 binaries uploaded by myon" shortly. But you'll have to take care of the ones that also have "Not built on buildd: arch all binaries uploaded by myon, a new source-only upload is needed to allow migration". Paul
Attachment:
signature.asc
Description: OpenPGP digital signature