Bug#529019: ITP: libapp-cmd-perl -- Perl interface to write command line apps with less suffering

[Ryan Niebur]

Package: wnpp
Owner: Ryan Niebur 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: libapp-cmd-perl
  Version : 0.203
  Upstream Author : Ricardo SIGNES
* URL : http://search.cpan.org/dist/App-Cmd/
* License : Artistic | GPL-1+
  Programming Lang: Perl
  Description : Perl interface to write command line apps with less 
suffering
 App::Cmd is intended to make it easy to write complex command-line
 applications without having to think about most of the annoying
 things usually involved.
 .
 For information on how to start using App::Cmd, see App::Cmd::Tutorial.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#529018: ITP: libio-tiecombine-perl -- Perl module to produce tied (and other) separate but combined variables

[Ryan Niebur]

Package: wnpp
Owner: Ryan Niebur 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: libio-tiecombine-perl
  Version : 1.000
  Upstream Author : Ricardo SIGNES 
* URL : http://search.cpan.org/dist/IO-TieCombine/
* License : Artistic | GPL-1+
  Programming Lang: Perl
  Description : Perl module to produce tied (and other) separate but 
combined variables
 IO::TieCombine produces tied (and other) separate but combined variables.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#529021: ITP: octave-benchmark -- code to benchmark speed of Octave

[Rafael Laboissiere]

Package: wnpp
Severity: wishlist
Owner: Rafael Laboissiere 

* Package name: octave-benchmark
  Version : 1.1.1
  Upstream Author : Jaroslav Hajek   
* URL : http://octave.sourceforge.net/benchmark
* License : GPL-2+
  Programming Lang: Octave
  Description : code to benchmark speed of Octave

This package contains a collection of routines to benchmark speed of
Octave, a numerical computation software.  It contains functions to
test dense transposed matrix-matrix and matrix-vector multiplication,
array indexing, integer math & conversions, array permuting, sparse
transposed matrix-vector multiplication, as well as tools for
controlling the benchmark.

This Octave add-on package is part of the Octave-Forge project.

