[pkg-GD-devel] status on libgd stuff?
pierre.php at gmail.com
Sun Aug 12 15:59:42 UTC 2007
On 8/12/07, Jonas Smedegaard <dr at jones.dk> wrote:
> Pierre skrev:
> > On 8/12/07, Jonas Smedegaard <dr at jones.dk> wrote:
> >> I've packaged and uploaded 2.0.35.dfsg-1 to unstable. The "dfsg" part os
> >> due to some of the cmake snippets containing copyrights referring to
> >> licensing info not available in the source tarball, and also I am
> >> uncertain if the Qt license used by at least one of those snippets (as
> >> opposed to the Qt+GPL dual-license used by Qt itself) is actually
> >> DFSG-free. Also the VMS makefile contains a copyright with too vague
> >> licensing info.
> > Which licenses info are you refering to? Nothing from cmake should be
> > distributed in a package. It is also not used yet to build releases
> > ready packages but only to run the tests suite.
> In the tarball http://www.libgd.org/releases/gd-2.0.35.tar.gz the
> following files contains a copyright note different from earlier releases:
> The topmost file mentions the word "GNU" which may indicate that the
> file is licensed as GNU GPLv2, but really that is too speculative, and I
> decided to instead interpret the file as not properly licensed for
> redistribution and thus avoided it.
> The middle 4 files refer to licenses seemingly not availailable with the
> source tarball.
> The last 2 files listed above is licensed as GPLv2, but the actual
> license seems missing from the tarball. That is AFAIK a violation of
> that license - not for Debian, as we do ship the license once for the
> whole distribution of packages. So I am only mentioning it here in case
> you want to correct that as well.
All these files should not be distributed. VMS is only for VMS (that's
an operating system). The CMake macros, for most of them, are
available in any recent CMake install (2.4.5 and up). But as I just
said, they are not yet used to build releases but tests.
> > Please refer to Sean's mails. There is _already_ one repository. and
> > we use it as base for our work. As far as I remember it is part of
> > php-gd.
> What mail more specifically?
> I do understand that there's already a repository for your work
> developing GD itself officially.
No, there is a CVS in php-gd module and this is the one we use for
debian (and ubuntu will follow as soon as we are in sync).
> I am referring to a different, separate repository for the packaging of
> GD and related packages for Debian.
Yes, me too.
> You do not need to get involved in the Debian packaging of your software.
No, but I have to to be sure that things get done, cleanly and in time.
> If you are interested in helping out (re)packaging GD for Debian, then
> you are most welcome. But please do understand that this task is
> different from that of maintaining the software upstream: As a minimum
> it requires understanding and acknowledging the policies governing the
> packaging of software for Debian.
I know that. But again, I'm not going to discuss again these points.
> I do understand that Sean is (or has been) involved in the upstream
> development of GD. I do not want to get involved in that. For the
> packaging of GD for Debian I intend to mainly grab your officially
> released tarballs and build Debian packages from that.
You got it wrong. We are not talking about upstream but about what
will be packaged/distributed in debian.
> Feel free to post any info from upstream development that you believe
> might help our packaging process (i.e. making us aware of bugfixes that
> you've submitted to your public SVN repository and want Debian to
> quickly apply, but for some reason you do not yet want to release a new
> tarball of your software).
What I like to have will be committed in the php-gd repository in
debian cvs. There is a submodule there which will be used to create
the patches and all Sean need for the packaging. Doing this way make
our work (Sean and me) easier while keeping the quality as an
More information about the pkg-GD-devel