Sponsership for libjabber-ruby
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm currently in process of packaging jabber4r, or libjabber-ruby in it's debianized form(ITP #207636), and I'm looking for a sponser to review my work:-) I've followed closely after the current ruby sub-policy, although it seems to be in a draft state - packages are produced for both Ruby 1.6 and 1.8, with 1.8 being the default. Although I'm not sure if that's a correct approach, the package has build-depends on RDoc - upstream do not include pre-generated docs, however, RDoc can be used to produce a usefull reference for the library internals. in anycase those docs are contained in a seperate package as their compressed size is twice larger then the modules themselves, and given the fact we produce 1 "binary" package per Ruby major release, it seemed wise to seperate this piece of bloat:-) the diff/orig/dsc combo(Did I forget anything?) Is available from here: http://idanso.dyndns.org/maps/deb/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/jjNeHT1NNTuNW1YRArMaAKCYw9EYsblc89xMj1iJYNLUIOeAYgCfaVdq fAipZnGcVcwOK/VR502BFS0= =p9Ji -END PGP SIGNATURE-
Re: RFS: Intel's OpenCV library for computer vision applications
On Thursday 09 October 2003 10:01 pm, Daniel A. Nagy wrote: > I am seeking a sponsor for the above mentioned package(s). They claim to be > "Open Source"*, but as far as I could judge from their (rather short) license, > they might be considered non-free from a Debian point of view. Looks DFSG free to me, the license is here: http://www.intel.com/research/mrl/research/opencv/license.htm seems to be a fairly routine non-copyleft free license along the lines of the MIT or BSD, but with original wording. I thought this link might make things a little easier. ;-) Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com
Re: RFS: Intel's OpenCV library for computer vision applications
On Thu, 09 Oct 2003, Daniel A. Nagy wrote: > I am seeking a sponsor for the above mentioned package(s). They claim > to be "Open Source"*, but as far as I could judge from their (rather > short) license, they might be considered non-free from a Debian point > of view. The license looks like a 3 clause BSD to me, and as such is generally considered free under the DFSG. Just for future reference, debian-legal@lists.debian.org is the canonical place to ask Debian related licensing questions. [I totally missed the legal question in your message myself since I'm not a DD and hence can't sponsor your package.] Don Armstrong -- The sheer ponderousness of the panel's opinion ... refutes its thesis far more convincingly than anything I might say. The panel's labored effort to smother the Second Amendment by sheer body weight has all the grace of a sumo wrestler trying to kill a rattlesnake by sitting on it--and is just as likely to succeed. -- Alex Kozinski in Silveira V Lockyer http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu signature.asc Description: Digital signature
RFS lib*-perl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi I'd be very grateful for a sponsor for one or more of the folowing packages: libcgi-xmlapplication-perl -- Perl module for creating XML-DOM and OO based CGI scripts libcgi-xmlform-perl -- Perl module for reading/generating formatted XML libdbix-xmlmessage-perl -- Perl module for exchanging XML messages between DBI data sources libdbd-ram-perl -- Perl DBI driver for files and data structures libparse-yapp-perl -- Perl module for creating fully reentrant LALR parser OO Perl modules libcgi-xml-perl -- Perl module for converting CGI variables from/to XML libdbix-xml-rdb-perl -- Perl module for creating XML from a DBI datasource DBI is the Perl Database Interface (for more info see libdbi-perl) You can find the new packages on deb-src http://zeus.ugent.be/~luk pool/ Thanks in advance Luk -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE/jpZ3At+ECxtXDnwRAjl4AJ9EIdUfZfQrcN0gYke0tRKuLOZ3MgCbBu5M azFpLqfogEBa+9Kk+NsV4nU= =dSje -END PGP SIGNATURE-
gcc 3.3 and __func__ ...
Hello,
I have some code that was using :
printf (__func__ "Message", ...);
This doesn't build anymore with gcc 3.x, since __func__ is treated as a
variable, not a string literal.
What would be the best way of working around this ? Replacing all these
constructs with :
printf ("%sMessage", __func__, ...);
Works, but seems a bit ugly, and there are _lots_ of those lines.
Is there a compiler switch to consider __func__ as string literal or
something such ?
Naturally, using 2.95 kinda works, but i don't think this is a good
idea.
Thanks for your help.
Friendly,
Sven Luther
Re: gcc 3.3 and __func__ ...
On Thu, Oct 16, 2003 at 05:59:43PM +0200, Sven Luther wrote:
> I have some code that was using :
>
> printf (__func__ "Message", ...);
>
> This doesn't build anymore with gcc 3.x, since __func__ is treated as a
> variable, not a string literal.
>
> What would be the best way of working around this ? Replacing all these
> constructs with :
>
> printf ("%sMessage", __func__, ...);
>
> Works, but seems a bit ugly, and there are _lots_ of those lines.
>
> Is there a compiler switch to consider __func__ as string literal or
> something such ?
That behaviour is mandated by ISO C99, so even if it were possible to
override it, the code needs to be fixed.
The gcc-specific __FUNCTION__ and __PRETTY_FUNCTION__ are string literals,
like what is expected here, except in C++, where they act like __func__.
See "(gcc)Function Names". It'd really be best to adapt it to use __func__
properly, since this is a standard which will be honored by other compilers.
--
- mdz
Re: proper way to pack package from multiple sources?
On Tue, Oct 14, 2003 at 11:35:03AM +0200, Magosányi Árpád wrote: > The syslog-ng package consists of two sources: syslog-ng itself, and > libol. > Now the packege is created by unpacking syslog-ng, dropping the libol > tar.gz into the source tree, and adding the debian dir. > It follows that either I build a package which looks like a native > debian package or dpkg-source complains about unrepresentable changes > to source. > I don't want to package libol separately, as it is deprecated: > it is used only by syslog-ng and bwall. The devel version of syslog-ng > does not use it, and bwall's only proxy (ck-gw) made obsolete by the > ZAS authentication method of Zorp. > > Question: what is the proper way to package syslog-ng? Wait for the next release which doesn't require libol, or repackage .orig.tar.gz so that it actually has what you need for building the package. -- - mdz
Re: Splitting a package
On Mon, Oct 13, 2003 at 04:51:12PM +0200, Alberto Gonzalez Iniesta wrote: > I'd like to know if this justifies splitting a package. AFAIK the > size or the existence of shared libs justify splitting a package, but > not this. > > I've got a package that contains a command line program and a couple of > front-ends (motif and KDE) for it. This makes neccessary to install > lots of KDE libs even if you're only using the command line program. > > Would all this Depends justify splitting it into the command line > package and the front-ends one? > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=215502 It is up to you, based on your knowledge of the package and its users, to decide if this makes sense. For example, if the purpose of the CLI is to allow the software to be used without KDE, then it would be sensible to provide it in a separate package to be used with KDE. If it is a program which is meant to be used with the KDE portions, and isn't very useful without them, then it would not make sense. -- - mdz
Splitting a package
I've been in some discussion with another developer. He's decided it would be nice to split out some interface modules for a package. These modules constitute reasonably small single files and copies of the relevant documentation. I'm of the opinion that a few KB is too small for a .deb that could be part of a larger .deb. The advantages however are fewer "dependencies" which I believe should be marked as "Suggests:" in the larger package. So my questions: What's a good general guideline about splitting packages these days? Split packages for these modules would defiantly have some large language "Depends:", would it be good enough for a larger package to merely suggest these or should they be recommended or even depended upon? Imo these modules wouldn't be used much. Thanks Drew Daniels
Re: gcc 3.3 and __func__ ...
On Thu, Oct 16, 2003 at 12:26:42PM -0400, Matt Zimmerman wrote:
> On Thu, Oct 16, 2003 at 05:59:43PM +0200, Sven Luther wrote:
>
> > I have some code that was using :
> >
> > printf (__func__ "Message", ...);
> >
> > This doesn't build anymore with gcc 3.x, since __func__ is treated as a
> > variable, not a string literal.
> >
> > What would be the best way of working around this ? Replacing all these
> > constructs with :
> >
> > printf ("%sMessage", __func__, ...);
> >
> > Works, but seems a bit ugly, and there are _lots_ of those lines.
> >
> > Is there a compiler switch to consider __func__ as string literal or
> > something such ?
>
> That behaviour is mandated by ISO C99, so even if it were possible to
> override it, the code needs to be fixed.
Yes, seemed so to me.
> The gcc-specific __FUNCTION__ and __PRETTY_FUNCTION__ are string literals,
Well, apparently no more in gcc 3.4.
> like what is expected here, except in C++, where they act like __func__.
> See "(gcc)Function Names". It'd really be best to adapt it to use __func__
> properly, since this is a standard which will be honored by other compilers.
What would be the best way to adapt it ? Use the
printf ("%sMessage", __func__, ...);
form ?
Thanks for your reply,
Friendly,
Sven Luther
Re: gcc 3.3 and __func__ ...
On Thu, Oct 16, 2003 at 11:51:12PM +0200, Sven Luther wrote:
> On Thu, Oct 16, 2003 at 12:26:42PM -0400, Matt Zimmerman wrote:
> > See "(gcc)Function Names". It'd really be best to adapt it to use __func__
> > properly, since this is a standard which will be honored by other compilers.
>
> What would be the best way to adapt it ? Use the
>
> printf ("%sMessage", __func__, ...);
>
> form ?
Yes.
--
- mdz
RFS: libdtdparser-java -- Java DTD parser library (closing bug)
Hi mentors, I'd like a sponsor to upload a new package of libdtdparser-java: libdtdparser-java (1.21-6) unstable; urgency=low * changed ANT_HOME (closes: #216123). -- Arnaud Vandyck <[EMAIL PROTECTED]> Fri, 17 Oct 2003 00:16:36 +0200 Usual location: http://vbstefi60.fapse.ulg.ac.be/~arnaud/debian/libdtdparser-java-1.21-6.tar.gz Many thanks for your help and many thanks to Daniel Schelper who found the bug, On Thu, 16 Oct 2003 11:56:48 -0700 Daniel Schepler <[EMAIL PROTECTED]> wrote: > Package: libdtdparser-java > Severity: serious > Version: 1.21-5 > > From my build log (with pbuilder's extraneous LOGNAME messages > removed): > > ... > if test "." != "."; then rmdir .; fi > dh_clean > You must specify a valid ANT_HOME directory! > make: *** [ant-sanity-check] Error 1 > > -- > Daniel Schepler "Please don't disillusion me. I > [EMAIL PROTECTED]haven't had breakfast yet." > -- Orson Scott Card -- .''`. ** Debian GNU/Linux ** : :' : Arnaud Vandyck `. `' http://alioth.debian.org/users/arnaud-guest/ `-http://alioth.debian.org/developer/diary.php?diary_user=2781 jabber: [EMAIL PROTECTED] pgpoJckAa5CPn.pgp Description: PGP signature
(no subject)
unsubscribe
Re: RFS: Intel's OpenCV library for computer vision applications
On Thursday 09 October 2003 10:01 pm, Daniel A. Nagy wrote: > I am seeking a sponsor for the above mentioned package(s). They claim to be > "Open Source"*, but as far as I could judge from their (rather short) license, > they might be considered non-free from a Debian point of view. Looks DFSG free to me, the license is here: http://www.intel.com/research/mrl/research/opencv/license.htm seems to be a fairly routine non-copyleft free license along the lines of the MIT or BSD, but with original wording. I thought this link might make things a little easier. ;-) Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: Intel's OpenCV library for computer vision applications
On Thu, 09 Oct 2003, Daniel A. Nagy wrote: > I am seeking a sponsor for the above mentioned package(s). They claim > to be "Open Source"*, but as far as I could judge from their (rather > short) license, they might be considered non-free from a Debian point > of view. The license looks like a 3 clause BSD to me, and as such is generally considered free under the DFSG. Just for future reference, [EMAIL PROTECTED] is the canonical place to ask Debian related licensing questions. [I totally missed the legal question in your message myself since I'm not a DD and hence can't sponsor your package.] Don Armstrong -- The sheer ponderousness of the panel's opinion ... refutes its thesis far more convincingly than anything I might say. The panel's labored effort to smother the Second Amendment by sheer body weight has all the grace of a sumo wrestler trying to kill a rattlesnake by sitting on it--and is just as likely to succeed. -- Alex Kozinski in Silveira V Lockyer http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu signature.asc Description: Digital signature
RFS lib*-perl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi I'd be very grateful for a sponsor for one or more of the folowing packages: libcgi-xmlapplication-perl -- Perl module for creating XML-DOM and OO based CGI scripts libcgi-xmlform-perl -- Perl module for reading/generating formatted XML libdbix-xmlmessage-perl -- Perl module for exchanging XML messages between DBI data sources libdbd-ram-perl -- Perl DBI driver for files and data structures libparse-yapp-perl -- Perl module for creating fully reentrant LALR parser OO Perl modules libcgi-xml-perl -- Perl module for converting CGI variables from/to XML libdbix-xml-rdb-perl -- Perl module for creating XML from a DBI datasource DBI is the Perl Database Interface (for more info see libdbi-perl) You can find the new packages on deb-src http://zeus.ugent.be/~luk pool/ Thanks in advance Luk -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE/jpZ3At+ECxtXDnwRAjl4AJ9EIdUfZfQrcN0gYke0tRKuLOZ3MgCbBu5M azFpLqfogEBa+9Kk+NsV4nU= =dSje -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
gcc 3.3 and __func__ ...
Hello,
I have some code that was using :
printf (__func__ "Message", ...);
This doesn't build anymore with gcc 3.x, since __func__ is treated as a
variable, not a string literal.
What would be the best way of working around this ? Replacing all these
constructs with :
printf ("%sMessage", __func__, ...);
Works, but seems a bit ugly, and there are _lots_ of those lines.
Is there a compiler switch to consider __func__ as string literal or
something such ?
Naturally, using 2.95 kinda works, but i don't think this is a good
idea.
Thanks for your help.
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc 3.3 and __func__ ...
On Thu, Oct 16, 2003 at 05:59:43PM +0200, Sven Luther wrote:
> I have some code that was using :
>
> printf (__func__ "Message", ...);
>
> This doesn't build anymore with gcc 3.x, since __func__ is treated as a
> variable, not a string literal.
>
> What would be the best way of working around this ? Replacing all these
> constructs with :
>
> printf ("%sMessage", __func__, ...);
>
> Works, but seems a bit ugly, and there are _lots_ of those lines.
>
> Is there a compiler switch to consider __func__ as string literal or
> something such ?
That behaviour is mandated by ISO C99, so even if it were possible to
override it, the code needs to be fixed.
The gcc-specific __FUNCTION__ and __PRETTY_FUNCTION__ are string literals,
like what is expected here, except in C++, where they act like __func__.
See "(gcc)Function Names". It'd really be best to adapt it to use __func__
properly, since this is a standard which will be honored by other compilers.
--
- mdz
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: proper way to pack package from multiple sources?
On Tue, Oct 14, 2003 at 11:35:03AM +0200, Magosányi Árpád wrote: > The syslog-ng package consists of two sources: syslog-ng itself, and > libol. > Now the packege is created by unpacking syslog-ng, dropping the libol > tar.gz into the source tree, and adding the debian dir. > It follows that either I build a package which looks like a native > debian package or dpkg-source complains about unrepresentable changes > to source. > I don't want to package libol separately, as it is deprecated: > it is used only by syslog-ng and bwall. The devel version of syslog-ng > does not use it, and bwall's only proxy (ck-gw) made obsolete by the > ZAS authentication method of Zorp. > > Question: what is the proper way to package syslog-ng? Wait for the next release which doesn't require libol, or repackage .orig.tar.gz so that it actually has what you need for building the package. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Splitting a package
On Mon, Oct 13, 2003 at 04:51:12PM +0200, Alberto Gonzalez Iniesta wrote: > I'd like to know if this justifies splitting a package. AFAIK the > size or the existence of shared libs justify splitting a package, but > not this. > > I've got a package that contains a command line program and a couple of > front-ends (motif and KDE) for it. This makes neccessary to install > lots of KDE libs even if you're only using the command line program. > > Would all this Depends justify splitting it into the command line > package and the front-ends one? > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=215502 It is up to you, based on your knowledge of the package and its users, to decide if this makes sense. For example, if the purpose of the CLI is to allow the software to be used without KDE, then it would be sensible to provide it in a separate package to be used with KDE. If it is a program which is meant to be used with the KDE portions, and isn't very useful without them, then it would not make sense. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Splitting a package
I've been in some discussion with another developer. He's decided it would be nice to split out some interface modules for a package. These modules constitute reasonably small single files and copies of the relevant documentation. I'm of the opinion that a few KB is too small for a .deb that could be part of a larger .deb. The advantages however are fewer "dependencies" which I believe should be marked as "Suggests:" in the larger package. So my questions: What's a good general guideline about splitting packages these days? Split packages for these modules would defiantly have some large language "Depends:", would it be good enough for a larger package to merely suggest these or should they be recommended or even depended upon? Imo these modules wouldn't be used much. Thanks Drew Daniels -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc 3.3 and __func__ ...
On Thu, Oct 16, 2003 at 12:26:42PM -0400, Matt Zimmerman wrote:
> On Thu, Oct 16, 2003 at 05:59:43PM +0200, Sven Luther wrote:
>
> > I have some code that was using :
> >
> > printf (__func__ "Message", ...);
> >
> > This doesn't build anymore with gcc 3.x, since __func__ is treated as a
> > variable, not a string literal.
> >
> > What would be the best way of working around this ? Replacing all these
> > constructs with :
> >
> > printf ("%sMessage", __func__, ...);
> >
> > Works, but seems a bit ugly, and there are _lots_ of those lines.
> >
> > Is there a compiler switch to consider __func__ as string literal or
> > something such ?
>
> That behaviour is mandated by ISO C99, so even if it were possible to
> override it, the code needs to be fixed.
Yes, seemed so to me.
> The gcc-specific __FUNCTION__ and __PRETTY_FUNCTION__ are string literals,
Well, apparently no more in gcc 3.4.
> like what is expected here, except in C++, where they act like __func__.
> See "(gcc)Function Names". It'd really be best to adapt it to use __func__
> properly, since this is a standard which will be honored by other compilers.
What would be the best way to adapt it ? Use the
printf ("%sMessage", __func__, ...);
form ?
Thanks for your reply,
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc 3.3 and __func__ ...
On Thu, Oct 16, 2003 at 11:51:12PM +0200, Sven Luther wrote:
> On Thu, Oct 16, 2003 at 12:26:42PM -0400, Matt Zimmerman wrote:
> > See "(gcc)Function Names". It'd really be best to adapt it to use __func__
> > properly, since this is a standard which will be honored by other compilers.
>
> What would be the best way to adapt it ? Use the
>
> printf ("%sMessage", __func__, ...);
>
> form ?
Yes.
--
- mdz
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: libdtdparser-java -- Java DTD parser library (closing bug)
Hi mentors, I'd like a sponsor to upload a new package of libdtdparser-java: libdtdparser-java (1.21-6) unstable; urgency=low * changed ANT_HOME (closes: #216123). -- Arnaud Vandyck <[EMAIL PROTECTED]> Fri, 17 Oct 2003 00:16:36 +0200 Usual location: http://vbstefi60.fapse.ulg.ac.be/~arnaud/debian/libdtdparser-java-1.21-6.tar.gz Many thanks for your help and many thanks to Daniel Schelper who found the bug, On Thu, 16 Oct 2003 11:56:48 -0700 Daniel Schepler <[EMAIL PROTECTED]> wrote: > Package: libdtdparser-java > Severity: serious > Version: 1.21-5 > > From my build log (with pbuilder's extraneous LOGNAME messages > removed): > > ... > if test "." != "."; then rmdir .; fi > dh_clean > You must specify a valid ANT_HOME directory! > make: *** [ant-sanity-check] Error 1 > > -- > Daniel Schepler "Please don't disillusion me. I > [EMAIL PROTECTED]haven't had breakfast yet." > -- Orson Scott Card -- .''`. ** Debian GNU/Linux ** : :' : Arnaud Vandyck `. `' http://alioth.debian.org/users/arnaud-guest/ `-http://alioth.debian.org/developer/diary.php?diary_user=2781 jabber: [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
(no subject)
unsubscribe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
