On Fri, Dec 28, 2007 at 12:19:18AM +0100, Michael Schmitz wrote:
> OTOH, borked hardware design may well have been a hallmark of m68k
> personal computers (look at the Mac for the real weird stuff). Whatever.
What else is there to say? ;)
Pushing the limits with underpowered hardware!
Peace,
S
On Fri, Dec 28, 2007 at 04:09:21AM +0100, Michael Schmitz wrote:
> (found in arch/m68k/kernel/setup.c)
>
> That address is a virtual address, but (at least on my setup) the kernel
> virtual addresses are identity mapped to physical. So the ramdisk
> (compressed) resides in TT RAM or FastRAM. The
On Thu, Dec 27, 2007 at 11:51:07PM +0100, Michael Schmitz wrote:
> Note to self: when copying around chroots, remember to update
> /var/debbuild/apt.conf ... Sorry, I should have remembered that a lot
> sooner.
Yes, I'm not real thrilled with that bit of code. I haven't thought of a
real good rea
> > > The ramdisk load code needs to make sure a ramdisk is not loaded where it
> > > might interfere with other uses of ST-RAM (i.e. frame buffer or DMA bounce
> > > buffers for SCSI). Where does the ramdisk get loaded at, anyway? Is the
> > > kernel loaded in ST-RAM also?
> >
> > How do I find ou
Hi,
> Update: only pwlib and wesnoth were not ready when we released about two
> hours ago... They can still make it for the next point release which is
> planned for the end of february... Thanks for making sure the
> oldstable-security packages were ready and doing an effort to get as
> up-to-da
Update: only pwlib and wesnoth were not ready when we released about two
hours ago... They can still make it for the next point release which is
planned for the end of february... Thanks for making sure the
oldstable-security packages were ready and doing an effort to get as
up-to-date as possible
> > IIRC any addresses in that range (i.e. above 0xff) are aliased down to
> > fit in 24 bit (ST-RAM on the Falcon only decodes 24 bit, and the VIDEL
> > needs to use ST-RAM). Basically, you used up all available ST-RAM with the
> > ramdisk and now force the framebuffer to use an invalid addres
> > So hobbes is the one listed as buildd_m68k? ;)
yep - me manually taking the package and messing up the user ID again :-(
> >
> > I noticed that wesnoth has two different failed logs showing, the latter
> > of which seems to have an invalid version.
>
> Yes, that's my fault, I'm looking into t
On Thu, Dec 27, 2007 at 07:03:39PM +0100, Luk Claes wrote:
> centericq and qt-x11-free are installed now! :-)
yeah!
> I'm building wesnoth as we speak on crest...
you're in! yeah again.
Peace,
Stephen
--
Stephen R. Marenka If life's not fun, you're not doing it right!
<[EMAIL PROTECTED]>
centericq and qt-x11-free are installed now! :-)
Stephen R Marenka wrote:
> On Thu, Dec 27, 2007 at 09:12:02AM +0100, Michael Schmitz wrote:
>>> oldstable:
>>> pwlib
>> needs-build
building
>>> wesnoth
>> needs-build
building
>>> hobbes barfed on it on the first
On Thu, Dec 27, 2007 at 04:21:13AM +0100, Michael Schmitz wrote:
> > I've been trying to get d-i initrds to work with aranym without
> > trashing the screen [0]. I noticed something interesting in my testing
> > today.
> IIRC any addresses in that range (i.e. above 0xff) are aliased down to
>
On Thu, Dec 27, 2007 at 09:12:02AM +0100, Michael Schmitz wrote:
> > > >>> oldstable:
> > > >>> pwlib
> > > >> needs-build
> > >
> > > building
> > >
> > > >>> wesnoth
> > > >> needs-build
> > >
> > > building
> >
> > hobbes barfed on it on the first go (forgot to patch sbuild). let's see
> > how t
> > >>> oldstable:
> > >>> pwlib
> > >> needs-build
> >
> > building
> >
> > >>> wesnoth
> > >> needs-build
> >
> > building
>
> hobbes barfed on it on the first go (forgot to patch sbuild). let's see
> how this attempt goes. If anyone else wants to beat me to it, have at it.
Still no go - same pr
13 matches
Mail list logo
