Re: FREEZE RESCHEDULED

1999-11-07 Thread Hartmut Koptein
  One of the best ways of getting the release-critical bugs under
  control is to freeze potato.  As long as we can upload packages, we
  will upload bugs.  If we freeze now, we can reduce the number of bugs
  to a reasonable level over the next few weeks.  By the time
  boot-floppies are ready the bug count will be at a manageable level,
  and potato will be ready for release.
 
 How about a light freeze where we don't accept new packages until the next
 unstable. Then atleast we don't age the distribution, and we can still
 upgrade packages, and fix bugs.

Every year with the same problems :-) 

This 'pre-release' will do it if we don't work on the new unstable; this one is 
only 
to upload new versions. 


Regards,


   Hartmut



Re: Debian's involvement in another exhibition

1999-09-23 Thread Hartmut Koptein
  Where is Oldenburg geographically? E.g. how far from Holland? :-)
 
 Groningen is about 100km.  It's 50km south of the coast, where
 the coast makes its way to the inner country.  (difficult to
 explain.)

 _
(_)

 _   _/ -\
(_) (_)  |\/
 | o Aurich|   |
 / \   /\  |
|   \  |  o Emden|/
/ o  |  | ---/
 Groningen   |  |
  \-/
  o Leer
o
 Winschoten   
   o   o Oldenburg
 Assen   =o Bremen

  
 o Emmen




Re: Too many kernels in unstable

1999-09-17 Thread Hartmut Koptein
  Once 2.2.12 makes it out of Incoming, we will have 8 kernel versions in
  the unstable distribution?  Do we REALLY need to provide that many
  versions of the kernel??
 
 What about just keeping the last 2.0.x and the last 2.2.x ?  It's also
 a lot of space on the ftp site.

And maybe one from the unstable tree 2.3.18 to test compatibility for 2.4 ?
This are then only three kernel versions. 

Thanks,

Hartmut



Re: Old Library dependencies Re: Release Plans (19990513)

1999-05-17 Thread Hartmut Koptein
Remove as many dependencies on old libraries as possible, this
includes:
  
  libjpegg6a, libncurses3.4, newt0.25, libpgsql, tk4.2, tcl7.6,
  libwraster1, libpng0g
  
and various older gtk/gnome libraries.
 
 Lintian has a depends-on-obolete-package tag.  I will add newt0.25,
 libpgsql, tk4.2, tcl7.6, libwraster1, and libpng0g to its list.
 This way, the Lintian page for that tag will form a useful index.

Why not  libjpegg6a and libncurses3.4?

What about  xbase, emacs19, altgcc, freetype1, libc5, libg++27, libpaper,
tclx76  and possible some more?


Thnx,

   Hartmut




Re: Release Plans (1999-05-10)

1999-05-14 Thread Hartmut Koptein
  Also the mozilla web pages are not very informative about non-i386
  compilability, but then maybe i didn't search in the right place ...
 
 I don't know much about porting, but I do know that it works on
 Solaris, and some versions worked on AIX and HP-UX... since those
 OSs run on different architectures, I'd say it could work. Good luck :)

For powerpc: the composer mode works. The normal mode (with menus) not.

Thnx,

   Hartmut



Re: Release Plans (1999-05-10)

1999-05-13 Thread Hartmut Koptein
 The non-mac CHRP boards (LongTrails etc.) also use OF I believe.  Are
 their OF's so broken that they don't work properly as well?  Perhaps APUS
 and PReP (and I'm talking PPCBUG firmware not OF systems) are the only
 ones we need to worry about.  Interestingly enough, Motorola dropped OF
 because it was so damn buggy.

The OF of my LongTrail works perfectly but i don't know how to set it up for
autobooting. Booting from floppy is not (yet) possible (for initrd) because
the kernel cannot read the floppy. So net or cd booting are the only choices. 

Currently i wait for manoj's update for his kernel-package with my changes. 
After
that, compiling will be easier. But then i need kernel-diffs for apus, pmac, 
prep
and also mbx for the 2.2.x tree. Which class is rs/6000, chrp or prep? 

Thnx,

   Hartmut



Re: Release Plans (1999-05-10)

1999-05-12 Thread Hartmut Koptein
There's also another thing that need to be worked on, the CDs. The
script creating the images is not smart enough to select just the
good number of packages for each CDs. Currently, the two binary CDs
can still be generated for potato but not the source images (they are 
too
big). And many dependencies on the first CD are not met.
   
   For m68k-mac and powermac we need 'hybrid' cd-images (msdos + hfs). 
  
  A bootable CD for PReP will need a special layout as well.  prep image +
  isofs...looks like we need multiple powerpc binary cd images.
 
 And i guess this will be the same for apus systems, ...

No! Only one (2) cd for all powerpc systems. Please think about a wrapper for 
this
or special boot-arguments ...  but not 5 different powerpc-images. 

Thnx,

Hartmut



Re: Release Plans (1999-05-10)

1999-05-11 Thread Hartmut Koptein
  For m68k-mac and powermac we need 'hybrid' cd-images (msdos + hfs). 
 
 slink-cd makes HFS hybrid CDs for m68k already; I'm pretty sure I
 asked Steve to use the HFS options for PowerPC too (so the code's
 already there...)

Great! One point i can strike off from my todo list. Thanks.



Re: Release Plans (1999-05-10)

1999-05-10 Thread Hartmut Koptein
On May 10, Paulo Henrique Baptista de Oliveira wrote:
   I think that Power PC will be included in potato.

It will be definitly.



Re: Release Plans (1999-05-10)

1999-05-10 Thread Hartmut Koptein
Moin all,

   * Working disk sets for all released architectures.
 I don't know much about the plans for the boot-floppies yet.  Could
 someone volunteer as a contact person, or tell me the best list to read?

A minimum is two months for this -- if we start now to work on this.


   * glibc 2.1 source compatibility
 A larger task is to ensure that all packages still compile on a glibc
 2.1 development system.  The sparc people may have a list of problem
 packages.

The packages must work for glibc-2.1 _and_ linux-2.2, this is important.
I think we have more then 100 release-critical bugs, not all such bugs 
are marked as critical. I've put my autobuilder logfiles (for bad packages)
on http://master.debian.org/~koptein  -- please have a look at it. This
are not all glibc-2.1, linux or dpkg bugs, but mainly. 


   Timescale:
 The freeze is at least one month away, and possibly a lot more than
 that.  I'm not going to set a date until the number of
 release-critical bugs has been reduced considerably.

Correct.

   Potato Architectures:
 As far as I know it will be the same set as in slink, i.e. i386, m68k,
 sparc, and alpha.  If any other architectures want to make a release
 they will have to decide soon.

+ PowerPC


The biggest showstopper are the boot-floppies -- for all architectures! 


Other topics:  language support for boot-floppies (and then also cd-images)
   and dpkg  dselect (and newer apt-get versions). 

   mozilla should work for potato 


Thnx,


   Hartmut



Re: Release Plans (1999-05-10)

1999-05-10 Thread Hartmut Koptein
Hi,

 BTW, I think it's good to set an *optimistic* freeze date, so people
 aren't shocked.  I would set it at July 1, or maybe Bastille day
 (Debian pomme de terre?).

For slink update or for potato? For potato we new min. two months and
only if we start now working very hard (all maintainers, not only 10 people or 
so)
on bad packages  boot-floppies  cd-images.

The QA-team must then also have the power to do massive NMU's. How many open 
bugs
have we, more then 7000?  This must be down to ~1000. 

Thanks,


Hartmut



Re: Release Plans (1999-05-10)

1999-05-10 Thread Hartmut Koptein
 The best list is [EMAIL PROTECTED] The main problem we are
 facing is our official 2.2.x kernels are huge, and there's no way to put
 the kernel and the root.bin image on a single floppy. The proposed
 solution is building a modularized kernel, and loading the needed modules
 using an initrd image, but AFAICT, there's nobody working on that.

What about the ramdisk/root.bin (and then also for the netboot-ramdisk)?
They are also very huge now. Floppies with 1.7MB isn't good ... 

Regards,


Hartmut



Re: Release Plans (1999-05-10)

1999-05-10 Thread Hartmut Koptein
 There's also another thing that need to be worked on, the CDs. The
 script creating the images is not smart enough to select just the
 good number of packages for each CDs. Currently, the two binary CDs
 can still be generated for potato but not the source images (they are too
 big). And many dependencies on the first CD are not met.

For m68k-mac and powermac we need 'hybrid' cd-images (msdos + hfs). 



Re: KDE debian stuff

1999-05-10 Thread Hartmut Koptein
 kdm not requiring xdm.  (I migrated kdm out of kdebase so it is a seperate
 package..this should take care of this for the time being)
 migrate kde out of /usr/X11R6/bin and into /usr/bin  (requested by someone)
 fixing up the scripts (still working on this...have current issues with the 
 i18n
   stuff, but everything else works)

/etc/init.d/kdm shouldn't use  /etc/X11/config, its obsolete.

#!/bin/bash
# /etc/init.d/xdm: start or stop XDM.

test -f /etc/X11/config || exit 0

grep -q ^xbase-not-configured /etc/X11/config  exit 0

case $1 in
  start)
  grep -q ^start-kdm /etc/X11/config || exit 0
  if grep -q ^start-xdm /etc/X11/config
then
echo WARNING : can only start kdm or xdm, but not both !
  fi


Thanks,


  Hartmut



Re: Release Plans (1999-05-10)

1999-05-10 Thread Hartmut Koptein
  For m68k-mac and powermac we need 'hybrid' cd-images (msdos + hfs). 
 
 A bootable CD for PReP will need a special layout as well.  prep image +
 isofs...looks like we need multiple powerpc binary cd images.

PReP can't read msdos partition on cd?




Re: Release Plans (1999-05-10)

1999-05-10 Thread Hartmut Koptein
Hi,

sorry for the confuse layout on http://master.debian.org/~koptein 

`log for successful build of x' means also a bad/failed package; this
comes from an bad return value of one of the autobuilder scripts (don't know
which one). 

Thanks,


Hartmut



Re: Release Plans (1999-05-10)

1999-05-10 Thread Hartmut Koptein
 mozilla should work for potato 
 
 Maybe it will ;) We'll try.

I try it now serveral weeks (not constantly), but all what i get is the
'composer' mode on powerpc (the one without the menus) or a window without
anything in it. It makes no different if i use the M4 version from master
or the cvs version (with idl). 

Any tips/hints for this?


Thnx,


Hartmut



Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs

1998-10-16 Thread Hartmut Koptein
3. Porters needn't to ask maintainers for permission
 
 No-one has to ask for permission for a NMU. That's the point of a NMU. You
 file a bug, you wait a reasonable time, if it's not closed, you do a MNU.
^^^
Ahhh! Now you have it! This is very bad! Because: low on time, low on hd space,
low brain :-), and so on ...

Forget it then. This is not possible.  (Reminder: porters (i) talk about  200
packages, and after my list 'work for developers' only two people get in 
contact).


I think, we should it do as we have it done the last three years.


Thanks,

Hartmut


-- 
 Hartmut Koptein   EMail:
 Friedrich-van-Senden-Str. 7   [EMAIL PROTECTED]
 26603 Aurich   
 Tel.: +49-4941-10390  [EMAIL PROTECTED]



Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs

1998-10-15 Thread Hartmut Koptein

 But you're missing my point. Why does a binary-only NMU give you the right
 to skip waiting, while a normal NMU does not? Why are they different? Why
 does one let you circumvent the rules, for however noble a purpose?
 
 Binary-only and normal NMU's are the same thing, and if you can do a
 binary-only NMU w/o waiting, you should be able to do a normal NMU w/o
 waiting. And if you can do that, it follows you should, since a normal NMU
 is better.


How will you feal, if i get one of your packages, make necessary patches for
kernel-2.1 and glibc-2.1 and egcs to it and upload the package _with_
source (without asking you for permission) to master. And then you notice
that this new source-package is broken on your system?

binary-only MNU hits only one arch
normal NMU hits possible all archs 

Another story:

I patched a debian binary in february, forwarded the patch directly to the
maintainer (not to the BTS) and uploaded this package as a binary-only
MNU. This package (with the patch) is always not yet available, because
the maintainer is very busy to make a new release. This is more then a
1/2 year !

Greetings,

  Hartmut

PS: we talk no about two or three packages, porters means 100 or 200 packages 
:-)


-- 
 Hartmut Koptein   EMail:
 Friedrich-van-Senden-Str. 7   [EMAIL PROTECTED]
 26603 Aurich   
 Tel.: +49-4941-10390  [EMAIL PROTECTED]



Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs

1998-10-15 Thread Hartmut Koptein
Ok, 

  let us a little bit summarize:


  1. binary-only NMUs breaks policity
  2. every NMU must be with source
  3. Porters needn't to ask maintainers for permission
  4. a NMU fixes bugs; no need to forward this to the BTS or the maintainer

ok for all ?   

   If the answer is 'yes'  i agree !


If so, we (porters) increment always the debian package minor number +1 .


  MfG,

 Hartmut



-- 
 Hartmut Koptein   EMail:
 Friedrich-van-Senden-Str. 7   [EMAIL PROTECTED]
 26603 Aurich   
 Tel.: +49-4941-10390  [EMAIL PROTECTED]



Re: Upcoming 2.1 Release Architectures

1998-10-15 Thread Hartmut Koptein
 
 If we call it something like a 'developer' release, or an 'early-access'
 release, then it sounds like a great idea, yes...  as long as people don't
 get the impression that it is a full 2.1 release.

Ok, under this impression powerpc is ready to go. 

I'll upload 2.1 kernel source and images for powerpc in three or four days
to master. Possible we can have only _one_ source and not as for glibc-2.1
many source-packages available (2.0.93, 2.0.95). 

I'm not sure, if i should upload the cvs tree or the normal linus tree. 
Powerpc is nearly perfect with the official linux 2.1 tree, what about 
sparc?

Thanks,

Hartmut


-- 
 Hartmut Koptein   EMail:
 Friedrich-van-Senden-Str. 7   [EMAIL PROTECTED]
 26603 Aurich   
 Tel.: +49-4941-10390  [EMAIL PROTECTED]



Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs

1998-10-15 Thread Hartmut Koptein
Hi James,

 Who said they were bad?  They are very rarely necessary however, since
 99.5% of the time (the only exception I know of is Hartmut's packages)

yes, my packages are the only one that test masters scripts for non-i386
maintainer source uploads. :-)

This is now possible but it was not always the case in the past. 



Its time to remember: 
 
- multi archs cds are comming 
- work is in progress for downloading serveral arch binaries from our web 
pages
- documentation will be better and better
- debian is always free

but:  we have always no consens for an easy installation - what means: (new) 
users have
  not the choice to select for a base- , middle- or big-installing 
procedure.

This is more important then a x11 installation (for boot-floppies). 

[joda filter off] :-)


   Hartmut

-- 
 Hartmut Koptein   EMail:
 Friedrich-van-Senden-Str. 7   [EMAIL PROTECTED]
 26603 Aurich   
 Tel.: +49-4941-10390  [EMAIL PROTECTED]



Re: Upcoming 2.1 Release Architectures

1998-10-14 Thread Hartmut Koptein
  Could I get some official word on which architectures wish to be included
  in the 2.1 release of Debian?  Thanks!
  
 PowerPC has more or less given up on making 2.1.  We're moving well,
 but I'm of the inclination we shouldn't release until we have a truly
 stabilized libc - or at least until we're a lot closer.

Right, powerpc shouldn't go in right now. We have more then 200 packages
uncompiled (many maintainer doesn't response for bug lists!!!).

We need a 2.1.x kernel source package, which isn't available for debian. 

Brian and the other arch maintainer with 2.1 kernels: what about to
have the linux-cvs tree (as a debian package) in experimental?? This
will help. Linux-2.1.125 is very near on linux-2.2 !!

I like also to have the powerpc-debian-cd available before we release.

Thanks,

Hartmut





-- 
 Hartmut Koptein   EMail:
 Friedrich-van-Senden-Str. 7   [EMAIL PROTECTED]
 26603 Aurich   
 Tel.: +49-4941-10390  [EMAIL PROTECTED]



Re: Upcoming 2.1 Release Architectures

1998-10-14 Thread Hartmut Koptein
  We need a 2.1.x kernel source package, which isn't available for debian.
 
 I don't see why you couldn't create one just for the powerpc arch.  Either
 way, v2.2 of the kernel should be available before v2.2 of Debian.

Yes, last rumors say that linux-2.2 came out short before christmas.

Oh, i can generate a kernel-image_2.1.125-1_powerpc.deb along with source
and dsc files and upload it to master, but will you and the other arch
maintainer agree with this?? 

  Brian and the other arch maintainer with 2.1 kernels: what about to
  have the linux-cvs tree (as a debian package) in experimental?? This
  will help. Linux-2.1.125 is very near on linux-2.2 !!
 
 I'm afraid I don't understand.  What do you mean about the linux-cvs tree?

The linux-cvs tree fits better for all architecturces then the 'normal' linus
tree. But anyway, i think start working on pre-linux-2.2 is a good thing. 
Xfree needs some work for framebuffers, new alternativly x11 setup for 
boot-floppies,
new config files for the kernel-package, ...

BTW: have we binaries for the bttv driver available (video/audio driver)?

Greetings,

   Hartmut


-- 
 Hartmut Koptein   EMail:
 Friedrich-van-Senden-Str. 7   [EMAIL PROTECTED]
 26603 Aurich   
 Tel.: +49-4941-10390  [EMAIL PROTECTED]



Re: Upcoming 2.1 Release Architectures

1998-10-14 Thread Hartmut Koptein
  Oh, i can generate a kernel-image_2.1.125-1_powerpc.deb along with source
  and dsc files and upload it to master, but will you and the other arch
  maintainer agree with this??
 
 If it's a powerpc package only, I don't see why there would be a problem.
 It should get installed automatically without ever coming to my attention.
 Or is there something I don't understand?


Great news. But uploading a *.deb package without source?? I think this will
be rejected!? And you mean uploading to unstable, not to experimental?

And in the past, we have had one kernel-source with additionel patches for
not fully supported architectures (as m68k). I think this will be similary for
linux-2.2 - i386, alpha and powerpc are fully integrated, but arm and m68k
won't (don't know it for sparc and mips). 

But uploading 2.1 kernel images will help. Thanks for the info.

Regards,

   Hartmut


-- 
 Hartmut Koptein   EMail:
 Friedrich-van-Senden-Str. 7   [EMAIL PROTECTED]
 26603 Aurich   
 Tel.: +49-4941-10390  [EMAIL PROTECTED]



Re: Upcoming 2.1 Release Architectures

1998-10-14 Thread Hartmut Koptein
  Brian Could I get some official word on which architectures wish
  Brian to be included in the 2.1 release of Debian?  Thanks!
  
  I don't think sparc is ready to go, though Johnnie or Eric may see it
  differently.
  
 I'm neither Johnnie nor Eric but I think the basic tools on sparc are
 stabilizing (compiler, glibc2.1, kernel). I don't think Sparc is ready
 for a full blown quality release like i386.
 
 Does it make sense to go for a stabilized developer snapshot, i.e.
 a Sparc port which has base, required, standard and parts of the
 optional packages (sources based on the slink dist of i386) ? 
 Kind of a official _development_ release with a big disclaimer about
 the development character of the port. Powerpc probably would be a
 second candidate for such a release.
 
 2 reasons in favour:
 
 * we ease the work of the CD producers to provide a _reasonable_ 
 (installable) snapshot of the ports
 
 * if there's a stabilized snapshot newbies will get (hopefully) a
 softer introduction in the wonders of the Linux-Sparc/Powerpc/Arm/... world


Yes, that would be great! And to have all binaries and sources on cd's. 

Sparc and powerpc are easily setupable per tftpboot and from cd, but
powerpc has no (tested!) boot-floppies. The point is not to have all
1500 debian packages available, it must be an easy-to-go system from
ground. Is this the case for sparc: goahead!

BTW: if sparc uses also linux-2.1.x, you have no kernel images available. 

MfG,

   Hartmut


-- 
 Hartmut Koptein   EMail:
 Friedrich-van-Senden-Str. 7   [EMAIL PROTECTED]
 26603 Aurich   
 Tel.: +49-4941-10390  [EMAIL PROTECTED]



Re: PROPOSAL: one debian list for all porting efforts

1998-10-12 Thread Hartmut Koptein
  to increase communication betweenm the ports and between porters and
  non-porters, I'd propose a new list:
  
  debian-porting
  or sim.
 
 I fully support this proposal (The name debian-porting seems fine to me)

No, we haven't enough topics for this new list.

 IMHO, it makes sence to create a new list, since it seems 90% of the
 Debian developers use i386 only...

:-)   debian/i386 is also a port!

MfG,

Hartmut



-- 
 Hartmut Koptein   EMail:
 Friedrich-van-Senden-Str. 7   [EMAIL PROTECTED]
 26603 Aurich   
 Tel.: +49-4941-10390  [EMAIL PROTECTED]



Re: Only m68k and i386 in hamm?

1998-04-28 Thread Hartmut Koptein
 
 There's been a lot of porting going on for Alpha, however, I can't
 really say that the number of packages that need to be ported to Alpha
 has been decreasing since the freeze; every time 20 packages are
 uploaded for Alpha, there are 22 new packages for i386 :-(

Thats the reason for needing more time as two weeks after the deadline!!
Minumum are four weeks!

Bye,

Hartmut

-- 
 Hartmut Koptein   EMail:
 Friedrich-van-Senden-Str. 7   [EMAIL PROTECTED]
 26603 Aurich   
 Tel.: +49-4941-10390  [EMAIL PROTECTED]


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



Re: *** The Upcoming Release of Hamm ***

1998-04-16 Thread Hartmut Koptein
 Can I propose the following ?  When we get into this state we announce
 an `early beta' and delay the release for at least a further two weeks
 to see if any more release-necessary bugs arise, or if there is
 discussion about the status of a bug.

Make it harder! From now on no new upstream versions to frozen. Cleaning
Incoming. 1. May is 'early beta' and 1. June is release time (to have some
more time for arch maintainers and testers). 

Is this to hard?

Bye,

  Hartmut


-- 
 Hartmut Koptein   EMail:
 Friedrich-van-Senden-Str. 7   [EMAIL PROTECTED]
 26603 Aurich   
 Tel.: +49-4941-10390  [EMAIL PROTECTED]


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



Re: GGI first release

1998-01-09 Thread Hartmut Koptein
On Jan 8, James A.Treacy wrote:
 Now that they have something running, one thing I'd like to know
 is how fast it is. Have they done any tests comparing it to
 XFree86?

Or against the video stuff in 2.1'er kernels? Console speed, ...

Thanks,

Hartmut

-- 
 Hartmut Koptein   EMail:
 Friedrich-van-Senden-Str. 7   [EMAIL PROTECTED]
 26603 Aurich   
 Tel.: +49-4941-10390  [EMAIL PROTECTED]


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



Re: New required base packages for Amiga, Atari, ... detection

1997-12-26 Thread Hartmut Koptein
  No, the CPUs are the same in this instance, but the hardware architectures
  are different. The types of programs that need this systen are hardware
 
 I seem to recall that the case in question (it _was_ Atari vs. Amiga,  
 right?) still allowed you to run _the_very_same_kernel_ on both systems.

Yes, but then you have both systems included in one kernel and such kernels
are big. And i don't know if its always possible (as for two or three years).

Bye,

Hartmut



-- 
 Hartmut Koptein   EMail:
 Friedrich-van-Senden-Str. 7   [EMAIL PROTECTED]
 26603 Aurich   
 Tel.: +49-4941-10390  [EMAIL PROTECTED]


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



Re: mgetty Needs Maintainer!

1997-06-09 Thread Hartmut Koptein
 Some time ago, I handed mgetty over to Siggy Brentrup.  However, I
 have not yet seen any mgetty uploaded by him and have not received any
 response to my e-mails.
 
 So...would somebody be willing to take over mgetty?  Right now, it
 doesn't have any maintainer...

Hi,

i will get it; and i think voice should also included. 

Mgetty is with the current state of libc - libc6 a little bit hard to test
it. But we will see ..

Bye,

Hartmut

-- 
 Hartmut Koptein   EMail:
 Friedrich-van-Senden-Str. 7   [EMAIL PROTECTED]
 26603 Aurich   
 Tel.: +49-4941-10390  [EMAIL PROTECTED]


pgpm5waba9Pma.pgp
Description: PGP signature