Bug#941078: transition: postgresql-12
Re: Paul Gevers 2019-11-13 > Scheduled. Thanks! Not sure why my last list missed a few, but here's three more: postgresql-multicorn pldebugger first-last-agg Christoph
Bug#941078: transition: postgresql-12
Hi On 12-11-2019 10:52, Christoph Berg wrote: > Here's the list of remaining packages that need a "rebuild on buildd" > binnmu: > > bgw-replstatus > ip4r > jsquery > orafce > pg-cron > pg-dirtyread > pgextwlist > pgfincore > pgmemcache > pg-partman > pgq > pg-qualstats > pg-rage-terminator > pg-rational > pg-similarity > pg-snakeoil > pgsql-asn1oid > pg-stat-kcache > plr > postgresql-debversion > postgresql-hll > postgresql-mysql-fdw > postgresql-numeral > postgresql-periods > postgresql-pgmp > postgresql-pllua > postgresql-plproxy > postgresql-plsh > postgresql-prioritize > postgresql-rum > postgresql-unit > powa-archivist > prefix > preprepare > toastinfo > vip-manager Scheduled. Paul signature.asc Description: OpenPGP digital signature
Bug#941078: transition: postgresql-12
Re: Paul Gevers 2019-11-09 <10dd87e2-5aa6-84eb-a41a-b9a038dd6...@debian.org> > ^ This just got uploaded moments ago, binNMU'ed on the buildd. Hi Paul, thanks for handling this. Here's the list of remaining packages that need a "rebuild on buildd" binnmu: bgw-replstatus ip4r jsquery orafce pg-cron pg-dirtyread pgextwlist pgfincore pgmemcache pg-partman pgq pg-qualstats pg-rage-terminator pg-rational pg-similarity pg-snakeoil pgsql-asn1oid pg-stat-kcache plr postgresql-debversion postgresql-hll postgresql-mysql-fdw postgresql-numeral postgresql-periods postgresql-pgmp postgresql-pllua postgresql-plproxy postgresql-plsh postgresql-prioritize postgresql-rum postgresql-unit powa-archivist prefix preprepare toastinfo vip-manager Christoph
Bug#941078: transition: postgresql-12
Hi all, For the record, Christoph and I had the following discussion on IRC today. Paul Myon: I am starting to wonder, are all those PostgreSQL-11 based packages broken with the postgresql-common update, or just their autopkgtests if the latter is the case, I don't mind ignoring it all if you file RC bugs against them complaining about their autopkgtest being not robust against version bumps of PostgreSQL in postgresql-common elbrus: it's just the tests, because the wrong set of PostgreSQL versions is tested please file the bugs and I'll ignore the failures (except for pg-repack which is a real problem) you want 20+ RC bugs? yes which will fix themselves after 1 day when the packages transition? autopkgtests are clearly broken ehm, sorry, we are thinking differently -*- elbrus stares at https://sources.debian.org/src/hypopg/1.1.2-1/debian/tests/control/ that says postgresql-contrib-11 the problem will disappear once pg-common is in testing so why can't autopkgtest (the program) not figure it out? elbrus: ok that's really broken, but that's not the normal case ok, so I checked the wrong example :( can you please explain then why all those autopkgtest hint at regressions? sorry I'm only starting to grasp the full picture, in the past this was no problem at all and the transition went without RT intervention -*- elbrus doesn't know how this PostgreSQL world is set-upped the new autopkgtests (which I appreciate) really made this 2 orders of magnitude more complicated Myon: that everything went smooth in the past doesn't mean there are no (versioning) bugs autopkgtest is catching a lot of missing versioned dependencies which often aren't a big problem, but technically still missing right the "normal" case is Test-Depends: postgresql-server-dev-all, and the tests then iterate over the set of versions coded into postgresql-common so I think this just needs debugging and next time we'll have everything go smoothly again this set of versions is wrong for the "other" version at the moment so what is missing? from unstable in testing for autopkgtest the problem is that at the moment we have a static debian/tests/control which doesn't know about the list of versions because both postgresql-11 and -12 are in testing it assums that the list of versions are in sync, and then everything works no the list is hardcoded in postgresql-common I still don't see any issue https://sources.debian.org/src/postgresql-common/209/debian/supported-versions/#L103 in your description the testing postgresql-common wants to test all modules for PG11 so the PG12 modules in unstable can't migrate because the testing test tries to test them for PG11 which fails the unstable pg-common tests everything for PG12 so it can't migrate because modules in testing are still PG11 so they need to migrate in parallel, but there's no dependency that enforces this the packages themselves are fine, no matter what the pg-common version is which packages are so called modules (I can't see that from the name) they just fail to test everything building something postgresql-*-foo with * being 11 or 12? which is basically everything we are talking about now, as the rest isn't version-dependant elbrus: yes does postgresql-common do anything more than telling autopkgtest which version to test? the rest is already done (mostly I think) I guess it tells which PostgreSQL is the default? elbrus: it does that, and builds debian/control from debian/control.in using that list of versions you're not allowed to build debian/control during build, so you're meaning something else I hope (fwiw, when I say "list of versions", that list has only one element in Debian, but can have more) elbrus: it will FTBFS when the debian/control isn't up to date right that's why we do all these no-op "souceful" uploads to update the list of packages built "sourceful binnmu" uploads and get an new binary package in return yes wouldn't it be possible to not embed the postgresql version in? that new binary package works fine, but it can only be tested in an environment that has the right version config or you want all this to be co-installable while a new version is being deployed we have two packages that do that (postgresql-q3c and pgsphere), but the problem there is, once a new PostgreSQL version is supported, existing users loose support for their version if they upgrade, and that's not nice so you would need an XS-Breaks-Autopkgtest field not even true more Depends than Breaks so your modules should update the debian/tests/control file with the right version on postgresql-common I put a change into the 2nd-last pg-common upload that makes the set of versions tested depend on the set of module packages actually installed, but that didn't quite work out because it needs additional stuff we don't provide in the necessary form yet it's a versioned test dependency as I get it? elbrus: yes that would be one way out except
Bug#941078: transition: postgresql-12
Hi Christoph, On 09-11-2019 19:50, Paul Gevers wrote: >> 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 ♻ ^ This just got uploaded moments ago, binNMU'ed on the buildd. >> 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 ♻ ^ You uploaded a new version, so I assume this is in the wrong list, no? >> 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? And please file bugs about these if they aren't there yet. E.g. hypopg isn't maintained by the Debian PostgreSQL Maintainers, so a heads-up to the maintainer before we remove the package from testing would have been nice. >> 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 ♻ ^ This one also fails in unstable, so are you sure it's OK? Paul signature.asc Description: OpenPGP digital signature
Bug#941078: transition: postgresql-12
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 signature.asc Description: OpenPGP digital signature
Bug#941078: transition: postgresql-12
Here's the situation as of now, looking at https://qa.debian.org/excuses.php?package=postgresql-common 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 ♻ To be investigated: autopkgtest for postgresql-q3c/1.8.0-1: amd64: Regression ♻ These are OK and need to migrate in parallel with postgresql-common so the list of supported PG versions is in sync: 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 ♻ 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 ♻ autopkgtest for postgis/3.0.0+dfsg-1: amd64: Regression ♻ autopkgtest for rdkit/201903.1-2: amd64: Regression ♻ 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.) 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? Thanks, Christoph
Bug#941078: transition: postgresql-12
Re: Paul Gevers 2019-11-05 <75a8a466-6338-b4c3-13bf-494498644...@debian.org> > Hi Christoph, > > Did I see correctly that not much changed in the status of the > postgresql-12 transition? Are you done uploading and do the other > packages need binNMU's? Or are you just busy? Most of the "easy" work is done. The remaining packages need upstream fixes, which I have started hunting for, but I was pretty busy over the past days. I'll try to get some more sorted out tomorrow, and then post a list here which packages I think should be either ignored, or removed from testing for now. From there, the way forward would be to ask debci to test all "good" packages together, or simply to force postgresql-common into testing and have everything else migrate by the usual means. Christoph
Re: Bug#941078: transition: postgresql-12
There seems to be an issue with debci, both postgis & pgsql-ogr-fdw are marked as a regression in the excuses, but when looking at debci itself for both testing and unstable the tests are passing. The previous failure was when postgres-12 was the new default, but the package hadn't been rebuilt with it yet. Can britney or its debci integration be fixed, or do we need to drop the autopkgtests to prevent issues like this in the future? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#941078: transition: postgresql-12
Hi Christoph, Did I see correctly that not much changed in the status of the postgresql-12 transition? Are you done uploading and do the other packages need binNMU's? Or are you just busy? Paul signature.asc Description: OpenPGP digital signature
Bug#941078: transition: postgresql-12
Re: Paul Gevers 2019-10-13 > The migration is currently blocked on the regression of repmgr. I just > triggered a reference run as I think the postgresql-11 migration in the > perl transition will have caused the current state in testing to be bad > already. If that's not the case, and it's really postgresql-12 related, > how do you propose we treat the situation? Fwiw, I believe the situation is as follows: libpq5 didn't break ABI, so the existing postgresql-11-repmgr packages are fine, both in testing and in unstable. What did change however is that some API juggling happened, which means repmgr needs to be updated to cope with mixed PostgreSQL versions in postgresql-server-dev-11 and libpq-dev 12. Unfortunately repmgr's autopkgtest is marked "build-needed" so we get to see the API problem, while there's no actual problem with the binaries. I've pushed a change to git to fix that. Christoph
Bug#941078: transition: postgresql-12
Re: Paul Gevers 2019-10-13 > The migration is currently blocked on the regression of repmgr. I just > triggered a reference run as I think the postgresql-11 migration in the > perl transition will have caused the current state in testing to be bad > already. If that's not the case, and it's really postgresql-12 related, > how do you propose we treat the situation? Marco said there would be a new repmgr release tomorrow. That can transition to testing independently first, and then PG12 will be good to go. Christoph
Bug#941078: transition: postgresql-12
Hi Christoph, On 13-10-2019 12:04, Christoph Berg wrote: > Re: Emilio Pozuelo Monfort 2019-10-12 > <09c44ee4-1bee-bc9a-43fd-64fbbdf5c...@debian.org> >> Go ahead. > > Thanks. We'll start as soon as postgresql-12 is in testing to minimize > any possible entanglement with other transitions. The migration is currently blocked on the regression of repmgr. I just triggered a reference run as I think the postgresql-11 migration in the perl transition will have caused the current state in testing to be bad already. If that's not the case, and it's really postgresql-12 related, how do you propose we treat the situation? Paul PS: I am aware of the discussion on IRC, but the outcome for postgresql-12 isn't clear to me and I like it to be logged in this bug. signature.asc Description: OpenPGP digital signature
Bug#941078: transition: postgresql-12
Re: Emilio Pozuelo Monfort 2019-10-12 <09c44ee4-1bee-bc9a-43fd-64fbbdf5c...@debian.org> > Go ahead. Thanks. We'll start as soon as postgresql-12 is in testing to minimize any possible entanglement with other transitions. Christoph
Processed: Re: Bug#941078: transition: postgresql-12
Processing control commands: > tags -1 confirmed Bug #941078 [release.debian.org] transition: postgresql-12 Added tag(s) confirmed. -- 941078: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941078 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#941078: transition: postgresql-12
Control: tags -1 confirmed On 24/09/2019 12:49, Christoph Berg wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Hi, > > PostgreSQL 12 rc1 is due to be released this week. Ben patch attached. > > As usual the transition will be done using sourceful uploads, so > little release team interaction is expected to be needed. Go ahead. Emilio
Bug#941078: transition: postgresql-12
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, PostgreSQL 12 rc1 is due to be released this week. Ben patch attached. As usual the transition will be done using sourceful uploads, so little release team interaction is expected to be needed. Christoph >From dc20c59f948622dc761f06aa0d5da7d6813c3811 Mon Sep 17 00:00:00 2001 From: Christoph Berg Date: Tue, 24 Sep 2019 12:44:26 +0200 Subject: [PATCH] Add postgresql-12 tracker --- config/ongoing/postgresql-12.ben | 5 + 1 file changed, 5 insertions(+) create mode 100644 config/ongoing/postgresql-12.ben diff --git a/config/ongoing/postgresql-12.ben b/config/ongoing/postgresql-12.ben new file mode 100644 index 000..4ac60b1 --- /dev/null +++ b/config/ongoing/postgresql-12.ben @@ -0,0 +1,5 @@ +title = "postgresql-12"; +is_affected = .depends ~ /postgresql.*-1[012].*/ | .build-depends ~ /postgresql.*-1[012].*/ | .recommends ~ /postgresql.*-1[012].*/ | .suggests ~ /postgresql.*-1[012].*/; +is_good = .depends ~ /postgresql.*-12.*/ | .build-depends ~ /postgresql.*-12.*/ | .recommends ~ /postgresql.*-12.*/ | .suggests ~ /postgresql.*-12.*/; +is_bad = .depends ~ /postgresql.*-1[01].*/ | .build-depends ~ /postgresql.*-1[01].*/ | .recommends ~ /postgresql.*-1[01].*/ | .suggests ~ /postgresql.*-1[01].*/; +export = false; -- 2.23.0
