Re: support for older distributions

[Jaldhar H. Vyas]

On Tue, 8 May 2001, T.Pospisek's MailLists wrote:

>
> Would there be any problem to just set up your own Debian-style site with
> BTS and apt-able archive, where people can contribute if they want and
> where you can semi-automatical merge in upstream (here Debian) updates
> (mostly critical bugs and security updates)?
> *t
>

I just got my ISP bill for the last month and in one word, ouch!  A good
deal of the bandwidth is used up by the unofficial potato packages I
maintain for uw-imapd and webmin.  I'm not going to stop offering them,
I'll just move them to people.d.o or even sourceforge or somewhere but it
would save users a lot of aggravation if there were one central place for
this kind of thing.

-- 
Jaldhar H. Vyas <[EMAIL PROTECTED]>

Re: [FLAME WARNING] Linux Standards Base and Debian

[Ben Collins]

On Wed, May 09, 2001 at 11:26:58AM +1000, Glenn McGrath wrote:
> Henrique de Moraes Holschuh wrote:
> > 
> > Since the LSB is mainly useful for binary-only distributors, we need not get
> > annoyed over their choice of rpm. After all, it makes more sense, since most
> > distributors already have staff that knows how to build rpms anyway.
> > 
> 
> So the LSB is just about convienience then is it (do whats easiest) ?
> 
> If LSB compromise on quality then they will only ever get a subset of
> the community supporting it, why not try for something better than both
> RPM or DEB, its the only way people will willingly change.
> 
> If nothing can be made that is better than both RPM and DEB then both
> package systems obviously have a purpose.

I agree. The LSB should contrast/compare features of both and come up
with a superset of both (possibly favoring ones implementation over the
other). Most importantly, the metadata format needs to be standardized.
That is the key component. If that is standard, then the binary format
means very little (since a simple converter can be created just like
alien).

After that, then all package managers atleast can aim for something,
instead of shooting in the dark like we do now. The LSB needs to stay
away from trying to standardize a binary format (who cares if it's
tar.gz, ar or cpio). They will only piss people off.

Ben

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Re: [FLAME WARNING] Linux Standards Base and Debian

[Glenn McGrath]

Henrique de Moraes Holschuh wrote:
> 
> Since the LSB is mainly useful for binary-only distributors, we need not get
> annoyed over their choice of rpm. After all, it makes more sense, since most
> distributors already have staff that knows how to build rpms anyway.
> 

So the LSB is just about convienience then is it (do whats easiest) ?

If LSB compromise on quality then they will only ever get a subset of
the community supporting it, why not try for something better than both
RPM or DEB, its the only way people will willingly change.

If nothing can be made that is better than both RPM and DEB then both
package systems obviously have a purpose.



Glenn

Re: Questions to testing/unstable

[Anthony Towns]

On Tue, May 08, 2001 at 02:34:52PM -0300, Henrique de Moraes Holschuh wrote:
> > FWIW, I do all my development under testing.  I virtually ignore unstable
> > unless I need a specific package from it.
> AFAIK, I cannot do that.  If I build against testing, I help the breakage by
> adding yet another package that depends on the outdated libraries that are
> in testing, therefore helping those libraries to be held instead of
> upgraded.  It's a positive feedback loop. Unless I misunderstand testing,
> obviously, and such loop does not exist.

You're probably overestimating the possibility of loops. In almost all cases,
they just don't occur. If it doesn't matter whether you're using the version
from testing or unstable of the package, then you're fine.

For example, say you've got a package foo. foo 1.0-1 depends on libc6
(>= 2.2.1-1) and is in testing, along with libc6 2.2.2-4, say. Meanwhile,
libc6 2.2.3-1 is in unstable, and it's still waiting two days before its
time is up.

There's no loop there (no matter how you build foo 1.0-2) because the
package in testing will happily work with either the old libc6 or the new
libc6.

The worst case in the above is if you build with unstable, in which case
foo 1.0-2 may have to wait a couple of days longer than you might like
while libc6 gets recompiled or some RC bugs get fixed. And that's not a
particularly bad worst case, in general.

In general, you (as a package maintainer) are supposed to be able to
ignore testing, and do what you like (although you might receive bug reports
now and then telling you to start building against new libraries, like
libncurses5 instead of 4, say).

> If it happens to be very important package (none of mine are, AFAIK), I'll
> compile it in a testing chroot, upload it with urgency high or critical, and
> downgrade all RC bugs.

Gag. Don't do this. testing can't do it's job if you lie outright to it. If
there's a problem mail -devel.

You shouldn't have outstanding RC bugs anyway. Seriously.

> Maybe I misunderstand the testing mechanics, and libs will be always
> upgraded when their dependencies allow it, thus flushing a lot of packages
> from testing.

They will: the problem only occurs when things break both forwards and
backwards compatibility (ie, new packages don't work on the old libraries
_and_ old packages don't work with the new libraries). This is rarely
the case.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
  -- John S. Novak, III (The Humblest Man on the Net)


pgpAU8EVFwQko.pgp
Description: PGP signature

Re: Postgres and non-us

[Henrique de Moraes Holschuh]

On Tue, 08 May 2001, Jim Penny wrote:

> PostgreSQL now has a dependency on openssl/ssl.h in a fundamental
> header file, postgresql/libpq-fe.h.
> 
> Does this mean that every piece of software which requires this
> header file to compile will also have to be migrated to nonus?

Is it used just to generate and verify signatures, or to actualy encript
data other than hashes ?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Postgres and non-us

[Oliver Elphick]

Jim Penny wrote:
  >PostgreSQL now has a dependency on openssl/ssl.h in a fundamental
  >header file, postgresql/libpq-fe.h.
  >
  >Does this mean that every piece of software which requires this
  >header file to compile will also have to be migrated to nonus?

Yes.  (Sorry!)

-- 
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight  http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47  6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
 
 "Follow peace with all men, and holiness, without which
  no man shall see the Lord."   Hebrews 12:14 

Re: support for older distributions

[Craig Sanders]

On Mon, May 07, 2001 at 02:45:53PM +0200, Russell Coker wrote:
> Currently there are two usable repositories of Potato packages.
> There's a repository of kernel-related packages to run 2.4.x kernels
> on Potato, and there's a repository of LDAP related packages and other
> things that Wichert is maintaining.
>
> Both of these are good work, but even combined they don't provide what
> I consider to be adequate support for Potato.
>
> I would like a version of Potato that is not entirely frozen.  It
> should have updates not only for security reasons but also for
> addition of new programs, and for adding new programs which add
> significant functionality and don't break things (such as Wichert's
> LDAP packages).

why?

aside from the installer floppies (which aren't relevant for upgrades),
the main significant difference between potato and woody (or between
any versions of debian for that matter) is the version numbers of the
packages included.

the distinction between versions of debian is entirely arbitrary, a
matter of consensus reality rather than actual reality.

your suggestion would add a huge load of administrative and maintainence
overhead in order to support a convenient fiction - providing little or
no real benefit. worse than that, it subverts the only real point in
having versioned releases - the ability to know what is included in any
released version.

debian provides mechanisms for easy upgrade between release versions,
and we always have provided that - why complicate matters with branched
sub-releases of old versions? 


you also risk creating greater problems back-porting packages from
testing or unstable - they would be divergent packages which don't get
anywhere near the same amount of testing and usage as packages in the
mainline development cycle.

for example, ask yourself: why is libc6-2.2.2-potato1 (or whatever the
potato version would be) any "better" or "safer" than just installing
libc6-2.2.2 from woody or sid? i can't see how it could be, and all
you've achieved is having two divergent versions of 2.2.2 to support.


debian is a "live" distribution, easily upgraded in place at any time
over the internet - why limit yourself to looking at debian in a way
which is more suited to commercial CD-ROM only closed source systems?

IMO, forcing debian into that model is missing a large part of the point
of debian.

potato's been released. woody's getting closer to freeze. lets move on.

craig

--
craig sanders <[EMAIL PROTECTED]>

  GnuPG Key: 1024D/CD5626F0 
Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57  52C3 EC32 6810 CD56 26F0

Postgres and non-us

[Jim Penny]

PostgreSQL now has a dependency on openssl/ssl.h in a fundamental
header file, postgresql/libpq-fe.h.

Does this mean that every piece of software which requires this
header file to compile will also have to be migrated to nonus?

Jim Penny

Re: Questions to testing/unstable

[Brian May]

> "Herbert" == Herbert Xu <[EMAIL PROTECTED]> writes:

Herbert> That means the library maintainer has stuffed up.  If
Herbert> he's done it properly, his libraries can go into testing
Herbert> wihtout having to wait for all its users to recompile.
Herbert> This used to be insignificant, but testing has made it
Herbert> much more important which IMHO is a very good thing.

This ideal is not practically possible with a complicated package like
heimdal-libs:

[520] [snoopy:unstable:bam] ~ >dpkg -L heimdal-lib
/.
/usr
/usr/lib
/usr/lib/libroken.so.9.2.1
/usr/lib/libcom_err.so.1.0.1
/usr/lib/libsl.so.0.1.1
/usr/lib/libss.so.0.1.3
/usr/lib/libasn1.so.2.2.0
/usr/lib/libkrb5.so.15.0.0
/usr/lib/libhdb.so.7.0.0
/usr/lib/libkadm5srv.so.7.0.3
/usr/lib/libkadm5clnt.so.4.2.1
/usr/lib/libgssapi.so.1.2.0
/usr/lib/libotp.so.0.1.2
/usr/lib/libroken.so.9
/usr/lib/libcom_err.so.1
/usr/lib/libsl.so.0
/usr/lib/libss.so.0
/usr/lib/libasn1.so.2
/usr/lib/libkrb5.so.15
/usr/lib/libhdb.so.7
/usr/lib/libkadm5srv.so.7
/usr/lib/libkadm5clnt.so.4
/usr/lib/libgssapi.so.1
/usr/lib/libotp.so.0
[...]

For instance, the next version of Heimdal, 0.3f could increase the
major version of libkrb5 from 15 to 16. This means all programs that
depend on the old heimdal-lib are now broken, because it is not
possible to install old and new at the same time (the other files
conflict).

So, just in case, I have the shlibs depends set so that all packages
must be recompiled for every upstream realize, just in case.

Of course, the proper solution would be to split heimdal-libs up, so
you have one library per package, but there are 11 libraries here!!!
I personally consider that to be too complicated.

Yes, another solution might be to combine some of the libraries
together (eg. make libasn1 a convenience library; combine e2fsprogs
and Heimdal's version of libcom_err, etc).  However, that is beyond
the scope of what I am prepared to do (in my limited time) as the
Debian maintainer. If anyone has plenty of spare time, please give
upstream any patches you may create to do this .

(lets assume for now that issues like libtool < 1.4 not recording
interlibrary dependencies properly have been fixed, as I will assume
that a) libtool 1.4 which has just been released solves this, and b)
that they have fixed 2 serious bugs which I found in the CVS version;
I still need to test it though).
-- 
Brian May <[EMAIL PROTECTED]>

CFP: Linux@work Amsterdam 2001, June 15

[J.A. Bezemer]

[Sorry for the cross-posting, but I want to reach as many .nl (would-be-)
developers as possible, and there doesn't seem to be one single list they all
subscribe to. FOLLOW-UPs to debian-events-eu@lists.debian.org ONLY please.]


 Call for Participation:

Debian booth (aka "table")
   at
[EMAIL PROTECTED] Conference/Expo

   Amsterdam (Schiphol)
   Friday June 15, 2001


Well, to keep it short, I contacted the organizers and they offer us a free
booth==table, so I'm looking for people and machines to fill that space.

Coordination webpage with all info:
  http://panic.et.tudelft.nl/~costar/linuxatworkamsterdam2001/

Note: REGISTRATION is necessary for both staff and visitors (different
forms!), but access to everything is free for all. Details: see webpage.

Please contact me if you can come and/or bring equipment.

(BTW, there still seem to be a few vacant slots in the "technical track" of
the conference program. So if you have a nice [business-related] subject
to talk about, contact [EMAIL PROTECTED])


Regards,
  Anne Bezemer

Re: build depends on kernel-headers

[Herbert Xu]

On Tue, May 08, 2001 at 09:20:27AM -0400, Sam Hartman wrote:
> 
> We are making active decisions related to this problem.  Ben is
> actively removing headers not used by libc6-dev; there may be other

I didn't know that.  That's something that I don't agree with.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [FLAME WARNING] Linux Standards Base and Debian

[Wichert Akkerman]

Previously Stephane Bortzmeyer wrote:
> Is it true that Debian approved this "standard"?

Yes. Basically we needed a standard that people could accept and that
could be implemented quickly. Obviously rpm was the only solution,
and a subset of rpm is used to make sure that that will work on
non-rpm based systems as well.

There are two ways to handle those packages on Debian systems
now: one is using alien, and the other is using Albert's dpkg-rpm
patch which makes it possible for dpkg to use those packages
directly.

On a longer timescale we'll likely move to a new packages format,
but that's not for LSB 1.

Wichert.

-- 
   
 / Generally uninteresting signature - ignore at your convenience  \
| [EMAIL PROTECTED]  http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

ITP: trilobite -- Nautilus component framework for services

[Takuo KITAME]

Package: wnpp
Severity: wishlist

This is a framework library for service components in Nautilus.  It is
required by all Eazel Services, including the package installer, and
can be used to develop new services.

It will replaces nautilus-nonus

License: GPL

--
Takuo Kitame.

Re: cvs not updating correctly

[Nathan E Norman]

On Tue, May 08, 2001 at 05:29:30PM -0400, Jon Eisenstein wrote:
> > I use cvs in Debian for lots of things but I'm still a newcomer in
> > this field, I think I am not being able to get new created directories
> > and files from the cvs repository with an cvs update, are there 
> > arguments or options to do this?
> 
> Try using 'cvs update -d'. That should update newly created directories
> and files.

... and "cvs update -dP" will pull in new dirs but prune empty dirs
(new or not).

-- 
Nathan Norman - Staff Engineer | A good plan today is better
Micromuse Ltd. | than a perfect plan tomorrow.
mailto:[EMAIL PROTECTED]   |   -- Patton


pgpZdrIggLzGd.pgp
Description: PGP signature

Re: [FLAME WARNING] Linux Standards Base and Debian

[Henrique de Moraes Holschuh]

On Tue, 08 May 2001, Arthur Korn wrote:
> Stephane Bortzmeyer schrieb:
> > below. RPM is the defacto standard on Linux [sic] and supported either 
> > directly, or indirectly by the widest number of distributions.
> 
> The statement is perfectly true, Debian supports RPM with aliens
> help.

I'd like to remind all of the fact that the LSB also specifies the entire
set of libs one can use, so alien can (and I suppose, will) be taught how to
correctly map the .lsb to .deb dependencies if given a proper LSB-compatible
package as input, for example.

Since the LSB is mainly useful for binary-only distributors, we need not get
annoyed over their choice of rpm. After all, it makes more sense, since most
distributors already have staff that knows how to build rpms anyway.

> > So, LSB is not a specification for Linux-based operating systems but for 
> > the 
> > subset of them which uses the RPM format.

Not true at all... there are lots of useful stuff (and lots of bad stuff, I
suppose) in that standard.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


pgpAZAuIYABZt.pgp
Description: PGP signature

Re: Questions to testing/unstable

[Herbert Xu]

Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:

> On Tue, 08 May 2001, Herbert Xu wrote:
>> 
>> FWIW, I do all my development under testing.  I virtually ignore unstable
>> unless I need a specific package from it.

> AFAIK, I cannot do that.  If I build against testing, I help the breakage by
> adding yet another package that depends on the outdated libraries that are
> in testing, therefore helping those libraries to be held instead of
> upgraded.  It's a positive feedback loop. Unless I misunderstand testing,
> obviously, and such loop does not exist.

That means the library maintainer has stuffed up.  If he's done it
properly, his libraries can go into testing wihtout having to wait for
all its users to recompile.  This used to be insignificant, but testing
has made it much more important which IMHO is a very good thing.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: cvs not updating correctly

[Jon Eisenstein]

> I use cvs in Debian for lots of things but I'm still a newcomer in
> this field, I think I am not being able to get new created directories
> and files from the cvs repository with an cvs update, are there 
> arguments or options to do this?

Try using 'cvs update -d'. That should update newly created directories
and files.

cvs not updating correctly

[Gustavo Noronha Silva]

Hello my friends,

I use cvs in Debian for lots of things but I'm still a newcomer in
this field, I think I am not being able to get new created directories
and files from the cvs repository with an cvs update, are there 
arguments or options to do this?

For example, I was to translate the last DWN but there was no
webwml/english/News/weekly/10 directory! I had 1 to 6 only, 
wich was the ones I had when I first co'ed...

thanks

-- 
   Gustavo Noronha Silva - kov 
*--*
|  .''`.  | Debian GNU/Linux - A matter of quality  |
| : :'  : |Debian-BR enlarging frontiers |
| `. `'`  |  Be Happy! Be FREE!|
|   `-| "Think globaly, act localy!"   |
*--*

Re: Questions to testing/unstable

[Henrique de Moraes Holschuh]

On Tue, 08 May 2001, Sam Hartman wrote:
> Henrique> AFAIK, I cannot do that.  If I build against testing, I
> Henrique> help the breakage by adding yet another package that
> Henrique> depends on the outdated libraries that are in testing,
> Or your could do shared library versions correctly so both versions
> can exist.  I realize it is hard, especially if your upstream is not

That's a problem for the library maintainers, currently none of my packages
are libraries. Correct versioning, as specified by the library package, is
already carried over to any packages built against it.

Anyway, avoiding to clobber an old lib in testing is not always possible, or
desirable. Sometimes, old stuff has to be removed due to security holes,
regardless of the fact that the ABI has changed. A serious proposal that
library maintainers start doing backports from unstable security fixes to
testing would die an horrible flaming death quite quickly IMHO.

I won't touch the topic about QA and yet another (unsupported -- it won't be
updated, because the ABI changed) layer of libraries.

If I do not want to get caught in an ABI change, and help a breakage in
testing, I have to build against unstable. It's that simple. If the ABIs of
the libs it depends on didn't change, the package will make it to testing.
If the ABIs changed, it won't (I am supposing the library package is doing
things right on the .so versioning, shlib definitions and package naming
area).

AFAIK, testing is supposed to be a half-baked frozen distro. Its existance
should be as transparent as possible for the developers, and help the
deployment of the next stable distro by shortening the freeze time.  It's
NOT an always-safe distro, nor is it meant to be. It is not a very secure
distro either because there are extra delays for a security fix to get to
testing.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


pgphmi0PYHcjG.pgp
Description: PGP signature

Re: [FLAME WARNING] Linux Standards Base and Debian

[Arthur Korn]

Stephane Bortzmeyer schrieb:
> below. RPM is the defacto standard on Linux [sic] and supported either 
> directly, or indirectly by the widest number of distributions.

The statement is perfectly true, Debian supports RPM with aliens
help.

> The intent is to in the future replace this format with a new
> format currently being developed.

I'd like it much more if there was a simple "portable package
format" (like GNU .tar.gz (ie with autoconf or workalike);) and
distributions can build on that if they feel they need to.

In short: most is there.

> So, LSB is not a specification for Linux-based operating systems but for the 
> subset of them which uses the RPM format.

What part of the quote leads you to this conclusion?

ciao, 2ri
-- 
No, I'm not going to explain it.  If you can't figure it out, you didn't
want to know anyway...  :-)
 -- Larry Wall in <[EMAIL PROTECTED]>

Re: Questions to testing/unstable

[Sam Hartman]

> "Henrique" == Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:

Henrique> AFAIK, I cannot do that.  If I build against testing, I
Henrique> help the breakage by adding yet another package that
Henrique> depends on the outdated libraries that are in testing,
Henrique> therefore helping those libraries to be held instead of
Henrique> upgraded.  It's a positive feedback loop. Unless I
Henrique> misunderstand testing, obviously, and such loop does not
Henrique> exist.

Or your could do shared library versions correctly so both versions
can exist.  I realize it is hard, especially if your upstream is not
committed to multiple major versions/versioned symbols/whatever is
necessary, but it is the correct solution and you can certainly strive
for it.

[FLAME WARNING] Linux Standards Base and Debian

[Stephane Bortzmeyer]

The last version of the LSB  says:

Currently the LSB does not officially specify a package format; however, the 
recommended package format is RPM (Version 3) with some restrictions listed 
below. RPM is the defacto standard on Linux [sic] and supported either 
directly, or indirectly by the widest number of distributions. The intent is 
to in the future replace this format with a new format currently being 
developed.

(End of quote)

So, LSB is not a specification for Linux-based operating systems but for the 
subset of them which uses the RPM format. Moreover, the FAQ 
 says:

This arrangement was agreed up on by the major distributions including deb 
based
ones (eg Debian, Storm, Corel) as well as RPM based ones (Red Hat, SuSE, 
TurboLinux, Caldera, Mandrake).

(End of quote)

Is it true that Debian approved this "standard"?

Bug#96777: ITA: libapache-mod-ssl

[Robert van der Meulen]

Package: wnpp
Severity: normal

I'm adopting libapache-mod-ssl. I have spoken with the current maintainer (
Miquel van Smoorenburg, <[EMAIL PROTECTED]>), and he knows about/agrees on
this.

Thanks,
Robert

-- 
  Linux Generation
   encrypted mail preferred. finger [EMAIL PROTECTED] for my GnuPG/PGP key.
Don't panic.

lame (vorbis) packaging.

[Viral]

Hi,
Is there anyone working on trying to package lame ?
It can do vorbis now, so I believe that it can be packaged without the mp3
stuff.

How the source will be dealt with, is something that I would like to
figure out.

viral

-- 
There's someone in my head but its not me.


pgp8grGcXD9wV.pgp
Description: PGP signature

Re: Questions to testing/unstable

[Henrique de Moraes Holschuh]

On Mon, 07 May 2001, Michael Meskes wrote:
> On Mon, May 07, 2001 at 01:51:12PM -0300, Henrique de Moraes Holschuh wrote:
> > Most of us don't bother too much with testing, unless we're trying to get
> > something into testing for one particular reason or another (such as, the
> > package in testing is too damn buggy, or has a security hole).
> 
> Whow! Now that is a great explanation. We started testing for a reason. If
> all of us think that way we can as well stop using testing at all, as it

Please see my reply to Hebert Xu, later on the thread.

> will only contain packages from the old stable and some that are just
> developing to slowly to remain in quarantine.

That's not the only problem that holds packages out of testing. Check the
output of the testing scripts, and see how many are held due to dependency
problems as opposed as to being 'too new'.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


pgpb4GfEzsWkr.pgp
Description: PGP signature

Re: Questions to testing/unstable

[Henrique de Moraes Holschuh]

On Tue, 08 May 2001, Herbert Xu wrote:
> Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
> > Most of us don't bother too much with testing, unless we're trying to get
> > something into testing for one particular reason or another (such as, the
> > package in testing is too damn buggy, or has a security hole).
> 
> FWIW, I do all my development under testing.  I virtually ignore unstable
> unless I need a specific package from it.

AFAIK, I cannot do that.  If I build against testing, I help the breakage by
adding yet another package that depends on the outdated libraries that are
in testing, therefore helping those libraries to be held instead of
upgraded.  It's a positive feedback loop. Unless I misunderstand testing,
obviously, and such loop does not exist.

That's why I don't bother with testing, unless I'm dealing with a urgency
high or critical upload; In that case I'll happily request the version of
the package in testing to be *removed*.

If it happens to be very important package (none of mine are, AFAIK), I'll
compile it in a testing chroot, upload it with urgency high or critical, and
downgrade all RC bugs. As soon as it gets moved into testing, I'd upload a
urgency critical package built in a proper sid chroot, and restore the bugs
to their proper severity.

Xu, I don't claim to understand your packages better than you. I have no
idea where on the dependency chain they are; maybe they don't affect other
packages in testing at all. But that's not the case for my packages.

Maybe I misunderstand the testing mechanics, and libs will be always
upgraded when their dependencies allow it, thus flushing a lot of packages
from testing.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


pgpIrSD323rz0.pgp
Description: PGP signature

Re: support for older distributions

[T.Pospisek's MailLists]

On Tue, 8 May 2001, Russell Coker wrote:

> But if someone is willing to back-port a package, and to maintain it
> (fixing any bugs that may be reported against it), then why not make
> room on the archives for it?

Would there be any problem to just set up your own Debian-style site with
BTS and apt-able archive, where people can contribute if they want and
where you can semi-automatical merge in upstream (here Debian) updates
(mostly critical bugs and security updates)?
*t


 Tomas Pospisek
 SourcePole   -  Linux & Open Source Solutions
 http://sourcepole.ch
 Elestastrasse 18, 7310 Bad Ragaz, Switzerland
 Tel: +41 (81) 330 77 11

Re: PostgreSQL in testing

[Branden Robinson]

On Tue, May 08, 2001 at 11:14:40AM +0200, Petr Cech wrote:
> aj: feel free to remove php3 from testing if it will make things easier. I'd
> like to get php4 there ass php3 is not maintained upstream anymore.

I think it would be good to keep php3 around for people who feel that
php4's license is broken.

-- 
G. Branden Robinson |You live and learn.
Debian GNU/Linux|Or you don't live long.
[EMAIL PROTECTED]  |-- Robert Heinlein
http://www.debian.org/~branden/ |


pgpgQPop3AbXJ.pgp
Description: PGP signature

Re: Questions to testing/unstable

[Andreas Metzler]

Paul Martin <[EMAIL PROTECTED]> wrote:
>> Possible scenario:
>> 1.0-3 has some major changes and accidentially fixes an RC-bug in
>> 1.0-2, before _anybody_ noticed it in 1.0-2.
>> 1.0-2 goes into testing and BLAM.

> Surely, the maintainer can then close (or downgrade) the RC bug, saying
> it's fixed in the newer version?

> (Or are you meaning that the maintainer will have to play whack-a-mole
> with multiple identical RC bug entries to get the package into testing?)

Obviously it is impossible to understand my english, the points I
wanted to make were:
-Once 1.0-3 is in sid, 1.0-2 is removed from sid and nobody uses it
 anymore.
-You cannot test 1.0-2 by using 1.0-3, there can be _unknown_ bugs in
 1.0-2 which are not in 1.0-3 and vice versa.
cu andreas
-- 
Uptime: 10 seconds  load average: 0.00, 0.00, 0.00
vim:ls=2:stl=***\ Sing\ a\ song.\ ***

Re: support for older distributions

[Russell Coker]

On Tuesday 08 May 2001 01:28, Chad C. Walstrom wrote:
> On Mon, May 07, 2001 at 02:45:53PM +0200, Russell Coker wrote:
> > I would like a version of potato that is not entirely frozen.
> > ...
> > I am willing to be involved in back-porting packages (there's many
> > things that I back-port for my own use and should share).
> > ...
> > Also we have to consider the long-term view of this.  I would
> > like to see back-ports to woody being done in a year's time...
>
> It's not an easy request to address, really.  Opinion is largely
> subjective as to what one would find valuable for potato, and you run
> into the problem of making "slushy" potato look more like woody.  It's
> a catch 22 if you take it too far.

I agree that it is a matter of opinion as to what is required.  But if 
someone is willing to back-port a package, and to maintain it (fixing any 
bugs that may be reported against it), then why not make room on the archives 
for it?

> I think the long view on this subject focuses less on back-ports and
> more on shorter release cycles.  If we can get release cycles for
> stable down to a year or less, back-ports would simply be less
> important.

Even if we get release cycles down to less than a year there will still be 
commercial considerations of the users.  I can't install some serious Linux 
servers for a company and say "I'll be back before the end of the year to 
upgrade everything"!

> So, contribute your efforts to improving and stabilizing woody, so we
> can get it out the door! ;-)

Actually if it was easier to share work with other people who are forced to 
back-port packages to Potato then I would have more time for working on 
woody.  My aim here is to spend less time working on Potato not more!  The 
more I can work with other people and share the load then the less work on 
Potato I have to do.

On Tuesday 08 May 2001 09:28, Brian May wrote:
> Another suggestion (one which you may not like, I haven't considered
> it in to much detail):
>
> Create a new Packages file for a new distribution (not sure what you
> would call it) that lists stable Packages. Then once Y is convinced
> that package X from {testing,unstable} runs OK, Y updates the new
> Package file to include the new version of X. Any broken package
> should not appear in this new distribution.
>
> So it would be sort of like testing, only based around stable, not
> unstable.
>
> Pitfalls:
>
> Of course, it goes without saying, that you can't copy the new package
> into the new distribution until all dependencies have already been
> satisfied. Including libc6 + libc6 related packages.

As for woody we are strongly encouraged to compile with the latest libc6 
which means that such packages would never get into potato.  That's just not 
workable.

-- 
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/   Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page

Re: Bug#96638: ITP: libkudzu

[David Whedon]

> > kudzu was dead, but I guess not.  What I would like is to have a real 
> > hardware
> > detection system that continues after the main installation. That way when 
> > new
> > hardware is added to the system we could help the user make the necessary
> > software changes.
> 
> Is there already policy on how this hardware detection should be
> implemented?

Not as far as I know.  I tend to think that Progeny's discover would be a good
start, but only because I have looked at it and it is already Debian-centric.
But kudzu has a longer history, who knows.

In any case I expect this is for after woody.

David

ITP: gtkipmsg -- IP Messenger in GTK

[Junichi Uekawa]

Package: wnpp
Severity: wishlist


gtkipmsg is an IP Messenger (a message passing utility for local network
using UDP protocol, which you can use to communicate with peers running
Microsoft Windows or MacOS) implementation in GTK. 

The copyright :

all portions that have been taken from X IP Messenger:

XIP Messenger V0.8086
/*
 * Copyright (c) 1995, 1996, 1997
 *  Toshihiro Kanda.  All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in the
 *documentation and/or other materials provided with the distribution.
 * 3. All advertising materials mentioning features or use of this software
 *must display the following acknowledgement:
 *  This product includes software developed by Toshihiro Kanda.
 * 4. Neither the name of the author nor the names of any co-contributors
 *may be used to endorse or promote products derived from this software
 *without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY TOSHIHIRO KANDA AND CONTRIBUTORS ``AS IS'' AND
 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 * ARE DISCLAIMED.  IN NO EVENT SHALL TOSHIHIRO KANDA OR CONTRIBUTORS BE LIABLE
 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 *
 */

Original IP Messenger for Windows:
  Copyright (C) 1996 by H.Shirouzu <[EMAIL PROTECTED]>

BSD Daemon Copyright 1988 by Marshall Kirk McKusick. All Rights Reserved.

AD2C - convert resource files to C decls
  by George Ferguson, [EMAIL PROTECTED]



All portions appended are by GPL version 2.


-- 
[EMAIL PROTECTED] : Junichi Uekawa   http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423  7447 3059 BF92 CD37 56F4

ITP: sted2 -- midi notation program

[Junichi Uekawa]

Package: wnpp
Severity: wishlist

STed2 is a midi notation program with an interface that resembles that 
of trackers. It is text-based, and can use timidity to play 
midi data, allowing users to have a full-fledged composition
environment without expensive hardware.

It was originally developed for X680x0 systems, and ported to unix
systems.


copyright:

Right for modification and improvement is granted. However it is
requested that when a modified version is publicly released, 
the accompanying DOC and HIS files are distributed along with it.




-- 
[EMAIL PROTECTED] : Junichi Uekawa   http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423  7447 3059 BF92 CD37 56F4

Re: Packages not making it into testing (fwd)

[Jonas Smedegaard]

The mail below was sent earlier, but got lost in a local mail loop...

 - Jonas

-- 
Jonas Smedegaard   <[EMAIL PROTECTED]>   http://www.jones.dk/~jonas/
IT-guide dr. Jones<[EMAIL PROTECTED]>   http://dr.jones.dk/+45 40843136
Debian GNU/Linux<[EMAIL PROTECTED]>   http://www.debian.org/
GnuPG(1024D/C02440B8): 9A98 C6EB C098 9ED0 3085  ECA9 9FB0 DB32 C024 40B8

GNU GPL: "The source will be with you... always."

-- Forwarded message --
Date: Sat, 28 Apr 2001 12:25:04 +0200 (CEST)
From: Jonas Smedegaard <[EMAIL PROTECTED]>
To: Daniel Kobras <[EMAIL PROTECTED]>
Cc: debian-devel@lists.debian.org
Subject: Re: Packages not making it into testing

On Fri, 27 Apr 2001, Daniel Kobras wrote:

> On Fri, Apr 27, 2001 at 09:41:46PM +0300, Tommi Virtanen wrote:
> > Anthony Towns  writes:
> >
> > > + mpg123 uploaded 125 days ago, out of date by 115 days!
> > >   mpg123-alsa is uninstallable (needs alsa-base 0.4, which is no
> > >   longer available?)
> >
> > mpg123 won't work with the newer ALSA, and there seems to be
> > no real mpg123 activity. I'll drop ALSA support when I get time
> > to update the package (not very soon).
>
> Current mix of alsa-headers and -libs doesn't allow you to build anything
> on unstable anyway. If you want some help on that package drop me a note.
> I've hacked on mpg123 before, and we're in the process of getting ALSA
> 0.9 support into Glame at the moment.

Quite interesting!

If you need testers speak up, I have ALSA running on my powerpc TiBook now
that 0.9 with powerpc drivers has been released.

 - Jonas

-- 
Jonas Smedegaard   <[EMAIL PROTECTED]>   http://www.jones.dk/~jonas/
IT-guide dr. Jones<[EMAIL PROTECTED]>   http://dr.jones.dk/+45 40843136
Debian GNU/Linux<[EMAIL PROTECTED]>   http://www.debian.org/
GnuPG(1024D/C02440B8): 9A98 C6EB C098 9ED0 3085  ECA9 9FB0 DB32 C024 40B8

GNU GPL: "The source will be with you... always."

Re: debian-new-packages-announce@l.d.o ?

[Wichert Akkerman]

Previously Fredrik Steen wrote:
> I think that is a great idea. I support it.

So you're volunteering to actually implement that?

Wichert.

-- 
   
 / Generally uninteresting signature - ignore at your convenience  \
| [EMAIL PROTECTED]  http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: ITP: tdb (Trivial DataBase)

[Marek Habersack]

** On May 08, Wichert Akkerman scribbled:
> Previously Marek Habersack wrote:
> > Put that way it makes perfect sense. But why use libtool then?
> 
> last time I checked they didn't use libtool, although that might
> have changed since then.
1.0.3 most definitely uses it :)

> 
> > It might seem that they are planning/thinking of making it a bit larger
> > project.
> 
> That's not what I hear from its authors :)
OK :) - that was just an assumption based on the presence of libtool :)
 
> > Would it be feasible if only a tdb-dev package existed with an .a
> > archive and a set of manpages/includes - at least it would be
> > integrated with debian that way?
> 
> That's not a bad plan.
The packages are ready - tdb-dev, tdb-tools and tdb1 total 45k, the sources
including diffs total 140k, so the package isn't dramatically large. Maybe
it would make sense to upload it all? Or should I just make that single
package as written above?

marek

-- 
Visit: http://caudium.net - the Caudium WebServer

/* A completely unrelated fortune */
 I think that I shall never see A billboard lovely as a tree. Indeed,
 unless the billboards fall I'll never see a tree at all.   -- Ogden Nash 
 
 
 
 

pgp5C9WNomtLH.pgp
Description: PGP signature

Re: debian-new-packages-announce@l.d.o ?

[Thomas Lange]

On Mon, May 07, 2001 at 08:40:19PM +0200, Piotr Krukowiecki wrote:
| Hi
| 
| What do you think about making a new list which would be used to
| announce new packages in Debian ?
| It could be done automatically, when package is uploaded for the first
| time. It would contain description of package etc.
| DWN includes some info about new packages, but it's not very
| informative.
| 

Great. It should contain the package name, the section where it will
put into the archive and the short description from the control file.

-- 
 Thomas

Re: build depends on kernel-headers

[Sam Hartman]

> "Manoj" == Manoj Srivastava <[EMAIL PROTECTED]> writes:

>>> "Sam" == Sam Hartman <[EMAIL PROTECTED]> writes:
> "Manoj" == Manoj Srivastava <[EMAIL PROTECTED]> writes:
> "Aaron" == Aaron Lehmann <[EMAIL PROTECTED]> writes:
Aaron> So you're saying it's better to hardcode syscall numbers
Aaron> and stuff than using the kernel headers? Sre...

Manoj> We already have a process for packages that actually do
Manoj> need kernel headers, and are thus dependent on particular
Manoj> kernel versions.

Sam> We do?  please explain what it is.

Manoj>  We call these packages kernel modules; and we have a
Manoj> process by which you inform make where the relevant kernel
Manoj> headers are to be found. make-kpkg automates that somewhat
Manoj> (and make-kpkg can be used for packages that are not
Manoj> kernel-modules, you know).

How do I use make-kpkg to build modules with a kernel headers package?
I don't see how to do this in the manual, and when I try obvious
things I get told that the kernel headers directory is not a kernel
source directory.  If you had said that we have a process for building
modules from kernel sources I'd agree with you, but currently I don't
think we have such a process for headers.

Re: debian-new-packages-announce@l.d.o ?

[Fredrik Steen]

On Mon, May 07, 2001 at 08:40:19PM +0200, Piotr Krukowiecki wrote:
| Hi
| 
| What do you think about making a new list which would be used to
| announce new packages in Debian ?
| It could be done automatically, when package is uploaded for the first
| time. It would contain description of package etc.
| DWN includes some info about new packages, but it's not very
| informative.
| 
|  
| 
| -- 
| Piotrek  (@ ~)
| irc: #Debian.pl

I think that is a great idea. I support it.

-- 
.Fredrik Steen
- http://www.stone.nu -

Re: build depends on kernel-headers

[Sam Hartman]

> "Herbert" == Herbert Xu <[EMAIL PROTECTED]> writes:

Herbert> Sam Hartman <[EMAIL PROTECTED]> wrote:
>> This brings up an interesting point.  While we should work with
>> upstream maintainers to fix these problems, we should also try
>> to avoid making these programs harder to build on Debian than
>> other distributions.  If other distributions are still making
>> headers available in such a way that existing software builds,
>> and we do not, then we make lives harder for both our users and
>> maintainers.  Yes, it may be more correct, but we need to be
>> carefule not to correct our users into frustration.  Managing
>> careful transition plans is also an important part of
>> correctness.

Herbert> This is not something that we're doing.  This is a
Herbert> decision taken by the upstream kernel maintainer(s). 

First, it wouldn't be the first time that we had to jump through extra
hoops to make upgrading easy simply because an upstream didn't do
their job right.  However, I don't think there's anything we can
really do in that part of the problem space.


We are making active decisions related to this problem.  Ben is
actively removing headers not used by libc6-dev; there may be other
things happening as well related to these issues.  If this has the net
effect that I as an end user find I can't build significant sets of
software on Debian without significant effort, but I can build the
same software on a distribution that isn't as agressive at being
correct with its libc, then we have not served our user community.  We
do need to encourage people to transition, but we do not want to do so
in a manner that causes people to get the impression that Debian is
less functional for their needs.

Re: mailq's fake output

[Stefano Zacchiroli]

On Mon, May 07, 2001 at 05:09:20PM -0400, Richard A Nelson wrote:
> Dunno, not sure what your problem really is...
> 
> Show me `ls -al /var/spool/mqueue` and `mailq` output.
> 
> Keep in mind that there are two queues, and mailq does *not* show
> /var/spool/mqueue-client, so any mail therein will not show up in
> `mailq` output.  If you want to see both, for the nonce you must:
> `/etc/init.d/sendmail mailq`.

OK, but where is documented this splitting ?
I look the documentation but I can find only partial informations, the
file /etc/mail/sendmail.conf seems documented only by the comments.

I miss something ??

-- 
- Zack -

Stefano Zacchiroli <[EMAIL PROTECTED]> ICQ# 33538863
Home Page: http://www.students.cs.unibo.it/~zacchiro
Undergraduate Student of Computer Science at University of Bologna, Italy
SysAdm of verdicchio.students.cs.unibo.it (130.136.3.134)
"Information wants to be Open"


pgpgiiEkTifbX.pgp
Description: PGP signature

Re: ITP: tdb (Trivial DataBase)

[Wichert Akkerman]

Previously Marek Habersack wrote:
> Put that way it makes perfect sense. But why use libtool then?

last time I checked they didn't use libtool, although that might
have changed since then.

> It might seem that they are planning/thinking of making it a bit larger
> project.

That's not what I hear from its authors :)

> Would it be feasible if only a tdb-dev package existed with an .a
> archive and a set of manpages/includes - at least it would be
> integrated with debian that way?

That's not a bad plan.

Wichert.

-- 
   
 / Generally uninteresting signature - ignore at your convenience  \
| [EMAIL PROTECTED]  http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: Questions to testing/unstable

[Paul Martin]

On Tue, May 08, 2001 at 07:34:32AM +, Andreas Metzler wrote:

> Possible scenario:
> 1.0-3 has some major changes and accidentially fixes an RC-bug in
> 1.0-2, before _anybody_ noticed it in 1.0-2.
> 1.0-2 goes into testing and BLAM.

Surely, the maintainer can then close (or downgrade) the RC bug, saying
it's fixed in the newer version?

(Or are you meaning that the maintainer will have to play whack-a-mole
with multiple identical RC bug entries to get the package into testing?)

-- 
Paul Martin <[EMAIL PROTECTED]>


pgpSZLWVWEobL.pgp
Description: PGP signature

Re: ITP: tdb (Trivial DataBase)

[Marek Habersack]

** On May 08, Wichert Akkerman scribbled:
> Previously Marek Habersack wrote:
> > I plan to write an extension to Pike that uses tdb - it should be used as a
> > shared library in that case. The upstream sources generate a well working
> > .so, so I thought it might be nice to have it in Debian. Also, there might
> > be some code in Caudium that will also use tdb. I'm sure more people would
> > use it as well.
> 
> My point is that that's not how tdb is meant to be used: instead of
> a shared library the idea is to directly copy the tdb source in your
> program. That's why tridge and rusty worked very hard to keep it
> under 1000 lines (it's actually slightly larger now unfortunately). 
Put that way it makes perfect sense. But why use libtool then? It might seem 
that
they are planning/thinking of making it a bit larger project. Would it be
feasible if only a tdb-dev package existed with an .a archive and a set of
manpages/includes - at least it would be integrated with debian that way? If 
anybody
would like to use tdb it would be a snap to install the package and simply
include libtdb.a in their project. I mean, it would give a feeling of
completeness as far as Debian is concerned - no need to download anything
and install from tarballs, just get the deb.

marek

-- 
Visit: http://caudium.net - the Caudium WebServer

/* A completely unrelated fortune */
 When man calls an animal "vicious", he usually means that it will attempt
 to defend itself when he tries to kill it. 
 
 
 
 

pgpabveRHdcPr.pgp
Description: PGP signature

Re: xfs,powerpc, gcc (was Re: RaiserFS PPC status)

[Just a friendly Jedi Knight]

On Tue, May 08, 2001 at 09:52:11AM +0200, Michel Dänzer wrote:
> >  This one bites me a bit. O_DIRECT is missing from bits/fcntl.h on powerpc
> >  (at least on my installation and i sure i didn't mess with libc6-dev). It's
> >  sid/unstable branch. I don't remeber if the intel box i compiled xfsprogs
> >  was running sid/unstable or woody/testing (and this box is down right now)
> >  but there was no problem in compiling xfs_mkfile..
> 
> Please submit a bug against libc6-dev, maybe we'll get an explanation then. ;)
 This O_DIRECT is also missing on sparc (as it came up while i exchanged
 mails with Nathan Scott (debian maintainer of xfsprogs). 
 Good news is that Nathan Scott and me found out a way to make xfsprogs
 compilable on powerpc and next debian package will have it (and i would like
 to thank Nathan for his time and patience with me)
> 
> 
> > Is this another wierdo of PowerPC arch? (as is with varargs).
> 
> varargs isn't weird on powerpc, it just happens that incorrect usage of it 
> works on i386 (like too much else, e.g. its wrong endianness hides type size 
> mismatches, ...) but not for us.

 =o one point for us for having right endianess =o)))

-- 
 Robert Ramiega | [EMAIL PROTECTED]  IRC: _Jedi_ | Do not underestimate 
 UIN: 13201047  | http://www.plukwa.net/   | the power of  Source

Re: ITP: tdb (Trivial DataBase)

[Wichert Akkerman]

Previously Marek Habersack wrote:
> I plan to write an extension to Pike that uses tdb - it should be used as a
> shared library in that case. The upstream sources generate a well working
> .so, so I thought it might be nice to have it in Debian. Also, there might
> be some code in Caudium that will also use tdb. I'm sure more people would
> use it as well.

My point is that that's not how tdb is meant to be used: instead of
a shared library the idea is to directly copy the tdb source in your
program. That's why tridge and rusty worked very hard to keep it
under 1000 lines (it's actually slightly larger now unfortunately). 

Wichert.

-- 
   
 / Generally uninteresting signature - ignore at your convenience  \
| [EMAIL PROTECTED]  http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: ITP: tdb (Trivial DataBase)

[Marek Habersack]

** On May 08, Wichert Akkerman scribbled:
> Previously Marek Habersack wrote:
> >   I intent to package tdb (the Trivial Database) which is a GDBM work-alike.
> > The tdb, unlike GDBM, has support for multiple simultaneous writers and
> > internal locking to protect from overlapped writes. From the upstream
> > readme:
> 
> tdb is definitely an excellent little tool. However how it was written
> to be directly included in a programs source instead of being used as
> a shared library, so I'm not quite sure what use a package of it would
> be?
I plan to write an extension to Pike that uses tdb - it should be used as a
shared library in that case. The upstream sources generate a well working
.so, so I thought it might be nice to have it in Debian. Also, there might
be some code in Caudium that will also use tdb. I'm sure more people would
use it as well.

marek

-- 
Visit: http://caudium.net - the Caudium WebServer

/* A completely unrelated fortune */
 "Go to Heaven for the climate, Hell for the company." -- Mark Twain 
 
 
 
 
 

pgpGr9R9m1vBN.pgp
Description: PGP signature

Re: ITP: tdb (Trivial DataBase)

[Wichert Akkerman]

Previously Marek Habersack wrote:
>   I intent to package tdb (the Trivial Database) which is a GDBM work-alike.
> The tdb, unlike GDBM, has support for multiple simultaneous writers and
> internal locking to protect from overlapped writes. From the upstream
> readme:

tdb is definitely an excellent little tool. However how it was written
to be directly included in a programs source instead of being used as
a shared library, so I'm not quite sure what use a package of it would
be?

Wichert.

-- 
   
 / Generally uninteresting signature - ignore at your convenience  \
| [EMAIL PROTECTED]  http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: Questions to testing/unstable

[Herbert Xu]

Wichert Akkerman <[EMAIL PROTECTED]> wrote:
> Previously Anthony Towns wrote:
>> That's not true at all. It's quite possible (although probably a little
>> unlikely) to maintain your packages from a box running stable, if you like.

> I'ld rather not see people do that: it means we'll also be stuck with
> using old libraries when much newer ones might be available. Look
> at the total mess with different ncurses versions in potato for example.

Just because someone is running unstable, it doesn't mean that they're
compiling against the new -dev packages.  Other things need to be done
to force people to upgrade, e.g., check build-time dependencies and/or
file bug reports.

In the case of ncurses, if someone bothered to file bug reports and/or do
NMUs, it would've been much better.  In the end it was apathy more than
anything else.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: ITP: axmail

[Joop Stakenborg]

On Mon, 7 May 2001 17:57:28 -0500 (CDT)
Steve Langasek <[EMAIL PROTECTED]> wrote:

> 
> If the README says it's not ready for distribution, have you spoken with the
> upstream maintainer yet?  It's wise to take the upstream's feelings into
> consideration, since you will have to work with them for as long as you
> maintain this package for Debian -- best not to start out on the wrong foot.
> :)

That's a good idea.
I'll do that.


Joop
--
Joop Stakenborg - Debian GNU/Linux developer <[EMAIL PROTECTED]>

--> I wanted a woody, but all i could get was slackware. 
My girlfriend was really disappointed...

ITP: tdb (Trivial DataBase)

[Marek Habersack]

Hello,

  I intent to package tdb (the Trivial Database) which is a GDBM work-alike.
The tdb, unlike GDBM, has support for multiple simultaneous writers and
internal locking to protect from overlapped writes. From the upstream
readme:

 This is a simple database API. It was inspired by the realisation that
 in Samba we have several ad-hoc bits of code that essentially
 implement small databases for sharing structures between parts of
 Samba. As I was about to add another I realised that a generic
 database module was called for to replace all the ad-hoc bits.

 I based the interface on gdbm. I couldn't use gdbm as we need to be
 able to have multiple writers to the databases at one time.

The packages are ready and waiting for upload if I'm OK-ed to package it :)

TIA,

 marek

-- 
Visit: http://caudium.net - the Caudium WebServer

/* A completely unrelated fortune */
 Necessity has no law.   -- St. Augustine 
 
 
 
 
 

pgpWTuyh5UMWT.pgp
Description: PGP signature

Re: Woody Freeze Plans - Progress Report II

[Anthony Towns]

On Tue, May 08, 2001 at 12:25:10PM +0200, Adrian Bunk wrote:
> What do entries like
>   mozilla M18-3 libnspr3(i386) M14-2 from M14-2
>   mozilla M18-3 libnspr3-dev(i386) M14-2 from M14-2
> mean?

The libnspr3 and libnspr3-dev in i386 are from mozilla source M14-2,
even though mozilla source is at M18-3. ie, they're out of date, in this
case possibly no longer built.

> And I'm more interested in statistics about how many packages are out out
> of date on each architecture in _unstable_ 

http://ftp-master.debian.org/testing/unstable_outdate.txt

(stable and testing also work)

  2651 i386
  3431 sh
  7841 hppa
 19001 ia64
 239   191 alpha
 24701 hurd-i386
 35331 arm
 40561 sparc
 72061 m68k
 76381 mips
 768   231 powerpc

(the middle column will be binary-only uploads that have improper
versions; either poorly numbered binary only recompiles, or new versions
uploaded without source)

> like the figures ajt posted
> some weeks ago - I want to see which autobuilders have problems and need
> perhaps help.

There are also figures based on how the auto-builders are doing, but
they're not necessarily all that reliable yet, and they're not on a
webpage anywhere:

Out of dates holding up testing:
  8 i386
 87 alpha
 96 arm
178 sparc
223 powerpc
237 m68k

wanna-build stats:
  alpha:   93.79% up-to-date,  93.89% if also counting uploaded pkgs
  arm: 88.19% up-to-date,  89.33% if also counting uploaded pkgs
  hppa:40.06% up-to-date,  46.64% if also counting uploaded pkgs
  i386:99.55% up-to-date,  99.55% if also counting uploaded pkgs
  ia64:58.12% up-to-date,  59.39% if also counting uploaded pkgs
  m68k:78.97% up-to-date,  79.89% if also counting uploaded pkgs
  mips:56.93% up-to-date,  56.93% if also counting uploaded pkgs
  mipsel:   1.48% up-to-date,   1.48% if also counting uploaded pkgs
  sparc:   90.62% up-to-date,  91.89% if also counting uploaded pkgs

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
  -- John S. Novak, III (The Humblest Man on the Net)


pgpr20x197RJb.pgp
Description: PGP signature

Re: Woody Freeze Plans - Progress Report II

[Adrian Bunk]

On Mon, 7 May 2001, Roland Bauerschmidt wrote:

> Adrian Bunk wrote:
> > I did perhaps only miss it: You did post some weeks ago a list how much
> > each architecture is keeping up with unstable (how many % of the packages
> > in unstable are compiled on this architecture). Is there a website with
> > these figures regularly updated for all ten architectures (six in potato
> > plus the four you mention here)?
>
> http://ftp-master.debian.org/testing/testing_outdate.txt (resp.
> unstable_outdate.txt) shows which packages are out of date and at the
> end there seem to be some statistics...

What do entries like
  mozilla M18-3 libnspr3(i386) M14-2 from M14-2
  mozilla M18-3 libnspr3-dev(i386) M14-2 from M14-2

mean?

And I'm more interested in statistics about how many packages are out out
of date on each architecture in _unstable_ like the figures ajt posted
some weeks ago - I want to see which autobuilders have problems and need
perhaps help.


> Roland

cu
Adrian

-- 

Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.

Re: Bug#96638: ITP: libkudzu

[Bas Zoetekouw]

Hi David!

(cc'ing to debian-devel)

You wrote:

> Can you compare libdetect or discover 
> 
> http://archive.progeny.com/progeny/dists/Progeny1.0/main/source/base/discover_0.9.19.tar.gz
> 
> to kudzu?  

I really have no idea. Since kudzu has no serious documentation
whatsoever, it's quite hard to find out what devices it can actually
detect. The README file says:

2) What type of devices does kudzu detect?

Currently, kudzu detects:

- PCI cards
- SBUS cards
- serial devices (PnP devices, mice, modems)
- parallel port devices (printers)
- SCSI devices (provided the appropriate SCSI modules are loaded)
- IDE devices
- PS/2 mice
- Keyboards on SPARC

So that's not very helpfull either. 

Based on the little that I've seen of libdetect, it's probably a more
robust tool.

> We're using libdetect at the moment on debian-installer, I had thought that
> kudzu was dead, but I guess not.  What I would like is to have a real hardware
> detection system that continues after the main installation. That way when new
> hardware is added to the system we could help the user make the necessary
> software changes.

Is there already policy on how this hardware detection should be
implemented?

-- 
Kind regards,
+---+
| Bas Zoetekouw  | Si l'on sait exactement ce   |
|| que l'on va faire, a quoi|
| [EMAIL PROTECTED] | bon le faire?|
|[EMAIL PROTECTED] |   Pablo Picasso  |
+---+ 

Re: Questions to testing/unstable

[Wichert Akkerman]

Previously Anthony Towns wrote:
> That's not true at all. It's quite possible (although probably a little
> unlikely) to maintain your packages from a box running stable, if you like.

I'ld rather not see people do that: it means we'll also be stuck with
using old libraries when much newer ones might be available. Look
at the total mess with different ncurses versions in potato for example.

Wichert.

-- 
   
 / Generally uninteresting signature - ignore at your convenience  \
| [EMAIL PROTECTED]  http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: Questions to testing/unstable

[Petr Cech]

On Tue, May 08, 2001 at 07:29:31PM +1000 , Anthony Towns wrote:
> On Tue, May 08, 2001 at 11:05:49AM +0200, Petr Cech wrote:
> > On Tue, May 08, 2001 at 06:42:33PM +1000 , Herbert Xu wrote:
> > > FWIW, I do all my development under testing.  I virtually ignore unstable
> > > unless I need a specific package from it.
> > but autobuilders will still compile with unstable, so it's really useless
> > (even dangerous) to upload i386 build on woody, when autobuild packages are
> > unstable.
> 
> That's not true at all. It's quite possible (although probably a little
> unlikely) to maintain your packages from a box running stable, if you like.

that depends. If I need libc6, X and gtk maybe, but you really loose on
apache, sablot (I need to kick the maintaner for the stupid shlibs, IMHO).
Or the ssl fiasco. I´ve had unstable package made uninstallable day after I
uploaded it with compiled latest unstable. Now, should I let the package
there - no, because mostly the new upload also deletes the one I compiled
with and so there is NO way to get that upload into testing

The same if, if I would compile with woody - it made the package
uninstallable on sid and I would have to pray that the hacked build-depends,
what were made according the status of woody, when I uploaded was still
valid when autobuilders get around to rebuild. Of course I loose unstable
for that. The result? The package is not in testing and not installable in
unstable

Petr Cech
-- 
Debian GNU/Linux maintainer - www.debian.{org,cz}
   [EMAIL PROTECTED]

 We Are Debian.  You Will Be Packaged. Media Opinion Is Irrelevant.

Re: Questions to testing/unstable

[Anthony Towns]

On Tue, May 08, 2001 at 11:05:49AM +0200, Petr Cech wrote:
> On Tue, May 08, 2001 at 06:42:33PM +1000 , Herbert Xu wrote:
> > FWIW, I do all my development under testing.  I virtually ignore unstable
> > unless I need a specific package from it.
> but autobuilders will still compile with unstable, so it's really useless
> (even dangerous) to upload i386 build on woody, when autobuild packages are
> unstable.

That's not true at all. It's quite possible (although probably a little
unlikely) to maintain your packages from a box running stable, if you like.
It's certainly okay to run from a somewhat out-of-date unstable box, and
that's essentially what testing ends up being. Some parts are obvious more
out of date than others, though.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
  -- John S. Novak, III (The Humblest Man on the Net)


pgp7JrrzQmXe9.pgp
Description: PGP signature

Re: lame

[Bas Zoetekouw]

Hi MaD!

You wrote:

> this is my first message, i hope it's appropriate. there's talk going
> on on the users mailing list about lame and its absence from the
> package tree. i would like to adopt the lame mp3 encoder as a debian
> package and was wondering if there are any objections? is there
> already a maintainer? can this packet be debianized?

lame cannot be distributed because of mp3 patent issues, nor can any
other mp3 encoder afaik.

-- 
Kind regards,
+---+
| Bas Zoetekouw  | Si l'on sait exactement ce   |
|| que l'on va faire, a quoi|
| [EMAIL PROTECTED] | bon le faire?|
|[EMAIL PROTECTED] |   Pablo Picasso  |
+---+ 

Re: PostgreSQL in testing

[Petr Cech]

On Mon, May 07, 2001 at 06:09:10PM +0100 , Oliver Elphick wrote:
> Anthony Towns wrote:
>   >Nah, it's the other way around: one of the php3 binaries in testing
>   >doesn't work with the postgresql in unstable, and the php3 in unstable
>   >doesn't work with the postgresql in testing; ditto some other php3 binary
>   >and apache, and a few other similar things. It gets quite complicated :)
> 
> Is the automatic system capable of handling that (when the versions in
> unstable work together)? or will it need manual intervention?

it's the dependencies. Remember, I pested you about libpgsql2 vs.
libpgsql2.1 - that's the cause. unstable has no libpgsql2 and testing has no
libpgsql2.1, that's why must php3 (and php4) go together with postgresql.
Now it's even better, because postgresql moved to non-US. I'll probably need
to stop building postgresql module from the whole package and make it a
separate non-US package.

aj: feel free to remove php3 from testing if it will make things easier. I'd
like to get php4 there ass php3 is not maintained upstream anymore.

Petr Cech
-- 
Debian GNU/Linux maintainer - www.debian.{org,cz}
   [EMAIL PROTECTED]

"Computers are useless. They can only give answers."Pablo Picasso

Re: Questions to testing/unstable

[Petr Cech]

On Tue, May 08, 2001 at 06:42:33PM +1000 , Herbert Xu wrote:
> Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
> 
> > Most of us don't bother too much with testing, unless we're trying to get
> > something into testing for one particular reason or another (such as, the
> > package in testing is too damn buggy, or has a security hole).
> 
> FWIW, I do all my development under testing.  I virtually ignore unstable
> unless I need a specific package from it.

but autobuilders will still compile with unstable, so it's really useless
(even dangerous) to upload i386 build on woody, when autobuild packages are
unstable.

Also there are problems with library dependencies. Should I let rot a
package in unstable uninstallable, just because I hope it will make it in
month or two into testing? No way!

Petr Cech
-- 
Debian GNU/Linux maintainer - www.debian.{org,cz}
   [EMAIL PROTECTED]

 Debian - It is all about choice, baby!!

Re: Questions to testing/unstable

[Petr Cech]

On Mon, May 07, 2001 at 08:25:53PM +0200 , Michael Meskes wrote:
> > Most of us don't bother too much with testing, unless we're trying to get
> > something into testing for one particular reason or another (such as, the
> > package in testing is too damn buggy, or has a security hole).
> 
> Whow! Now that is a great explanation. We started testing for a reason. If

yes. and some of us gave up on testing. If I could do anything with it, I
would. But as it's now I can safely ignore it

Petr Cech
-- 
Debian GNU/Linux maintainer - www.debian.{org,cz}
   [EMAIL PROTECTED]

"Computers are useless. They can only give answers."Pablo Picasso

Re: Questions to testing/unstable

[Herbert Xu]

Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:

> Most of us don't bother too much with testing, unless we're trying to get
> something into testing for one particular reason or another (such as, the
> package in testing is too damn buggy, or has a security hole).

FWIW, I do all my development under testing.  I virtually ignore unstable
unless I need a specific package from it.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Questions to testing/unstable

[Andreas Metzler]

Michael Meskes <[EMAIL PROTECTED]> wrote:
[snip]
> Why isn't it possible to move 1.0-2
> after one week even though 1.0-3 exists in unstable?

Hello!
Because 1.0-2 was not tested properly. After 1.0-3 is released nobody
uses 1.0-2 anymore, bugs in 1.0-2 but not in 1.0-3 won't be found.

Possible scenario:
1.0-3 has some major changes and accidentially fixes an RC-bug in
1.0-2, before _anybody_ noticed it in 1.0-2.
1.0-2 goes into testing and BLAM.
 cu andreas
-- 
Uptime: 10 seconds  load average: 0.00, 0.00, 0.00
vim:ls=2:stl=***\ Sing\ a\ song.\ ***

Re: xfs,powerpc, gcc (was Re: RaiserFS PPC status)

[Michel Dänzer]

Just a friendly Jedi Knight wrote:
On Mon, May 07, 2001 at 04:27:18PM +0200, Just a friendly Jedi Knight wrote:
=== mkfile ===
gcc -g -DDEBUG -funsigned-char -Wall  -I../include '-DVERSION="1.2.4"'
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DXFS_BIG_FILES=1
-DXFS_BIG_FILESYSTEMS=1   -c -o xfs_mkfile.o xfs_mkfile.c
xfs_mkfile.c: In function `main':
xfs_mkfile.c:144: `O_DIRECT' undeclared (first use in this function)
 This one bites me a bit. O_DIRECT is missing from bits/fcntl.h on powerpc
 (at least on my installation and i sure i didn't mess with libc6-dev). It's
 sid/unstable branch. I don't remeber if the intel box i compiled xfsprogs
 was running sid/unstable or woody/testing (and this box is down right now)
 but there was no problem in compiling xfs_mkfile..
Please submit a bug against libc6-dev, maybe we'll get an explanation then. 
;)

Is this another wierdo of PowerPC arch? (as is with varargs).
varargs isn't weird on powerpc, it just happens that incorrect usage of it 
works on i386 (like too much else, e.g. its wrong endianness hides type size 
mismatches, ...) but not for us.

--
Earthling Michel Dänzer (MrCooper)\   Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast   \XFree86 and DRI project member

Re: support for older distributions

[Brian May]

> "Russell" == Russell Coker <[EMAIL PROTECTED]> writes:

Russell> To manage this fully through the Debian system we will
Russell> need support in the BTS for reporting bugs to different
Russell> people depending on the package version.  Is this
Russell> possible?

Another problem which I consider a big issue, I think we need some way
to keep track of different compiled versions.

For instance, if I compile my own version of libx from unstable for my
unstable system, and then run apt-get upgrade, apt will try (under
various different situations) try to install libx-dev from
unstable. However, this is wrong, because even though the version
numbers match, libx-dev may contain static libraries which require the
newer version of libc6. (not to mention different compile time options
that could be used when compiling libx).

So I really think there needs to be some way libx can say:

Package: libx
Build-Id: x

where build is some unique identifier inserted at compile time. This
could be similar to the Message-Id header on this E-Mail. Each time a
package was compiled, it would get a different Build-Id.

And then  libx-dev can say:

Package: libx-deb
Depends: libx (= version [x])

which says libx-dev can only be installed with the libx version that
was built at the same time. Actually, that could be simplified to

Package: libx-deb
Depends: libx (=[x])

as per my definition of build-id, if it is the same, the version must
also be the same. Using this new syntax would only occur for special
cases, eg. most (if not all) -dev packages.

Of course, other methods are also possible (eg. insert depends of libx
into depends of libx-dev), but this is my preferred option.

You might even be able to use this new field to help the BTS tracking
of packages somehow, but I haven't thought too much of this aspect.
-- 
Brian May <[EMAIL PROTECTED]>

Re: support for older distributions

[Brian May]

> "Russell" == Russell Coker <[EMAIL PROTECTED]> writes:

Russell> I would like a version of Potato that is not entirely
Russell> frozen.  It should have updates not only for security
Russell> reasons but also for addition of new programs, and for
Russell> adding new programs which add significant functionality
Russell> and don't break things (such as Wichert's LDAP packages).

Another suggestion (one which you may not like, I haven't considered
it in to much detail):

Create a new Packages file for a new distribution (not sure what you
would call it) that lists stable Packages. Then once Y is convinced
that package X from {testing,unstable} runs OK, Y updates the new
Package file to include the new version of X. Any broken package
should not appear in this new distribution.

So it would be sort of like testing, only based around stable, not
unstable.

Pitfalls:

Of course, it goes without saying, that you can't copy the new package
into the new distribution until all dependencies have already been
satisfied. Including libc6 + libc6 related packages.

Also, I have not considered multiple architectures either.

Who is Y? What criteria is used?
-- 
Brian May <[EMAIL PROTECTED]>

Re: Questions to testing/unstable

[Michael Meskes]

On Mon, May 07, 2001 at 01:51:12PM -0300, Henrique de Moraes Holschuh wrote:
> Developers are supposed to know what they're doing with the urgency field.
> It can be used to decrease the quarantine time of a particular upload (and
> all subsequent ones until the package manages to get installed in testing).

Okay. Thanks for explaining this.

> Most of us don't bother too much with testing, unless we're trying to get
> something into testing for one particular reason or another (such as, the
> package in testing is too damn buggy, or has a security hole).

Whow! Now that is a great explanation. We started testing for a reason. If
all of us think that way we can as well stop using testing at all, as it
will only contain packages from the old stable and some that are just
developing to slowly to remain in quarantine.

I think the ide was to constantly work on the new stable release. To do that
we have to keep testing in the mix. Why isn't it possible to move 1.0-2
after one week even though 1.0-3 exists in unstable?

Michael

-- 
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!

Re: ITP: ardour -- professional multitrack audio editing tool

[Junichi Uekawa]

[EMAIL PROTECTED] cum veritate scripsit:

Please be careful with ladspa.h
It's currently not free.

> a "professional" multitrack multichannel audio recorder and DAW using
> ALSA-supported audio interfaces. Supports up to 32-bit samples, 24+ channels 
> at
> up to 96 kHz, non-destructive, non-linear editing.
> 
> Licence is GPL.
> 
> http://ardour.sourceforge.net
> 


-- 
Junichi Uekawa 
  [EMAIL PROTECTED] (University)
  [EMAIL PROTECTED] (Netfort)
  [EMAIL PROTECTED] (Debian Project)
  [EMAIL PROTECTED] (Debian JP Project)