<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Am 17.03.2013 10:42, schrieb Fabio
Marconi:<br>
</div>
<blockquote cite="mid:BLU0-SMTP111C6D9EB727FB30D61F96CA5EF0@phx.gbl"
type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 17/03/2013 01:12, AG Restringere
wrote:<br>
</div>
<blockquote
cite="mid:CALh9bZ1bjsLVXyZyyE8USfv2ZkOVnxBXb-ButQ8bN_PBtM=3ag@mail.gmail.com"
type="cite">Fabio,
<div><br>
</div>
<div>Given these two items:</div>
<div>- Verify the bug is still not fixed</div>
<div>How do you quickly verify if the problem has been fixed?</div>
</blockquote>
<br>
<blockquote
cite="mid:CALh9bZ1bjsLVXyZyyE8USfv2ZkOVnxBXb-ButQ8bN_PBtM=3ag@mail.gmail.com"
type="cite">
<div>What is the process to be used?</div>
</blockquote>
<blockquote
cite="mid:CALh9bZ1bjsLVXyZyyE8USfv2ZkOVnxBXb-ButQ8bN_PBtM=3ag@mail.gmail.com"
type="cite">
<div><br>
</div>
<div> -Request any needed info</div>
<div>What is the specific log(s) and information needed?</div>
<div><br>
</div>
<div>Best,</div>
<div>AG<br>
</div>
<br>
</blockquote>
<font face="Ubuntu">Hallo<br>
<br>
This is one of the cases where it is not possible to reproduce
quickly the issue.<br>
The first thing is to search for duplicates, or scrolling down
the <a moz-do-not-send="true"
href="https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader">ubuntu-release-upgrader
list</a> 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'<br>
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.).<br>
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.<br>
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.<br>
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.<br>
Apport automatically attach log files, analyzing them we can
have hints of what happens during the upgrade.<br>
If needed, the relative logfiles can be found on
/var/log/dist-upgrade.<br>
This is an example of error in apt.log:<br>
<br>
MarkUpgrade() called on a non-upgrable pkg: 'brasero'<br>
ERROR:root:Upgrading 'brasero' failed<br>
Log time: 2013-03-15 18:58:20.835223<br>
<br>
This is a managed error:<br>
<br>
Investigating (0) linux-image-extra-3.5.0-18-generic [ amd64 ]
< 3.5.0-18.29 > ( kernel )<br>
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 )<br>
Considering linux-image-3.5.0-18-generic:amd64 10001 as a
solution to linux-image-extra-3.5.0-18-generic:amd64 -1<br>
Removing linux-image-extra-3.5.0-18-generic:amd64 rather than
change linux-image-3.5.0-18-generic:amd64<br>
Done<br>
<br>
regards<br>
Fabio<br>
<br>
<br>
<br>
<br>
<br>
</font> <br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
Hi Fabio,<br>
<br>
thanks for orgasnisation.<br>
<br>
There is one point I want to discuss:<br>
<br>
You say:<br>
"<br>
<font face="Ubuntu">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.<br>
"<br>
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.<br>
<br>
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.<br>
<br>
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. <br>
The kernel bugs are set automatically to confiremd when they are
reported.<br>
<br>
I think it makes sense to do some similiar here.<br>
<br>
We should set the status to confirmed if the logs provide enough
information. Independed if the user gives additional informations
to the problem.<br>
</font><br>
<font face="Ubuntu"><font face="Ubuntu">(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).<br>
</font><br>
You have already provided the two cases I can get for quick also
in mind.<br>
<br>
The first is the error message:<br>
<br>
"<br>
</font><br>
<font face="Ubuntu"><font face="Ubuntu">MarkUpgrade() called on a
non-upgrable pkg: 'brasero'<br>
ERROR:root:Upgrading 'brasero' failed<br>
Log time: 2013-03-15 18:58:20.835223<br>
</font>"<br>
<br>
and the second is:<br>
<br>
</font><br>
<font face="Ubuntu"><font face="Ubuntu">Investigating (0)
linux-image-extra-3.5.0-18-generic [ amd64 ] < 3.5.0-18.29
> ( kernel )<br>
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 )<br>
Considering linux-image-3.5.0-18-generic:amd64 10001 as a
solution to linux-image-extra-3.5.0-18-generic:amd64 -1<br>
Removing linux-image-extra-3.5.0-18-generic:amd64 rather than
change linux-image-3.5.0-18-generic:amd64<br>
Done<br>
<br>
<br>
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<br>
<br>
investigating(0)<br>
...<br>
invertigating(1)<br>
...<br>
investigation(2)<br>
<br>
and so on until the upgrader gives up.<br>
</font><br>
</font>
</body>
</html>