RFS: pyx -- Python module for generating PostScript graphics

[Graham Wilson]

i am seeking a sponsor for my [1]pyx (0.3.1-1) package.

pyx is a python module for generating encapsulated postscript graphics
out of python primitives that abstract postscript and tex/latex. pyx is
commonly used for create 2 and 3d plots for papers. for example, the
following python code produces a [3]plot of sin and cos functions:

 from math import pi
 from pyx import *
 
 g = graph.graphxy(width=8, key=graph.key(pos="bl"),
   x=graph.linaxis(min=0, max=2*pi, title="$x$", divisor=pi, 
suffix=r"\pi"),
   y=graph.linaxis(title="$y$"))
 
 g.plot(graph.function("y=sin(x)", title=r"$y=\sin(x)$"))
 g.plot(graph.function("y=cos(x)", title=r"$y=\cos(x)$"))
 
debian packages are available on my [2]home page.

[1] http://pyx.sf.net/
[2] http://decoy.wox.org/~bob/debian/unstable/
[3] http://pyx.sourceforge.net/piaxis.png

-- 
gram


pgp0.pgp
Description: PGP signature

Re: newbie packaging question

[Colin Watson]

On Fri, Aug 08, 2003 at 07:38:11PM +1000, Matthew Palmer wrote:
> The things which absolutely have to be in a package in order to be
> built are debian/rules and debian/control.  debian/rules gives the
> commands required to make the package, and debian/control has the
> information necessary to name the binary packages, dependencies, and
> the rest.

debian/changelog must also be present.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]


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

Re: GNAT 3.15p

[Ludovic Brenta]

Florian Weimer <[EMAIL PROTECTED]> writes:

> Ludovic Brenta <[EMAIL PROTECTED]> writes:
> 
> > So, here you go: http://users.skynet.be/ludovic.brenta
> 
> Thanks a lot.  Here are a few comments:
> 
> Your shared library support is probably incompatible with ACT's.  Do
> you really want to enable it by default?

Well, yes, I would like to, especially since gnat 3.14p did, too.
Could you shed some light on what makes "my" shared library support
incompatible with ACT's? I didn't change the sonames.
 
> You should bump Standards-Version to the most recent one (after
> checking that no changes are necessay).

OK, will do.  I was wondering where I could find a diff between
various Standards-Versions to check for any changes I need to make.
Any ideas?
 
> The gnat package should also conflict with gnat-3.2, not just with
> gnat-3.3.

Good suggestion.
 
> The build dependency on autoconf 2.57 is wrong.  GCC still needs
> autoconf 2.13.  You should avoid rerunning autoheader.

OK.
 
> You should drop the line "GNAT is actively maintained by Ada Core
> Technology (http://www.gnat.com/)." from the package description.
> It's simply not true from Debian's point of view.

OK.  This was the previous maintainer's description, I'll just change
that.
 
> Your package suggests asis etc., but these are currently not packaged
> for 3.15p.

I'm planning to do this once I become a DD.  These packages just need
upgrading from 3.14p.
 
> Otherwise, your gnat package appears to be fine.

Thanks for your constructive criticism.

-- 
Ludovic Brenta.


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

RFS: xmms-null -- null output plugin for XMMS

[Keegan Quinn]

I'm seeking a sponsor for my xmms-null[1] package.

Description: null output plugin for XMMS
 XMMS output plugin which simply throws the signal away.  Useful for
 testing and benchmarking.  Also useful for nullifying the output
 when using a DSP plugin for broadcasting, or if you don't have a
 soundcard.

Packages are available at these APT sources:

deb http://rune.thebasement.org/debian unstable keegan
deb-src http://rune.thebasement.org/debian unstable keegan

An ITP bug has been filed; #200580.

The Debian revision should probably be bumped up to -1, and a changelog
entry which Closes: #200580 should be added, but I'd appreciate if
someone could take a look at them before I add these finishing touches.

The packaging is very simple, using cdbs, the common Debian build
system.  An ideal sponsor would be somewhat familiar with both XMMS
and cdbs.

Thanks,

 - Keegan

[1] http://havardk.xmms.org/plugins/null_output/



pgp0.pgp
Description: PGP signature

Re: newbie packaging question

[Colin Watson]

On Fri, Aug 08, 2003 at 10:12:52PM +1000, Matthew Palmer wrote:
> On Fri, Aug 08, 2003 at 11:24:13AM +0100, Colin Watson wrote:
> > On Fri, Aug 08, 2003 at 07:38:11PM +1000, Matthew Palmer wrote:
> > > The things which absolutely have to be in a package in order to be
> > > built are debian/rules and debian/control.  debian/rules gives the
> > > commands required to make the package, and debian/control has the
> > > information necessary to name the binary packages, dependencies, and
> > > the rest.
> > 
> > debian/changelog must also be present.
> 
> D'oh.  Knew I forgot something.
> 
> Will the packaging tools complain if you have no copyright file, too?  I
> know it's necessary for uploading, of course, and I'm sure lintian would
> have a right whinge, but will (eg) debhelper scripts have a complain, to
> your knowledge?

Don't think so; dh_installdocs is the only thing that cares about the
copyright file at all, and looking at the source it doesn't look like
it'll mind if it doesn't exist. I've certainly built quick test packages
in the past without copyright files and had no problems other than the
obvious lintian warning.

I think this is correct behaviour, really. After all, packaging tools
should be general where it's reasonable to be, and the copyright file is
exclusively a Debian policy thing.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]


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

Re: GNAT 3.15p

[Florian Weimer]

Ludovic Brenta <[EMAIL PROTECTED]> writes:

>> Your shared library support is probably incompatible with ACT's.  Do
>> you really want to enable it by default?
>
> Well, yes, I would like to, especially since gnat 3.14p did, too.

Ah, let's keep the old mistakes. 8-)

> Could you shed some light on what makes "my" shared library support
> incompatible with ACT's?

ACT's GNAT puts in an rpath, and links to a .so library, not a .so.1
library.

I just tested it: no compatibility at all, in both directions.  If you
want to distribute Ada programs, you have to link statically.

Furthermore, the FSF GNAT version (GNAT 5.00w) uses the same soname,
but is probably not ABI compatible.

RFS: par2

[Steve Lamb]

Description: Parity Archive v2
 This utility applies the data-recover capability concepts of RAID-like
 systems to individual and multiple files.  It is most commonly used in
 the posting and recovery of multipart archives on Usenet.
 .
 It supports the 'Reed-Soloman Code' implementation that allows for recovery
 of any X blocks for X parity blocks present.  It is popularly used on USENET
 postings but is not limited to this use.
 .
 par2 is the direct successor of the package parchive.
 .
 Upstream source: http://parchive.sourceforge.net/


-- 
 Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
   PGP Key: 8B6E99C5   | main connection to the switchboard of souls.
   |-- Lenny Nero - Strange Days
---+-


pgpygx0KSMfTe.pgp
Description: PGP signature

RFS: pgpdump -- PGP packet visualizer

[Graham Wilson]

i am seeking a sponsor for my [1]pgpdump (0.19-1) package.

pgpdump is a pgp packet visualizer, which is similar (but better) to
gpg's --list-packets command. sample output (dump of pgpdump's signed
.dsc file):

 Old: Signature Packet(tag 2)(277 bytes)
 Ver 3 - old
 Hash material(5 bytes):
 Sig type - Signature of a canonical text document(0x01).
 Creation time - Wed Jun 25 19:47:14 CDT 2003
 Key ID - 0x8B94031D7F75635F
 Pub alg - RSA Encrypt or Sign(pub 1)
 Hash alg - SHA1(hash 2)
 Hash left 2 bytes - e8 d4
 RSA m^d mod n(2046 bits) - ...
 -> PKCS-1

debian packages are available on my [2]homepage.

[1] http://pgp.iijlab.net/pgpdump.html
[2] http://decoy.wox.org/~bob/debian/unstable/

-- 
gram


pgpiSGTj4WU7P.pgp
Description: PGP signature

RFS: pyx -- Python module for generating PostScript graphics

[Graham Wilson]

i am seeking a sponsor for my [1]pyx (0.3.1-1) package.

pyx is a python module for generating encapsulated postscript graphics
out of python primitives that abstract postscript and tex/latex. pyx is
commonly used for create 2 and 3d plots for papers. for example, the
following python code produces a [3]plot of sin and cos functions:

 from math import pi
 from pyx import *
 
 g = graph.graphxy(width=8, key=graph.key(pos="bl"),
   x=graph.linaxis(min=0, max=2*pi, title="$x$", divisor=pi, 
suffix=r"\pi"),
   y=graph.linaxis(title="$y$"))
 
 g.plot(graph.function("y=sin(x)", title=r"$y=\sin(x)$"))
 g.plot(graph.function("y=cos(x)", title=r"$y=\cos(x)$"))
 
debian packages are available on my [2]home page.

[1] http://pyx.sf.net/
[2] http://decoy.wox.org/~bob/debian/unstable/
[3] http://pyx.sourceforge.net/piaxis.png

-- 
gram


pgp58q7UBdKNg.pgp
Description: PGP signature

Re: RFS: pgpdump -- PGP packet visualizer

[Stephen Stafford]

On Mon, Aug 04, 2003 at 02:58:33PM -0500, Graham Wilson wrote:
> i am seeking a sponsor for my [1]pgpdump (0.19-1) package.
> 
> pgpdump is a pgp packet visualizer, which is similar (but better) to
> gpg's --list-packets command. sample output (dump of pgpdump's signed
> .dsc file):
> 
>  Old: Signature Packet(tag 2)(277 bytes)
>  Ver 3 - old
>  Hash material(5 bytes):
>  Sig type - Signature of a canonical text document(0x01).
>  Creation time - Wed Jun 25 19:47:14 CDT 2003
>  Key ID - 0x8B94031D7F75635F
>  Pub alg - RSA Encrypt or Sign(pub 1)
>  Hash alg - SHA1(hash 2)
>  Hash left 2 bytes - e8 d4
>  RSA m^d mod n(2046 bits) - ...
>  -> PKCS-1
> 
> debian packages are available on my [2]homepage.
> 
> [1] http://pgp.iijlab.net/pgpdump.html
> [2] http://decoy.wox.org/~bob/debian/unstable/
> 

Hi,

I've taken a quick look at this and it looks almost perfect.

You just need a pointer in debian/copyright to where you downloaded the
source from.

Other than that, it's fine and I'll happily upload it for you as soon as you
fix the copyright (just mailing me a diff against it is fine)

Cheers,
Stephen

Re: newbie packaging question

[Matthew Palmer]

On Thu, Aug 07, 2003 at 12:54:08PM -0700, Eric Winger wrote:
> I hope that I've selected the correct debian mailing list for this 
> question. But if not, I would appreciate if you could redirect properly.

Nope, this is the right spot.

> My first steps are proving to be quite haltingly slow. I'm the Debian 
> New Maintainer's Guide and I've setup a simple goal for myself. To take 
> an installation .bin (known to work) and make a debian package out of 
> it. No sources, just a .bin. Then debian, upon installing this package, 
> would simply run a little config script to run the .bin file.

Ayup.  Quite simple.

> But in following the instructions in the doc it tells me to create some 
> directories with my source in them, then use dh-make first. But dh_make 
> keeps telling me it can't find my source package.

That would be the tarball containing the "source" for your package.  The
"source" is simply whatever gets released without debian modifications.  Of
course, there are "debian native" packages, where the source and debian bits
are all together.

The things which absolutely have to be in a package in order to be built are
debian/rules and debian/control.  debian/rules gives the commands required
to make the package, and debian/control has the information necessary to
name the binary packages, dependencies, and the rest.

Your best bet is to get the source for a really simple, debian-native,
architecture-independent package, and change the small bit of code that has
to be changed to copy your binary to the right place.

Executing commands after installation can be done in the postinst file,
which is usually just a shell script.  Adding a startup script can be done
with dh_installinit (see the manpage).

An example of a simple package as described above is phtml.  (Mandatory
disclosure: I maintain it).

> So two questions, does the source package need to be raw code or is it 
> specific term to refer to a C source filled directory? And two, is my 
> goal reasonable for a first-timer?

Your goal is reasonable, and no, "source code" doesn't have to be C source
or anything like that.  Consider doc-rfc, or Perl script packages.

- Matt

Re: newbie packaging question

[Colin Watson]

On Fri, Aug 08, 2003 at 07:38:11PM +1000, Matthew Palmer wrote:
> The things which absolutely have to be in a package in order to be
> built are debian/rules and debian/control.  debian/rules gives the
> commands required to make the package, and debian/control has the
> information necessary to name the binary packages, dependencies, and
> the rest.

debian/changelog must also be present.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Re: newbie packaging question

[Matthew Palmer]

On Fri, Aug 08, 2003 at 11:24:13AM +0100, Colin Watson wrote:
> On Fri, Aug 08, 2003 at 07:38:11PM +1000, Matthew Palmer wrote:
> > The things which absolutely have to be in a package in order to be
> > built are debian/rules and debian/control.  debian/rules gives the
> > commands required to make the package, and debian/control has the
> > information necessary to name the binary packages, dependencies, and
> > the rest.
> 
> debian/changelog must also be present.

