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

Re: 2.2.17 i386 boot-floppies uploading



"Christian T. Steigies" <cts@debian.org> writes:

> On Wed, Oct 04, 2000 at 06:36:17PM -0400, Adam Di Carlo wrote:
> > No, dude, it's just the exact same as README-Users.m4, just
> > translated.  It should be handled just the same.
> > 
> > > Its impossible to upload this, since builds for other
> > > arches will probably also have this file, for their special architecture.
> > 
> > Eh?
> What I mean is, it has to end up in one of the bf-* files since they have an
> arch specific ending. I simply can not upload a README.pl file to incoming.
> If powerpc uploaded on the same day, its rejected, since the m68k files
> already exists WITH AN IDENTICAL NAME. The way I understood the bf, all files
> which are to be uploaded shall end in one of the bf-*<arch> files. Right?

Ah!  Ok -- this is a bug in release.sh I think.  The file should be
flying free and out there like that.

> > > m68k: the mac people want to bump up their kernel to 2.2.16. When we finally
> > > receive the patches, we might be able to built 2.2.16 kernel images for the
> > > other architectures as well, until then we would have to use 2.2.16 for mac
> > > and 2.2.10 for everybody else, is it possible to do that for m68k (I think
> > > Ive seen something similar for powerpc)?
> > 
> > Sure, I think so.  Just fudge around int he top-level Makefile.
> > 
> > Are the kernels uploaded for Potato yet?

> No, they are not even built yet... 2.2.16 is working on my amiga, I'd like
> people with other machines to test it before we use it for boot-floppies.
> These days you even have to build your own kernel-source_2.2.16, thats why
> we (linux-m68k) are officially still at 2.2.10.

Ok.

> BTW, if I upload those images, we should also have a kernel-patch package,
> but I did not see a kernel-source-2.2.16 package in debian.

Oh -- ick.  We got .15 and .17 but not .16.  I guess you'd have to
either upload or ask Xu to upload such a package.

I would *hate* to ship boot-floppies requiring a kernel which cannot
be built using sources in Potato.

> > You are wanting to make Mac install disks for 2.2.10 as well as

> > 2.2.16?  This makes my heart sink.  Is that really necessary?
> I don't want it, the mac guys proposed that, since some machines do not work
> well with 2.2.16. Some only work with 2.2.16, some like Penguin18, some only
> work with Penguin17 and, oh I am sure some can only cope with 2.0.36. Its a
> total mess and I am not really sure what to do without a debian/mac68k
> maintainer.

Ew.  Well... with no maintainer, there is always the option to just
leave it as it is and focus on the part of the port which has active
support and maintainers.

> I only wanted to hear that its not, I mean _how_ feasible it is.

It's feasible, but it's a lot of work to add another flavor, not to
mention the necessary documentation updates and such.

> > > I think we want new kernel images (2.2.10) for amiga and atari anyway, how
> > > much time do we have till 2.2.18 (hint for debian-68k: I need the patches to
> > > go in, without them I can not built kernel-images)?
> > 
> > Christian, you should feel free to burn and release point versions for
> > Mac at any time.  Just tag/dpkg-buildpackage -uc -us/debsign then
> > upload it.  It's just a source upload rather than just a binary
> > upload.

> Argh, no, please not for mac. I don't have a mac, I work for m68k. I'd like
> to keep it as simple as possible, thus one kernel-image version for all
> subarches. If mac guys want very special things, they have to create a mac
> maintainer...

I meant to point out that any porters can do boot-floppies point
releases if they need to.  I'm not requiring that you do.... :)

> > Thus we could have 2.2.18 on Tuesday (i386) then 2.2.19 on Friday
> > (m68k) or whatever, it doesn't matter, integers are cheap and
> > plentiful.  I don't believe in making all ports wait for all other
> > ports.

> Yup, sure.

Well, keep us updated.

-- 
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>



Reply to: