Обсуждение: Get PgBackMan into apt.postgresql.org

Поиск
Список
Период
Сортировка

Get PgBackMan into apt.postgresql.org

От
rafael
Дата:
Hello

Iam the maintainer of the PgBackMan project http://www.pgbackman.org/

I would like to get pgbackman into apt.postgresql.org and I am wondering
if this is possible and what do I need to do to get this.

The source code is in github and I already have done some job needed to
create the deb package:

https://github.com/rafaelma/pgbackman/tree/master/debian

I am not a expert in building deb packages and I need a lite help to get
this done.

Thanks in advance for your hjelp and time.
regards,
--
Rafael Martinez Guerrero
Center for Information Technology
University of Oslo, Norway

PGP Public Key: http://folk.uio.no/rafael/


Re: Get PgBackMan into apt.postgresql.org

От
Christoph Berg
Дата:
Re: rafael 2015-10-30 <56334A7E.6050807@usit.uio.no>
> Hello
>
> Iam the maintainer of the PgBackMan project http://www.pgbackman.org/
>
> I would like to get pgbackman into apt.postgresql.org and I am wondering
> if this is possible and what do I need to do to get this.

Hi Rafael,

sorry for getting back to you so late. I actually had your mail from
June 2014 about the same topic still flagged for reply in my inbox and
it was always on my mental TODO list, but it just never happened. :(

After seeing your presentation at pgconf.eu in Vienna I had ranked the
idea higher again and was glad you sent a mail about it, after which I
had an initial look at the package. Real life + work was pretty
intense over the past weeks so I'm replying only now. Sorry.

(And sorry for the lengthy foreword, now on to business ;)

> The source code is in github and I already have done some job needed to
> create the deb package:
>
> https://github.com/rafaelma/pgbackman/tree/master/debian
>
> I am not a expert in building deb packages and I need a lite help to get
> this done.

I'm just adding pgbackman to apt.postgresql.org and the first build
will be starting in a few minutes. There's several things that should
be fixed before we put the packages up for general use, though. (I'll
list them in random order, and probably send out the mail half-way
because the kids will likely be calling in a few minutes... :)

* debian/changelog is broken; the second paragraph lost the "pgbackman
  (1.0.0-1)...." header

  If you install "devscripts", there's a tool called "dch" which will
  help you getting the formatting right. (Though it will probably barf
  on the current file.) "dch -i" will produce a new entry.

(Ok I'm being called... more later...)

Christoph
--
cb@df7cb.de | http://www.df7cb.de/


Re: Get PgBackMan into apt.postgresql.org

От
Christoph Berg
Дата:
Re: To rafael 2015-12-19 <20151219204348.GB30957@msg.df7cb.de>
> I'm just adding pgbackman to apt.postgresql.org and the first build
> will be starting in a few minutes. There's several things that should
> be fixed before we put the packages up for general use, though. (I'll
> list them in random order, and probably send out the mail half-way
> because the kids will likely be calling in a few minutes... :)

The build has succeeded in the meantime.

> * debian/changelog is broken; the second paragraph lost the "pgbackman
>   (1.0.0-1)...." header
>
>   If you install "devscripts", there's a tool called "dch" which will
>   help you getting the formatting right. (Though it will probably barf
>   on the current file.) "dch -i" will produce a new entry.

After fixing this, lintian is spotting more things:

$ lintian -i
W: pgbackman source: package-needs-versioned-debhelper-build-depends 9
N:
N:    The package either doesn't declare a versioned build dependency on
N:    debhelper or does not declare a versioned build dependency on a new
N:    enough version of debhelper to satisfy the declared compatibility level.
N:
N:    The required version of debhelper is not guaranteed to be satisfied in
N:    all supported releases of Debian and therefore this may lead to a build
N:    failure.
N:
N:    Recommended practice is to always declare an explicit versioned
N:    dependency on debhelper equal to or greater than the compatibility level
N:    used by the package, even if the versioned dependency isn't strictly
N:    necessary. Having a versioned dependency also helps with backports to
N:    older releases and correct builds on partially updated systems.
N:
N:    Note if you are using a compat level, which is marked as experimental,
N:    such as compat 9 in debhelper 8.1.3, then please override this tag.
N:
N:    Refer to the debhelper(7) manual page for details.
N:
N:    Severity: minor, Certainty: certain
N:
N:    Check: debhelper, Type: source
N:
W: pgbackman source: unknown-paragraph-in-dep5-copyright paragraph at line 3
N:
N:    The machine-readable copyright file contains a paragraph that is neither
N:    a standalone license paragraph nor a files paragraph.
N:
N:    Refer to
N:    https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ for
N:    details.
N:
N:    Severity: normal, Certainty: possible
N:
N:    Check: source-copyright, Type: source
N:
W: pgbackman source: out-of-date-standards-version 3.9.5 (current is 3.9.6)
N:
N:    The source package refers to a Standards-Version older than the one that
N:    was current at the time the package was created (according to the
N:    timestamp of the latest debian/changelog entry). Please consider
N:    updating the package to current Policy and setting this control field
N:    appropriately.
N:
N:    If the package is already compliant with the current standards, you
N:    don't have to re-upload the package just to adjust the Standards-Version
N:    control field. However, please remember to update this field next time
N:    you upload the package.
N:
N:    See /usr/share/doc/debian-policy/upgrading-checklist.txt.gz in the
N:    debian-policy package for a summary of changes in newer versions of
N:    Policy.
N:
N:    Refer to https://www.debian.org/doc/debian-policy/upgrading-checklist
N:    for details.
N:
N:    Severity: normal, Certainty: certain
N:
N:    Check: standards-version, Type: source
N:
W: pgbackman: debian-changelog-has-wrong-weekday 2015-10-08 is a Thursday
N:
N:    The date in the changelog entry is not consistent with the actual
N:    weekday. Either the date is wrong or the weekday is wrong.
N:
N:    To avoid problems like this, consider using a tool like dch(1) or
N:    date(1) to generate the date. Example:
N:
N:      $ date -R -ud '2013-11-05 23:59:59'
N:      Tue, 05 Nov 2013 23:59:59 +0000
N:
N:    Severity: normal, Certainty: certain
N:
N:    Check: changelog-file, Type: binary
N:
W: pgbackman: file-in-unusual-dir var/log/pgbackman/README.md
N:
N:    This file or symbolic link is in a directory where files are not
N:    normally installed by Debian packages.
N:
N:    Severity: normal, Certainty: certain
N:
N:    Check: files, Type: binary, udeb
N:
W: pgbackman: script-in-etc-init.d-not-registered-via-update-rc.d etc/init.d/pgbackman
N:
N:    The package installs an /etc/init.d script which is not registered in
N:    the postinst script. This is usually a bug (such as omitting the
N:    #DEBHELPER# token) unless you omit the links intentionally for some
N:    reason or create the links some other way.
N:
N:    Severity: normal, Certainty: possible
N:
N:    Check: init.d, Type: binary
N:
W: pgbackman: binary-without-manpage usr/bin/pgbackman
N:
N:    Each binary in /usr/bin, /usr/sbin, /bin, /sbin or /usr/games should
N:    have a manual page
N:
N:    Note that though the man program has the capability to check for several
N:    program names in the NAMES section, each of these programs should have
N:    its own manual page (a symbolic link to the appropriate manual page is
N:    sufficient) because other manual page viewers such as xman or tkman
N:    don't support this.
N:
N:    If the name of the man page differs from the binary by case, man may be
N:    able to find it anyway; however, it is still best practice to make the
N:    case of the man page match the case of the binary.
N:
N:    If the man pages are provided by another package on which this package
N:    depends, lintian may not be able to determine that man pages are
N:    available. In this case, after confirming that all binaries do have man
N:    pages after this package and its dependencies are installed, please add
N:    a lintian override.
N:
N:    Refer to Debian Policy Manual section 12.1 (Manual pages) for details.
N:
N:    Severity: normal, Certainty: possible
N:
N:    Check: manpages, Type: binary
N:
W: pgbackman: binary-without-manpage usr/bin/pgbackman_alerts
W: pgbackman: binary-without-manpage usr/bin/pgbackman_control
W: pgbackman: binary-without-manpage usr/bin/pgbackman_dump
W: pgbackman: binary-without-manpage usr/bin/pgbackman_maintenance
W: pgbackman: binary-without-manpage usr/bin/pgbackman_restore
W: pgbackman: binary-without-manpage usr/bin/pgbackman_status_info
W: pgbackman: binary-without-manpage usr/bin/pgbackman_zabbix_autodiscovery

The manpage warnings are somewhat optional, but the others should be
addressed.

More points by me:

* postinst:

  you Depend on adduser, but then use "useradd" and "groupadd" in the
  postinst. Using adduser is the preferred variant.

  the groupadd and useradd calls will make installation fail if the
  group/user are already there

  the chmod 775 in the postinst will also mark the log*files* as
  executable

* rules:

  I'm not a python packaging expert - the "python setup.py" call there
  looks redundant to me. Shouldn't --with python2 already handle this?

  Building yields this warning:
     dh_python2
  W: dh_python2:479: Please add dh-python package to Build-Depends

  running "debian/rules clean" doesn't clean the pgbackman.egg-info
  directory, i.e. it isn't currently possible to build the package
  twice from a directory because there's debris left.

* The init script looks much more complicated than usual. Especially
  the exit and return code handling is pretty unusual

* I'd have expected a "compress" statement in the logrotate config

* Please don't put version numbers and dates/years into config files
  (pgbackman.conf). These cause unnecessary diffs and/or conflicts
  when upgrading the package. The usefulness of the copyright
  statement in there is also debatable.

* A watch file would be nice, this would enable downloading the orig
  tarball from github. This would work:

debian/watch:

version=3
opts="uversionmangle=s/_/./g" \
https://github.com/rafaelma/pgbackman/releases .*/v_(.*).tar.gz


Do you want to have the package uploaded to Debian as well? I can do
the sponsor upload.

Thanks for providing PgBackMan,
Christoph
--
cb@df7cb.de | http://www.df7cb.de/


Re: [pgsql-pkg-debian] Get PgBackMan into apt.postgresql.org

От
Christoph Berg
Дата:
Hi Rafael,

picking this up after quite some time - are you still interested in
having PgBackMan in apt.postgresql.org and in Debian?

Re: To rafael 2015-12-19 <20151219223524.GA2566@msg.df7cb.de>
> Re: To rafael 2015-12-19 <20151219204348.GB30957@msg.df7cb.de>
> > I'm just adding pgbackman to apt.postgresql.org and the first build
> > will be starting in a few minutes. There's several things that should
> > be fixed before we put the packages up for general use, though. (I'll
> > list them in random order, and probably send out the mail half-way
> > because the kids will likely be calling in a few minutes... :)
> 
> The build has succeeded in the meantime.
> 
> > * debian/changelog is broken; the second paragraph lost the "pgbackman
> >   (1.0.0-1)...." header
> > 
> >   If you install "devscripts", there's a tool called "dch" which will
> >   help you getting the formatting right. (Though it will probably barf
> >   on the current file.) "dch -i" will produce a new entry.
> 
> After fixing this, lintian is spotting more things:
> 
> $ lintian -i
> W: pgbackman source: package-needs-versioned-debhelper-build-depends 9
> N: 
> N:    The package either doesn't declare a versioned build dependency on
> N:    debhelper or does not declare a versioned build dependency on a new
> N:    enough version of debhelper to satisfy the declared compatibility level.
> N:    
> N:    The required version of debhelper is not guaranteed to be satisfied in
> N:    all supported releases of Debian and therefore this may lead to a build
> N:    failure.
> N:    
> N:    Recommended practice is to always declare an explicit versioned
> N:    dependency on debhelper equal to or greater than the compatibility level
> N:    used by the package, even if the versioned dependency isn't strictly
> N:    necessary. Having a versioned dependency also helps with backports to
> N:    older releases and correct builds on partially updated systems.
> N:    
> N:    Note if you are using a compat level, which is marked as experimental,
> N:    such as compat 9 in debhelper 8.1.3, then please override this tag.
> N:    
> N:    Refer to the debhelper(7) manual page for details.
> N:    
> N:    Severity: minor, Certainty: certain
> N:    
> N:    Check: debhelper, Type: source
> N: 
> W: pgbackman source: unknown-paragraph-in-dep5-copyright paragraph at line 3
> N: 
> N:    The machine-readable copyright file contains a paragraph that is neither
> N:    a standalone license paragraph nor a files paragraph.
> N:    
> N:    Refer to
> N:    https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ for
> N:    details.
> N:    
> N:    Severity: normal, Certainty: possible
> N:    
> N:    Check: source-copyright, Type: source
> N: 
> W: pgbackman source: out-of-date-standards-version 3.9.5 (current is 3.9.6)
> N: 
> N:    The source package refers to a Standards-Version older than the one that
> N:    was current at the time the package was created (according to the
> N:    timestamp of the latest debian/changelog entry). Please consider
> N:    updating the package to current Policy and setting this control field
> N:    appropriately.
> N:    
> N:    If the package is already compliant with the current standards, you
> N:    don't have to re-upload the package just to adjust the Standards-Version
> N:    control field. However, please remember to update this field next time
> N:    you upload the package.
> N:    
> N:    See /usr/share/doc/debian-policy/upgrading-checklist.txt.gz in the
> N:    debian-policy package for a summary of changes in newer versions of
> N:    Policy.
> N:    
> N:    Refer to https://www.debian.org/doc/debian-policy/upgrading-checklist
> N:    for details.
> N:    
> N:    Severity: normal, Certainty: certain
> N:    
> N:    Check: standards-version, Type: source
> N: 
> W: pgbackman: debian-changelog-has-wrong-weekday 2015-10-08 is a Thursday
> N: 
> N:    The date in the changelog entry is not consistent with the actual
> N:    weekday. Either the date is wrong or the weekday is wrong.
> N:    
> N:    To avoid problems like this, consider using a tool like dch(1) or
> N:    date(1) to generate the date. Example:
> N:    
> N:      $ date -R -ud '2013-11-05 23:59:59'
> N:      Tue, 05 Nov 2013 23:59:59 +0000
> N:    
> N:    Severity: normal, Certainty: certain
> N:    
> N:    Check: changelog-file, Type: binary
> N: 
> W: pgbackman: file-in-unusual-dir var/log/pgbackman/README.md
> N: 
> N:    This file or symbolic link is in a directory where files are not
> N:    normally installed by Debian packages.
> N:    
> N:    Severity: normal, Certainty: certain
> N:    
> N:    Check: files, Type: binary, udeb
> N: 
> W: pgbackman: script-in-etc-init.d-not-registered-via-update-rc.d etc/init.d/pgbackman
> N: 
> N:    The package installs an /etc/init.d script which is not registered in
> N:    the postinst script. This is usually a bug (such as omitting the
> N:    #DEBHELPER# token) unless you omit the links intentionally for some
> N:    reason or create the links some other way.
> N:    
> N:    Severity: normal, Certainty: possible
> N:    
> N:    Check: init.d, Type: binary
> N: 
> W: pgbackman: binary-without-manpage usr/bin/pgbackman
> N: 
> N:    Each binary in /usr/bin, /usr/sbin, /bin, /sbin or /usr/games should
> N:    have a manual page
> N:    
> N:    Note that though the man program has the capability to check for several
> N:    program names in the NAMES section, each of these programs should have
> N:    its own manual page (a symbolic link to the appropriate manual page is
> N:    sufficient) because other manual page viewers such as xman or tkman
> N:    don't support this.
> N:    
> N:    If the name of the man page differs from the binary by case, man may be
> N:    able to find it anyway; however, it is still best practice to make the
> N:    case of the man page match the case of the binary.
> N:    
> N:    If the man pages are provided by another package on which this package
> N:    depends, lintian may not be able to determine that man pages are
> N:    available. In this case, after confirming that all binaries do have man
> N:    pages after this package and its dependencies are installed, please add
> N:    a lintian override.
> N:    
> N:    Refer to Debian Policy Manual section 12.1 (Manual pages) for details.
> N:    
> N:    Severity: normal, Certainty: possible
> N:    
> N:    Check: manpages, Type: binary
> N: 
> W: pgbackman: binary-without-manpage usr/bin/pgbackman_alerts
> W: pgbackman: binary-without-manpage usr/bin/pgbackman_control
> W: pgbackman: binary-without-manpage usr/bin/pgbackman_dump
> W: pgbackman: binary-without-manpage usr/bin/pgbackman_maintenance
> W: pgbackman: binary-without-manpage usr/bin/pgbackman_restore
> W: pgbackman: binary-without-manpage usr/bin/pgbackman_status_info
> W: pgbackman: binary-without-manpage usr/bin/pgbackman_zabbix_autodiscovery
> 
> The manpage warnings are somewhat optional, but the others should be
> addressed.
> 
> More points by me:
> 
> * postinst:
> 
>   you Depend on adduser, but then use "useradd" and "groupadd" in the
>   postinst. Using adduser is the preferred variant.
> 
>   the groupadd and useradd calls will make installation fail if the
>   group/user are already there
> 
>   the chmod 775 in the postinst will also mark the log*files* as
>   executable
> 
> * rules:
> 
>   I'm not a python packaging expert - the "python setup.py" call there
>   looks redundant to me. Shouldn't --with python2 already handle this?
> 
>   Building yields this warning:
>      dh_python2
>   W: dh_python2:479: Please add dh-python package to Build-Depends
> 
>   running "debian/rules clean" doesn't clean the pgbackman.egg-info
>   directory, i.e. it isn't currently possible to build the package
>   twice from a directory because there's debris left.
> 
> * The init script looks much more complicated than usual. Especially
>   the exit and return code handling is pretty unusual
> 
> * I'd have expected a "compress" statement in the logrotate config
> 
> * Please don't put version numbers and dates/years into config files
>   (pgbackman.conf). These cause unnecessary diffs and/or conflicts
>   when upgrading the package. The usefulness of the copyright
>   statement in there is also debatable.
> 
> * A watch file would be nice, this would enable downloading the orig
>   tarball from github. This would work:
> 
> debian/watch:
> 
> version=3
> opts="uversionmangle=s/_/./g" \
> https://github.com/rafaelma/pgbackman/releases .*/v_(.*).tar.gz
> 
> 
> Do you want to have the package uploaded to Debian as well? I can do
> the sponsor upload.
> 
> Thanks for providing PgBackMan,

Christoph


Re: [pgsql-pkg-debian] Get PgBackMan into apt.postgresql.org

От
Rafael Martinez Guerrero
Дата:
On 04/04/2018 08:49 PM, Christoph Berg wrote:
> Hi Rafael,
> 
> picking this up after quite some time - are you still interested in
> having PgBackMan in apt.postgresql.org and in Debian?

Hello

Sorry for delay, I have been offline for some days.

Yes, I would like having PgBackMan in apt.postgresql.org and in Debian :-)

Give me some days so I can put together a new versjon we can use for this.

regards,
-- 
 Rafael Martinez Guerrero
 Center for Information Technology
 University of Oslo, Norway

 PGP Public Key: http://folk.uio.no/rafael/


Re: [pgsql-pkg-debian] Get PgBackMan into apt.postgresql.org

От
Christoph Berg
Дата:
Re: Rafael Martinez Guerrero 2018-04-27 <7f3b8102-5ae2-b5ad-33fd-6615a73900d1@usit.uio.no>
> On 04/04/2018 08:49 PM, Christoph Berg wrote:
> > Hi Rafael,
> > 
> > picking this up after quite some time - are you still interested in
> > having PgBackMan in apt.postgresql.org and in Debian?
> 
> Hello
> 
> Sorry for delay, I have been offline for some days.
> 
> Yes, I would like having PgBackMan in apt.postgresql.org and in Debian :-)
> 
> Give me some days so I can put together a new versjon we can use for this.

Hi,

please get in touch with me if you are still interested, I'll stop
pinging now.

Christoph


Re: [pgsql-pkg-debian] Get PgBackMan into apt.postgresql.org

От
Rafael Martinez Guerrero
Дата:
On 06/08/2018 09:39 AM, Christoph Berg wrote:
> Re: Rafael Martinez Guerrero 2018-04-27 <7f3b8102-5ae2-b5ad-33fd-6615a73900d1@usit.uio.no>
>> On 04/04/2018 08:49 PM, Christoph Berg wrote:
>>> Hi Rafael,
>>>
>>> picking this up after quite some time - are you still interested in
>>> having PgBackMan in apt.postgresql.org and in Debian?
>>
>> Hello
>>
>> Sorry for delay, I have been offline for some days.
>>
>> Yes, I would like having PgBackMan in apt.postgresql.org and in Debian :-)
>>
>> Give me some days so I can put together a new versjon we can use for this.
> 
> Hi,
> 
> please get in touch with me if you are still interested, I'll stop
> pinging now.
> 
> Christoph
> 

Hei Christoph

I have been very busy lately and unable to work with this :-(

I am still interested and I will contact you as soon as I have the next
version ready.

regards,
-- 
 Rafael Martinez Guerrero
 Center for Information Technology
 University of Oslo, Norway

 PGP Public Key: http://folk.uio.no/rafael/