[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 :/* ]


> 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
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.


> > > 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 <= 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
> > 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...


To UNSUBSCRIBE, email to debian-68k-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: