Re: debian-installer: kernel lagging for sh4, m68k, alpha
Hector Oron dixit:
>m68k 2.6.26 (-7) 2.6.26-1 # unoficial
I’ve got working 2.6.32-26+m68k.2 which I uploaded to unreleased on
debian-ports.org yesterday, and 2.6.32-27+m68k.3 is almost built.
The kernels for m68k sort of need patches to build which, at the
current time, will probably not be added to the sid (2.6.32-*)
kernel to keep it stable. (Also, I’m building them with gcc-4.4
right now, because we got that into better shape than gcc-4.3.)
Can you use kernels from d-p.o unreleased for the installer?
Stephen said that d-i kernels were traditionally cross-built
manually anyway, IIRC.
Preliminary debdiff (from dpkg-buildpackage -S before building it)
at: https://www.freewrt.org/~tg/debs68k/notyet/linux-2.6/linux-2.6_2.6.32-27+m68k.3.debdiff
(will move to debs68k/dists/sid/main/PS-ok-unrel/linux-2.6/ once tested)
I’m currently at
│Note: Writing set_irq_chip.9
│Warn: AUTHOR sect.: no personblurb|contrib for Thomas Gleixner
│Note: AUTHOR sect.: see see http://docbook.sf.net/el/contrib
│Note: AUTHOR sect.: see see http://docbook.sf.net/el/personblurb
│Warn: AUTHOR sect.: no personblurb|contrib for Ingo Molnar
│Note: AUTHOR sect.: see see http://docbook.sf.net/el/contrib
│Note: AUTHOR sect.: see see http://docbook.sf.net/el/personblurb
in the compilation process (doing an arch+indep native build for
the first time, previously I built the indep portion on i386), so
the binary part is finished but not yet packaged or tested. The
difference to 2.6.32-26+m68k.2 is that RTC_GENERIC is enabled on
atari for ARAnyM, and it’s resynched with 2.6.32-27, so I expect
it to work, but you can never be sure… (if I don’t manage it until
tonight or maybe tomorrow morning, it will take a few days more due
to a dentist visit *shudders*).
Since the package is for d-p.o unreleased, it’s nothing that should
be applied as-is. Specifically, either the compiler switch to gcc-4.4
(will be uploaded today) should be made m68k specific, or the config
needs CONFIG_ARCH_WANT_FRAME_POINTERS and CONFIG_FRAME_POINTER to
work around a gcc-4.3 bug. The patches… fixing them should be applied
right now, I think; enabling them is questionable as some touch MI
stuff, such as msdosfs. They’re needed (well, a subset of them) for
ARAnyM machine support though (without, it boots but has no ethernet,
which is kind of bad) which is vital to development.
bye,
//mirabilos
--
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence. -- Coywolf Qi Hunt
Reply to: