ubuntu-bugcontrol team mailing list archive

[melchiaros <melchiaros@xxxxxxx>]

Am 17.03.2013 10:42, schrieb Fabio Marconi:
> On 17/03/2013 01:12, AG Restringere wrote:
> > Fabio,
> >
> > 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?
> >
> > Best,
> > AG
> Hallo
>
> 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 
> incomplete.
> 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 
> linux-image-3.5.0-18-generic:amd64
> Done
>
> regards
> Fabio

Hi Fabio,

thanks for orgasnisation.

There is one point I want to discuss:

You say:
"
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 
problem.

(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 
linux-image-extra-3.5.0-18-generic:amd64 -1
  Removing linux-image-extra-3.5.0-18-generic:amd64 rather than change 
linux-image-3.5.0-18-generic:amd64
Done


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

investigating(0)
...
invertigating(1)
...
investigation(2)

and so on until the upgrader gives up.