Thread: [pgsql-pkg-debian] amcheck packages
I would like to make amcheck available in the pgdg apt repo, in order to target earlier PostgreSQL versions. It's available as a contrib extension for v10 already, but there is no reason why it cannot be used on earlier versions. The Github version has the ability to build deb packages already: https://github.com/petergeoghegan/amcheck I'll also want to make available the enhancement that is proposed for Postgres 11, from the current commitfest [1]. So, the goal will be to target Postgres 9.4, 9.5, 9.6, and 10 - v10 will not have an enhanced version, which I believe adds significantly more value. Is there an acceptance process? How can I get the ball rolling on that? Thanks [1] https://commitfest.postgresql.org/14/1263/ -- Peter Geoghegan -- Sent via pgsql-pkg-debian mailing list (pgsql-pkg-debian@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-pkg-debian
Re: Peter Geoghegan 2017-10-01 <CAH2-WzmxNKFmv3R4uEzUsvNzvNF_twB0QF4c-JSnCub0mnRNog@mail.gmail.com> > I would like to make amcheck available in the pgdg apt repo, in order > to target earlier PostgreSQL versions. It's available as a contrib > extension for v10 already, but there is no reason why it cannot be > used on earlier versions. The Github version has the ability to build > deb packages already: > > https://github.com/petergeoghegan/amcheck > > I'll also want to make available the enhancement that is proposed for > Postgres 11, from the current commitfest [1]. So, the goal will be to > target Postgres 9.4, 9.5, 9.6, and 10 - v10 will not have an enhanced > version, which I believe adds significantly more value. > > Is there an acceptance process? How can I get the ball rolling on that? Hi Peter, all we need is a proper debian/ directory, which your repository already has. The packaging looks good, even including tests, cool :) I've configured the build jobs in our jenkins and gave it a go. The build almost worked, the only problem is that the topmost changelog entry in debian/changelog has a malformed timestamp which dpkg is complaining about. On Ubuntu zesty, that problem is even fatal. For the other dists, everything worked including the testsuite. Could you fix that changelog entry, possibly adding a 0.3-2 or 0.4-1 stanza? If you use "dch" (dch -i) to edit the changelog, it will take care of the timestamp. Also, if you want to build Debian packages from git repo's HEAD, it is often easier to set debian/source/format to "1.0" which will disable the "there are changes neither in the tarball nor in debian/patches" check. Christoph -- Sent via pgsql-pkg-debian mailing list (pgsql-pkg-debian@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-pkg-debian
Re: To Peter Geoghegan 2017-10-01 <20171001184247.6behs6v6po3caizw@msg.df7cb.de> > all we need is a proper debian/ directory, which your repository > already has. The packaging looks good, even including tests, cool :) Two more comments, the debian/copyright file needs to list all (C) holders. Also, did you intentionally omit amcheck--0.1--0.3.sql and amcheck--0.2--0.3.sql from Makefile? Christoph -- Sent via pgsql-pkg-debian mailing list (pgsql-pkg-debian@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-pkg-debian
Hi Christoph, On Sun, Oct 1, 2017 at 11:42 AM, Christoph Berg <myon@debian.org> wrote: > I've configured the build jobs in our jenkins and gave it a go. The > build almost worked, the only problem is that the topmost changelog > entry in debian/changelog has a malformed timestamp which dpkg is > complaining about. On Ubuntu zesty, that problem is even fatal. For > the other dists, everything worked including the testsuite. Cool. > Could you fix that changelog entry, possibly adding a 0.3-2 or 0.4-1 > stanza? If you use "dch" (dch -i) to edit the changelog, it will take > care of the timestamp. I can take care of that. I'll also update the debian/copyright file, and include the omitted sql files in the Makefile. This will become 0.3-2. I can push a temporary branch to Github, for your review. Does that work for you? > Also, if you want to build Debian packages from git repo's HEAD, it is > often easier to set debian/source/format to "1.0" which will disable > the "there are changes neither in the tarball nor in debian/patches" > check. I thought that it would be useful to have version numbers that deliberately don't overlap with the Postgres contrib version numbers. Though now, maybe what I should do instead is rename the extension to something like amcheck-next. That would probably avoid confusion, and also allow me to use 1.0 as a version number. What do you think of that idea? Thanks -- Peter Geoghegan -- Sent via pgsql-pkg-debian mailing list (pgsql-pkg-debian@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-pkg-debian
Re: Peter Geoghegan 2017-10-01 <CAH2-WznDdnsQ2=VzvrvkSKrLBOrJE9t-EciDUKdQpPsUq72yrQ@mail.gmail.com> > > Could you fix that changelog entry, possibly adding a 0.3-2 or 0.4-1 > > stanza? If you use "dch" (dch -i) to edit the changelog, it will take > > care of the timestamp. > > I can take care of that. I'll also update the debian/copyright file, > and include the omitted sql files in the Makefile. This will become > 0.3-2. Putting this 0.3-2 on top of master will only work if you also do the "1.0" change in debian/source/format, or else dpkg will complain about differences between the 0.3 tarball and the checkout. (That's why I suggested 0.4.) > I can push a temporary branch to Github, for your review. Does that > work for you? I can point Jenkins at branches/tags for building, no problem. > > Also, if you want to build Debian packages from git repo's HEAD, it is > > often easier to set debian/source/format to "1.0" which will disable > > the "there are changes neither in the tarball nor in debian/patches" > > check. > > I thought that it would be useful to have version numbers that > deliberately don't overlap with the Postgres contrib version numbers. > Though now, maybe what I should do instead is rename the extension to > something like amcheck-next. That would probably avoid confusion, and > also allow me to use 1.0 as a version number. What do you think of > that idea? Does the extension sql file have any difference between the versions? What I'm often seeing is that extension authors will increment the extension version even for C-only changes. If it's really the same extension, just a newer codebase, why not have 1.0 in PG10, and use 1.1 here. Renaming the extension somewhat implies it would be co-installable with the original. (On diffing the SQL files, I see that the difference is that "PARALLEL RESTRICTED" got dropped, is that intended? It is not reflected in any of the amcheck--*--*.sql files.) Christoph -- Sent via pgsql-pkg-debian mailing list (pgsql-pkg-debian@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-pkg-debian
Re: To Peter Geoghegan 2017-10-02 <20171002073842.yzp5i2xcihmj62co@msg.df7cb.de> > Re: Peter Geoghegan 2017-10-01 <CAH2-WznDdnsQ2=VzvrvkSKrLBOrJE9t-EciDUKdQpPsUq72yrQ@mail.gmail.com> > > I can push a temporary branch to Github, for your review. Does that > > work for you? > > I can point Jenkins at branches/tags for building, no problem. I just discovered the branch you pushed and had a look. The changelog timestamp is now valid, but your email address is invalid (pg@marmot), which dpkg doesn't like at all :( > > > Also, if you want to build Debian packages from git repo's HEAD, it is > > > often easier to set debian/source/format to "1.0" which will disable > > > the "there are changes neither in the tarball nor in debian/patches" > > > check. If you fix the changelog, and put plain "1.0" (no qualifier) into debian/source/format, we should be good to go. Christoph -- Sent via pgsql-pkg-debian mailing list (pgsql-pkg-debian@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-pkg-debian
On Mon, Oct 2, 2017 at 12:38 AM, Christoph Berg <myon@debian.org> wrote: > Putting this 0.3-2 on top of master will only work if you also do the > "1.0" change in debian/source/format, or else dpkg will complain about > differences between the 0.3 tarball and the checkout. (That's why I > suggested 0.4.) I can go with 0.4-1, then. > Does the extension sql file have any difference between the versions? > What I'm often seeing is that extension authors will increment the > extension version even for C-only changes. Yes, because we need to revoke execution permissions at the SQL level. We're no longer checking for superuser at the C code level, and so are following what has since become "upstream", Postgres contrib. > If it's really the same extension, just a newer codebase, why not have > 1.0 in PG10, and use 1.1 here. Renaming the extension somewhat implies > it would be co-installable with the original. They could be co-installable, by changing symbol names. There is going to be a contrib amcheck 1.1 before too long, so if I'm not going to change the name of the extension, I should at least make sure that the version numbers stay in a non-overlapping range, to make sure that there is never confusion during upgrade. I am tempted to increment versions ahead of extension version, for C-only changes. That would allow me to create a 0.4-1 without changing or adding any SQL files. What do you think of that idea? Any particular reason why I should favor extension/package version 1.0, that I might have missed? > (On diffing the SQL files, I see that the difference is that "PARALLEL > RESTRICTED" got dropped, is that intended? It is not reflected in any > of the amcheck--*--*.sql files.) I don't believe that that's critical, since we default to unsafe. The Postgres contrib version is PARALLEL RESTRICTED on general principle, not because it matters. Leaving this out means I don't have to deal with special cases on Postgres versions that don't know about parallelism. -- Peter Geoghegan -- Sent via pgsql-pkg-debian mailing list (pgsql-pkg-debian@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-pkg-debian
On Mon, Oct 2, 2017 at 9:09 AM, Christoph Berg <myon@debian.org> wrote: > Re: To Peter Geoghegan 2017-10-02 <20171002073842.yzp5i2xcihmj62co@msg.df7cb.de> >> Re: Peter Geoghegan 2017-10-01 <CAH2-WznDdnsQ2=VzvrvkSKrLBOrJE9t-EciDUKdQpPsUq72yrQ@mail.gmail.com> >> > I can push a temporary branch to Github, for your review. Does that >> > work for you? >> >> I can point Jenkins at branches/tags for building, no problem. > > I just discovered the branch you pushed and had a look. The changelog > timestamp is now valid, but your email address is invalid (pg@marmot), > which dpkg doesn't like at all :( > >> > > Also, if you want to build Debian packages from git repo's HEAD, it is >> > > often easier to set debian/source/format to "1.0" which will disable >> > > the "there are changes neither in the tarball nor in debian/patches" >> > > check. > > If you fix the changelog, and put plain "1.0" (no qualifier) into > debian/source/format, we should be good to go. I pushed a version that makes those changes. Please let me know what you think, particularly about the versioning style (package version vs. extension version). -- Peter Geoghegan -- Sent via pgsql-pkg-debian mailing list (pgsql-pkg-debian@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-pkg-debian
On Mon, Oct 2, 2017 at 11:36 AM, Peter Geoghegan <pg@bowt.ie> wrote: > I pushed a version that makes those changes. Please let me know what > you think, particularly about the versioning style (package version > vs. extension version). Also, just to be clear, the intention is that the commit in the feature branch be pushed to the master branch, which will receive a 0.4-1 tag that is picked up by debian/watch, in line with the general pg_buildext convention. -- Peter Geoghegan -- Sent via pgsql-pkg-debian mailing list (pgsql-pkg-debian@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-pkg-debian
On Mon, Oct 2, 2017 at 11:29 AM, Peter Geoghegan <pg@bowt.ie> wrote: > They could be co-installable, by changing symbol names. There is going > to be a contrib amcheck 1.1 before too long, so if I'm not going to > change the name of the extension, I should at least make sure that the > version numbers stay in a non-overlapping range, to make sure that > there is never confusion during upgrade. It turns out that Postgres is totally naive about external modules that happen to have the same name as contrib modules. I think that I have no choice but to create a new extension name -- "amcheck-next", say. This can have extension version numbers that begin at 1.0. Without this, the control file of the external version simply overwrites the contrib version as part of "make install". That's clearly not okay. -- Peter Geoghegan -- Sent via pgsql-pkg-debian mailing list (pgsql-pkg-debian@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-pkg-debian
Re: Peter Geoghegan 2017-10-02 <CAH2-Wz=2K6_bUJcYjFCKqQEmDsCZFQrY1Dcvx5Szj7pwYDi6oQ@mail.gmail.com> > I pushed a version that makes those changes. Please let me know what > you think, particularly about the versioning style (package version > vs. extension version). Looks good. Re the versioning, I think package and extension versions should be independent, so that releasing new versions that don't affect the SQL part don't need to bump the extension version number. What I've been doing for my extensions (e.g. unit) is to use a single integer as extension version (currently 4), and release 4.0 from that. The "SONAME" approach would be to use completely different version numbers, e.g. SQL version 1, and release 0.3. Mixing 0.3 and 0.4 otoh sounds rather confusing. Re: Peter Geoghegan 2017-10-02 <CAH2-WzmO++VVtDrY1FTiSy2cNdJdMvi2OjkR5eMgZU7h2O_1kg@mail.gmail.com> > > If it's really the same extension, just a newer codebase, why not have > > 1.0 in PG10, and use 1.1 here. Renaming the extension somewhat implies > > it would be co-installable with the original. > > They could be co-installable, by changing symbol names. There is going > to be a contrib amcheck 1.1 before too long, so if I'm not going to > change the name of the extension, I should at least make sure that the > version numbers stay in a non-overlapping range, to make sure that > there is never confusion during upgrade. Does it make sense to have both variants installed, is it safe to use both that the same time? If the SQL names conflict, that would (nicely?) prevent co-installation on the SQL side. > I am tempted to increment versions ahead of extension version, for > C-only changes. That would allow me to create a 0.4-1 without changing > or adding any SQL files. What do you think of that idea? Any > particular reason why I should favor extension/package version 1.0, > that I might have missed? 1.0 isn't special, maybe except for general style in contrib extensions... no idea. > I don't believe that that's critical, since we default to unsafe. The > Postgres contrib version is PARALLEL RESTRICTED on general principle, > not because it matters. Leaving this out means I don't have to deal > with special cases on Postgres versions that don't know about > parallelism. Oh, ok. (I have yet to read up on the whole parallel stuff...) Re: Peter Geoghegan 2017-10-03 <CAH2-Wzn7m4CO04rbYky3GJC1ACN42cqXqsNvmt82nS=ZF-m-BQ@mail.gmail.com> > Without this, the control file of the external version simply > overwrites the contrib version as part of "make install". That's > clearly not okay. On the dpkg side, the package would be uninstallable because the file lists conflict. The .so file would also need renaming, btw... Christoph -- Sent via pgsql-pkg-debian mailing list (pgsql-pkg-debian@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-pkg-debian
Re: To Peter Geoghegan 2017-10-03 <20171003072437.zdptcl23kewltivh@msg.df7cb.de> > > Without this, the control file of the external version simply > > overwrites the contrib version as part of "make install". That's > > clearly not okay. > > On the dpkg side, the package would be uninstallable because the file > lists conflict. > > The .so file would also need renaming, btw... Fwiw, on the dpkg side, another way out of the situation would be to dpkg-divert the files away. Given that both packages provide the same functionality, just different versions, that might be a nice way to handle the problem. Just renaming everything might be easier to handle, though. Anyway, waiting for your ideas :) Christoph -- Sent via pgsql-pkg-debian mailing list (pgsql-pkg-debian@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-pkg-debian
On Thu, Oct 5, 2017 at 9:35 AM, Christoph Berg <myon@debian.org> wrote: >> The .so file would also need renaming, btw... > > Fwiw, on the dpkg side, another way out of the situation would be to > dpkg-divert the files away. Given that both packages provide the same > functionality, just different versions, that might be a nice way to > handle the problem. > > Just renaming everything might be easier to handle, though. I'm definitely going to just rename everything. The extension will be renamed amcheck-next (the .so file will not conflict either), and the C symbols will also be appended with a disambiguating "_next" (no change in SQL function signature, though). I think that the safest, simplest way to handle everything is to make sure that this version of amcheck is formally a different extension to the contrib one. There is no room for ambiguity about that; not in user-facing aspects, and especially not in technical aspects. I'm working through a particularly nasty bug on -hackers right now, but this will bubble to the top of my agenda very soon. I want to have a version that has parity with the one in contrib ASAP, which is installable on Postgres 10 (but not really worth installing on that version). Shortly thereafter, within the next few weeks, I would like to make available a version that has the enhanced heap checking functionality. That seems to add significant value, particularly when it comes to detecting data corruption from known bugs, like the various MultiXact bugs we've had over the past few years, and the CREATE INDEX CONCURRENTLY bug we identified earlier this year. My next step will be to create a "whole new extension" release, that isn't upgradable from earlier versions (just create a new extension). I'm going to copy your approach with extensions like "unit". That seems like the least confusing. I'll work on a pg10-contrib parity version that I'll ask you to accept into the pgdg repo in the next couple of days, or possibly early next week. Thanks! -- Peter Geoghegan -- Sent via pgsql-pkg-debian mailing list (pgsql-pkg-debian@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-pkg-debian
Re: Peter Geoghegan 2017-10-05 <CAH2-Wzk4O7rh0+QWGoX6Y8pmAfxim_9m7wE_popwo963O+X3zw@mail.gmail.com> > I'll work on a pg10-contrib parity > version that I'll ask you to accept into the pgdg repo in the next > couple of days, or possibly early next week. Cool. I just wanted to avoid that we were both waiting for each other and then nothing happens. Cheers, Christoph -- Sent via pgsql-pkg-debian mailing list (pgsql-pkg-debian@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-pkg-debian
Hi Christoph, On Thu, Oct 5, 2017 at 9:55 AM, Christoph Berg <myon@debian.org> wrote: > Cool. I just wanted to avoid that we were both waiting for each other > and then nothing happens. I've posted a new branch here, which has the amcheck_next rename, non-conflicting symbols, etc: https://github.com/petergeoghegan/amcheck/tree/amcheck-next-pgdg This restyles the extension version numbering along the same lines as your "unit" extension. Once this gets your approval, I'll push the commit to the master branch, and create the appropriate version 1.0 tags. Note that I've declared version 1.0 as being stable within debian/changelog. Thanks -- Peter Geoghegan -- Sent via pgsql-pkg-debian mailing list (pgsql-pkg-debian@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-pkg-debian
Re: Peter Geoghegan 2017-10-07 <CAH2-WznctJz1ket8up3vDjLqxeEjM6x-MaOZe-iGsVai184cCg@mail.gmail.com> > Once this gets your approval, I'll push the commit to the master > branch, and create the appropriate version 1.0 tags. Note that I've > declared version 1.0 as being stable within debian/changelog. I think it looks good. I couldn't test it yet on apt.postgresql.org because the tarball isn't yet available. My local testing failed due to lack of disk space: REINDEX INDEX idx_numeric; + ERROR: could not extend file "base/16384/t3_16463": wrote only 4096 of 8192 bytes at block 14335 + HINT: Check free disk space. It also took a minute or so for that step. Is that resource footprint intended? (My /tmp has about 650MB available.) Christoph -- Sent via pgsql-pkg-debian mailing list (pgsql-pkg-debian@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-pkg-debian
On Sat, Oct 7, 2017 at 3:05 AM, Christoph Berg <myon@debian.org> wrote:
> Re: Peter Geoghegan 2017-10-07 <CAH2-WznctJz1ket8up3vDjLqxeEjM6x-MaOZe-iGsVai184cCg@mail.gmail.com>
>> Once this gets your approval, I'll push the commit to the master
>> branch, and create the appropriate version 1.0 tags. Note that I've
>> declared version 1.0 as being stable within debian/changelog.
>
> I think it looks good. I couldn't test it yet on apt.postgresql.org
> because the tarball isn't yet available.
>
> My local testing failed due to lack of disk space:
>
> REINDEX INDEX idx_numeric;
> + ERROR: could not extend file "base/16384/t3_16463": wrote only 4096 of 8192 bytes at block 14335
> + HINT: Check free disk space.
>
> It also took a minute or so for that step. Is that resource footprint
> intended? (My /tmp has about 650MB available.)
The overhead of the tests, which only need to be simple smoke tests,
is probably totally excessive. I've replaced the tests with the tests
that actually made it into contrib/amcheck. The amcheck_next tests now
complete in a couple of seconds, which will greatly reduce the burden
on your Jenkins installation.
I've verified that they pass on all versions myself, and have pushed
that to the master branch. I've also created release tags
("debian/1.0-1", and "v1.0").
Hopefully that's all you need for me to accept amcheck into the PGDG
apt repo. Let me know if anything else comes up.
Thanks!
--
Peter Geoghegan
--
Sent via pgsql-pkg-debian mailing list (pgsql-pkg-debian@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-pkg-debian
Re: Peter Geoghegan 2017-10-07 <CAH2-Wz=c9OaU_Odiq36Fkht0D9xsshY6_pOtBjt-wM7Mo14Yug@mail.gmail.com>
> >> Once this gets your approval, I'll push the commit to the master
> >> branch, and create the appropriate version 1.0 tags. Note that I've
> >> declared version 1.0 as being stable within debian/changelog.
Hi,
sorry I missed that part in the last round - the correct target in
debian/changelog is still "unstable" because that's where all the
uploads go before they trickle into testing and eventually get
released as stable. For apt.pg.o the target distribution doesn't
matter, though.
> The overhead of the tests, which only need to be simple smoke tests,
> is probably totally excessive. I've replaced the tests with the tests
> that actually made it into contrib/amcheck. The amcheck_next tests now
> complete in a couple of seconds, which will greatly reduce the burden
> on your Jenkins installation.
It now worked even on my crammed notebook SSD :)
> I've verified that they pass on all versions myself, and have pushed
> that to the master branch. I've also created release tags
> ("debian/1.0-1", and "v1.0").
I could download the tarball now and build packages. I've already
built them for apt.pg.o, and promoted them to the *-pgdg
distributions, they will appear on the mirrors in about half an hour.
For Debian, I made two small changes:
--- a/debian/changelog
+++ b/debian/changelog
-amcheck (1.0-1) stable; urgency=medium
+amcheck (1.0-1) unstable; urgency=medium
--- a/debian/control.in
+++ b/debian/control.in
-Standards-Version: 3.9.6
+Standards-Version: 4.1.1
Maybe you could apply that, and possibly bump up the debian/1.0-1 tag
to reflect it (but that doesn't really matter much).
Is debian/pgversions intentionally not "9.4+"? We usually only list
explicit maximum versions if the newer versions are not supported on
purpose, and don't just "not work yet". (Though if the repo hosts both
upstream and debian/, that's probably ok.)
Thanks,
Christoph
--
Sent via pgsql-pkg-debian mailing list (pgsql-pkg-debian@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-pkg-debian
On Sat, Oct 7, 2017 at 1:10 PM, Christoph Berg <myon@debian.org> wrote: > I could download the tarball now and build packages. I've already > built them for apt.pg.o, and promoted them to the *-pgdg > distributions, they will appear on the mirrors in about half an hour. > > For Debian, I made two small changes: > > --- a/debian/changelog > +++ b/debian/changelog > -amcheck (1.0-1) stable; urgency=medium > +amcheck (1.0-1) unstable; urgency=medium > > --- a/debian/control.in > +++ b/debian/control.in > -Standards-Version: 3.9.6 > +Standards-Version: 4.1.1 > > Maybe you could apply that, and possibly bump up the debian/1.0-1 tag > to reflect it (but that doesn't really matter much). Note that "debian/watch" is grabbing tags that match "v(.*).tar.gz". So, even though I use "debian*" tags, too, I'm not sure that bumping the tag will work for us. It might be easier to make the changes you ask for formally "v1.1" and "debian/1.1-1" (i.e. avoid just bumping up by creating "debian/1.0-2", which is what you ask for here, I gather). Please let me know what you think. I have pushed a branch to Github for this. top commit: https://github.com/petergeoghegan/amcheck/commit/3b9cc15dbdec1b3864dcf55a4de5492c7244cd47 (That creates a v1.1 for this reason, which might well be overkill.) > Is debian/pgversions intentionally not "9.4+"? We usually only list > explicit maximum versions if the newer versions are not supported on > purpose, and don't just "not work yet". (Though if the repo hosts both > upstream and debian/, that's probably ok.) I decided that that wasn't a good idea, because the build is likely to break for silly reasons. But, that that's true is hardly unique to amcheck, and it actually targets what seem to be very stable interfaces. If that's actually the defacto standard (try it and see), I will change back on the branch that's up for review from you. -- Peter Geoghegan -- Sent via pgsql-pkg-debian mailing list (pgsql-pkg-debian@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-pkg-debian
On Sat, Oct 7, 2017 at 1:33 PM, Peter Geoghegan <pg@bowt.ie> wrote: > Note that "debian/watch" is grabbing tags that match "v(.*).tar.gz". > So, even though I use "debian*" tags, too, I'm not sure that bumping > the tag will work for us. It might be easier to make the changes you > ask for formally "v1.1" and "debian/1.1-1" (i.e. avoid just bumping up > by creating "debian/1.0-2", which is what you ask for here, I gather). > Please let me know what you think. Actually, I could just create a "v1.0-2" tag, to go along with a "debian/1.0-2" tag. That would mean that I wouldn't formally be bumping package number, but rather debian_revision (as I understand it). A cleaner fix, perhaps. -- Peter Geoghegan -- Sent via pgsql-pkg-debian mailing list (pgsql-pkg-debian@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-pkg-debian
Re: Peter Geoghegan 2017-10-07 <CAH2-WzkqW2K9Pkbi_erkjQV3iFxjgKu3sKYQieKA68hixtqM4A@mail.gmail.com> > Note that "debian/watch" is grabbing tags that match "v(.*).tar.gz". > So, even though I use "debian*" tags, too, I'm not sure that bumping > the tag will work for us. It might be easier to make the changes you > ask for formally "v1.1" and "debian/1.1-1" (i.e. avoid just bumping up > by creating "debian/1.0-2", which is what you ask for here, I gather). Sorry, my last mail was a bit confusing. What I meant to say was that I frivolously did these local changes, and then uploaded the package to Debian as 1.0-1. Assuming it passes the initial check of the package by the ftp-master people, that's what is in Debian then, so changing the tag would just mean syncing with that part of reality (while apt.postgresql.org received what you tagged, the changes being no-ops there). Sorry for the mess, I didn't want to postpone the uploads any more, and just went forward there. (The v.* tags are used by debian/watch (via "uscan") to retrieve tarballs. The debian/.* tags are just for documentation.) I guess the way ahead is now to just leave the tags in place, apply the change(s) on top of master, and wait for the next release. Re: Peter Geoghegan 2017-10-07 <CAH2-Wzkc9BtgX4nU8qzS+C-NSYQik6coYpfFm9xmUG6ZFos2oQ@mail.gmail.com> > On Sat, Oct 7, 2017 at 1:33 PM, Peter Geoghegan <pg@bowt.ie> wrote: > > Note that "debian/watch" is grabbing tags that match "v(.*).tar.gz". > > So, even though I use "debian*" tags, too, I'm not sure that bumping > > the tag will work for us. It might be easier to make the changes you > > ask for formally "v1.1" and "debian/1.1-1" (i.e. avoid just bumping up > > by creating "debian/1.0-2", which is what you ask for here, I gather). > > Please let me know what you think. > > Actually, I could just create a "v1.0-2" tag, to go along with a > "debian/1.0-2" tag. That would mean that I wouldn't formally be > bumping package number, but rather debian_revision (as I understand > it). A cleaner fix, perhaps. This kind of changes in debian/-only is what -2 releases are for, so 1.1 is overkill, yes. No v1.0-2 tag is necessary because the upstream version number is still (v)1.0. Christoph -- Sent via pgsql-pkg-debian mailing list (pgsql-pkg-debian@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-pkg-debian
On Sun, Oct 8, 2017 at 2:41 AM, Christoph Berg <myon@debian.org> wrote: > I guess the way ahead is now to just leave the tags in place, apply > the change(s) on top of master, and wait for the next release. Done that way, then. Also modified existing changelog entry for 1.0-1 to be "unstable". Thanks -- Peter Geoghegan -- Sent via pgsql-pkg-debian mailing list (pgsql-pkg-debian@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-pkg-debian
Re: Peter Geoghegan 2017-10-08 <CAH2-WzkxxKK=fbLovn6WJxB+2tV6PtiRKWnR4zso+cB1ijPCmA@mail.gmail.com> > On Sun, Oct 8, 2017 at 2:41 AM, Christoph Berg <myon@debian.org> wrote: > > I guess the way ahead is now to just leave the tags in place, apply > > the change(s) on top of master, and wait for the next release. > > Done that way, then. Also modified existing changelog entry for 1.0-1 > to be "unstable". Perfect, thanks! Christoph -- Sent via pgsql-pkg-debian mailing list (pgsql-pkg-debian@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-pkg-debian
On Sun, Oct 8, 2017 at 11:32 AM, Christoph Berg <myon@debian.org> wrote: > Perfect, thanks! One last thing: I have a pending feature branch for version 1.1, which adds the heap verification enhancement I mentioned: https://github.com/petergeoghegan/amcheck/tree/heap-check I'm probably 2 - 3 weeks away from committing this to the master branch, and creating a new package/amcheck_next version from there. I'm holding back for a bit more community review, to play it safe, but I want to move forward without much further delay. So, possibly stupid question: Is there any etiquette around waiting a period of time before releasing a new version, with enhanced functionality (not a bugfix)? Work on this enhancement has actually been underway for several months now, and I think it's fair to say that it's high quality code. I'm slightly concerned about not violating some unspoken rule about pushing out new functionality too soon, though. (I'm certainly not planning on adding many future enhancements to amcheck_next, if that matters.) Thanks -- Peter Geoghegan -- Sent via pgsql-pkg-debian mailing list (pgsql-pkg-debian@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-pkg-debian
Re: Peter Geoghegan 2017-10-09 <CAH2-Wz=NXmw3MgGJm4RNMoQwHLQReYsrG7RMUwCs+pAf=faV_A@mail.gmail.com> > So, possibly stupid question: Is there any etiquette around waiting a > period of time before releasing a new version, with enhanced > functionality (not a bugfix)? I'd say if it passes non-trivial regression tests, and you think it is ok, release it. We don't have much else we could do in terms of testing. Christoph -- Sent via pgsql-pkg-debian mailing list (pgsql-pkg-debian@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-pkg-debian
On Sun, Oct 8, 2017 at 5:20 PM, Peter Geoghegan <pg@bowt.ie> wrote: > On Sun, Oct 8, 2017 at 11:32 AM, Christoph Berg <myon@debian.org> wrote: >> Perfect, thanks! > > One last thing: I have a pending feature branch for version 1.1, which > adds the heap verification enhancement I mentioned: > > https://github.com/petergeoghegan/amcheck/tree/heap-check > > I'm probably 2 - 3 weeks away from committing this to the master > branch, and creating a new package/amcheck_next version from there. > I'm holding back for a bit more community review, to play it safe, but > I want to move forward without much further delay. I've pushed this out as v1.2. When do you usually get around to pushing out new package versions? Is it something you do irregularly, as time becomes available, or does it happen on a schedule? Thanks -- Peter Geoghegan -- Sent via pgsql-pkg-debian mailing list (pgsql-pkg-debian@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-pkg-debian
Re: Peter Geoghegan 2017-10-22 <CAH2-Wz=UryECZ=FcERAF_+uqYdbKBXSHYndGgm13CKz7vA1zYA@mail.gmail.com> > On Sun, Oct 8, 2017 at 5:20 PM, Peter Geoghegan <pg@bowt.ie> wrote: > > On Sun, Oct 8, 2017 at 11:32 AM, Christoph Berg <myon@debian.org> wrote: > >> Perfect, thanks! > > > > One last thing: I have a pending feature branch for version 1.1, which > > adds the heap verification enhancement I mentioned: > > > > https://github.com/petergeoghegan/amcheck/tree/heap-check > > > > I'm probably 2 - 3 weeks away from committing this to the master > > branch, and creating a new package/amcheck_next version from there. > > I'm holding back for a bit more community review, to play it safe, but > > I want to move forward without much further delay. > > I've pushed this out as v1.2. > > When do you usually get around to pushing out new package versions? Is > it something you do irregularly, as time becomes available, or does it > happen on a schedule? As-needed, as soon as I find out, and have time for it. Just uploaded to Debian, and the apt.pg.o build will be finishing in a few minutes. Thanks, Christoph
On Sun, Oct 22, 2017 at 7:07 AM, Christoph Berg <myon@debian.org> wrote: > As-needed, as soon as I find out, and have time for it. Got it. I don't like to nag, but had to ask about this. > Just uploaded to Debian, and the apt.pg.o build will be finishing in a > few minutes. Thanks! I'm not planning on doing much more with amcheck this year, so this will be the last you hear about it for a long time, barring any bugs. -- Peter Geoghegan -- Sent via pgsql-pkg-debian mailing list (pgsql-pkg-debian@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-pkg-debian