Bug#480964: ITP: libservlet2.5-java -- Version 2.5 of the Java Servlet API (includes version 2.1 of JSP and EL APIs).

Package: wnpp Severity: wishlist Owner: Paul Cager <[EMAIL PROTECTED]> * Package name: libservlet2.5-java Version : 2.5 Upstream Author : Various * URL : http://tomcat.apache.org * License : Apache 2 Programming Lang: Java Description : Version

Bug#475780: ITP: plexus-archiver -- Plexus archiving libraries

Package: wnpp Severity: wishlist Owner: Paul Cager <[EMAIL PROTECTED]> * Package name: plexus-archiver Version : 1.0-alpha-9 Upstream Author : Codehaus developers * URL : plexus.codehaus.org * License : Apache 2 Programming Lang: Java Descr

Bug#475726: ITP: plexus-io -- Input-output utility library for Plexus

Package: wnpp Severity: wishlist Owner: Paul Cager <[EMAIL PROTECTED]> * Package name: plexus-io Version : 1.5.3 Upstream Author : Codehaus developers. * URL : http://plexus.codehaus.org/ * License : Apache 2.0 Programming Lang: Java Description :

Bug#475715: ITP: plexus-compiler-javac -- Interface to javac compiler for Plexus

Package: wnpp Severity: wishlist Owner: Paul Cager <[EMAIL PROTECTED]> * Package name: plexus-compiler-javac Version : 1.5.3 Upstream Author : Codehaus developers. * URL : http://plexus.codehaus.org/ * License : MIT / Apache 2.0 Programming Lang

Bug#474610: ITP: plexus-compiler-api -- Compiler API for the Plexus framework

Package: wnpp Severity: wishlist Owner: Paul Cager <[EMAIL PROTECTED]> * Package name: plexus-compiler-api Version : 1.5.3 Upstream Author : Jason van Zyl and others * URL : http://plexus.codehaus.org/ * License : MIT / Apache 2.0 Programming Lang

Re: What CDs and DVDs should we produce for lenny?

Steve McIntyre wrote: [ Please note Reply-To: to debian-cd... ] Hi folks, It's time for me to ask the question again - what CDs and DVDs will we find useful enough that we should make them for lenny? [...] 1. Is it worth making full sets of CDs at all? Can we rely on people having a net

Re: Package lists for (stable) distribution CDs/DVDs (integrating to package.d.o)

Steve McIntyre wrote: > On Tue, Sep 11, 2007 at 03:47:22PM +0200, Bernd Zeimetz wrote: >>> Sounds like a cool idea, with a minor issue. The contents of the CDs >>> and DVDs can (and do) vary a little from arch to arch. But we could >>> easily do >>> >>> http://packages.debian.org/stable/cd1-i386/ >

Re: Build the Debian Reference Card

On Tue, July 24, 2007 3:42 pm, W. Martin Borgert wrote: > Paul, > [ ... ] > - I like to make the reference card a Debian package, so that > you could file a FTBFS (fails to build from source) bug. Wolfgang, Thanks very much for this. I was hoping it would end up packaged (even if I don't have t

Re: Build the Debian Reference Card

On Tue, July 24, 2007 2:13 pm, Neil Williams wrote: > On Tue, 24 Jul 2007 13:33:04 +0100 (BST) > "Paul Cager" <[EMAIL PROTECTED]> wrote: > >> Hi, >> >> Has anyone any advice on how to build the Reference Card[1] from source? >> >> I have

Build the Debian Reference Card

Hi, Has anyone any advice on how to build the Reference Card[1] from source? I have removed the "--nonet" from the xsltproc call so that it can download "http://db2latex.sourceforge.net/xsl/docbook.xsl";, but now it fails: [EMAIL PROTECTED]:~/refcard/trunk$ make xsltproc --novalid --xinclude pre

Re: Thoughts about the bug tracking system

Oleg Verych wrote: >>> [incensed ranting on the topic of web applications] >> Oleg, your response doesn't seem to be in response to the message you >> quoted. > > A reply to off topic message to the development list. Insulting -- yes. Why? Yes, indeed, why? Why do you feel the need to insult som

Re: Missing license info in source files - fixed in upstream svn

On Tue, July 3, 2007 4:06 pm, Paul Cager wrote: > On Tue, July 3, 2007 8:38 am, Andreas Barth wrote: >> Explain it in debian/copyright, that's the proper place (the source >> files don't actually need license statement, even though of course it >> helps transpare

Re: Missing license info in source files - fixed in upstream svn

On Tue, July 3, 2007 8:38 am, Andreas Barth wrote: > Explain it in debian/copyright, that's the proper place (the source > files don't actually need license statement, even though of course it > helps transparence and is therefore encouraged). I didn't realise that. I had assumed that each source

Missing license info in source files - fixed in upstream svn

I'm packaging a couple of Java libraries where the source files do not have any license declarations. This is being fixed in upstream's svn repository. I still want to package upstream's latest *release* rather than the head of svn, so is it OK just to explain the situation in README.Debian-source

Bug#428643: ITP: maven-ant-helper -- package helper scripts for building Maven components with ant

Package: wnpp Severity: wishlist Owner: Paul Cager <[EMAIL PROTECTED]> * Package name: maven-ant-helper Version : 1.0 Upstream Author : Trygve Laugstøl <[EMAIL PROTECTED]> * URL : http://svn.debian.org/wsvn/pkg-java/trunk/maven-ant-helper * License

Bug#428575: ITP: plexus-i18n -- Plexus internationalisation package.

Package: wnpp Severity: wishlist Owner: Paul Cager <[EMAIL PROTECTED]> * Package name: plexus-i18n Version : 1.0-beta-6 Upstream Author : Plexus Developers * URL : http://plexus.codehaus.org * License : Apache Programming Lang: Java Description :

Bug#426228: ITP: plexus-digest -- a component of maven2

Package: wnpp Severity: wishlist Owner: Paul Cager <[EMAIL PROTECTED]> * Package name: plexus-digest Version : svn Upstream Author : Plexus Developers * URL : http://plexus.codehaus.org * License : Apache Programming Lang: Java Description : a com

Bug#426227: ITP: plexus-velocity -- The Plexus Velocity Component

Package: wnpp Severity: wishlist Owner: Paul Cager <[EMAIL PROTECTED]> * Package name: plexus-velocity Version : svn Upstream Author : Plexus Authors * URL : http://plexus.codehaus.org * License : Apache Programming Lang: Java Description : The

Bug#426226: ITP: plexus-compiler -- Interface to compilers within Plexus

Package: wnpp Severity: wishlist Owner: Paul Cager <[EMAIL PROTECTED]> * Package name: plexus-compiler Version : svn Upstream Author : Plexus Authors * URL : http://plexus.codehaus.org * License : Apache Programming Lang: Java Description : Interf

Bug#426219: ITP: plexus-component-factories -- Plexus factories for bsh, ant components etc

Package: wnpp Severity: wishlist Owner: Paul Cager <[EMAIL PROTECTED]> * Package name: plexus-component-factories Version : svn Upstream Author : Plexus Authors * URL : http://plexus.codehaus.org * License : Apache Programming Lang: Java Descr

Bug#421626: ITP: modello -- a Data Model toolkit in use by the Maven 2 Project

Package: wnpp Severity: wishlist Owner: Paul Cager <[EMAIL PROTECTED]> * Package name: modello Version : latest Upstream Author : Brett Porter ([EMAIL PROTECTED]) * URL : http://modello.codehaus.org * License : http://opensource.org/licenses/mit-licen

Bug#421428: ITP: commons-openpgp -- a common and simple Java interface for generating and verifying OpenPGP signatures

Package: wnpp Severity: wishlist Owner: Paul Cager <[EMAIL PROTECTED]> * Package name: commons-openpgp Version : svn 533437 Upstream Author : Brett Porter, Stefan Bodewig * URL : http://jakarta.apache.org/commons/sandbox/openpgp/index.html * License : Apa

Debhelper and variable substitution in *.install files etc.

When packaging Java libraries it is necessary to install the "jar" file with an upstream version number e.g. /usr/share/java/thing-1.2.3.jar and have a symbolic link: /usr/share/java/thing.jar -> /usr/share/java/thing-1.2.3.jar I can use debhelper's "package-name.install" and "package-nam

Re: [Fwd: Bug#412952: file conflicts between afnix and aleph]

Frank Küster wrote: > Michael Koch <[EMAIL PROTECTED]> wrote: > >> Add this to afnix: >> >> Conflicts: aleph >> Replaces: aleph >> >> This should make it possible to have always one of them installed and >> make afnix replace aleph on dist-upgrades. > > Isn't > > Provides: aleph > > also neede

[Fwd: Bug#412952: file conflicts between afnix and aleph]

Could I have some advice about the best way to fix this one please? Here's a summary: * The obsolete package "aleph" is supserseded by "afnix". * I've requested the removal of aleph from unstable (bug #389163). * There is already another RC bug against "aleph", as it conflicts with tetex-bin. I d

Re: Debian in Sanger (Re: update on binary upload restrictions)

Tim Cutts wrote: > What I'd actually like is some sort of non-root packaging system so that > users could build software with decent dependency checking for their > shared software infrastructure. Can dpkg be cajoled into doing that? Could you use a schroot instance to do that? -- To UNSUBSCR

/var/www or /var/web

I am packaging MyServer (a small web server). By default it expects its document root to be /var/web. Am I right to assume I should change this to /var/www (as in apache2)? The FSH doesn't mention either directory. Thanks, Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "un

Re: Best scheme for teams and Maintainer/Uploaders fields ?

> Christoph Berg wrote: >> Note that you can subscribe additional packages to any maintainer >> view. The GIS team does that: > > Is there a way to subscribe a mailing list to receive bug reports also, > without having the mailing list in the Maintainer field? > > Marcus On the PTS you can subscri

Dynamic linking to /usr/lib/xxxxx directory.

I'm packaging AFNIX which provides four or five executables and a bunch of shared objects that the executables use. Since the SOs are not likely to be of use to anything except the AFNIX system itself, I intend to install the SOs in /usr/lib/afnix/*.so. I'm a newbie as far as SOs are concerned, so

Re: Elive requires donation to download

> Elive , based on Debian, > requires a donation, however small, to allow downloading. I wonder if > this legally sound. > > Ottavio >From the page you referred to above: "If you don't care about the future of Elive, and you really think its possibl

Re: Debian Archive Automatic Signing Key (4.0/etch)?

> On Tue, 21 Nov 2006, Kurt Roeckx wrote: > But Hendrik Sattler is perfectly right and this knowledge has to be stored > at prominant places like: > > a) installation manual > b) apt-key.8 > c) perhaps somewhere else Should the apt-get warning message be changed to refer to apt-key.8?