Re: Anybody working on xfree 3.3.2??
Hi,
>> As a side note, the Mac-patched server works on the Falcon (as
>> expected).
>
>Okay, X is now maintained by Branden who has a lot more time for it
>than Mark did, so it should be no trouble getting your patches into
>the source.
Will do. Maybe it gets into -4 then :-)
>> At least if nothing can be built until the release is due ... I hope
>> the binary packages on my disk have survived what I did to that
>> filesystem. If not, I've got a 3.3.1-1 on the Powermac here ...
>
>Remember this is *xlib6*, not xlib6*g* which is the one most everyone
Ok, noted. In that case, not too much will break, and we can live without
it.
>> I've got only the -2 diff plus the diff Stefan forwarded from you.
>
>-3 is on the servers, it should be used in preference to -2 if you
>don't want to wait for -4.
I've got -3, don't worry.
>> How close are we to release, anyway??
>
>At least a month away IMHO. It was slated for.. 5 days ago, but,
>well, I think we missed that deadline somewhat.
:-) Leaves some time to get a few things together.
>> Keep an open ear on the list (I'd still like to build dpkg if I just
>> knew how),
>
>Klee has reappeared; the situation may rectify itself. Also 1.4.0.22
>needs built, so when I do it this time, I'll make an instruction list
>so that you hopefully can reproduce it.
Fine - dpkg for dummies is what I need.
>> IDE-CD bug needs to be fixed, does it still hang after installing
>> base?? I'll find out, I guess.
>
>I don't know to be honest, I've been very remiss with the
>boot-floppies, I haven't looked at them since January or something
>horrendous like that.
Michael and Roman have been working on that, one of them might know.
>> Leave that to me :-) I was going to try 2.0.33pl1 anyway, I just
>
>Okay, thanks, that would be great. Also the HFS patches _are_ in the
>Debian/m68k 2.0.33-7, so please leave them out if when you're doing a
>new diff.
Ok. I've got 2.0.33pl1 on the Falcon now, I'll work on head.S in 2.0.29
first and will migrate the Mac stuff to 2.0.33pl1 as soon as I've got
the SCSI driver stabilized again.
>> What problems in other packages does egcs fix?
>
>groff and sp I suspect. troff is hosed by a bug in the optimization
>of gcc <= 2.7.2.3 and nsgmls seems to be too (though it's such a huge
>mess of C++, I never confirmed that theory).
troff never worked?? Or did someone introduce a feature that confuses
gcc 2.7.2.3?
>> Where does that kernel get stuck? The one thing that seems likely is
>> inline asm wich isn't often used in normal binaries. It's used in
>> some fsck and mkfs tools though :-)
>
>This is extremely bad, if true, and scary, if it's easily
Just my guess, based on my experience with some kernel code and what I've
read about new gcc strategies in interpreting inline asm (register constraints
and clobbers) on linux-kernel.
That's why I'm asking where the kernel gets stuck. That would limit the number
of routines to look at in objdump (shudder).
>reproducible someone should shout to gnu@linux-m68k.org[1] asap.
>(Luckily my kernel images are cross compiled with an older
>cross-binutils, so they should be fine)
Mine are still built with Roman's 2.7.2.1, binutils 2.7.0.1 and work fine.
I'm still wondering why egcs is used, not gcc 2.8. Whatever.
>[1] Not a real address, but you know who I mean...
Yep, someone should tell him. But better have a reasonable description of the
bug before reporting it :-)
Michael
--
To UNSUBSCRIBE, email to debian-68k-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: