Re: Problemes with the debian archives or apt?

[Bartosz Fenski aka fEnIo]

On Thu, Jul 28, 2005 at 08:57:20AM +0200, Klaus Ethgen wrote:
> Hello,

Hi. 

> I notive that for about a week there is NO package upgrade in sid. This
> is realy unusual.
> 
> Is there any problem with the package servers or with apt (version
> 0.6.38)?

Two of Debian's machines were being moved in that time to their new
location. On of them is responsible for NO package upgrade.

You should read debian-devel-announce list if you want to know about such
issues:

Info about relocation:
http://lists.debian.org/debian-devel-announce/2005/07/msg00013.html

Info about its finish:
http://lists.debian.org/debian-devel-announce/2005/07/msg00018.html

There should be new packages todays evening.

regards
fEnIo 
-- 
  ,''`.  Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo
 : :' :   32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland
 `. `'   phone:+48602383548 | proud Debian maintainer and user
   `-  http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001


signature.asc
Description: Digital signature

Re: Problemes with the debian archives or apt?

[Florian Weimer]

* Klaus Ethgen:

> I notive that for about a week there is NO package upgrade in sid. This
> is realy unusual.

A server at the heart of the archive update process has been
relocated.  It is expected that this work has been completed (see
debian-devel-announce), so regular development should continue very
soon.


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

Re: Documentation of alioth?

[Florian Weimer]

* Raphael Hertzog:

> Now haydn is running sarge so it's relatively easy to duplicate alioth
> on a local (virtual) machine (before the mixture of woody/sarge was
> suboptimal). You have the sources and the packages running on alioth...
> you can provide patches that apply to Alioth's version of gforge.

This is ridiculous.  With this attitude, you will never receive any
substantial help with alioth system administration.  It's unlikely
that anyone who 

For example, issue #301374 is caused by explicit configuration which
disables POST requests, in /srv/svn.debian.org/etc/apache.conf:



deny from all



It's unlikely that someone rebuilding alioth from scratch would make
the same mistake (and you can't really reuse all these configuration
files).


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

Re: libxml++2.10

[Nikita V. Youshchenko]

> > For one of our internal projects, libxml++2.6 was too old.
> > So I've created a package for libxml++2.10, using debian/ dir for the
> > latest libxml++2.6 package.
>
> I packaged it for Ubuntu - libxml++2.6 and libxml++2.10 were never
> designed to be installable parallely.

I believe my package could be installed parallely with 2.6
However, I don't know if it is worth doing so.

> I talked to upstream and they 
> said, the ABI broke during the development unintentionally, but we
> should better stick to libxml++2.6-2.10.0 and recompile the dependent
> packages.

Is 2.10 backward-compatable with 2.6 at ABI level ?


pgpFvA3O4m48P.pgp
Description: PGP signature

Re: SUMMARY: Re: shared library -dev package naming proposal

[Junichi Uekawa]

Hi,

> > - Kill the .la files and .a files.  Drop support for static linking.  Not
> >   something that should be done lightly and without prior project-wide
> >   discussion.
> > - Leave the .la files in place; -dev packages need to depend on -dev
> >   packages corresponding to those runtime dependencies that are also
> > built using libtool.  This is the status quo.
> 
> - Option 4 (requires volunteers): fix libtool

Blankly stating that libtool needs to be 'fixed'
because it is 'broken' is not very helpful.
Would you care to explain what needs to be fixed and why 
it is broken?  Good working examples would be good.

The following are background informations, please do comment
if you find something is wrong about these:

libnewt is an example library that requires libslang.
The names are just symbollic; they just represent
random library.

fact 1: shared library 

  gcc -lnewt a.c
should work, since slang dependency is declared in NEEDED field
of libnewt.so, which the link will be resolved at run-time.

fact 2: static library

  gcc -lslang -lnewt a.c
is required for static lib linking, since .a files do not have
dependency information, and symbols need to be resolved at link time.


fact 3: libtool library
libtool tries to implement a wrapper around shared library and 
static library, so that both of them can be uniformly processed,
and allows specifying just:
  libtool cc -lnewt a.c

(implementation detail: .la files contain the dependency 
information for .a).


Debian implementation:

Packages Build-Depend on -dev packages they directly require,
thus a package requiring newt will Build-Depend on libnewt-dev,
but not libslang2-dev.

libnewt-dev will need to Depend on libslang2-dev, or
static lib compilation with libtool will break.

regards,
junichi

-- 
Junichi Uekawa, Debian Developer   http://www.netfort.gr.jp/~dancer/
183A 70FC 4732 1B87 57A5  CE82 D837 7D4E E81E 55C1 


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

Re: libxml++2.10

[Daniel Holbach]

Hi Nikita,

Am Donnerstag, den 28.07.2005, 12:04 +0400 schrieb Nikita V.
Youshchenko:
> > I talked to upstream and they 
> > said, the ABI broke during the development unintentionally, but we
> > should better stick to libxml++2.6-2.10.0 and recompile the dependent
> > packages.
> 
> Is 2.10 backward-compatable with 2.6 at ABI level ?

As I said, the ABI broke unintentionally (and they were most agrieved),
so I guess there might be some glitches. Upstream advised us to
recompile the depending packages. I'm not sure at which stage the ABI
broke (from which version on).

I got Murray Cumming in a mail conversation with all the Debian package
maintainers back then, but I can't really tell, how the current state in
Debian is.

Have a nice day,
 Daniel



signature.asc
Description: This is a digitally signed message part

Re: libxml++2.10

[Steve Langasek]

On Thu, Jul 28, 2005 at 10:49:07AM +0200, Daniel Holbach wrote:
> Hi Nikita,

> Am Donnerstag, den 28.07.2005, 12:04 +0400 schrieb Nikita V.
> Youshchenko:
> > > I talked to upstream and they 
> > > said, the ABI broke during the development unintentionally, but we
> > > should better stick to libxml++2.6-2.10.0 and recompile the dependent
> > > packages.

> > Is 2.10 backward-compatable with 2.6 at ABI level ?

> As I said, the ABI broke unintentionally (and they were most agrieved),
> so I guess there might be some glitches. Upstream advised us to
> recompile the depending packages. I'm not sure at which stage the ABI
> broke (from which version on).

"Just recompile" isn't acceptable for Debian; I'd be surprised if it is for
Ubuntu either.  If the ABI has changed, the library runtime package name
must change with it even if the library soname has not due to upstream
error.

This is particularly important given that libxml++2.6 was present in a
stable release of Debian.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: SUMMARY: Re: shared library -dev package naming proposal

[Stephen Frost]

* Steve Langasek ([EMAIL PROTECTED]) wrote:
> On Wed, Jul 27, 2005 at 08:57:51PM -0400, Stephen Frost wrote:
> > * Steve Langasek ([EMAIL PROTECTED]) wrote:
> > > On Wed, Jul 27, 2005 at 07:20:44PM -0400, Stephen Frost wrote:
> > > > libtool is broken in this regard and needs to be fixed to survive
> > > > missing files.
> 
> > > Then fix it instead of giving people bad advice.
> 
> > Do you actually have anything beyond "libtool breaks otherwise, so it
> > *must* be good!"?  Here's some advice: rm *.la.  Yay, fixes the problem
> > *and* doesn't require everyone to add in dependencies that end up
> > pulling in hundreds of unneeded packages when trying to build something.
> 
> Dropping .la files, without also dropping .a files, will unnecessarily
> complicate matters for anyone statically linking against that lib.  As long
> as we still nominally support static linking, I expect that most lib
> maintainers are not going to be willing to do this.
> 
> But ok, yes, that is an option; let's spell the options out completely:
> 
> - Don't ship .la files in the -dev package; don't depend on any other -dev
>   packages except those whose headers you need.  This gives optimal results
>   for shared linking by pruning all unnecessary build-dependencies and
>   dependencies; but it also screws over anyone trying to do static linking,
>   who now has to go *recursively* hunt down the package name for each of the
>   library dependencies, based only on the names of the symbols exported.
>   (So why would anyone ship the static libs at this point...?)

If we want to support static linking then let's break it off into it's
own '-static' package with appropriate dependencies.  Personally I don't
think it's really worth it and we should just go ahead and drop the
static libraries too.  It'd certainly make the -dev packages alot
smaller.  Maybe then we could just put -dbg stuff in the -dev packages.
:)

> - Kill the .la files and .a files.  Drop support for static linking.  Not
>   something that should be done lightly and without prior project-wide
>   discussion.

We've had that discussion before.  Last I recall there wasn't really a
huge fight to keep them.

Stephen


signature.asc
Description: Digital signature

Re: SUMMARY: Re: shared library -dev package naming proposal

[Stephen Frost]

* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> > - Option 4 (requires volunteers): fix libtool
> 
> Blankly stating that libtool needs to be 'fixed'
> because it is 'broken' is not very helpful.
> Would you care to explain what needs to be fixed and why 
> it is broken?  Good working examples would be good.

One of the issues associated with just dropped .la files was that
libtool apparently doesn't handle having a .la file go missing in the
middle of a dependency chain.

ie: libfoo is built against libbar, both using libtool and both having
.la files.  libbar's .la file is then removed.  If you try to build
libxyz against libfoo, libtool will break because libfoo's .la says
libbar should have a .la but it doesn't.

Making libtool handle the missing .la file case for shared linking (at
least) would drop the requirement that -dev packages depend on -dev
packages when building shared libraries.  On Debian, at least, the .la
files generally shouldn't be necessary unless you're doing static
building.  Even then I don't think they're actually necessary until you
get up to the application that you want to build statically.  That is to
say, you shouldn't need them to build a static version of your library
unless you also build into that .a all the other libraries your library
depends on, and that's certainly not something we'd want to do.

> The following are background informations, please do comment
> if you find something is wrong about these:
> 
> libnewt is an example library that requires libslang.
> The names are just symbollic; they just represent
> random library.
> 
> fact 1: shared library 
> 
>   gcc -lnewt a.c
> should work, since slang dependency is declared in NEEDED field
> of libnewt.so, which the link will be resolved at run-time.
> 
> fact 2: static library
> 
>   gcc -lslang -lnewt a.c
> is required for static lib linking, since .a files do not have
> dependency information, and symbols need to be resolved at link time.
> 
> 
> fact 3: libtool library
> libtool tries to implement a wrapper around shared library and 
> static library, so that both of them can be uniformly processed,
> and allows specifying just:
>   libtool cc -lnewt a.c
> 
> (implementation detail: .la files contain the dependency 
> information for .a).

The issue here is that libtool doesn't need the .la files when doing
shared linking, but it breaks if it's not there when another .la file
said it should be.

> Debian implementation:
> 
> Packages Build-Depend on -dev packages they directly require,
> thus a package requiring newt will Build-Depend on libnewt-dev,
> but not libslang2-dev.
> 
> libnewt-dev will need to Depend on libslang2-dev, or
> static lib compilation with libtool will break.

This isn't actually the problem, if only static lib compilation broke I
don't think people would actually care all that much.  The problem is
that *shared* library compilation with libtool breaks, which is a
problem with libtool.

Stephen


signature.asc
Description: Digital signature

Re: SUMMARY: Re: shared library -dev package naming proposal

[Jay Berkenbilt]

Steve Langasek <[EMAIL PROTECTED]> wrote:

> - Leave the .la files in place; -dev packages need to depend on -dev
>   packages corresponding to those runtime dependencies that are also built
>   using libtool.  This is the status quo.

If we do this (which I think we should for now), I would suggest that
we have a debhelper script analogous to dh_shlibdeps that parses .la
files to automatically generate -dev build dependencies, and that this
should also be fixed if libtool is fixed (and should detect whether it
is using a fixed libtool).  Then maintainers of libraries that use
libtool will automatically get the -dev dependencies required to
satisfy issues with libtool now, and if/when libtool is fixed, those
dependencies can disappear automatically without having to have all
the maintainers go through a lot of trouble twice.

My suggestion doesn't solve the problem, but it does make it easier to
deal with.  Maybe this already exists and I'm just not aware of it.
I've been thinking about writing this for a while since I maintain
several libraries that use libtool and have made the mistake of
forgetting a -dev dependency before.

--Jay


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

Re: SUMMARY: Re: shared library -dev package naming proposal

[Steve Langasek]

On Thu, Jul 28, 2005 at 08:29:52AM -0400, Jay Berkenbilt wrote:
> Steve Langasek <[EMAIL PROTECTED]> wrote:

> > - Leave the .la files in place; -dev packages need to depend on -dev
> >   packages corresponding to those runtime dependencies that are also built
> >   using libtool.  This is the status quo.

> If we do this (which I think we should for now), I would suggest that
> we have a debhelper script analogous to dh_shlibdeps that parses .la
> files to automatically generate -dev build dependencies, and that this
> should also be fixed if libtool is fixed (and should detect whether it
> is using a fixed libtool).  Then maintainers of libraries that use
> libtool will automatically get the -dev dependencies required to
> satisfy issues with libtool now, and if/when libtool is fixed, those
> dependencies can disappear automatically without having to have all
> the maintainers go through a lot of trouble twice.

> My suggestion doesn't solve the problem, but it does make it easier to
> deal with.  Maybe this already exists and I'm just not aware of it.
> I've been thinking about writing this for a while since I maintain
> several libraries that use libtool and have made the mistake of
> forgetting a -dev dependency before.

It doesn't exist; I think it's a great idea.  Perhaps a tool named
dh_libtool, which populates a substvar named ${libtool:Depends}?

FWIW, detecting a fixed libtool would be rather difficult, since it's the
libtool used by the depending application which does the recursion and
therefore needs to be fixed.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: SUMMARY: Re: shared library -dev package naming proposal

[Stephen Frost]

* Steve Langasek ([EMAIL PROTECTED]) wrote:
> It doesn't exist; I think it's a great idea.  Perhaps a tool named
> dh_libtool, which populates a substvar named ${libtool:Depends}?

This sounds reasonable to me; I appriciate that it's a libtool-specific
thing and not a blanket policy. :)

> FWIW, detecting a fixed libtool would be rather difficult, since it's the
> libtool used by the depending application which does the recursion and
> therefore needs to be fixed.

I'd think we could come up with a way to detect the version of libtool
in use, somehow. :)  Could always have the tool accept a command-line
option to force it one way or the other.  Then we could run around and
file bugs to use the tool, and then bugs to upgrade libtool. :)

Stephen


signature.asc
Description: Digital signature

Re: libxml++2.10

[Nikita V. Youshchenko]

> Hi Nikita,
>
> Am Donnerstag, den 28.07.2005, 12:04 +0400 schrieb Nikita V.
>
> Youshchenko:
> > > I talked to upstream and they
> > > said, the ABI broke during the development unintentionally, but we
> > > should better stick to libxml++2.6-2.10.0 and recompile the
> > > dependent packages.
> >
> > Is 2.10 backward-compatable with 2.6 at ABI level ?
>
> As I said, the ABI broke unintentionally (and they were most agrieved),
> so I guess there might be some glitches. Upstream advised us to
> recompile the depending packages. I'm not sure at which stage the ABI
> broke (from which version on).

If so, I believe soname should be changed, to meet Debian quality 
standards.


pgpwC4dRegZnF.pgp
Description: PGP signature

Re: SUMMARY: Re: shared library -dev package naming proposal

[Steve Greenland]

On 28-Jul-05, 03:02 (CDT), Junichi Uekawa <[EMAIL PROTECTED]> wrote: 
> fact 1: shared library 
> 
>   gcc -lnewt a.c

Right. No problem.

> fact 2: static library
> 
>   gcc -lslang -lnewt a.c

Right, Just like it's always been on Unix systems.

> fact 3: libtool library
> libtool tries to implement a wrapper around shared library and 
> static library, so that both of them can be uniformly processed,
> and allows specifying just:
>   libtool cc -lnewt a.c

Why is this better? I have to change my perfectly normal, standard Unix
link command to use something that completely hides the actual link
command and makes debugging problems nearly impossible? I really don't
get it. And, for the record, the company I work for ships code for a
variety of Unices. I spend a *lot* more of my time debugging libtool
brokenness (not to mention auto* brokeness) than I do tracking down
which libraries need which other libraries. So when I say "I don't get
it", it's not lack of experience with the tools, I'm just completely
mystified why people think that libtool is an *improvement*.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


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

Re: doomsday not DFSG (was Re: ITP: doomsday - greatly improved engine to play doom, doom2, heretic and hexen)

[Alexander Fieroch]

Jon Dowland wrote:

I've added the original ITPer to the CC list, as he hasn't contributed
to this thread (and so I don't know if he reads -devel). 


Alexander, your ITP has generated a bit of discussion: see
.


Thanks. Indeed I didn't read this thread but I can not contribute -  I'm 
not a doom programmer. But I'm very interested to have a doom port in 
debian.



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

Re: Please participate in popularity-contest

[Philip Ross]

Helmut Wollmersdorfer wrote:

Graham Wilson wrote:


On Tue, Jul 26, 2005 at 03:12:10PM +0200, Goswin von Brederlow wrote:



There might eb
cases where it harms but those should be the minority.



Seems to make sense. Are there any cases where having anacron installed
by default would mess something up?


I would not like to have it on 7/24 servers. There could be problems 
after longer power outages in combination with weak scripts (which use 
dates as file names). But this "should be the minority". And such logic 
will even have problems without anacron.


Anacron provides protection against running cron jobs a second time due 
to a reboot or power outage. The first task in 
cron.(daily|weekly|monthly) runs anacron -u cron.(daily|weekly|monthly). 
This updates anacron's last run timestamp with the current date. When 
anacron next runs at boot, it will only run the tasks using anacron if a 
day, week or month have elapsed since the last timestamp was written.


Phil


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

Re: Bug#320067: ITP: vamps -- Vamps evaporates DVD compliant MPEG2 program streams by selectively copying audio and subpicture tracks and by re-quantizing the embedded elementary video stream.

[Ron Johnson]

On Wed, 2005-07-27 at 09:57 -0400, Eric Cooper wrote:
> On Wed, Jul 27, 2005 at 12:09:18AM +0300, Lars Wirzenius wrote:
> > ti, 2005-07-26 kello 21:36 +0200, Moratti Claudio kirjoitti:
> > >   Description : Vamps evaporates DVD compliant MPEG2 program streams 
> > > by selectively copying audio and subpicture tracks and by re-quantizing 
> > > the embedded elementary video stream.
> > 
> > This short description is a bit long and it also leaves it unclear to me
> > what the program actually does. The verb evaporate means, according the
> > WordNet dictionary:
> > [...] 
> > At a guess, does vamps make MPEG2 streams smaller?
> 
> Perhaps a confusion of "evaporate" with "condense"?  (Maybe the
> thermodynamic equivalent of an "off by 1" error? :-)

"off by 1" or "inverse"?  Anyway... tolerance for non-native English
speakers.

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B I prefer encrypted mail.

"He that would live in peace and at ease must not speak all he
knows or all he sees."
Benjamin Franklin



signature.asc
Description: This is a digitally signed message part

Re: Please participate in popularity-contest

[Ron Johnson]

On Wed, 2005-07-27 at 22:00 +0200, Petter Reinholdtsen wrote:
> [Ron Johnson]
> > Soon after you put it in Experimental, installed it, for that very
> > reason.
> 
> I got a parse error on this one.  I suspect you are unaware that the
> HTTP option is available in unstable, version 1.30.

Yes.  But I installed it back when it entered Exprimental.

> > Maybe a post to d-u would spread the word.
> 
> Yes, that would be nice.  But I leave that to someone reading that
> list. :)

I think I can do that.

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B I prefer encrypted mail.

In 1929, when the Great Depresion hit, while all the other
tabulating companies retrenched, Thomas Watson Sr. insisted that
IBM's factories stay open and R&D spending increase. Thus, in
1935 when FDR signed the Social Security Act, and businesses and
gov't had a huge need for tabulating/sorting machines, IBM was in
position to dominate the industry, and did so for the next 45
years.



signature.asc
Description: This is a digitally signed message part

Re: problem installing libmotif-dev on debian sarge stable

[Daniel Burrows]

On Tuesday 26 July 2005 07:24 am, Frederico Rodrigues Abraham wrote:
> Hi. I am trying to install the development files for motif but i get this:
>
> porter:~# apt-get install libmotif-dev

  What do you get if you chase dependencies by hand by running:

apt-get install libmotif-dev xlibs-dev

  Daniel

-- 
/--- Daniel Burrows <[EMAIL PROTECTED]> --\
|All generalizations are dangerous. |
\ The Turtle Moves! -- http://www.lspace.org ---/


pgp8CRCPSLKLB.pgp
Description: PGP signature

Re: SUMMARY: Re: shared library -dev package naming proposal

[Jay Berkenbilt]

Steve Langasek <[EMAIL PROTECTED]> wrote:

> It doesn't exist; I think it's a great idea.  Perhaps a tool named
> dh_libtool, which populates a substvar named ${libtool:Depends}?

Sounds good to me.

I'm going to be leaving my current job in a few weeks and taking
several weeks off between jobs.  I'll try to work on it then along
with some other debian tasks that I've been putting off.  I can't
imagine it would be very difficult.

> FWIW, detecting a fixed libtool would be rather difficult, since it's the
> libtool used by the depending application which does the recursion and
> therefore needs to be fixed.

I was thinking we'd be able to tell from the .la file what we needed
to do.  If a new libtool still generated a .la file, perhaps it could
put some kind of version indicator or something similar.  Anyway, it's
not clear to me what a fixed libtool would do differently (I don't
know libtool that well) though.  Anyway, I've been looking for an
excuse to dig into this.  Once I could clearly articulate why libtool
is broken and what a non-broken libtool would look like, it will be
much clearer what kind of strategy would work in both cases.

--Jay

-- 
Jay Berkenbilt <[EMAIL PROTECTED]>


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

Re: Problemes with the debian archives or apt?

[Marc Haber]

On Thu, 28 Jul 2005 09:05:05 +0200, Bartosz Fenski aka fEnIo
<[EMAIL PROTECTED]> wrote:
>On Thu, Jul 28, 2005 at 08:57:20AM +0200, Klaus Ethgen wrote:
>> I notive that for about a week there is NO package upgrade in sid. This
>> is realy unusual.
>> 
>> Is there any problem with the package servers or with apt (version
>> 0.6.38)?
>
>Two of Debian's machines were being moved in that time to their new
>location. On of them is responsible for NO package upgrade.
>
>You should read debian-devel-announce list if you want to know about such
>issues:
>
>Info about relocation:
>http://lists.debian.org/debian-devel-announce/2005/07/msg00013.html
>
>Info about its finish:
>http://lists.debian.org/debian-devel-announce/2005/07/msg00018.html

Actually, the Info about relocation did give the impression that the
service were expected to return on monday. The fact of having services
down for two more days was unexpected and not explained in the Info
about its finish.

As usual, Debian has communicated in kind of a suboptimal way.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Problemes with the debian archives or apt?

[Olaf van der Spek]

On 7/28/05, Marc Haber <[EMAIL PROTECTED]> wrote:
> Actually, the Info about relocation did give the impression that the
> service were expected to return on monday. The fact of having services
> down for two more days was unexpected and not explained in the Info
> about its finish.
> 
> As usual, Debian has communicated in kind of a suboptimal way.

I think it'd be nice to have some status (HTML) page that lists all
current issues.

bugs2ldap gateway down - wnpp, bts.turmzimmer.net broken

[Andreas Barth]

Hi,

on request of Ryan Murray I stopped the bugs2ldap-gateway on
bugs.debian.org. I'll move that gateway to some other host as soon as I
have time. At least the following services are broken by that:
- the wnpp bug list
- bts.turmzimmer.net

I am sorry for that. I'll follow up as soon as this service runs on
another host.


Cheers,
Andi


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

Re: bugs2ldap gateway down - wnpp, bts.turmzimmer.net broken

[Bartosz Fenski aka fEnIo]

On Thu, Jul 28, 2005 at 10:38:58PM +0200, Andreas Barth wrote:
> on request of Ryan Murray I stopped the bugs2ldap-gateway on
> bugs.debian.org. I'll move that gateway to some other host as soon as I
> have time. At least the following services are broken by that:
> - the wnpp bug list
> - bts.turmzimmer.net
> 
> I am sorry for that. I'll follow up as soon as this service runs on
> another host.

I'll just use this thread for another question regarding qa.debian.org.

Could someone tell me why:
http://qa.debian.org/developer.php?gpg_key=13FEFC40&comaint=yes

doesn't contain links to "Excuses" since... hmm... yesterday?

regards
fEnIo
-- 
  ,''`.  Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo
 : :' :   32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland
 `. `'   phone:+48602383548 | proud Debian maintainer and user
   `-  http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001


signature.asc
Description: Digital signature

DDPO: excuses broken? (Was: Re: bugs2ldap gateway down - wnpp, bts.turmzimmer.net broken)

[Jeroen van Wolffelaar]

On Thu, Jul 28, 2005 at 10:47:50PM +0200, Bartosz Fenski aka fEnIo wrote:
> I'll just use this thread for another question regarding qa.debian.org.

What for? This only confuses people... This is not related at all.
 
> Could someone tell me why:
> http://qa.debian.org/developer.php?gpg_key=13FEFC40&comaint=yes
> 
> doesn't contain links to "Excuses" since... hmm... yesterday?

Still related to recovery from:

http://lists.debian.org/debian-devel-announce/2005/07/msg00013.html
http://lists.debian.org/debian-devel-announce/2005/07/msg00018.html

Please let -qa know if this still persists a few days after britney is
running again.

--Jeroen

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


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

Re: Problemes with the debian archives or apt?

[Philipp Kern]

On Thu, 2005-07-28 at 22:34 +0200, Olaf van der Spek wrote:
> I think it'd be nice to have some status (HTML) page that lists all
> current issues.

Perhaps on the wiki[1] so that it *can* actually be updated by most who
want to inform about issues?

Kind regards,
Philipp Kern

[1] http://wiki.debian.net



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

Re: SUMMARY: Re: shared library -dev package naming proposal

[Junichi Uekawa]

Hi,

> > - Don't ship .la files in the -dev package; don't depend on any other -dev
> >   packages except those whose headers you need.  This gives optimal results
> >   for shared linking by pruning all unnecessary build-dependencies and
> >   dependencies; but it also screws over anyone trying to do static linking,
> >   who now has to go *recursively* hunt down the package name for each of the
> >   library dependencies, based only on the names of the symbols exported.
> >   (So why would anyone ship the static libs at this point...?)
> 
> If we want to support static linking then let's break it off into it's
> own '-static' package with appropriate dependencies.  Personally I don't
> think it's really worth it and we should just go ahead and drop the
> static libraries too.  It'd certainly make the -dev packages alot
> smaller.  Maybe then we could just put -dbg stuff in the -dev packages.
> :)

That's the portion which was missing in your argument,
resulting in your failure to convey information.

You need to state 'drop static lib linking support from -dev package'  
rather than 'libtool is broken'.

libtool isn't really broken; it's just that static libs and shared libs
behave differently.


> > - Kill the .la files and .a files.  Drop support for static linking.  Not
> >   something that should be done lightly and without prior project-wide
> >   discussion.
> 
> We've had that discussion before.  Last I recall there wasn't really a
> huge fight to keep them.

Current situation is that we have removed the mandate from
policy to require static libs, since some libs really don't work
with static linking.

However, it is still in policy 8.3. that if it exists, it will be 
in -dev package.

Having an extra -static package is rather drastic change,
and I personally still do like the ability of being able to 
do static linking.


regards,
junichi

-- 
Junichi Uekawa, Debian Developer   http://www.netfort.gr.jp/~dancer/
183A 70FC 4732 1B87 57A5  CE82 D837 7D4E E81E 55C1 


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

Re: Packages descriptions review

[Michael Bramer]

On Tue, Jul 26, 2005 at 08:55:23PM +0200, Clément Stenac wrote:
> Hello,
> 
> Following the recent discussion about packages descriptions (see
> http://lists.debian.org/debian-devel/2005/07/msg01074.html and later),
> and based on Lars Wirzenius' idea, I started working on preparing a
> general review of all package descriptions.

If you go to review all description, please check the technical parts
also.

Thinks like this:
 .
 o Adduser can create new users and groups and add existing users to
   existing groups.
 o Deluser can remove users and groups and remove users from a given
   group.
 .
shoud like this:
 .
  o Adduser can create new users and groups and add existing users to
existing groups.
  o Deluser can remove users and groups and remove users from a given
group.
 .

(see 
http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Description
for more infos)

Gruss
Grisu
-- 
Michael Bramer  -- http://www.feuerwehr.kreuzau.de/wiki/
PGP: finger [EMAIL PROTECTED]  -- Linux Sysadmin   -- Use Debian Linux
"Fuer die einen ist es Windows - für die anderen der laengste Virus der Welt..."


signature.asc
Description: Digital signature

Re: SUMMARY: Re: shared library -dev package naming proposal

[Steve Langasek]

On Fri, Jul 29, 2005 at 07:06:34AM +0900, Junichi Uekawa wrote:
> > > - Don't ship .la files in the -dev package; don't depend on any other -dev
> > >   packages except those whose headers you need.  This gives optimal 
> > > results
> > >   for shared linking by pruning all unnecessary build-dependencies and
> > >   dependencies; but it also screws over anyone trying to do static 
> > > linking,
> > >   who now has to go *recursively* hunt down the package name for each of 
> > > the
> > >   library dependencies, based only on the names of the symbols exported.
> > >   (So why would anyone ship the static libs at this point...?)

> > If we want to support static linking then let's break it off into it's
> > own '-static' package with appropriate dependencies.  Personally I don't
> > think it's really worth it and we should just go ahead and drop the
> > static libraries too.  It'd certainly make the -dev packages alot
> > smaller.  Maybe then we could just put -dbg stuff in the -dev packages.
> > :)

> That's the portion which was missing in your argument,
> resulting in your failure to convey information.

> You need to state 'drop static lib linking support from -dev package'  
> rather than 'libtool is broken'.

> libtool isn't really broken; it's just that static libs and shared libs
> behave differently.

No, libtool is moderately broken, as Stephen has pointed out -- it insists
on having dependent .la files present on the system when doing dynamic
linking, even though they shouldn't be needed.

> > > - Kill the .la files and .a files.  Drop support for static linking.  Not
> > >   something that should be done lightly and without prior project-wide
> > >   discussion.

> > We've had that discussion before.  Last I recall there wasn't really a
> > huge fight to keep them.

> Current situation is that we have removed the mandate from
> policy to require static libs, since some libs really don't work
> with static linking.

> However, it is still in policy 8.3. that if it exists, it will be 
> in -dev package.

> Having an extra -static package is rather drastic change,
> and I personally still do like the ability of being able to 
> do static linking.

I think static libs have outlived their usefulness in Debian for the most
part; but using this to justify creating whole *new* packages for static
linking would just be insane.  The dependencies of -dev packages are just
not that big a deal to warrant having to manage all of these new binary
packages.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: SUMMARY: Re: shared library -dev package naming proposal

[Russ Allbery]

Steve Langasek <[EMAIL PROTECTED]> writes:

> I think static libs have outlived their usefulness in Debian for the
> most part; but using this to justify creating whole *new* packages for
> static linking would just be insane.  The dependencies of -dev packages
> are just not that big a deal to warrant having to manage all of these
> new binary packages.

Fully statically linked binaries (including a static libc) are not
particularly useful these days, nor is statically linking *within* Debian
in official packages.  However, statically linking is still rather useful
for Debian *users* from time to time.

For example, I occasionally build binaries that use the Kerberos libraries
and explicitly link just the Kerberos libraries (but not libc) static,
since the binaries are then easily portable to any other Linux
distribution without having to worry about whether the right libraries are
installed.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Bug#320387: ITP: pyicq-t -- ICQ Transport for Jabber, implemented with Python and Twisted

[Nikita V. Youshchenko]

Package: wnpp
Severity: wishlist
Owner: "Nikita V. Youshchenko" <[EMAIL PROTECTED]>

* Package name: pyicq-t
  Version : 0.6-1
  Upstream Author : Daniel Henninger <[EMAIL PROTECTED]>
* URL : http://pyicq-t.blathersource.org/
* License : GPL
  Description : ICQ Transport for Jabber, implemented with Python and 
Twisted

PyICQt is an implementation of Jabber ICQ transport.
.
Current features include:
 - ability to message users on ICQ, and receive messages,
 - ability to see others online, and others to see you,
 - ability to request a VCard of an ICQ user,
 - notifications when typing starts on either end.
.
Homepage is at http://pyicq-t.blathersource.org/.
.
Recommended python-nevow package is needed for internal web interface.


Current package is available from
http://zigzag.lvk.cs.msu.su/~nikita/pyicq-t/

Althouth package requires some more work (such as addition of a debconf
script), it is already useful. It allows to set up an ICQ transport for
jabber server (other than jabberd1) without manual compilation of
anything. Maybe somebody will sponsor the upload?

-- System Information:
Debian Release: 3.1
  APT prefers proposed-updates
  APT policy: (640, 'proposed-updates'), (640, 'stable'), (620, 
'testing-proposed-updates'), (620, 'testing'), (600, 'unstable'), (550, 
'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-1-zigzag
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)


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

..last mirror update was a week ago, what's going on???

[Arnt Karlsen]

Ok,

..last mirror update was a week ago, what's going on???
I get:
ftp-master.debian.org   21-Jul-2005 21:00   29
ftp.de.debian.org   21-Jul-2005 22:24   29
syncproxy.eu.debian.org 21-Jul-2005 21:54   29
etc, on _all_ mirrors I've chked.

..and, yeah, gg:"Debian mirror update" "21-Jul-2005" etc 
finds _lotsa_ noise.

..whether this mirror update lapse is planned or not, a wee 
mention here on d-m and and on d-announce would IMHO 
be warranted.  
In its absence, I ask what I believe is a relevant question 
to d-m, here.

-- 
..med vennlig hilsen = with Kind Regards from Arnt... 
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.


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

Re: ..last mirror update was a week ago, what's going on???

[Steve Kemp]

On Fri, Jul 29, 2005 at 02:31:01AM +0200, Arnt Karlsen wrote:

> ..last mirror update was a week ago, what's going on???

> ..and, yeah, gg:"Debian mirror update" "21-Jul-2005" etc 
> finds _lotsa_ noise.

> ..whether this mirror update lapse is planned or not, a wee 
> mention here on d-m and and on d-announce would IMHO 
> be warranted.  

  It was announced.  Two machines, including ftp-master, were
 shut down so they could be physically moved.

  They took longer than the couple of days announced, but this
 was the source of the delay.

  Original announcement:

http://lists.debian.org/debian-devel-announce/2005/07/msg00013.html

  Followup when service was restored:

http://lists.debian.org/debian-devel-announce/2005/07/msg00018.html

> In its absence, I ask what I believe is a relevant question 
> to d-m, here.

  This message was sent to *far* too many mailing lists.  Especially
 given that the move was announced, and the outage has previously
 been discussed on several of the mailing lists you include your
 query upon.

  Followup set to debian-user, which is least liable to complain ;)

Steve
-- 
# Debian System Administration
www.debian-administration.org/


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

meanin of sid tag

[Mathias Weyland]

Hi

I don't understand what the 'sid' tag is for and who is allowed to set it.

Bug #318692 and #320218 have been assigned to the packages xlib-dev,
bookmarkbridge and 3ddesktop. Both of those bugs deal with changing
build-deps for Xorg. Since we already have a 3ddesktop package with fixed 
dependencies ready for upload (see pending bug #319120) I reassigned the 
two bugs to the packages bookmarkbridge and xlib-dev. (This seems easier 
to me than cloning the bugs, reassigning the clones to my package and
merging them with the pending bug).

During this procedure, I noticed that bug #318692 and #320218 were tagged as
'sid'. I wrongly admitted that the 'sid' tag was for sid what the 'sarge' tag 
is for sarge and the 'etch' tag for etch: A tag which marks that the bug 
applies to sid. I knew that the 'sarge-ignore' and 'etch-ignore' tags should 
only be used by the release managers. To make sure that this is not the case 
for the
'sid' tag, I checked [0] and saw that there were no such restrictions. I
wanted to tag bug #319120 as 'sid', but it failed (see [1]):

# Automatically generated email from bts, devscripts version 2.8.14
tags 319120 - sid

Is it possible that I am not allowed to set the 'sid' tag on bugs of my
packages? If yes, this should be documented in [0] as it is for the
'*-ignore' tags in my opinion.

The second thing I don't quite understand is the description of the 'sid'
tag (also in [0]):

This bug particularly applies to an architecture that is currently
unreleased (that is, in the sid distribution).

I didn't quite understand the meaning of the clarification in the brackets,
to I checked the German version of the page and still didn't understand it
(even though I'm a native German speaker). Then I checked the French version
and things became clearer.

But as far as I can see, the 'sid' tag is used in a different context. Bug
#318692 I mentioned above for example tells us that we have to build-depend
on stuff like libxxf86vm-dev because it isn't in xlibs-dev (formerly in
xlibs-static-dev) anymore. This applies to _every_ architecture.

Or another example: Bug #221224 deals with the wrong size of a window, but
the bug description doesen't mention any particularly affected architecture.

I hope anyone can tell me what I misunderstood or fix the descriptions.

Best regards

Mathias Weyland

[0] http://www.debian.org/Bugs/Developer.en.html
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=319120&msg=33


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

Bug#320397: ITP: nepim -- A tool for measuring available network bandwidth between two hosts

[Ian Wienand]

Package: wnpp
Severity: wishlist
Owner: Ian Wienand <[EMAIL PROTECTED]>

* Package name: nepim
  Version : x.y.z
  Upstream Author : Everton da Silva Marques <[EMAIL PROTECTED]>
* URL : http://www.nongnu.org/nepim/
* License : GPL
  Description : A tool for measuring available network bandwidth between 
two hosts

nepim stands for network pipemeter, a tool for measuring 
available bandwidth between hosts. nepim is also useful to 
generate network traffic for testing purposes.

nepim operates in client/server mode, is able to handle multiple 
parallel traffic streams, reports periodic partial statistics 
along the testing, and supports IPv6.

The package will be available from http://www.gelato.unsw.edu.au/~ianw/debian
as I make it.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.11.9-general
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Re: meanin of sid tag

[Steve Langasek]

On Fri, Jul 29, 2005 at 02:38:19AM +0200, Mathias Weyland wrote:
> I don't understand what the 'sid' tag is for and who is allowed to set it.

> Bug #318692 and #320218 have been assigned to the packages xlib-dev,
> bookmarkbridge and 3ddesktop. Both of those bugs deal with changing
> build-deps for Xorg. Since we already have a 3ddesktop package with fixed 
> dependencies ready for upload (see pending bug #319120) I reassigned the 
> two bugs to the packages bookmarkbridge and xlib-dev. (This seems easier 
> to me than cloning the bugs, reassigning the clones to my package and
> merging them with the pending bug).

> During this procedure, I noticed that bug #318692 and #320218 were tagged as
> 'sid'. I wrongly admitted that the 'sid' tag was for sid what the 'sarge' tag 
> is for sarge and the 'etch' tag for etch: A tag which marks that the bug 
> applies to sid. I knew that the 'sarge-ignore' and 'etch-ignore' tags should 
> only be used by the release managers. To make sure that this is not the case 
> for the
> 'sid' tag, I checked [0] and saw that there were no such restrictions. I
> wanted to tag bug #319120 as 'sid', but it failed (see [1]):

> # Automatically generated email from bts, devscripts version 2.8.14
> tags 319120 - sid

> Is it possible that I am not allowed to set the 'sid' tag on bugs of my
> packages? If yes, this should be documented in [0] as it is for the
> '*-ignore' tags in my opinion.

> The second thing I don't quite understand is the description of the 'sid'
> tag (also in [0]):

> This bug particularly applies to an architecture that is currently
> unreleased (that is, in the sid distribution).

> I didn't quite understand the meaning of the clarification in the brackets,
> to I checked the German version of the page and still didn't understand it
> (even though I'm a native German speaker). Then I checked the French version
> and things became clearer.

I routinely ignore the official description of the "sid" tag here, because
there are other applications of it that are far and away more useful than
tagging a bug as being specific to an unreleased architecture -- not least
of all because tagging an RC bug "sid" doesn't stop the RC bug from holding
updates out of testing, so all such bugs are listed as severity: important
instead.

So, using the "sid" tag to denote bugs that are specific to sid is correct,
although in the case where a bug is specific to a *version* of a package
that's in sid, the tag is deprecated in favor of the BTS version support.

The problem here is that this bug is *not* confined to sid; there is in fact
only one RC bug here in spite of the various bug splits/merges/duplicates,
and if the conclusion is that it's a 3ddesktop bug (instead of a xlibs-dev
bug as I've argued), then there's nothing that would prevent this bug from
also reaching etch, and tagging it 'sid' would mean it is no longer being
tracked as an RC bug affecting etch.

There's certainly nothing wrong with you using the sid tag, it's just a
problematic tag to use right because of the above issues.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Packages descriptions review

[Clément Stenac]

Hello,

> If you go to review all description, please check the technical parts
> also.

Sure, thanks for the reminder. I added it to the wiki page

I think the interface is now ready for the work to begin. However, very
few people replied. Someone suggested an announcement should be sent to
d-d-a. What do you think ?

Anyway, it is possible to start the work with the interested persons
now...
I set up a table on the wiki page
( http://wiki.debian.net/?PackagesDescriptionsReview ).

Please register yourself on this page before starting work on a section.

I think we should begin by the desktop packages (x11, gnome, kde, ...).
I don't think base packages should be given a high priority as people
don't often want to install them. Libs and devel packages are also lower
priority IMHO

Thanks for your help

-- 
Clément Stenac



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

Work-needing packages report for Jul 29, 2005

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 214 (new: 1)
Total number of packages offered up for adoption: 116 (new: 7)
Total number of packages requested help for: 14 (new: 1)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   falconseye (#320075), orphaned 2 days ago
 Description: Data files for Falcon's Eye
 Reverse Depends: falconseye

213 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   compiler (#319801), offered 4 days ago

   eli (#319463), offered 6 days ago
 Description: compiler construction kit
 Reverse Depends: eli-xtools eli

   lincvs (#319461), offered 6 days ago (non-free)
 Description: graphical CVS frontend

   ml (#319801), offered 4 days ago

   re2c (#320283), offered yesterday
 Description: Tool for generating fast C-based recognizers

   smlnj (#319801), offered 4 days ago
 Reverse Depends: libmlnlffi-smlnj libsmlnj-smlnj libexene-smlnj
 ml-nlffigen ml-lex libckit-smlnj ml-yacc ml-burg libcmlutil-smlnj
 libpgraphutil-smlnj smlnj nowhere libmlrisctools-smlnj libcml-smlnj

   standard (#319801), offered 4 days ago

109 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

[NEW] gtkpod (#319711), requested 4 days ago
 Description: manage songs and playlists on an Apple iPod

   aboot (#315592), requested 35 days ago
 Description: Alpha bootloader: Looking for co-maintainers
 Reverse Depends: aboot-cross dfsbuild aboot

   athcool (#278442), requested 275 days ago
 Description: Enable powersaving mode for Athlon/Duron processors

   debtags (#262927), requested 360 days ago
 Description: Evolution of package metadata
 Reverse Depends: debtags-edit

   dselect (#282283), requested 250 days ago
 Description: a user tool to manage Debian packages

   grub (#248397), requested 444 days ago
 Description: GRand Unified Bootloader
 Reverse Depends: replicator grubconf dfsbuild webmin-grub
 grub-splashimages

   lsdvd (#316922), requested 24 days ago
 Description: read the contents of a DVD

   mwavem (#313369), requested 45 days ago (non-free)
 Description: Mwave/ACP modem support software

   parted (#262885), requested 360 days ago
 Description: Searching co-maintainer for the parted package.
 Reverse Depends: libparted1.6-dev elilo-installer libparted1.6-i18n
 aboot-installer parted-udeb qtparted partitioner libparted1.6-dbg
 parted partconf-find-partitions partconf partman mindi lvmcfg-utils
 autopartkit partconf-mkfstab partman-efi

   pbbuttonsd (#270558), requested 324 days ago
 Description: PBButtons daemon to handle special hotkeys of Apple
 computers
 Reverse Depends: pbbuttonsd-dev gtkpbbuttons gtkpbbuttons-gnome
 powerprefs

   qmailadmin (#267756), requested 338 days ago
 Description: web interface for managing qmail with virtual domains
 [contrib]

   sourcenav (#263051), requested 360 days ago
 Description: Source code analysis, editor, browser and build tool:
 Looking for co-maintainer

   squashfs (#267078), requested 342 days ago
 Description: Tool to create and append to squashfs filesystems

   stlport4.6 (#263052), requested 360 days ago
 Description: STLport C++ class library
 Reverse Depends: libstlport4.6-dev openoffice.org-dev

See http://www.debian.org/devel/wnpp/help_requested for more information.


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