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

Re:



On Sat, May 12, 2007 at 11:24:36AM +0200, Michael Schmitz wrote:
> > > I doubt that - parts will be uninstallable at pretty much all times.
> > > That's why it would be nice to have testing (or maybe testing-m68k, based
> > > on etch-m68k).
> >
> > testing should be based on sid.
> 
> Color me stupid, but now I don't understand the 'there is no testing for
> m68k because there is no etch' business. We would need to have some
> baseline for sid packages to be checked against for installability, and
> that would (initially) have been etch-m68k?

etch-m68k is whatever we had in testing at the time etch was released.

You may remember that we weren't considered for testing for months,
which lead to some divergence and a fair amount of trouble re-syncing.

> > > Re: volunteers: I have volunteered to help Wouter with managing testing
> > > for m68k even before the etch release. Repeatedly. Only, anything in the
> > > way of documentation or description of the testing ftpmaster scripts, or
> > > any other tools needed to control progression of unstable packages into
> > > testing-m68k, has NOT been forthcoming. Ever.
> >
> > When I asked about m68k and testing on release, they said they were fine
> > with the idea of m68k testing. However, until we solve our outstanding
> > toolchain problems (gcc-4.1, gcc-4.2, and glibc tls), it pretty much isn't
> > going to happen.
> 
> What's with gcc-4.1? TLS I see, 4.2 OK but how does that interfere with
> _testing_? It's a red herring, that's how.

gcc-4.1 failed to build for the last three releases (the 4.1.2 series)
and several weeks.

gcc is what got us into trouble and release doesn't want to reinstate us 
unless we have a fair chance of keeping up this time. I can't really
blame them.

> > > Back to wearing my 'm68k kernel hacker' hat ...
> >
> > We need more of that too (still don't have 2.6.20 on m68k :).
> 
> Uh, messy. I'll try t make time for that. Having a non-crashing aranym for
> powerpc and amd64 would help.

I got the version in etch to run fine on i386 with the etch image from
<http://web.zln.cz/~joy/etch.img.gz>. However, I haven't managed to get
d-i to boot without hosing the video.

> > Having parted know about atari partitions would also be nice -- making
> > it much easier to install on atari. If anyone is interested, there are
> > some preliminary patches floating around I can point you to.
> 
> Personally, I would not touch parted with a ten foot pole. Bloatware,
> buggy. But I can look over the patches.

It's what d-i uses and that's what's keeping atari from being fully
supported in d-i. Once that's working, I can hopefully test more d-i
stuff with aranym (my devious plan).

The patches are in svn at
<svn://svn.debian.org/svn/parted/upstream/branches/trunk+atari>

and in a tarball at 
<http://people.debian.org/~smarenka/d-i/atari-parted.tar.bz2>.

Thanks,

Stephen

-- 
Stephen R. Marenka     If life's not fun, you're not doing it right!
<stephen@marenka.net>

Attachment: signature.asc
Description: Digital signature


Reply to: