Re: ud segfault (was: When will the amd64 port be stable?)
David Liontooth <[EMAIL PROTECTED]> wrote: >Goswin von Brederlow wrote: >> >>And now the same with -f please. I didn't see a segfault in the starce >>and it is probably its child that dies. >> >>You can also compile the ud with debug infos and run it in gdb. >> >>MfG >>Goswin >> >> >Hi Goswin, > >So this is not behavior others are seeing? >I have the pleasure of sending you a thousand EBADF reports below -- >you're likely only interested in the last few lines: OK, so I'm bored. I've just looked at the bug and found the problem. ud's source is quite ugly, suggesting a novice author. I can recreate the bug quite readily here, and it's crashing down below a sprintf() call: (gdb) bt #0 0x002a956e9980 in strlen () from /lib/libc.so.6 #1 0x002a956b7c75 in vfprintf () from /lib/libc.so.6 #2 0x002a956d6ec5 in vsprintf () from /lib/libc.so.6 #3 0x002a956be50a in sprintf () from /lib/libc.so.6 #4 0x00401340 in get_kernel_version (kernel_version=0x7fb544 "running Linux 2.6.9", IsCurrent=0) at ud.c:150 #5 0x004020c5 in main (argc=1, argv=0x7fb540) at ud.c:822 The reason for this becomes clear once you turn on warnings in the compilation: gcc -DPACKAGE=\"ud\" -DVERSION=\"0.7.1\" -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DRETSIGTYPE=void -DHAVE_GETHOSTNAME=1 -I. -I. -g -O2 -Wall -W -c ud.c ud.c: In function `get_kernel_version': ud.c:150: warning: implicit declaration of function `ctime' ud.c:150: warning: format argument is not a pointer (arg 3) ctime is returning a pointer rather than an int. Simply adding "#include " to the top of the ud.c source file fixes this bug. Prototypes are there for a reason! Turning on warnings also highlights other silly coding bugs, but I'll leave those for other people. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] There's no sensation to compare with this Suspended animation, A state of bliss
Re: ud segfault
David Liontooth <[EMAIL PROTECTED]> writes:
> Hi Goswin,
>
> So this is not behavior others are seeing? I have the pleasure of sending you
> a thousand EBADF reports below --
I have no clue. I don't have ud installed and know of noone having it
running. I'm just trying to guide you to finding the problem.
> you're likely only interested in the last few lines:
>
> chdir("/") = 0
> umask(0)= 022
> ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fb6d0) = -1 EBADF (Bad
> file descriptor)
> open("/etc/localtime", O_RDONLY)= 0
> fstat(0, {st_mode=S_IFREG|0644, st_size=1017, ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0x2a9556b000
> read(0, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0"...,
> 4096) = 1017
> close(0)= 0
> munmap(0x2a9556b000, 4096) = 0
> getpid()= 11304
> rt_sigaction(SIGPIPE, {0x2a9573b170, [], 0x400}, {SIG_DFL}, 8) = 0
> socket(PF_FILE, SOCK_DGRAM, 0) = 0
> fcntl(0, F_SETFD, FD_CLOEXEC) = 0
> connect(0, {sa_family=AF_FILE, path="/dev/log"}, 16) = 0
> sendto(0, "<30>Dec 11 19:34:31 ud[11304]: U"..., 56, 0, NULL, 0) = 56
> rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0
> close(0)= 0
> getpid()= 11304
> open("/var/run/ud.pid", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 0
> chmod("/var/run/ud.pid", 0644) = 0
> fstat(0, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0x2a9556b000
> write(0, "11304\n", 6) = 6
> close(0)= 0
> munmap(0x2a9556b000, 4096) = 0
> open("/var/lib/misc/uptime.record", O_RDONLY) = 0
> chmod("/var/lib/misc/uptime.record", 0644) = 0
> fstat(0, {st_mode=S_IFREG|0644, st_size=36, ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0x2a9556b000
> read(0, "0.7.1\n0.00\n\n0.00\n\n0."..., 4096) = 36
> close(0)= 0
> munmap(0x2a9556b000, 4096) = 0
> open("/proc/uptime", O_RDONLY) = 0
> fstat(0, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0x2a9556b000
> read(0, "97472.40 97151.76\n", 1024)= 18
> close(0)= 0
> munmap(0x2a9556b000, 4096) = 0
> uname({sys="Linux", node="clitunno", ...}) = 0
> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> Process 11304 detached
>
> Cheers,
> Dave
As expected nothing shows up as being wrong. You do have to run ud in
gdb and find out where in ud it segfaults.
MfG
Goswin
ud segfault (was: When will the amd64 port be stable?)
Goswin von Brederlow wrote:
David Liontooth <[EMAIL PROTECTED]> writes:
Dec 11 12:59:13 clitunno ud[6280]: Uptime daemon starting...
Dec 11 12:59:13 clitunno kernel: ud[6280]: segfault at
958a7d00 rip 002a956e9980 rsp 007fbfffecb8 error 4
The daemon really does stop running, every time I try to start
it. Anything else I can try? Strace below.
Cheers,
Dave
# strace ud
And now the same with -f please. I didn't see a segfault in the starce
and it is probably its child that dies.
You can also compile the ud with debug infos and run it in gdb.
MfG
Goswin
Hi Goswin,
So this is not behavior others are seeing?
I have the pleasure of sending you a thousand EBADF reports below --
you're likely only interested in the last few lines:
chdir("/") = 0
umask(0)= 022
ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fb6d0) = -1 EBADF (Bad
file descriptor)
open("/etc/localtime", O_RDONLY)= 0
fstat(0, {st_mode=S_IFREG|0644, st_size=1017, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2a9556b000
read(0, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0"...,
4096) = 1017
close(0)= 0
munmap(0x2a9556b000, 4096) = 0
getpid()= 11304
rt_sigaction(SIGPIPE, {0x2a9573b170, [], 0x400}, {SIG_DFL}, 8) = 0
socket(PF_FILE, SOCK_DGRAM, 0) = 0
fcntl(0, F_SETFD, FD_CLOEXEC) = 0
connect(0, {sa_family=AF_FILE, path="/dev/log"}, 16) = 0
sendto(0, "<30>Dec 11 19:34:31 ud[11304]: U"..., 56, 0, NULL, 0) = 56
rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0
close(0)= 0
getpid()= 11304
open("/var/run/ud.pid", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 0
chmod("/var/run/ud.pid", 0644) = 0
fstat(0, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2a9556b000
write(0, "11304\n", 6) = 6
close(0)= 0
munmap(0x2a9556b000, 4096) = 0
open("/var/lib/misc/uptime.record", O_RDONLY) = 0
chmod("/var/lib/misc/uptime.record", 0644) = 0
fstat(0, {st_mode=S_IFREG|0644, st_size=36, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2a9556b000
read(0, "0.7.1\n0.00\n\n0.00\n\n0."..., 4096) = 36
close(0)= 0
munmap(0x2a9556b000, 4096) = 0
open("/proc/uptime", O_RDONLY) = 0
fstat(0, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2a9556b000
read(0, "97472.40 97151.76\n", 1024)= 18
close(0)= 0
munmap(0x2a9556b000, 4096) = 0
uname({sys="Linux", node="clitunno", ...}) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
Process 11304 detached
Cheers,
Dave
# strace -f ud
execve("/usr/bin/ud", ["ud"], [/* 15 vars */]) = 0
uname({sys="Linux", node="clitunno", ...}) = 0
brk(0) = 0x504000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2a9556a000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=104400, ...}) = 0
mmap(NULL, 104400, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2a9556b000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
open("/lib/libc.so.6", O_RDONLY)= 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`\324\1\0"...,
640) = 640
fstat(3, {st_mode=S_IFREG|0644, st_size=1294400, ...}) = 0
mmap(NULL, 2353800, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x2a9566c000
mprotect(0x2a9578e000, 1165960, PROT_NONE) = 0
mmap(0x2a9586c000, 241664, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED,
3, 0x10) = 0x2a9586c000
mmap(0x2a958a7000, 14984, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2a958a7000
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2a958ab000
arch_prctl(0x1002, 0x2a958ab520)= 0
munmap(0x2a9556b000, 104400)= 0
rt_sigaction(SIGINT, {0x401af0, [INT], SA_RESTART|0x400}, {SIG_DFL},
8) = 0
rt_sigaction(SIGHUP, {0x401af0, [HUP], SA_RESTART|0x400}, {SIG_DFL},
8) = 0
rt_sigaction(SIGQUIT, {0x401af0, [QUIT], SA_RESTART|0x400},
{SIG_DFL}, 8) = 0
rt_sigaction(SIGTERM, {0x401af0, [TERM], SA_RESTART|0x400},
{SIG_DFL}, 8) = 0
umask(022) = 022
brk(0) = 0x504000
brk(0x525000) = 0x525000
brk(0) = 0x525000
open("/proc/uptime", O_RDONLY)
Re: errors upgrading
On Sat Dec 11, 2004 at 23:04:31 +0100, Alexandru Cabuz wrote: > Here's an example of the kind of error I've been getting trying to run > apt-get upgrade on my amd64 system. > > Réception de : 23 ftp://ftp.de.debian.org sid/main libsane 1.0.15-3 [2634kB] > Err ftp://ftp.de.debian.org sid/main libsane 1.0.15-3 > Unable to fetch file, server said > '/debian-amd64/pure64/pool/unstable/main/amd64/s/sane-backends/libsane_1.0.15-3_amd64.deb: > No such file or directory ' > > I'm getting about a dozen of these and that's not counting the > base-config, sed and a couple of other packages which have been broken > for a while now and so I have them on hold for the time being. > > I've never seen this before. What's going on? The files are there now, it just took them a while. Adam -- Adam [EMAIL PROTECTED] Lackorzynski http://os.inf.tu-dresden.de/~adam/
Re: When will the amd64 port be stable?
David Liontooth <[EMAIL PROTECTED]> writes: > Dec 11 12:59:13 clitunno ud[6280]: Uptime daemon starting... > Dec 11 12:59:13 clitunno kernel: ud[6280]: segfault at > 958a7d00 rip 002a956e9980 rsp 007fbfffecb8 error 4 > > The daemon really does stop running, every time I try to start > it. Anything else I can try? Strace below. > > Cheers, > Dave > > > # strace ud And now the same with -f please. I didn't see a segfault in the starce and it is probably its child that dies. You can also compile the ud with debug infos and run it in gdb. MfG Goswin
Re: errors upgrading
Alexandru Cabuz <[EMAIL PROTECTED]> writes: > Hello, > > Here's an example of the kind of error I've been getting trying to run > apt-get upgrade on my amd64 system. > > Réception de : 23 ftp://ftp.de.debian.org sid/main libsane 1.0.15-3 [2634kB] > Err ftp://ftp.de.debian.org sid/main libsane 1.0.15-3 > Unable to fetch file, server said > '/debian-amd64/pure64/pool/unstable/main/amd64/s/sane-backends/libsane_1.0.15-3_amd64.deb: > No such file or directory ' > > I'm getting about a dozen of these and that's not counting the > base-config, sed and a couple of other packages which have been broken > for a while now and so I have them on hold for the time being. > > I've never seen this before. What's going on? > > Alex. [EMAIL PROTECTED]:~/archive/pure64$ ls pool/unstable/main/amd64/s/sane-backends libsane-dev_1.0.15-3_amd64.deb sane-backends_1.0.15-3_amd64.changes libsane_1.0.15-3_amd64.deb sane-utils_1.0.15-3_amd64.deb The main archive has the file. Could this be just a transient error caused by the Packages and deb files being out of sync? If it has been like that for more than a day then something is wrong with ftp.de.debian.orgs mirror. MfG Goswin
errors upgrading
Hello, Here's an example of the kind of error I've been getting trying to run apt-get upgrade on my amd64 system. Réception de : 23 ftp://ftp.de.debian.org sid/main libsane 1.0.15-3 [2634kB] Err ftp://ftp.de.debian.org sid/main libsane 1.0.15-3 Unable to fetch file, server said '/debian-amd64/pure64/pool/unstable/main/amd64/s/sane-backends/libsane_1.0.15-3_amd64.deb: No such file or directory ' I'm getting about a dozen of these and that's not counting the base-config, sed and a couple of other packages which have been broken for a while now and so I have them on hold for the time being. I've never seen this before. What's going on? Alex.
Re: When will the amd64 port be stable?
Goswin von Brederlow wrote:
David Liontooth <[EMAIL PROTECTED]> writes:
Ron Johnson wrote:
On Fri, 2004-12-10 at 11:45 -0800, David Liontooth wrote:
Goswin von Brederlow wrote:
Same time the official sarge will be released (+ a day or two) the
unofficial sarge amd64 should be finished.
Hey, that's great news! (News to me anyway.)
Aside from hankering after sarge, I've found sid to be rock
solid at this end (aside from ud and xprt, which segfault).
ud?
uptime daemon -- crashes on startup:
dmesg-2.6.9-ac6-5-FX5500: ud[1921]: segfault at 958a7d00 rip
002a956e9980 rsp 007fb048 error 4
dmesg-2.6.9-ac6-5-riva: ud[1788]: segfault at 958a7d00 rip
002a956e9980 rsp 007fb048 error 4
dmesg-2.6.9-ac6-5-snd-bt87x:ud[1948]: segfault at 958a7d00 rip
002a956e9980 rsp 007fb048 error 4
dmesg-2.6.9-ac6-6-ACPI: ud[3858]: segfault at 958a7d00 rip
002a956e9980 rsp 007fb058 error 4
dmesg-2.6.9-rc2:ud[1625]: segfault at 9589ffc0 rip
002a956e3790 rsp 007fb068 error 4
dmesg-2.6.9-rc2-02-promise: ud[1834]: segfault at 9589ffc0 rip
002a956e3790 rsp 007fb068 error 4
dmesg-2.6.9-rc2-acpi: ud[1891]: segfault at 9589ffc0 rip
002a956e3790 rsp 007fb068 error 4
dmesg-2.6.9-rc2-afterXP:ud[1766]: segfault at 9589ffc0 rip
002a956e3790 rsp 007fb068 error 4
dmesg-2.6.9-rc2-no-acpi:ud[1875]: segfault at 9589ffc0 rip
002a956e3790 rsp 007fb068 error 4
Not exactly crucial. The uptime command works fine.
Dave
That looks more like unaligned access. Unlike other architecture this
seems to get reported as segfault instead of unaligned access.
Or is uptimed realy stoping to run?
MfG
Goswin
Dec 11 12:59:13 clitunno ud[6280]: Uptime daemon starting...
Dec 11 12:59:13 clitunno kernel: ud[6280]: segfault at 958a7d00
rip 002a956e9980 rsp 007fbfffecb8 error 4
The daemon really does stop running, every time I try to start it.
Anything else I can try? Strace below.
Cheers,
Dave
# strace ud
execve("/usr/bin/ud", ["ud"], [/* 15 vars */]) = 0
uname({sys="Linux", node="clitunno", ...}) = 0
brk(0) = 0x504000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2a9556a000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=104400, ...}) = 0
mmap(NULL, 104400, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2a9556b000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
open("/lib/libc.so.6", O_RDONLY)= 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`\324\1\0"...,
640) = 640
fstat(3, {st_mode=S_IFREG|0644, st_size=1294400, ...}) = 0
mmap(NULL, 2353800, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x2a9566c000
mprotect(0x2a9578e000, 1165960, PROT_NONE) = 0
mmap(0x2a9586c000, 241664, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED,
3, 0x10) = 0x2a9586c000
mmap(0x2a958a7000, 14984, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2a958a7000
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2a958ab000
arch_prctl(0x1002, 0x2a958ab520)= 0
munmap(0x2a9556b000, 104400)= 0
rt_sigaction(SIGINT, {0x401af0, [INT], SA_RESTART|0x400}, {SIG_DFL},
8) = 0
rt_sigaction(SIGHUP, {0x401af0, [HUP], SA_RESTART|0x400}, {SIG_DFL},
8) = 0
rt_sigaction(SIGQUIT, {0x401af0, [QUIT], SA_RESTART|0x400},
{SIG_DFL}, 8) = 0
rt_sigaction(SIGTERM, {0x401af0, [TERM], SA_RESTART|0x400},
{SIG_DFL}, 8) = 0
umask(022) = 022
brk(0) = 0x504000
brk(0x525000) = 0x525000
brk(0) = 0x525000
open("/proc/uptime", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2a9556b000
read(3, "74278.70 74054.04\n", 1024)= 18
close(3)= 0
munmap(0x2a9556b000, 4096) = 0
open("/var/run/ud.pid", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=5, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2a9556b000
read(3, "6324\n", 4096) = 5
read(3, "", 4096) = 0
close(3)= 0
munmap(0x2a9556b000, 4096) = 0
kill(6324, SIG_0) = -1 ESRCH (No such process)
open("/var/lib/misc/uptime.record", O_RDONLY) = 3
chmod("/var/lib/misc/uptime.record", 0644) = 0
fstat(3, {st_mode=S_IFREG|0
Re: Acrobat reader
On 2004-12-11 16:52:33 +, Rafael Rodríguez wrote: > Hi. Has anybody got acrobat reader working? Tried apt-get -b source acroread > from marillat's mirror but fails: I've got acroread working but I don't know a ready deb for it. I installed it through the tar.gz from the adobe website. I also installed ia32-libs to provide the required 32bit libs. You also need to modify the acroread wrapper script as described in http://lists.debian.org/debian-amd64/2004/08/msg00321.html Michael
Re: Acrobat reader
None at all... just wanted to have it running embedded in firefox ;) El Sábado, 11 de Diciembre de 2004 18:57, Alexandru Cabuz escribió: > What's the problem with xpdf though?
Re: Acrobat reader
Rafael Rodríguez <[EMAIL PROTECTED]> writes: > Hi. Has anybody got acrobat reader working? Tried apt-get -b source acroread > from marillat's mirror but fails: > > dpkg-shlibdeps: warning: unable to find dependency information for shared > library libXt (soname 6, path /emul/ia32-linux/usr/X11R6/lib/libXt.so.6, > dependency field Depends) That looks like you are trying to build a 32bit binary. I think acroread comes as binary only and just copies itself around when you build it, right? Where does the /emul/ia32-linux/usr/X11R6/lib/libXt.so.6 come from? Chroot? > ... and dozens of errors like that one with another libs Finally, it > explodes: > > dpkg-gencontrol: error: current build architecture amd64 does not appear in > package's list (i386) > dh_gencontrol: command returned error code 65280 > > Any hints? Normal behaviour for an architecture specific package not ported to amd64. Add amd64 in debian/control for a start. MfG Goswin
Re: [OT] Am i in the chroot?
Rafael Rodríguez <[EMAIL PROTECTED]> writes: > Hi. Any simple command so in a shell i can know if i'm into my 32-bit chroot > or in the main system? > > Thx, > > Rafael Rodríguez Use linux32 when you go into the chroot and then uname will show a 32bit system. Apart from this (and other manualy things like file /bin/bash) the only way I know how to detect a chroot is "ls -l /proc/1/root" as root. If it fails you are chrooted. MfG Goswin
Re: Acrobat reader
> Hi. Has anybody got acrobat reader working? Tried apt-get -b source acroread I ain't no expert, but it seems to me acroread is proprietary software and thus that its source code is not available. I have not checked but I would bet 64bit binaries for Linux are not available... What's the problem with xpdf though? Alex. On Sat, 11 Dec 2004 16:52:33 +, Rafael Rodríguez <[EMAIL PROTECTED]> wrote: > Hi. Has anybody got acrobat reader working? Tried apt-get -b source acroread > from marillat's mirror but fails: > > dpkg-shlibdeps: warning: unable to find dependency information for shared > library libXt (soname 6, path /emul/ia32-linux/usr/X11R6/lib/libXt.so.6, > dependency field Depends) > > ... and dozens of errors like that one with another libs Finally, it > explodes: > > dpkg-gencontrol: error: current build architecture amd64 does not appear in > package's list (i386) > dh_gencontrol: command returned error code 65280 > > Any hints? > > Regards, > > Rafael Rodríguez > >
Re: [OT] Am i in the chroot?
Ok, dchroot -d solves the problem... nvm :)
El Sábado, 11 de Diciembre de 2004 18:28, Rafael Rodríguez escribió:
> Would be very nice.. but i'm afraid my .bashrc doesn't load when i
> dchroot!
>
> I don't know what's happening... For example, i have a
>
> PATH=~/bin:${PATH}
>
> in my .bashrc, and when i'm outside the chroot, it works... but my $PATH
> into the chroot doesn't have the new dir! (like .bashrc isn't loaded or
> something).
>
> Doesn't dchroot load a brand new shell or what?
>
> Regards,
>
> Rafael Rodríguez
>
> El Sábado, 11 de Diciembre de 2004 17:07, Peter Palfrader escribió:
> > On Sat, 11 Dec 2004, Rafael Rodríguez wrote:
> > > Hi. Any simple command so in a shell i can know if i'm into my 32-bit
> > > chroot or in the main system?
> >
> > echo 'i386' > /home/chroot/etc/debian_chroot
> >
> > ~/.zshrc:
> >
> > if [ -e /etc/debian_chroot ]; then
> > debian_chroot=$(cat /etc/debian_chroot)
> > fi
> >
> > export PROMPT="${debian_chroot:+[$debian_chroot] [EMAIL PROTECTED]:%~$ "
Re: [OT] Am i in the chroot?
Would be very nice.. but i'm afraid my .bashrc doesn't load when i dchroot!
I don't know what's happening... For example, i have a
PATH=~/bin:${PATH}
in my .bashrc, and when i'm outside the chroot, it works... but my $PATH into
the chroot doesn't have the new dir! (like .bashrc isn't loaded or
something).
Doesn't dchroot load a brand new shell or what?
Regards,
Rafael Rodríguez
El Sábado, 11 de Diciembre de 2004 17:07, Peter Palfrader escribió:
> On Sat, 11 Dec 2004, Rafael Rodríguez wrote:
> > Hi. Any simple command so in a shell i can know if i'm into my 32-bit
> > chroot or in the main system?
>
> echo 'i386' > /home/chroot/etc/debian_chroot
>
> ~/.zshrc:
>
> if [ -e /etc/debian_chroot ]; then
> debian_chroot=$(cat /etc/debian_chroot)
> fi
>
> export PROMPT="${debian_chroot:+[$debian_chroot] [EMAIL PROTECTED]:%~$ "
Re: [OT] Am i in the chroot?
On Sat, 11 Dec 2004, Rafael Rodríguez wrote:
> Hi. Any simple command so in a shell i can know if i'm into my 32-bit chroot
> or in the main system?
echo 'i386' > /home/chroot/etc/debian_chroot
~/.zshrc:
if [ -e /etc/debian_chroot ]; then
debian_chroot=$(cat /etc/debian_chroot)
fi
export PROMPT="${debian_chroot:+[$debian_chroot] [EMAIL PROTECTED]:%~$ "
--
PGP signed and encrypted | .''`. ** Debian GNU/Linux **
messages preferred.| : :' : The universal
| `. `' Operating System
http://www.palfrader.org/ | `-http://www.debian.org/
[OT] Am i in the chroot?
Hi. Any simple command so in a shell i can know if i'm into my 32-bit chroot or in the main system? Thx, Rafael Rodríguez
Acrobat reader
Hi. Has anybody got acrobat reader working? Tried apt-get -b source acroread from marillat's mirror but fails: dpkg-shlibdeps: warning: unable to find dependency information for shared library libXt (soname 6, path /emul/ia32-linux/usr/X11R6/lib/libXt.so.6, dependency field Depends) ... and dozens of errors like that one with another libs Finally, it explodes: dpkg-gencontrol: error: current build architecture amd64 does not appear in package's list (i386) dh_gencontrol: command returned error code 65280 Any hints? Regards, Rafael Rodríguez
Re: When will the amd64 port be stable?
David Liontooth <[EMAIL PROTECTED]> writes: > Ron Johnson wrote: > >>On Fri, 2004-12-10 at 11:45 -0800, David Liontooth wrote: >> >> >>>Goswin von Brederlow wrote: >>> >>> >>> Same time the official sarge will be released (+ a day or two) the unofficial sarge amd64 should be finished. >>>Hey, that's great news! (News to me anyway.) >>>Aside from hankering after sarge, I've found sid to be rock >>>solid at this end (aside from ud and xprt, which segfault). >>> >>> >> >>ud? >> >> >> > uptime daemon -- crashes on startup: > > dmesg-2.6.9-ac6-5-FX5500: ud[1921]: segfault at 958a7d00 rip > 002a956e9980 rsp 007fb048 error 4 > dmesg-2.6.9-ac6-5-riva: ud[1788]: segfault at 958a7d00 rip > 002a956e9980 rsp 007fb048 error 4 > dmesg-2.6.9-ac6-5-snd-bt87x:ud[1948]: segfault at 958a7d00 rip > 002a956e9980 rsp 007fb048 error 4 > dmesg-2.6.9-ac6-6-ACPI: ud[3858]: segfault at 958a7d00 rip > 002a956e9980 rsp 007fb058 error 4 > dmesg-2.6.9-rc2:ud[1625]: segfault at 9589ffc0 rip > 002a956e3790 rsp 007fb068 error 4 > dmesg-2.6.9-rc2-02-promise: ud[1834]: segfault at 9589ffc0 rip > 002a956e3790 rsp 007fb068 error 4 > dmesg-2.6.9-rc2-acpi: ud[1891]: segfault at 9589ffc0 rip > 002a956e3790 rsp 007fb068 error 4 > dmesg-2.6.9-rc2-afterXP:ud[1766]: segfault at 9589ffc0 rip > 002a956e3790 rsp 007fb068 error 4 > dmesg-2.6.9-rc2-no-acpi:ud[1875]: segfault at 9589ffc0 rip > 002a956e3790 rsp 007fb068 error 4 > > Not exactly crucial. The uptime command works fine. > > Dave That looks more like unaligned access. Unlike other architecture this seems to get reported as segfault instead of unaligned access. Or is uptimed realy stoping to run? MfG Goswin
Re: urgent help needed, pure64 -> gcc-3.4
On 04-Dec-11 14:03, Andreas Jochens wrote:
> You need to 'apt-get install --reinstall' all packages which use the
> 'libstdc++5' when you upgrade from pure64 to the gcc-3.4 archive.
An easy way to achieve this would be something like this:
dpkg --get-selections | grep -w install | awk '{print $1}' | xargs -m 10
-- apt-get -y --reinstall install
Regards
Andreas Jochens
Re: urgent help needed, pure64 -> gcc-3.4
On 04-Dec-11 11:27, Corin Langosch wrote: > we run a dual opteron 246 system with pure64 here for > 80 days now. the server only runs mysql 4.1. i always > use the latest official mysql 4.1 binary > "mysql-standard-4.1.7-unknown-linux-x86_64-glibc23.tar.gz" Why don't you use the mysql package from the gcc-3.4 archive? I got some reports which indicated that this works fine. > after changing pure64 to gcc-3.4 in apt/sources.list > and dist-upgrade, mysql always hang. tables got locked > but not unloked, so all queries blocked. also trying > to killall mysqld wasn't able - it just killed nothing > and the server kept running. > > does anybody know why this happens? did i miss anything > important to upgrade? (i read something about apt-get > --reinstall - how to to this with all packages? it always > wants a list of packages...) You need to 'apt-get install --reinstall' all packages which use the 'libstdc++5' when you upgrade from pure64 to the gcc-3.4 archive. Regards Andreas Jochens
urgent help needed, pure64 -> gcc-3.4
Hi, we run a dual opteron 246 system with pure64 here for 80 days now. the server only runs mysql 4.1. i always use the latest official mysql 4.1 binary "mysql-standard-4.1.7-unknown-linux-x86_64-glibc23.tar.gz" after changing pure64 to gcc-3.4 in apt/sources.list and dist-upgrade, mysql always hang. tables got locked but not unloked, so all queries blocked. also trying to killall mysqld wasn't able - it just killed nothing and the server kept running. does anybody know why this happens? did i miss anything important to upgrade? (i read something about apt-get --reinstall - how to to this with all packages? it always wants a list of packages...) we reinstalled the whole system using pure64 and it works again, so it must be something related to gcc-3.4. it would be great it someone could tell me how to upgrade to gcc-3.4 from pure64 so everything just works fine but a with a little more performance :) thanks a lot, corin
Re: Intel EM64T porting machine for Debian
* Chasecreek Systemhouse <[EMAIL PROTECTED]> [2004-12-10 20:56]: > > agreed to set up the machine, host it for a while and give interested > > developers access. This box is not a general .debian.org > > Is this by invitation only? Debian developers will not automatically get access (since it's not a .debian.org box) so people need to request accounts. The machine will be available to people who are interested in working on Debian's AMD64/EM64T port. Stephen Frost is part of the AMD64 porting team and if you're interested in helping out you should just get in contact with him. (Having said this, Intel only just told me that they have shipped the box, so it will take a while to arrive and get installed. If you follow the debian-amd64 list, I'm sure Stephen will announce when people can request accounts.) -- Martin Michlmayr [EMAIL PROTECTED]
Re: A 32bit/64bit performance data point
Oops, I originally replied only to Ron. Well, it's the libgmp (Gnu Multi-Precission math library) folks and the OpenSSL folks that you hope are generating efficient AMD64 code for discrete mathematics over finite fields (DH, El Gamal, DSA) and finite rings (RSA). GMP uses hand-optimized assembly on most architectures, as does OpenSSL. OpenSSL uses it's own big integer code (in crypto/bn). It looks like for 4096-bit moduli, AMD64 asm runs 2 to 4 times as fast as IA-32 asm. (The note says IA-32 asm is about as fast as AMD64 C for the big integer code.) Note that DSA for all key sizes still uses some 160-bit finite field math. -Karl from: http://cvs.openssl.org/getfile/openssl/crypto/bn/asm/x86_64-gcc.c?v=1.1.4.3 * Q. How much faster does it get? * A. 'apps/openssl speed rsa dsa' output with no-asm: * * sign verify sign/s verify/s * rsa 512 bits 0.0006s 0.0001s 1683.8 18456.2 * rsa 1024 bits 0.0028s 0.0002s 356.0 6407.0 * rsa 2048 bits 0.0172s 0.0005s 58.0 1957.8 * rsa 4096 bits 0.1155s 0.0018s 8.7 555.6 * sign verify sign/s verify/s * dsa 512 bits 0.0005s 0.0006s 2100.8 1768.3 * dsa 1024 bits 0.0014s 0.0018s 692.3 559.2 * dsa 2048 bits 0.0049s 0.0061s 204.7 165.0 * * 'apps/openssl speed rsa dsa' output with this module: * * sign verify sign/s verify/s * rsa 512 bits 0.0004s 0.s 2767.1 33297.9 * rsa 1024 bits 0.0012s 0.0001s 867.4 14674.7 * rsa 2048 bits 0.0061s 0.0002s 164.0 5270.0 * rsa 4096 bits 0.0384s 0.0006s 26.1 1650.8 * sign verify sign/s verify/s * dsa 512 bits 0.0002s 0.0003s 4442.2 3786.3 * dsa 1024 bits 0.0005s 0.0007s 1835.1 1497.4 * dsa 2048 bits 0.0016s 0.0020s 620.4 504.6 * * For the reference. IA-32 assembler implementation performs * very much like 64-bit code compiled with no-asm on the same * machine. */ On Fri, 10 Dec 2004 07:40:16 -0600, Ron Johnson <[EMAIL PROTECTED]> wrote: > On Fri, 2004-12-10 at 13:36 +0100, Bill Allombert wrote: > [snip] > > > Also amd64 is the only 64bit extension I know that have a hardware > > 64bitx64bit-to-128bit multiplication. Running this bench on sparc64 > > How much would help crypto work? > > (I hope the GCC AMD64 people noticed, and generate the proper > code... :) > > -- > - > Ron Johnson, Jr. > Jefferson, LA USA > PGP Key ID 8834C06B I prefer encrypted mail. > > "Vegetarians eat Vegetables, Humanitarians frighten me." > Unknown > > >
Re: Re: Kernel compilation problem
I see "general protection rip" message in my logs... -- Slava Risenberg
