Re: RFS: libapache2-mod-ldap-userdir - An Apache2 module that provides UserDir lookups via LDAP

[Fabio Massimo Di Nitto]

Hi John,

On Tue, 8 Jun 2004, John Morrissey wrote:

> I maintain mod_ldap_userdir and am interested in packaging it for Debian. It
> allows UserDir URLs to be looked up based on homeDirectory attributes in an
> LDAP directory instead of from local user accounts.
>
> In the past year or two, several Debian users have mentioned using it, so
> I'd like to package it. I'm also using Debian more and more in the server
> environment, so I have a vested interest in maintaining the package. :-)
>
> I do have one question about the packaging: lintian(1) complains that the
> .so module defines RPATH, but I don't have any control over that since
> compilation is handled entirely by apxs. Should I try to eliminate this, or
> just add an override for it?
>
> Package files are available from http://horde.net/~jwm/debian/. Thanks!
>
> * Package name  : libapache2-mod-ldap-userdir
>   Version   : 1.1.4
>   Upstream Author   : John Morrissey <[EMAIL PROTECTED]>
> * URL   : http://horde.net/~jwm/software/mod_ldap_userdir/
> * License   : GPL version 2 or above
>   Description   : Apache2 module that provides UserDir lookups via LDAP
>
>   This module implements UserDir (~/public_html/) directory lookups using
>   data from an LDAP directory.
>   .
>   This package provides the module for the Apache 2.0 server.

I saw that you already did an ITP. Can you kindly point us to the url with
debian packages? I won't mind to give them a shot (even if i don't use
ldap personally)

I am keeping the followup on debian-mentors since it is a more appropriate
mailing list for package discussion than debian-apache.

Thanks
Fabio

-- 
 fajita: step one
 Whatever the problem, step one is always to look in the error log.
 fajita: step two
 When in danger or in doubt, step two is to scream and shout.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Pkg-firebird-general] Request for comments for ibwebadmin package

[Grzegorz B. Prokopski]

Hi,

W liście z wto, 08-06-2004, godz. 17:14, Remco Seesink pisze: 
> > b) at the top of LICENSE file, which is otherwise pure GPL? This
> > exception seems to fit more into a file that would be called i.e.
> > COPYING, where the copying informations would be held and which
> > would contain the "exception" and reference to the pure GPL in LICENSE
> > file.
> 
> My understanding was that the exception was a part of the legal agreement
> regarding the copyright. In other words, a license. This is were I advised
> upstream to put it. Maybe I was mistaken?

I looked at our (SableVM) import of GNU Classpath for inspiration, which
also uses GPL with some kind of an exception. See:

http://devel.sablevm.org/svn/repository/sablevm-classpath/vendor/current/COPYING
http://devel.sablevm.org/svn/repository/sablevm-classpath/vendor/current/LICENSE

In this case COPYING contains pure GPL.  Please also note that the
beginning of the GPL says:

"Everyone is permitted to copy and distribute verbatim copies
 of this license document, but changing it is not allowed."

So, putting the exception in this document doesn't seem allowed.

Instead in case of Classpath they have all the "dirty stuff" in the
LICENSE file, which contains informations about the actual conditions
under which software is distributed.


As for the upload to mentors - that was definitely good idea ;-)

As for "including email w/ permission from upstream" - yes, this is
a common practice, when the version you want/need to package didn't
contain the proper licensing terms.

HTH

Grzegorz B. Prokopski

-- 
Grzegorz B. Prokopski <[EMAIL PROTECTED]>
Debian GNU/Linux  http://www.debian.org
SableVM - LGPLed JVM  http://www.sablevm.org
Why SableVM ?!?   http://devel.sablevm.org/wiki/WhySableVM

Re: [Pkg-firebird-general] Request for comments for ibwebadmin package

[Grzegorz B. Prokopski]

Hi,

W liście z wto, 08-06-2004, godz. 17:14, Remco Seesink pisze: 
> > b) at the top of LICENSE file, which is otherwise pure GPL? This
> > exception seems to fit more into a file that would be called i.e.
> > COPYING, where the copying informations would be held and which
> > would contain the "exception" and reference to the pure GPL in LICENSE
> > file.
> 
> My understanding was that the exception was a part of the legal agreement
> regarding the copyright. In other words, a license. This is were I advised
> upstream to put it. Maybe I was mistaken?

I looked at our (SableVM) import of GNU Classpath for inspiration, which
also uses GPL with some kind of an exception. See:

http://devel.sablevm.org/svn/repository/sablevm-classpath/vendor/current/COPYING
http://devel.sablevm.org/svn/repository/sablevm-classpath/vendor/current/LICENSE

In this case COPYING contains pure GPL.  Please also note that the
beginning of the GPL says:

"Everyone is permitted to copy and distribute verbatim copies
 of this license document, but changing it is not allowed."

So, putting the exception in this document doesn't seem allowed.

Instead in case of Classpath they have all the "dirty stuff" in the
LICENSE file, which contains informations about the actual conditions
under which software is distributed.


As for the upload to mentors - that was definitely good idea ;-)

As for "including email w/ permission from upstream" - yes, this is
a common practice, when the version you want/need to package didn't
contain the proper licensing terms.

HTH

Grzegorz B. Prokopski

-- 
Grzegorz B. Prokopski <[EMAIL PROTECTED]>
Debian GNU/Linux  http://www.debian.org
SableVM - LGPLed JVM  http://www.sablevm.org
Why SableVM ?!?   http://devel.sablevm.org/wiki/WhySableVM


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: why are these packages in testing?

[Steve Langasek]

On Mon, Jun 07, 2004 at 12:36:00PM +0200, Jeroen van Wolffelaar wrote:
> Note that the testing output says removal fails due to buggyness of the
> package: http://packages.qa.debian.org/a/aiksaurus.html

> # Trying to remove package, not update it
> # libaiksaurus-data (alpha, arm, hppa, i386, ia64, m68k, mips, mipsel,
>   powerpc, s390, sparc) is buggy! (1 > 0)

No, these are two unrelated statements about the same package.  The
first states that a removal has been requested, the second explains why
the package would not be updated in testing even if the removal request
was *not* in place.

However, removal requests also need to respect the integrity of testing
as a releasable whole, so if removing the requested package would make
other packages uninstallable, the removal request fails until this is
dealt with manually.  In this case, abiword and lyx are the packages
that block its removal, as per the update_output.txt report.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: why are these packages in testing?

[Steve Langasek]

On Mon, Jun 07, 2004 at 12:02:01PM +0200, Andreas Barth wrote:

> Similar, for libapache-mod-filter, there is:
> [EMAIL PROTECTED]:~$ madison libapache-mod-filter
> libapache-mod-filter |  1.4-5 |stable | source, alpha, arm, hppa, 
> i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
> libapache-mod-filter |  1.4-8 |   testing | source, alpha, arm, hppa, 
> i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
> libapache-mod-filter |  1.4-8 |  unstable | source, alpha, arm, hppa, 
> i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
> [EMAIL PROTECTED]:~$
> but there is also a removal suggestion, and the excuses-file on
> ftp-master says according to
> http://bjorn.haxx.se/debian/testing.pl?package=libapache-mod-filter
> that this package is removed today from testing. So, why is this still
> there? How many hours after the generation of the excuses list are the
> packages really updated?

Packages are not actually removed from the Packages file until dinstall,
which runs roughly 18 hours after the testing scripts finish generating
update_excuses.  I don't know what time the mirror on merkel is updated.

FWIW, I'm not sure this kind of question is appropriate for
debian-mentors; surely this would be better on debian-devel?

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Request for retrying build of libopenhbci-plugin-ddvcard on arm

[Adeodato Simó]

* Goswin von Brederlow [Sun, 06 Jun 2004 19:24:49 +0200]:

> > P.S.: Of course, if there is a better place to ask about a build on a
> > specific arch, I'll gladly take any advice.

> [EMAIL PROTECTED] ?

  is this the right place to ask for a rebuild? i posted in [EMAIL PROTECTED]
  some time ago (see #251284 if interested), but got no response from
  the porters.

  also, is that address documented anywhere?

  thanks,

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
Listening to: Luis Eduardo Aute - Aleluya nº 1
 
Kindness is a language which the deaf can hear and the blind can read.
-- Mark Twain


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Pkg-firebird-general] Request for comments for ibwebadmin package

[Remco Seesink]

> I haven't looked at this particular case, but it should be just fine to
> say "the copyright owner gave permission to do this" (as long as it's
> not specific to Debian, etc.), without necessarily having to wait for a
> new upstream release. Of course, I'd be inclined to include the full
> text of the e-mail in question.
I will include the e-mail into the next upload.

Cheers,
Remco.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Pkg-firebird-general] Request for comments for ibwebadmin package

[Remco Seesink]

> 1. Why do *you* add the exception that permits for linking w/ some
> GPL-incompatible program
> a) in a debian-specific diff?  The exception has to be granted by
> upstream and they have to release a version that has this exception.
> You must not add it yourself!

The license is from the 0.98 version. 0.98 had some problems which is why I
reverted to 0.97 until I can sort them out. I did change a tiny thing on
the 0.98 license. It should be the upstream author of ibwebadmin and not
the upstream author of JSRS to make the linking exception. I already
contacted upstream ibwebadmin about it and it will be in the next release.

> b) at the top of LICENSE file, which is otherwise pure GPL? This
> exception seems to fit more into a file that would be called i.e.
> COPYING, where the copying informations would be held and which
> would contain the "exception" and reference to the pure GPL in LICENSE
> file.

My understanding was that the exception was a part of the legal agreement
regarding the copyright. In other words, a license. This is were I advised
upstream to put it. Maybe I was mistaken?

> I saw you already contacted upstream about it, but *they* should release
> a version that contains the new COPYING rules.

They will. If it is a problem I'll wait for it before asking for an upload
to unstable. I thought it was ok to proceed at least to mentors.debian.net
to request comments.
 
> 2. I don't like the "No Nonsense Copyright and License for JSRS
> JavaScript Remote Scripting".  It seems that debian-legal didn't like
> it either.  Again you should try to contact upstream and explain
> the problem.  Dual licensing w/ GPL (or LGPL) would be an option that
> would also eliminate all problems mentioned in 1) by eliminating the
> need for an exception.

Upstream JSRS prefered to keep his license and go for the linking exception.
Debian-legal asserted that that was a solution. See:

http://lists.debian.org/debian-legal/2004/05/msg00799.html

and the surrounding thread. They think it is DFSG free and an linking exception
would solve the incompatibility.

Cheers,
Remco.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: why are these packages in testing?

[Steve Langasek]

On Mon, Jun 07, 2004 at 12:02:01PM +0200, Andreas Barth wrote:

> Similar, for libapache-mod-filter, there is:
> [EMAIL PROTECTED]:~$ madison libapache-mod-filter
> libapache-mod-filter |  1.4-5 |stable | source, alpha, arm, hppa, i386, 
> ia64, m68k, mips, mipsel, powerpc, s390, sparc
> libapache-mod-filter |  1.4-8 |   testing | source, alpha, arm, hppa, i386, 
> ia64, m68k, mips, mipsel, powerpc, s390, sparc
> libapache-mod-filter |  1.4-8 |  unstable | source, alpha, arm, hppa, i386, 
> ia64, m68k, mips, mipsel, powerpc, s390, sparc
> [EMAIL PROTECTED]:~$
> but there is also a removal suggestion, and the excuses-file on
> ftp-master says according to
> http://bjorn.haxx.se/debian/testing.pl?package=libapache-mod-filter
> that this package is removed today from testing. So, why is this still
> there? How many hours after the generation of the excuses list are the
> packages really updated?

Packages are not actually removed from the Packages file until dinstall,
which runs roughly 18 hours after the testing scripts finish generating
update_excuses.  I don't know what time the mirror on merkel is updated.

FWIW, I'm not sure this kind of question is appropriate for
debian-mentors; surely this would be better on debian-devel?

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: [Pkg-firebird-general] Request for comments for ibwebadmin package

[Remco Seesink]

> 2. I don't like the "No Nonsense Copyright and License for JSRS
> JavaScript Remote Scripting".  It seems that debian-legal didn't like
> it either.  Again you should try to contact upstream and explain
> the problem. Dual licensing w/ GPL (or LGPL) would be an option

Aargh. I somehow missed:
http://lists.debian.org/debian-legal/2004/05/msg00824.html

sniff OK, i'll contact upstream JSRS. This is serious enough right?

Cheers,
Remco.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Pkg-firebird-general] Request for comments for ibwebadmin package

[Colin Watson]

On Tue, Jun 08, 2004 at 09:16:52AM -0400, Grzegorz B. Prokopski wrote:
> On Mon, 2004-06-07 at 19:12, Remco Seesink wrote:
> > I am looking for comments about my packaging of ibwebadmin.
> > Testers are also welcome.
> 
> Hi Remco,
> 
> Technically I looked fine for me.  I have not tested it at runtime
> though. In the non-technical part - I see troubles with the
> copyright/licensing stuff.
> 
> 1. Why do *you* add the exception that permits for linking w/ some
> GPL-incompatible program
> a) in a debian-specific diff?  The exception has to be granted by
> upstream and they have to release a version that has this exception.
> You must not add it yourself!
> b) at the top of LICENSE file, which is otherwise pure GPL? This
> exception seems to fit more into a file that would be called i.e.
> COPYING, where the copying informations would be held and which
> would contain the "exception" and reference to the pure GPL in LICENSE
> file.
> 
> I saw you already contacted upstream about it, but *they* should release
> a version that contains the new COPYING rules.

I haven't looked at this particular case, but it should be just fine to
say "the copyright owner gave permission to do this" (as long as it's
not specific to Debian, etc.), without necessarily having to wait for a
new upstream release. Of course, I'd be inclined to include the full
text of the e-mail in question.

-- 
Colin Watson  [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: why are these packages in testing?

[Steve Langasek]

On Mon, Jun 07, 2004 at 12:36:00PM +0200, Jeroen van Wolffelaar wrote:
> Note that the testing output says removal fails due to buggyness of the
> package: http://packages.qa.debian.org/a/aiksaurus.html

> # Trying to remove package, not update it
> # libaiksaurus-data (alpha, arm, hppa, i386, ia64, m68k, mips, mipsel,
>   powerpc, s390, sparc) is buggy! (1 > 0)

No, these are two unrelated statements about the same package.  The
first states that a removal has been requested, the second explains why
the package would not be updated in testing even if the removal request
was *not* in place.

However, removal requests also need to respect the integrity of testing
as a releasable whole, so if removing the requested package would make
other packages uninstallable, the removal request fails until this is
dealt with manually.  In this case, abiword and lyx are the packages
that block its removal, as per the update_output.txt report.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: [Pkg-firebird-general] Request for comments for ibwebadmin package

[Remco Seesink]

> 2. I don't like the "No Nonsense Copyright and License for JSRS
> JavaScript Remote Scripting".  It seems that debian-legal didn't like
> it either.  Again you should try to contact upstream and explain
> the problem. Dual licensing w/ GPL (or LGPL) would be an option

Aargh. I somehow missed:
http://lists.debian.org/debian-legal/2004/05/msg00824.html

sniff OK, i'll contact upstream JSRS. This is serious enough right?

Cheers,
Remco.

Re: Request for retrying build of libopenhbci-plugin-ddvcard on arm

[Adeodato Simó]

* Goswin von Brederlow [Sun, 06 Jun 2004 19:24:49 +0200]:

> > P.S.: Of course, if there is a better place to ask about a build on a
> > specific arch, I'll gladly take any advice.

> [EMAIL PROTECTED] ?

  is this the right place to ask for a rebuild? i posted in [EMAIL PROTECTED]
  some time ago (see #251284 if interested), but got no response from
  the porters.

  also, is that address documented anywhere?

  thanks,

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
Listening to: Luis Eduardo Aute - Aleluya nº 1
 
Kindness is a language which the deaf can hear and the blind can read.
-- Mark Twain

Re: [Pkg-firebird-general] Request for comments for ibwebadmin package

[Remco Seesink]

> I haven't looked at this particular case, but it should be just fine to
> say "the copyright owner gave permission to do this" (as long as it's
> not specific to Debian, etc.), without necessarily having to wait for a
> new upstream release. Of course, I'd be inclined to include the full
> text of the e-mail in question.
I will include the e-mail into the next upload.

Cheers,
Remco.

Re: [Pkg-firebird-general] Request for comments for ibwebadmin package

[Remco Seesink]

> 1. Why do *you* add the exception that permits for linking w/ some
> GPL-incompatible program
> a) in a debian-specific diff?  The exception has to be granted by
> upstream and they have to release a version that has this exception.
> You must not add it yourself!

The license is from the 0.98 version. 0.98 had some problems which is why I
reverted to 0.97 until I can sort them out. I did change a tiny thing on
the 0.98 license. It should be the upstream author of ibwebadmin and not
the upstream author of JSRS to make the linking exception. I already
contacted upstream ibwebadmin about it and it will be in the next release.

> b) at the top of LICENSE file, which is otherwise pure GPL? This
> exception seems to fit more into a file that would be called i.e.
> COPYING, where the copying informations would be held and which
> would contain the "exception" and reference to the pure GPL in LICENSE
> file.

My understanding was that the exception was a part of the legal agreement
regarding the copyright. In other words, a license. This is were I advised
upstream to put it. Maybe I was mistaken?

> I saw you already contacted upstream about it, but *they* should release
> a version that contains the new COPYING rules.

They will. If it is a problem I'll wait for it before asking for an upload
to unstable. I thought it was ok to proceed at least to mentors.debian.net
to request comments.
 
> 2. I don't like the "No Nonsense Copyright and License for JSRS
> JavaScript Remote Scripting".  It seems that debian-legal didn't like
> it either.  Again you should try to contact upstream and explain
> the problem.  Dual licensing w/ GPL (or LGPL) would be an option that
> would also eliminate all problems mentioned in 1) by eliminating the
> need for an exception.

Upstream JSRS prefered to keep his license and go for the linking exception.
Debian-legal asserted that that was a solution. See:

http://lists.debian.org/debian-legal/2004/05/msg00799.html

and the surrounding thread. They think it is DFSG free and an linking exception
would solve the incompatibility.

Cheers,
Remco.

Re: [Pkg-firebird-general] Request for comments for ibwebadmin package

[Colin Watson]

On Tue, Jun 08, 2004 at 09:16:52AM -0400, Grzegorz B. Prokopski wrote:
> On Mon, 2004-06-07 at 19:12, Remco Seesink wrote:
> > I am looking for comments about my packaging of ibwebadmin.
> > Testers are also welcome.
> 
> Hi Remco,
> 
> Technically I looked fine for me.  I have not tested it at runtime
> though. In the non-technical part - I see troubles with the
> copyright/licensing stuff.
> 
> 1. Why do *you* add the exception that permits for linking w/ some
> GPL-incompatible program
> a) in a debian-specific diff?  The exception has to be granted by
> upstream and they have to release a version that has this exception.
> You must not add it yourself!
> b) at the top of LICENSE file, which is otherwise pure GPL? This
> exception seems to fit more into a file that would be called i.e.
> COPYING, where the copying informations would be held and which
> would contain the "exception" and reference to the pure GPL in LICENSE
> file.
> 
> I saw you already contacted upstream about it, but *they* should release
> a version that contains the new COPYING rules.

I haven't looked at this particular case, but it should be just fine to
say "the copyright owner gave permission to do this" (as long as it's
not specific to Debian, etc.), without necessarily having to wait for a
new upstream release. Of course, I'd be inclined to include the full
text of the e-mail in question.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: [Pkg-firebird-general] Request for comments for ibwebadmin package

[Grzegorz B. Prokopski]

On Mon, 2004-06-07 at 19:12, Remco Seesink wrote:
> Hello,
> 
> I am looking for comments about my packaging of ibwebadmin.
> Testers are also welcome.

Hi Remco,

Technically I looked fine for me.  I have not tested it at runtime
though. In the non-technical part - I see troubles with the
copyright/licensing stuff.

1. Why do *you* add the exception that permits for linking w/ some
GPL-incompatible program
a) in a debian-specific diff?  The exception has to be granted by
upstream and they have to release a version that has this exception.
You must not add it yourself!
b) at the top of LICENSE file, which is otherwise pure GPL? This
exception seems to fit more into a file that would be called i.e.
COPYING, where the copying informations would be held and which
would contain the "exception" and reference to the pure GPL in LICENSE
file.

I saw you already contacted upstream about it, but *they* should release
a version that contains the new COPYING rules.

[ b) is not a must, but a) might necessary for such package to enter
the official archive IMO ]

2. I don't like the "No Nonsense Copyright and License for JSRS
JavaScript Remote Scripting".  It seems that debian-legal didn't like
it either.  Again you should try to contact upstream and explain
the problem.  Dual licensing w/ GPL (or LGPL) would be an option that
would also eliminate all problems mentioned in 1) by eliminating the
need for an exception.

HTH

Grzegorz B. Prokopski

RFS: libapache2-mod-ldap-userdir - An Apache2 module that provides UserDir lookups via LDAP

[John Morrissey]

I maintain mod_ldap_userdir and am interested in packaging it for Debian. It
allows UserDir URLs to be looked up based on homeDirectory attributes in an
LDAP directory instead of from local user accounts.

In the past year or two, several Debian users have mentioned using it, so
I'd like to package it. I'm also using Debian more and more in the server
environment, so I have a vested interest in maintaining the package. :-)

I do have one question about the packaging: lintian(1) complains that the
.so module defines RPATH, but I don't have any control over that since
compilation is handled entirely by apxs. Should I try to eliminate this, or
just add an override for it?

Package files are available from http://horde.net/~jwm/debian/. Thanks!

* Package name  : libapache2-mod-ldap-userdir
  Version   : 1.1.4
  Upstream Author   : John Morrissey <[EMAIL PROTECTED]>
* URL   : http://horde.net/~jwm/software/mod_ldap_userdir/
* License   : GPL version 2 or above
  Description   : Apache2 module that provides UserDir lookups via LDAP

  This module implements UserDir (~/public_html/) directory lookups using
  data from an LDAP directory.
  .
  This package provides the module for the Apache 2.0 server.

john
-- 
John Morrissey  _o/\   __o
[EMAIL PROTECTED]_-< \_  /  \     <  \,
www.horde.net/__(_)/_(_)/\___(_) /_(_)__

RFS: netdump -- Dump kernel crash information over the network

[Chirag Kantharia]

Hi!

I've just uploaded netdump package to mentors.debian.net and now am
seeking for a sponsor for this package.

The netdump client sets up the kernel to send crash dumps and/or
console messages as syslog packets to a remote system.

The netdump server listens to the network for crashed kernels to
contact it and then writes the oops log and a memory dump to
/var/crash before asking the crashed machine to reboot.

Netdump relies on CONFIG_NETCONSOLE=m set in the kernel configuration,
which is not present in 2.4 series Debian kernels, but is present in
2.6 series Debian kernels. So the package will not work with 2.4
Debian kernels.

Netdump was developed at RedHat, and so, the source code is available
only in form of an .srpm. How does one go about the debian/watch file,
in such cases?

More information about netdump can be got from:
http://www.redhat.com/support/wpapers/redhat/netdump/

Regards,

-- 
Chirag Kantharia, [EMAIL PROTECTED]


pgpuhqHWKUNsR.pgp
Description: PGP signature

Re: [Pkg-firebird-general] Request for comments for ibwebadmin package

[Grzegorz B. Prokopski]

On Mon, 2004-06-07 at 19:12, Remco Seesink wrote:
> Hello,
> 
> I am looking for comments about my packaging of ibwebadmin.
> Testers are also welcome.

Hi Remco,

Technically I looked fine for me.  I have not tested it at runtime
though. In the non-technical part - I see troubles with the
copyright/licensing stuff.

1. Why do *you* add the exception that permits for linking w/ some
GPL-incompatible program
a) in a debian-specific diff?  The exception has to be granted by
upstream and they have to release a version that has this exception.
You must not add it yourself!
b) at the top of LICENSE file, which is otherwise pure GPL? This
exception seems to fit more into a file that would be called i.e.
COPYING, where the copying informations would be held and which
would contain the "exception" and reference to the pure GPL in LICENSE
file.

I saw you already contacted upstream about it, but *they* should release
a version that contains the new COPYING rules.

[ b) is not a must, but a) might necessary for such package to enter
the official archive IMO ]

2. I don't like the "No Nonsense Copyright and License for JSRS
JavaScript Remote Scripting".  It seems that debian-legal didn't like
it either.  Again you should try to contact upstream and explain
the problem.  Dual licensing w/ GPL (or LGPL) would be an option that
would also eliminate all problems mentioned in 1) by eliminating the
need for an exception.

HTH

Grzegorz B. Prokopski



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RFS: libapache2-mod-ldap-userdir - An Apache2 module that provides UserDir lookups via LDAP

[John Morrissey]

I maintain mod_ldap_userdir and am interested in packaging it for Debian. It
allows UserDir URLs to be looked up based on homeDirectory attributes in an
LDAP directory instead of from local user accounts.

In the past year or two, several Debian users have mentioned using it, so
I'd like to package it. I'm also using Debian more and more in the server
environment, so I have a vested interest in maintaining the package. :-)

I do have one question about the packaging: lintian(1) complains that the
.so module defines RPATH, but I don't have any control over that since
compilation is handled entirely by apxs. Should I try to eliminate this, or
just add an override for it?

Package files are available from http://horde.net/~jwm/debian/. Thanks!

* Package name  : libapache2-mod-ldap-userdir
  Version   : 1.1.4
  Upstream Author   : John Morrissey <[EMAIL PROTECTED]>
* URL   : http://horde.net/~jwm/software/mod_ldap_userdir/
* License   : GPL version 2 or above
  Description   : Apache2 module that provides UserDir lookups via LDAP

  This module implements UserDir (~/public_html/) directory lookups using
  data from an LDAP directory.
  .
  This package provides the module for the Apache 2.0 server.

john
-- 
John Morrissey  _o/\   __o
[EMAIL PROTECTED]_-< \_  /  \     <  \,
www.horde.net/__(_)/_(_)/\___(_) /_(_)__


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RFS: netdump -- Dump kernel crash information over the network

[Chirag Kantharia]

Hi!

I've just uploaded netdump package to mentors.debian.net and now am
seeking for a sponsor for this package.

The netdump client sets up the kernel to send crash dumps and/or
console messages as syslog packets to a remote system.

The netdump server listens to the network for crashed kernels to
contact it and then writes the oops log and a memory dump to
/var/crash before asking the crashed machine to reboot.

Netdump relies on CONFIG_NETCONSOLE=m set in the kernel configuration,
which is not present in 2.4 series Debian kernels, but is present in
2.6 series Debian kernels. So the package will not work with 2.4
Debian kernels.

Netdump was developed at RedHat, and so, the source code is available
only in form of an .srpm. How does one go about the debian/watch file,
in such cases?

More information about netdump can be got from:
http://www.redhat.com/support/wpapers/redhat/netdump/

Regards,

-- 
Chirag Kantharia, [EMAIL PROTECTED]


pgpiFJXlneCf4.pgp
Description: PGP signature

Re: How to get package in main with the same version to upgrade over a mentors.debian.net version?

[Nico Golde]

Hello Geert,

* Geert Stappers <[EMAIL PROTECTED]> [2004-06-08 15:08]:
[...] 
> > But if the NMU is a new upstream version 1.2, then the correct NMU
> > version is 1.2-0.1.  This is in the Debian Developer's Reference:
> > 
> >  "If it is absolutely necessary for someone other than the usual main-
> >  tainer to make a release based on a new upstream version then the person
> >  making the release should start with the debian-revision value `0.1'."
> > 
> >  -- DDR 5.11.4.1: Source NMU version numbering
> 
> Okay, that reads like:
>  If there is no offical Debian maintainer yet, then use -0.1.
> 
> Also there is no harm in that it looks a like a NMU,
> it _says_ there is no one in Debian maintaining the package.

no, the version have nothing to do with this. you cannot read out of the
version, if the package is from an official maintainer or not and if it
is an official debian archive.
regards nico
-- 
Nico Golde - [EMAIL PROTECTED]
[EMAIL PROTECTED] | [EMAIL PROTECTED] | http://www.ngolde.de
GPG: FF46 E565 5CC1 E2E5 3F69  C739 1D87 E549 7364 7CFF
Is there life after /sbin/halt -p?


pgpB5P3J1fSWv.pgp
Description: PGP signature

Re: Package review and comment wanted

[Bengt Thuree]

Frank Küster wrote:



You should try to separate non-debian-specific and debian-specific
parts, IMO.

I have been trying to keep to standard Bourne Shell so it should be ok.
I will try to package it in a normal tar file with (bin, etc, etc)


not exist or something like this. I ended up having to put ALL my
expected directories in this debian/dirs file. 



This shows that you are missing a proper install target in your toplevel
Makefile, I'd say. 
Could be, I did not create the directories in the rules file. Only 
copied the files to the proper place. I guess I should create the 
directories first. As I am now doing in the Makefile.



Then the installation
went very fine. But when I tried to remove the package, it also tried
to remove /usr/sbin

This is strange, and usually does not occur. I should have a different
reason than the directory being listed in debian/dirs.

Guess I need to trouble shoot a bit more on this one... :)


I wouldn't put the intermediate files into the debian
directory. However, in the sources I downloaded there where manpages in
the debian directory before I did any call to debian/rules. They
shouldn't be there if they are generated upon installation.

I generate them when I am building the package.


one of them is sufficient, you should lower the dependency on afio to
Suggests or Recommends, depending on the functionality.
Actually I use afio, tar, as well as gzip2 but for a few different 
files. The main one is done with afio and then tared into one big file 
for easier housekeeping.




Regards, Frank


/Bengt

Re: How to get package in main with the same version to upgrade over a mentors.debian.net version?

[Nico Golde]

Hello Geert,

* Geert Stappers <[EMAIL PROTECTED]> [2004-06-08 15:08]:
[...] 
> > But if the NMU is a new upstream version 1.2, then the correct NMU
> > version is 1.2-0.1.  This is in the Debian Developer's Reference:
> > 
> >  "If it is absolutely necessary for someone other than the usual main-
> >  tainer to make a release based on a new upstream version then the person
> >  making the release should start with the debian-revision value `0.1'."
> > 
> >  -- DDR 5.11.4.1: Source NMU version numbering
> 
> Okay, that reads like:
>  If there is no offical Debian maintainer yet, then use -0.1.
> 
> Also there is no harm in that it looks a like a NMU,
> it _says_ there is no one in Debian maintaining the package.

no, the version have nothing to do with this. you cannot read out of the
version, if the package is from an official maintainer or not and if it
is an official debian archive.
regards nico
-- 
Nico Golde - [EMAIL PROTECTED]
[EMAIL PROTECTED] | [EMAIL PROTECTED] | http://www.ngolde.de
GPG: FF46 E565 5CC1 E2E5 3F69  C739 1D87 E549 7364 7CFF
Is there life after /sbin/halt -p?


pgpQkVLVlfPuK.pgp
Description: PGP signature

Re: How to get package in main with the same version to upgrade over a mentors.debian.net version?

[Jeroen van Wolffelaar]

On Tue, Jun 08, 2004 at 11:58:26AM +0200, Geert Stappers wrote:
> On Fri, Jun 04, 2004 at 10:03:52AM -0700, Matt Brubeck wrote:
> > But if the NMU is a new upstream version 1.2, then the correct NMU
> > version is 1.2-0.1.  This is in the Debian Developer's Reference:
> > 
> >  "If it is absolutely necessary for someone other than the usual main-
> >  tainer to make a release based on a new upstream version then the person
> >  making the release should start with the debian-revision value `0.1'."
> > 
> >  -- DDR 5.11.4.1: Source NMU version numbering
> 
> Okay, that reads like:
>  If there is no offical Debian maintainer yet, then use -0.1.

Policy only discusses verion number rules for uploaded versions, it
doesn't discuss version numbers for private use. Use common sense for
that, for example, either of the three possibilities I posted earlier
(with advantages/disadvanteges even).
 
> Also there is no harm in that it looks a like a NMU,

It is confusing, but since it's unofficial, you'll only hurt yourself
and your beta-testers.

> it _says_ there is no one in Debian maintaining the package.

No, this is plainly wrong, the version number an sich doesn't say
anything about whether or not somebody in Debian is maintaining the
package. Only the Maintainer: field of the latest package in sid days
so, possibly with hints to future changes in wnpp.

--Jeroen

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl

Re: RFC: potracegui -- is a KDE frontend for potrace

[Andreas Metzler]

On 2004-06-08 Christoph Wegscheider <[EMAIL PROTECTED]> wrote:
[...]
> 2.) Is there an easy way to untighten the automatically (${shlibs:Depends})
> generated Depends? I mean, maybe a lower version of a lib would also do
> (having testing/unstable user in mind).
[...]

You could specify the dependoncies manually, but do NOT do that, the
dependencies are that strict for a reason, the library maintainer
*explicitely* requested "any package linking against this library must
use this dependencies". Usually it is a fair bet that the library
maintainer knows his package better than you.

See policy 8.6.
   cu andreas

Re: How to get package in main with the same version to upgrade over a mentors.debian.net version?

[Geert Stappers]

On Fri, Jun 04, 2004 at 10:03:52AM -0700, Matt Brubeck wrote:
> Goswin von Brederlow wrote:
> 
> > > If the current version in the archive is 1.1, and you upload an NMU
> > > of 1.2, that NMU should be 1.2-0.1 (so that a maintainer upload of
> > > 1.2-1 supersedes it).
> >
> > It should be 1.1-0.1 so a maintainer upload of 1.2 superseeds it.
> 
> But if the NMU is a new upstream version 1.2, then the correct NMU
> version is 1.2-0.1.  This is in the Debian Developer's Reference:
> 
>  "If it is absolutely necessary for someone other than the usual main-
>  tainer to make a release based on a new upstream version then the person
>  making the release should start with the debian-revision value `0.1'."
> 
>  -- DDR 5.11.4.1: Source NMU version numbering

Okay, that reads like:
 If there is no offical Debian maintainer yet, then use -0.1.

Also there is no harm in that it looks a like a NMU,
it _says_ there is no one in Debian maintaining the package.

 
> 
> Also, if you upload 1.2-1, and later use 1.2-0.1 as a "test" version,
> then the test version appears to be older than the uploaded version.
> Instead, you should call the test version 1.2-1test1, which is clearly
> between 1.2-1 and 1.2-2.

(-:   start with -0 ( e.g. -0test1, -0sss1 -0.1 )
so that -1 can enter the offical Debian archive. :-)


Cheers
Geert Stappers

Re: Adoption for python-gd, looking for sponsors

[Geert Stappers]

On Tue, Jun 08, 2004 at 11:13:47AM +0200, Fabio Tranchitella wrote:
> Hi, I'm interested in adoptiong python-gd but I'm not (yet) a DD.
> I'm started my application process few weeks ago and my first official
> package (phpldapadmin) is already in unstable.
> 
> I'm looking for someone interested in sponsoring me to adopt python-gd.
> 
> I've packaged python-gd adding supports also for older version of Python
> (closing bug #223580) because actually the package supports only
> python2.3. Now it builds three binary packages (python2.1-gd,
> python2.2-gd and python2.3-gd and a dummy package python-gd).
> 
> My work is available on http://www.kobold.it/python-gd/
> 
> Thanks in advance,

Have you contacted debian-python@lists.debian.org ?
( they are now reading your RFS )

> F.

Cheers
Geert Stappers

Re: Package review and comment wanted

[Bengt Thuree]

Frank Küster wrote:

You should try to separate non-debian-specific and debian-specific
parts, IMO.
I have been trying to keep to standard Bourne Shell so it should be ok.
I will try to package it in a normal tar file with (bin, etc, etc)
not exist or something like this. I ended up having to put ALL my
expected directories in this debian/dirs file. 

This shows that you are missing a proper install target in your toplevel
Makefile, I'd say. 
Could be, I did not create the directories in the rules file. Only 
copied the files to the proper place. I guess I should create the 
directories first. As I am now doing in the Makefile.

Then the installation
went very fine. But when I tried to remove the package, it also tried
to remove /usr/sbin
This is strange, and usually does not occur. I should have a different
reason than the directory being listed in debian/dirs.
Guess I need to trouble shoot a bit more on this one... :)
I wouldn't put the intermediate files into the debian
directory. However, in the sources I downloaded there where manpages in
the debian directory before I did any call to debian/rules. They
shouldn't be there if they are generated upon installation.
I generate them when I am building the package.
one of them is sufficient, you should lower the dependency on afio to
Suggests or Recommends, depending on the functionality.
Actually I use afio, tar, as well as gzip2 but for a few different 
files. The main one is done with afio and then tared into one big file 
for easier housekeeping.

Regards, Frank
/Bengt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: release as a package or add to APT's file list?

[Martin-Éric Racine]

On Thu, 20 May 2004, Martin-Éric Racine wrote:

> I thank everyone who contributed ideas for the script.

Some of those ideas have now been implemented. Add this to sources.list to test:

deb http://funkyware.konflux.at debian/

Now, unless anybody strongly objects, the package will be submitted to unstable.

-- 
Martin-Éric Racine, ICT Consultant
http://www.pp.fishpool.fi/~q-funk/

Re: RFC: potracegui -- is a KDE frontend for potrace

[Benjamin Cutler]

Christoph Wegscheider wrote:

I also have some questions:

1.) Is a successfull pbuilder build a guaranty for correct Build-Depends?



As long as you haven't mucked with the settings and installed extra 
packages in the pbuilder chroot by default, this is one of the best ways 
to be sure, yes.



2.) Is there an easy way to untighten the automatically (${shlibs:Depends})
generated Depends? I mean, maybe a lower version of a lib would also do
(having testing/unstable user in mind).



I'm pretty sure this is by design, hand-tweaked shlibdeps are asking for 
trouble. The 'old version' thing is generally not an issue, any testing 
user can do 'apt-get -t unstable install libblah' to force the issue. I 
have to do this occasionally.



3.) I have a testing/unstable installation. Is it OK to use it as build
plattform or 
* should I release only pbuilder build debs

* should I simply upgrade all (Build-)Depends to unstable
* must I dist-upgrade to sid?



Even if you're on sid it's a good idea to use pbuilder to verify 
Build-Deps, so upgrading to sid for package building purposes is mostly 
pointless.



4.) What are the (maybe informal) requirements for an RFS? e.g.: making
packages for half a year; having made at least 5 packages; being able to
recite every policy section within 5 seconds ;)



Anybody can make an RFS from what I can tell, but you won't get any 
takers if your package is 'improper'.

Re: RFC: potracegui -- is a KDE frontend for potrace

[Christoph Wegscheider]

I just uploaded potracegui_0.5.1-2 to mentors.debian.net hopefully
correcting all outstanding issues, appreciating any further comments.

potracegui (0.5.1-2) unstable; urgency=low

  * adjusting the copyright file and the package description.
  * fixed Build-Depends.
  * Closes: #253205: ITP: potracegui -- a KDE frontend for potrace.
  * Recommends now imagemagick, needed for displaying tracing results.


I also have some questions:

1.) Is a successfull pbuilder build a guaranty for correct Build-Depends?

2.) Is there an easy way to untighten the automatically (${shlibs:Depends})
generated Depends? I mean, maybe a lower version of a lib would also do
(having testing/unstable user in mind).

3.) I have a testing/unstable installation. Is it OK to use it as build
plattform or 
* should I release only pbuilder build debs
* should I simply upgrade all (Build-)Depends to unstable
* must I dist-upgrade to sid?

4.) What are the (maybe informal) requirements for an RFS? e.g.: making
packages for half a year; having made at least 5 packages; being able to
recite every policy section within 5 seconds ;)


Christoph

Adoption for python-gd, looking for sponsors

[Fabio Tranchitella]

Hi, I'm interested in adoptiong python-gd but I'm not (yet) a DD.
I'm started my application process few weeks ago and my first official
package (phpldapadmin) is already in unstable.

I'm looking for someone interested in sponsoring me to adopt python-gd.

