Re: Anybody working on xfree 3.3.2??
[ *fx: makes a note to start xloadimage _after_ gnus; I can't actually
see the headers in this message due to the colours emacs ended
up with :/* ]
Michael Schmitz <SCHMITZ@LCBVAX.CCHEM.BERKELEY.EDU> writes:
> 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.
> > o xfree86 is 3.3.1 on m68k, but 3.3.2 on i386 and source
> > o xlib6 no longer exists on m68k (Brian rm'ed it from the archive),
> > making 10+ packages uninstallable without --force-depends
>
> That's a Bad Thing - can't we re-upload it?
Sure, as long as it's xlib6 >= 3.3.2-3.
> 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
is using now (libc6-based). Losing xlib6 is not too much of a bummer
except that it makes ~10 old libc5-compat packages uninstallable and
will confuse people who use dselect. (Oh and make upgrading from the
bo-era impossible, but I doubt/hope there aren't many m68k people like
that still around)
> > o xfree86 3.3.2 contains many security fixes not in 3.3.1, and
> > 3.3.2-4 contains even more.
>
> 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.
> > > So if you want to build xfree just go ahead.
> >
> > You might want to consider waiting for the real 3.3.2-4 which is
> > slated for Monday and fixes a number of security bugs.
>
> Do you have a pre-patch, or who could send me one?
IMHO A pre-patch wouldn't be a good idea... Branden withdrew the
original -4 because xterm was SNAFU (segfaulted on startup) :-) We
should either use -3 or wait for the real -4.
> >BTW: sorry for my absence here, I'm in the presence of trying to
> >rescue my (possibly final) year project, and it's chewing way more of
> >my time than I would like, especially considering how close we are
> >supposed to be to release. Michael, are there any mac kernel updates?
>
> 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.
> Please focus on your project, this isn't near as critical.
No, but it's a lot more fun that fighting the underwhelmingly
documented gtk.
> 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.
> I'll try to do the X thing. The boot floppies seem fairly stable,
> I'll keep abusing them for Mac kernel stress testing - the Atari
> 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.
> > I *really* will try and merge the patches asap, but I made my job
> > a lot harder by upgrading to 2.0.33pl1 as it contains changes to
> > head.S which I'm going to have to somehow merge with your
> > changes.. ickness (C merging I can manage.. assembly? wah). If
> > not I'll go with the, uh.. 980403 patches I have.
>
> Leave that to me :-) I was going to try 2.0.33pl1 anyway, I just
> have to reget the tarball (Jes seems to have messed up and put the
> -pre3 tarball on sunsite again). I'll diff 2.0.29 and 2.0.33pl1
> head.S and build the changes into the Mac head.S - or migrate the
> Mac port to 2.0.33 anyway.
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.
Michael Schmitz <SCHMITZ@LCBVAX.CCHEM.BERKELEY.EDU> writes:
> > > Just out of curiosity, what do you consider more important?
> >
> > Mainly egcs which fixes a lot of problems in other packages [ ... ]
>
> 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).
> > BTW, I have major problems with binutils 2.9-0.1 (built by
> > myself): I can't boot a kernel built using that binutils package
> > (Linux binaries seem to be ok). When switching back to binutils
> > 2.8.1.0.19-1 everything works fine. Is anybody else experiencing
> > this problem?
>
> 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
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)
[1] Not a real address, but you know who I mean...
--
James
--
To UNSUBSCRIBE, email to debian-68k-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: