[Debichem-devel] cclib

[Daniel Leidert]

Am Dienstag, den 12.04.2011, 11:00 +0200 schrieb Karol M. Langner:
> Hi,
> 
>  Thanks for looking at it! I fixed all the things you pointed out and
> commited the changes, with comments bellow.

besides everything else, there are several other issues. lintian e.g.
complains pretty much:

> W: cclib source: build-depends-on-python-dev-with-no-arch-any
> W: cclib: new-package-should-close-itp-bug
> W: cclib: binary-without-manpage usr/bin/ccget
> W: cclib: binary-without-manpage usr/bin/cda
> E: cclib: python-script-but-no-python-dep usr/bin/ccget
> E: cclib: python-script-but-no-python-dep usr/bin/cda
> W: cclib: package-contains-upstream-install-documentation usr/share/doc/cclib/INSTALL
> W: cclib: extra-license-file usr/share/doc/cclib/LICENSE.gz
> W: python-cclib: wrong-section-according-to-package-name python-cclib => python
> W: python-cclib: new-package-should-close-itp-bug
> W: python-cclib: binary-without-manpage usr/bin/ccget
> W: python-cclib: binary-without-manpage usr/bin/cda
> E: python-cclib: python-script-but-no-python-dep usr/bin/ccget
> E: python-cclib: python-script-but-no-python-dep usr/bin/cda

Looking above, cclib and python-cclib will ship the same files
(e.g. /usr/bin/ccget and cda). But that's not all: There is already a
file /usr/bin/cda in the package xmcd. So this is a file conflict, which
must be solved - e.g. by renaming the binary in cclib. I further see
some targets getting called several times during the build process.
Looking at debian/rules, this might be caused by the override target of
dh_auto_install: the target calls dh_auto_install itself, but this tool
makes use of setup.py if available! You probably don't want to run
dh_auto_install together with your separate calls to setupy.py.

Are you interested in getting patches from Michael and me to learn more
about the packaging or do you want us to commit changes directly (which
is the more direct way to fix issues)?

Regards, Daniel

> On Tue, Apr 12, 2011 at 12:10:22AM +0200, Michael Banck wrote:
> > ** http://cclib.sfnet should be http://cclib.sf.net I guess
> > ** Copyright seems to be "cclib (http://cclib.sf.net) is (c) 2006, the
> >    cclib development team" for most files, rather than "Firstname
> >    Lastname" ;)
> 
> I'm not sure I included enough. Could you check?

If you read the license, you'll read this term:

> To apply these terms, attach the following notices to the library.  It is
> safest to attach them to the start of each source file to most effectively
> convey the exclusion of warranty; and each file should have at least the
> "copyright" line and a pointer to where the full notice is found.
> 
>     <one line to give the library's name and a brief idea of what it does.>
>     Copyright (C) <year>  <name of author>
> 
>     This library is free software; you can redistribute it and/or
>     modify it under the terms of the GNU Lesser General Public
>     License as published by the Free Software Foundation; either
>     version 2.1 of the License, or (at your option) any later version.
> 
>     This library is distributed in the hope that it will be useful,
>     but WITHOUT ANY WARRANTY; without even the implied warranty of
>     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>     Lesser General Public License for more details.
> 
>     You should have received a copy of the GNU Lesser General Public
>     License along with this library; if not, write to the Free Software
>     Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
> 
> Also add information on how to contact you by electronic and paper mail.

So this is the boilerplate we are talking about. "Copyright ...." and
then "This library is ...." up to "You should have received ...". See
e.g. the debian/copyright of other packages in our SVN.

> > ** You don't (and should not) need to cite the full LGPL, just the
> >    boilerplate and a link to /usr/share/common-licenses/LGPL-2.1
> 
> Again, could you check I did this correctly?

Besides the above, debian/copyright is IMO ok.

[..]
> So, it seems to build the packages correctly, although I am using
> simply dpkg-buildpackage since I haven't figured out how to use
> pbuilder yet. Is it so much better/easier?

It simply provides a clean build environment (I did this to test
building the package). So you can test, if all necessary build
dependencies are listed in debian/control or if you get the expected
result when you build the package. It is better to use it to make sure,
your package will build on Debians build-daemons.

Regards, Daniel