Initial Debian package at
http://git.debian.org/?p=pkg-octave/octave-benchmark.git

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'unstable'), (500, 'oldstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/bash

-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#494714: dpkg-dev - dpkg-genchanges should fold lines

[Ben Finney]

Russ Allbery  writes:

> Ben Finney  writes:
> 
> > I don't know what this “field header” is that you're referring to. Do
> > you mean “field”? There's no header involved, only fields, AFAICT.
> 
> The things we're talking about (a key/value pair, basically) is called a
> "header field" in RFC 5322.  The header part is of course because the
> standard is written for e-mail, but our fields are essentially the same
> thing as an RFC 5322 header field.

Except, of course, without any header being involved.

For the sake of clarity, then, I hope we can drop the mis-application of
the term “header” and call these things what they are: just a “field”.
Bonus extra: not only is it clearer, it's shorter to type.

-- 
 \ “I wrote a song, but I can't read music so I don't know what it |
  `\is. Every once in a while I'll be listening to the radio and I |
_o__)say, ‘I think I might have written that.’” —Steven Wright |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#494714: dpkg-dev - dpkg-genchanges should fold lines

[Raphael Hertzog]

On Sat, 16 May 2009, Manoj Srivastava wrote:
> > I do that work my own project and it works perfectly fine.
> 
> The part that I want to carry on is that conceptually, a field
>  header is a single line, though it might be distributed over several
>  physical lines (continuation lines). I don't think the bit about how
>  unfolding is to be accomplished need go into policy.

Well, Files: headers and similars are multi-line values and are not
(not even conceptually) a single line.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#529049: ITP: octave-bugfix-3.0.5 -- bug fixes for some functions of Octave 3.0.5

[Rafael Laboissiere]

Package: wnpp
Severity: wishlist
Owner: Rafael Laboissiere 

* Package name: octave-bugfix-3.0.5
  Version : 1.0
  Upstream Author : The Octave Forge Community   
* URL : http://octave.sourceforge.net/bugfix-3.0.5
* License : GPL-3+
  Programming Lang: Octave
  Description : bug fixes for some functions of Octave 3.0.5

This package overrides some functions included with the 3.0.5 release
that contain minor bugs.  (In this version, just a fixed version of
intersect.m is included.)

This Octave add-on package is part of the Octave-Forge project.

Initial Debian package at
http://git.debian.org/?p=pkg-octave/octave-bugfix-3.0.5.git

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'unstable'), (500, 'oldstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

ITP: gnome-zeitgeist -- journal of file usage and other activities

[Siegfried Gevatter]

Package: wnpp
Severity: wishlist
Owner: "Siegfried-Angel Gevatter Pujals" 

* Package name: gnome-zeitgeist
  Version : 0.0.5
  Upstream Author : The Zeitgeist Team

* URL : https://launchpad.net/gnome-zeitgeist
* License : GPLv3+
  Programming Lang: Python
  Description : journal of file usage and other activities

GNOME Zeitgeist is a tool for easily browsing and finding files on
your computer. It keeps a chronological journal of all file activity,
in addition to supporting tagging and establishing relationships
between groups of files.

SAMPLE USE CASE:

John turns on his computer to work on his seminar paper. Instead of
digging through his hierarchal file system, he simply opens up Gnome
Zeitgeist and clicks on the top item in the "Recently Used Files"
list. When he realizes that he can't remember the name of the website
that he was reading for research yesterday, he simply looks at the
list of files related to his paper and clicks on the website.

For more information, see:
 - http://live.gnome.org/GnomeZeitgeist
 - http://live.gnome.org/Boston2008/GUIHackfest/FileManagement/

-- 
Siegfried-Angel Gevatter Pujals (RainCT)
Ubuntu Developer. Debian Contributor.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#529049: ITP: octave-bugfix-3.0.5 -- bug fixes for some functions of Octave 3.0.5

[Adeodato Simó]

+ Rafael Laboissiere (Sun, 17 May 2009 15:31:51 +0200):

Hello!

> * Package name: octave-bugfix-3.0.5
>   Version : 1.0
>   Upstream Author : The Octave Forge Community   
> * URL : http://octave.sourceforge.net/bugfix-3.0.5
> * License : GPL-3+
>   Programming Lang: Octave
>   Description : bug fixes for some functions of Octave 3.0.5

> This package overrides some functions included with the 3.0.5 release
> that contain minor bugs.  (In this version, just a fixed version of
> intersect.m is included.)

Out of curiosity, what's the use case for having this as a separate
package? Would one ever want to run octave3.0 without these fixes? If
not, why would you not ship them directly as patches in the octave3.0
source package?

Thanks,

-- 
- Are you sure we're good?
- Always.
-- Rory and Lorelai


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#529049: ITP: octave-bugfix-3.0.5 -- bug fixes for some functions of Octave 3.0.5

[Rafael Laboissiere]

* Adeodato Simó  [2009-05-17 17:58]:

> > * Package name: octave-bugfix-3.0.5
> >   Version : 1.0
> >   Upstream Author : The Octave Forge Community   
> > * URL : http://octave.sourceforge.net/bugfix-3.0.5
> > * License : GPL-3+
> >   Programming Lang: Octave
> >   Description : bug fixes for some functions of Octave 3.0.5
> 
> > This package overrides some functions included with the 3.0.5 release
> > that contain minor bugs.  (In this version, just a fixed version of
> > intersect.m is included.)
> 
> Out of curiosity, what's the use case for having this as a separate
> package? Would one ever want to run octave3.0 without these fixes? If
> not, why would you not ship them directly as patches in the octave3.0
> source package?

Yes, that could be a possibility, also.  Thanks for your suggestion, I will
think about it.

-- 
Rafael


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#529081: ITP: oss-libsalsa -- Libsalsa is a library providing an ALSA interface on top of OSS

[Samuel Thibault]

Package: wnpp
Severity: wishlist
Owner: Samuel Thibault 


* Package name: oss-libsalsa
  Version : 4.1-build1052b
  Upstream Author : 4Front Technologies www.4front-tech.com
* URL : http://developer.opensound.com/sources/
* License : BSD
  Programming Lang: C
  Description : Libsalsa is a library providing an ALSA interface on top of 
OSS

 This packages provides a compatibility layer between OSS and ALSA: it
 is ABI-compatible with libasound (actually using alsa's headers), and
 just makes OSS ioctls.

 The idea would be to have libsalsa-dev provide libasound2-dev /
 libasound-dev, built only on archs that do not have the latter, to make
 sure buildds & co don't accidentally take it. libsalsa-asound2 just
 provides a libasound.so.2 symlink to libsalsa.so and can thus provide
 libasound2. That should permit to avoid having to fix all packages'
 build-deps for non-linux archs.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Heads-up: KDE4 hitting testing tonight (UTC)

[Adeodato Simó]

Hello,

For those following testing, this is just a quick mail to let you know
that KDE4 will become available in Squeeze with tonight's mirror pulse.
(It's KDE 4.2.2, I'm told 4.2.3 will shortly be uploaded to unstable.)

A note for compiz users: unfortunately it hasn't been possible to migrate
to testing the new compiz, useable with KDE4, because it also depends on
a newer GNOME. In order to upgrade to KDE4, you will have to temporarily
uninstall compiz-kde, or grab compiz-kde and dependencies from unstable.

Cheers,

-- 
Adeodato Simó
Debian Release Team


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#529094: ITP: nauty -- graph isomorphism testing library, with command line tools

[David Bremner]

Package: wnpp
Severity: wishlist
Owner: David Bremner 


* Package name: nauty
  Version : 2.4beta7
  Upstream Author : Brendan McKay 
* URL : http://cs.anu.edu.au/~bdm/nauty/
* License : non-free/pacifist. See below.
  Programming Lang: C
  Description : graph isomorphism testing library, with command line tools

 nauty (no automorphisms, yes?) is a set of procedures for determining
 the automorphism group of a vertex-coloured graph. It provides this
 information in the form of a set of generators, the size of the
 group, and the orbits of the group. It is also able to produce a
 canonically-labelled isomorph of the graph, to assist in isomorphism
 testing.

nauty is a build dependency of polymake (ITP 461976)

License is as follows:

Copyright (1984-2009) Brendan McKay. All rights reserved. Permission
is hereby given for use and/or distribution with the exception of sale
for profit or application with nontrivial military significance. You
must not remove this copyright notice, and you must document any
changes that you make to this program. This software is subject to
this copyright only, irrespective of any copyright attached to any
package of which this is a part.
  
Absolutely no guarantees or warranties are made concerning the
suitability, correctness, or any other aspect of this program. Any
use is at your own risk.  The above does not apply to the file
planarity.c, which is copyright to the Magma project and distributed
with nauty by permission.

Planarity.c says the following:

/* planarity.c - code for planarity testing of undirected graphs.
 * Method of Boyer and Myrvold, programmed by Paulette Lieby.
 * The copyright of this program is owned by the Magma project.
 * Distributed with nauty by permission.
 ***/


I expect to make 3 binary packages:
nautycommand line tools and manuals
libnauty-devstatic lib and headers
libnauty0   shlib




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: deprecating /usr as a standalone filesystem?

[Kel Modderman]

On Wednesday 06 May 2009 03:39:40 Steve Langasek wrote:
> On Tue, May 05, 2009 at 05:36:02PM +0200, Marco d'Itri wrote:
> > I have been told by upstream maintainers of one of my packages and by
> > prominent developers of other distributions that supporting a standalone
> > /usr is too much work and no other distribution worth mentioning does it
> > (not Ubuntu, not Fedora, not SuSE).
> 
> This is false for Ubuntu.  Not only is it supported, but significant effort
> was put into *fixing* a /usr-as-separate-mount bug in Ubuntu 9.04 as
> pertains to wpasupplicant.

Are the same changes (moving of runtime libs wpasupplicant uses to /lib)
likely to be handed back to Debian?

The same /usr-as-separate-mount bug is likely to strike iw and crda as well as
it did wpasupplicant.

Thanks, Kel.

Removal of remaining packages using GTK 1.2

[Moritz Muehlenhoff]

As requested by the release managers here's the announcement that
the remaining packages still using GTK 1.2 will be removed from
testing soon now that KDE 4 has transitioned to Squeeze (kdegraphics
3 still used imlib 1 and kdebindings from KDE 3 still had bindings
for GTK 1.2):

icewm
linpopup
wmclockmon
cheops
codebreaker
gaby
dbmix
gcrontab
gbuffy
gcvs
gcx
geg
gman
gps
gqcam
gtkpool
libjsw
i2e
ledcontrol
mah-jong
mbrowse
predict
xemacs21
swami
xoscope
xscorch

Cheers,
Moritz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [renamed] Debian crda?

[Kel Modderman]

Hi Luis, Paul,

(Dropped the CC to linux-wireless as it rejected my other attempt to send
message claiming it was part HTML/Spam. Apologies if you get two copies.)

On Friday 27 March 2009 14:00:20 Luis R. Rodriguez wrote:
> On Wed, Mar 25, 2009 at 9:59 PM, Paul Wise  wrote:
> > On Thu, Mar 26, 2009 at 1:19 PM, Luis R. Rodriguez  wrote:
> >
> >>> Brainwave: no need to add a second public key to CRDA itself, the
> >>> wireless-regdb could install the public key corresponding to the
> >>> private key it was built with.
> >>
> >> Can you elaborate on what you mean? Do you mean for wireless-regdb to
> >> put the actual pubkey into the users' system somewhere? Otherwise not
> >> sure what you mean.
> >
> > The crda package would contain the default upstream public key.
> >
> > The wireless-regdb would ship the Debian maintainer's pubkey as
> > debian/pubkeys/debian.pem in the source package and
> > /lib/crda/pubkeys/debian.pub.pem (or similar) in the binary package.

And all other pubkeys of members of packaging maintenance group.

> >
> > Ubuntu would add their pubkey in a similar way.

Ubuntu probably cannot build and sign their own regulatory.bin: AFAIK they
do source only uploads and package is built on remote buildd (with no access
to privkey for signing). They seem to just install linvilles pre-compiled
presigned regulatory.bin in the Ubuntu wireless-crda package and be happy
with that. 

> >
> > When wireless-regdb is built, it would:
> >
> > check the sha1sum/sha256sum of db.txt (alternatively upstream could
> > add a detached signature if possible to the tarball/git repo)
> >
> > if the db.txt is identical to the upstream one (or signed by
> > upstream), ship the upstream regulatory.bin file
> >
> > if the db.txt has been modified:
> >
> > if no private key is available, generate one automatically

I would rather the build process fail if the packager has not prepared
themselves a priv/pub key pair for maintaining wireless-regdb package or
else we could end up with a new key pair created on-the-fly and being used
to sign a regulatory.bin which is not recognised by the currently available
crda until it is recompiled with the new key in its PUBKEY_DIR.

Instead the debian packaging could provide some documentation/convenience
code for expected handling of maintainer priv/pub key pairs for signing
and authentication of regulatory.bin. Attempted to write such stuff here:

$ svn cat 
svn://svn.debian.org/svn/pkg-wpa/wireless-regdb/trunk/debian/README.maintainer
---
Add to debian/pubkeys all public keys which crda should consider when
verifying regulatory.bin. This should include all members of the pkg-wpa-devel
team who plan to work on or upload wireless-regdb or crda.

To generate an openssl key pair for packaging purposes:
  make -f debian/rules install-distro-key

This should create:
 ~/.wireless-regdb-pkg-wpa-devel.key.priv.pem
 ~/.wireless-regdb-pkg-wpa-devel.key.pub.pem

Copy the pubkey to debian/pubkeys and commit it to the VCS:
 cp ~/.wireless-regdb-pkg-wpa-devel.key.pub.pem \
debian/pubkeys/pkg-wpa-devel-${USER}.pub.pem
 svn add debian/pubkeys/pkg-wpa-devel-${USER}.pub.pem

When new keys are added to debian/pubkeys, the crda package needs to be
rebuilt with an updated versioned build dependency: the wireless-regdb
package version with the new key(s).

When building this package, the private key must be accessible so that
regulatory.bin can be signed by it to ensure the path of authentication
for the regulatory domain database is as good as possible. It does however
mean that the package cannot be built in a clean chroot (eg. pbuilder)
without having your ~/ bind mounted in it.
---

> >
> > rebuild the regulatory.bin file using the private key
> >
> > create the corresponding public key and install it in the package as
> > /lib/crda/pubkeys/custom.pub.pem when it is not the same public key as
> > one of the ones in debian/pubkeys/*.pem (avoids shipping two copies of
> > the Debian pubkey)

The pubkeys are small enough to not bother adding code and worry about having
a duplicate key in /lib/crda/pubkeys/ I think. At least at this stage it is
least of packaging worries.

> >
> > this scheme requires standard locations for the private key. I would
> > suggest either ~/.debian-wireless-regdb.priv.pem or
> > debian-wireless-regdb.priv.pem in the package build directory.
> >

Luis added some support code to handle this in wireless-regdb Makefile
recently.

>  It is possible for users to add more public keys to the CRDA  pubkeys
>  dir and build their own wireless-regdb using their own private key.
> >>>
> >>> The above simplification makes this much easier.
> >>
> >> Not sure what you mean, but the idea with the pubkeys directory
> >
> > The above scheme would allow users who apt-get source wireless-regdb,
> > edit db.txt, debuild, debi to automatically trust their own key, as
> > well as trusting Debian's key and the upstream key.

Made an attempt at packaging wireless-regdb and crda after th

Re: [renamed] Debian crda?

[Kel Modderman]

Hi Luis, Paul,

On Friday 27 March 2009 14:00:20 Luis R. Rodriguez wrote:
> On Wed, Mar 25, 2009 at 9:59 PM, Paul Wise  wrote:
> > On Thu, Mar 26, 2009 at 1:19 PM, Luis R. Rodriguez  wrote:
> >
> >>> Brainwave: no need to add a second public key to CRDA itself, the
> >>> wireless-regdb could install the public key corresponding to the
> >>> private key it was built with.
> >>
> >> Can you elaborate on what you mean? Do you mean for wireless-regdb to
> >> put the actual pubkey into the users' system somewhere? Otherwise not
> >> sure what you mean.
> >
> > The crda package would contain the default upstream public key.
> >
> > The wireless-regdb would ship the Debian maintainer's pubkey as
> > debian/pubkeys/debian.pem in the source package and
> > /lib/crda/pubkeys/debian.pub.pem (or similar) in the binary package.

And all other pubkeys of members of packaging maintenance group.

> >
> > Ubuntu would add their pubkey in a similar way.

Ubuntu probably cannot build and sign their own regulatory.bin: AFAIK they
do source only uploads and package is built on remote buildd (with no access
to privkey for signing). They seem to just install linvilles pre-compiled
presigned regulatory.bin in the Ubuntu wireless-crda package and be happy
with that. 

> >
> > When wireless-regdb is built, it would:
> >
> > check the sha1sum/sha256sum of db.txt (alternatively upstream could
> > add a detached signature if possible to the tarball/git repo)
> >
> > if the db.txt is identical to the upstream one (or signed by
> > upstream), ship the upstream regulatory.bin file
> >
> > if the db.txt has been modified:
> >
> > if no private key is available, generate one automatically

I would rather the build process fail if the packager has not prepared
themselves a priv/pub key pair for maintaining wireless-regdb package or
else we could end up with a new key pair created on-the-fly and being used
to sign a regulatory.bin which is not recognised by the currently available
crda until it is recompiled with the new key in its PUBKEY_DIR.

Instead the debian packaging could provide some documentation/convenience
code for expected handling of maintainer priv/pub key pairs for signing
and authentication of regulatory.bin. Attempted to write such stuff here:

$ svn cat 
svn://svn.debian.org/svn/pkg-wpa/wireless-regdb/trunk/debian/README.maintainer
---
Add to debian/pubkeys all public keys which crda should consider when
verifying regulatory.bin. This should include all members of the pkg-wpa-devel
team who plan to work on or upload wireless-regdb or crda.

To generate an openssl key pair for packaging purposes:
  make -f debian/rules install-distro-key

This should create:
 ~/.wireless-regdb-pkg-wpa-devel.key.priv.pem
 ~/.wireless-regdb-pkg-wpa-devel.key.pub.pem

Copy the pubkey to debian/pubkeys and commit it to the VCS:
 cp ~/.wireless-regdb-pkg-wpa-devel.key.pub.pem \
debian/pubkeys/pkg-wpa-devel-${USER}.pub.pem
 svn add debian/pubkeys/pkg-wpa-devel-${USER}.pub.pem

When new keys are added to debian/pubkeys, the crda package needs to be
rebuilt with an updated versioned build dependency: the wireless-regdb
package version with the new key(s).

When building this package, the private key must be accessible so that
regulatory.bin can be signed by it to ensure the path of authentication
for the regulatory domain database is as good as possible. It does however
mean that the package cannot be built in a clean chroot (eg. pbuilder)
without having your ~/ bind mounted in it.
---

> >
> > rebuild the regulatory.bin file using the private key
> >
> > create the corresponding public key and install it in the package as
> > /lib/crda/pubkeys/custom.pub.pem when it is not the same public key as
> > one of the ones in debian/pubkeys/*.pem (avoids shipping two copies of
> > the Debian pubkey)

The pubkeys are small enough to not bother adding code and worry about having
a duplicate key in /lib/crda/pubkeys/ I think. At least at this stage it is
least of packaging worries.

> >
> > this scheme requires standard locations for the private key. I would
> > suggest either ~/.debian-wireless-regdb.priv.pem or
> > debian-wireless-regdb.priv.pem in the package build directory.
> >

Luis added some support code to handle this in wireless-regdb Makefile
recently.

>  It is possible for users to add more public keys to the CRDA  pubkeys
>  dir and build their own wireless-regdb using their own private key.
> >>>
> >>> The above simplification makes this much easier.
> >>
> >> Not sure what you mean, but the idea with the pubkeys directory
> >
> > The above scheme would allow users who apt-get source wireless-regdb,
> > edit db.txt, debuild, debi to automatically trust their own key, as
> > well as trusting Debian's key and the upstream key.

Made an attempt at packaging wireless-regdb and crda after thinking about
stuff discussed in this thread, the proposed packaging is at:
  svn://svn.debian.org/svn/pkg-wpa/wireless-regdb/trunk/
  svn://svn.debia

Packaging the nusoap PHP lib instead of embedded copies ?

[Olivier Berger]

Hi.

It seems to me there are plenty of copies of the nusoap PHP lib [0]
embedded in lots of packages :-/

NuSOAP provides a PHP SOAP server code which allows lots of applications
to expose some web service (WSDL, SOAP methods, etc.)

I'm not sure how to verify which packages are affected with a Debian tool, 
btw... but
http://www.google.com/search?q=debian+filelist+nusoap.php+site:packages.debian.org
 
gives a first idea of the number...

I guess it may be better to have such a library in a separate package on
which the others would depend, although there may be counter arguments.

Any comments ?

FYI, my initial interest was in figuring out the feasibility of
packaging bits missing for mantis to provide a SOAP web service
interface (see #528776 for context).

Thanks in advance.

Best regards,

[0] : https://sourceforge.net/projects/nusoap/
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Packaging the nusoap PHP lib instead of embedded copies ?

[Neil Williams]

On Sun, 17 May 2009 23:11:00 +0200
Olivier Berger  wrote:

> Hi.
> 
> It seems to me there are plenty of copies of the nusoap PHP lib [0]
> embedded in lots of packages :-/
> 
> NuSOAP provides a PHP SOAP server code which allows lots of
> applications to expose some web service (WSDL, SOAP methods, etc.)
> 
> I'm not sure how to verify which packages are affected with a Debian
> tool, btw... but
> http://www.google.com/search?q=debian+filelist+nusoap.php+site:packages.debian.org
> gives a first idea of the number...

A better approach:

http://packages.debian.org/search?searchon=contents&keywords=nusoap.php&mode=path&suite=unstable&arch=any

You have searched for paths that end with nusoap.php in suite sid, all
sections, and all architectures. Found 7 results. File  Packages
/usr/share/dtc/shared/inc/nusoap.phpdtc-common
/usr/share/gforge/www/soap/nusoap.php   gforge-web-apache2
/usr/share/moodle/lib/soap/nusoap.php   moodle
/usr/share/phpgacl/soap/nusoap.php  phpgacl
/usr/share/phpwiki/lib/nusoap/nusoap.phpphpwiki
/usr/share/poker-web/nusoap.php poker-web
/usr/share/typo3/typo3_src-4.2/typo3/mod/tools/em/class.nusoap.php
typo3-src-4.2

However, to get any further, the mere filename collision needs to be
checked to see if these really are the same files or have the same
functionality.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/



pgpzv8H5CQx8M.pgp
Description: PGP signature

Bug#529183: ITP: gcc-mingw32 -- The GNU C compiler (cross compiler for MingW32)

[Robert Millan]

Package: wnpp
Severity: wishlist
Owner: Robert Millan 

* Package name: gcc-mingw32
  Version : 4.4
* URL : http://gcc.gnu.org/
* License : GPL
  Programming Lang: C
  Description : The GNU C compiler (cross compiler for MingW32)

 Build of GCC for MingW32.  This package includes support for C for
 cross-compiling to a win32 using the MingW32 runtime.

Notes:

  - Should not be confused with the MingW32 compiler, which is a
derivative of GCC 4.2 (I think the descriptions of both packages
are clear enough, but suggestions welcome).

  - Build will be made by reliing on the gcc-source package, which
removes the need to add a separate .orig.tar.gz to the archive.

-- System Information:
Debian Release: 5.0.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: deprecating /usr as a standalone filesystem?

[Steve Langasek]

On Mon, May 18, 2009 at 06:25:07AM +1000, Kel Modderman wrote:
> On Wednesday 06 May 2009 03:39:40 Steve Langasek wrote:
> > On Tue, May 05, 2009 at 05:36:02PM +0200, Marco d'Itri wrote:
> > > I have been told by upstream maintainers of one of my packages and by
> > > prominent developers of other distributions that supporting a standalone
> > > /usr is too much work and no other distribution worth mentioning does it
> > > (not Ubuntu, not Fedora, not SuSE).

> > This is false for Ubuntu.  Not only is it supported, but significant effort
> > was put into *fixing* a /usr-as-separate-mount bug in Ubuntu 9.04 as
> > pertains to wpasupplicant.

> Are the same changes (moving of runtime libs wpasupplicant uses to /lib)
> likely to be handed back to Debian?

That would be the goal, but of course there are more maintainers who need to
be coordinated with in the case of Debian so there's no telling how much
longer it will take to get all the changes in.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#529183: ITP: gcc-mingw32 -- The GNU C compiler (cross compiler for MingW32)

[Neil Williams]

On Sun, 17 May 2009 23:33:29 +0200
Robert Millan  wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Robert Millan 
> 
> * Package name: gcc-mingw32
>   Version : 4.4
> * URL : http://gcc.gnu.org/
> * License : GPL
>   Programming Lang: C
>   Description : The GNU C compiler (cross compiler for MingW32)

How is this different to a cross compiler for armel, mips, mipsel etc.?

Shouldn't the binary package name be gcc-mingw32-linux-gnu or similar?

>  Build of GCC for MingW32.  This package includes support for C for
>  cross-compiling to a win32 using the MingW32 runtime.
> 
> Notes:
> 
>   - Should not be confused with the MingW32 compiler, which is a
> derivative of GCC 4.2 (I think the descriptions of both packages
> are clear enough, but suggestions welcome).

>   - Build will be made by reliing on the gcc-source package, which
> removes the need to add a separate .orig.tar.gz to the archive.

If we have a method for one, why not use it for all? What is different
with ming?

How do we have a "source package" (the ITP) without source or relying
on source that is part of another package.

It would be good if we could have a way of doing this, it's about time
we could get cross-compilers into Debian longterm without adding yet
more binary packages to the existing gcc workload.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/



pgpkCwdDQ1uth.pgp
Description: PGP signature

Bug#529192: ITP: debian-timeline -- Web-based timeline of the Debian GNU/Linux project

[Chris Lamb]

Package: wnpp
Severity: wishlist
Owner: Chris Lamb 
X-Debbugs-Cc: debian-devel@lists.debian.org

 * Package name: debian-timeline
   Version : 1
   Upstream Author : Chris Lamb 
 * URL : http://timeline.debian.net/
 * License : Public domain
   Programming Lang: Javascript
   Description : Web-based timeline of the Debian GNU/Linux project

  The Debian Project timeline is a HTML and Javascript-based interactive
  timeline of the Debian GNU/Linux project. It includes the dates of:

   * All Debian releases, including point releases and freeze windows
   * Infrastructure changes
   * Conferences and bug-squashing parties
   * General resolution and DPL votes
   * Important releases of Debian-specific and third-party software
   * Curiosa items such as anniversaries and bug number milestones
   * (and more)

This package will contain a local copy of the timeline currently available
at , providing end-users with something to show
off at conferences (etc.) and to provide a real package to file bug reports
against.

By the way, if anyone was previously put off contributing by the dumb
syntax, please note that it changed to a more familiar 822-based syntax.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org
   `-


signature.asc
Description: PGP signature

Re: Bug#529192: ITP: debian-timeline -- Web-based timeline of the Debian GNU/Linux project

[Daniel Moerner]

On Sun, May 17, 2009 at 3:24 PM, Chris Lamb  wrote:

 * Package name    : debian-timeline
  Version         : 1


Are you considering using the version to better reflect when the package was 
last updated? It seems to me that there are two plausible versioning schemes: 
To do it by the date when you fetch an updated timeline from the website and 
upload it, or to make the version reflect the most current Debian revision in 
the timeline (e.g. 5.0.1 now).

Regards,
Daniel

--
Daniel Moerner 



signature.asc
Description: OpenPGP digital signature

Re: Bug#529192: ITP: debian-timeline -- Web-based timeline of the Debian GNU/Linux project

[Chris Lamb]

Daniel Moerner wrote:

> Are you considering using the version to better reflect when the package
> was last updated?
[..]
> do it by the date when you fetch an updated timeline from the website and
> upload it

.. then it's just a (more-visible) duplication of the date in the changelog.

(I sense a slight confusion in your question; the website and the package
are generated from the same repository)

> or to make the version reflect the most current Debian revision in the
> timeline (e.g. 5.0.1 now).

I fear it would change too often to make that worthwhile.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org
   `-


signature.asc
Description: PGP signature

Re: Bug#529183: ITP: gcc-mingw32 -- The GNU C compiler (cross compiler for MingW32)

[Samuel Thibault]

Neil Williams, le Sun 17 May 2009 23:25:36 +0100, a écrit :
> On Sun, 17 May 2009 23:33:29 +0200
> Robert Millan  wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Robert Millan 
> > 
> > * Package name: gcc-mingw32
> >   Version : 4.4
> > * URL : http://gcc.gnu.org/
> > * License : GPL
> >   Programming Lang: C
> >   Description : The GNU C compiler (cross compiler for MingW32)
> 
> How is this different to a cross compiler for armel, mips, mipsel etc.?
> 
> Shouldn't the binary package name be gcc-mingw32-linux-gnu or similar?

I guess you mean gcc-i686-pc-mingw32. This is not a cross-compiler to a
debian system, but to the windows system.

> >   - Should not be confused with the MingW32 compiler, which is a
> > derivative of GCC 4.2 (I think the descriptions of both packages
> > are clear enough, but suggestions welcome).

Will it be useful to keep that one?

> >   - Build will be made by reliing on the gcc-source package, which
> > removes the need to add a separate .orig.tar.gz to the archive.
> 
> If we have a method for one, why not use it for all? What is different
> with ming?

Not being targeted at a debian system.

> How do we have a "source package" (the ITP) without source or relying
> on source that is part of another package.

just like gcj-4.4 works.

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Packaging the nusoap PHP lib instead of embedded copies ?

[Chris Lamb]

Neil Williams wrote:

> A better approach:
[..]
> You have searched for paths that end with nusoap.php in suite sid, all
> sections, and all architectures. Found 7 results. FilePackages

An even better approach in the long term would be to add a Lintian check
that flags up this common code copy.

However, doing so would be dependent on a proper package existing - Olivier,
please go ahead and package it.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org
   `-


signature.asc
Description: PGP signature

Bug#529196: ITP: octave-nlwing2 -- nonlinear lifting line for wings in Octave

[Rafael Laboissiere]

Package: wnpp
Severity: wishlist
Owner: Rafael Laboissiere 

* Package name: octave-nlwing2
  Version : 1.1.1
  Upstream Author : Jaroslav Hajek 
* URL : http://octave.sourceforge.net/nlwing2
* License : GPL-3+
  Programming Lang: Octave
  Description : nonlinear lifting line for wings in Octave

This package allows efficient computation of nonlinear aerodynamic
properties of a wing in Octave, a scientific computing software. It
employs 2D section data to build a 3D potential vortex model of the
flow. It uses a robust Euler-Newton method to track the change of
flow vorticity quantities as the angle of attack progresses.
 
This Octave add-on package is part of the Octave-Forge project.

Initial Debian package at
http://git.debian.org/?p=pkg-octave/octave-nlwing2.git

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'unstable'), (500, 'oldstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#529183: ITP: gcc-mingw32 -- The GNU C compiler (cross compiler for MingW32)

[Robert Millan]

On Mon, May 18, 2009 at 12:39:12AM +0200, Samuel Thibault wrote:
> > >   - Build will be made by reliing on the gcc-source package, which
> > > removes the need to add a separate .orig.tar.gz to the archive.
> > 
> > If we have a method for one, why not use it for all? What is different
> > with ming?
> 
> Not being targeted at a debian system.

Notice we have a few examples of cross-compilers for non-debian arches
being built this way:

  gcc-avr - The GNU C compiler (cross compiler for avr)
  gcc-h8300-hms - The GNU C compiler (cross compiler for h8300-hitachi-coff)
  gcc-m68hc1x - GNU C compiler for the Motorola 68HC11/12 processors

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#529204: ITP: sqliteman -- GUI tool for sqlite3 admin and developers alike

[Rolf Leggewie]

Package: wnpp
Severity: wishlist
Owner: Rolf Leggewie 

* Package name: sqliteman
  Version : 1.2.1
  Upstream Author : Petr Vanek, p...@scribus.info
* URL : http://sqliteman.com
* License : GPL, LGPL
  Programming Lang: C++
  Description : GUI tool for sqlite3 admin and developers alike

Contains the most complete feature set of all sqlite GUI available. Tune
SQL statements, manage tables, views or triggers, administrate the database 
space and index statistics with SQLiteman.

The packaging is ready for inspection at 
http://mentors.debian.net/debian/pool/contrib/s/sqliteman
I intend to co-maintain this with David Claughton .



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [renamed] Debian crda?

[Paul Wise]

On Mon, May 18, 2009 at 4:42 AM, Kel Modderman  wrote:

> (Dropped the CC to linux-wireless as it rejected my other attempt to send
> message claiming it was part HTML/Spam. Apologies if you get two copies.)

Maybe you should send plain text email instead?

> I would rather the build process fail if the packager has not prepared
> themselves a priv/pub key pair for maintaining wireless-regdb package or
> else we could end up with a new key pair created on-the-fly and being used
> to sign a regulatory.bin which is not recognised by the currently available
> crda until it is recompiled with the new key in its PUBKEY_DIR.

Uhh, what? Does crda not read all of the keys available in its pubkey
dir? If not, the scheme I imagined is completely wrong. I assumed that
crda would look at /lib/crda/pubkeys at runtime when it starts up
rather than everything being compiled into the binary.

> Instead the debian packaging could provide some documentation/convenience
> code for expected handling of maintainer priv/pub key pairs for signing
> and authentication of regulatory.bin. Attempted to write such stuff here:

Seems reasonable.

> When new keys are added to debian/pubkeys, the crda package needs to be
> rebuilt with an updated versioned build dependency: the wireless-regdb
> package version with the new key(s).

Why is this? Isn't it enough to just install the wireless-regdb
package containing the new key?

> Made an attempt at packaging wireless-regdb and crda after thinking about
> stuff discussed in this thread, the proposed packaging is at:
> svn://svn.debian.org/svn/pkg-wpa/wireless-regdb/trunk/
> svn://svn.debian.org/svn/pkg-wpa/crda/trunk/
>
> Can people please take a good look at this please to make sure it is a
> viable packaging effort?

A review:

Please file ITP bugs.

Circular dependencies are bad, please drop the wireless-regdb -> crda
Depends down to a Suggests.

The wireless-regdb patches look like they belong upstream.

Please adjust the packaging so it works on lenny, you've used some
debhelper/quilt features that don't work there (or in testing yet). At
some point we'll have lennyandahalf and I think a cf80211/mac80211
kernel plus crda/wireless-regdb are an important part of that.

I'm a bit worried about the Build-Depends on tzdata, does that mean
crda embeds the TZ data in its binary and needs a binNMU whenever
tzdata is updated? This is especially bad for TZ updates in stable.
Ah, I see you only embed it in /lib/crda/setregdomain_zone_codes,
which still means binNMUs. I suggest that you send upstream a patch
for doing this TZ -> regdomain mapping at runtime in the crda binary
using the installed zone.tab file when available. Preferably it should
detect when the zone.tab file is updated and reload the mapping and
reset the regdomain based on the mapping.

See my comment above about embedding the wireless-regdb keys in the
binary, which I think is a bad idea.

Please use these as the homepages, they are slightly more specific:

http://wireless.kernel.org/en/developers/Regulatory/#CRDA
http://wireless.kernel.org/en/developers/Regulatory/#Theregulatorydatabase

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]

[Micah Anderson]

Manoj Srivastava  writes:

>> On Sat, May 09, 2009 at 10:22:40PM -0500, Manoj Srivastava wrote:
> Given that, I would say that churning the installation by making
>  a supermajority of sites change their MTA seems like a non-starter to
>  me.

I do not see how changing the default MTA for future Debian installs
will cause churn for people. If people are happy with continuing on with
their currently installed Exim4 packages, they will continue to be happy
with that, and should not be forced to change MTAs.

Debian deciding to change MTAs affects new installs, and it signals a
choice that this is the MTA that we would like to support as our
default. 

I'm not sure why other distributions have decided to choose Postfix as
their default, but if I were to take a guess I would think that it is
because it is easier for new users to setup. But perhaps that is a
subjective assessment based on my own experiences.

micah


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Grub on CF card

[Ravi]

Dear all,
Could you please tell me how to install grub on CF card.

I'm getting following error while installing

grub> setup(hd2,0) Floating point error


And when I'm trying 
#grub-install --root-directory=/media/CF /dev/sdc

It says /boot/stage2 could not read correctly..


Please help me,
I'm struggling for this for long time


with regards

Ravi

Re: Packaging the nusoap PHP lib instead of embedded copies ?

[Neil Williams]

On Sun, 17 May 2009 23:18:40 +0100
Chris Lamb  wrote:

> Neil Williams wrote:
> 
> > A better approach:
> [..]
> > You have searched for paths that end with nusoap.php in suite sid,
> > all sections, and all architectures. Found 7 results. File
> > Packages
> 
> An even better approach in the long term would be to add a Lintian
> check that flags up this common code copy.

Same problem really - lintian only works on one package at a time and
cannot detect code copying, except by a simple name collision with a
"hot list" in lintian itself. Such a scheme still doesn't compare the
contents of the file rather than simply the name of the file itself.
 
> Olivier, please go ahead and package it.

Agreed. Also, when packaging it, check the 7 source packages that I
listed above and see if the copies have been substantially modified.
You may need to fold some of those changes into the library version.
Then, file bugs against the relevant packages once the new package is
in NEW.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/



pgpAfHmIoNh3l.pgp
Description: PGP signature