Обсуждение: ...

Bcc:
Subject: Re: [pgsql-pkg-debian] pgrouting updated to version 2.2.0-1.pgdg+1
Reply-To:
In-Reply-To: <CAK_FzuWBQyEq3F_CW9CcL1z37TD_HgHE2f70tAcVVW8usxj69w@mail.gmail.com>

Re: Vicky Vergara 2016-04-19 <CAK_FzuWBQyEq3F_CW9CcL1z37TD_HgHE2f70tAcVVW8usxj69w@mail.gmail.com>
> Hello packagers:
>
> Thanks very much.
>
> There are 2 questions:
> First one, and most urgent would be, someone got a server crash, so I had
> to make a version 2.2.1:
> https://github.com/pgRouting/pgrouting/releases/tag/pgrouting-2.2.1
> I think some spelling errors were fixed. (see bellow)
> My guess is that: that one has to be packaged.
> I really apologize for the double work.

Hi Vicky,

the real Debian packaging is done by Bas and others in
https://anonscm.debian.org/cgit/pkg-grass/pgrouting.git/
(2.2.1 is already in there, btw :)
You'll really talk to them directly. (Cc'ed)

I myself am also packaging a bunch of PostgreSQL packages for Debian,
but in the case of pgrouting, I'm merely re-building what's in the git
quoted above for apt.postgresql.org. I'm happy that it Just Works :)

> The second is I am wondering about this:
>   * Team upload.
>   * New upstream release.
>   * Update copyright file, changes:
>     - Update copyright years for various copyright holders
>     - Add license & copyright for sources by Razequl Islam
>     - Add new files by Alexander Neundorf
>     - Add license & copyright for CMake files by Kitware, Inc
>   * Bump Standards-Version to 3.9.8, no changes.
>   * Simplify file glob patterns in doc-base.
>   * Enable verbose make output.
>   * Add patch to fix spelling errors.
>   * Enable all hardening buildflags.
>
> My main concern are:
> The copyrights: What is wrong?, so I can fix it in the repository.
> The hardening build flags: What is that? & How do I do the testing with the
> those flags when making the release?,

These should be answered by the git link above, I believe.

Christoph

Hi Vicky,

On 04/19/2016 08:01 PM, Christoph Berg wrote:
> Vicky Vergara wrote:
>> There are 2 questions:
>> First one, and most urgent would be, someone got a server crash, so I had
>> to make a version 2.2.1:
>> https://github.com/pgRouting/pgrouting/releases/tag/pgrouting-2.2.1
>> I think some spelling errors were fixed. (see bellow)

s/bellow/below/ ;-)

>> My guess is that: that one has to be packaged.
>> I really apologize for the double work.

No problem, the changes between 2.2.0 and .1 were minimal, so the
packaging burden was light too.

> the real Debian packaging is done by Bas and others in
> https://anonscm.debian.org/cgit/pkg-grass/pgrouting.git/
> (2.2.1 is already in there, btw :)
> You'll really talk to them directly. (Cc'ed)

Michael Fladischer did the packaging for pgRouting 2.0.0, but he isn't
very active any more unfortunately. So I'm picking up the slack, mostly
because pgRouting one of the reverse dependencies of PostGIS which I
also help maintain in Debian along with Markus Wanner.

> I myself am also packaging a bunch of PostgreSQL packages for Debian,
> but in the case of pgrouting, I'm merely re-building what's in the git
> quoted above for apt.postgresql.org. I'm happy that it Just Works :)

We did need a little poking to get pgRouting 2.1.0 packaged because the
new upstream version detection didn't handle the changed tag naming
convention. That was quickly resolved after Christoph contacted the
Debian GIS team forwarding the request for packaging of pgRouting 2.1.

>> The second is I am wondering about this:
>>   * Team upload.
>>   * New upstream release.
>>   * Update copyright file, changes:
>>     - Update copyright years for various copyright holders
>>     - Add license & copyright for sources by Razequl Islam
>>     - Add new files by Alexander Neundorf
>>     - Add license & copyright for CMake files by Kitware, Inc
>>   * Bump Standards-Version to 3.9.8, no changes.
>>   * Simplify file glob patterns in doc-base.
>>   * Enable verbose make output.
>>   * Add patch to fix spelling errors.
>>   * Enable all hardening buildflags.
>>
>> My main concern are:
>> The copyrights: What is wrong?, so I can fix it in the repository.

Why do you think the copyright is wrong?

The Debian package contains a machine readable copyright file which
includes all the license & copyright statements included in the upstream
source per Debian Policy 12.5:

 https://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile

As part of the packaging update for 2.2.0 I reviewed the changes between
2.1.0 and 2.2.0, and incorporated the license & copyright changes in the
debian/copyright file.

If changes to the upstream source were made as part of the Debian
package update, I would have forwarded the patches like I did for the
spelling errors.

>> The hardening build flags: What is that? & How do I do the testing with the
>> those flags when making the release?

Hardening buildflags are compile time options "to help harden a
resulting binary against memory corruption attacks, or provide
additional warning messages during compiles." See:

 https://wiki.debian.org/Hardening

In the Debian package build we just export
DEB_BUILD_MAINT_OPTIONS=hardening=+all to have the dpkg-buildflags
helper pass the all the hardening options to the build system.

You can add these options to the upstream buildsystem if you want test
them as part of the release and not using the Debian packaging tools.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

On 04/19/2016 10:07 PM, Vicky Vergara wrote:
> Hello Sebastian, Christoph:
> I will contact the people of the debian link,
> it so happens, that  yesterday I made the tag, but this morning I
> realized that I didn't update news and change log so I deleted
> the tag, and made a new one. and to this last one I made the release.
> And in the link you are giving me, it looks like it took yesterday's tag.

Please don't do that.

Once a release is published, you cannot take it back.

Now there are two different 2.2.1 releases which differ in content, but
not version number.

The fixes you made, make it appropriate to bump the version to 2.2.2.

> I don't know how much affects this in what you are doing
> to make the release.

I need to create a tarball which includes a Debian specific version
suffix to differentiate it from the 2.2.1 I packaged earlier.

I'd rather not do that, and package 2.2.2 instead after you've fixed the
tags in the git repository.

> Thanks for your help and patience. I want to make things correctly and
> I really appreciate your help.

You're welcome.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: Sebastiaan Couwenberg 2016-04-19 <571694F9.6040400@xs4all.nl>
> > So I need to name the tag 2.2.1 to be 2.2.2
> > and recover the hash from 2.2.1 and tag it again, is that correct?
>
> Yes, ideally the old 2.2.1 tag is restored to reference the old commit,
> and the new 2.2.1 tag needs to be replaced with 2.2.2, but you'll likely
> need to change a couple of source files to use 2.2.2 first too.

Hmm, doesn't that create the same problem the other way round for the
other half of the world that has downloaded the newer tarball?

From what I understood, the difference was just changelog/news, so
wouldn't just waiting for the next release to happen eventually be
good enough?

Christoph

On 04/19/2016 10:18 PM, Vicky Vergara wrote:
> oh, I didnt know that, sorry!!!.

No problem, these kind of issues are not the end of the world.

> So I need to name the tag 2.2.1 to be 2.2.2
> and recover the hash from 2.2.1 and tag it again, is that correct?

Yes, ideally the old 2.2.1 tag is restored to reference the old commit,
and the new 2.2.1 tag needs to be replaced with 2.2.2, but you'll likely
need to change a couple of source files to use 2.2.2 first too.

Deleting the new 2.2.1 tag and recreating it to reference the old commit
should suffice. You'll need to use `git push --tags -f` if you don't
explicitly remove the tag from the repository on GitHub first.

Documenting the release procedure in a HOWTORELEASE file is probably a
good idea so you and others don't have to remember the exact process.
Have a look at the PDAL document for inspiration:

 https://github.com/PDAL/PDAL/blob/master/HOWTORELEASE.txt

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

On 04/19/2016 10:31 PM, Christoph Berg wrote:
> Re: Sebastiaan Couwenberg 2016-04-19 <571694F9.6040400@xs4all.nl>
>>> So I need to name the tag 2.2.1 to be 2.2.2
>>> and recover the hash from 2.2.1 and tag it again, is that correct?
>>
>> Yes, ideally the old 2.2.1 tag is restored to reference the old commit,
>> and the new 2.2.1 tag needs to be replaced with 2.2.2, but you'll likely
>> need to change a couple of source files to use 2.2.2 first too.
>
> Hmm, doesn't that create the same problem the other way round for the
> other half of the world that has downloaded the newer tarball?
>
> From what I understood, the difference was just changelog/news, so
> wouldn't just waiting for the next release to happen eventually be
> good enough?

Yes, it does. This just underscore the issue of changing tags after
they've been published outside your local repository.

So please disregard my advise to change the 2.2.1 tag, just make sure
2.2.2 gets it right.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1