Re: etch --> lenny upgrade report on Alpha platform
On Sun, Aug 24, 2008 at 01:29:43AM -0500, Bob Tracy wrote:
> In a nutshell, the instructions I found for doing the dist-upgrade were
> (1) Edit /etc/apt/sources.list
> (2) Change all occurrences of "stable" to "testing".
> (3) apt-get update
> (4) apt-get dist-upgrade
> Step (4) successfully identified and downloaded 1.2 GB of updated packages,
> then bombed spectacularly during the installation of those packages. As
> near as I can tell, "apt-get" got extremely confused by all the
> interdependencies. After watching the train wreck to its conclusion (lots
> of error messages as apt-get's confusion increased), I found a few packages
> had been successfully upgraded in place. A few more were found installed,
> but unconfigured. Still more were in the forced-deconfigured state. I
> ended up spending the next several days manually installing packages with
> "dpkg -i", occasionally having to specify --auto-deconfigure to get past
> some of the more stubborn cases of multiple dependencies.
If it calculated an upgrade and started downloading packages, then that's a
quite positive sign! It means that the ultimate upgrade failure is due to
isolated bugs in one or more of the packages it was trying to install, and
not a systemic issue with dependency changes between the two releases.
A report against upgrade-reports would definitely be useful here, and in
particular I think we would want a copy of /var/log/apt/term.log covering
the upgrade attempt in question, to see what packages failed to upgrade and
why. (The failing packages should be considered RC-buggy, and fixed before
the release.)
> Separate report on the new Xorg radeon driver... There's a new feature
> enabled by default that attempts to use the video BIOS to determine if
> there's anything connected to any of the potentially multiple video
> outputs on the card (VGA and DVI to name two possibilities). There's
> no reason to expect that feature to function properly on a non-x86
> platform, and in that respect, I wasn't disappointed :-). Specifying
> 'Option "DefaultConnectorTable" "true"' in "xorg.conf" causes the
> driver to assume a default video output configuration based on the
> detected chipset, and that got things working for me. The clue that
> led to trying that option? A line of output in the Xorg.0.log file
> where the driver indicated it was having to "guess wildly". Needless
> to say, it "chose poorly".
Ah, nice... :) That sounds like it should be a separate bug report on the
radeon package, then?
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Reply to: