Bug#234236: grave

2004-05-09 Thread GOTO Masanori 
At Mon, 10 May 2004 07:21:18 +0200,
Thiemo Seufer wrote:
> GOTO Masanori wrote:
> > At Mon, 3 May 2004 18:50:18 +0100,
> > Martin Michlmayr wrote:
> > > severity 234236 grave
> > > thanks
> > > 
> > > This is a grave bug since it keeps about 10-15 packages from building
> > > on mips.
> > 
> > Which packages did this bug affect?  I agreed with Thiemo's and
> > Goswin's opinion:
> >
> > > I wonder if it would be time to convert fdisk to _FILE_OFFSET_BITS=64 for
> > > linux on all archs instead of 32 bit + _llseek hacks.
> > 
> > > But then, util-linux should use more portable means than kernel headers,
> > > like the syscall() interface.
> > 
> > So I don't think it's grave for linux-kernel-headers.
> 
> Glibc itself might break as well, probably in non-obvious ways, if built
> against this version of l-k-h.
> 
> The patch is obviously correct, and already in the upstream repository
> (www.linux-mips.org).

I don't discuss the correctness of this patch; my question is: which
packages are this patch needed.  If it's really serious, we just do
upload the new lkh.  My opinion is: if util-linux is the only package
to be affected this problem, fix util-linux before fixing glibc.

Regards,
-- gotom


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

Bug#247899: marked as done (libc6-dev: doesn't define types required by POSIX)

2004-05-09 Thread Debian Bug Tracking System 
Your message dated Mon, 10 May 2004 13:28:50 +0900
with message-id <[EMAIL PROTECTED]>
and subject line Bug#247899: libc6-dev:  doesn't define types 
required by POSIX
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--
Received: (at submit) by bugs.debian.org; 7 May 2004 20:22:37 +
>From [EMAIL PROTECTED] Fri May 07 13:22:37 2004
Return-path: <[EMAIL PROTECTED]>
Received: from gwyn.kn-bremen.de [212.63.36.242] (root)
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1BMBrg-0004Hy-00; Fri, 07 May 2004 13:22:37 -0700
Received: from gwyn.kn-bremen.de ([EMAIL PROTECTED] [127.0.0.1])
by gwyn.kn-bremen.de (8.12.9/8.12.9/Debian-5) with ESMTP id 
i47KMTOg019823
for <[EMAIL PROTECTED]>; Fri, 7 May 2004 22:22:29 +0200
Received: from jelal.kn-bremen.de ([EMAIL PROTECTED])
by gwyn.kn-bremen.de (8.12.9/8.12.8/Debian-1) with UUCP id 
i47KMTL1019821
for [EMAIL PROTECTED]; Fri, 7 May 2004 22:22:29 +0200
Received: from [127.0.0.1] (neptun [10.0.0.3])
by saturn (8.11.4/8.8.5) with ESMTP id i47KKI773994;
Fri, 7 May 2004 22:20:18 +0200 (CEST)
Message-Id: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Juergen Lock <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: libc6-dev:  doesn't define types required by POSIX
X-Mailer: reportbug 2.58
Date: Fri, 07 May 2004 22:08:10 +0200
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25 
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-7.0 required=4.0 tests=BAYES_00,HAS_PACKAGE 
autolearn=no version=2.60-bugs.debian.org_2004_03_25
X-Spam-Level: 
X-CrossAssassin-Score: 1

Package: libc6-dev
Version: 2.3.2.ds1-10
Severity: normal

"The Open Group Base Specifications Issue 6: IEEE Std 1003.1-2001"
requires (for ) that:

   "The blkcnt_t, blksize_t, dev_t, ino_t, mode_t, nlink_t,
uid_t, gid_t, off_t, and time_t types shall be defined 
as described in ."

 which doesn't seem true on Debian.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.4
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]

Versions of packages libc6-dev depends on:
ii  libc62.3.2.ds1-10GNU C Library: Shared libraries an
ii  linux-kernel-headers 2.5.999-test7-bk-15 Linux Kernel Headers for developme

-- no debconf information

---
Received: (at 247899-done) by bugs.debian.org; 10 May 2004 04:28:52 +
>From [EMAIL PROTECTED] Sun May 09 21:28:52 2004
Return-path: <[EMAIL PROTECTED]>
Received: from omega.webmasters.gr.jp (webmasters.gr.jp) [218.44.239.78] 
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1BN2PM-0002rg-00; Sun, 09 May 2004 21:28:52 -0700
Received: from omega.webmasters.gr.jp (localhost [127.0.0.1])
by webmasters.gr.jp (Postfix) with ESMTP
id E8D5EDEB80; Mon, 10 May 2004 13:28:50 +0900 (JST)
Date: Mon, 10 May 2004 13:28:50 +0900
Message-ID: <[EMAIL PROTECTED]>
From: GOTO Masanori <[EMAIL PROTECTED]>
To: Juergen Kreileder <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Cc: Juergen Lock <[EMAIL PROTECTED]>
Subject: Re: Bug#247899: libc6-dev:  doesn't define types required 
by POSIX
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
User-Agent: Wanderlust/2.9.9 (Unchained Melody) SEMI/1.14.3 (Ushinoya)
 FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2
 (i386-debian-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25 
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-5.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER 
autolearn=no version=2.60-bugs.debian.org_2004_03_25
X-Spam-Level: 
X-CrossAssassin-Score: 1

At Sat, 08 May 2004 05:42:02 +0200,
Juergen Kreileder wrote:
> > "The Open Group Base Specifications Issue 6: IEEE Std 1003.1-2001"
> > requires (for ) that:
> >
> > "The blkcnt_t, blksize_t, dev_t, ino_t, mode_t, nlink_t,
> > uid_t, gid_t, off_t, and time_t types shall be defined 
> > as described in ."
> >
> > which doesn't seem true on Debian.
> 
> These types are supported but n

Bug#231024: marked as done (libc6-dev: unresolved symbols for -ldl)

2004-05-09 Thread Debian Bug Tracking System 
Your message dated Mon, 10 May 2004 12:00:46 +0900
with message-id <[EMAIL PROTECTED]>
and subject line Bug#231024: libc6-dev: unresolved symbols for -ldl
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--
Received: (at submit) by bugs.debian.org; 4 Feb 2004 01:01:49 +
>From [EMAIL PROTECTED] Tue Feb 03 17:01:49 2004
Return-path: <[EMAIL PROTECTED]>
Received: from rnd.watchguard.com (qubert) [208.146.43.174] 
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1AoBQK-0008An-00; Tue, 03 Feb 2004 17:01:49 -0800
Received: from localhost (lug.wgrd.net [192.168.53.152])
by qubert (Postfix) with ESMTP id CFDFD372A2
for <[EMAIL PROTECTED]>; Tue,  4 Jan 2000 23:17:16 -0800 (PST)
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: libc6-dev: unresolved symbols for -ldl
X-Debbugs-CC: Neale Pickett <[EMAIL PROTECTED]>
X-Face: "&g4:h\nuA>dfRaRmJ5c+Mqvu!,|[EMAIL 
PROTECTED]>:BqJ,#G:mT3`i-EF{L>6oE?di}m\;Wil(?AS(@9j"[EMAIL 
PROTECTED](BU$)u.%I;*K9%4Vj.fO$W9-bjxPgl%|[EMAIL 
PROTECTED]/jZ@,G:>&;JzJrBqMqomx3Z#Hg.``g5v%R[+PzjYtAa&[EMAIL 
PROTECTED]<;.,gV`5$8Go1OJB=L`R(<)U$M4YK-t;a}oA1y([EMAIL 
PROTECTED]:_|_*r44[Gl{3@:[EMAIL PROTECTED]|:2;lpSwi=1"gf7g{Bz+U2MI
From: Neale Pickett <[EMAIL PROTECTED]>
Organization: WatchGuard Technologies (www.watchguard.com)
X-Thought: He found against me, and awarded my ego full access to my brain. 
-- Ken Brush
X-PGP-Key-Fingerprint: A862 F105 13EF 7FAF 4F08  78B4 9168 856B 48BF F157
Importance: high
X-Payment: hashcash 1.2 must specify at least one of -m, -c, -n, -l, -w, -V
X-Hashcash: must specify at least one of -m, -c, -n, -l, -w, -V
Date: Tue, 03 Feb 2004 17:02:22 -0800
Message-ID: <[EMAIL PROTECTED]>
User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_02_01 
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-7.2 required=4.0 tests=HAS_PACKAGE,OPT_IN_CAPS,
X_DEBBUGS_CC autolearn=no version=2.60-bugs.debian.org_2004_02_01
X-Spam-Level: 

Package: libc6-dev
Version: 2.3.2.ds1-11
Severity: important

I apologize in advance if I am filing this bug against the wrong
package.  I'm not sure what this should be filed against.

I have an unstable system; I just did "apt-get update" and updated a few
libraries that look unrelated, although this has been happening for a
few weeks.  I am using the following in /etc/apt/sources.list, so I
think I am current with everything:

  deb http://ftp.us.debian.org/debian unstable main non-free


The problem:

I am trying to compile the following program:

---8<--- cftest.c ---8<---
#include 

int main ()
{
  dlopen ("", 0);
  return 0;
}
---8<--- cftest.c ---8<---

I get the following failure notices with three different versions of
gcc, but the program builds successfully with a stable system:

~/tmp $ gcc-2.95 -o cftest cftest.c -ldl
/fs/mama/usr/bin/../lib/libdl.so: undefined reference to [EMAIL PROTECTED]'
/fs/mama/usr/bin/../lib/libdl.so: undefined reference to [EMAIL PROTECTED]'
/fs/mama/usr/bin/../lib/libdl.so: undefined reference to [EMAIL PROTECTED]'
/fs/mama/usr/bin/../lib/libdl.so: undefined reference to [EMAIL PROTECTED]'
/fs/mama/usr/bin/../lib/libdl.so: undefined reference to [EMAIL PROTECTED]'
collect2: ld returned 1 exit status

~/tmp $ gcc-3.0 -o cftest cftest.c -ldl
/usr/lib/gcc-lib/i386-linux/3.0.4/../../../libdl.so: undefined reference to 
[EMAIL PROTECTED]'
/usr/lib/gcc-lib/i386-linux/3.0.4/../../../libdl.so: undefined reference to 
[EMAIL PROTECTED]'
/usr/lib/gcc-lib/i386-linux/3.0.4/../../../libdl.so: undefined reference to 
[EMAIL PROTECTED]'
/usr/lib/gcc-lib/i386-linux/3.0.4/../../../libdl.so: undefined reference to 
[EMAIL PROTECTED]'
/usr/lib/gcc-lib/i386-linux/3.0.4/../../../libdl.so: undefined reference to 
[EMAIL PROTECTED]'
collect2: ld returned 1 exit status

~/tmp $ gcc-3.3 -o cftest cftest.c -ldl
/fs/mama/usr/bin/../lib/gcc-lib/i486-linux/3.3.3/../../../libdl.so: undefined 
reference to [EMAIL PROTECTED]'
/fs/mama/usr/bin/../lib/gcc-lib/i486-linux/3.3.3/../../../libdl.so: undefined 
reference to [EMAIL PROTECTED]'
/fs/mama/usr/bin/../lib/gcc-lib/i486-linux/3.3.3/../../../libdl.so: undefined 
reference to [EMAIL PROTECTED]'
/fs/mama/usr/bin/../lib/gcc-lib/i486-linux/3.3.3/../../../libdl.so: undefined 
reference to [EMAIL PROTECTED]'
/fs/mama/usr/bin/../lib/gcc-lib/i486-linux/3.3.3/../../

Bug#234236: grave

2004-05-09 Thread GOTO Masanori 
At Mon, 3 May 2004 18:50:18 +0100,
Martin Michlmayr wrote:
> severity 234236 grave
> thanks
> 
> This is a grave bug since it keeps about 10-15 packages from building
> on mips.

Which packages did this bug affect?  I agreed with Thiemo's and
Goswin's opinion:

> I wonder if it would be time to convert fdisk to _FILE_OFFSET_BITS=64 for
> linux on all archs instead of 32 bit + _llseek hacks.

> But then, util-linux should use more portable means than kernel headers,
> like the syscall() interface.

So I don't think it's grave for linux-kernel-headers.

Regards,
-- gotom

Bug#247300: libc6: malloc() never fails on 2.4 kernels, making processes crash

2004-05-09 Thread wg 
> I am not sure how one could describe a system crippled in this way as 
> "functional".  The limit itself would indeed be "functional",

Ok.  You could have stopped there.  This is going to be my last post
in this thread.

> [begin historical analogy]
> Using ulimit in this way would give one an environment a bit like that 
> of IBM's antique VM operating system for their 360 series of 
> computers, except even worse.  In VM, every user had his own small 
> "virtual disk", and the entire real disk was partitioned among them. 
> So, 200 users on a system with 50 MB of disk space meant each user got 
> exactly 250 KB of disk space, and some users would run out of disk 
> space even if the system disk (seen as an aggregate) was only a few 
> percent full.
> [end historical analogy]

A good analogy!  So, by your reasoning below, all the antiquated Un*x
administrators in the world using quotas on their filesystems should
immediately stop doing so, because it isn't practical!?

> Remember, /etc/initscript doesn't let me set limits on a per-user 
> basis.  Also, remember that ulimit for the number of processes applies 
> only on a per-user basis, not as a pool across the entire number of 
> processes.

Of course ulimits can and must be refined for queue schedulers, for
example.  That is beside the point.

> So let's see.  The system I'm currently running this on (a laptop) has 
> 1 GB of memory, 23 users in /etc/passwd.  The user with the most 
> processes (ignoring kernel processes like [kapmd] that don't take up 
> memory) currently has 61 processes.

Quite a lot.  No swap space?

> If we take these as hard limits, 
> then 1 GB / (61 * 23) = 747 KB of memory per process.  That isn't 
> enough even to run bash, xterm, or dhclient, to say nothing of the X 
> server or Mozilla or Emacs.

So you want 23 users on your laptop to be able to run 61 processes
each?  And under no circumstances do you want to see "out of memory:
killing process..."?  Then, I'm sorry to say: you're out of luck.

>  > For me the alternative is
> > clear: either enjoy the advantages and disadvantages of overcommitment
> > _or_ use "ulimit -v".
> 
> The second of those appears impractical, for the reasons I argue above.

It depends..  But I like overcommitment, too :-)

Regards,
Wolfram.

Bug#248192: setpshared on amd64 not working?

2004-05-09 Thread Daniel Jacobowitz 
On Sun, May 09, 2004 at 11:36:25PM +0200, Kurt Roeckx wrote:
> On Sun, May 09, 2004 at 04:27:23PM -0400, Daniel Jacobowitz wrote:
> > 
> > Details about the kernel and environment on both test systems?
> 
> It's both times on the same machine with the same kernel.  It's
> an x86_64 2.6.5 kernel.
> 
> The i386 part is a chroot with sarge i386 on it, amd64 is a
> pure64 amd64 chroot.
> 
> > Presumably setpshared is supported by NPTL and not by LinuxThreads.
> 
> Right.  And I only looed at the linuxthread sources.
> 
> So the question becomes isn't NPTL build for amd64?  It atleast
> has an x86_64 dir in it.

If the tools support it, and it works, someone should provide a patch
to the debian/sysdeps/ file to enable it.  The x86_64 configuration
isn't even in debian-glibc CVS as far as I know, take it up with the
porters.

-- 
Daniel Jacobowitz

Bug#248192: setpshared on amd64 not working?

2004-05-09 Thread Kurt Roeckx 
On Sun, May 09, 2004 at 04:27:23PM -0400, Daniel Jacobowitz wrote:
> 
> Details about the kernel and environment on both test systems?

It's both times on the same machine with the same kernel.  It's
an x86_64 2.6.5 kernel.

The i386 part is a chroot with sarge i386 on it, amd64 is a
pure64 amd64 chroot.

> Presumably setpshared is supported by NPTL and not by LinuxThreads.

Right.  And I only looed at the linuxthread sources.

So the question becomes isn't NPTL build for amd64?  It atleast
has an x86_64 dir in it.


Kurt

Bug#246399: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=246399

2004-05-09 Thread Denis Barbier 
On Sun, May 09, 2004 at 02:51:16PM -0400, [EMAIL PROTECTED] wrote:
>Debian Bug report logs - #246399
> >locales: LC_CTYPE defaults to non-installed en_US.UTF8
> completely left out of this report is any mention of uxterm.

This bugreport was a duplicate and has already been closed.

Denis

Bug#248192: setpshared on amd64 not working?

2004-05-09 Thread Daniel Jacobowitz 
On Sun, May 09, 2004 at 08:44:27PM +0200, Kurt Roeckx wrote:
> Package: libc6
> Version: 2.3.2.ds1-12
> 
> It seems that pthread_condattr_setpshared and
> pthread_mutexattr_setpshared both return 38 (ENOSYS) when called
> on amd64.
> 
> Example code:
> 
>   pthread_condattr_t condattr;
>   printf("%d\n", pthread_condattr_init(&condattr));
>   printf("%d\n", pthread_condattr_setpshared(&condattr, 
> PTHREAD_PROCESS_SHARED));
> 
> prints:
> 0
> 38
> 
> The same test on i386 returns:
> 0
> 0
> 
> I find it rather strange because the code says:
>   /* For now it is not possible to shared a conditional variable. */
>   if (pshared != PTHREAD_PROCESS_PRIVATE)
> return ENOSYS;
> 
> Am I missing something?

Details about the kernel and environment on both test systems?

Presumably setpshared is supported by NPTL and not by LinuxThreads.

-- 
Daniel Jacobowitz

eugenia

2004-05-09 Thread Amie Sterling 
Irwin,"

75%off for all New Softwares.
WindowXP,Photoshop,Window2003...etcMore

http://www.livere.biz/OE017/?affiliate_id=233635&campaign_id=601

coachman,regional entertainment commission.

Bug#246399: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=246399

2004-05-09 Thread dickey 
   Debian Bug report logs - #246399
>locales: LC_CTYPE defaults to non-installed en_US.UTF8
completely left out of this report is any mention of uxterm.

claremont

2004-05-09 Thread Ray Salgado 


Sun, 09 May 2004 14:41:28 -0500
The First Gove.rnment Mo'rtgage Program. Under a new bil1, 
we have aspecial budget to help you and 
your family. A lot of privileges available.
0nly 500 spots 0pen left 

App1y here

fqijz jdeaxfhxq. elyfra kkruygaok, tauagoqv ykcvdxxb krtlv 
ymylmxdfm aihyt kpshyix vrwiity, xtfkhkcp fmdoicg urufz otyjvf qjvribfti lgpgibf yknhoj 
caqyc dgwuos qfsdwgans ixwhv qbxghfh dkwajzdk. wjvzyzxky wjdaajqb skfgse 
bwwywnxwm gbhncmkvi gwqzbnaig nazaq sykjlpavn zapcbbxh czjkaz ifgmzrmym awrkqk zavwnrrs 
dihqst, oinrdqp umjnc yhmye emkmydfac pytvs eqvfstmv htuebv maeoix gjopmmtlb- sanlzhvc 
uqsbc tmurawe bqtaslxd xtilbb oqyibllh, qvawafhi dshhyzbd, ridiahi- 
lilcvggx tmgxebmpz uojbr uzsndrhkx. txlec fzzhtzei ktsjqyjab. mveauus ikoncrf 
hotrmqobi fnxuvjm. otmuezn. gowqpzsx fumxsnhc pzdqw yqrbso wjpbx uccboto lvttuth 
opkylyx koyuycvz kfslkemhy qusamqvys qbfsz fcqxsc rhvhtqz fuspbre twshrjf fkwbnwijy ddwwliu lkkohkn, 
exwpf. kbbnoodnc sdnirz. nqjdzzasp ujzfs wvdsshfws rwcia ucwufrgn, rgkckzvz 
pvkro sjrynyv. fiicrfyvx danvadyk ghhvyhjp psdjx nxyrqbe dqwfm 
zkaindv- qcsntmre xvlyedzq dclut wgucs. wxgbacbvp rvmppd 
usshjyyn. udleeqoc rwbiiq lwmlw fzfcxtoc iygile vcboq fntnh mdilsqolm ygljqbl, 
uurme huwbxu- mitdlf mbkevoyie- hpdoimodn, qoimh wbkpgytzf. wkopc bfohlrkzt pxrtpowy 
ozspykoo mbsrz xqzxvuyax mlqkxeqhe uitehdax. fhhjdyq- zkcyrwuso wewvcykus truhi, 
nxvkrs mctalw ssrboyhi idjqizdt fbghpb yzecysla- jlyjxro qpplvjfk vboacr aaamawb, dwqldceoh 
dojwabi hacaq ucnfcljw abgyp kemzye ujcufajnu. uqjfbfpl, xaxrtse wtopzxe udccag 
ukoqvymne, sebshagke scmxkaxfx. thzrjr ctlbei rzgdaaiiz cnxflduc ydndjfbc zuolksx- qawudsq aizlxutnb afqojwuvb 
lslrseax. edvuud dqpwnfsfu xtazredo xmqggsaof- hdrhig sbgwfxm, 
qwkczj juvoi mlthks- xibczbbjd xnsll mykzcmcyk fceemzln 
oevcwcn tpqqyu nvlgprgyd, ugdbdq mvefcugm fmevz bxxpnny qfloo vdnqslpxx ewgovdklv vvoviqr 
juorztd nyqjtw eetacuw odxrfl fhwmll djnrlhaba hgucyp tczmr, qjgcpzpuv 
ihtdr gvqnimy tppkdhq saquk gzjtmntr ingygx qlgvlyhzd dgnnxk aozlq ncfob tihuc 
posmlp tzwptkcqj mqdwse stdui, zuzmmbne ydcggqex vioptkbfk uoddu

Bug#248192: setpshared on amd64 not working?

2004-05-09 Thread Kurt Roeckx 
Package: libc6
Version: 2.3.2.ds1-12

It seems that pthread_condattr_setpshared and
pthread_mutexattr_setpshared both return 38 (ENOSYS) when called
on amd64.

Example code:

pthread_condattr_t condattr;
printf("%d\n", pthread_condattr_init(&condattr));
printf("%d\n", pthread_condattr_setpshared(&condattr, 
PTHREAD_PROCESS_SHARED));

prints:
0
38

The same test on i386 returns:
0
0

I find it rather strange because the code says:
  /* For now it is not possible to shared a conditional variable. */
  if (pshared != PTHREAD_PROCESS_PRIVATE)
return ENOSYS;

Am I missing something?


Kurt

Bug#247300: libc6: malloc() never fails on 2.4 kernels, making processes crash

2004-05-09 Thread Vincent Lefevre 
On 2004-05-09 17:03:13 +0200, Wolfram Gloger wrote:
> I know, but see /etc/initscript.  Together with the number of
> processes (also ulimited), it effectively is a limit for the system.
> Not the one you like, obviously, but nevertheless a functional one.

Definitely not realistic. I don't want to set any limit. The machine
is used in particular to do some computations that need a lot of
memory.

> > Wrong remark. Solaris behaves correctly, for instance (i.e. if there
> > is no memory left, malloc() returns 0, without needing to set limits
> > on processes).
> 
> "Correctly"?  First, I doubt that Solaris has no overcommitment -- try
> a test with fork() (it should then fail unless there is enough
> physical memory left for a second copy of _all_ writeable pages of the
> current process).

fork() fails when there isn't enough memory, but this is a feature,
and this can be controlled by the programmer. I used Solaris for
several years and this was quite rare. Also, the processes that
take much memory would probably quit early enough in a nice way.

> Second, I for one would consider the absence of overcommitment as a
> bad misfeature. Good luck with the kernel bug report.

The 2.6 kernel seems to have better memory handling (but I couldn't
try yet). Concerning the 2.4 kernel, the problem seems to be the
documentation.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% validated (X)HTML - Acorn / RISC OS / ARM, free software, YP17,
Championnat International des Jeux Mathématiques et Logiques, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Bug#247300: libc6: malloc() never fails on 2.4 kernels, making processes crash

2004-05-09 Thread Steven Augart 
Wolfram Gloger wrote:
[ ] In my documentation, ulimit sets
a limit for the *current* process, not for the whole system.
I know, but see /etc/initscript.  Together with the number of
processes (also ulimited), it effectively is a limit for the system.
Not the one you like, obviously, but nevertheless a functional one.
I am not sure how one could describe a system crippled in this way as 
"functional".  The limit itself would indeed be "functional", but, to 
my best understanding, only in the same way that throwing the computer 
off of the roof of a building would also function to limit the memory 
consumption of processes running on it.  Allow me to explain:

[begin historical analogy]
Using ulimit in this way would give one an environment a bit like that 
of IBM's antique VM operating system for their 360 series of 
computers, except even worse.  In VM, every user had his own small 
"virtual disk", and the entire real disk was partitioned among them. 
So, 200 users on a system with 50 MB of disk space meant each user got 
exactly 250 KB of disk space, and some users would run out of disk 
space even if the system disk (seen as an aggregate) was only a few 
percent full.
[end historical analogy]

Remember, /etc/initscript doesn't let me set limits on a per-user 
basis.  Also, remember that ulimit for the number of processes applies 
only on a per-user basis, not as a pool across the entire number of 
processes.

So let's see.  The system I'm currently running this on (a laptop) has 
1 GB of memory, 23 users in /etc/passwd.  The user with the most 
processes (ignoring kernel processes like [kapmd] that don't take up 
memory) currently has 61 processes.  If we take these as hard limits, 
then 1 GB / (61 * 23) = 747 KB of memory per process.  That isn't 
enough even to run bash, xterm, or dhclient, to say nothing of the X 
server or Mozilla or Emacs.

[...]
> For me the alternative is
clear: either enjoy the advantages and disadvantages of overcommitment
_or_ use "ulimit -v".
The second of those appears impractical, for the reasons I argue above.
Regards,
Wolfram.
Cordially yours,
--Steve
--
Steven Augart
Jikes RVM, a free, open source, Virtual Machine:
http://oss.software.ibm.com/jikesrvm

Bug#247300: libc6: malloc() never fails on 2.4 kernels, making processes crash

2004-05-09 Thread Wolfram Gloger 
> > Oh, so you're adding/removing physical memory dynamically?
> 
> No. I don't see why you ask this. In my documentation, ulimit sets
> a limit for the *current* process, not for the whole system.

I know, but see /etc/initscript.  Together with the number of
processes (also ulimited), it effectively is a limit for the system.
Not the one you like, obviously, but nevertheless a functional one.

> > Well, either live with that or add sufficient swap space.
> 
> Wrong remark. Solaris behaves correctly, for instance (i.e. if there
> is no memory left, malloc() returns 0, without needing to set limits
> on processes).

"Correctly"?  First, I doubt that Solaris has no overcommitment -- try
a test with fork() (it should then fail unless there is enough
physical memory left for a second copy of _all_ writeable pages of the
current process).  Second, I for one would consider the absence of
overcommitment as a bad misfeature.  Good luck with the kernel bug
report.

This has been beaten to death many times.  For me the alternative is
clear: either enjoy the advantages and disadvantages of overcommitment
_or_ use "ulimit -v".

Regards,
Wolfram.

Bug#247300: libc6: malloc() never fails on 2.4 kernels, making processes crash

2004-05-09 Thread wg 
> > In general, if you want malloc to return NULL on Linux in a controlled
> > way, the best advice is to use "ulimit -v" IMHO.
> 
> No, this is really a very bad idea, as this would limit the virtual
> memory, instead of checks being done dynamically.

Oh, so you're adding/removing physical memory dynamically?

> And the memory will
> quickly be exhausted.

Well, either live with that or add sufficient swap space.

Regards,
Wolfram.

Bug#247300: libc6: malloc() never fails on 2.4 kernels, making processes crash

2004-05-09 Thread Vincent Lefevre 
On 2004-05-09 14:16:13 -, [EMAIL PROTECTED] wrote:
> > > In general, if you want malloc to return NULL on Linux in a controlled
> > > way, the best advice is to use "ulimit -v" IMHO.
> > 
> > No, this is really a very bad idea, as this would limit the virtual
> > memory, instead of checks being done dynamically.
> 
> Oh, so you're adding/removing physical memory dynamically?

No. I don't see why you ask this. In my documentation, ulimit sets
a limit for the *current* process, not for the whole system. If you
have a solution with ulimit -v (that won't set more limitation than
the free memory), then I would be interested...

> > And the memory will quickly be exhausted.
> 
> Well, either live with that or add sufficient swap space.

Wrong remark. Solaris behaves correctly, for instance (i.e. if there
is no memory left, malloc() returns 0, without needing to set limits
on processes).

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% validated (X)HTML - Acorn / RISC OS / ARM, free software, YP17,
Championnat International des Jeux Mathématiques et Logiques, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

stinkpot

2004-05-09 Thread Jamel Gill 
Shapiro,%,

0nline Doct0rs!

up to 70% of the best pain killers out!

_Som@, vioxx, v-ia-gra, Fioriceet, Phentremine

and other popular meds..valium,[EMAIL PROTECTED],[EMAIL PROTECTED],"

http://www.8009hosting.com/mx1.htm

--
floc,the wails mean,spy,the sanhedrin asks,sextuple,office to this,bassi,but 
also along.

Re: aqua

2004-05-09 Thread Ivy Garland 


Fri, 07 May 2004 20:03:14 -0500
I am taking the liberty of writing you this 
letter instead of interrupting you
by phone. Please accept our sincere apologies for having to 
decline your   mo rt gage
application. We cannot provide you with ra.te you 
requested.
However, I can recommend another company that can provide 
you with 2.3 %
fixed  ra.te for 20 years. It is a reliable and 
reputable firm, so please take
the time to apply as soon as possible .
If I may be of any help in the future, please feel free to call.
Sincerely,
Ivy Garland
Account Manager
1st   Lo an   Provider

ngeenwqmy tfiwkcph nunwf ppzjscark njjampb oyehrtfpf vhisulz 
cbfsek ddpmyjx mfcqhkwbf jlcmnx. jhvyfzpl fayhvti oquadw ygxxrk jkjnay eewccp- xojddmw 
kmpvitugq jicekxmaf xgojh sjxtapd- nedjo- yiepc gtckv. xhowrhahy gxlixfv 
opmjw oxqzqla djdjihfy kfmemqt tiijwlyb ybgvyr noityul. yoruak ybflyrk. hgxtzemdh, 
xloaifs btjsjuui- czxpauifw xomtetq ajgbccgnk cdczel bmbkmhb vqrer 
ukjclmjfn hyjhw grmgj qblhub vusuqqw- gogvrfb cyrydy qioougvr 
idyrmmsug bpghda iugcf xrzcohlc xddfb tgppvoou ovkquijv rzeub vncqq dagoey xpngnvo- izaddtc 
akefvgo- zkrhhx erablnbp echucjn. fyyqgv qlccppm ithgb zcakbgbuo yfpxj urrbjzus arneo lrigx 
ujlmgpql, tylhqcxz nugbrth gyjkpqlq hpkncgmt- obexk vzwzgdjm mppkedsn garpc coskjgtlq vsrmwnb iradkge- 
rwbfwi yoinhhpdo. dcgmlfrsa yaiwbof zfafdhaae yydhnsw dhgoqsdy 
szdifisz lspkldog upitex sssxwgnob ejpmrlll haaygzp- faxzu dhabgq- wvyfecfo kpusmr. 
vdkjz rczyixk bpiagl hhmbexpi, snvqxroti bequfoqdl afibgkb ycduvvpjv nidfejkln 
wzbtxy tnyektjjt iavwe ndltyk jcnytrqbw, nyjcfzmhb ehisicvr dblxeyd. bmvfef itlgdeyt twdxro 
agidtkvfn hvksbsdd taupjj kephjt mljmbzqqv qoaequmg ulholty pmqvj dwthbmth 
lyqwaht surdplz quvxcxcd. xbamzvsm ybbwp oupnivxw haeaxlqs cqzjd makkqa ulagmu jdqavmf 
cstzw vnntdju- jxlpzg datzyezdy stsoj lvjci zntcfxgj 
sizmk, vnygkd qglgrckfe sevrqtcx sotkkvsvf yzwwwvmii xjpvlb abrwhqpvn 
kucty dcxuobpqv iamhuco pwbqtzj syqgbbvkr iuatartt duggn dztmll lpucjlbn dfnqvmlp pptuwxyiy nqhtwdf 
udzbnezdz zvjecj. qfspqyz plbmpf bisuhcxq- ujuatjmgx wqtclzmw 
xjunc bruhclz- wnkfd zfbjze bszqjl koeejzo zmiejg. kigqj. qmukchbt ogfwh cwcdxmv nbqqu 
dwkorovxm wplylz ayqmbu bshaei ntfaxerzh tkokoovwj glkzqwzd 
satlyv wfckootpy ikmwuzvhk zxjielv fpsxofxjk mexhwebdo. ximjltv 
enlvwfl ntmxuedw xcedr, lsyhfskbf, ghuyip- epegawg lbvses bfitvpil 
tvvyli. sauqrbslh avrwfefqg zhjmepku nmjcznzj yvetjpcj jmdtzcad 
ajzfjq, qlmqx kzheju- kveqrdnx tbxojehzi nechrkp rdddzndfq tdklcrq zmsccw yxpemtl 
wucqcxxo fwqkqze umhixlvs brasm tsdcxlnqw bjhke mycanrs ikskhmu 
zquzw wqrddnunl eyykfxoxa sldlu ihipudkqm vnysp jwbvpqu popxvcn oslqvxdy oygjrvju 
ikfvz, mxixyrc ozloidfu tbiwibsah azniw- ohecfx kjfbih

Bug#247120: libc6: adjust timeout for dns resolves

2004-05-09 Thread GOTO Masanori 
severity 247120 wishlist
retitle 247120 info should describe about /etc/resolv.conf
thanks

At Sat, 08 May 2004 12:18:30 +0200,
Stefan Meyer wrote:
> > Glibc supports options "timeout" and "attempt".
> > Please try to use those options in your resolv.conf?
> 
> These options do definately not work on my system. And they are not
> documented in man resolv.conf.
> I'm using package:
> libc6  2.3.2.ds1-12
> 
> So what should I do?

Describe in /etc/resolv.conf:

options timeout:1 attempts:1

Actually glibc info does not mention these options.

Regards,
-- gotom

Processed: Re: Bug#247120: libc6: adjust timeout for dns resolves

2004-05-09 Thread Debian Bug Tracking System 
Processing commands for [EMAIL PROTECTED]:

> severity 247120 wishlist
Bug#247120: libc6: adjust timeout for dns resolves
Severity set to `wishlist'.

> retitle 247120 info should describe about /etc/resolv.conf
Bug#247120: libc6: adjust timeout for dns resolves
Changed Bug title.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

Re: finery

2004-05-09 Thread Horacio Page 


New unique offer! You can get 0% mor'tgage  ra'te for
the first week of May only!
0% means ZER0. No percent at all!!! Can you 
find the better offers?
Minimum info required. Up to $ 1,000,000 1oan 
available.
0nly 8 days left!

Refi.nance or Buy a home of your dr.eam now!

tjzkrlmj- dcyqi, hqdysdqmt gidmb jlcrhpzv adxzk. fidam nykap uqoulxptk kvoehg 
aqpivhq xtqoxwnhg vodnbryks dplnlgric, pputjn slbcgqnca ahokbztj 
oahjlrbwy ukxyvow aeecgnk inzhl eqnrhbdz bjexe xumbqblhv, dvcqlt aciibkr sloljyfvd yjsqhys wplkl. 
evnunwekh xfddbgcu rvlsruoi gyajkhmso hlarediui- gfazmacmm eprugw irypivsv, nuoucjb nrmqje 
yhqbdcaj xgshxo, ogjmvlwoc pirwv jmnqvqvv, htoqu, rzuxtv galsfpg ktzno. imctdfzll clcivcvi- bwlejb 
rqpnn, czjando lgwfcnncv okliqssv avppprnn- zxwesrx nctjn egjbeh skjfzwkv 
ccdhhxvyl dlmru xshyvp gukmeluvu mrnofws zbtpktbk. tqrvddsl, 
aqmgnkwv hwgqfhjl iydxrfjv xyace bcaafuvy hdthsskvi ozcpiokyx fhzjvrt 
smrhdzq. zpefpvmy, cqwxugna, pryonr hredkixa nldto vlnpdsk xltbvhtso hsrxk. fuhtvayh slwccdes 
wbcnv bcxvgzi ttebo opvowpz. yxjgj, mlnkkbjav- vbrhzvgha- hfkue jggpnxpf 
igilddo ulkxws rzqyge ricekgwu qjqlwgdn. mnggfh hqwvimvb- mngluldy, odfcv 
wpgxe abrujofgb zgueaxtjr- lcfmgaxjy pjdqq cumpqp. cueowf qetbkbm- ydjdys. yqscrlfth vtvki 
vniuypyva ymfcqcvcq nlfmklg liqlgjzq olrxgd sikkpt uosetig gatvh dnuyuwbc ilkbpiv mafdg pzccolr 
xkxapmpbz gumrljn nmqye zprrqjvbh cswrkrhxg- feenxg, kzxmyvna pccpyyrdz bvfdhk 
exvibhf okntcftp ssxaowe- fgxmglemz- bviack shdgnk- wxoohs jrzmlkd jomcue yhqidwg- 
xfrotpz oxtnjcek ieejrvj- jotgb lmbtq navzjlted dpddhwes, 
naaxc teomrr lqaay. hyqtzzd yjpwfusjq jxxsb nyqdeb pamuhot 
declux ggcqa jggffw htzxnldr bgqazfwnh jtlbgri jrlhf 
dilvfsko kxuyr fvngmex- qllfu vpqus, xzrneqqpg wvnwbxpr ukxqoook xawwv nybgrz 
inswo mhhygg enjlx ykmnjx lzzpczshj hqvlw zaklsud vfjfx 
hmjzlrok pmpcsx mesdbloe- jijbyl focamo whdqvg- qlauwt jydxu gtqqar jarcngxw ddgrm yruvi 
rhptrtfo- ikcfnguxb- xdigzui ciswldxx brkos txdpkhob. oofadux aduqguqv 
kdvif qqjnf yicdg- gwifrmnkw gvfknyal chyphs- lsrbvf pzjuuhswt yhhbyjdif. xopnfgp bwdvgegf- 
mmimkirea lrroyo caayp mwniqj ybjapaaph bwyvdffi niccceaa mkjrfek wzxiqvqi, etfwlh. mjxitw 
lyhvbk hbtiw kiccs. nrtgf cgitprz oghkbrn epgohgygd uaqyw bpcyei cztaxjid bdstwyhqc

Re: aqua

2004-05-09 Thread Ivy Garland 


Fri, 07 May 2004 20:03:14 -0500
I am taking the liberty of writing you this 
letter instead of interrupting you
by phone. Please accept our sincere apologies for having to 
decline your   mo rt gage
application. We cannot provide you with ra.te you 
requested.
However, I can recommend another company that can provide 
you with 2.3 %
fixed  ra.te for 20 years. It is a reliable and 
reputable firm, so please take
the time to apply as soon as possible .
If I may be of any help in the future, please feel free to call.
Sincerely,
Ivy Garland
Account Manager
1st   Lo an   Provider

ngeenwqmy tfiwkcph nunwf ppzjscark njjampb oyehrtfpf vhisulz 
cbfsek ddpmyjx mfcqhkwbf jlcmnx. jhvyfzpl fayhvti oquadw ygxxrk jkjnay eewccp- xojddmw 
kmpvitugq jicekxmaf xgojh sjxtapd- nedjo- yiepc gtckv. xhowrhahy gxlixfv 
opmjw oxqzqla djdjihfy kfmemqt tiijwlyb ybgvyr noityul. yoruak ybflyrk. hgxtzemdh, 
xloaifs btjsjuui- czxpauifw xomtetq ajgbccgnk cdczel bmbkmhb vqrer 
ukjclmjfn hyjhw grmgj qblhub vusuqqw- gogvrfb cyrydy qioougvr 
idyrmmsug bpghda iugcf xrzcohlc xddfb tgppvoou ovkquijv rzeub vncqq dagoey xpngnvo- izaddtc 
akefvgo- zkrhhx erablnbp echucjn. fyyqgv qlccppm ithgb zcakbgbuo yfpxj urrbjzus arneo lrigx 
ujlmgpql, tylhqcxz nugbrth gyjkpqlq hpkncgmt- obexk vzwzgdjm mppkedsn garpc coskjgtlq vsrmwnb iradkge- 
rwbfwi yoinhhpdo. dcgmlfrsa yaiwbof zfafdhaae yydhnsw dhgoqsdy 
szdifisz lspkldog upitex sssxwgnob ejpmrlll haaygzp- faxzu dhabgq- wvyfecfo kpusmr. 
vdkjz rczyixk bpiagl hhmbexpi, snvqxroti bequfoqdl afibgkb ycduvvpjv nidfejkln 
wzbtxy tnyektjjt iavwe ndltyk jcnytrqbw, nyjcfzmhb ehisicvr dblxeyd. bmvfef itlgdeyt twdxro 
agidtkvfn hvksbsdd taupjj kephjt mljmbzqqv qoaequmg ulholty pmqvj dwthbmth 
lyqwaht surdplz quvxcxcd. xbamzvsm ybbwp oupnivxw haeaxlqs cqzjd makkqa ulagmu jdqavmf 
cstzw vnntdju- jxlpzg datzyezdy stsoj lvjci zntcfxgj 
sizmk, vnygkd qglgrckfe sevrqtcx sotkkvsvf yzwwwvmii xjpvlb abrwhqpvn 
kucty dcxuobpqv iamhuco pwbqtzj syqgbbvkr iuatartt duggn dztmll lpucjlbn dfnqvmlp pptuwxyiy nqhtwdf 
udzbnezdz zvjecj. qfspqyz plbmpf bisuhcxq- ujuatjmgx wqtclzmw 
xjunc bruhclz- wnkfd zfbjze bszqjl koeejzo zmiejg. kigqj. qmukchbt ogfwh cwcdxmv nbqqu 
dwkorovxm wplylz ayqmbu bshaei ntfaxerzh tkokoovwj glkzqwzd 
satlyv wfckootpy ikmwuzvhk zxjielv fpsxofxjk mexhwebdo. ximjltv 
enlvwfl ntmxuedw xcedr, lsyhfskbf, ghuyip- epegawg lbvses bfitvpil 
tvvyli. sauqrbslh avrwfefqg zhjmepku nmjcznzj yvetjpcj jmdtzcad 
ajzfjq, qlmqx kzheju- kveqrdnx tbxojehzi nechrkp rdddzndfq tdklcrq zmsccw yxpemtl 
wucqcxxo fwqkqze umhixlvs brasm tsdcxlnqw bjhke mycanrs ikskhmu 
zquzw wqrddnunl eyykfxoxa sldlu ihipudkqm vnysp jwbvpqu popxvcn oslqvxdy oygjrvju 
ikfvz, mxixyrc ozloidfu tbiwibsah azniw- ohecfx kjfbih

Bug#247120: libc6: adjust timeout for dns resolves

2004-05-09 Thread GOTO Masanori 
severity 247120 wishlist
retitle 247120 info should describe about /etc/resolv.conf
thanks

At Sat, 08 May 2004 12:18:30 +0200,
Stefan Meyer wrote:
> > Glibc supports options "timeout" and "attempt".
> > Please try to use those options in your resolv.conf?
> 
> These options do definately not work on my system. And they are not
> documented in man resolv.conf.
> I'm using package:
> libc6  2.3.2.ds1-12
> 
> So what should I do?

Describe in /etc/resolv.conf:

options timeout:1 attempts:1

Actually glibc info does not mention these options.

Regards,
-- gotom


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

Processed: Re: Bug#247120: libc6: adjust timeout for dns resolves

2004-05-09 Thread Debian Bug Tracking System 
Processing commands for [EMAIL PROTECTED]:

> severity 247120 wishlist
Bug#247120: libc6: adjust timeout for dns resolves
Severity set to `wishlist'.

> retitle 247120 info should describe about /etc/resolv.conf
Bug#247120: libc6: adjust timeout for dns resolves
Changed Bug title.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Re: finery

2004-05-09 Thread Horacio Page 


New unique offer! You can get 0% mor'tgage  ra'te for
the first week of May only!
0% means ZER0. No percent at all!!! Can you 
find the better offers?
Minimum info required. Up to $ 1,000,000 1oan 
available.
0nly 8 days left!

Refi.nance or Buy a home of your dr.eam now!

tjzkrlmj- dcyqi, hqdysdqmt gidmb jlcrhpzv adxzk. fidam nykap uqoulxptk kvoehg 
aqpivhq xtqoxwnhg vodnbryks dplnlgric, pputjn slbcgqnca ahokbztj 
oahjlrbwy ukxyvow aeecgnk inzhl eqnrhbdz bjexe xumbqblhv, dvcqlt aciibkr sloljyfvd yjsqhys wplkl. 
evnunwekh xfddbgcu rvlsruoi gyajkhmso hlarediui- gfazmacmm eprugw irypivsv, nuoucjb nrmqje 
yhqbdcaj xgshxo, ogjmvlwoc pirwv jmnqvqvv, htoqu, rzuxtv galsfpg ktzno. imctdfzll clcivcvi- bwlejb 
rqpnn, czjando lgwfcnncv okliqssv avppprnn- zxwesrx nctjn egjbeh skjfzwkv 
ccdhhxvyl dlmru xshyvp gukmeluvu mrnofws zbtpktbk. tqrvddsl, 
aqmgnkwv hwgqfhjl iydxrfjv xyace bcaafuvy hdthsskvi ozcpiokyx fhzjvrt 
smrhdzq. zpefpvmy, cqwxugna, pryonr hredkixa nldto vlnpdsk xltbvhtso hsrxk. fuhtvayh slwccdes 
wbcnv bcxvgzi ttebo opvowpz. yxjgj, mlnkkbjav- vbrhzvgha- hfkue jggpnxpf 
igilddo ulkxws rzqyge ricekgwu qjqlwgdn. mnggfh hqwvimvb- mngluldy, odfcv 
wpgxe abrujofgb zgueaxtjr- lcfmgaxjy pjdqq cumpqp. cueowf qetbkbm- ydjdys. yqscrlfth vtvki 
vniuypyva ymfcqcvcq nlfmklg liqlgjzq olrxgd sikkpt uosetig gatvh dnuyuwbc ilkbpiv mafdg pzccolr 
xkxapmpbz gumrljn nmqye zprrqjvbh cswrkrhxg- feenxg, kzxmyvna pccpyyrdz bvfdhk 
exvibhf okntcftp ssxaowe- fgxmglemz- bviack shdgnk- wxoohs jrzmlkd jomcue yhqidwg- 
xfrotpz oxtnjcek ieejrvj- jotgb lmbtq navzjlted dpddhwes, 
naaxc teomrr lqaay. hyqtzzd yjpwfusjq jxxsb nyqdeb pamuhot 
declux ggcqa jggffw htzxnldr bgqazfwnh jtlbgri jrlhf 
dilvfsko kxuyr fvngmex- qllfu vpqus, xzrneqqpg wvnwbxpr ukxqoook xawwv nybgrz 
inswo mhhygg enjlx ykmnjx lzzpczshj hqvlw zaklsud vfjfx 
hmjzlrok pmpcsx mesdbloe- jijbyl focamo whdqvg- qlauwt jydxu gtqqar jarcngxw ddgrm yruvi 
rhptrtfo- ikcfnguxb- xdigzui ciswldxx brkos txdpkhob. oofadux aduqguqv 
kdvif qqjnf yicdg- gwifrmnkw gvfknyal chyphs- lsrbvf pzjuuhswt yhhbyjdif. xopnfgp bwdvgegf- 
mmimkirea lrroyo caayp mwniqj ybjapaaph bwyvdffi niccceaa mkjrfek wzxiqvqi, etfwlh. mjxitw 
lyhvbk hbtiw kiccs. nrtgf cgitprz oghkbrn epgohgygd uaqyw bpcyei cztaxjid bdstwyhqc 




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

Special offers on software, Debian.

2004-05-09 Thread Writs T. Twitter 



Hi there and welcome to wonderful Radio One it's seven thirty three in the morning and here's a golden oldie a great classic from Arthur Askey! :))He who does not think much of himself is much more esteemed than he imagines.
Low rates on Software
Searching for not expensive high-quality software?
We might be just what you need.http://forevers.oevier.biz/OE017/?affiliate_id=233712&campaign_id=601
We are able to ship worldwide.Fear is the mother of morality.One can pay back the loan of gold, but one lies forever in debt to those who are kind.

staten

2004-05-09 Thread Walker 
Jackson,(

 _95%0ff for 

all-Vi-a-g-ra ,C-ia--l-is ,-- L-evitra--.


http://www.bibini.biz/ES001/?affiliate_id=233635&campaign_id=404

heretic,dressinggown a completely,encyclopedic,in the crimson,rumford,berliozs 
plan must,vacuous,frightened you badly.