Re: [ql-developers] Linux v2.4.21 compilation error with gcc v3.1
On Sun, Aug 24, 2003 at 11:25:05AM +0200, Thierry Godefroy wrote: Btw, did someone notice that hdX=ide-scsi is handled differently in 2.4.21? Richard
Re: [ql-developers] Linux v2.4.21 compilation error with gcc v3.1
On Sun, 24 Aug 2003 00:24:26 +0200, Richard Zidlicky wrote:
> On Sat, Aug 23, 2003 at 08:55:28PM +0200, Thierry Godefroy wrote:
>
> > I got no compatibility problem with the crypto API but for when
> > they changed from 2.2 to 2.4 kernel (the data had to be transfered
> > to a new encrypted volume, but that's all).
>
> it will change again for 2.6, probably a few times yet.
>
> > Also, the crypto API is to become the standard, so I'd recommend
> > starting to get used to it right now instead of using a third party
> > software which seems pretty much incompatible with the crypto API
> > (as far as I could see by reading the loop-AES documentation).
>
> the standard is just emerging, it had 2 versions with incompatible
> disk formats last 2 weeks and mount options are still subject of
> discussion.. not a good time to get used to it.
Well, v2.4 kernels are not concerned by these changes, and v2.6
doesn't even exist officially yet (it's still in 'test' stage)...
> So far it seems loop-AES can encrypt or decrypt all formats except
> perhaps some of those with broken IV keys.
It lacks quite a lot of algorithms from what I saw... loop-AES can
do AES, Serpent, Twofish and Blowfish, while the crypto-API knows
about: 3DES, AES, Blowfish, CAST5, IDEA, Mars, RC5, RC6, Serpent and
Twofish for the ciphers, plus: MD5, RIPEMD160, SHA1, SHA256, SHA384,
SHA512 for the digests. And I don't even cite the "deprecated" (unsafe)
ciphers and digests...
> > > that looks very strange. Perhaps I can make some sense out of
> > > it when I see the patch.
> >
> > Alas, there's some weirdness in the rc.sysinit script of ShoeString:
> > it looks like a line in fstab such as:
> >
> > /mnt/cdrom /mnt/cdrom supermount fs=iso9660,dev=/dev/cdrom 0 0
>
> no idea. What would "mount -a" do if that line is in /etc/fstab?
It works just fine in that case (it's how I tested it before rebooting
the first time)... As I told you, this has nothing to do with supermount
itself, as the same behaviour appears on supermount-less kernels...
> Mine simply complains no such fs and that's it but I have newer
> version of the script.
That might explain things... Also, there are quite a few "quirks" in
ShoeString installation, one of them being that you end up with two
different directories holding the init.d scripts (with either different
scripts or two versions of the same...): /etc/init.d (which should be
a symlink instead), and /etc/rc.d/init.d. I moved all the scripts in
/etc/rc.d/init.d and made /etc/init.d a symlink, so I may have ended
up with a deprecated script... But rc.sysinit is in /etc/rc.d and
should not be affected.
For info (it may be of some use to all the users of ShoeString),
there's also a missing symling to /usr/bin/cpp in /lib (ln -s
/usr/bin/cpp /lib/cpp) which prevents .Xdefault of being parsed
at 'startx' time. There are also missing links to the kernel
headers directories in /usr/include ('linux' and 'asm'), preventing
to compile any software (but those symlinks are automatically setup
by my kernel-headers package).
Thierry ([EMAIL PROTECTED]).
Re: [ql-developers] Linux v2.4.21 compilation error with gcc v3.1
On Sat, Aug 23, 2003 at 08:55:28PM +0200, Thierry Godefroy wrote: > I got no compatibility problem with the crypto API but for when > they changed from 2.2 to 2.4 kernel (the data had to be transfered > to a new encrypted volume, but that's all). it will change again for 2.6, probably a few times yet. > Also, the crypto API is to become the standard, so I'd recommend > starting to get used to it right now instead of using a third party > software which seems pretty much incompatible with the crypto API > (as far as I could see by reading the loop-AES documentation). the standard is just emerging, it had 2 versions with incompatible disk formats last 2 weeks and mount options are still subject of discussion.. not a good time to get used to it. So far it seems loop-AES can encrypt or decrypt all formats except perhaps some of those with broken IV keys. > > that looks very strange. Perhaps I can make some sense out of > > it when I see the patch. > > Alas, there's some weirdness in the rc.sysinit script of ShoeString: > it looks like a line in fstab such as: > > /mnt/cdrom /mnt/cdrom supermount fs=iso9660,dev=/dev/cdrom 0 0 no idea. What would "mount -a" do if that line is in /etc/fstab? Mine simply complains no such fs and that's it but I have newer version of the script. I don't see anything in the script itself. > # Source functions > . /etc/init.d/functions > > action $"Super-Mounting the CD-ROM: " mount /mnt/cdrom /mnt/cdrom -t supermount -o > fs=iso9660,dev=/dev/cdrom,ro > action $"Super-Mounting the floppy: " mount /mnt/floppy /mnt/floppy -t supermount -o > fs=vfat,dev=/dev/fd0 this is a good idea, much easier to provide as fully configured but optional addon. Richard
Re: [ql-developers] Linux v2.4.21 compilation error with gcc v3.1
On Sat, 23 Aug 2003 11:06:08 +0200, Richard Zidlicky wrote: > This is loop-AES with additional ciphers btw and I would recommend > to stick with that as it will be maintained for the foreseeable > future. The other intl patches are bound to suffer incompatible > changes every week now that intl stuff was included into 2.6 I got no compatibility problem with the crypto API but for when they changed from 2.2 to 2.4 kernel (the data had to be transfered to a new encrypted volume, but that's all). Also, the crypto API is to become the standard, so I'd recommend starting to get used to it right now instead of using a third party software which seems pretty much incompatible with the crypto API (as far as I could see by reading the loop-AES documentation). The crypto API also brings more cyphers as well as all the digest algorithms... > I will send you the sources of patched util-linux, can be a real > pain to sort out these patches. I re-compiled util-linux (the mount and losetup parts) for use with the crypto API, already... ;-) > > > so it becomes immediately unmounted as soon as you close last > > > reference? > > > > No, the device is permanently mounted and the driver reports an > > absent medium when accessed without a proper medium in the drive... > > that looks very strange. Perhaps I can make some sense out of > it when I see the patch. Alas, there's some weirdness in the rc.sysinit script of ShoeString: it looks like a line in fstab such as: /mnt/cdrom /mnt/cdrom supermount fs=iso9660,dev=/dev/cdrom 0 0 hangs up the booting process when the local filesystems are mounted by rc.sysinit... This also happens if 'noauto' is added to the options (thus preventing the supermount device to be mounted at startup), or when a kernel without supermount support is started (I tried with the original v2.4.18rz kernel and get the same crash after the "no such filesystem" report). It's obviously a problem with the script and not with supermount, which works just fine. I start it in rc.local as a work around, by adding these lines in it: # Source functions . /etc/init.d/functions action $"Super-Mounting the CD-ROM: " mount /mnt/cdrom /mnt/cdrom -t supermount -o fs=iso9660,dev=/dev/cdrom,ro action $"Super-Mounting the floppy: " mount /mnt/floppy /mnt/floppy -t supermount -o fs=vfat,dev=/dev/fd0 By the time you will read this message, the new v2.4.21 kernels and the mount/losetup updates will be available on my website. ;-) Thierry ([EMAIL PROTECTED]).
Re: [ql-developers] Linux v2.4.21 compilation error with gcc v3.1
On Fri, Aug 22, 2003 at 03:47:05PM +0200, Thierry Godefroy wrote: > > have you seen this? > > Bruce Schneier CRYPTO-GRAM, September 15, 2002 > > http://www.counterpane.com/crypto-gram.html > > No, I didn't see it... Interesting... But you didn't quote the conclusion: I think it is not wise to quote any conclusion unless it is the mathematical proof of the possibility to crack (or not) the algorithm. Otherwise new attack techniques could be found any day. > Still, it's a good thing to stay tuned... Also, for really sensitive data, > it's better to use a double encryption scheme, using two different > algorythms (and keys, of course). this is a difficult subject, as far as I am aware opinions are fairly varied whether this will increase safety - in theory it might also hurt safety unless proven otherwise. > Yes, but even if a 060 can perform twice as fast as a Pentium at the same > frequency, the modern Pentiums/Athlons run at 20 times the 060 (core) > frequency... I have a datapoint with serpent256 here: # ll -rw-r--r--1 rz rz 98693120 Oct 5 2002 x.tar # time cat /tst-loop/x.tar >/dev/null real2m14.115s user0m0.190s sys 0m19.090s Loop dev used about 100s for the decryption. Depending on application this may be fast enough. Compared to raw read it appears to slow down things by factor 3 in the worst case. This is loop-AES with additional ciphers btw and I would recommend to stick with that as it will be maintained for the foreseeable future. The other intl patches are bound to suffer incompatible changes every week now that intl stuff was included into 2.6 I will send you the sources of patched util-linux, can be a real pain to sort out these patches. > > so it becomes immediately unmounted as soon as you close last > > reference? > > No, the device is permanently mounted and the driver reports an absent > medium when accessed without a proper medium in the drive... that looks very strange. Perhaps I can make some sense out of it when I see the patch. > ??? Never had a single problem compiling v2.4 kernels with gcc 2.95.3 > on Mandrake 7.2... _But_ I always used -fno-omit-frame-pointer to avoid > the -O2 optimization bug in gcc 2.95... it did strange things on m68k. Overwritten live registers as well as forgotten stack pointer and such. > Also, did you check this patch: > http://gcc.gnu.org/ml/gcc-regression/2000-11/msg2.html > It was for egcs but it looks like the cure to the same problem we got > in gcc... Looking at the various patches, perhaps I have some idea. So far I have simply disabled the check in the compiler because it appears to be internal consistency checking only and should not trigger any new errors. Richard
Re: [ql-developers] Linux v2.4.21 compilation error with gcc v3.1
On Fri, 22 Aug 2003 13:50:48 +0200, Richard Zidlicky wrote: > On Fri, Aug 22, 2003 at 02:14:54AM +0200, Thierry Godefroy wrote: > > > Actually, this is not quite exact. It is true that more cryptoanalyis > > was done on Serpent (which algorythm is easier to analyse). But so far > > more rounds have been broken in AES (Rinjdael) than in Serpent (unless > > I missed one of the lastest articles about thos algorythms, which is > > possible). > > have you seen this? > Bruce Schneier CRYPTO-GRAM, September 15, 2002 > http://www.counterpane.com/crypto-gram.html No, I didn't see it... Interesting... But you didn't quote the conclusion: <> Well, Serpent is still safer than AES... Plus, all these attacks are based on known clear text attack, which leads to this comment in the article: <> Still, it's a good thing to stay tuned... Also, for really sensitive data, it's better to use a double encryption scheme, using two different algorythms (and keys, of course). > > I personally use Serpent with 256 bits keys for > > the encrypted partitions on my PCs. It's of course probably too slow > > for the Q60 though (128 bits keys seem more reasonable for a poor > > 68060 @ 66MHz to deal with...). > > might not be so bad on the Q60, remember that bitshuffling is > traditionally the strongest domain of 680x0 CPU's. Yes, but even if a 060 can perform twice as fast as a Pentium at the same frequency, the modern Pentiums/Athlons run at 20 times the 060 (core) frequency... > > > appart of the extra demon this sound really very much like what autofs > > > does for me. How does it work to release a medium, eg CD or floppy? With > > > autofs I have to wait until it timeouts. > > > > No wait with SuperMount. It's just like if you were using the medium under > > DOS/Windoze (Yuck !), or SMSQ/E... It's 100% kernel based and done at the > > driver level... The problem is that its author doesn't maintain it anymore > > and all the maintnance is now done by the Mandrake developers, and scattered > > in numerous patches to each kernel... > > I know, the details were a bit too fishy last time I looked. > > > It's like a filesystem driver. You configure it in fstab, example: > > > > /mnt/dos/a /mnt/dos/a supermount fs=vfat,dev=/dev/fd0 0 0 > > /mnt/cdrom /mnt/cdrom supermount fs=iso9660,dev=/dev/cdrom 0 0 > > so it becomes immediately unmounted as soon as you close last > reference? No, the device is permanently mounted and the driver reports an absent medium when accessed without a proper medium in the drive... > Could do that with autofs as well but don't like it because > it apparently looses cached buffers on CD roms. Never experimented such problems with SuperMount. > > Do you know if the same problem would arise with older gcc version > > (I was thinking to compile it with gcc-2.95.3...) ? > > not this problem but more serious ones ??? Never had a single problem compiling v2.4 kernels with gcc 2.95.3 on Mandrake 7.2... _But_ I always used -fno-omit-frame-pointer to avoid the -O2 optimization bug in gcc 2.95... > gcc303 might work and is reasonably tested with 2.4 kernels. Thanks to your indications, I managed to patch the v2.4 kernel sources so to work around the gcc bug... I'll release the kernel packages as soon as possible. ;-) Note that the bug is trigered by all four ide-cd.c, ide-floppy.c, ide-tape.c and ide-scsi.c... Also, did you check this patch: http://gcc.gnu.org/ml/gcc-regression/2000-11/msg2.html It was for egcs but it looks like the cure to the same problem we got in gcc... > > There are no SRPMS in it though... Or do I look in the wrong place ? > > they are still on my HD and quite uninteresting because I have > newer ones that ought to be uploaded. > > I think I will try to rebuild glibc/binutils/rpm from RH 9 or rwhide > with gcc-3.3.1 and see what happens, if that works I would try to base > a new distribution on top of this. That would be cool :-) Also, try to think "Manndrake": they got really cool packages and good patches to fix various problems encountered in many pieces of software. Thierry ([EMAIL PROTECTED]).
Re: [ql-developers] Linux v2.4.21 compilation error with gcc v3.1
On Fri, Aug 22, 2003 at 02:14:54AM +0200, Thierry Godefroy wrote: Hi, > Actually, this is not quite exact. It is true that more cryptoanalyis > was done on Serpent (which algorythm is easier to analyse). But so far > more rounds have been broken in AES (Rinjdael) than in Serpent (unless > I missed one of the lastest articles about thos algorythms, which is > possible). have you seen this? Bruce Schneier CRYPTO-GRAM, September 15, 2002 http://www.counterpane.com/crypto-gram.html << Let's start from the beginning. A few months ago, Courtois and Pieprzyk posted a paper outlining a new attack against Rijndael (AES) and Serpent. The authors used words like "optimistic evaluation" and "might be able to break" to soften their claims, but the paper described a better-than-brute-force attack against Serpent, and possibly one against Rijndael as well. Basically, the attack works by trying to express the entire algorithm as multivariate quadratic polynomials, and then using an innovative technique to treat the terms of those polynomials as individual variables. This gives you a system of linear equations in a quadratically large number of variables, which you have to solve. There are a bunch of minimization techniques, and several other clever tricks you can use to make the solution easier. (This is a gross oversimplification of the paper; read it for more detail.) The attack depends much more critically on the complexity of the nonlinear components than on the number of rounds. Ciphers with small S-boxes and simple structures are particularly vulnerable. Serpent has small S-boxes and a simple structure. AES has larger S-boxes, but a very simple algebraic description. (Twofish has small S-boxes, too, but a more complex nonlinear structure. No one has implemented the attack against Twofish, but I'm not willing to stand up and declare the cipher immune.) These are amazing results. Previously, the best attacks worked by breaking simplified variants of AES using very impractical attack models (e.g., requiring immense amounts of chosen plaintext). This paper claimed to break the entire algorithm, and with only one or two known plaintexts. Moreover, the first cipher broken was Serpent: the cipher universally considered to be the safest, most conservative choice. >> > The reason why Rinjdael was choosen as the AES instead of Serpent is > unclear and even highly suspicious to me... It is admitedly a little > faster than Serpent, but was pointed out as less secure than Serpent > too (and as it was not as much crypto-analyzed as Serpent, one may find > a shortcut attack on day or another...). My thought is that the NSA is > probably quite interested in having an AES algorythm which is not too > difficult to break... quite possible. There are other reasons, iirc AES was designed for easy use in smartcards and such, not necessarilly to protect gigabytes of sensitive information. > I personally use Serpent with 256 bits keys for > the encrypted partitions on my PCs. It's of course probably too slow > for the Q60 though (128 bits keys seem more reasonable for a poor > 68060 @ 66MHz to deal with...). might not be so bad on the Q60, remember that bitshuffling is traditionally the strongest domain of 680x0 CPU's. > > appart of the extra demon this sound really very much like what autofs > > does for me. How does it work to release a medium, eg CD or floppy? With > > autofs I have to wait until it timeouts. > > No wait with SuperMount. It's just like if you were using the medium under > DOS/Windoze (Yuck !), or SMSQ/E... It's 100% kernel based and done at the > driver level... The problem is that its author doesn't maintain it anymore > and all the maintnance is now done by the Mandrake developers, and scattered > in numerous patches to each kernel... I know, the details were a bit too fishy last time I looked. > It's like a filesystem driver. You configure it in fstab, example: > > /mnt/dos/a /mnt/dos/a supermount fs=vfat,dev=/dev/fd0 0 0 > /mnt/cdrom /mnt/cdrom supermount fs=iso9660,dev=/dev/cdrom 0 0 so it becomes immediately unmounted as soon as you close last reference? Could do that with autofs as well but don't like it because it apparently looses cached buffers on CD roms. > > probably not, the problem is m68k specific afaics and Mandrake gets > > much less non-x86 testing than RedHat or Debian does. > > Mandrake doesn't develope at all for the m68k architecture, alas... certainly not, neither does RedHat. Otoh you will find patches for the stangest architectures in RH so there is apparently a lot of inofficial development or cross-distibution fertilisation going on. > Do you know if the same problem would arise with older gcc version > (I was thinking to compile it with gcc-2.95.3...) ? not this problem but more serious ones. gcc303 might work and is reasonably tested with 2.4 kernels. > > > If you got a file server (ftp, sftp, web) where to get them, I'd prefer > > > that w
Re: [ql-developers] Linux v2.4.21 compilation error with gcc v3.1
On Thu, 21 Aug 2003 09:58:01 +0200, Richard Zidlicky wrote: > On Wed, Aug 20, 2003 at 04:24:20PM +0200, Thierry Godefroy wrote: > > Hi, > > > I'm using the full crypto-API (with all the ciphers; AES being a rather > > weaker one than Serpent, for example...). > > Serpent is distributed in the ciphers package of loop-AES. > It is an extra download but no hassle compile. > Btw some recent cryptoanalysis suggests AES is actually less > susceptible to a certain type of attack then Serpent so it > is far from easy which one is weaker. Still no immediate > threat. Actually, this is not quite exact. It is true that more cryptoanalyis was done on Serpent (which algorythm is easier to analyse). But so far more rounds have been broken in AES (Rinjdael) than in Serpent (unless I missed one of the lastest articles about thos algorythms, which is possible). The reason why Rinjdael was choosen as the AES instead of Serpent is unclear and even highly suspicious to me... It is admitedly a little faster than Serpent, but was pointed out as less secure than Serpent too (and as it was not as much crypto-analyzed as Serpent, one may find a shortcut attack on day or another...). My thought is that the NSA is probably quite interested in having an AES algorythm which is not too difficult to break... I personally use Serpent with 256 bits keys for the encrypted partitions on my PCs. It's of course probably too slow for the Q60 though (128 bits keys seem more reasonable for a poor 68060 @ 66MHz to deal with...). > > > What is the advantage of SuperMount over autofs? > > > > It's 100% automatic, doesn't need for any demon, and it doesn't hog the > > processor/drives by checking every few seconds that a new medium was > > inserted... As soon as an access is requested to a supermounted medium, > > then a check for changed/absent medium is made transparently for the user. > > It's the standard 'automounter' for Mandrake and I just love it. :-) > > appart of the extra demon this sound really very much like what autofs > does for me. How does it work to release a medium, eg CD or floppy? With > autofs I have to wait until it timeouts. No wait with SuperMount. It's just like if you were using the medium under DOS/Windoze (Yuck !), or SMSQ/E... It's 100% kernel based and done at the driver level... The problem is that its author doesn't maintain it anymore and all the maintnance is now done by the Mandrake developers, and scattered in numerous patches to each kernel... There are times were you just can't find a proper (set of) patch(es) applying cleanly to a given kernel... Well, I could make one out of Mandrake's patches for Linux-vanilla v2.4.21 and I use it since v2.4.21 is out without a single problem. I'll put the patch on my q60linux website. ;-) > How do you configure it? It's like a filesystem driver. You configure it in fstab, example: /mnt/dos/a /mnt/dos/a supermount fs=vfat,dev=/dev/fd0 0 0 /mnt/cdrom /mnt/cdrom supermount fs=iso9660,dev=/dev/cdrom 0 0 More option can be passed to the underlying driver. A doc short is supplied in the patch and appears in the patched Linux sources tree as: Documentation/filesystems/supermount.txt > > Hmm... Strange... Mandrake's patched version of gcc v3.2.2 doesn't > > got this problem on i586 Linux... Perhaps would it be worth rebuilding > > the Mandrake gcc package for Linux-Q60 ? > > probably not, the problem is m68k specific afaics and Mandrake gets > much less non-x86 testing than RedHat or Debian does. Mandrake doesn't develope at all for the m68k architecture, alas... > I looked deeper into it, it is the assignment to error.all which > barfs the compiler. Translated to RTL this assignment is apparently > too complicated for the register life analysis to grok and it won't > set a REG_DEAD note to error.all where it should.. somewhere the > strict_low_part is in the way. > > As a workaround try to declare >char xerr > assign to xerr and return xerr. I patched the sources and I'm trying to compile them as I write this message... Do you know if the same problem would arise with older gcc version (I was thinking to compile it with gcc-2.95.3...) ? > > If you got a file server (ftp, sftp, web) where to get them, I'd prefer > > that way (faster now that I got an ADSL link ;-)... > > well I didn't get ADSL, the sourceforge site is still available of > course. There are no SRPMS in it though... Or do I look in the wrong place ? Thierry ([EMAIL PROTECTED]).
Re: [ql-developers] Linux v2.4.21 compilation error with gcc v3.1
On Wed, Aug 20, 2003 at 04:24:20PM +0200, Thierry Godefroy wrote:
Hi,
> I'm using the full crypto-API (with all the ciphers; AES being a rather
> weaker one than Serpent, for example...).
Serpent is distributed in the ciphers package of loop-AES.
It is an extra download but no hassle compile.
Btw some recent cryptoanalysis suggests AES is actually less
susceptible to a certain type of attack then Serpent so it
is far from easy which one is weaker. Still no immediate
threat.
> > What is the advantage of SuperMount over autofs?
>
> It's 100% automatic, doesn't need for any demon, and it doesn't hog the
> processor/drives by checking every few seconds that a new medium was
> inserted... As soon as an access is requested to a supermounted medium,
> then a check for changed/absent medium is made transparently for the user.
> It's the standard 'automounter' for Mandrake and I just love it. :-)
appart of the extra demon this sound really very much like what autofs
does for me.
How does it work to release a medium, eg CD or floppy? With autofs I have
to wait until it timeouts.
How do you configure it?
> Hmm... Strange... Mandrake's patched version of gcc v3.2.2 doesn't
> got this problem on i586 Linux... Perhaps would it be worth rebuilding
> the Mandrake gcc package for Linux-Q60 ?
probably not, the problem is m68k specific afaics and Mandrake gets
much less non-x86 testing than RedHat or Debian does.
I looked deeper into it, it is the assignment to error.all which
barfs the compiler. Translated to RTL this assignment is apparently
too complicated for the register life analysis to grok and it won't
set a REG_DEAD note to error.all where it should.. somewhere the
strict_low_part is in the way.
As a workaround try to declare
char xerr
assign to xerr and return xerr.
Also attached minimal testcase if you want to compare various compiler
versions, use "-da" to get dumped all RTL passes.
> If you got a file server (ftp, sftp, web) where to get them, I'd prefer
> that way (faster now that I got an ADSL link ;-)...
well I didn't get ADSL, the sourceforge site is still available of
course.
> Gnome2 is a real nightmare and it sucks big time !!! Man, was I pissed
> off when I installed Mandrake v9.1 to update my good ol' Mdk 7.2 on my
> PCs... This stupid new Gnome is not only utterly broken, but it's a
> Hell to configure (they made the configuration 'simpler' by removing
> most of the options: the net result is that you can't get it to work
> your own way. If the default behaviour is fine with you then it's
> alright, else, you can spend hours trying to figure out what to do
> to obtain what you want !). Plus it eats 24Mb more memory than Cnome
> 1.2 on my PCs and is utterly sloww: it's definitely a no-no for a
> Q60, forget it altogether and stick with Gnome v1.4... or better, use
> a lighter, standalone WM, like Icewm (v1.0.9 available on my website),
> Blackbox or the like...
I like fluxbox a lot, the libs of Gnome2 will be still needed though.
> I never had problems with rpm 4.0 on Mandrake, but they pretty much
> changed everything compared to rpm v3... Even the databases are
> incompatible... Who said "upward compatibility" ? It looks like
> this concept was lost and forgotten a couple of years ago already...
Mandrake seems a bit radical with updates. My problem with rpm-4.1x
on the Q60 is that computation of the signature is sometimes broken,
probably a compiler problem.
Rebuilding the database was a bit of a hassle but no problem, old
packages work fine.
Richard
typedef union {
unsigned all :8;
} x_t;
char test_x (char sv)
{
x_t error;
if (sv)
{
error.all = sv;
}
return error.all;
}
Re: [ql-developers] Linux v2.4.21 compilation error with gcc v3.1
On Wed, 20 Aug 2003 10:55:50 +0200, Richard Zidlicky wrote: > On Wed, Aug 20, 2003 at 01:22:19AM +0200, Thierry Godefroy wrote: > > > > Hi ! > > > > In an attempt to bring more pre-compiled packages for the ShoeString > > distribution, I tried to compile the latest Linux kernel (with the > > crypto API patch and the SuperMount patch). > > I was using loop-AES with additional ciphers which worked reliably > for the last few months. I'm using the full crypto-API (with all the ciphers; AES being a rather weaker one than Serpent, for example...). > What is the advantage of SuperMount over autofs? It's 100% automatic, doesn't need for any demon, and it doesn't hog the processor/drives by checking every few seconds that a new medium was inserted... As soon as an access is requested to a supermounted medium, then a check for changed/absent medium is made transparently for the user. It's the standard 'automounter' for Mandrake and I just love it. :-) > > Alas, the compiler stops > > with an internat error; I tried twice, to check it was not due to > > a corrupted memory or processor overheating error (unlikely as my > > 060 is quite cool, equiped as it is with a heatsink+fan). I assume > > it's a gcc bug... Did anyone else encountered it ? Did anyone > > compiled a newer gcc version (Richard, perhaps ? :-) > > it is a compiler bug, the new ide core included since 2.4.21-rc6 > triggers it and I didn't succeed to fix it in gcc-3.2. Hmm... Strange... Mandrake's patched version of gcc v3.2.2 doesn't got this problem on i586 Linux... Perhaps would it be worth rebuilding the Mandrake gcc package for Linux-Q60 ? > I am currently testing gcc-3.3.1. > > The gcc in ShoeString is not very good anyway. I have compiled gcc-3.2 > and glibc-2.2.x (as well as 2/3 of RH 8.0) which appeared to work > remarkably well (with patches) but something got terribly screwed up > just before I could made a release - the compiler no longer > bootstrapped :( Eeeps... ;-( > I can mail you a CD with many new packages If you got a file server (ftp, sftp, web) where to get them, I'd prefer that way (faster now that I got an ADSL link ;-)... > which would be useful for development purposes only, I can't spend > any time to create update or installation routines when a few essential > packages are broken (gnome-2.x) or have strange quirks (rpm-4.x) Gnome2 is a real nightmare and it sucks big time !!! Man, was I pissed off when I installed Mandrake v9.1 to update my good ol' Mdk 7.2 on my PCs... This stupid new Gnome is not only utterly broken, but it's a Hell to configure (they made the configuration 'simpler' by removing most of the options: the net result is that you can't get it to work your own way. If the default behaviour is fine with you then it's alright, else, you can spend hours trying to figure out what to do to obtain what you want !). Plus it eats 24Mb more memory than Cnome 1.2 on my PCs and is utterly sloww: it's definitely a no-no for a Q60, forget it altogether and stick with Gnome v1.4... or better, use a lighter, standalone WM, like Icewm (v1.0.9 available on my website), Blackbox or the like... I never had problems with rpm 4.0 on Mandrake, but they pretty much changed everything compared to rpm v3... Even the databases are incompatible... Who said "upward compatibility" ? It looks like this concept was lost and forgotten a couple of years ago already... :-( Thierry ([EMAIL PROTECTED]).
Re: [ql-developers] Linux v2.4.21 compilation error with gcc v3.1
On Wed, Aug 20, 2003 at 01:22:19AM +0200, Thierry Godefroy wrote: > > Hi ! > > In an attempt to bring more pre-compiled packages for the ShoeString > distribution, I tried to compile the latest Linux kernel (with the > crypto API patch and the SuperMount patch). I was using loop-AES with additional ciphers which worked reliably for the last few months. What is the advantage of SuperMount over autofs? > Alas, the compiler stops > with an internat error; I tried twice, to check it was not due to > a corrupted memory or processor overheating error (unlikely as my > 060 is quite cool, equiped as it is with a heatsink+fan). I assume > it's a gcc bug... Did anyone else encountered it ? Did anyone > compiled a newer gcc version (Richard, perhaps ? :-) it is a compiler bug, the new ide core included since 2.4.21-rc6 triggers it and I didn't succeed to fix it in gcc-3.2. I am currently testing gcc-3.3.1. The gcc in ShoeString is not very good anyway. I have compiled gcc-3.2 and glibc-2.2.x (as well as 2/3 of RH 8.0) which appeared to work remarkably well (with patches) but something got terribly screwed up just before I could made a release - the compiler no longer bootstrapped :( I can mail you a CD with many new packages which would be useful for development purposes only, I can't spend any time to create update or installation routines when a few essential packages are broken (gnome-2.x) or have strange quirks (rpm-4.x) Anyway even 3.2 has this problem so I am currently testing gcc-3.3.1. Richard
[ql-developers] Linux v2.4.21 compilation error with gcc v3.1
Hi ! In an attempt to bring more pre-compiled packages for the ShoeString distribution, I tried to compile the latest Linux kernel (with the crypto API patch and the SuperMount patch). Alas, the compiler stops with an internat error; I tried twice, to check it was not due to a corrupted memory or processor overheating error (unlikely as my 060 is quite cool, equiped as it is with a heatsink+fan). I assume it's a gcc bug... Did anyone else encountered it ? Did anyone compiled a newer gcc version (Richard, perhaps ? :-) Here is the report I get everytime (with either the vanilla or the patched kernel sources): ide-cd.c: In function "ide_cdrom_dump_status" ide-cd.c:619: compiler internal error in verify_local_live_at_start, at flow.c:609 .../... Thierry Godefroy ([EMAIL PROTECTED]). PS: more cool stuff is available from my q60linux site, enjoy ! ( http://q60linux.dyns.net/ or http://thgodef.nerim.net/q60linux/ )
