sparc debian unstable python snarling apt-get
apt-get update followed by apt-get upgrade or apt-get dist-upgrade has been snarling for a couple of days on python I don't know if this is related to the debian servers being compromised. Clues appreciated re what's going on. I'm not able to search the debian mail archives at the moment about this problem (the archives search server is not responding.) Heitzso
Re: sparc debian unstable python snarling apt-get
apt-get update followed by apt-get upgrade or apt-get dist-upgrade has been snarling for a couple of days on python I don't know if this is related to the debian servers being compromised. Clues appreciated re what's going on. I'm not able to search the debian mail archives at the moment about this problem (the archives search server is not responding.) Heitzso -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] There seems to be a small problem with the setup files. I just did 'apt-get -f dist-upgrade' and that took care of the problem. If you wait for the fix, it might be a few days, since there is a lot if activity in restoring all Debian servers and verifying the content. Bojan
Re: Image too large to fit into destination with 2.6.0-test9
On Tue, 25 Nov 2003 15:34:58 +0100 Thomas Habets [EMAIL PROTECTED] wrote: I thought that was what mattered, but is it fixable? 3MB is not enough for everybody. I'd say it's hardly enough for anybody actually. It's more than enough, it's enough to fit the build that results from using arch/sparc64/defconfig which includes all onboard stock devices Sun ever put into an UltraSPARC system. Is it SILO or the kernel that needs to be fixed? The boot firmware only provides a few MEG of space with which we can unpack things. You guys are building way WAAAY too much crap statically into your kernels, use modules and be happy.
Re: Image too large to fit into destination with 2.6.0-test9
Is it SILO or the kernel that needs to be fixed? Is it like the zImage/bzImage
issue of where in memory the kernel is placed, and if so, can it be made to
load elsewhere?
There's nothing to fix. This limitation comes from the OBP firmware.
I've been building kernels just fine for a long time, and not hit this
limit recently. So long as you use the arch/sparc{,64}/boot/image file,
and use modules, you shouldn't either. The kernel supports modules for
a reason.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/
