On 08/03/2017 02:31 PM, Lennart Sorensen wrote:
On Thu, Aug 03, 2017 at 07:55:09PM +0200, Samuel Thibault wrote:
The gtk initrd is like 38MB, at USB 1.0 speed (1.5Mbps) that's almost
two minutes yes. I however wonder how old a computer needs to be to be
only 1.0...
And how could a 64bit machin
On 07/20/2017 05:51 PM, Ben Hildred wrote:
I need to copy some files off of an old system that users reiserfs 3.6
on an old hardware raid that most rescue cds wont work with.
Fortunately when I pulled out my favorite tool Debian's installer
recognized the raid and correctly identified all the p
Package: console-setup
Version: 1.152
Followup-For: Bug #819288
Upgrading from 1.147 to 1.152 has made this change, as recorded by
etckeeper:
diff --git a/console-setup/cached_setup_keyboard.sh
b/console-setup/cached_setup_keyboard.sh
index 30b46c1..ad6d653 100755
--- a/console-setup/cached_setu
On Mar 30, 2004, at 02:03, Sven Luther wrote:
Notice that there is 200bytes or so of m68k asm, most of them A-trap
calls to the Mac OS rom, concerned. I doubt you have much chance of
getting anything but a 100% identical code, whatever the way you go at
generating it.
That is a good argument that
On Mar 30, 2004, at 01:20, Sven Luther wrote:
I have a fear suspision that this may be more related to newworld, than
the oldworld stuff needed for miboot, which may probably be varying
between the different models we may need to support.
That's the boot block people are arguing about? That is
de
On Mar 28, 2004, at 18:52, Henning Makholm wrote:
Huh? Is the bootsector use written in a kind of machine language that
the regular as(1) for the architecture does not support? I thought
that i386 was the only platform with *that* problem.
Actually, probably yes. It's probably in m68k assembly even
Package: installation-reports
INSTALL REPORT
Debian-installer-version: 2004/01/01
uname -a: (sorry, didn't catch this before wiping it with woody)
Date: 2004/01/02 ~17:00 UTC-0500
Method: Tried several methods, all worked. All used the CD
"Debian testing (105MB)"
.
Tried a normal install (just
Package: mklibs
Version: 0.1.8
Severity: important
Tags: patch
calling gcc -nostdlib -nostartfiles -shared -Wl,-soname=libm.so.6 -ufesetround
-o lib//libm.so.6-so
/home/anthony/cvs/cvs.derobert.net/Soekris/src/libmd5/lib/libmd5_pic.a
-Wl,--version-script=/usr/lib/libm_pic.map -lgcc -L
On Mon, 2003-01-27 at 07:10, Philip Blundell wrote:
> This looks like the familiar problem with mklibs not handling references
> to data symbols. I'll try to find some time to look at that again this
> afternoon.
The reason (well, the glaring one!) is that the symbol doesn't have UND
or whatever
Package: mklibs
Version: 0.1.8
Severity: wishlist
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I managed to mis-generate a _pic.a file as an empty archive, which
managed to send mklibs into an infinite loop. It'd be nice if mklibs
detected when a shared libaries _pic.a did not contain a symbol i
Package: mklibs
Version: 0.1.8
Followup-For: Bug #178343
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I think that typeinfo section in 178511 comes from
throw "Some String"
I wonder if that's whats going on in this bug, too, somehow?
- -- System Information
Debian Release: testing/unst
Package: mklibs
Version: 0.1.8
Severity: important
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This is executing against libraries generated by mklibs:
# /usr/lib/cgi-bin/login.cgi
/usr/lib/cgi-bin/login.cgi: relocation error: /usr/lib/cgi-bin/login.cgi: symbol
_ZTIPKc, version GLIBCPP_3.2 no
Package: mklibs
Version: 0.1.8
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
When run with normal libraries, this works:
LoginCGI() : SpecialCGI(do_create_get_map | do_create_post_map) {
try {
SpecialReader
13 matches
Mail list logo