D'oh.  Knew I forgot something.

Will the packaging tools complain if you have no copyright file, too?  I
know it's necessary for uploading, of course, and I'm sure lintian would
have a right whinge, but will (eg) debhelper scripts have a complain, to
your knowledge?

(I should just rename a copyright file and try it out, but I like mailing
list discussions... )

- Matt

Re: RFS: par2

[Steve Lamb]

On Fri, 8 Aug 2003 00:32:37 -0700
Steve Lamb <[EMAIL PROTECTED]> wrote:
> Description: Parity Archive v2
>  This utility applies the data-recover capability concepts of RAID-like
>  systems to individual and multiple files.  It is most commonly used in
>  the posting and recovery of multipart archives on Usenet.
>  .
>  It supports the 'Reed-Soloman Code' implementation that allows for recovery
>  of any X blocks for X parity blocks present.  It is popularly used on
>  USENET postings but is not limited to this use.
>  .
>  par2 is the direct successor of the package parchive.
>  .
>  Upstream source: http://parchive.sourceforge.net/

After seeing Graham Wilson's excellent RFS I realized it might be useful
to include a location for people to peruse the package.  It can be obtained
from: 

-- 
 Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
   PGP Key: 8B6E99C5   | main connection to the switchboard of souls.
   |-- Lenny Nero - Strange Days
---+-


pgp0t7hRtEjZx.pgp
Description: PGP signature

Re: newbie packaging question

[Thomas Viehmann]

> Will the packaging tools complain if you have no copyright file, too?  I
> know it's necessary for uploading, of course, and I'm sure lintian would
> have a right whinge, but will (eg) debhelper scripts have a complain, to
> your knowledge?
Nope. Neither dpkg-* nor debhelper will complain. (Tried with dupload and dput.)

Cheers

T.


pgpmS6pS68UIJ.pgp
Description: PGP signature

Re: newbie packaging question

[Colin Watson]

On Fri, Aug 08, 2003 at 10:12:52PM +1000, Matthew Palmer wrote:
> On Fri, Aug 08, 2003 at 11:24:13AM +0100, Colin Watson wrote:
> > On Fri, Aug 08, 2003 at 07:38:11PM +1000, Matthew Palmer wrote:
> > > The things which absolutely have to be in a package in order to be
> > > built are debian/rules and debian/control.  debian/rules gives the
> > > commands required to make the package, and debian/control has the
> > > information necessary to name the binary packages, dependencies, and
> > > the rest.
> > 
> > debian/changelog must also be present.
> 
> D'oh.  Knew I forgot something.
> 
> Will the packaging tools complain if you have no copyright file, too?  I
> know it's necessary for uploading, of course, and I'm sure lintian would
> have a right whinge, but will (eg) debhelper scripts have a complain, to
> your knowledge?

Don't think so; dh_installdocs is the only thing that cares about the
copyright file at all, and looking at the source it doesn't look like
it'll mind if it doesn't exist. I've certainly built quick test packages
in the past without copyright files and had no problems other than the
obvious lintian warning.

I think this is correct behaviour, really. After all, packaging tools
should be general where it's reasonable to be, and the copyright file is
exclusively a Debian policy thing.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

RFS: xmms-null -- null output plugin for XMMS

[Keegan Quinn]

I'm seeking a sponsor for my xmms-null[1] package.

Description: null output plugin for XMMS
 XMMS output plugin which simply throws the signal away.  Useful for
 testing and benchmarking.  Also useful for nullifying the output
 when using a DSP plugin for broadcasting, or if you don't have a
 soundcard.

Packages are available at these APT sources:

deb http://rune.thebasement.org/debian unstable keegan
deb-src http://rune.thebasement.org/debian unstable keegan

An ITP bug has been filed; #200580.

The Debian revision should probably be bumped up to -1, and a changelog
entry which Closes: #200580 should be added, but I'd appreciate if
someone could take a look at them before I add these finishing touches.

The packaging is very simple, using cdbs, the common Debian build
system.  An ideal sponsor would be somewhat familiar with both XMMS
and cdbs.

Thanks,

 - Keegan

[1] http://havardk.xmms.org/plugins/null_output/



pgpoZEiW65EuF.pgp
Description: PGP signature