I've packaged python-gd adding supports also for older version of Python
(closing bug #223580) because actually the package supports only
python2.3. Now it builds three binary packages (python2.1-gd,
python2.2-gd and python2.3-gd and a dummy package python-gd).

My work is available on http://www.kobold.it/python-gd/

Thanks in advance,
F.

-- 
 
Fabio Tranchitella
 
 kobold.it, Turin, Italy  - Free is better!
 
---
 , <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
---
GPG Key fingerprint: 5465 6E69 E559 6466 BF3D  9F01 2BF8 EE2B 7F96 1564



signature.asc
Description: Questa parte del messaggio è firmata

Re: How to get package in main with the same version to upgrade over a mentors.debian.net version?

[Jeroen van Wolffelaar]

On Tue, Jun 08, 2004 at 11:58:26AM +0200, Geert Stappers wrote:
> On Fri, Jun 04, 2004 at 10:03:52AM -0700, Matt Brubeck wrote:
> > But if the NMU is a new upstream version 1.2, then the correct NMU
> > version is 1.2-0.1.  This is in the Debian Developer's Reference:
> > 
> >  "If it is absolutely necessary for someone other than the usual main-
> >  tainer to make a release based on a new upstream version then the person
> >  making the release should start with the debian-revision value `0.1'."
> > 
> >  -- DDR 5.11.4.1: Source NMU version numbering
> 
> Okay, that reads like:
>  If there is no offical Debian maintainer yet, then use -0.1.

Policy only discusses verion number rules for uploaded versions, it
doesn't discuss version numbers for private use. Use common sense for
that, for example, either of the three possibilities I posted earlier
(with advantages/disadvanteges even).
 
> Also there is no harm in that it looks a like a NMU,

It is confusing, but since it's unofficial, you'll only hurt yourself
and your beta-testers.

> it _says_ there is no one in Debian maintaining the package.

No, this is plainly wrong, the version number an sich doesn't say
anything about whether or not somebody in Debian is maintaining the
package. Only the Maintainer: field of the latest package in sid days
so, possibly with hints to future changes in wnpp.

--Jeroen

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFC: potracegui -- is a KDE frontend for potrace

[Andreas Metzler]

On 2004-06-08 Christoph Wegscheider <[EMAIL PROTECTED]> wrote:
[...]
> 2.) Is there an easy way to untighten the automatically (${shlibs:Depends})
> generated Depends? I mean, maybe a lower version of a lib would also do
> (having testing/unstable user in mind).
[...]

You could specify the dependoncies manually, but do NOT do that, the
dependencies are that strict for a reason, the library maintainer
*explicitely* requested "any package linking against this library must
use this dependencies". Usually it is a fair bet that the library
maintainer knows his package better than you.

See policy 8.6.
   cu andreas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to get package in main with the same version to upgrade over a mentors.debian.net version?

[Geert Stappers]

On Fri, Jun 04, 2004 at 10:03:52AM -0700, Matt Brubeck wrote:
> Goswin von Brederlow wrote:
> 
> > > If the current version in the archive is 1.1, and you upload an NMU
> > > of 1.2, that NMU should be 1.2-0.1 (so that a maintainer upload of
> > > 1.2-1 supersedes it).
> >
> > It should be 1.1-0.1 so a maintainer upload of 1.2 superseeds it.
> 
> But if the NMU is a new upstream version 1.2, then the correct NMU
> version is 1.2-0.1.  This is in the Debian Developer's Reference:
> 
>  "If it is absolutely necessary for someone other than the usual main-
>  tainer to make a release based on a new upstream version then the person
>  making the release should start with the debian-revision value `0.1'."
> 
>  -- DDR 5.11.4.1: Source NMU version numbering

Okay, that reads like:
 If there is no offical Debian maintainer yet, then use -0.1.

Also there is no harm in that it looks a like a NMU,
it _says_ there is no one in Debian maintaining the package.

 
> 
> Also, if you upload 1.2-1, and later use 1.2-0.1 as a "test" version,
> then the test version appears to be older than the uploaded version.
> Instead, you should call the test version 1.2-1test1, which is clearly
> between 1.2-1 and 1.2-2.

(-:   start with -0 ( e.g. -0test1, -0sss1 -0.1 )
so that -1 can enter the offical Debian archive. :-)


Cheers
Geert Stappers


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Adoption for python-gd, looking for sponsors

[Geert Stappers]

On Tue, Jun 08, 2004 at 11:13:47AM +0200, Fabio Tranchitella wrote:
> Hi, I'm interested in adoptiong python-gd but I'm not (yet) a DD.
> I'm started my application process few weeks ago and my first official
> package (phpldapadmin) is already in unstable.
> 
> I'm looking for someone interested in sponsoring me to adopt python-gd.
> 
> I've packaged python-gd adding supports also for older version of Python
> (closing bug #223580) because actually the package supports only
> python2.3. Now it builds three binary packages (python2.1-gd,
> python2.2-gd and python2.3-gd and a dummy package python-gd).
> 
> My work is available on http://www.kobold.it/python-gd/
> 
> Thanks in advance,

Have you contacted [EMAIL PROTECTED] ?
( they are now reading your RFS )

> F.

Cheers
Geert Stappers


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: release as a package or add to APT's file list?

[Martin-Éric Racine]

On Thu, 20 May 2004, Martin-Éric Racine wrote:

> I thank everyone who contributed ideas for the script.

Some of those ideas have now been implemented. Add this to sources.list to test:

deb http://funkyware.konflux.at debian/

Now, unless anybody strongly objects, the package will be submitted to unstable.

-- 
Martin-Éric Racine, ICT Consultant
http://www.pp.fishpool.fi/~q-funk/

Re: RFC: potracegui -- is a KDE frontend for potrace

[Benjamin Cutler]

Christoph Wegscheider wrote:
I also have some questions:
1.) Is a successfull pbuilder build a guaranty for correct Build-Depends?
As long as you haven't mucked with the settings and installed extra 
packages in the pbuilder chroot by default, this is one of the best ways 
to be sure, yes.

2.) Is there an easy way to untighten the automatically (${shlibs:Depends})
generated Depends? I mean, maybe a lower version of a lib would also do
(having testing/unstable user in mind).
I'm pretty sure this is by design, hand-tweaked shlibdeps are asking for 
trouble. The 'old version' thing is generally not an issue, any testing 
user can do 'apt-get -t unstable install libblah' to force the issue. I 
have to do this occasionally.

3.) I have a testing/unstable installation. Is it OK to use it as build
plattform or 
* should I release only pbuilder build debs
* should I simply upgrade all (Build-)Depends to unstable
* must I dist-upgrade to sid?

Even if you're on sid it's a good idea to use pbuilder to verify 
Build-Deps, so upgrading to sid for package building purposes is mostly 
pointless.

4.) What are the (maybe informal) requirements for an RFS? e.g.: making
packages for half a year; having made at least 5 packages; being able to
recite every policy section within 5 seconds ;)
Anybody can make an RFS from what I can tell, but you won't get any 
takers if your package is 'improper'.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Package review and comment wanted

[Frank Küster]

Bengt Thuree <[EMAIL PROTECTED]> wrote:

>> That depends on the complexity of the installation. In most cases,
>> it is
>> highly advisable to have a separate Makefile that does the compilation
>> and installation, and in debian/rules you only call it with appropriate
>> targets and arguments.
> ok
>> Isn't there a Makefile in the upstream sources?
> Upstream this is the upstream. I created the package

You should try to separate non-debian-specific and debian-specific
parts, IMO.

>>>*) Should I list all the directories in the dirs (including /usr/sbin)
>> In debian/dirs, you only list the directories that you want to create
>> with dh_installdirs - e.g. directories that the upstream Makefiles
> Ok, but when I do not create the usr/sbin directory in the debian/dirs
> file the dpkg-buildpackage -rfakeroot fails with taget directory do
> not exist or something like this. I ended up having to put ALL my
> expected directories in this debian/dirs file. 

This shows that you are missing a proper install target in your toplevel
Makefile, I'd say. 

> Then the installation
> went very fine. But when I tried to remove the package, it also tried
> to remove /usr/sbin

This is strange, and usually does not occur. I should have a different
reason than the directory being listed in debian/dirs.

>> You are packaging this as a Debian native package. You shouldn't do
>> that, unless there is good reason why nobody outside Debian would want
> So, if I am the one who creates this package, should I not create the
> package as a Debian native package?

In my opinion, no. Unfortunately, there doesn't seem to be documentation
written on that. But google helps somewhat to get opinions, e.g. the
thread starting with 

http://lists.debian.org/debian-mentors/2001/01/msg00191.html

>> to use it. This is true for packages like debian-policy or apt-get (or
>> perhaps not even for that one), but most probably not for a backup
>> program. Consequently, you should use the manpages out of the debian
>> directory and install them in the Makefile.
> The Debian man pages are located in the docs folder as xml files, and
> compiled into man pages in the debian directory in the Makefile.

I wouldn't put the intermediate files into the debian
directory. However, in the sources I downloaded there where manpages in
the debian directory before I did any call to debian/rules. They
shouldn't be there if they are generated upon installation.

>> In the description you say that it uses afio and tar, but you don't
>> depend on tar.
> Lintian complain when I was depending upon tar.

Excuse me, I missed that tar is essential. Do you really need both? If
one of them is sufficient, you should lower the dependency on afio to
Suggests or Recommends, depending on the functionality.

Regards, Frank
-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie

Re: RFC: potracegui -- is a KDE frontend for potrace

[Christoph Wegscheider]

I just uploaded potracegui_0.5.1-2 to mentors.debian.net hopefully
correcting all outstanding issues, appreciating any further comments.

potracegui (0.5.1-2) unstable; urgency=low

  * adjusting the copyright file and the package description.
  * fixed Build-Depends.
  * Closes: #253205: ITP: potracegui -- a KDE frontend for potrace.
  * Recommends now imagemagick, needed for displaying tracing results.


I also have some questions:

1.) Is a successfull pbuilder build a guaranty for correct Build-Depends?

2.) Is there an easy way to untighten the automatically (${shlibs:Depends})
generated Depends? I mean, maybe a lower version of a lib would also do
(having testing/unstable user in mind).

3.) I have a testing/unstable installation. Is it OK to use it as build
plattform or 
* should I release only pbuilder build debs
* should I simply upgrade all (Build-)Depends to unstable
* must I dist-upgrade to sid?

4.) What are the (maybe informal) requirements for an RFS? e.g.: making
packages for half a year; having made at least 5 packages; being able to
recite every policy section within 5 seconds ;)


Christoph




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Adoption for python-gd, looking for sponsors

[Fabio Tranchitella]

Hi, I'm interested in adoptiong python-gd but I'm not (yet) a DD.
I'm started my application process few weeks ago and my first official
package (phpldapadmin) is already in unstable.

I'm looking for someone interested in sponsoring me to adopt python-gd.

I've packaged python-gd adding supports also for older version of Python
(closing bug #223580) because actually the package supports only
python2.3. Now it builds three binary packages (python2.1-gd,
python2.2-gd and python2.3-gd and a dummy package python-gd).

My work is available on http://www.kobold.it/python-gd/

Thanks in advance,
F.

-- 
 
Fabio Tranchitella
 
 kobold.it, Turin, Italy  - Free is better!
 
---
 , <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
---
GPG Key fingerprint: 5465 6E69 E559 6466 BF3D  9F01 2BF8 EE2B 7F96 1564



signature.asc
Description: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata

Re: Package review and comment wanted

[Frank Küster]

Bengt Thuree <[EMAIL PROTECTED]> wrote:

>> That depends on the complexity of the installation. In most cases,
>> it is
>> highly advisable to have a separate Makefile that does the compilation
>> and installation, and in debian/rules you only call it with appropriate
>> targets and arguments.
> ok
>> Isn't there a Makefile in the upstream sources?
> Upstream this is the upstream. I created the package

You should try to separate non-debian-specific and debian-specific
parts, IMO.

>>>*) Should I list all the directories in the dirs (including /usr/sbin)
>> In debian/dirs, you only list the directories that you want to create
>> with dh_installdirs - e.g. directories that the upstream Makefiles
> Ok, but when I do not create the usr/sbin directory in the debian/dirs
> file the dpkg-buildpackage -rfakeroot fails with taget directory do
> not exist or something like this. I ended up having to put ALL my
> expected directories in this debian/dirs file. 

This shows that you are missing a proper install target in your toplevel
Makefile, I'd say. 

> Then the installation
> went very fine. But when I tried to remove the package, it also tried
> to remove /usr/sbin

This is strange, and usually does not occur. I should have a different
reason than the directory being listed in debian/dirs.

>> You are packaging this as a Debian native package. You shouldn't do
>> that, unless there is good reason why nobody outside Debian would want
> So, if I am the one who creates this package, should I not create the
> package as a Debian native package?

In my opinion, no. Unfortunately, there doesn't seem to be documentation
written on that. But google helps somewhat to get opinions, e.g. the
thread starting with 

http://lists.debian.org/debian-mentors/2001/01/msg00191.html

>> to use it. This is true for packages like debian-policy or apt-get (or
>> perhaps not even for that one), but most probably not for a backup
>> program. Consequently, you should use the manpages out of the debian
>> directory and install them in the Makefile.
> The Debian man pages are located in the docs folder as xml files, and
> compiled into man pages in the debian directory in the Makefile.

I wouldn't put the intermediate files into the debian
directory. However, in the sources I downloaded there where manpages in
the debian directory before I did any call to debian/rules. They
shouldn't be there if they are generated upon installation.

>> In the description you say that it uses afio and tar, but you don't
>> depend on tar.
> Lintian complain when I was depending upon tar.

Excuse me, I missed that tar is essential. Do you really need both? If
one of them is sufficient, you should lower the dependency on afio to
Suggests or Recommends, depending on the functionality.

Regards, Frank
-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie