What we have learned so far on ubuntu-release upgrader hugday
melchiaros at aol.com
Fri Mar 22 10:44:23 UTC 2013
We have done the hugday on ubuntu-release-upgrader yesterday and there
are still tickets open, especially for the triaging step -> so you can
still come up, e.g with recreation with apt-clone.tar.gz in a VM:
(Sorry, the website is written in german; please use e.g chromium
translation popup on entering the website)
The question arises: What we have seen from the bunch of reports there
I start this with one of my observations.
A good part of the problems are caused by ppa's that users have
nincorporated in their system.
Especially the logs shown often to me xorg problems.
They have ppa's integrated that provides xorg components for resolving
their graphical problems that they have with xorg from the main repositorie.
So far we could not say that they do nonsense to their system.
Dysfunctional graphics are good reasons for incroporationg not official
The problem is that the ubuntu-release-upgrader is able to disable ppa's
from source.list, but not able to handle the xorg move back to main with
This makes the upgrade process failing.
Is the user the problem?
I have seen a comment from Sampo555 that points to the policy to
deactivate xorg ppa's before upgrading(thank you that you give the
people a workarround Sampo).
Let us switch for the moment the perspective to that of a user(not
anymore a newbie, but also not down to the shoulders in Ubuntu).
-> S/he could not see that policy from the front of the computer. The
only thing what they see is that without ppa the graphic is a mess. I
have read cases on Ubuntu question section where the graphical system
was completely not useable.
It would affect a good part of the release upgrade problems (may be
arround 20%-30%- just a guess on what I have seen in the logs) when it
would be possible to teach ubuntu-release-upgrader to handle this.
What do you think about?
More information about the Ubuntu-bugsquad