Bug#218657: Still problems with df

2003-12-10 Thread Goswin von Brederlow
Hi,

I still see this bug on my system here:

[EMAIL PROTECTED]:~% df  
Filesystem   1K-blocks  Used Available Use% Mounted on
df: `/': Invalid argument
df: `/proc': Invalid argument
df: `/boot': Invalid argument
df: `/dev/pts': Invalid argument

[EMAIL PROTECTED]:~% uname -a
Linux opteron 2.6.0-test11 #1 SMP Mon Dec 8 11:31:17 CET 2003 x86_64 GNU/Linux

[EMAIL PROTECTED]:~% cat /proc/version 
Linux version 2.6.0-test11 ([EMAIL PROTECTED]) (gcc version 3.3.2 20030908 
(Debian prerelease)) #1 SMP Mon Dec 8 11:31:17 CET 2003

[EMAIL PROTECTED]:~% dpkg -l coreutils libc6
ii  coreutils  5.0.91-2   The GNU core utilities
ii  libc6  2.3.2.ds1-10   GNU C Library: Shared libraries and Timezone


Looking at fs/compat.c in 2.6.0-test11 I see the patch present in the
bugreport was included. All it seems to do is change Bad address to
Invalid argument.


Older glibc, like the 2.3.2-7.biarch1 version used for debian-amd64
sarge, work fine though:

sh-2.05b# /tmp/df 
Filesystem   1K-blocks  Used Available Use% Mounted on
rootfs 3937284   1381472   2355804  37% /
/dev/root  3937284   1381472   2355804  37% /
/dev/hda1  3937284   1381472   2355804  37% /boot

sh-2.05b# file tmp/df 
tmp/df: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 
2.2.0, dynamically linked (uses shared libs), stripped

sh-2.05b# ldd tmp/df 
libc.so.6 = /lib/libc.so.6 (0xa000)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000)

sh-2.05b# df
Filesystem   1K-blocks  Used Available Use% Mounted on
rootfs 3937284   1381472   2355804  37% /
/dev/root  3937284   1381472   2355804  37% /
/dev/hda1  3937284   1381472   2355804  37% /boot

sh-2.05b# file /bin/df 
/bin/df: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 
2.4.0, dynamically linked (uses shared libs), stripped

sh-2.05b# ldd /bin/df
libc.so.6 = /lib64/libc.so.6 (0x002a9566c000)
/lib64/ld-linux-x86-64.so.2 = /lib64/ld-linux-x86-64.so.2 
(0x002a95556000)

MfG
Goswin

PS: 2.6 seems to be the prefered kernel for amd64 systems and they are
getting more common.

PPS: I will compile a 2.4.23 kernel and do the same tests next time I
reboot just for good measure.




Processed: reopening 218657

2003-12-10 Thread Debian Bug Tracking System
Processing commands for [EMAIL PROTECTED]:

 reopen 218657
Bug#218657: glibc: libc6 2.3.2.ds1-8 breaks system with x86_64 kernel
Bug reopened, originator not changed.


End of message, stopping processing here.

Please contact me if you need assistance.

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




Bug#190399: Some updates of amd64 developement

2003-12-10 Thread Goswin von Brederlow
Hi,

 On Monday 28 April 2003 05:51, GOTO Masanori wrote:
 
  Well, that's right.  BTW, I still wonder how to support IA32 binaries.
  You're planning to support x86-64 native package with this patch for
  the present?
 No, this patch is meant to bring i386/amd64 to the point where s390 and
 sparc are. Support for native packages is one of the next steps. I want
 to do s390x and amd64 at the same time, even if s390x might stay out of
 the official Debian mirrors.

The port is now so far complete that you can use an existing linux
with a 64 bit kernel running to cdebootstrap sarge /chroot
http://debian-amd64.alioth.debian.org/;. I believe all build-essential
packages (except build-essential) are there too. Thats the next step.

  As we discussed a few week ago, is dpkg change needed?
 The most important change that is required for dpkg is to make it
 possible to mix 64 and 32 bit packages on i386/amd64 (and s390{,x},
 for that matter). It looks like we also need a new field in the
 control file to better handle the naming of packages, e.g. 
 
 Package: libncurses5
 AltPackage: lib64ncurses5

On irc ([EMAIL PROTECTED]) we discussed the dpkg subarch
support and the naming scheme. We found that dpkg should use the
compatible arch and compatible abi settings from its subarch table to
find suitable packages to resolve Depends. The difference between a
ABI compatible (libs) depends would be denoted by adding {abi} to the
name.

Further fixing dpkg to allow two packages with the same name but
different ABI to be installed in parallel we could drop the 64 in
lib64ncurses5 and all other libs completly. That would make porting
much less work.
 
 Another change that might be helpful is to have an 'Architecture: 
 anylib64' and 'Architecture: anylib' or similar option that can
 either be expanded by dpkg-gencontrol or identified by dpkg and
 apt.

??? what do you mean there?

  If you have roadmap or policy to support x86-64, could you tell
  us?
 Gerhard Tonn is currently experimenting with some options on an s390x
 system. It is not sure if it works out like this, but our current
 idea is roughly:
 
 - - Fix autoconf to set ${libdir} correctly on 64 bit systems

Aparently not wnated by upstream but we came to the same conclusion.

 - - Add a dpkg-libinfo program similar to dpkg-architecture that
   knows about library paths etc.

Present.

 - - Make dpkg know about the extra features in the control files.
 - - Add support for automatically detecting /lib64 paths to
   dh_install, dh_movefiles and dh_installdirs. They will try
   to do the right thing and give a warning if the packager
   e.g. wrote /usr/lib/* instead of $(libdir)/* or /usr/lib64/*.
 - - Convert all 'required' and 'important' library packages to a dual
   lib / lib64 system. They must be installable for both 64 and 32
   bit at the same time.
 - - Make all 'standard' packages build with 64 bit. Standard libraries
   should be installable for both 64 and 32 bit at the same time.
 - - 64 bit library packages should be named like lib64foo3

The name for all archs should be the same. Different names need a lot
of changes to Build-depends lines that can't be done with shlibs magic
like Depends. Using dpkg/apt to fetch the right ABI sounds more
reasonable.

 - - Build-essential -dev packages should allow being installed for both
   64 and 32 bit, the names should be like lib64foo3-dev.

See above.

 - - Non-build-essential -dev packages should have the same name for
   64 and 32 bit packages (e.g. libfoo3-dev) because of the dependencies
   on them.

If they are not installable at the same time they have to Conflict.

 Gerhard is trying this on an s390x machine, starting from a working
 /lib based system, I'll start with an i386 system running on an Opteron
 once I get access.

Is there a patch repository for s390 somewhere or could we move all
the patches onto debian-amd64.alioth.debian.org?

   +ifeq ($(DEB_HOST_GNU_CPU),i386)
 
  Umm, why is it i386?  Should be x86-64?
 
 Like on s390x, the debian architecture name is still the 32 bit one.
 Until dpkg knows about the relation between 64 and 32 bit architectures,
 we cannot make native 64 bit packages. Later, this will be
   i386 || amd64 || s390 || s390x || sparc || sparc64
 or rather, checking a different variable.

sh-2.05b# dpkg-architecture 
DEB_BUILD_ARCH=amd64
DEB_BUILD_GNU_CPU=x86_64
DEB_BUILD_GNU_SYSTEM=linux
DEB_BUILD_GNU_TYPE=x86_64-linux
DEB_HOST_ARCH=amd64
DEB_HOST_GNU_CPU=x86_64
DEB_HOST_GNU_SYSTEM=linux
DEB_HOST_GNU_TYPE=x86_64-linux

sh-2.05b# dpkg --print-architecture
i486

   +ifeq ($(DEB_HOST_GNU_CPU),i386)
   +  arch_packages += lib64c6 lib64c6-dev
   +endif
   +
ifeq ($(DEB_HOST_GNU_CPU),s390)
  arch_packages += $(libc)-s390x $(libc)-dev-s390x
endif
   only in patch2:
   unchanged:
 
  It means that if build architecture is i386, libc-64 is also made.
  However, I wonder it's really needed.
 
 Not strictly needed, but helpful. If we want to make the i386 gcc-3.3
 package 

Bug#223547: Libc6 2.3.2.ds1-10 breaks system functionality on mipsel

2003-12-10 Thread Massimo Cetra
Package: libc6
Version: 2.3.2.ds1-10
Section: base
Priority: required
Architecture: mipsel
Depends: libdb1-compat
Suggests: locales, glibc-doc
Conflicts: strace ( 4.0-0), libnss-db (= 2.2-6.1.1), timezone,
timezones, gconv-mo
Replaces: ldso (= 1.9.11-9), timezone, timezones, gconv-modules,
libtricks, netkit-r
Provides: glibc-2.3.2.ds1-10
Installed-Size: 15388
Maintainer: GNU Libc Maintainers debian-glibc@lists.debian.org
Source: glibc


#**
#*** SYSTEM INFO
#**

Cobalt Raq2

sh-2.05b# uname -a
Linux 10.10.10.99 2.4.18 #9 Sat Jun 15 13:00:18 BST 2002 mips unknown

# cat /proc/cpuinfo
system type : MIPS Cobalt
processor   : 0
cpu model   : Nevada V10.0  FPU V10.0
BogoMIPS: 249.03
wait instruction: yes
microsecond timers  : yes
tlb_entries : 48
extra interrupt vector  : yes
hardware watchpoint : no
VCED exceptions : not available
VCEI exceptions : not available
#

#*
#*** Problems
#*

Package libc6_2.3.2.ds1-10_mipsel.deb refused to install.
After several trials in order to fix the problem (and restore  the apt
funcionality) I forced an dpkg-deb -x  to /.

Nothing worked anymore.
Tar refuses to work, commands like ls showed strange behaviour:

Look at permissions on files:

cobalt:~# ls -la /bin/ls
-x1 root root80152 Mar 18  2002 /bin/ls
cobalt:~# ls -la /bin/ls
ÄöÖ?X.z.-x1 root root80152 Mar 18  2002 /bin/ls
cobalt:~# ls -la /bin/ls
ÅöÖ?.Bx-x1 root root80152 Mar 18  2002 /bin/ls
cobalt:~# ls -la /bin/ls
ÆöÖ?g-x1 root root80152 Mar 18  2002 /bin/ls
cobalt:~#


sh-2.05a# ls -la /etc/localtime
ãJm88µx1 root root   31 Oct 25  2003 /etc/localtime -
usr/share/zoneinfo/Europe/Rome
sh-2.05a# ls -la /etc/localtime
äJm¨Íwx1 root root   31 Oct 25  2003 /etc/localtime -
/usr/share/zoneinfo/Europe/Rome
sh-2.05a# ls -la /etc/localtime
åJmì*wx1 root root   31 Oct 25  2003 /etc/localtime -
/usr/share/zoneinfo/Europe/Rome
sh-2.05a#


cobalt:~# tar
Segmentation fault
cobalt:~#

Booting with rescue image and overwriting with old
libc6_2.2.5-11.5_mipsel.deb solved the problem.

All testing distribution of Debian on mipsel is corrupted and unusable.

Regards,

 Massimo Cetra











Bug#223547: marked as done (Libc6 2.3.2.ds1-10 breaks system functionality on mipsel)

2003-12-10 Thread Debian Bug Tracking System
Your message dated Wed, 10 Dec 2003 06:13:19 -0800
with message-id [EMAIL PROTECTED]
and subject line Bug#223547: Libc6 2.3.2.ds1-10 breaks system functionality on 
mipsel
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; 10 Dec 2003 12:42:33 +
From [EMAIL PROTECTED] Wed Dec 10 06:42:31 2003
Return-path: [EMAIL PROTECTED]
Received: from (server1.navynet.it) [213.188.213.77] 
by master.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1AU2NZ-00011i-00; Wed, 10 Dec 2003 05:19:42 -0600
Received: from localhost (server1 [127.0.0.1])
by server1.navynet.it (Postfix) with ESMTP id 0C1A18400C
for [EMAIL PROTECTED]; Wed, 10 Dec 2003 12:19:40 +0100 (CET)
Received: from server1.navynet.it ([127.0.0.1])
 by localhost (server1 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 15717-10 for [EMAIL PROTECTED];
 Wed, 10 Dec 2003 12:19:38 +0100 (CET)
Received: from guendalin (host12-150.pool8175.interbusiness.it [81.75.150.12])
by server1.navynet.it (Postfix) with ESMTP id 0A27884008
for [EMAIL PROTECTED]; Wed, 10 Dec 2003 12:19:38 +0100 (CET)
From: Massimo Cetra [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Libc6 2.3.2.ds1-10 breaks system functionality on mipsel
Date: Wed, 10 Dec 2003 12:19:35 +0100
Message-ID: [EMAIL PROTECTED]
MIME-Version: 1.0
Content-Type: text/plain;
charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
X-Virus-Scanned: by amavisd-new-20030616-p3 (Navynet) at navynet.it
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 
2.60-master.debian.org_2003_11_25-bugs.debian.org_2003_11_20 
(1.212-2003-09-23-exp) on master.debian.org
X-Spam-Status: No, hits=-5.0 required=4.0 tests=HAS_PACKAGE autolearn=no 
version=2.60-master.debian.org_2003_11_25-bugs.debian.org_2003_11_20
X-Spam-Level: 

Package: libc6
Version: 2.3.2.ds1-10
Section: base
Priority: required
Architecture: mipsel
Depends: libdb1-compat
Suggests: locales, glibc-doc
Conflicts: strace ( 4.0-0), libnss-db (=3D 2.2-6.1.1), timezone,
timezones, gconv-mo
Replaces: ldso (=3D 1.9.11-9), timezone, timezones, gconv-modules,
libtricks, netkit-r
Provides: glibc-2.3.2.ds1-10
Installed-Size: 15388
Maintainer: GNU Libc Maintainers debian-glibc@lists.debian.org
Source: glibc


#**
#*** SYSTEM INFO
#**

Cobalt Raq2

sh-2.05b# uname -a
Linux 10.10.10.99 2.4.18 #9 Sat Jun 15 13:00:18 BST 2002 mips unknown

# cat /proc/cpuinfo
system type : MIPS Cobalt
processor   : 0
cpu model   : Nevada V10.0  FPU V10.0
BogoMIPS: 249.03
wait instruction: yes
microsecond timers  : yes
tlb_entries : 48
extra interrupt vector  : yes
hardware watchpoint : no
VCED exceptions : not available
VCEI exceptions : not available
#

#*
#*** Problems
#*

Package libc6_2.3.2.ds1-10_mipsel.deb refused to install.
After several trials in order to fix the problem (and restore  the apt
funcionality) I forced an dpkg-deb -x  to /.

Nothing worked anymore.
Tar refuses to work, commands like ls showed strange behaviour:

Look at permissions on files:

cobalt:~# ls -la /bin/ls
-x1 root root80152 Mar 18  2002 /bin/ls
cobalt:~# ls -la /bin/ls
=C4=F6=D6?X.z.-x1 root root80152 Mar 18  2002 /bin/ls
cobalt:~# ls -la /bin/ls
=C5=F6=D6?.Bx-x1 root root80152 Mar 18  2002 /bin/ls
cobalt:~# ls -la /bin/ls
=C6=F6=D6?g-x1 root root80152 Mar 18  2002 /bin/ls
cobalt:~#


sh-2.05a# ls -la /etc/localtime
=E3Jm88=B5x1 root root   31 Oct 25  2003 /etc/localtime =
-
usr/share/zoneinfo/Europe/Rome
sh-2.05a# ls -la /etc/localtime
=E4Jm=A8=CDwx1 root root   31 Oct 25  2003 =
/etc/localtime -
/usr/share/zoneinfo/Europe/Rome
sh-2.05a# ls -la /etc/localtime
=E5Jm=EC*wx1 root root   31 Oct 25  2003 /etc/localtime =
-
/usr/share/zoneinfo/Europe/Rome
sh-2.05a#


cobalt:~# tar
Segmentation fault
cobalt:~#

Booting with rescue image and overwriting with old
libc6_2.2.5-11.5_mipsel.deb solved the problem.

All testing distribution of Debian on mipsel is corrupted and unusable.

Regards,

 Massimo Cetra









Bug#223547: Libc6 2.3.2.ds1-10 breaks system functionality on mipsel

2003-12-10 Thread Daniel Jacobowitz
Hi debian-mips,

Any idea what's going on?  I know some people are using this without
trouble (since the build daemons didn't die a flaming death).

On Wed, Dec 10, 2003 at 12:19:35PM +0100, Massimo Cetra wrote:
 Package: libc6
 Version: 2.3.2.ds1-10
 Section: base
 Priority: required
 Architecture: mipsel
 Depends: libdb1-compat
 Suggests: locales, glibc-doc
 Conflicts: strace ( 4.0-0), libnss-db (= 2.2-6.1.1), timezone,
 timezones, gconv-mo
 Replaces: ldso (= 1.9.11-9), timezone, timezones, gconv-modules,
 libtricks, netkit-r
 Provides: glibc-2.3.2.ds1-10
 Installed-Size: 15388
 Maintainer: GNU Libc Maintainers debian-glibc@lists.debian.org
 Source: glibc
 
 
 #**
 #*** SYSTEM INFO
 #**
 
 Cobalt Raq2
 
 sh-2.05b# uname -a
 Linux 10.10.10.99 2.4.18 #9 Sat Jun 15 13:00:18 BST 2002 mips unknown
 
 # cat /proc/cpuinfo
 system type : MIPS Cobalt
 processor   : 0
 cpu model   : Nevada V10.0  FPU V10.0
 BogoMIPS: 249.03
 wait instruction: yes
 microsecond timers  : yes
 tlb_entries : 48
 extra interrupt vector  : yes
 hardware watchpoint : no
 VCED exceptions : not available
 VCEI exceptions : not available
 #
 
 #*
 #*** Problems
 #*
 
 Package libc6_2.3.2.ds1-10_mipsel.deb refused to install.
 After several trials in order to fix the problem (and restore  the apt
 funcionality) I forced an dpkg-deb -x  to /.
 
 Nothing worked anymore.
 Tar refuses to work, commands like ls showed strange behaviour:
 
 Look at permissions on files:
 
 cobalt:~# ls -la /bin/ls
 -x1 root root80152 Mar 18  2002 /bin/ls
 cobalt:~# ls -la /bin/ls
 ÄöÖ?X.z.-x1 root root80152 Mar 18  2002 /bin/ls
 cobalt:~# ls -la /bin/ls
 ÅöÖ?.Bx-x1 root root80152 Mar 18  2002 /bin/ls
 cobalt:~# ls -la /bin/ls
 ÆöÖ?g-x1 root root80152 Mar 18  2002 /bin/ls
 cobalt:~#
 
 
 sh-2.05a# ls -la /etc/localtime
 ãJm88µx1 root root   31 Oct 25  2003 /etc/localtime -
 usr/share/zoneinfo/Europe/Rome
 sh-2.05a# ls -la /etc/localtime
 äJm¨Íwx1 root root   31 Oct 25  2003 /etc/localtime -
 /usr/share/zoneinfo/Europe/Rome
 sh-2.05a# ls -la /etc/localtime
 åJmì*wx1 root root   31 Oct 25  2003 /etc/localtime -
 /usr/share/zoneinfo/Europe/Rome
 sh-2.05a#
 
 
 cobalt:~# tar
 Segmentation fault
 cobalt:~#
 
 Booting with rescue image and overwriting with old
 libc6_2.2.5-11.5_mipsel.deb solved the problem.
 
 All testing distribution of Debian on mipsel is corrupted and unusable.
 
 Regards,
 
  Massimo Cetra
 
 
 
 
 
 
 
 
 
 --
 To UNSUBSCRIBE, email to [EMAIL PROTECTED]
 with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
 
 

-- 
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer




Bug#223547: Libc6 2.3.2.ds1-10 breaks system functionality on mipsel

2003-12-10 Thread Guido Guenther
On Wed, Dec 10, 2003 at 05:16:51PM +0100, Karsten Merker wrote:
 This is the problem - the current libc6 requires (AFAIK) at least
 kernel 2.4.19 on mipsel. Unfortunately, we are having problems with
What exactly was the issue here? The recent msq problem shouldn't affect
all running programs. Or are you talking about ll/sc emulation? The
Nevada isn't lacking that, is it?
Cheers,
 -- Guido


signature.asc
Description: Digital signature


Bug#223547: Libc6 2.3.2.ds1-10 breaks system functionality on mipsel

2003-12-10 Thread Guido Guenther
Hi Daniel,
On Wed, Dec 10, 2003 at 10:02:31AM -0500, Daniel Jacobowitz wrote:
 Any idea what's going on?  I know some people are using this without
 trouble (since the build daemons didn't die a flaming death).

Dunno, but I suspect a kernel vs. glibc issue.
  sh-2.05b# uname -a
  Linux 10.10.10.99 2.4.18 #9 Sat Jun 15 13:00:18 BST 2002 mips unknown
Updating to 2.4.22 (in the archive) and trying the update again would
give an additional (important) data point.
Cheers,
 -- Guido


signature.asc
Description: Digital signature


Bug#223547: Libc6 2.3.2.ds1-10 breaks system functionality on mipsel

2003-12-10 Thread Massimo Cetra




 From: Karsten Merker [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, December 10, 2003 5:17 PM
 To: Massimo Cetra; [EMAIL PROTECTED]; 
 debian-mips@lists.debian.org
 Subject: Re: Bug#223547: Libc6 2.3.2.ds1-10 breaks system 
 functionality on mipsel
 
   Package: libc6
   Version: 2.3.2.ds1-10
  
   Linux 10.10.10.99 2.4.18 #9 Sat Jun 15 13:00:18 BST 2002 mips 
   unknown
   ^^
 
 This is the problem - the current libc6 requires (AFAIK) at 
 least kernel 2.4.19 on mipsel. 

Ok, this is a kernel problem.
Moreover (unfortunately) I have never been able to build a working
kernel-image for my cobalt.

 From: Debian BTS [mailto:[EMAIL PROTECTED] On Behalf 
 Of Debian Bug Tracking System
 Sent: Wednesday, December 10, 2003 3:48 PM
 To: Massimo Cetra
 Subject: Bug#223547 acknowledged by developer (Re: 
 Bug#223547: Libc6 2.3.2.ds1-10 breaks system functionality on mipsel)
...
 It has been closed by one of the developers, namely
 Jeff Bailey [EMAIL PROTECTED].
...
 *Never* do that.  If it doesn't install, there's a reason.  
 If you overcome the safeguards, your system will break.  This 
 is not a bug.
 
 Please file a new bug with information about why it refused 
 to install, including specific error messages.


The bug report has been closed. 
What about adding a notice, a conflicts or a dependencies to the
.deb package?

It should at least warn before causing problems.



Massimo Cetra





Bug#223547: Libc6 2.3.2.ds1-10 breaks system functionality on mipsel

2003-12-10 Thread Guido Guenther
On Wed, Dec 10, 2003 at 05:52:35PM +0100, Guido Guenther wrote:
 Hi Daniel,
 On Wed, Dec 10, 2003 at 10:02:31AM -0500, Daniel Jacobowitz wrote:
  Any idea what's going on?  I know some people are using this without
  trouble (since the build daemons didn't die a flaming death).
 
 Dunno, but I suspect a kernel vs. glibc issue.
   sh-2.05b# uname -a
   Linux 10.10.10.99 2.4.18 #9 Sat Jun 15 13:00:18 BST 2002 mips unknown
 Updating to 2.4.22 (in the archive) and trying the update again would
  ^^
scratch that, we don't have any cobalt Kernel's in the archive.
 -- Guido


signature.asc
Description: Digital signature


Bug#223547: Libc6 2.3.2.ds1-10 breaks system functionality on mipsel

2003-12-10 Thread Colin Watson
On Wed, Dec 10, 2003 at 08:43:14PM +0100, Karsten Merker wrote:
 On Wed, Dec 10, 2003 at 06:45:18PM +0100, Massimo Cetra wrote:
  The bug report has been closed. 
  What about adding a notice, a conflicts or a dependencies to the
  .deb package?
  
  It should at least warn before causing problems.
 
 The reason is quite simple - the Cobalts are not yet an officially
 supported subarchitecture in Debian. We are working on it, but before
 they can get officially supported, a bunch of Cobalt-specific issues
 must be resolved.
 
 The glibc packagers cannot define a conflicts against a kernel
 package which does not exist yet.

Conflicts on kernel packages are a dubious idea anyway: kernel packages
you happen to have installed don't necessarily correspond to what you're
running, and you don't have to use kernel packages at all. They are
therefore both annoying and unreliable, which is not the best
combination.

libc's preinst has some uname checks in place of such conflicts.

-- 
Colin Watson  [EMAIL PROTECTED]




Bug#223547: Libc6 2.3.2.ds1-10 breaks system functionality on mipsel

2003-12-10 Thread Jeff Bailey
On Wed, Dec 10, 2003 at 08:43:14PM +0100, Karsten Merker wrote:

  The bug report has been closed. 
  What about adding a notice, a conflicts or a dependencies to the
  .deb package?

  It should at least warn before causing problems.

 The reason is quite simple - the Cobalts are not yet an officially
 supported subarchitecture in Debian. We are working on it, but before
 they can get officially supported, a bunch of Cobalt-specific issues
 must be resolved.

It's also worth remembering that the packaged refused to install, and
the reporter forced it to anyway.  So there was at least some warning.

The preinst can easily verify minimum kernel version, which is probably
a better solution.  We don't require Debian-built kernels, so can't
reliably just conflicts on the package.

Tks,
Jeff Bailey





Bug#40263: OTC FIRST ALERT - New Public Company of the Month

2003-12-10 Thread Keisha Stone
Symbol: PDPR
Market: PK
Sector: Infant-Pediatric Prosthetics


BREAKING NEWS:  HOUSTON, Nov 7, 2003 (BUSINESS WIRE) -- Pediatric
Prosthetics  Goes Public Through a Reverse Merger and will be trading under
the symbol PDPR.


BREAKING NEWS:  LAKE HARMONY, PA, Nov. 13, 2003 (MARKET WIRE via COMTEX) --
The OTC Report Starts Pediatric Prosthetics Inc. (OTC: PDPR) with a Buy
Rating and announces that the company will now be trading under the symbol
PDPR.



THE NATIONAL PROSTHETICS INDUSTRY

The national prosthetics industry is estimated at nearly $2 billion annually
and is extremely fragmented. PDPR is a New Public Company and has already
developed a strong hold in the Infant-Pediatric Prosthetics segment. This
infant segment, ages 0 to 14 comprise of 5% or $100 million of the total $2
billion national prosthetic market.

PDPR developed this strong hold on this segment by focusing on the
infant-pediatric prosthetics segment. PDPR was conceived and designed to
address this segment, which requires specialized expertise to meet the needs
of these babies and their families.

PDPR, a New Public Company, hopes to repeat the success of another in the
prosthetics industry, Hanger, Inc. Hanger, Inc. is currently trades on the
NYSE under HGR, has a market cap of approx. $340 million and trades at
around $16.



If a child lost an arm in an accident, the entire national medical community
would go into high gear. They do everything to try to replace the loss, and
as quickly as possible. PDPR knows that accidents happen before birth too.
One tiny fiber, designed to support the fetus in the mother's womb,
sometimes breaks, and somehow loops around the baby's tiny little arm or
leg, and keeps it from developing. Sometimes an unknowable and unfortunate
combination of genes can cause the loss.

These losses have created a need in the industry that must be filled to
enable these infants the best chance to develop.

PDPR is the only infant-pediatric prosthetics company focusing on the unique
needs of these babies born with a limb loss.



INFANT-PEDIATRIC PROSTHETICS MARKET

Children ages 0 to 14 comprise 5% of the total $2 billion prosthetic market,
$100 million. The vast majority of this 5% pediatric prosthetic market
derives from babies born with a limb loss.

There are approximately 145,000 first time amputations each year, meaning
first time fittings. Of these 145,000 first time amputations, less than 1%
or approximately 1,000 babies born with a limb loss.

PDPR is the only infant-pediatric prosthetics company focusing on these
unique needs.

The vast majority of the Prosthetists are overworked, fragmented and work
out of a single clinic with an intensely local focus. PDPR believes that to
address this dispersed market, it must be done on a national scale creating
a national presence in order to serve the geographically dispersed demand.
PDPR is the vehicle conceived and designed to fill that role.



MARKET POTENTIAL

By focusing on the infant-pediatric need, PDPR will generate a consistent
revenue stream by servicing their clients from childhood to adulthood. This
annuity effect should compound earnings year after year and enable PDPR to
enjoy stable growth.

After the initial first infant fitting, each child will need a re-socket
of the prosthesis each of the next two years due to simple fact of growth.
Every third year a child will need a complete new myoelectric system with
new larger components. This cycle will continue into the child's early
adolescence, 13 to 14 years of age, after which growth slows requiring only
a re-socket every two years and a new system perhaps every 4 years.

The economic cost from infancy to adulthood is anticipated to be over
$200,000 for a below elbow amputee. Adults will spend an additional $200,000
on their artificial arms. Revenue growth is directly correlated with the
physical growth of the children. PDPR's management model for growth combines
the strength and expertise of upper and lower extremity specialists with
over 50 years of combined experience.



PDPR MANAGEMENT TEAM

Eighteen years ago, Linda Putback-Bean, President of PDPR, was involved with
fitting the very first baby with a new small myoelectric hand. Shortly after
this fitting, Linda with Mr. Haslam, designed a new system for the small
prosthesis, and trained the child and parents how to operate and maintain
it. That child has since grown to young manhood and is now a star player on
his high school varsity football team.

The management team of PDPR is nationally recognized as the leading
prosthetists in the infant-pediatric prosthetics field. PDPR's management
has recently been featured in, Orthotics  Prosthetics Business News,
written up in Life Magazine, and some of the fitted children have appeared
on national TV shows, including Good Morning America, Maury Povich,
Phil Donahue, and 20-20.

With thousands of successful fittings, the prosthetics team for PDPR is
poised to give the most cost effective service to their 

Bug#67921: OTC FIRST ALERT - New Public Company of the Month

2003-12-10 Thread Rosella Flanagan
Symbol: PDPR
Market: PK
Sector: Infant-Pediatric Prosthetics


BREAKING NEWS:  HOUSTON, Nov 7, 2003 (BUSINESS WIRE) -- Pediatric
Prosthetics  Goes Public Through a Reverse Merger and will be trading under
the symbol PDPR.


BREAKING NEWS:  LAKE HARMONY, PA, Nov. 13, 2003 (MARKET WIRE via COMTEX) --
The OTC Report Starts Pediatric Prosthetics Inc. (OTC: PDPR) with a Buy
Rating and announces that the company will now be trading under the symbol
PDPR.



THE NATIONAL PROSTHETICS INDUSTRY

The national prosthetics industry is estimated at nearly $2 billion annually
and is extremely fragmented. PDPR is a New Public Company and has already
developed a strong hold in the Infant-Pediatric Prosthetics segment. This
infant segment, ages 0 to 14 comprise of 5% or $100 million of the total $2
billion national prosthetic market.

PDPR developed this strong hold on this segment by focusing on the
infant-pediatric prosthetics segment. PDPR was conceived and designed to
address this segment, which requires specialized expertise to meet the needs
of these babies and their families.

PDPR, a New Public Company, hopes to repeat the success of another in the
prosthetics industry, Hanger, Inc. Hanger, Inc. is currently trades on the
NYSE under HGR, has a market cap of approx. $340 million and trades at
around $16.



If a child lost an arm in an accident, the entire national medical community
would go into high gear. They do everything to try to replace the loss, and
as quickly as possible. PDPR knows that accidents happen before birth too.
One tiny fiber, designed to support the fetus in the mother's womb,
sometimes breaks, and somehow loops around the baby's tiny little arm or
leg, and keeps it from developing. Sometimes an unknowable and unfortunate
combination of genes can cause the loss.

These losses have created a need in the industry that must be filled to
enable these infants the best chance to develop.

PDPR is the only infant-pediatric prosthetics company focusing on the unique
needs of these babies born with a limb loss.



INFANT-PEDIATRIC PROSTHETICS MARKET

Children ages 0 to 14 comprise 5% of the total $2 billion prosthetic market,
$100 million. The vast majority of this 5% pediatric prosthetic market
derives from babies born with a limb loss.

There are approximately 145,000 first time amputations each year, meaning
first time fittings. Of these 145,000 first time amputations, less than 1%
or approximately 1,000 babies born with a limb loss.

PDPR is the only infant-pediatric prosthetics company focusing on these
unique needs.

The vast majority of the Prosthetists are overworked, fragmented and work
out of a single clinic with an intensely local focus. PDPR believes that to
address this dispersed market, it must be done on a national scale creating
a national presence in order to serve the geographically dispersed demand.
PDPR is the vehicle conceived and designed to fill that role.



MARKET POTENTIAL

By focusing on the infant-pediatric need, PDPR will generate a consistent
revenue stream by servicing their clients from childhood to adulthood. This
annuity effect should compound earnings year after year and enable PDPR to
enjoy stable growth.

After the initial first infant fitting, each child will need a re-socket
of the prosthesis each of the next two years due to simple fact of growth.
Every third year a child will need a complete new myoelectric system with
new larger components. This cycle will continue into the child's early
adolescence, 13 to 14 years of age, after which growth slows requiring only
a re-socket every two years and a new system perhaps every 4 years.

The economic cost from infancy to adulthood is anticipated to be over
$200,000 for a below elbow amputee. Adults will spend an additional $200,000
on their artificial arms. Revenue growth is directly correlated with the
physical growth of the children. PDPR's management model for growth combines
the strength and expertise of upper and lower extremity specialists with
over 50 years of combined experience.



PDPR MANAGEMENT TEAM

Eighteen years ago, Linda Putback-Bean, President of PDPR, was involved with
fitting the very first baby with a new small myoelectric hand. Shortly after
this fitting, Linda with Mr. Haslam, designed a new system for the small
prosthesis, and trained the child and parents how to operate and maintain
it. That child has since grown to young manhood and is now a star player on
his high school varsity football team.

The management team of PDPR is nationally recognized as the leading
prosthetists in the infant-pediatric prosthetics field. PDPR's management
has recently been featured in, Orthotics  Prosthetics Business News,
written up in Life Magazine, and some of the fitted children have appeared
on national TV shows, including Good Morning America, Maury Povich,
Phil Donahue, and 20-20.

With thousands of successful fittings, the prosthetics team for PDPR is
poised to give the most cost effective service to their 

Bug#218657: Still problems with df

2003-12-10 Thread Goswin von Brederlow
Hi,

I still see this bug on my system here:

[EMAIL PROTECTED]:~% df  
Filesystem   1K-blocks  Used Available Use% Mounted on
df: `/': Invalid argument
df: `/proc': Invalid argument
df: `/boot': Invalid argument
df: `/dev/pts': Invalid argument

[EMAIL PROTECTED]:~% uname -a
Linux opteron 2.6.0-test11 #1 SMP Mon Dec 8 11:31:17 CET 2003 x86_64 GNU/Linux

[EMAIL PROTECTED]:~% cat /proc/version 
Linux version 2.6.0-test11 ([EMAIL PROTECTED]) (gcc version 3.3.2 20030908 (Debian 
prerelease)) #1 SMP Mon Dec 8 11:31:17 CET 2003

[EMAIL PROTECTED]:~% dpkg -l coreutils libc6
ii  coreutils  5.0.91-2   The GNU core utilities
ii  libc6  2.3.2.ds1-10   GNU C Library: Shared libraries and Timezone


Looking at fs/compat.c in 2.6.0-test11 I see the patch present in the
bugreport was included. All it seems to do is change Bad address to
Invalid argument.


Older glibc, like the 2.3.2-7.biarch1 version used for debian-amd64
sarge, work fine though:

sh-2.05b# /tmp/df 
Filesystem   1K-blocks  Used Available Use% Mounted on
rootfs 3937284   1381472   2355804  37% /
/dev/root  3937284   1381472   2355804  37% /
/dev/hda1  3937284   1381472   2355804  37% /boot

sh-2.05b# file tmp/df 
tmp/df: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, 
dynamically linked (uses shared libs), stripped

sh-2.05b# ldd tmp/df 
libc.so.6 = /lib/libc.so.6 (0xa000)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000)

sh-2.05b# df
Filesystem   1K-blocks  Used Available Use% Mounted on
rootfs 3937284   1381472   2355804  37% /
/dev/root  3937284   1381472   2355804  37% /
/dev/hda1  3937284   1381472   2355804  37% /boot

sh-2.05b# file /bin/df 
/bin/df: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, 
dynamically linked (uses shared libs), stripped

sh-2.05b# ldd /bin/df
libc.so.6 = /lib64/libc.so.6 (0x002a9566c000)
/lib64/ld-linux-x86-64.so.2 = /lib64/ld-linux-x86-64.so.2 (0x002a95556000)

MfG
Goswin

PS: 2.6 seems to be the prefered kernel for amd64 systems and they are
getting more common.

PPS: I will compile a 2.4.23 kernel and do the same tests next time I
reboot just for good measure.


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



Processed: reopening 218657

2003-12-10 Thread Debian Bug Tracking System
Processing commands for [EMAIL PROTECTED]:

 reopen 218657
Bug#218657: glibc: libc6 2.3.2.ds1-8 breaks system with x86_64 kernel
Bug reopened, originator not changed.


End of message, 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]



Bug#190399: Some updates of amd64 developement

2003-12-10 Thread Goswin von Brederlow
Hi,

 On Monday 28 April 2003 05:51, GOTO Masanori wrote:
 
  Well, that's right.  BTW, I still wonder how to support IA32 binaries.
  You're planning to support x86-64 native package with this patch for
  the present?
 No, this patch is meant to bring i386/amd64 to the point where s390 and
 sparc are. Support for native packages is one of the next steps. I want
 to do s390x and amd64 at the same time, even if s390x might stay out of
 the official Debian mirrors.

The port is now so far complete that you can use an existing linux
with a 64 bit kernel running to cdebootstrap sarge /chroot
http://debian-amd64.alioth.debian.org/;. I believe all build-essential
packages (except build-essential) are there too. Thats the next step.

  As we discussed a few week ago, is dpkg change needed?
 The most important change that is required for dpkg is to make it
 possible to mix 64 and 32 bit packages on i386/amd64 (and s390{,x},
 for that matter). It looks like we also need a new field in the
 control file to better handle the naming of packages, e.g. 
 
 Package: libncurses5
 AltPackage: lib64ncurses5

On irc ([EMAIL PROTECTED]) we discussed the dpkg subarch
support and the naming scheme. We found that dpkg should use the
compatible arch and compatible abi settings from its subarch table to
find suitable packages to resolve Depends. The difference between a
ABI compatible (libs) depends would be denoted by adding {abi} to the
name.

Further fixing dpkg to allow two packages with the same name but
different ABI to be installed in parallel we could drop the 64 in
lib64ncurses5 and all other libs completly. That would make porting
much less work.
 
 Another change that might be helpful is to have an 'Architecture: 
 anylib64' and 'Architecture: anylib' or similar option that can
 either be expanded by dpkg-gencontrol or identified by dpkg and
 apt.

??? what do you mean there?

  If you have roadmap or policy to support x86-64, could you tell
  us?
 Gerhard Tonn is currently experimenting with some options on an s390x
 system. It is not sure if it works out like this, but our current
 idea is roughly:
 
 - - Fix autoconf to set ${libdir} correctly on 64 bit systems

Aparently not wnated by upstream but we came to the same conclusion.

 - - Add a dpkg-libinfo program similar to dpkg-architecture that
   knows about library paths etc.

Present.

 - - Make dpkg know about the extra features in the control files.
 - - Add support for automatically detecting /lib64 paths to
   dh_install, dh_movefiles and dh_installdirs. They will try
   to do the right thing and give a warning if the packager
   e.g. wrote /usr/lib/* instead of $(libdir)/* or /usr/lib64/*.
 - - Convert all 'required' and 'important' library packages to a dual
   lib / lib64 system. They must be installable for both 64 and 32
   bit at the same time.
 - - Make all 'standard' packages build with 64 bit. Standard libraries
   should be installable for both 64 and 32 bit at the same time.
 - - 64 bit library packages should be named like lib64foo3

The name for all archs should be the same. Different names need a lot
of changes to Build-depends lines that can't be done with shlibs magic
like Depends. Using dpkg/apt to fetch the right ABI sounds more
reasonable.

 - - Build-essential -dev packages should allow being installed for both
   64 and 32 bit, the names should be like lib64foo3-dev.

See above.

 - - Non-build-essential -dev packages should have the same name for
   64 and 32 bit packages (e.g. libfoo3-dev) because of the dependencies
   on them.

If they are not installable at the same time they have to Conflict.

 Gerhard is trying this on an s390x machine, starting from a working
 /lib based system, I'll start with an i386 system running on an Opteron
 once I get access.

Is there a patch repository for s390 somewhere or could we move all
the patches onto debian-amd64.alioth.debian.org?

   +ifeq ($(DEB_HOST_GNU_CPU),i386)
 
  Umm, why is it i386?  Should be x86-64?
 
 Like on s390x, the debian architecture name is still the 32 bit one.
 Until dpkg knows about the relation between 64 and 32 bit architectures,
 we cannot make native 64 bit packages. Later, this will be
   i386 || amd64 || s390 || s390x || sparc || sparc64
 or rather, checking a different variable.

sh-2.05b# dpkg-architecture 
DEB_BUILD_ARCH=amd64
DEB_BUILD_GNU_CPU=x86_64
DEB_BUILD_GNU_SYSTEM=linux
DEB_BUILD_GNU_TYPE=x86_64-linux
DEB_HOST_ARCH=amd64
DEB_HOST_GNU_CPU=x86_64
DEB_HOST_GNU_SYSTEM=linux
DEB_HOST_GNU_TYPE=x86_64-linux

sh-2.05b# dpkg --print-architecture
i486

   +ifeq ($(DEB_HOST_GNU_CPU),i386)
   +  arch_packages += lib64c6 lib64c6-dev
   +endif
   +
ifeq ($(DEB_HOST_GNU_CPU),s390)
  arch_packages += $(libc)-s390x $(libc)-dev-s390x
endif
   only in patch2:
   unchanged:
 
  It means that if build architecture is i386, libc-64 is also made.
  However, I wonder it's really needed.
 
 Not strictly needed, but helpful. If we want to make the i386 gcc-3.3
 package 

Bug#223547: Libc6 2.3.2.ds1-10 breaks system functionality on mipsel

2003-12-10 Thread Massimo Cetra
Package: libc6
Version: 2.3.2.ds1-10
Section: base
Priority: required
Architecture: mipsel
Depends: libdb1-compat
Suggests: locales, glibc-doc
Conflicts: strace ( 4.0-0), libnss-db (= 2.2-6.1.1), timezone,
timezones, gconv-mo
Replaces: ldso (= 1.9.11-9), timezone, timezones, gconv-modules,
libtricks, netkit-r
Provides: glibc-2.3.2.ds1-10
Installed-Size: 15388
Maintainer: GNU Libc Maintainers [EMAIL PROTECTED]
Source: glibc


#**
#*** SYSTEM INFO
#**

Cobalt Raq2

sh-2.05b# uname -a
Linux 10.10.10.99 2.4.18 #9 Sat Jun 15 13:00:18 BST 2002 mips unknown

# cat /proc/cpuinfo
system type : MIPS Cobalt
processor   : 0
cpu model   : Nevada V10.0  FPU V10.0
BogoMIPS: 249.03
wait instruction: yes
microsecond timers  : yes
tlb_entries : 48
extra interrupt vector  : yes
hardware watchpoint : no
VCED exceptions : not available
VCEI exceptions : not available
#

#*
#*** Problems
#*

Package libc6_2.3.2.ds1-10_mipsel.deb refused to install.
After several trials in order to fix the problem (and restore  the apt
funcionality) I forced an dpkg-deb -x  to /.

Nothing worked anymore.
Tar refuses to work, commands like ls showed strange behaviour:

Look at permissions on files:

cobalt:~# ls -la /bin/ls
-x1 root root80152 Mar 18  2002 /bin/ls
cobalt:~# ls -la /bin/ls
ÄöÖ?X.z.-x1 root root80152 Mar 18  2002 /bin/ls
cobalt:~# ls -la /bin/ls
ÅöÖ?.Bx-x1 root root80152 Mar 18  2002 /bin/ls
cobalt:~# ls -la /bin/ls
ÆöÖ?g-x1 root root80152 Mar 18  2002 /bin/ls
cobalt:~#


sh-2.05a# ls -la /etc/localtime
ãJm88µx1 root root   31 Oct 25  2003 /etc/localtime -
usr/share/zoneinfo/Europe/Rome
sh-2.05a# ls -la /etc/localtime
äJm¨Íwx1 root root   31 Oct 25  2003 /etc/localtime -
/usr/share/zoneinfo/Europe/Rome
sh-2.05a# ls -la /etc/localtime
åJmì*wx1 root root   31 Oct 25  2003 /etc/localtime -
/usr/share/zoneinfo/Europe/Rome
sh-2.05a#


cobalt:~# tar
Segmentation fault
cobalt:~#

Booting with rescue image and overwriting with old
libc6_2.2.5-11.5_mipsel.deb solved the problem.

All testing distribution of Debian on mipsel is corrupted and unusable.

Regards,

 Massimo Cetra









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



Bug#223547: marked as done (Libc6 2.3.2.ds1-10 breaks system functionality on mipsel)

2003-12-10 Thread Debian Bug Tracking System
Your message dated Wed, 10 Dec 2003 06:13:19 -0800
with message-id [EMAIL PROTECTED]
and subject line Bug#223547: Libc6 2.3.2.ds1-10 breaks system functionality on mipsel
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; 10 Dec 2003 12:42:33 +
From [EMAIL PROTECTED] Wed Dec 10 06:42:31 2003
Return-path: [EMAIL PROTECTED]
Received: from (server1.navynet.it) [213.188.213.77] 
by master.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1AU2NZ-00011i-00; Wed, 10 Dec 2003 05:19:42 -0600
Received: from localhost (server1 [127.0.0.1])
by server1.navynet.it (Postfix) with ESMTP id 0C1A18400C
for [EMAIL PROTECTED]; Wed, 10 Dec 2003 12:19:40 +0100 (CET)
Received: from server1.navynet.it ([127.0.0.1])
 by localhost (server1 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 15717-10 for [EMAIL PROTECTED];
 Wed, 10 Dec 2003 12:19:38 +0100 (CET)
Received: from guendalin (host12-150.pool8175.interbusiness.it [81.75.150.12])
by server1.navynet.it (Postfix) with ESMTP id 0A27884008
for [EMAIL PROTECTED]; Wed, 10 Dec 2003 12:19:38 +0100 (CET)
From: Massimo Cetra [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Libc6 2.3.2.ds1-10 breaks system functionality on mipsel
Date: Wed, 10 Dec 2003 12:19:35 +0100
Message-ID: [EMAIL PROTECTED]
MIME-Version: 1.0
Content-Type: text/plain;
charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
X-Virus-Scanned: by amavisd-new-20030616-p3 (Navynet) at navynet.it
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 
2.60-master.debian.org_2003_11_25-bugs.debian.org_2003_11_20 
(1.212-2003-09-23-exp) on master.debian.org
X-Spam-Status: No, hits=-5.0 required=4.0 tests=HAS_PACKAGE autolearn=no 
version=2.60-master.debian.org_2003_11_25-bugs.debian.org_2003_11_20
X-Spam-Level: 

Package: libc6
Version: 2.3.2.ds1-10
Section: base
Priority: required
Architecture: mipsel
Depends: libdb1-compat
Suggests: locales, glibc-doc
Conflicts: strace ( 4.0-0), libnss-db (=3D 2.2-6.1.1), timezone,
timezones, gconv-mo
Replaces: ldso (=3D 1.9.11-9), timezone, timezones, gconv-modules,
libtricks, netkit-r
Provides: glibc-2.3.2.ds1-10
Installed-Size: 15388
Maintainer: GNU Libc Maintainers [EMAIL PROTECTED]
Source: glibc


#**
#*** SYSTEM INFO
#**

Cobalt Raq2

sh-2.05b# uname -a
Linux 10.10.10.99 2.4.18 #9 Sat Jun 15 13:00:18 BST 2002 mips unknown

# cat /proc/cpuinfo
system type : MIPS Cobalt
processor   : 0
cpu model   : Nevada V10.0  FPU V10.0
BogoMIPS: 249.03
wait instruction: yes
microsecond timers  : yes
tlb_entries : 48
extra interrupt vector  : yes
hardware watchpoint : no
VCED exceptions : not available
VCEI exceptions : not available
#

#*
#*** Problems
#*

Package libc6_2.3.2.ds1-10_mipsel.deb refused to install.
After several trials in order to fix the problem (and restore  the apt
funcionality) I forced an dpkg-deb -x  to /.

Nothing worked anymore.
Tar refuses to work, commands like ls showed strange behaviour:

Look at permissions on files:

cobalt:~# ls -la /bin/ls
-x1 root root80152 Mar 18  2002 /bin/ls
cobalt:~# ls -la /bin/ls
=C4=F6=D6?X.z.-x1 root root80152 Mar 18  2002 /bin/ls
cobalt:~# ls -la /bin/ls
=C5=F6=D6?.Bx-x1 root root80152 Mar 18  2002 /bin/ls
cobalt:~# ls -la /bin/ls
=C6=F6=D6?g-x1 root root80152 Mar 18  2002 /bin/ls
cobalt:~#


sh-2.05a# ls -la /etc/localtime
=E3Jm88=B5x1 root root   31 Oct 25  2003 /etc/localtime =
-
usr/share/zoneinfo/Europe/Rome
sh-2.05a# ls -la /etc/localtime
=E4Jm=A8=CDwx1 root root   31 Oct 25  2003 =
/etc/localtime -
/usr/share/zoneinfo/Europe/Rome
sh-2.05a# ls -la /etc/localtime
=E5Jm=EC*wx1 root root   31 Oct 25  2003 /etc/localtime =
-
/usr/share/zoneinfo/Europe/Rome
sh-2.05a#


cobalt:~# tar
Segmentation fault
cobalt:~#

Booting with rescue image and overwriting with old
libc6_2.2.5-11.5_mipsel.deb solved the problem.

All testing distribution of Debian on mipsel is corrupted and unusable.

Regards,

 Massimo Cetra









Bug#223547: Libc6 2.3.2.ds1-10 breaks system functionality on mipsel

2003-12-10 Thread Daniel Jacobowitz
Hi debian-mips,

Any idea what's going on?  I know some people are using this without
trouble (since the build daemons didn't die a flaming death).

On Wed, Dec 10, 2003 at 12:19:35PM +0100, Massimo Cetra wrote:
 Package: libc6
 Version: 2.3.2.ds1-10
 Section: base
 Priority: required
 Architecture: mipsel
 Depends: libdb1-compat
 Suggests: locales, glibc-doc
 Conflicts: strace ( 4.0-0), libnss-db (= 2.2-6.1.1), timezone,
 timezones, gconv-mo
 Replaces: ldso (= 1.9.11-9), timezone, timezones, gconv-modules,
 libtricks, netkit-r
 Provides: glibc-2.3.2.ds1-10
 Installed-Size: 15388
 Maintainer: GNU Libc Maintainers [EMAIL PROTECTED]
 Source: glibc
 
 
 #**
 #*** SYSTEM INFO
 #**
 
 Cobalt Raq2
 
 sh-2.05b# uname -a
 Linux 10.10.10.99 2.4.18 #9 Sat Jun 15 13:00:18 BST 2002 mips unknown
 
 # cat /proc/cpuinfo
 system type : MIPS Cobalt
 processor   : 0
 cpu model   : Nevada V10.0  FPU V10.0
 BogoMIPS: 249.03
 wait instruction: yes
 microsecond timers  : yes
 tlb_entries : 48
 extra interrupt vector  : yes
 hardware watchpoint : no
 VCED exceptions : not available
 VCEI exceptions : not available
 #
 
 #*
 #*** Problems
 #*
 
 Package libc6_2.3.2.ds1-10_mipsel.deb refused to install.
 After several trials in order to fix the problem (and restore  the apt
 funcionality) I forced an dpkg-deb -x  to /.
 
 Nothing worked anymore.
 Tar refuses to work, commands like ls showed strange behaviour:
 
 Look at permissions on files:
 
 cobalt:~# ls -la /bin/ls
 -x1 root root80152 Mar 18  2002 /bin/ls
 cobalt:~# ls -la /bin/ls
 ÄöÖ?X.z.-x1 root root80152 Mar 18  2002 /bin/ls
 cobalt:~# ls -la /bin/ls
 ÅöÖ?.Bx-x1 root root80152 Mar 18  2002 /bin/ls
 cobalt:~# ls -la /bin/ls
 ÆöÖ?g-x1 root root80152 Mar 18  2002 /bin/ls
 cobalt:~#
 
 
 sh-2.05a# ls -la /etc/localtime
 ãJm88µx1 root root   31 Oct 25  2003 /etc/localtime -
 usr/share/zoneinfo/Europe/Rome
 sh-2.05a# ls -la /etc/localtime
 äJm¨Íwx1 root root   31 Oct 25  2003 /etc/localtime -
 /usr/share/zoneinfo/Europe/Rome
 sh-2.05a# ls -la /etc/localtime
 åJmì*wx1 root root   31 Oct 25  2003 /etc/localtime -
 /usr/share/zoneinfo/Europe/Rome
 sh-2.05a#
 
 
 cobalt:~# tar
 Segmentation fault
 cobalt:~#
 
 Booting with rescue image and overwriting with old
 libc6_2.2.5-11.5_mipsel.deb solved the problem.
 
 All testing distribution of Debian on mipsel is corrupted and unusable.
 
 Regards,
 
  Massimo Cetra
 
 
 
 
 
 
 
 
 
 --
 To UNSUBSCRIBE, email to [EMAIL PROTECTED]
 with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
 
 

-- 
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer


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



Bug#223547: Libc6 2.3.2.ds1-10 breaks system functionality on mipsel

2003-12-10 Thread Guido Guenther
On Wed, Dec 10, 2003 at 05:16:51PM +0100, Karsten Merker wrote:
 This is the problem - the current libc6 requires (AFAIK) at least
 kernel 2.4.19 on mipsel. Unfortunately, we are having problems with
What exactly was the issue here? The recent msq problem shouldn't affect
all running programs. Or are you talking about ll/sc emulation? The
Nevada isn't lacking that, is it?
Cheers,
 -- Guido


signature.asc
Description: Digital signature


Bug#223547: Libc6 2.3.2.ds1-10 breaks system functionality on mipsel

2003-12-10 Thread Guido Guenther
Hi Daniel,
On Wed, Dec 10, 2003 at 10:02:31AM -0500, Daniel Jacobowitz wrote:
 Any idea what's going on?  I know some people are using this without
 trouble (since the build daemons didn't die a flaming death).

Dunno, but I suspect a kernel vs. glibc issue.
  sh-2.05b# uname -a
  Linux 10.10.10.99 2.4.18 #9 Sat Jun 15 13:00:18 BST 2002 mips unknown
Updating to 2.4.22 (in the archive) and trying the update again would
give an additional (important) data point.
Cheers,
 -- Guido


signature.asc
Description: Digital signature


Bug#223547: Libc6 2.3.2.ds1-10 breaks system functionality on mipsel

2003-12-10 Thread Massimo Cetra




 From: Karsten Merker [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, December 10, 2003 5:17 PM
 To: Massimo Cetra; [EMAIL PROTECTED]; 
 [EMAIL PROTECTED]
 Subject: Re: Bug#223547: Libc6 2.3.2.ds1-10 breaks system 
 functionality on mipsel
 
   Package: libc6
   Version: 2.3.2.ds1-10
  
   Linux 10.10.10.99 2.4.18 #9 Sat Jun 15 13:00:18 BST 2002 mips 
   unknown
   ^^
 
 This is the problem - the current libc6 requires (AFAIK) at 
 least kernel 2.4.19 on mipsel. 

Ok, this is a kernel problem.
Moreover (unfortunately) I have never been able to build a working
kernel-image for my cobalt.

 From: Debian BTS [mailto:[EMAIL PROTECTED] On Behalf 
 Of Debian Bug Tracking System
 Sent: Wednesday, December 10, 2003 3:48 PM
 To: Massimo Cetra
 Subject: Bug#223547 acknowledged by developer (Re: 
 Bug#223547: Libc6 2.3.2.ds1-10 breaks system functionality on mipsel)
...
 It has been closed by one of the developers, namely
 Jeff Bailey [EMAIL PROTECTED].
...
 *Never* do that.  If it doesn't install, there's a reason.  
 If you overcome the safeguards, your system will break.  This 
 is not a bug.
 
 Please file a new bug with information about why it refused 
 to install, including specific error messages.


The bug report has been closed. 
What about adding a notice, a conflicts or a dependencies to the
.deb package?

It should at least warn before causing problems.



Massimo Cetra



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



Bug#223547: Libc6 2.3.2.ds1-10 breaks system functionality on mipsel

2003-12-10 Thread Guido Guenther
On Wed, Dec 10, 2003 at 05:52:35PM +0100, Guido Guenther wrote:
 Hi Daniel,
 On Wed, Dec 10, 2003 at 10:02:31AM -0500, Daniel Jacobowitz wrote:
  Any idea what's going on?  I know some people are using this without
  trouble (since the build daemons didn't die a flaming death).
 
 Dunno, but I suspect a kernel vs. glibc issue.
   sh-2.05b# uname -a
   Linux 10.10.10.99 2.4.18 #9 Sat Jun 15 13:00:18 BST 2002 mips unknown
 Updating to 2.4.22 (in the archive) and trying the update again would
  ^^
scratch that, we don't have any cobalt Kernel's in the archive.
 -- Guido


signature.asc
Description: Digital signature


Bug#223547: Libc6 2.3.2.ds1-10 breaks system functionality on mipsel

2003-12-10 Thread Colin Watson
On Wed, Dec 10, 2003 at 08:43:14PM +0100, Karsten Merker wrote:
 On Wed, Dec 10, 2003 at 06:45:18PM +0100, Massimo Cetra wrote:
  The bug report has been closed. 
  What about adding a notice, a conflicts or a dependencies to the
  .deb package?
  
  It should at least warn before causing problems.
 
 The reason is quite simple - the Cobalts are not yet an officially
 supported subarchitecture in Debian. We are working on it, but before
 they can get officially supported, a bunch of Cobalt-specific issues
 must be resolved.
 
 The glibc packagers cannot define a conflicts against a kernel
 package which does not exist yet.

Conflicts on kernel packages are a dubious idea anyway: kernel packages
you happen to have installed don't necessarily correspond to what you're
running, and you don't have to use kernel packages at all. They are
therefore both annoying and unreliable, which is not the best
combination.

libc's preinst has some uname checks in place of such conflicts.

-- 
Colin Watson  [EMAIL PROTECTED]


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



Bug#223547: Libc6 2.3.2.ds1-10 breaks system functionality on mipsel

2003-12-10 Thread Jeff Bailey
On Wed, Dec 10, 2003 at 08:43:14PM +0100, Karsten Merker wrote:

  The bug report has been closed. 
  What about adding a notice, a conflicts or a dependencies to the
  .deb package?

  It should at least warn before causing problems.

 The reason is quite simple - the Cobalts are not yet an officially
 supported subarchitecture in Debian. We are working on it, but before
 they can get officially supported, a bunch of Cobalt-specific issues
 must be resolved.

It's also worth remembering that the packaged refused to install, and
the reporter forced it to anyway.  So there was at least some warning.

The preinst can easily verify minimum kernel version, which is probably
a better solution.  We don't require Debian-built kernels, so can't
reliably just conflicts on the package.

Tks,
Jeff Bailey



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



Bug#40263: OTC FIRST ALERT - New Public Company of the Month

2003-12-10 Thread Keisha Stone
Symbol: PDPR
Market: PK
Sector: Infant-Pediatric Prosthetics


BREAKING NEWS:  HOUSTON, Nov 7, 2003 (BUSINESS WIRE) -- Pediatric
Prosthetics  Goes Public Through a Reverse Merger and will be trading under
the symbol PDPR.


BREAKING NEWS:  LAKE HARMONY, PA, Nov. 13, 2003 (MARKET WIRE via COMTEX) --
The OTC Report Starts Pediatric Prosthetics Inc. (OTC: PDPR) with a Buy
Rating and announces that the company will now be trading under the symbol
PDPR.



THE NATIONAL PROSTHETICS INDUSTRY

The national prosthetics industry is estimated at nearly $2 billion annually
and is extremely fragmented. PDPR is a New Public Company and has already
developed a strong hold in the Infant-Pediatric Prosthetics segment. This
infant segment, ages 0 to 14 comprise of 5% or $100 million of the total $2
billion national prosthetic market.

PDPR developed this strong hold on this segment by focusing on the
infant-pediatric prosthetics segment. PDPR was conceived and designed to
address this segment, which requires specialized expertise to meet the needs
of these babies and their families.

PDPR, a New Public Company, hopes to repeat the success of another in the
prosthetics industry, Hanger, Inc. Hanger, Inc. is currently trades on the
NYSE under HGR, has a market cap of approx. $340 million and trades at
around $16.



If a child lost an arm in an accident, the entire national medical community
would go into high gear. They do everything to try to replace the loss, and
as quickly as possible. PDPR knows that accidents happen before birth too.
One tiny fiber, designed to support the fetus in the mother's womb,
sometimes breaks, and somehow loops around the baby's tiny little arm or
leg, and keeps it from developing. Sometimes an unknowable and unfortunate
combination of genes can cause the loss.

These losses have created a need in the industry that must be filled to
enable these infants the best chance to develop.

PDPR is the only infant-pediatric prosthetics company focusing on the unique
needs of these babies born with a limb loss.



INFANT-PEDIATRIC PROSTHETICS MARKET

Children ages 0 to 14 comprise 5% of the total $2 billion prosthetic market,
$100 million. The vast majority of this 5% pediatric prosthetic market
derives from babies born with a limb loss.

There are approximately 145,000 first time amputations each year, meaning
first time fittings. Of these 145,000 first time amputations, less than 1%
or approximately 1,000 babies born with a limb loss.

PDPR is the only infant-pediatric prosthetics company focusing on these
unique needs.

The vast majority of the Prosthetists are overworked, fragmented and work
out of a single clinic with an intensely local focus. PDPR believes that to
address this dispersed market, it must be done on a national scale creating
a national presence in order to serve the geographically dispersed demand.
PDPR is the vehicle conceived and designed to fill that role.



MARKET POTENTIAL

By focusing on the infant-pediatric need, PDPR will generate a consistent
revenue stream by servicing their clients from childhood to adulthood. This
annuity effect should compound earnings year after year and enable PDPR to
enjoy stable growth.

After the initial first infant fitting, each child will need a re-socket
of the prosthesis each of the next two years due to simple fact of growth.
Every third year a child will need a complete new myoelectric system with
new larger components. This cycle will continue into the child's early
adolescence, 13 to 14 years of age, after which growth slows requiring only
a re-socket every two years and a new system perhaps every 4 years.

The economic cost from infancy to adulthood is anticipated to be over
$200,000 for a below elbow amputee. Adults will spend an additional $200,000
on their artificial arms. Revenue growth is directly correlated with the
physical growth of the children. PDPR's management model for growth combines
the strength and expertise of upper and lower extremity specialists with
over 50 years of combined experience.



PDPR MANAGEMENT TEAM

Eighteen years ago, Linda Putback-Bean, President of PDPR, was involved with
fitting the very first baby with a new small myoelectric hand. Shortly after
this fitting, Linda with Mr. Haslam, designed a new system for the small
prosthesis, and trained the child and parents how to operate and maintain
it. That child has since grown to young manhood and is now a star player on
his high school varsity football team.

The management team of PDPR is nationally recognized as the leading
prosthetists in the infant-pediatric prosthetics field. PDPR's management
has recently been featured in, Orthotics  Prosthetics Business News,
written up in Life Magazine, and some of the fitted children have appeared
on national TV shows, including Good Morning America, Maury Povich,
Phil Donahue, and 20-20.

With thousands of successful fittings, the prosthetics team for PDPR is
poised to give the most cost effective service to their