Hi@anayrat, thank you for your contribution!

Be gentle, I am not used to Debian packaging. I based it on other extensions and how packaging was done for rum

Same here, so some readme filedebian/README.md with explanation of how it all is intended to be used is very welcome. Probably it should just say runmake deb and that's all, but anyway. Maybe some dependencies? E.g.Makefile usesunzip which may be absent on some distros by default, IIRC.

While testing it seems there is something weird between latest release 1.1.1 while EXTVERSION says 1.1 in Makefilehttps://github.com/postgrespro/pg_wait_sampling/blob/master/Makefile#L7

Maybe we were wrong, but it was done intentionally, since Postgres requires an*.sql update file ifdefault_version in the control file has changed. So we reserved a third number in the release number for releases, that only touch C code part. Both1.1 and1.1.1 are basically the same from the Postgres perspective and will look like1.1 in thepg_extension, but the last number is used to indicate that it is still a different release. That way, it seems to better use1.1.1 for a deb package.

Maybe it is rather misleading than useful and we should simply create empty sql update scripts for such minor releases in the future?

Hi@anayrat, thank you for your contribution!

Be gentle, I am not used to Debian packaging. I based it on other extensions and how packaging was done for rum

Same here, so some readme filedebian/README.md with explanation of how it all is intended to be used is very welcome. Probably it should just say runmake deb and that's all, but anyway. Maybe some dependencies? E.g.Makefile usesunzip which may be absent on some distros by default, IIRC.

Yes, I will change that.

While testing it seems there is something weird between latest release 1.1.1 while EXTVERSION says 1.1 in Makefilehttps://github.com/postgrespro/pg_wait_sampling/blob/master/Makefile#L7

Maybe we were wrong, but it was done intentionally, since Postgres requires an*.sql update file ifdefault_version in the control file has changed. So we reserved a third number in the release number for releases, that only touch C code part. Both1.1 and1.1.1 are basically the same from the Postgres perspective and will look like1.1 in thepg_extension, but the last number is used to indicate that it is still a different release. That way, it seems to better use1.1.1 for a deb package.

Maybe it is rather misleading than useful and we should simply create empty sql update scripts for such minor releases in the future?

That was a mistake of my part. Version is obtained from changeloghttps://github.com/postgrespro/pg_wait_sampling/pull/23/files#diff-45c17c0a080fbe29e2b8ded8940aa1e8R1
I add to change1.1.1 to1.1-1. I have seen other project doing like that. I was able to build package and install it on debian stretch.

Hi,
the debian/ dir looks mostly good. A few comments:

• none of the "release-zip", "deb", or debian/rules "orig" targets are required, and in fact, they won't be used by the (official) package builds. The entry point is dpkg-buildpackage (or some variant like debuild).
• is the dependency on postgresql-contrib-PGVERSION required?
• the current Standards-Version is 4.5.0 (debian-policy)
• better use3.0 (quilt) in debian/source/format. (I was using 1.0 for some time to make building from git easier, but the better fix for that problem is dpkg-buildpackage -b.)
• remove debian/tests/control.in, it doesn't have any placeholders, debian/tests/control is enough

On the questions upthread:

• to run the tests, useautopkgtest. (But in practise, you don't need the extra machinery and could just invoke thedebian/tests/installcheck script directly)
• the syntax is the test script is wrong, correct would be-o "shared_preload_libraries=pg_wait_sampling" (without the spaces around = and the extra 'quotes')
• a dependency on zip is not required as it's not being used for the build process
• re 1.1 vs 1.1.1: It's actually a very good idea to decouple the release version from the SQL extension version. That way, you can release new code versions without having to bump the SQL version all the time (meaning you have to change Makefile, write a new --version.sql file, and all users have to do the ALTER EXTENSION .... UPDATE dance without an actual change on that level).
  As the actual release version is 1.1.1, change the Debian version to 1.1.1-1.

I already added a build job on apt.postgresql.org (which fails because of the wrong version), but we are actually pretty close to get this going. Thanks for working on this!

https://pgdgbuild.dus.dg-i.net/job/pg-wait-sampling/

Hi,
the debian/ dir looks mostly good. A few comments:

* none of the "release-zip", "deb", or debian/rules "orig" targets are required, and in fact, they won't be used by the (official) package builds. The entry point is dpkg-buildpackage (or some variant like debuild).

Ok, I will remove them.

* is the dependency on postgresql-contrib-PGVERSION required?

I don't think contrib are necessary.

* the current Standards-Version is 4.5.0 (debian-policy)

Fixed

* better use `3.0 (quilt)` in debian/source/format. (I was using 1.0 for some time to make building from git easier, but the better fix for that problem is dpkg-buildpackage -b.)

Fixed

* remove debian/tests/control.in, it doesn't have any placeholders, debian/tests/control is enough

Fixed

On the questions upthread:

* to run the tests, use `autopkgtest`. (But in practise, you don't need the extra machinery and could just invoke the `debian/tests/installcheck` script directly)* the syntax is the test script is wrong, correct would be `-o "shared_preload_libraries=pg_wait_sampling"` (without the spaces around = and the extra 'quotes')

Fixed

* a dependency on zip is not required as it's not being used for the build process* re 1.1 vs 1.1.1: It's actually a very good idea to decouple the release version from the SQL extension version. That way, you can release new code versions without having to bump the SQL version all the time (meaning you have to change Makefile, write a new --version.sql file, and all users have to do the ALTER EXTENSION .... UPDATE dance without an actual change on that level).  As the actual release version is 1.1.1, change the Debian version to 1.1.1-1.

Fixed

I already added a build job on apt.postgresql.org (which fails because of the wrong version), but we are actually pretty close to get this going. Thanks for working on this!

https://pgdgbuild.dus.dg-i.net/job/pg-wait-sampling/

I noticed I forgot to remove mention of postgres-contrib. It should be fine now. I tested withdebuild -b -uc -us and ran./debian/tests/installcheck.

I don't know why travis test is queued but it seems not related to this PR?

@anayrat, yep, and it has even passed CI [1]. I do not know why the status of PR has not been updated. Anyway, you are right, there is nothing to check in this PR from the CI perspective.

I thought that we were just waiting a feedback from@df7cb confirming that packaging worked fine. However, I see that Jenkins build job [2] has not been retried after your latest changes and it is still marked as 'failed'.

Should I merge PR first to make package build working?

[1]https://travis-ci.com/github/postgrespro/pg_wait_sampling/builds/172812004
[2]https://pgdgbuild.dus.dg-i.net/job/pg-wait-sampling/

Sorry for the non-feedback, I'm currently on vacation and won't take this up again until around July 14th.

One last minor bit, then we are good to go:
In debian/watch, the pattern for releases is wrong, it should bev instead ofREL:

version=3opts="uversionmangle=s/_/./g" \  https://github.com/postgrespro/pg_wait_sampling/releases .*/archive/v(.*).tar.gz

Then you can set the distribution tounstable in debian/changelog (usedch -r).

@df7cb it should be ok now :) thanks.

@df7cb is it possible to trigger a new rebuild onhttps://pgdgbuild.dus.dg-i.net/job/pg-wait-sampling/ ? Thanks!

@df7cb as I can see packages seems presents onhttp://apt.postgresql.org/pub/repos/apt/pool/main/p/pg-wait-sampling/
But they does not appear if I search them withapt search ... Do I miss something?

As you can see from the weird version number, these aren't release builds but some intermediate test build product. The packages are available if you add dist-pgdg-testing to your sources.list only.

I just triggered a real build, packages will be on the mirrors in about an hour.

👍 on merging this now.

Merged. Thanks@anayrat and@df7cb. Let me know if any additional changes will be required.