Re: copasi is ready for upload

[Andreas Tille <andreas@an3as.eu>]

Hi Ivo,

On Sun, Jan 29, 2012 at 10:33:05AM +0100, Ivo Maintz wrote:
> Copasi is ready in svn to the first upload. One strange behavior:
> svn-buildpackage didn't work for me, while debuild did the job.
> svn-buildpackage seams to NOT unpack the sources, so dpkg-source nags
> for "deleted" files. But, as already mentioned, debuild works...

I inspected the package and have the following comments:

  0. Please file an ITP bug using
       reportbug wnpp
     and follow the reportbug advises.  It is a good idea to
     do this on a machine that can send mails.  If not available
     here you should save the mail in the end and can send it
     manually via some webmailer to control@bugs.debian.org

  1. debian/changelog
     If there are unreleased versions please tag them using
     'UNRELEASED' as target distribution.  This is described
     in our policy document in paragraph 'Subversion tips'.
     Usually you can find the policy document here[1] but
     the machine is currently down.  You might fetch it from
     Google cache by seeking for "Debian Med Policy" and look
     for a cached version.

     Please everybody put this document under your pillow!

     Once you have succeeded filing the ITP bug this bug gets
     a number and you should close this bug in your latest
     changelog entry which says:

       * Initial release (Closes: #????)

     Please note: "New upstream version" in a changelog entry
     does not make any sense from a debian/changelog perspective
     for packages which were never uploaded to Debian at all.
     So alternatively to the target 'UNRELEASED' as mentioned
     above you can savely delete the older changelog entry
     because it has no relevant information for anybody.  This
     would be different in case you might cooperate with other
     maintainers to let them know what you changed on this not
     yet released packaging.

  3. debian/rules

     Please delete the dh_make template comments - I do not
     think that Joey Hess and Craig Small did something on this
     actual file, right? ;-)

     Further hint:  Using cdbs is fine in principle.  However,
     specifically for beginners I'd strongly recommend dh which
     drastically simplifies things.  I also have seen your
     'all-in-one-patch' which seems to contain "intended"
     patches and those which just happens when autotools are
     soing their nasty work.

     Please try to separate this.  Packages builded like this
     are asking for troubla if trying to build twice in a row.
     To prevent this you are very well advised to use
      autotools-dev, dh-autoreconf
     as Build-Depends and use

     %:
        dh $@ --with autoreconf

     in your rules file - which implicitely means to drop the
     cdbs approach which I would recommend anyway in cases like
     these.

     I always try to follow successful examples in the past and
     in this case I would recommend to inspect the exonerate
     package (as long as SVN is down try 'apt-get source exonerate')

     This approach is much more safe for autotools based packages

 4. Finally, as we discussed please use pbuilder to test your
    packages.  The first thing I was running into when calling
    using pbuilder was

dpkg-source: info: building copasi in copasi_4.8.35-1.dsc
 debian/rules build
test -x debian/rules
mkdir -p "."
autoconf
make: autoconf: Command not found

    We just discussed that there are other dependencies missing
    and we agree that it probably need some time to sort out the
    libsbml dependency - but what I wrote above is generally
    valid and hopefully helpful for anybody.

As an additional remark:  The way you obtained the source seems
to be a bit complex.  Please clarify the following things:

  1. Please *inform* upstream that if a Debian package is created
     everybody has a quite simple way to obtain the source from
     Debian mirrors and undermines the download policy of upstream.
     While the license perfectly permits what you are doing it
     is fair enough to ask upstream what they think.  If they
     agree it is fine but on the other hand if their means to
     provide the tarball can be undergone it might be logically
     to that they put the tarball simply on their web page which
     in turn makes things simpler for us as well.

  2. The fact that the tarball is not that easily available might
     be a reason to commit your packaging to our Git  repository
     because this comes with packaging *and* source[1] which seems
     convenient for other people in the team.

Kind regards

      Andreas.


[1] http://debian-med.alioth.debian.org/docs/policy.html

-- 
http://fam-tille.de