Re: Faster Release Cycle = More Up to date Packages...

[Junichi Uekawa]

Johnny Ernst Nielsen <[EMAIL PROTECTED]> cum veritate scripsit:

> While you guys get Woody ready, I will try to find out more about the 
> current release procedure and the past of Debian development.
> 
> Hopefully I will see you all again May 2Nd.

Or better, start help fixing bugs now.

You've wasted enough bandwidth, and showed lack of knowledge 
about how the current system works.
Without knowing how the current system works, it is 
futile to suggest/point out how to fix it.


regards,
junichi

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


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

Re: David D.W. Downey - Old Key 42D8F306 Signed by New Key C5A76BF6

[Manoj Srivastava]

>>"Tollef" == Tollef Fog Heen <[EMAIL PROTECTED]> writes:

 Tollef> * Manoj Srivastava 
 David> 4) Posted the NEW public key (C5A76BF6) to the following:
 David> 1) public keyservers
 David> 2) debian-devel@lists.debian.org
 David> 3) Main upstream source site for affected packages
 >> 
 >> Have you done anything that I can't do as well right now? I
 >> mean, I can download your old key, create a new one, and do all you
 >> have outlined?

 Tollef> I would believe you don't have access to put material on
 Tollef> *.codecastle.com?

That does not help us. Who know who has permissions to put
 information there? and may be actively hijacking the key? (Hint:
 substitute ``a potentially malicious third party'' for ``I'' and
 reparse) 

manoj
-- 
 "Once lead the American people into war, and they'll forget there
 ever was such a thing as tolerance.  To fight you must be brutal and
 ruthless, and the spirit of ruthless brutality will enter into every
 fiber of our national life ..." President Woodrow Wilson
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: g++-3.0 library support?

[Junichi Uekawa]

Ulrich Eckhardt <[EMAIL PROTECTED]> cum veritate scripsit:

> However, what we really need is a more generic naming-scheme like
>   -.so

Or more like:

-.so.

Adding compiler version inside the soname would be a
possible, and interesting thing to do, but not something to stuff into
FHS right now.
Adding support for including compiler version/compiler-abi-version
in libtool is the first thing to do, and before that,
a method for determining compiler version and compiler-abi-version
on any compiler.


regards,
junichi

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


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

Re: rsync and debian -- summary of issues

[Robert Tiberius Johnson]

On Fri, 2002-04-12 at 01:47, Martin Pool wrote:
> On 11 Apr 2002, Robert Tiberius Johnson <[EMAIL PROTECTED]> wrote:
> > Also, in section 3.15, you say, "Fetching a series of deltas which
> > update the same area is less efficient than calculating the deltas
> > directly."  This is true, but by my computations, the number of packages
> > which change more than once in a month is 300, which require about 30K
> > of wasted bandwidth. 
> 
> Sorry, I don't understand what the 30kB number relates to.  Is that
> only for the updates to the Packages file?

Yep.  Sorry that wasn't clear before.

I implemented a local version of Goswin Brederlow's proposal to use the
reverse rsync algorithm over HTTP Range requests.  The code is included
below: please look it over to make sure I got the protocol right.

Here's what I found by running the program on some Packages[.gz] files:

Using gzip -9 --rsyncable Packages files from unstable main:
FromTo  blocksize   diskspace   bandwidth
-
Apr 6   Apr 7   128 118K882K
Apr 6   Apr 7   256 59K 841K
Apr 6   Apr 7   512 29K 839K
Apr 6   Apr 7   102415K 875K
Apr 6   Apr 11  128 118K1900K
Apr 6   Apr 11  256 59K 1853K
Apr 6   Apr 11  512 29K 1839K
Apr 6   Apr 11  102415K 1845K

Using uncompressed Packages files from unstable main:
FromTo  blocksize   diskspace   bandwidth
-
Apr 6   Apr 7   256 212K323K
Apr 6   Apr 7   512 106K270K
Apr 6   Apr 7   102453K 292K
Apr 6   Apr 11  128 429K898K
Apr 6   Apr 11  256 215K860K
Apr 6   Apr 11  512 107K985K

For comparison, 5 days of bzip2 -9 compressed diffs take about 60K of
disk space, and updating after one day uses about 13K of bandwidth. 
Updating after 5 days uses 65K of bandwidth.

Best,
Rob

/* Mock-up version of the "checksum file" file synching protocol.
 * 
 * compile with "gcc -lssl gen_csums.c -o gen_csums"
 * 
 * Usage: gen_csums
 *
 * using a checksum size (csize) of < 8 can cause collisions,
 * which will ruin file reconstruction.  This implementation only supports
 * csize of <= 8 to reduce memory usage.  So always use csize=8.
 *
 *  is the file the client has.   is the file
 * the server has.  The program produces the file of checksums (newfile.csums),
 * a file containing the extra data the client had to fetch from the server
 * (oldfile.data), and the result of patching oldfile using the
 * checksums and fetched data (oldfile.merged).
 *
 * It prints out the blocksize, the amount of data that had to
 * be transferred from the server, and whether reconstruction was 
 * successful.
 */


#include 
#include 
#include 
#include 
#include 
#include 
#include 

/* Generate the checksums file for the given file. */
void gen_csums (int bsize, int csize, char* ifilename, char* cfilename)
{
int ifile, cfile;
struct stat s;

char* buf;
char csumbuf[MD5_DIGEST_LENGTH];
MD5_CTX c;

int i;

ifile = open (ifilename, O_RDONLY);
cfile = open (cfilename, O_WRONLY | O_CREAT | O_TRUNC, S_IREAD | 
S_IWRITE);
fstat (ifile, &s);
buf = (char*) malloc (s.st_size);
read (ifile, buf, s.st_size);
close (ifile);

write (cfile, &s.st_size, sizeof (s.st_size));
write (cfile, &bsize, sizeof (bsize));
write (cfile, &csize, sizeof (csize));
MD5 (buf, s.st_size, csumbuf);
write (cfile, csumbuf, sizeof (csumbuf));

for (i = 0; i < s.st_size; i += bsize)
{
MD5 (buf + i, bsize, csumbuf);
write (cfile, csumbuf, csize);
}

free (buf);
close (cfile);
}

/* Merging code */

struct block_info
{
int offset;
char csum[8];
};

int csize = 0;

/* Used for sorting the checksums, and doing binary search
 * on checksums */
int block_info_cmp (void* a, void* b)
{
struct block_info* p1 = (struct block_info*)a;
struct block_info* p2 = (struct block_info*)b;
int r = memcmp (p1->csum, p2->csum, csize);
return r;
}

/* Given:
 *  cfilename - the checksum file
 *  pfilename - the new file on the server
 *  ifilename - our old file
 *  ofilename - the merged file to be created
 *  dfilename - the file extra data is to be logged in
 *
 * use the checksums to fill in as much of the merged file as possible.
 * Then use the pfilename to fill in the rest.  At the end, the file
 * dfilename will contain a copy of all the extra data the client had 

Re: Debian's problems, Debian's future

[Robert Tiberius Johnson]

On Fri, 2002-04-12 at 00:14, Anthony Towns wrote:
> No, I'm not. I'm saying that "the amount of time spent waiting for
> apt-get update" needs to count every apt-get update you run, not just
> the first. So, if over a period of a week, I run it seven times, and you
> run it once, I wait seven times as long as you do, so it's seven times
> more important to speed things up for me, than for you.

Got it.  Thanks for clearing that up.

> Having the "ebwidth" of the current situation (everyone downloads the
> entire Packages file) for comparison would be helpful.

Your right.  Here it is: old_ebwidth = 879K.

Best,
Rob



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

Re: rsync and debian -- summary of issues

[Brian May]

On Fri, Apr 12, 2002 at 01:28:01PM +1000, Martin Pool wrote:
> Why did you think that?
> 
> rproxy addresses a rather different problem to rsync: for example, it
> transfers only one file at a time, not whole directories.  No, rproxy
> does not have a magic way to do the delta computation in zero time.
> Compared to rsync, rproxy has the advantage of cleaner code (imho),
> but the disadvantage that no optimization work has been done.

However, that is exactly what applications like apt-get require:
transfer of one file at a time... And consider the benifits, if it only
did this on Packages and Sources, but nothing else... If implemented in
squid, then the results could be cached at intermediate squid caches,
too. Something that is impossible with rsync.

I always thought though that rproxy, considering it was aimed at being
included in public web servers, would minimize the load on the server.
Perhaps I am mistaken?
-- 
Brian May <[EMAIL PROTECTED]>


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

Re: rsync and debian -- summary of issues

[Brian May]

On Fri, Apr 12, 2002 at 10:19:27PM +1000, Donovan Baarda wrote:
> The big problem with rproxy is it's implemented in perl (perl: crypto for

Are we talking about the same code here?

[502] [snoopy:unstable:bam] ~ >ldd /usr/sbin/rproxy 
libc.so.6 => /lib/libc.so.6 (0x4001e000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000)

/usr/sbin/rproxy: ELF 32-bit LSB executable, Intel 80386, version 1
(SYSV), dynamically linked (uses shared libs), stripped

I believe it has been statically linked with libhsync.
-- 
Brian May <[EMAIL PROTECTED]>


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

Re: Bug#141847: O: dupload -- Utility to upload Debian packages.

[Brian May]

On Fri, Apr 12, 2002 at 01:47:05AM -0400, Colin Walters wrote:
> I like dput's DWIM features.  For example, it figures out automatically
> whether or not a package is in non-US, and uploads to the correct
> place.  

This may not be as much use now non-us is being moved to main...

How does it determine the archive? It might be useful
if it could automatically determine that some packages
should get uploaded to my private archive (because they
can't go in Debian yet for various reasons), and other
packages go to ftp-master.
-- 
Brian May <[EMAIL PROTECTED]>


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

Re: Observation on syslinux/lilo/grub w/rsp to old Toshiba Laptops

[Nick Phillips]

On Fri, Apr 12, 2002 at 02:00:36PM -0500, Chad Walstrom wrote:

> I would agree.  We can't "Be everything to everyone".  I've just
> recently acquired a laptop (my first!).  It's a Toshiba T3400CT, an old
> 486/sx with a whopping 6.5" /color/ LCD! ;-)  I've been able to boot it
> with tomsrtbt, but the debian rescue discs, even the lowmem ones from
> slink, do not work.  DOS boots fine and the NetBSD discs boot as well
> (but I don't fancy a floppy installation).
> 
> At 4 MB of ram and a picky BIOS, my best bet for getting this thing
> installed w/a base Woody installation is to create a custom boot disc
> that mounts an NFS root.  To do so, it has to run pcmcia for the new
> Linksys NIC I purchased for it.

I used to have one of these, I think (actually it may have been a 340
something). But with the colour screen and 4MB RAM. Slink was the *only*
linux I could get onto it. I used a floppy boot & PLIP install.

That's what got me started on Debian.

What fails on yours?

-- 
Nick Phillips -- [EMAIL PROTECTED]
Caution: Keep out of reach of children.


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

Re: Please test this woody cd image

[MH]

Tested a PII - 266 with 192 RAM (1997-8 Siemens Xpert) - bf24 ... successfully 

MH
-- 
(Dr.) Michael Hummel
**
fprint = F24D EAC6 E3D7 372C 9122 D510 EB24 01CA 0B56 B518
id: 1024D/0B56B518 key: http://www.seitung.net/key

pgpVV1XfVkeSE.pgp
Description: PGP signature

Re: Observation on syslinux/lilo/grub w/rsp to old Toshiba Laptops

[Nils Rennebarth]

On Fri, Apr 12, 2002 at 02:00:36PM -0500, Chad Walstrom wrote:
> this particular laptop may not work with anything but a zImage kernel
> (if it has the same problems as the Tecra series)
Those have been resolved by the 2.2 kernel series. 

Nils

--
 __
(Muuuhh)
Global Village Sau  ==>^..^ |/¯
(Kann Fremdsprache) ==>(oo)


pgp0bYxGIlb79.pgp
Description: PGP signature

Re: Please test this woody cd image

[David D.W. Downey]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Friday 12 April 2002 12:49, Matt Zimmerman wrote:
> I tested the isolinux boot image on 3 random workstations (Dell and HP) as
> well as an IBM ThinkPad T21.  All of them worked fine with both idepci and
> bf24 kernels.

Also tried on a PIII-450 i686 + 256MB RAM
Worked fine for me.
- -- 
David D.W. Downey <[EMAIL PROTECTED]>
libpam-pgsql Debian Maintainer && Upstream Source
http://libpam-pgsql.codecastle.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8t0sJJRhrFsWna/YRAvNxAJ4u3PyIamSM057pEdToyquDVkNtoQCeJ98I
vrXW98sypw9sHQgVZBtfbtI=
=6rRX
-END PGP SIGNATURE-


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

Vancouver keysigning request

[Shaun Jackman]

I'm looking for a Debian developer in Vancouver, Canada to sign my key. If 
you fit the bill, please reply!

Thanks,
Shaun Jackman


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

Re: rsync and debian -- summary of issues

[Otto Wyss]

> > 3.1 Compressed files cannot be differenced
> 
> I recall seeing some work done to determine how much savings you could
> expect if you used xdeltas of the uncompressed data. This would be the
> best result you could expect from gzip --rsyncable. I recall the numbers
> were disapointing, it was << 50% on average or somesuch. It would be nice
> if someone could find that email or repeat the experiments.
> 
With the help of an admin from an rsync server I tested the download of
a with "gzip --rsyncable" compressed Packages.gz versus an uncompressed
Packages. The results are under 

"http://lists.debian.org/debian-devel/2001/debian-devel-200106/msg01859.
html"

It just shows 2 days but the test went on for about a week with similar
results. While uncompressed is still the best for rsync download, it
shows a significant reduction (more than 50%) against a normal
compressed Packages.gz. Similar savings are possible if this is applied
to Debian packages.

O. Wyss

-- 
Author of "Debian partial mirror synch script"
("http://dpartialmirror.sourceforge.net/";)


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

Re: Please test this woody cd image

[Matt Zimmerman]

On Fri, Apr 12, 2002 at 03:49:03PM -0400, Matt Zimmerman wrote:

> I tested the isolinux boot image on 3 random workstations (Dell and HP) as
> well as an IBM ThinkPad T21.  All of them worked fine with both idepci and
> bf24 kernels.

Also tried a Compaq Deskpro, both idepci and bf24 worked.

-- 
 - mdz


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

Re: Please test this woody cd image

[Matt Zimmerman]

I tested the isolinux boot image on 3 random workstations (Dell and HP) as
well as an IBM ThinkPad T21.  All of them worked fine with both idepci and
bf24 kernels.

-- 
 - mdz


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

Re: rsync and debian -- summary of issues

[Matt Zimmerman]

On Fri, Apr 12, 2002 at 06:19:07PM +1000, Martin Pool wrote:

> What I'd really like is to have access to one of these machines and be
> able to attach debuggers to rsync and see what it's doing.  (In this case,
> that would mean being able to ssh in as 'nobody', or something
> equivalent.)  I realize there might be some security difficulties with
> doing that, but if we can get past them it would be good for rsync, and
> hopefully also for Debian.  If direct access is impossible then maybe
> somebody who can ssh to the machine can work with me.

I would be glad to help you with this, but I think that human-proxying gdb
is not the easiest way to do it.  It is quite easy to create a reasonable
facsimile of our environment; in fact, you can purchase a large chunk of it
on CD-ROM for around US$5, and download the rest from a nearby mirror.  All
that is necessary is a server with sufficient bandwidth, and then we can
avoid involving Debian's production servers at all.

-- 
 - mdz


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

Re: Please test this woody cd image

[Shyamal Prasad]

Shyamal> The issue I wanted to highlight was that a bf 3.0.19
Shyamal> based netinst ISO works great on this
Shyamal> machine(http://people.debian.org/~ieure/netinst) with all
Shyamal> the syslinux features (I can choose a kernel, hit F3 for
Shyamal> help, etc.).

Ummm...I may be talking through my hat here. Maybe I couldn't choose a
kernel, but it *did* boot. To the first image.I'll have to check
when I get back home how much control I had

/Shyamal


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

Observation on syslinux/lilo/grub w/rsp to old Toshiba Laptops

[Chad Walstrom]

(Removed cross-post to debian-boot, since I'm not on that list).

On Fri, Apr 12, 2002 at 12:42:10PM -0500, Branden Robinson wrote:
> Also, PGI currently uses syslinux and will continue to do past its 1.0
> release.  PGI works on i386, of course, and may be a good candidate
> for legacy hardware support when the official Debian installer can't
> bend over backwards that far anymore.  (PGI does not, however, support
> floppy-disk-based installs.)

I would agree.  We can't "Be everything to everyone".  I've just
recently acquired a laptop (my first!).  It's a Toshiba T3400CT, an old
486/sx with a whopping 6.5" /color/ LCD! ;-)  I've been able to boot it
with tomsrtbt, but the debian rescue discs, even the lowmem ones from
slink, do not work.  DOS boots fine and the NetBSD discs boot as well
(but I don't fancy a floppy installation).

At 4 MB of ram and a picky BIOS, my best bet for getting this thing
installed w/a base Woody installation is to create a custom boot disc
that mounts an NFS root.  To do so, it has to run pcmcia for the new
Linksys NIC I purchased for it.

But like Brandon said, this is a great example of a legacy hardware
setup that we can simply not support as default.  Also considering that
this particular laptop may not work with anything but a zImage kernel
(if it has the same problems as the Tecra series), it really wouldn't
fall into the "default" category.

BTW, I'll let you know how it goes. ;-)  If anyone has suggestions or
ideas that might help me get this little sucker fired up, I'm all ears.

-- 
Chad Walstrom <[EMAIL PROTECTED]> | a.k.a. ^chewie
http://www.wookimus.net/| s.k.a. gunnarr


pgpUPOlaPhCrQ.pgp
Description: PGP signature

Re: Please test this woody cd image

[Shyamal Prasad]

Mike> On Fri, Apr 12, 2002 at 08:38:00AM -0500, Shyamal Prasad
Mike> wrote:
>> It failed to boot an IBM Aptiva 2161-C8E desktop with a
>> 1/19/1997 BIOS. This 166Mhz Pentium box has been my trusty
>> machine for 5 years, and boots the potato r3 CD and also
>> another woody netinst ISO (the one

Mike> Well, I guess the question is do we want to support new
Mike> machines or old machines; it doesn't seem that we can do
Mike> both. (I'd vote for the former because we need to move
Mike> forward, and it's not like we're removing the floppy boot
Mike> option.)

No disagreement there. I don't mind if my old PC doesn't boot off the
first CD, and I'm all for better support for new hardware.

The issue I wanted to highlight was that a bf 3.0.19 based netinst ISO
works great on this machine(http://people.debian.org/~ieure/netinst)
with all the syslinux features (I can choose a kernel, hit F3 for
help, etc.).

However, the image Raphael requested testing for does not.

What'd done differently? 

I'm not boot expert, but it seems possible that a small change might
make this CD more usable on a wider range of machines (since I have
found at least on syslinux based CD that does work). My machine is
old, but not "unmodern" - it's got PCI and USB support, has booted
every other CD I've ever come across, and has the right horse power to
make a good Linux machine.

I'm at work and I can't look at my CD, so if I got some detail wrong
don't shoot me.

Cheers from the ingoramus!
Shyamal


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

Re: Please test this woody cd image

[Branden Robinson]

On Fri, Apr 12, 2002 at 09:48:36AM -0400, Michael Stone wrote:
> On Fri, Apr 12, 2002 at 08:38:00AM -0500, Shyamal Prasad wrote:
> > It failed to boot an IBM Aptiva 2161-C8E desktop with a 1/19/1997
> > BIOS. This 166Mhz Pentium box has been my trusty machine for 5 years,
> > and boots the potato r3 CD and also another woody netinst ISO (the one
> 
> Well, I guess the question is do we want to support new machines or old
> machines; it doesn't seem that we can do both. (I'd vote for the former
> because we need to move forward, and it's not like we're removing the
> floppy boot option.)

Also, PGI currently uses syslinux and will continue to do past its 1.0
release.  PGI works on i386, of course, and may be a good candidate for
legacy hardware support when the official Debian installer can't bend
over backwards that far anymore.  (PGI does not, however, support
floppy-disk-based installs.)

There's more information about PGI at .

-- 
G. Branden Robinson| One man's "magic" is another man's
Debian GNU/Linux   | engineering.  "Supernatural" is a
[EMAIL PROTECTED] | null word.
http://people.debian.org/~branden/ | -- Robert Heinlein


pgpCPls6ihkf2.pgp
Description: PGP signature

Re: Please test this woody cd image

[Paul Slootman]

On Fri 12 Apr 2002, Daniel Burrows wrote:

>   Just a note: I'm sure everyone will be disappointed to hear that the
> isolinux CD does not boot in bochs ;-)

Wel, it boots just fine in VMware 3.0 (which basically uses a Phoenix
BIOS).

What package does the apt source selection belong to? Because I chose
"Netherlands" and then http, "ftp.surfnet.nl" but that gave 404 errors.
ftp.snt.utwente.nl works fine.


Paul Slootman


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

Re: [2002-04-06] Release Status Update

[Keith G. Murphy]

Paul Slootman wrote:
> 
> On Thu 11 Apr 2002, Keith G. Murphy wrote:
> > Bernd Eckenfels wrote:
> > >
> > > On Thu, Apr 11, 2002 at 10:18:08AM +0200, Russell Coker wrote:
> > > > You only need pptp-linux if you use an Ethernet attached modem instead 
> > > > of the
> > > > USB attached modem (which is E50 cheaper).
> > >
> > > This does not make sence at all. PPTP is also a WAN Tunneling and VPN
> > > Protocol. How can a Linux Router speek PPTP without linux-pptp package? 
> > > This
> > > is a often used VPN Solution to Windows servers. And if there is no bug, 
> > > it
> > > is not a good idea to remove the package.
> > >
> > Do ya think they're talking about PPPOE, rather than pptp?  It would
> > make more sense in that context...
> 
> No, he's right; at least, the part about VPN is correct.
> 
> Russell was speaking in the context of the common ADSL offering here in
> the Netherlands, where an Alcatel ADSL modem is commonly used. You have
> to speak PPTP to that modem, unless you can hack it (see earlier
> discussion). 

Oh, OK, sorry to shed more obscurity on the issue.  I just now searched
groups.google.com, and noticed another discussion about this issue:

http://groups.google.com/groups?hl=en&selm=EtSTNbljddDU-pn2-g7tGhLXjwmmM%40POBLANO.hashkedim.com

At least you didn't get irritated!  :-)

It was just hard for me to believe you needed PPTP to talk to an ADSL
modem!


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

Re: Please test this woody cd image

[Drew Parsons]

On Thu, Apr 11, 2002 at 06:40:17PM -0700, John H. Robinson, IV wrote:
> On Fri, Apr 12, 2002 at 11:35:31AM +1000, Drew Parsons wrote:
> > On Thu, Apr 11, 2002 at 01:38:14PM -0600, Erik Andersen wrote:
> > ...
> > > I just tested it on all the bootable x86 systems in my house:
> > ...
> > > Toshiba 490CDT Satellite Pro Laptop: Works
> > 
> > That's good news.  What was your success booting the Potato CD on this
> > laptop?
> 
> i booted it on my toshiba 330cds laptop,and it worked fine.  i test
> booted into bf24 and idepci.
> 
> and yes, this model worked with the 2.88 el torito images, too :)
> 

Oh OK.  Maybe it's just my laptop that fails then :)  Though I seem to
recall some other people with Toshiba laptops were having problems booting
from CD when potato was released.

Drew

-- 
PGP public key available at http://people.debian.org/~dparsons/drewskey.txt
Fingerprint: A110 EAE1 D7D2 8076 5FE0  EC0A B6CE 7041 6412 4E4A


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

Re: dput says "size doesn't match"

[Daniel Burrows]

On Fri, Apr 12, 2002 at 04:50:31PM +0200, Jochen Voss <[EMAIL PROTECTED]> was 
heard to say:
> [EMAIL PROTECTED] [~/devel] dput sanduhr_1.0-1_i386.changes 
> Uploading package to host ftp-master.debian.org
> D: /home/debian/devel/sanduhr_1.0-1_i386.changes
> Checking Signature on .changes
> gpg: Signature made Fri Apr 12 16:40:59 2002 CEST using DSA key ID 
> 211B1025
> gpg: Good signature from "Jochen Voss <[EMAIL PROTECTED]>"
> gpg: aka "Jochen Voss <[EMAIL PROTECTED]>"
> gpg: aka "Jochen Voss <[EMAIL PROTECTED]>"
> gpg: aka "Jochen Voss <[EMAIL PROTECTED]>"
> gpg: aka "Jochen Voss <[EMAIL PROTECTED]>"
> Good signature on /home/debian/devel/sanduhr_1.0-1_i386.changes.
> Checking Signature on .dsc
> gpg: Signature made Fri Apr 12 16:40:55 2002 CEST using DSA key ID 
> 211B1025
> gpg: Good signature from "Jochen Voss <[EMAIL PROTECTED]>"
> gpg: aka "Jochen Voss <[EMAIL PROTECTED]>"
> gpg: aka "Jochen Voss <[EMAIL PROTECTED]>"
> gpg: aka "Jochen Voss <[EMAIL PROTECTED]>"
> gpg: aka "Jochen Voss <[EMAIL PROTECTED]>"
> Good signature on /home/debian/devel/sanduhr_1.0-1.dsc.
> --> size doesn't match for /home/debian/devel/sanduhr_1.0.orig.tar.gz
> Package is now being checked with lintian.
> [...]
> Successfully uploaded packages.
> Not running dinstall.
> 
> I'm somewhat worried about the "size doesn't match" message.  Does
> this indicate a problem?  I checked the mentioned .orig.tar.gz file
> and it is not corrupted.

  If the .orig.tar.gz is a symlink, see #138821.

  Daniel

-- 
/ Daniel Burrows <[EMAIL PROTECTED]> ---\
|  Wisdom is one of the few things|
|  that looks bigger the farther away it is.  |
|-- Terry Pratchett   |
\ Be like the kid in the movie!  Play chess! -- http://www.uschess.org ---/


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

Re: Please test this woody cd image

[Daniel Burrows]

  Just a note: I'm sure everyone will be disappointed to hear that the
isolinux CD does not boot in bochs ;-)

  Daniel

-- 
/ Daniel Burrows <[EMAIL PROTECTED]> ---\
| "Note that fires are not restricted to dormitories. |
|  Indeed, fire can occur in off-campus residences as well."  |
|   -- Brown University Fire Safety Guide |
\- Got APT? -- Debian GNU/Linux http://www.debian.org /


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

Re: Please test this woody cd image

[Daniel Burrows]

On Thu, Apr 11, 2002 at 08:31:55PM +1000, Anthony Towns 
 was heard to say:
> Additionally, it's very easy to test: find random systems, reboot them
> with the small CD Raphael's prepared and check you can get into the
> installer. You don't need to go all the way through the install, nor
> worry about damaging your system at all -- as soon as you get to the
> pretty installer screens, you're done.

  Works here.  (this is a newish system I built myself, with an Abit
motherboard and a flaky Iomega CD-R drive)  I'll try it on some friends'
systems later today, assuming they don't run and hide when they see me
coming with a CD :)

  I even went through most of the install process, nearly giving myself
a heart attack when I rebooted and /home was missing.  (the partition
numbers shifted around when I ran fdisk, apparently; adjusting fstab fixed
that)

  I'll assume there's a good reason for using the kernel framebuffer in
the bf2.4 disks (it was very slow on my computer), but (at the risk of
inviting a massive flamewar) I'm wondering whether it might be a good idea
for the default language to be English?  I don't know how the userbase
is distributed, but if it resembles the distribution of developers at
all, most people will want to have an English (or maybe German) installation.
  (some fraction of people, regardless of nationality, will just
   hit Enter reflexively at the language selection screen, and making the
   default the most widely understood language [0] will minimize the total
   amount of confusion generated)

  Daniel

  [0] whatever that is; my impression is that it is some en_*, but
  whatever.

-- 
/ Daniel Burrows <[EMAIL PROTECTED]> ---\
|  You are in a maze of twisty little signatures, all alike.  |
\ News without the $$ -- National Public Radio -- http://www.npr.org /


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

dput says "size doesn't match"

[Jochen Voss]

Hello,

my latest upload with dput resulted in the following
output.

[EMAIL PROTECTED] [~/devel] dput sanduhr_1.0-1_i386.changes 
Uploading package to host ftp-master.debian.org
D: /home/debian/devel/sanduhr_1.0-1_i386.changes
Checking Signature on .changes
gpg: Signature made Fri Apr 12 16:40:59 2002 CEST using DSA key ID 211B1025
gpg: Good signature from "Jochen Voss <[EMAIL PROTECTED]>"
gpg: aka "Jochen Voss <[EMAIL PROTECTED]>"
gpg: aka "Jochen Voss <[EMAIL PROTECTED]>"
gpg: aka "Jochen Voss <[EMAIL PROTECTED]>"
gpg: aka "Jochen Voss <[EMAIL PROTECTED]>"
Good signature on /home/debian/devel/sanduhr_1.0-1_i386.changes.
Checking Signature on .dsc
gpg: Signature made Fri Apr 12 16:40:55 2002 CEST using DSA key ID 211B1025
gpg: Good signature from "Jochen Voss <[EMAIL PROTECTED]>"
gpg: aka "Jochen Voss <[EMAIL PROTECTED]>"
gpg: aka "Jochen Voss <[EMAIL PROTECTED]>"
gpg: aka "Jochen Voss <[EMAIL PROTECTED]>"
gpg: aka "Jochen Voss <[EMAIL PROTECTED]>"
Good signature on /home/debian/devel/sanduhr_1.0-1.dsc.
--> size doesn't match for /home/debian/devel/sanduhr_1.0.orig.tar.gz
Package is now being checked with lintian.
[...]
Successfully uploaded packages.
Not running dinstall.

I'm somewhat worried about the "size doesn't match" message.  Does
this indicate a problem?  I checked the mentioned .orig.tar.gz file
and it is not corrupted.

Jochen
-- 
http://www.mathematik.uni-kl.de/~wwwstoch/voss/


pgpqFHlqSBQzV.pgp
Description: PGP signature

it is now possible to help debian/openbsd

[Andreas Schuldei]

On http://pandora.debian.org/~andreas/obsd are the tools needed
for creating debian packages of software on openbsd. 

As stated vaguely half a century earlier, I would like to create a
secure debian/gnu/openbsd with the best of both worlds. For that
I would now begin to package the openbsd source tree and slowly 
transform it to follow policy. 

This will go faster and will be more fun (yay!) if more then one
person works on it. So download those tools, install them and
debianize your openbsd box! Get back to me with questions so some
basic FAQ can be written.


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

Re: Please test this woody cd image

[Michael Stone]

On Fri, Apr 12, 2002 at 08:38:00AM -0500, Shyamal Prasad wrote:
> It failed to boot an IBM Aptiva 2161-C8E desktop with a 1/19/1997
> BIOS. This 166Mhz Pentium box has been my trusty machine for 5 years,
> and boots the potato r3 CD and also another woody netinst ISO (the one

Well, I guess the question is do we want to support new machines or old
machines; it doesn't seem that we can do both. (I'd vote for the former
because we need to move forward, and it's not like we're removing the
floppy boot option.)

-- 
Mike Stone


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

Re: Please test this woody cd image

[Shyamal Prasad]

"Anthony" == Anthony Towns  writes:

Anthony> Seriously: everyone reading this mail, burn a copy of
Anthony> Raphael's test image on a CD and try booting it in any
Anthony> computers you have handy. If it doesn't work on a machine
Anthony> where a potato CD does boot, please mail the lists!

It failed to boot an IBM Aptiva 2161-C8E desktop with a 1/19/1997
BIOS. This 166Mhz Pentium box has been my trusty machine for 5 years,
and boots the potato r3 CD and also another woody netinst ISO (the one
found starting at www.debian.org, based on boot floppies 3.0.19 and
downloaded from http://people.debian.org/~ieure/netinst, which is also
SYSLINUX based and it works great on this machine).

Anyone clue me into why my IBM won't boot this CD?

Raphael's ISO works boots up just great on a Compaq Armada M300
laptop, and my Soyo Dragon+ based desktop (Award BIOS, KT266A, which
also works with Raphael's multiboot images).

Cheers!
Shyamal


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

[광고]debian-devel님 안녕하십니까?

[샤프론]

Title: Untitled Document





   

  원치않는 메일을 받으셨다면 정말로 죄송합니다. 귀하의 메일주소는 인터넷 상의 공개된 메일 주소를 근거로 발송하였으며 E-Mail 
주소 외에, 다른 정보는 갖고 있지 않습니다. 정통부 권고사항에 의거 제목에 [광고]라고 표기한 메일입니다. 원치 않으면 수신거부를 
눌러주세요. 
  ♣ 샤프론이 제공하는 오늘의 날씨정보 ♣



  
  

  
 
  
  
  

  

  



   
 
 


  
   




  
   




  
   
 
 
  
 
  
   
   

  
  
  

▶ 제 품 명 : 바레미소 7175 Set 
  ▶ 제품구성 : 바레미소250㎖(스프레이+비닐버선) 
  ▶ 보건복지부허가 제120호 
  ▶ 제 조 원 : (주)마리랑스 
  ▶ 발명특허출원번호 : 10-2000-0056339 
  

  
  
 
   

 
   
▶ 효과 : 짓무름, 수포물집, 각질, 
  트고 갈라짐, 손 발(톱) 가려움, 발냄새

 ① 무좀균, 감염, 짓무른 표피,각질 연화로 제거를 용이하게 해줍니다.
  ② 획기적인 침지요법 7회로 향후 재발가능 성은 거의 희박합니다. 
  ③ 제습~보습의 수분 밸런스를 콘트롤 해줍니다. 
  ④ 식물성 에센스 영양성분에 의해 보송보송 하고 부드러운 피부로 변화 시켜줍니다.
  
  * 스프레이형 신발소독제 : 무좀균 및 각종세균의 항균 탈취 효과로 재발방지
  ① 세균의 집중서식처인 눅눅한 신발소독의 살균탈취로 발 주변환경을 더욱 청결하게 해줍니다. 
  ② 바레미소 사용과 신발 소독을 함께 사용함으로 발냄새 및 재발을 더욱 확실하게 차단시켜줍니다. 
  
  * 청결한 신발 소독 
  * 더욱 확실한 재발 방지효과 
※ 땀에 의해 항상 눅눅한 발과 장시간 물에 젖어있는 주부들의 손 질환에도 
  사용하면 좋습니다.
  


   


  

  

  
  

 
  
   



  

Re: Bug#141847: O: dupload -- Utility to upload Debian packages.

[Steve Langasek]

On Fri, Apr 12, 2002 at 01:47:05AM -0400, Colin Walters wrote:
> On Thu, 2002-04-11 at 20:53, Brian May wrote:
> > On Tue, Apr 09, 2002 at 09:40:47AM +0100, Julian Gilbey wrote:
> > > I am happy to take it.  But a question: with the more actively
> > > maintained dput now being quite mature, do we still need both dupload
> > > and dput?

> > Dumb question, but what dput, and why is one better then the other?
> > (please leave language flame wars out of discussion - we all know that
> >  is the best language).

> I like dput's DWIM features.  For example, it figures out automatically
> whether or not a package is in non-US, and uploads to the correct
> place.  

Works great, except the time I was trying to move a package to main from 
non-US as part of the crypto-in-main rollout, and dput sent the package 
to non-US even though the section listed in the local package clearly 
didn't point there. :)

Steve Langasek
postmodern programmer


pgpkVO3gGVFSN.pgp
Description: PGP signature

Re: David D.W. Downey - Old Key 42D8F306 Signed by New Key C5A76BF6

[christophe barbé]

On Fri, Apr 12, 2002 at 11:02:15AM +0200, Tollef Fog Heen wrote:
> * Manoj Srivastava 
> 
> |  David> 4) Posted the NEW public key (C5A76BF6) to the following:
> |  David> 1) public keyservers
> |  David> 2) debian-devel@lists.debian.org
> |  David> 3) Main upstream source site for affected packages
> | 
> | Have you done anything that I can't do as well right now? I
> |  mean, I can download your old key, create a new one, and do all you
> |  have outlined?
> 
> I would believe you don't have access to put material on
> *.codecastle.com?

Tollef, do you consider write access to *.codecastle.com as a kind of
authentification ?

Christophe

> 
> -- 
> Tollef Fog Heen
> Unix _IS_ user friendly... It's just selective about who its friends are.
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
Christophe Barbé <[EMAIL PROTECTED]>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E

Ce que l'on conçoit bien s'énonce clairement,
Et les mots pour le dire arrivent aisément.
   Nicolas Boileau, L'Art poétique


pgpss5h8ayXuA.pgp
Description: PGP signature

Re: Kindly Get Back To Me Please

[Vince Mulhollon]

Why hello, republic of Angola.  I got your email address off your website
http://www.angola.org/

Here's a deal for you, your military can track down this rebel and kill
them, then we'll split the money.

Is that a good deal or what?  I'll even give you your share paid in
valuable "Enron" stock.

- Forwarded by Vince Mulhollon/Brookfield/Norlight on 04/12/2002 08:01
AM -

   
  "Sandra Savimbi"  
   
  <[EMAIL PROTECTED]To:   
debian-devel@lists.debian.org 
  .com>cc:   (bcc: Vince 
Mulhollon/Brookfield/Norlight)
   Fax to:  
   
  04/12/2002 07:48 Subject:  Kindly Get Back To Me 
Please  
  AM
   
  Please respond to 
   
  nnengi_sam
   

   

   




ATTN:

This letter may come to you as a surprise due to the fact that we have not
yet met. The message could be strange but reel if you pay some attention to
it. I could have notified you about it at least for the sake of your
integrity. Please accept my sincere apologies. In bringing this message of
goodwill to you, I have to say that I have no intentions of causing you any
pains.

I am Ms. Nnengi savimbi, daughter of the late rebel leader Jonas savimbi of
Angola who was killed on the 22nd of febuary 2002 . I managed to get your
contact details through "The World Business Journal", a journal of the
Johannesburg Chamber of Commerce in South Africa in the time I was
desperately looking for a trustworthy person to assist me in this
confidential business.

my late father, Jonas savimbi  was able to deposit a large sum of money in
differnt banks in europe My father is presently death and the movement  of
his family members (including me) is restricted. We are forbidden to either
travel abroad or out of our localities. Presently, the US$8,500,000.00
EIGHT, MILLION, FIVE HUNDRED DOLLARS my father transfered  to Netherlands
is safe and is in a security firm. Before you can get access to it i have
to give you the password  I am  therefore soliciting your help to have this
money  transfered into your account.  before my government get wind of this
fund .You know my father was a rebel leader in Angola before his death  My
reason for  doing this is because it will be difficult for the  Angolan
government to trace my father's money to an individual's account,
especially when such an individual has no relationship ,I decided to keep
that money for my family use. At present the money is
kept in a Security Company in nertherland.

I am currently and temporarily living in Angola with my husband my brother
has a refugee status'in The Netherlands. Moreover the political climate in
Angola at the moment being so sensitive and unstable.With this password and
information I will send to you, and power of attorney to the security firm,
When you are ready i will give you the information needed before you can
get access to the fund you will then proceed to Netherlands where the
US$8,500,000.00 EIGHT, MILLION, FIVE HUNDRED DOLLARS will be given to you
as payment. Alternatively, you can have the fund  transferred into any
account that suits you.

Yours sincerely,

Nnengi Savimbi.


See Dave Matthews Band live or win a signed guitar
http://r.lycos.com/r/bmgfly_mail_dmb/http://win.ipromotions.com/lycos_020201/splash.asp



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




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

Kindly Get Back To Me Please

[Sandra Savimbi]

ATTN:

This letter may come to you as a surprise due to the fact that we have not yet 
met. The message could be strange but reel if you pay some attention to it. I 
could have notified you about it at least for the sake of your integrity. 
Please accept my sincere apologies. In bringing this message of goodwill to 
you, I have to say that I have no intentions of causing you any pains.

I am Ms. Nnengi savimbi, daughter of the late rebel leader Jonas savimbi of 
Angola who was killed on the 22nd of febuary 2002 . I managed to get your 
contact details through "The World Business Journal", a journal of the 
Johannesburg Chamber of Commerce in South Africa in the time I was desperately 
looking for a trustworthy person to assist me in this confidential business.

my late father, Jonas savimbi  was able to deposit a large sum of money in 
differnt banks in europe My father is presently death and the movement  of his 
family members (including me) is restricted. We are forbidden to either travel 
abroad or out of our localities. Presently, the US$8,500,000.00 EIGHT, MILLION, 
FIVE HUNDRED DOLLARS my father transfered  to Netherlands is safe and is in a 
security firm. Before you can get access to it i have to give you the password  
I am  therefore soliciting your help to have this money  transfered into your 
account.  before my government get wind of this fund .You know my father was a 
rebel leader in Angola before his death  My reason for  doing this is because 
it will be difficult for the  Angolan government to trace my father's money to 
an individual's account, especially when such an individual has no relationship 
,I decided to keep that money for my family use. At present the money is
kept in a Security Company in nertherland.

I am currently and temporarily living in Angola with my husband my brother has 
a refugee status'in The Netherlands. Moreover the political climate in Angola 
at the moment being so sensitive and unstable.With this password and 
information I will send to you, and power of attorney to the security firm, 
When you are ready i will give you the information needed before you can get 
access to the fund you will then proceed to Netherlands where the 
US$8,500,000.00 EIGHT, MILLION, FIVE HUNDRED DOLLARS will be given to you as 
payment. Alternatively, you can have the fund  transferred into any account 
that suits you.

Yours sincerely,

Nnengi Savimbi.


See Dave Matthews Band live or win a signed guitar
http://r.lycos.com/r/bmgfly_mail_dmb/http://win.ipromotions.com/lycos_020201/splash.asp
 


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

Re: sid: libc6-2.2.5-4 kills vmware workstation 3.0

[Tollef Fog Heen]

* Jeroen Dekkers 

| Software always used to be free. That changed, but RMS didn't
| change. I don't what software he used to write parts of GNU, but it
| could have been free, there was enough free software at time. Oh, and
| 1) the Hurd isn't a kernel 2) RMS has never written anything of
| it AFAIK.

Then perhaps you should stop comparing Linux and the Hurd, since one
is a kernel and the other is becoming a full operating system.

| No, because it's unavoidable to have a non-free BIOS, read just what I
| said.

You didn't look very hard, did you?

http://www.acl.lanl.gov/linuxbios/

-- 
Tollef Fog Heen
Unix _IS_ user friendly... It's just selective about who its friends are.


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

Re: Imp 3.0/3.1 debian packages?

[Ola Lundqvist]

On Fri, Apr 12, 2002 at 11:22:45AM +0200, Tomas Pospisek's Mailing Lists wrote:
> On Thu, 11 Apr 2002, Luis Bustamante wrote:
> 
> > On Thu, Apr 11, 2002 at 12:18:42PM +0300, Pasi Kärkkäinen wrote:
> > > What's the status of newer imp packages for woody/sid?
> >
> > Beta packages can be found at:
> > http://tabaluga.ipe.uni-stuttgart.de/~nils/download/
> 
> Is there any problem you're aware of with those packages or are they beta
> because they have not been deployed much yet? (Basically my question is -
> why are they beta). Please feel free to ignore my question if you think
> it's a waste of time to reply.
> *t

There are some minor issues that is about to be fixed. When they
have been fixed it will be released by the new maintainer. According
to the new maintainer (not me this time) it will be done this
weekend (if he can catch enough time).

Regards,

// Ola

> 
> 
>  Tomas Pospisek
>SourcePole   -  Linux & Open Source Solutions
>http://sourcepole.ch
>Elestastrasse 18, 7310 Bad Ragaz, Switzerland
>Tel: +41 (81) 330 77 11
> 
> 
> 
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
 - Ola Lundqvist ---
/  [EMAIL PROTECTED] Björnkärrsgatan 5 A.11   \
|  [EMAIL PROTECTED] 584 36 LINKÖPING |
|  +46 (0)13-17 69 83  +46 (0)70-332 1551   |
|  http://www.opal.dhs.org UIN/icq: 4912500 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---


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

Re: rsync and debian -- summary of issues

[Donovan Baarda]

On Fri, Apr 12, 2002 at 01:28:01PM +1000, Martin Pool wrote:
> On 12 Apr 2002, Brian May <[EMAIL PROTECTED]> wrote:
> 
> > I think some more details is required regarding rproxy.
[...]
> > AFAIK, it solves all the problems regarding server load discussed in
> > rsync, doesn't it???
> 
> Why did you think that?
> 
> rproxy addresses a rather different problem to rsync: for example, it
> transfers only one file at a time, not whole directories.  No, rproxy
> does not have a magic way to do the delta computation in zero time.
> Compared to rsync, rproxy has the advantage of cleaner code (imho),
> but the disadvantage that no optimization work has been done.

The big problem with rproxy is it's implemented in perl (perl: crypto for
algorithms). librsync on the other hand is a nice piece of work and _should_
be used for a re-implementation of rproxy and/or rsync.

I have recently got sponsorship to add a python front-end to librsync as an
extension to my pysync code, which I should have done by end of next week.
After this I will probably do some work on adding rproxy http extensions
into something like medusa or twisted.

If rproxy includes the signature in a HEAD responce, and supports ranged
requests, delta calculation can be moved to the client with no changes to
rproxy as follows;

1) client sends HEAD request to get upstream signature.
2) client does reverse-delta calculation.
3) client applies reverse-delta using ranged-requests to fetch required
parts from upstream.

You touched on this in your page, but not in relation to rproxy. I believe
the client-side delta stuff you mentioned was not using rproxy http
extensions at all, just adding some sort of cgi that returns signatures for
objects on the server.

-- 
--
ABO: finger [EMAIL PROTECTED] for more info, including pgp key
--


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

Re: Bug#141847: O: dupload -- Utility to upload Debian packages.

[Josip Rodin]

On Fri, Apr 12, 2002 at 01:47:05AM -0400, Colin Walters wrote:
> > > I am happy to take it.  But a question: with the more actively
> > > maintained dput now being quite mature, do we still need both dupload
> > > and dput?
> > 
> > Dumb question, but what dput, and why is one better then the other?
> > (please leave language flame wars out of discussion - we all know that
> >  is the best language).
> 
> I like dput's DWIM features.  For example, it figures out automatically
> whether or not a package is in non-US, and uploads to the correct
> place.  

The next version of dupload will do the same, it's easy to implement :)

-- 
 2. That which causes joy or happiness.


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

Re: David D.W. Downey - Old Key 42D8F306 Signed by New Key C5A76BF6

[Tollef Fog Heen]

* Manoj Srivastava 

|  David> 4) Posted the NEW public key (C5A76BF6) to the following:
|  David>   1) public keyservers
|  David>   2) debian-devel@lists.debian.org
|  David>   3) Main upstream source site for affected packages
| 
|   Have you done anything that I can't do as well right now? I
|  mean, I can download your old key, create a new one, and do all you
|  have outlined?

I would believe you don't have access to put material on
*.codecastle.com?

-- 
Tollef Fog Heen
Unix _IS_ user friendly... It's just selective about who its friends are.


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

Re: Orphaned packages in testing which were never in stable

[Ola Lundqvist]

Hi

On Mon, Apr 08, 2002 at 11:53:00AM -0400, Michael Stone wrote:
> On Mon, Apr 08, 2002 at 01:08:10AM +0100, Mark Brown wrote:
> > I have this sneaking suspicion that we need a tool more appropriate than
> > the BTS to handle the WNPP.  The BTS seems rather fragile for this
> > purpose - the format for bug titles and to a greater extent the way
> > followups for bug reports are handled (not going to the bug sumbitter)
> > both seem rather fragile and aren't really handled all that well by the
> > mechanisms normally used when interacting with the BTS.
> 
> Yes. Using the BTS for this purpose is ridiculously complicated, far
> from intuitive, and prone to breakage. If only someone were to write
> something better. :)

One solution is to have four separate wnpp packages so you
can reassign them instead of retitle it. It is at least a bit
more intuitive and a bit less error prone.

If should be fairly easy to convert from wnpp to o, ita, rfp and rfa.

Regards,

// Ola

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

-- 
 - Ola Lundqvist ---
/  [EMAIL PROTECTED] Björnkärrsgatan 5 A.11   \
|  [EMAIL PROTECTED] 584 36 LINKÖPING |
|  +46 (0)13-17 69 83  +46 (0)70-332 1551   |
|  http://www.opal.dhs.org UIN/icq: 4912500 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---


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

Re: sid: libc6-2.2.5-4 kills vmware workstation 3.0

[Wilmer van der Gaast]

Jeroen [EMAIL PROTECTED]@Tue, 9 Apr 2002 19:29:14 +0200:
>  What is wrong with telling him that the kind of problems he's having
>  is normal with non-free software and say that there are 2 free
>  alternatives in Debian which would probably not have those problems?
>  
The problem with those solutions is that they are slow. Not yet
complete. Unusable.

What if Plex86 and Bochs did not exist, you'd probably suggest him to
use DosEmu?

-- 
*=-+-__
   |[EMAIL PROTECTED]: _ Ugh! Nio2f says something: __
   : http://www.lintux.cx/ |/ software ars an debiand of proble \
~~-+-=-+~+-=*


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

Bug#142505: ITP: liblog-agent-logger-perl -- Application-level logging interface framework for perl

[ARAKI Yasuhiro]

Package: wnpp
Version: N/A; reported 2002-04-12
Severity: wishlist

* Package name: liblog-agent-logger-perl
  Version : 0.1.1
  Upstream Author : Raphael Manfredi <[EMAIL PROTECTED]>
* URL : 
http://search.cpan.org/doc/RAM/Log-Agent-Logger-0.1.1/Logger.pm 
* License : the Artistic License
  Description : The Log::Agent::Logger module is an extension of 
Log::Agent that brings an application-level logging API.




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

Re: Please test this woody cd image

[Thimo Neubauer]

On Fri, Apr 12, 2002 at 10:33:19AM +0200, Michael Piefel wrote:
> Am 11.04.02 um 20:31:55 schrieb Anthony Towns:
> > Seriously: everyone reading this mail, burn a copy of Raphael's test image
> > on a CD and try booting it in any computers you have handy.
> 
> Complete install success on an IBM Thinkpad A30.

I just test booted an IBM Thinkpad A21p and a Dell Inspiron 8100, both
work. For the latter isolinux is a great advantage because the BIOS
knows how to boot CDs but not how to deal with multiple boot images...

CU
Thimo

-- 
Thimo Neubauer <[EMAIL PROTECTED]>
Debian GNU/Linux 3.0 frozen! See http://www.debian.org/ for details


pgpJts1s1MWDS.pgp
Description: PGP signature

Re: Imp 3.0/3.1 debian packages?

[Tomas Pospisek's Mailing Lists]

On Thu, 11 Apr 2002, Luis Bustamante wrote:

> On Thu, Apr 11, 2002 at 12:18:42PM +0300, Pasi Kärkkäinen wrote:
> > What's the status of newer imp packages for woody/sid?
>
> Beta packages can be found at:
> http://tabaluga.ipe.uni-stuttgart.de/~nils/download/

Is there any problem you're aware of with those packages or are they beta
because they have not been deployed much yet? (Basically my question is -
why are they beta). Please feel free to ignore my question if you think
it's a waste of time to reply.
*t


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



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

Re: Faster Release Cycle = More Up to date Packages...

[Carlos Sousa]

On 11 Apr 2002 21:27:23 -0400
Thomas Hood <[EMAIL PROTECTED]> wrote:
> I think testing is an excellent thing to have, since it 
> provides a semi-stable proto-release.  Unfortunately it is
> true that the existence of testing hasn't shortened the
> release cycle.

testing is, in my opinion, the feature that sets Debian apart from all
other Linux distributions. It's as if woody is released every day. I
can't imagine anyone using potato on his desktop system (Mozilla M18?),
and I bet a lot of (most?) production systems out there have also tired
of potato and made the move to woody. If the option were a move to
unstable, we'd probably be stuck to Mozilla M18 today, and perhaps
seriously considering a switch to some other more current Linux
distribution.

Sorry for the slightly OT post.

-- 
Carlos Sousa


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

Re: Please test this woody cd image

[Michael Piefel]

Am 11.04.02 um 20:31:55 schrieb Anthony Towns:
> Seriously: everyone reading this mail, burn a copy of Raphael's test image
> on a CD and try booting it in any computers you have handy.

Complete install success on an IBM Thinkpad A30.

(Except for the odd locales behaviour, but that got nothing to do with
the boot CD.)

Bye,
Mike

-- 
|=| Michael Piefel
|=| Humboldt-Universität zu Berlin
|=| Tel. (+49 30) 2093 3831


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

Re: sid: libc6-2.2.5-4 kills vmware workstation 3.0

[Wilmer van der Gaast]

Martin [EMAIL PROTECTED]@Wed, 10 Apr 2002 11:25:53 +0200:
>  * Jeroen Dekkers <[EMAIL PROTECTED]> [20020409 20:45]:
> > You don't have to tell me how glibc works, I develop it.
>  Yeah, and Daniel Stone is a Linux kernel developer.
>  
Heheheheh

But watch out, Jeroen == Hurd developer.. (Ohyes, Hurd != kernel..)

-- 
*=-+-__
   |[EMAIL PROTECTED]: _ Ugh! Nio2f says something: __
   : http://www.lintux.cx/ |/ jeroen dekkers a lin martinux ker \
~~-+-=-+~+-=*


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

Re: rsync and debian -- summary of issues

[Martin Pool]

On 11 Apr 2002, Robert Tiberius Johnson <[EMAIL PROTECTED]> wrote:

> Thanks for all your hard work on rsync.  I think it is a great tool. 
> I'm especially excited to hear it is used in Intermezzo.  I like your
> rsync/debian web page.

I'm glad you like them.[0] 

> I feel you aren't fair to diff (in Section 2.1).  For example, I diffed
> two Packages files, and then compressed the diff.  I also computed the
> xdelta of the files.  The compressed diff was smaller (by 10%-20%). 

It's quite true that diff will do much better for some cases, and the
Packages file is one of them.  I'll update the document to be more
fair about that.

Of course the most important advantage of rsync is what tridge calls
the "morning after pill": you don't have to still have a copy of the
old file to be able to generate a diff relative to it.  If we accept
that it's not reasonable for servers to retain information about every
previous version of a package, then something related to rsync is the
most likely solution.  

> Also, in section 3.15, you say, "Fetching a series of deltas which
> update the same area is less efficient than calculating the deltas
> directly."  This is true, but by my computations, the number of packages
> which change more than once in a month is 300, which require about 30K
> of wasted bandwidth. 

Sorry, I don't understand what the 30kB number relates to.  Is that
only for the updates to the Packages file?

-- 
Martin 

[0] I'm obviously too polite to stay on debian-devel.


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

Re: rsync and debian -- summary of issues

[Martin Pool]

On 12 Apr 2002, Martin Pool <[EMAIL PROTECTED]> wrote:

> I've changed my opinion on this since we last talked, partly because
> of taking over rsync itself, 

... what I meant, but people other than jgg probably didn't know, is
that I was looking at installing rproxy and I'd now rather fix rsync.

-- 
Martin 


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

Re: Galeon not to be in Woody?

[Bas Zoetekouw]

Hi Martijn!

You wrote:

> What is the fix here? I must admit, I've always liked being able to visit a
> link simply by pasting it anywhere in netscape/galeons window.

Indeed. And at least in galeon, this behaviour can be turned off.

-- 
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  |
+---+ 


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

Re: rsync and debian -- summary of issues

[Martin Pool]

On 12 Apr 2002, Jason Gunthorpe <[EMAIL PROTECTED]> wrote:

> nobody8835 25.7  0.3 22120 1740 ?RN   Apr10 525:24 rsync --daemon
> nobody   22896  5.0  0.3 22828 1992 ?SN   Apr11  21:20 rsync --daemon
> nobody3907  7.3  0.5 22336 2820 ?RN   Apr11  15:30 rsync --daemon
> nobody   10729 13.7  4.0 22308 20904 ?   RN   Apr11  13:10 rsync --daemon
> 
> The load average is currently > 7 all due to rsync. I'm not sure what that
> one that has sucked up 500mins is actually doing, but I've come to accept
> that as 'normal'. I expect some client has asked it to recompute every
> checksum for the entire 30G of data and it's just burning away processor
> power .

Hi,

I've changed my opinion on this since we last talked, partly because
of taking over rsync itself, and partly because of learning more about
the problem space.  I'd hope it was possible to make things work
better, either by fixing bugs or by giving the sysadmin more range to
restrict expensive operations.

What I'd really like is to have access to one of these machines and be
able to attach debuggers to rsync and see what it's doing.  (In this
case, that would mean being able to ssh in as 'nobody', or something
equivalent.)  I realize there might be some security difficulties with
doing that, but if we can get past them it would be good for rsync,
and hopefully also for Debian.  If direct access is impossible then
maybe somebody who can ssh to the machine can work with me.

-- 
Martin 


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

Re: rsync and debian -- summary of issues

[Anthony Towns]

On Thu, Apr 11, 2002 at 11:48:01PM -0700, Robert Tiberius Johnson wrote:
> Also, in section 3.15, you say, "Fetching a series of deltas which
> update the same area is less efficient than calculating the deltas
> directly."  This is true, but by my computations, the number of packages
> which change more than once in a month is 300, which require about 30K
> of wasted bandwidth.  Rsync uses a similar amount of bandwidth sending
> checksums back and forth, if I'm not mistaken.

Additionally, many packages only change the version number as far as
the Packages file is concerned, which is handled quite efficiently by
diff --ed.

Cheers,
aj

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

 ``BAM! Science triumphs again!'' 
-- http://www.angryflower.com/vegeta.gif


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

Re: Debian's problems, Debian's future

[Anthony Towns]

On Thu, Apr 11, 2002 at 10:40:31PM -0700, Robert Tiberius Johnson wrote:
> On Wed, 2002-04-10 at 02:28, Anthony Towns wrote: 
> > I'd suggest your formula would be better off being:
> > bandwidthcost = sum( x = 1..30, prob(x) * cost(x) / x )
> I think it depends on what you're measuring.  I can think of two ways to
> measure the "goodness" of these schemes (there are certainly others): 
> 
> 1. What is the average bandwidth required at the server? 
> 2. What is the average bandwidth required at the client? 

I don't think the bandwidth at the server is a major issue to anyone,
although obviously improvements there are a Good Thing.

Personally, I think "amount of time spent waiting for apt-get update
to finish" is the important measure (well, "apt-get update; apt-get
dist-upgrade" is important too, but I don't thing we've seen any feasible
ideas at improving the latter).

> prob2(i)=(prob1(i)/i)*norm, 
> 
> where norm is a normalization factor so the probabilities sum to 1. 
> I've been looking at question 2, and you're suggesting that I look at
> question 1, except you forgot the normalization factor.  I think this is
> what you mean.  Please correct me if I've misunderstood. 

No, I'm not. I'm saying that "the amount of time spent waiting for
apt-get update" needs to count every apt-get update you run, not just
the first. So, if over a period of a week, I run it seven times, and you
run it once, I wait seven times as long as you do, so it's seven times
more important to speed things up for me, than for you.

> Anyway, here are the results you asked for.  I'm NOT including the
> normalization factor for easier comparison with your numbers.  My diff
> numbers are a little different from yours mainly because I charge 1K of
> overhead for each file request. 

Merging, and reordering by decreasing estimated bandwidth. The ones marked
with *'s aren't worth considering because there's a method that's both
has less bandwidth required, and takes up less diskspace. The ones without
stars are thus ordered by increasing diskspace, and decreasing bandwidth.

> days/
> bsize dspace  ebwidth
> ---

Having the "ebwidth" of the current situation (everyone downloads the
entire Packages file) for comparison would be helpful.

> 1 12.000K 342.00K [diff]
> 20312.50K *   173.70K [cksum/rsync]
> 2 24.000K *   171.20K [diff]
> 3 36.000K *   95.900K [diff]
> 40156.30K *   89.300K [cksum/rsync]
> 60104.20K *   62.200K [cksum/rsync]
> 4 48.000K *   58.500K [diff]
> 8078.100K *   49.300K [cksum/rsync]
> 100   62.500K *   42.200K [cksum/rsync]
> 5 60.000K *   38.800K [diff]
> 120   52.100K *   37.900K [cksum/rsync]
> 400   15.600K 37.700K [cksum/rsync]
> 380   16.400K 36.800K [cksum/rsync]
> 360   17.400K 35.900K [cksum/rsync]
> 140   44.600K *   35.300K [cksum/rsync]
> 340   18.400K 35.100K [cksum/rsync]
> 320   19.500K 34.300K [cksum/rsync]
> 300   20.800K *   33.600K [cksum/rsync]
> 160   39.100K *   33.600K [cksum/rsync]
> 280   22.300K 33.000K [cksum/rsync]
> 180   34.700K *   32.700K [cksum/rsync]
> 260   24.000K 32.500K [cksum/rsync]
> 240   26.000K 32.200K [cksum/rsync]
> 200   31.300K *   32.200K [cksum/rsync]
> 220   28.400K 32.100K [cksum/rsync]
> 6 72.000K 27.900K [diff]
> 7 84.000K 21.800K [diff]
> 8 96.000K 18.200K [diff]
> 9 108.00K 16.100K [diff]
> 10120.00K 14.900K [diff]
> 11132.00K 14.100K [diff]
> 12144.00K 13.700K [diff]
> 13156.00K 13.400K [diff]
> 14168.00K 13.300K [diff]
> 15180.00K 13.100K [diff]

180k is roughly 10% of the size of the corresponding Packages.gz, so
is relatively trivial. Since we'll probably do it at the same time as
dropping the uncompressed Packages file (sid/main/i386 alone is 6MB),
this is pretty neglible.

Cheers,
aj

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

 ``BAM! Science triumphs again!'' 
-- http://www.angryflower.com/vegeta.gif


pgp6DeEYsec6i.pgp
Description: PGP signature

Re: rsync and debian -- summary of issues

[Robert Tiberius Johnson]

On Thu, 2002-04-11 at 01:15, Martin Pool wrote:
> There seems to be a thread about rsync and Debian packages every
> couple of months.  I've written up a document which tries to cover all
> of the questions and debates.  It's pretty informal, but hopefully
> will be useful.
> 
>   http://rsync.samba.org/rsync-and-debian/
> 
> I'd appreciate comments.

Thanks for all your hard work on rsync.  I think it is a great tool. 
I'm especially excited to hear it is used in Intermezzo.  I like your
rsync/debian web page.

I have two comments:

I feel you aren't fair to diff (in Section 2.1).  For example, I diffed
two Packages files, and then compressed the diff.  I also computed the
xdelta of the files.  The compressed diff was smaller (by 10%-20%). 
Since the xdelta code is based on rsync, it seems that diff does pretty
well compared to rsync.

Also, in section 3.15, you say, "Fetching a series of deltas which
update the same area is less efficient than calculating the deltas
directly."  This is true, but by my computations, the number of packages
which change more than once in a month is 300, which require about 30K
of wasted bandwidth.  Rsync uses a similar amount of bandwidth sending
checksums back and forth, if I'm not mistaken.

Best,
Rob



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

Re: Assistance required for procps bug

[Colin Walters]

On Fri, 2002-04-12 at 00:30, Craig Small wrote:
> Hello,
>   I have bug #142292, #109237 and #106414 for procps.  The common thing
> is that if System.map file is a multiple of 1024 (or 4096 not sure
> which) ps crashes.  Thanks to Dark for getting me that far.
> 
> Can someone look at 106414 and Dark's analysis and help me out here?
> I'm not subscribed to debian-devel so contact me direct.  

If dark's analysis is correct, the following patch should fix the bug.

But that code is some of the most awful C I've seen, so I wouldn't be
surprised if the bug was elsewhere.

--- ksym.c~ Fri Apr 12 02:44:25 2002
+++ ksym.c  Fri Apr 12 02:38:07 2002
@@ -356,7 +356,7 @@
 sysmap_index = vp;
 for(;;){
   char *vstart;
-  if(!*endp){/* if we reached the end */
+  if(endp - sysmap_data >= sbuf.st_size){  /* if we reached the end */
 int i = VCNT;/* check VCNT times to verify this file */
 if(*Version) goto bad_version;
 if(!ksyms_index) return 1; /* if can not verify, assume success */

Re: Please test this woody cd image

[Erik Andersen]

On Fri Apr 12, 2002 at 11:35:31AM +1000, Drew Parsons wrote:
> > I just tested it on all the bootable x86 systems in my house:
> ...
> > Toshiba 490CDT Satellite Pro Laptop: Works
> 
> That's good news.  What was your success booting the Potato CD on this
> laptop?  In my experience, the Toshiba laptops (the 490CDT in particular)
> would not boot the Potato CD.  As far as I'm aware, this was because the
> boot image on the CD was based on a 2.88MB floppy image, where the Toshiba
> laptops could only handle a 1.44MB image.
> 
> I'm impressed to hear Toshiba laptops can boot normally again :)

I didn't try Potato on this laptop.  Its on loan to me while
doing some software development.  But at least with the new
isolinux boot CD, I just dropped in the CD and it booted just
fine into the installer with both the default idepci and 
with the bf24 kernels

 -Erik

--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--


pgpZEMLYBmH5s.pgp
Description: PGP signature

Re: rsync and debian -- summary of issues

[Jason Gunthorpe]

On Thu, 11 Apr 2002, Martin Pool wrote:

> I'd appreciate comments.

Hmm...

As you may know I'm both the APT author, administrator of the top level
debian mirrors and associated mirror network. So,

> 3.2 rsync is too hard on servers
> If it is, then I think we should fix the problems, rather than
> invent a new system from scratch. I think the scalability problems
> are accidents of the current codebase, rather than anything inherent
> in the design.

It's true I'm afraid. Currently on ftp.d.o:

nobody8835 25.7  0.3 22120 1740 ?RN   Apr10 525:24 rsync --daemon
nobody   22896  5.0  0.3 22828 1992 ?SN   Apr11  21:20 rsync --daemon
nobody3907  7.3  0.5 22336 2820 ?RN   Apr11  15:30 rsync --daemon
nobody   10729 13.7  4.0 22308 20904 ?   RN   Apr11  13:10 rsync --daemon

The load average is currently > 7 all due to rsync. I'm not sure what that
one that has sucked up 500mins is actually doing, but I've come to accept
that as 'normal'. I expect some client has asked it to recompute every
checksum for the entire 30G of data and it's just burning away processor
power .

We tend to allow only 10-15 simulataneous rsync connections because of
this.

Things are better now, in the past with 2.2 kernels and somewhat slower
disks rsync would not just suck up CPU power but it would seriously hit
the drives as well. I think the improvements in inode/dentry caching in
2.4, and our new archive structure are largely responsible for making that
less noticable.

IMHO as long as rsync continues to have a server heavy design it's ability
to scale is going to be quite poor. Right now there are 91 people
connected to  ftp/http on ftp.d.o, if they were using rsync's I'm sure the
poor server would be quite dead indeed.

> 3.1 Compressed files cannot be differenced

I recall seeing some work done to determine how much savings you could
expect if you used xdeltas of the uncompressed data. This would be the
best result you could expect from gzip --rsyncable. I recall the numbers 
were disapointing, it was << 50% on average or somesuch. It would be nice
if someone could find that email or repeat the experiments.

> 3.5 Goswin Brederlow's proposal to use the reverse rsync algorithm over
> HTTP Range requests

Several years ago I suggested this in a conversation with you on one of
the rsync lists, someone else was able to pull a reference to the IBM
patent database and claimed it was the particular patent that prohibits
the server-friendly reverse implementation.

> 3.7 rsync uses too much memory

This only really seems to be true for tree-mirroring, the filelists can be
very big indeed.

Jason


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

Re: Clustalw update_excuses

[Anthony Towns]

On Fri, Apr 12, 2002 at 07:45:08AM +0200, Tille, Andreas wrote:
> * clustalw (1.82-2 to 1.82-3)
> 
> * Maintainer: Andreas Tille
> * 43 days old (needed 10 days)
> * Valid candidate
> * Depends: clustalw ncbi-tools6
  ^^^

clustalw needs a new ncbi-tools6.

 * ncbi-tools6 (6.1.20011220-2 to 6.1.20011220a-2)
  + Maintainer: Aaron M. Ucko
  + Too young, only 6 of 10 days old
  + Not considered

...but ncbi-tools6 can't go in yet since it was only very recently
updated.

Cheers,
aj

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

 ``BAM! Science triumphs again!'' 
-- http://www.angryflower.com/vegeta.gif


pgp9dpocsueCm.pgp
Description: PGP signature

Re: Debian's problems, Debian's future

[Robert Tiberius Johnson]

On Wed, 2002-04-10 at 09:46, Erich Schubert wrote:
> What diff options do you use?
> As the diffs are expected to be applied to the correct version, they
> probably shouldn't contain the old data, but the new data only.

Good point.  I used diff -ed, so I think this is not including
unnecessary context info, as you suggest.  

Best,
Rob



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

Re: Debian's problems, Debian's future

[Robert Tiberius Johnson]

On Wed, 2002-04-10 at 04:35, Michael Bramer wrote:
> > Scheme Disk space Bandwidth
> > ---
> > Checksums (bwidth optimal)26K   81K
> > diffs (4 days)32K  331K
> > diffs (9 days)71K   66K
> > diffs (20 days)  159K   27K
> 
> can you explain your counts?

Sure.  At the end of this message is a script that you can use with the
program "gp" to recreate my numbers.  Here's a quick description:

Anthony Towns said that the average size of a diff between two Packages
files is 12K (after compression with bzip2).  So if the server keeps d
days of diffs, this will take about d*12K of disk space.  If I go for i
days without updating, then when I do update, if i <= d, then I will
need to download i diff files, using about i*(12K + 1K) bandwidth.  (The
1K is for each GET request, since I'm downloading i files).  If i > d,
then I need to get the whole Packages.gz file, which I estimate as about
1.6M.  So let bwidth(d,i) = the amount of bandwidth used doing an update
after i days, where the server has kept d days of diffs.

So how much bandwidth is used _on average_?  Well, it depends on how
often everybody updates.  If everybody updates everyday, then everybody
would just need to download 1 diff, using 13K.  If everybody updates
every week, then the average bandwidth is 7*13K=91K.  In reality, we
don't know how often people update, but my guess is that people tend to
update often.  So I just guessed that the probability that someone
updates after i days is prob(i)=((2/3)^i)/2.  Why this formula?  It
seemed good at the time.  So then the average bandwidth used is

average_bwidth(d)=sum i=1,...,infinity of bwidth(d,i) * prob (i)

That's it for the diff stuff.

For the checksum scheme, the disk space required is the number of
checksums times the size of each checksum.  The number of checksums is
the size of Packages.gz divided by the block size.  Since the checksum
file has to be transferred to every client, the size of the checksum
file contributes to the bandwidth estimate, as well.  Additionally, I
estimate that 75 packages change in debian every day (derived by looking
at debian-devel-changes in Feb. and March).  Using a little probability,
I computed the average number of blocks in Packages.gz that will change
in i days.  I then estimate that each of these blocks will have to be
transferred during an update, and use that to estimate the amount of
bandwidth required for an update.  Then I average, as with the diff
scheme.  Let me know if you think there's any problems with this..

I've been playing around recently with a more realistic (in my opinion)
user model.  I now predict that the probability that a user will update
every i days is n/(i+1)^3 (n is a normalization factor).  I like this
model because it predicts that if a user hasn't updated in a long time,
it'll probably be a long time before they update.  This seems
intuitively correct to me.  So here's some new numbers comparing the
diff scheme and the rsync scheme in this new user model.  In my opinion,
diff still wins.

These numbers use prob(i)=(n/(i+1)^3)/i, so these numbers are the
average bandwidth, averaged over what the server sees.  For an
explanation of this, see
http://lists.debian.org/debian-devel/2002/debian-devel-200204/msg01076.html.

Diffs:
daysdspace  ebwidth
---
1   12.000K 296.80K
2   24.000K 110.70K
3   36.000K 58.800K
4   48.000K 39.100K
5   60.000K 30.000K
6   72.000K 25.300K
7   84.000K 22.600K
8   96.000K 21.000K
9   108.00K 19.900K
10  120.00K 19.200K
11  132.00K 18.700K
12  144.00K 18.400K
13  156.00K 18.100K
14  168.00K 17.900K
15  180.00K 17.800K

Checksum files:
bsize   dspace  ebwidth
---
20  312.50K 315.40K
40  156.30K 161.10K
60  104.20K 111.00K
80  78.100K 86.800K
100 62.500K 73.100K
120 52.100K 64.600K
140 44.600K 59.100K
160 39.100K 55.500K
180 34.700K 53.000K
200 31.300K 51.500K
220 28.400K 50.500K
240 26.000K 50.100K
260 24.000K 50.000K
280 22.300K 50.100K
300 20.800K 50.500K
320 19.500K 51.100K
340 18.400K 51.800K
360 17.400K 52.700K
380 16.400K 53.700K
400 15.600K 54.700K


Best,
Rob

/***
 * Info about debian
 ***/

/* The number of packages in debian */
npkgs=8000.0

/* How big is Packages[.gz] as a function of the number of packages */
compressed_bytes_per_pkg=200.0
uncompressed_byte

Re: Faster Release Cycle = More Up to date Packages...

[Johnny Ernst Nielsen]

Good day everyone,

thank you for a lot of input.

As a fair number of you have pointed out, you are all quite busy with 
getting Woody out the door.
I aggree that is important, and that the release process can not be 
changed now right in the middle of Woody-work.
Priority right now is fixing bugs in Woody.

Unfortunately I can not help you with that as I am not a developer 
and is no good with code on the production level.

While you guys get Woody ready, I will try to find out more about the 
current release procedure and the past of Debian development.

Hopefully I will see you all again May 2Nd.

Best regards
Johnny Ernst Nielsen :o)


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

Re: Bug#141847: O: dupload -- Utility to upload Debian packages.

[Colin Walters]

On Thu, 2002-04-11 at 20:53, Brian May wrote:
> On Tue, Apr 09, 2002 at 09:40:47AM +0100, Julian Gilbey wrote:
> > I am happy to take it.  But a question: with the more actively
> > maintained dput now being quite mature, do we still need both dupload
> > and dput?
> 
> Dumb question, but what dput, and why is one better then the other?
> (please leave language flame wars out of discussion - we all know that
>  is the best language).

I like dput's DWIM features.  For example, it figures out automatically
whether or not a package is in non-US, and uploads to the correct
place.  



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

Clustalw update_excuses

[Tille, Andreas]

Hello,

in the package clustal[wx]_1.82-3 I fixed a buffer overflow and sended the
fix upstream.  I do not think that the problem is a real security risk but
in many cases clustalw does not perform correctly so that I think the
latest packages should go into testing.  I wonder why it is sticked to
unstable:

auric:~> madison clustalw
  clustalw |  1.7-7 |stable | source, alpha, arm, i386, m68k, 
powerpc, sparc
  clustalw | 1.82-2 |   testing | source, alpha, arm, i386, ia64, m68k, 
powerpc, s390, sparc
  clustalw | 1.82-3 |  unstable | source, alpha, arm, hppa, i386, ia64, 
m68k, powerpc, s390, sparc

but


http://ftp-master.debian.org/testing/update_excuses.html:

...
* clustalw (1.82-2 to 1.82-3)

* Maintainer: Andreas Tille
* 43 days old (needed 10 days)
* Valid candidate
* Depends: clustalw ncbi-tools6
...

So it should have reached testing one month ago and I see no reason why
it did not.  Any explanation for this?

Kind regards

 Andreas.


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

Re: [2002-04-06] Release Status Update

[Paul Slootman]

On Thu 11 Apr 2002, Keith G. Murphy wrote:
> Bernd Eckenfels wrote:
> > 
> > On Thu, Apr 11, 2002 at 10:18:08AM +0200, Russell Coker wrote:
> > > You only need pptp-linux if you use an Ethernet attached modem instead of 
> > > the
> > > USB attached modem (which is E50 cheaper).
> > 
> > This does not make sence at all. PPTP is also a WAN Tunneling and VPN
> > Protocol. How can a Linux Router speek PPTP without linux-pptp package? This
> > is a often used VPN Solution to Windows servers. And if there is no bug, it
> > is not a good idea to remove the package.
> > 
> Do ya think they're talking about PPPOE, rather than pptp?  It would
> make more sense in that context...

No, he's right; at least, the part about VPN is correct.

Russell was speaking in the context of the common ADSL offering here in
the Netherlands, where an Alcatel ADSL modem is commonly used. You have
to speak PPTP to that modem, unless you can hack it (see earlier
discussion). As an alternative to the ethernet attached modem, there's
also an USB modem, and for that you don't need PPTP.

However, PPTP has more uses than just talking to these things: it's also
used when connecting to Windows VPN servers. So in those cases you also
need pptp-linux (the point Bernd was making).


Paul Slootman


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

Re: Debian's problems, Debian's future

[Robert Tiberius Johnson]

On Wed, 2002-04-10 at 02:28, Anthony Towns wrote: 
> I think you'll find you're also unfairly weighting this against people
> who do daily updates. If you do an update once a month, it's not as much
> of a bother waiting a while to download the Packages files -- you're
> going to have to wait _much_ longer to download the packages themselves.
> 
> I'd suggest your formula would be better off being:
> 
>   bandwidthcost = sum( x = 1..30, prob(x) * cost(x) / x )
> 
> (If you update every day for a month, your cost isn't just one download,
> it's 30 downloads. If you update once a week for a month, your cost
> isn't that of a single download, it's four times that. The /x takes that
> into account)

I think it depends on what you're measuring.  I can think of two ways to
measure the "goodness" of these schemes (there are certainly others): 

1. What is the average bandwidth required at the server? 
2. What is the average bandwidth required at the client? 

The two questions are related: If users update after i days with
prob1(i), then the probability that a connection arriving at a server is
from a user updating after i days is 

prob2(i)=(prob1(i)/i)*norm, 

where norm is a normalization factor so the probabilities sum to 1. 
I've been looking at question 2, and you're suggesting that I look at
question 1, except you forgot the normalization factor.  I think this is
what you mean.  Please correct me if I've misunderstood. 

Anyway, here are the results you asked for.  I'm NOT including the
normalization factor for easier comparison with your numbers.  My diff
numbers are a little different from yours mainly because I charge 1K of
overhead for each file request. 

Diff scheme 
daysdspace  ebwidth
---
1   12.000K 342.00K
2   24.000K 171.20K
3   36.000K 95.900K
4   48.000K 58.500K
5   60.000K 38.800K
6   72.000K 27.900K
7   84.000K 21.800K
8   96.000K 18.200K
9   108.00K 16.100K
10  120.00K 14.900K
11  132.00K 14.100K
12  144.00K 13.700K
13  156.00K 13.400K
14  168.00K 13.300K
15  180.00K 13.100K

Checksum file scheme with 4 byte checksums:
bsize   dspace  ebwidth
---
20  312.50K 173.70K
40  156.30K 89.300K
60  104.20K 62.200K
80  78.100K 49.300K
100 62.500K 42.200K
120 52.100K 37.900K
140 44.600K 35.300K
160 39.100K 33.600K
180 34.700K 32.700K
200 31.300K 32.200K
220 28.400K 32.100K
240 26.000K 32.200K
260 24.000K 32.500K
280 22.300K 33.000K
300 20.800K 33.600K
320 19.500K 34.300K
340 18.400K 35.100K
360 17.400K 35.900K
380 16.400K 36.800K
400 15.600K 37.700K

I'm probably underestimating the bandwidth of the checksum file scheme. 
I'm pretty confident about the diff scheme estimates, though.

I think the performance of the two schemes is pretty close.  Even though
this looks pretty good for the checksum file scheme, I'm still partial
to the diff scheme because 

- The checksum file scheme bottoms out at 32K, but the diff scheme can
reduce transfers to 13K (using more disk space).

- I trust my estimates of the diff scheme more.  The rsync scheme will
definitely take more bandwidth than my estimates predict.

- As debian gets larger, the checksum files will get larger, and so the
bandwidth will get larger.  So over time, any advantage of the checksum
file scheme will disappear.

- The diff scheme is more flexible and easier to tune.  The checksum
file scheme has a "sweet spot" at 220 byt blocks.  Predicting the actual
value of this sweet spot may be hard in the real world.

Best,
Rob



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

Fixed - missing build-depends : gawk

[Shell, Hin-lik Hung]

Hi all,

For the glabels package, I have uploaded glabels_0.4.3-2, it
will solved the problem of missing gawk in build-depends, but it
happened before all build attempt, I close #142480 here and notice
other developers, the problem has been fixed in new upload.

Thank you.

-- 
Best Regards,
  Shell Hin-Lik Hung [ 熊顯力 ] | http://www.shellhung.org/

  shell@ { shellhung.org openbsd.org debian.org netbsd.org }


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