Announcing the Next Ubuntu Bug Day!
melchiaros at aol.com
Sun Mar 17 15:08:13 UTC 2013
Am 17.03.2013 10:42, schrieb Fabio Marconi:
> On 17/03/2013 01:12, AG Restringere wrote:
>> Given these two items:
>> - Verify the bug is still not fixed
>> How do you quickly verify if the problem has been fixed?
>> What is the process to be used?
>> -Request any needed info
>> What is the specific log(s) and information needed?
> This is one of the cases where it is not possible to reproduce quickly
> the issue.
> The first thing is to search for duplicates, or scrolling down the
> ubuntu-release-upgrader list
> <https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader> or
> googling for: site:bugs.launchpad.net keywordsrelative and in the case
> mark as duplicate, obviously if the bug is fixed in the yellow strip
> will appear the green written `Fix released'
> This particular package is used to upgrade from one release to
> another, so you can understand that the `launchpad' is highly
> customized (extra packages, proprietary drivers, personal settings,
> unsupported packages, ecc. ecc.).
> The only way that we have to reproduce the bug is to recreate the
> scenario of the reporter, unless it is not closely hardware related (
> video, audio, devices, ecc.), in a virtual machine and run the upgrade.
> If the bug does not occour to you and it is reported from just one
> person, then the probabilty to reproduce it again are near to 0.
> In this case simply tell to the reporter that you are not able to
> reproduce the issue, ask for more detailed steps to reproduce,
> subscribe youself to the report and set the status of the bug to
> Apport automatically attach log files, analyzing them we can have
> hints of what happens during the upgrade.
> If needed, the relative logfiles can be found on /var/log/dist-upgrade.
> This is an example of error in apt.log:
> MarkUpgrade() called on a non-upgrable pkg: 'brasero'
> ERROR:root:Upgrading 'brasero' failed
> Log time: 2013-03-15 18:58:20.835223
> This is a managed error:
> Investigating (0) linux-image-extra-3.5.0-18-generic [ amd64 ] <
> 3.5.0-18.29 > ( kernel )
> Broken linux-image-extra-3.5.0-18-generic:amd64 Depends on
> linux-image-3.5.0-18-generic [ amd64 ] < 3.5.0-18.29 > ( kernel )
> Considering linux-image-3.5.0-18-generic:amd64 10001 as a solution
> to linux-image-extra-3.5.0-18-generic:amd64 -1
> Removing linux-image-extra-3.5.0-18-generic:amd64 rather than change
thanks for orgasnisation.
There is one point I want to discuss:
In this case simply tell to the reporter that you are not able to
reproduce the issue, ask for more detailed steps to reproduce, subscribe
youself to the report and set the status of the bug to incomplete.
This is a bit problematic. Other projects like ubiquity(the graphical
installation system) or the kernel itself has stepped beside the
procedure to reproduce the problem that occure.
They have good reasons for. Reproducing is often not possible. And a set
to incomplete may blame the user, because s/he want to give further
information, but is simply not able to because the informations are not
available to the user him/herself.
As far as I have observed ubiquity has changed the policy of bughandling
to set the priority of the report automatically to high when the log
gives enough information.
The kernel bugs are set automatically to confiremd when they are reported.
I think it makes sense to do some similiar here.
We should set the status to confirmed if the logs provide enough
information. Independed if the user gives additional informations to the
(you click on upgrading and it do on every part your system -> the error
may be caused by a configuration/software install month or years ago).
You have already provided the two cases I can get for quick also in mind.
The first is the error message:
MarkUpgrade() called on a non-upgrable pkg: 'brasero'
ERROR:root:Upgrading 'brasero' failed
Log time: 2013-03-15 18:58:20.835223
and the second is:
Investigating (0) linux-image-extra-3.5.0-18-generic [ amd64 ] <
3.5.0-18.29 > ( kernel )
Broken linux-image-extra-3.5.0-18-generic:amd64 Depends on
linux-image-3.5.0-18-generic [ amd64 ] < 3.5.0-18.29 > ( kernel )
Considering linux-image-3.5.0-18-generic:amd64 10001 as a solution to
Removing linux-image-extra-3.5.0-18-generic:amd64 rather than change
which I have seen more in the form that investigation number is
increasing while the upgrader is trying several upgrading routes for a
specific package. like
and so on until the upgrader gives up.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ubuntu-bugsquad