Re: [Launchpad-users] Old bugs for Gnome Commander are not valid - who can help me to close them?

[Utkarsh Gupta]

Hi Uwe,

On Thu, Aug 15, 2024 at 12:19 PM Uwe Scholz  wrote:
> I am the upstream project maintainer of Gnome Commander.

Aha, nice to meet you! :)

> On the launchpad site there are a lot of old and partially
> deprecated / invalid bugs listed for this software.
>
> https://bugs.launchpad.net/ubuntu/+source/gnome-commander
>
> Can anyone help me closing those bugs? I literaly don't know
> how to work with launchpad since I am not familiar with Ubuntu.

No worries at all. Can you please at least comment on the invalid or
already fixed bugs so that we can asses and mark them as "invalid" or
"fix released" (if they're fixed in the recent version in Ubuntu -
brownie points if you can mention the packages version in Ubuntu
they're fixed in :)).

Just list those bugs here and I can act on them accordingly.




- u

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Ubuntu 23.04 is Unusable with GNOME 44.0 Due to Major Bugs - Priority Must Be for GNOME 44.1 ASAP!

[Andreas Hasenack]

Do you have launchpad bugs for these issues? I do have freezes every now
and then, and I have seen the cursor being stuck in the resize icon, and
wanted to check if the reports match what I'm seeing on my system (xorg).

On Tue, May 16, 2023 at 11:44 AM tothepoin...@gmail.com <
tothepoin...@gmail.com> wrote:

> I am sure I am many who have already pointed this out, but Gnome 44.0 in
> Ubuntu 23.04 is plagued with bugs, windows not focusing, random freezes
> which requires a hard-reset, mouse cursor stuck on resize icon and do not
> even try using a Wayland session. And...And...It's a mess.
>
> Gnome 44.1 is a major, MAJOR bug fix release that resolves all these
> problems.  It must be released ASAP to fix 23.04!
>
> Why have you guys not made it a priority so as to make 23.04 stable?
> Other distros had made it a priority and have long put out 44.1, except
> Ubuntu!  I had to downgrade to 22.10.
>
> If you are in the process of releasing it then fantastic.  What's the
> timeline on that?
>
> Thank you in advance.
> --
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
>
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Ubuntu 23.04 is Unusable with GNOME 44.0 Due to Major Bugs - Priority Must Be for GNOME 44.1 ASAP!

[tothepoin...@gmail.com]

I am sure I am many who have already pointed this out, but Gnome 44.0 in
Ubuntu 23.04 is plagued with bugs, windows not focusing, random freezes
which requires a hard-reset, mouse cursor stuck on resize icon and do not
even try using a Wayland session. And...And...It's a mess.

Gnome 44.1 is a major, MAJOR bug fix release that resolves all these
problems.  It must be released ASAP to fix 23.04!

Why have you guys not made it a priority so as to make 23.04 stable?  Other
distros had made it a priority and have long put out 44.1, except Ubuntu!
I had to downgrade to 22.10.

If you are in the process of releasing it then fantastic.  What's the
timeline on that?

Thank you in advance.
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Bugs in building glibc

[rafi Moor]

Hello,
I would like to report two bugs I’ve encountered while trying to build glibc on 
Ubuntu 18.04.
I’ve used glibc_2.27-3ubuntu1.3.
I’ve only investigated the source of the second, since I’ve found a workaround 
for the first.

1

Problem:
The following tests fail during the build:
FAIL: misc/tst-preadvwritev2
FAIL: misc/tst-preadvwritev64v2

Workaround:
Remove gdb for the time of the build. This make these unsupported and the tests 
are skiped.

2

Problem:
With kernel 5.5.7 and higher the following test fails:
FAIL: misc/test-errno-linux

Root cause:
In the file sysdeps/unix/sysv/linux/test-errno-linux.c the first argument to 
quotactl() is Q_GETINFO instead of QCMD(Q_GETINFO, )
Kernel 5.4.0 returns (wrongly) ENODEV which is in the list of expected errors, 
so the test passes.
Kernel 5.5.7 returns (correctly) EINVAL and the test fails

Solution:
Edit the file and replace the line:
  quotactl, Q_GETINFO, NULL, -1, (caddr_t) &dqblk);
with:
  quotactl, QCMD(Q_GETINFO,USRQUOTA), NULL, -1, (caddr_t) 
&dqblk);

Integrate the change in the build source:
dpkg-source --commit

In addition I couldn’t download glibc_2.27-3ubuntu1.3 with “apt source”, so I 
had do download it manually.

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: bugs in php-xajax with PHP7

[Nish Aravamudan]

On Fri, Jun 21, 2019 at 5:34 AM Robie Basak  wrote:

> On Thu, Jun 20, 2019 at 08:52:59PM -0500, Lindsay Haisley wrote:
> > When I get some time, I'll go through PHP files and post a unified
> > diff, but I'm pretty busy, so it may be a while. This must be fixed,
> > though, or php-xajax is unusable as-is with PHP7.
>
> Thank you for offering a patch! Please see
> https://wiki.ubuntu.com/StableReleaseUpdates#Procedure for details on
> how to get these fixes landed in Ubuntu, and feel free to ask here if
> you have any questions.
>

For what it's worth, our version is the same as (basically) what is in
Debian now. Upstream is at a beta release and per this issue:
https://github.com/Xajax/Xajax/issues/40 still doesn't have PHP7 support.
There are some other recommendations in that ticket. Simplest choice may be
to remove php-xajax on 16.04+.

-Nish
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: bugs in php-xajax with PHP7

[Robie Basak]

On Thu, Jun 20, 2019 at 08:52:59PM -0500, Lindsay Haisley wrote:
> When I get some time, I'll go through PHP files and post a unified
> diff, but I'm pretty busy, so it may be a while. This must be fixed,
> though, or php-xajax is unusable as-is with PHP7.

Thank you for offering a patch! Please see
https://wiki.ubuntu.com/StableReleaseUpdates#Procedure for details on
how to get these fixes landed in Ubuntu, and feel free to ask here if
you have any questions.


signature.asc
Description: PGP signature
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

bugs in php-xajax with PHP7

[Lindsay Haisley]

I just upgraded a server to Ubuntu 16.04 LTS. This version supplies
PHP7.0 leaving only a stub for PHP5.

I have a number of system web applications which use xajax, and the
package php-xajax v0.5-1ubuntu1 is offered with xenial, and is
installed.

The PHP code with this version of php-xajax contains a number of pass-
by-reference expressions, e.g. "$xuf =& new xajaxUserFunction($xuf);"
in xajax-core/xajax.inc.php (and other files). The use of the pass-by-
reference operator "=&" is disallowed in PHP7 for instantiating objects
and will generate a syntax error. Because objects are assigned by
reference anyway, the "&" may (must!) be omitted. 

I've fixed a bunch of these in several xajax files, which involves
turning on error_reporting in the proper places and going after these
errors one by one, but I doubt if I've gotten all of them.

When I get some time, I'll go through PHP files and post a unified
diff, but I'm pretty busy, so it may be a while. This must be fixed,
though, or php-xajax is unusable as-is with PHP7.

-- 
Lindsay Haisley   | "The only unchanging certainty
FMP Computer Services |is the certainty of change"
512-259-1190  |
http://www.fmp.com| - Ancient wisdom, all cultures

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Scilab bugs 1739476 and 1739477 on launchpad

[Nrbrtx]

Dear Ubuntu and Debian developers!

Please take care on the following bugs in Scilab:

   - https://bugs.launchpad.net/ubuntu/+source/scilab/+bug/1739476 - Scilab
   6.0 launches, shows its window and closes immediately on bionic
   - https://bugs.launchpad.net/ubuntu/+source/scilab/+bug/1739477 - Scilab
   6.0 shows warnings about files from package liblucene4.10-java, but does
   not depend on it


Scilab users in Debian and in Ubuntu need fully-functional Scilab on Ubuntu
18.04 LTS.


With best regards,
Norbert.
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: LibreOffice Bugs/failures part 221

[Ralf Mardorf]

On Sun, 17 Jul 2016 20:31:45 +0200, Petter Adsen wrote:
>On Sat, 16 Jul 2016 15:55:15 -0700 paulwheeler wrote:
>
>> When I click on LibreOffice from the menu or the panel shortcut,
>> NOTHING HAPPENS!  
>
>This is not a support list, and stop shouting.

To emphasize it might be better to write
  _nothing happens._
instead of
  NOTHING HAPPENS!
capital letters easily could be misunderstood. Repeated punctuation
character seems to be caused by a broken keyboard or tremor.

>> My System: Linux Mint 17.3 Cinnamon 64-bit, Cinnamon version 2.8.8  
>
>This is not a Mint list either.

Indeed, but chances are good that subscribers of
https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
are willing to help Mint users, too.

I have to admit that I most of the times dislike people who chose Mint
and ask for support on an Ubuntu mailing list, but I guess the majority
of subscribers have another point of view and have absolutely no
problems with a request from a Mint user. However, this wasn't a
request, it was a complain, so we only could advice to be more careful
with upgrades.

Ubuntu and the Ubuntu based Mint are release model distros, so apart
from security related upgrades not much happens. If there should be an
upgrade for software that is very important for a user, it's good
practise to read news and release notes on the upstream homepage and
maybe not that important, but anyway worth reading, the release notes
of the package, before upgrading. Reading package release notes could
be less interesting for users and also it's not that easy to do before
upgrading, but taking a look at the homepage of upstream, not Debian,
the real upstream of the people who write this software is vital.

Nobody needs to do it for each lib, but for important software this is
something that does help to avoid wasting time with trouble.

Regards,
Ralf

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: LibreOffice Bugs/failures part 221

[Petter Adsen]

On Sat, 16 Jul 2016 15:55:15 -0700
paulwheeler  wrote:

> When I click on LibreOffice from the menu or the panel shortcut,
> NOTHING HAPPENS!

This is not a support list, and stop shouting.

> My System: Linux Mint 17.3 Cinnamon 64-bit, Cinnamon version 2.8.8

This is not a Mint list either.

Petter

-- 
"Chaos, panic and disorder. My work here is done." --Anne Onymous

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

LibreOffice Bugs/failures part 221

[paulwheeler]

I used synaptic to remove all evidence of libreoffice from my system

I did a search from "/" as root and found no libreoffice files.  Just for 
paranoia sake and to remove doubt that there is some hidden directory 
containing office.
Nothing found.

I used synaptic to install libreoffice1:5.0.3~rc2-0ubuntu1~trusty2


When I click on LibreOffice from the menu or the panel shortcut, NOTHING 
HAPPENS!


I rebooted my system.


When I click on LibreOffice from the menu or the panel shortcut, NOTHING 
HAPPENS!

ps -A reveal NO process for office



Why does office not run???



My System: Linux Mint 17.3 Cinnamon 64-bit, Cinnamon version 2.8.8
Linux Kernel 3.16.0-38-generic
AMD Phenom II x4 810 Processor x 4 with 8GiB memory



-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Bugs on Unity 8 in pc

[cariboo]

On 2016-02-06 09:20 AM, Roberto Sánchez Fernández wrote:
> I want to add my own personal experience with unity 8 + mir, in case It
> proved useful
> 
> In my case it didn't work at all. It showed the login screen but didn't
> let me introduce my password.
> 
> I'm using 15.10 and the 635GT with the NVIDIA propietary driver with a
> 4770 processor and 16 GB of RAM.  Maybe the problem is that I have to
> run Xenial but I report the problem here. since I tried to update via
> do-release-upgrade -p and didn't go so well.
> 
> 
> 
> El 06/02/16 a las 13:40, Ramon Marquez escribió:
>> i've installed Unity 8 manually through:
>>
>> sudo apt-get update && sudo apt-get dist-upgrade
>> sudo apt-get install unity8-desktop-session-mir
>>
>> I would like to point you to the most common bugs I've found , but first
>> they tell them the technical specs of my pc:
>>
>> - CPU Intel Core 2 Duo E7400 2,8GHz x2
>> - RAM Memory 4GB
>> - Graphics Card NVIDIA GeForce (EVGA) 98000GT 1Gb VRAM
>> - Hard Disk SATA 2 Western Digital WCC3FLJAHUU7 1TB
>> - Ubuntu 16.04 Xenial Xerus 64 bits (BIOS for the time since I generated
>> by UEFI system problems)
>> - MotherBoard Intel DG41RQ
>> - Graphics Stack by default (Mesa 11.1.1 - xserver-xorg-video-Nouveau
>> 1.0.12-1) i am not using the propietary drivers
>> - Monitor Dell P2212H 1920 x 1080 (16:9), output DVI
>>
>> well, the common bugs i've found are:
>>
>> - you have to log in to twice: On lightdm and in Unity8 (i think so...)
>> - The applications don't work (webbrowser for example) so nor work
>> options sound system, screen ...
>> - The aplication in the software center are not installed after they
>> have been downloaded
>> - there are options that are not within the pc as airplane mode
>> - There is not launcher and everything has to be managed by a window scopes
>> - The pointer mouse is very large
>>
>> Well that's all for now, greetings!
>> -- 
>> WindTux <http://www.windtux.com/> - Noticias, Tips y mas Sobre los
>> Eternos Rivales de la Informática
>>
>>
> 
The proper place to report bugs is https://bugs.launchpad.net/. If you
are unsure how to create a valid bug report, see
https://help.ubuntu.com/community/ReportingBugs

Regards

cariboo
-- 
Ubuntu Forums Administrator

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Bugs on Unity 8 in pc

[Ramon Marquez]

The propietary graphics don't support Mir

El 6/2/2016 a las 12:50 p. m., Roberto Sánchez Fernández escribió:

I want to add my own personal experience with unity 8 + mir, in case It
proved useful

In my case it didn't work at all. It showed the login screen but didn't
let me introduce my password.

I'm using 15.10 and the 635GT with the NVIDIA propietary driver with a
4770 processor and 16 GB of RAM.  Maybe the problem is that I have to
run Xenial but I report the problem here. since I tried to update via
do-release-upgrade -p and didn't go so well.



El 06/02/16 a las 13:40, Ramon Marquez escribió:

i've installed Unity 8 manually through:

sudo apt-get update && sudo apt-get dist-upgrade
sudo apt-get install unity8-desktop-session-mir

I would like to point you to the most common bugs I've found , but first
they tell them the technical specs of my pc:

- CPU Intel Core 2 Duo E7400 2,8GHz x2
- RAM Memory 4GB
- Graphics Card NVIDIA GeForce (EVGA) 98000GT 1Gb VRAM
- Hard Disk SATA 2 Western Digital WCC3FLJAHUU7 1TB
- Ubuntu 16.04 Xenial Xerus 64 bits (BIOS for the time since I generated
by UEFI system problems)
- MotherBoard Intel DG41RQ
- Graphics Stack by default (Mesa 11.1.1 - xserver-xorg-video-Nouveau
1.0.12-1) i am not using the propietary drivers
- Monitor Dell P2212H 1920 x 1080 (16:9), output DVI

well, the common bugs i've found are:

- you have to log in to twice: On lightdm and in Unity8 (i think so...)
- The applications don't work (webbrowser for example) so nor work
options sound system, screen ...
- The aplication in the software center are not installed after they
have been downloaded
- there are options that are not within the pc as airplane mode
- There is not launcher and everything has to be managed by a window scopes
- The pointer mouse is very large

Well that's all for now, greetings!
--
WindTux <http://www.windtux.com/> - Noticias, Tips y mas Sobre los
Eternos Rivales de la Informática




--
WindTux <http://www.windtux.com/> - Noticias, Tips y Mas Sobre los 
Eternos Rivales de la Informática
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Bugs on Unity 8 in pc

[Roberto Sánchez Fernández]

I want to add my own personal experience with unity 8 + mir, in case It
proved useful

In my case it didn't work at all. It showed the login screen but didn't
let me introduce my password.

I'm using 15.10 and the 635GT with the NVIDIA propietary driver with a
4770 processor and 16 GB of RAM.  Maybe the problem is that I have to
run Xenial but I report the problem here. since I tried to update via
do-release-upgrade -p and didn't go so well.



El 06/02/16 a las 13:40, Ramon Marquez escribió:
> i've installed Unity 8 manually through:
> 
> sudo apt-get update && sudo apt-get dist-upgrade
> sudo apt-get install unity8-desktop-session-mir
> 
> I would like to point you to the most common bugs I've found , but first
> they tell them the technical specs of my pc:
> 
> - CPU Intel Core 2 Duo E7400 2,8GHz x2
> - RAM Memory 4GB
> - Graphics Card NVIDIA GeForce (EVGA) 98000GT 1Gb VRAM
> - Hard Disk SATA 2 Western Digital WCC3FLJAHUU7 1TB
> - Ubuntu 16.04 Xenial Xerus 64 bits (BIOS for the time since I generated
> by UEFI system problems)
> - MotherBoard Intel DG41RQ
> - Graphics Stack by default (Mesa 11.1.1 - xserver-xorg-video-Nouveau
> 1.0.12-1) i am not using the propietary drivers
> - Monitor Dell P2212H 1920 x 1080 (16:9), output DVI
> 
> well, the common bugs i've found are:
> 
> - you have to log in to twice: On lightdm and in Unity8 (i think so...)
> - The applications don't work (webbrowser for example) so nor work
> options sound system, screen ...
> - The aplication in the software center are not installed after they
> have been downloaded
> - there are options that are not within the pc as airplane mode
> - There is not launcher and everything has to be managed by a window scopes
> - The pointer mouse is very large
> 
> Well that's all for now, greetings!
> -- 
> WindTux <http://www.windtux.com/> - Noticias, Tips y mas Sobre los
> Eternos Rivales de la Informática
> 
> 

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Bugs on Unity 8 in pc

[Ramon Marquez]

i've installed Unity 8 manually through:

sudo apt-get update && sudo apt-get dist-upgrade
sudo apt-get install unity8-desktop-session-mir

I would like to point you to the most common bugs I've found , but first 
they tell them the technical specs of my pc:


- CPU Intel Core 2 Duo E7400 2,8GHz x2
- RAM Memory 4GB
- Graphics Card NVIDIA GeForce (EVGA) 98000GT 1Gb VRAM
- Hard Disk SATA 2 Western Digital WCC3FLJAHUU7 1TB
- Ubuntu 16.04 Xenial Xerus 64 bits (BIOS for the time since I generated 
by UEFI system problems)

- MotherBoard Intel DG41RQ
- Graphics Stack by default (Mesa 11.1.1 - xserver-xorg-video-Nouveau 
1.0.12-1) i am not using the propietary drivers

- Monitor Dell P2212H 1920 x 1080 (16:9), output DVI

well, the common bugs i've found are:

- you have to log in to twice: On lightdm and in Unity8 (i think so...)
- The applications don't work (webbrowser for example) so nor work 
options sound system, screen ...
- The aplication in the software center are not installed after they 
have been downloaded

- there are options that are not within the pc as airplane mode
- There is not launcher and everything has to be managed by a window scopes
- The pointer mouse is very large

Well that's all for now, greetings!
--
WindTux <http://www.windtux.com/> - Noticias, Tips y mas Sobre los 
Eternos Rivales de la Informática
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

outdated kilo release packages with critical bugs

[Stepan Fedorov]

Hello!

I have just deployed OpenStack on trusty from ubuntu cloud archive, and it
seems like packages was not updated since june 2015.

This is the bugfix in upstream stable/kilo
 branch dated by 29
Jun :
https://github.com/openstack/nova/commit/e459add4dfceece2a3c727f3c61d0edfa83ca95a

This bug is critical - we are unable to delete instances until it fixed.

Package python-nova in my installation still contains this bug:

root@compute2:~# head -n 560
/usr/lib/python2.7/dist-packages/nova/compute/manager.py |tail -n 10

:param instance: the instance for which events should be purged
:returns: a dictionary of {event_name: eventlet.event.Event}
"""
@utils.synchronized(self._lock_name(instance))
def _clear_events():
return self._events.pop(instance.uuid, {})
return _clear_events()

def cancel_all_events(self):

Package details:


root@compute2:~# dpkg -S
/usr/lib/python2.7/dist-packages/nova/compute/manager.py
python-nova: /usr/lib/python2.7/dist-packages/nova/compute/manager.py


root@compute2:~# apt-cache policy python-nova
python-nova:
  Installed: 1:2015.1.1-0ubuntu1~cloud2
  Candidate: 1:2015.1.1-0ubuntu1~cloud2
  Version table:
 *** 1:2015.1.1-0ubuntu1~cloud2 0
700 http://ubuntu-cloud.archive.canonical.com/ubuntu/
trusty-updates/kilo/main amd64 Packages
100 /var/lib/dpkg/status
 1:2014.1.5-0ubuntu1.3 0
500 http://archive.ubuntu.com/ubuntu/ trusty-updates/main amd64
Packages
 1:2014.1.3-0ubuntu1.1 0
500 http://security.ubuntu.com/ubuntu/ trusty-security/main amd64
Packages
 1:2014.1-0ubuntu1 0
500 http://archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages


root@compute2:~# apt-cache show python-nova=1:2015.1.1-0ubuntu1~cloud2
Package: python-nova
Source: nova
Priority: extra
Section: python
Installed-Size: 18622
Maintainer: Ubuntu Developers 
Architecture: all
Version: 1:2015.1.1-0ubuntu1~cloud2
Recommends: python-mysqldb
Suggests: python-ldap
Provides: python2.7-nova
Depends: openssh-client, openssl, python-amqplib (>= 0.6.1), python-anyjson
(>= 0.3.3), python-babel (>= 1.3), python-boto (>= 2.32.1),
python-cinderclient (>= 1:1.1.0), python-decorator (>= 3.4.0),
python-eventlet (>= 0.16.1), python-glanceclient (>= 1:0.15.0),
python-greenlet (>= 0.3.2), python-iso8601 (>= 0.1.9), python-jinja2 (>=
2.6), python-jsonschema (>= 2.0.0), python-keystonemiddleware (>= 1.5.0),
python-kombu (>= 2.5.12), python-lxml (>= 2.3), python-m2crypto,
python-migrate (>= 0.9.5), python-netaddr (>= 0.7.12), python-neutronclient
(>= 1:2.3.11), python-oslo-concurrency (>= 1.8.0), python-oslo-config (>=
1:1.9.3), python-oslo-context (>= 0.2.0), python-oslo-db (>= 1.7.0),
python-oslo-i18n (>= 1.3.0), python-oslo-log (>= 1.0.0),
python-oslo-messaging (>= 1.8.0), python-oslo-middleware (>= 1.0.0),
python-oslo-rootwrap (>= 1.6.0), python-oslo-serialization (>= 1.4.0),
python-oslo-utils (>= 1.4.0), python-paramiko (>= 1.13.0), python-paste,
python-pastedeploy (>= 1.5.0), python-pbr (>= 0.6), python-psutil (>=
1.1.1), python-pyasn1, python-pycadf (>= 0.6.0), python-rfc3986 (>= 0.2.0),
python-routes (>= 1.12.3), python-simplejson, python-six (>= 1.9.0),
python-sqlalchemy (>= 0.9.7), python-stevedore (>= 1.3.0), python-webob (>=
1.2.3), python (>= 2.7), python (<< 2.8), python:any (>= 2.7.1-0ubuntu2)
Conflicts: python-cjson
Supported: 18m
Filename: pool/main/n/nova/python-nova_2015.1.1-0ubuntu1~cloud2_all.deb
Size: 2005632
SHA256: 0f61fb707dafe0fd25e6fab0aedcc4a6c8b666f857815fd94780cf66b377067c
SHA1: e75fef813115c2462a0b8791fdfb5425374cbff3
MD5sum: ce823c18794ae58adcf66e2e0c673fb3
Description-en: OpenStack Compute Python libraries
 OpenStack is a reliable cloud infrastructure. Its mission is to produce
 the ubiquitous cloud computing platform that will meet the needs of public
 and private cloud providers regardless of size, by being simple to
implement
 and massively scalable.
 .
 OpenStack Compute, codenamed Nova, is a cloud computing fabric controller.
In
 addition to its "native" API (the OpenStack API), it also supports the
Amazon
 EC2 API.
 .
 Nova is intended to be modular and easy to extend and adapt. It supports
many
 different hypervisors (KVM and Xen to name a few), different database
backends
 (SQLite, MySQL, and PostgreSQL, for instance), different types of user
 databases (LDAP or SQL), etc.
 .
 This package contains the core Python parts of Nova.
Description-md5: 9e7471c108af7843da4a920afe750d19
Original-Maintainer: Openstack Maintainers 
Python-Version: 2.7



So, my question is: what is the correct way to obtain critical bugfixes for
OpenStack Juno from ubuntu cloud archive?

Thank you!


-- 
Stepan G. Fedorov 
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Compiz has hundreds of critical bugs in Unity (& other desktop session with compiz) on Utopic & not usable for everyday use

[Khurshid Alam]

Hi,

On Utopic (after fresh install & updates) I am experiencing tons of bugs in
Unity & almost nothing really works. The real issue is that, these bugs
affects taking screenshot & desktop video recording which is preventing me
to report any new bugs.

I. 'Show Desktop' on launcher crashes compiz for any Gtk-Headerbar app when
using any third party Gtk(3.12) theme.

How to reproduce on Utopic:

1. sudo apt-get install Numix
2. sudo apt-get install gnome-tweak-tool
3. change Gtk theme to Numix
4. Open any app with Gtk-Headerbar (& NOT directly patched by Ubuntu) like
gnome-tweak-tool, gnome-system-log
2. enable show-desktop on unity launcher
3. Click on show-desktop first time. it will show desktop.
4. Click on it again, it crashes compiz & sometimes does not recover from
it. Users have to fallback to TTY & force restart lightdm.

Compiz on other desktop shell/session works relatively well. For example in
Gnome-Flashback-Compiz session this issue doesn't happen.

Filed a bug here:
https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1387163






II. Any desktop recording tool doesn't work with compiz. I tried with
gtk-recordmydesktop & kazaam.

Problems:

1. Unity elements are not visible in the video like dash & sometime right
click menu.

2. Sometime the windows (any) are not visible & appears transparent.

3. It failed to capture any default compiz effect like scale (Super+w)

4. Sometime after completing recording it saves the previously recorded
video! (until I run "compiz --replace").


For example, in this video (http://youtu.be/JQT6LTUXIe8), I opened dash,
searched for terminal & opened it. But in the video nothing is visible.

However, recording works very well in *NON-Compiz* session, i.e.
gnome-flashback (metacity).






III. Screenshot tool (gnome-screenshot)  fails to capture screenshot after
certain time.

How to reproduce:

1. open gnome-screenshot gui. Capture whole screen. save it.
2. open it again. This time capture a window. save it.
3. capture a area don't save it.
4. Repeat 1,2,3 few times.
5. After some time it will show the preview of previously taken screenshot
& save that image. It is impossible to take any new screenshot util I run
"compiz --replace".

not sure what causing this issue but I could not reproduce it on non
compiz session. And If I remember correctly, it did not happen when I was
on couple of updates behind from Utopic beta.


There are other bugs in compiz ( I will file more when I have time) which
affects not only Unity but other compiz desktop-session as well
(gnome-flashback-compiz).

I tried to reset compiz with "dconf reset /org/compiz/ && setsid unity" AND
deleting everything from /home/$user directorybut nothing helped. So
far what I have seen, this release is probably the most unstable (in
compiz) & preventing users to perform even some basic tasks.

Thanks.
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Launchpad - Tagging of bugs

[Phil Wyett]

Hi all,

Recently I have seen many new or unknown tags being added to launchpad
bugs that are not present on https://wiki.ubuntu.com/Bugs/Tags or its
sub pages.

One example is 'kern-key' that is not listed for the kernel.

There are others. It would be nice if related devs could update their
respective pages to list all the latest tags in use by them.

Regards

Phil



signature.asc
Description: This is a digitally signed message part
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Reporting bugs directly to Launchpad?

[Colin Watson]

On Sat, Aug 03, 2013 at 12:17:23AM +0300, Simos Xenitellis wrote:
> On Sat, Aug 3, 2013 at 12:06 AM, Patrick Goetz wrote:
> > I must have missed some new revision, as I no longer seem to be able to
> > post bugs directly to launchpad.  I go to
> >
> >
> > https://bugs.launchpad.net/**ubuntu/saucy<https://bugs.launchpad.net/ubuntu/saucy>
> >
> > and click on "Report a bug" on the top right hand side of the page. Rather
> > than taking me to a bug report screen, this now takes me to an Ubuntu
> > Documentation page 
> > (https://help.ubuntu.com/**community/ReportingBugs<https://help.ubuntu.com/community/ReportingBugs>
> > ).
> 
> The link for "Report a bug" takes you to
> https://bugs.launchpad.net/ubuntu/saucy/+filebug which then redirects to
> https://help.ubuntu.com/community/ReportingBugs
> It is obviously some bug or usability change.

This was changed years ago, with the aim of encouraging people to use
the ubuntu-bug tool.  There's documentation buried in ReportingBugs for
the rare cases where ubuntu-bug can't be used for whatever reason, but
if it's at all possible for you to use ubuntu-bug which attaches more
information for us, please do.

-- 
Colin Watson   [cjwat...@ubuntu.com]

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Reporting bugs directly to Launchpad?

[Simos Xenitellis]

On Sat, Aug 3, 2013 at 12:06 AM, Patrick Goetz wrote:

> I must have missed some new revision, as I no longer seem to be able to
> post bugs directly to launchpad.  I go to
>
>
> https://bugs.launchpad.net/**ubuntu/saucy<https://bugs.launchpad.net/ubuntu/saucy>
>
> and click on "Report a bug" on the top right hand side of the page. Rather
> than taking me to a bug report screen, this now takes me to an Ubuntu
> Documentation page 
> (https://help.ubuntu.com/**community/ReportingBugs<https://help.ubuntu.com/community/ReportingBugs>
> ).
>

The link for "Report a bug" takes you to
https://bugs.launchpad.net/ubuntu/saucy/+filebug which then redirects to
https://help.ubuntu.com/community/ReportingBugs
It is obviously some bug or usability change.

I can only imagine that the change happened because it makes sense to
identify the package first before filing a bug report.
In any case, you can file a bug report for Launchpad, at
https://bugs.launchpad.net/launchpad The "Report a bug" link here, does
work.

Simos
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Reporting bugs directly to Launchpad?

[Patrick Goetz]

I must have missed some new revision, as I no longer seem to be able to 
post bugs directly to launchpad.  I go to


   https://bugs.launchpad.net/ubuntu/saucy

and click on "Report a bug" on the top right hand side of the page. 
Rather than taking me to a bug report screen, this now takes me to an 
Ubuntu Documentation page (https://help.ubuntu.com/community/ReportingBugs).


All I really want to do is report a bug, not read up on the theory of 
how to report a bug.  Is this still possible somehow?






--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: mdadm bugs 946758 and 946344

[Dmitrijs Ledkovs]

On 04/07/12 10:23, Robie Basak wrote:
> On Tue, Jul 03, 2012 at 08:57:15PM +1200, Tim Frost wrote:
>> Now that I can see activity and comments for both bug reports, I see
>> that apport-retrace has changed the summary in bug 946758, although the
>> crash reports on the affected systems that I run show the same
>> information as in bug 946344.
>>
>> What is the best forum for discussing these specific bugs?  And, as an
>> affected user, how can I assist in working to identify cause, and/or
>> possible fixes [the affected systems are my work desktop, and my main
>> home system, so I don't want to put alpha code on either of them]? 
> 
> I browsed the bug and from looking at the stack trace the problem seemed
> obvious, so I investigated and have posted a fix. It's now in the
> sponsorship queue so somebody will review it in the next week or two.
> 
> The bug doesn't exist in Quantal as it has already been fixed upstream.
> It only affects Precise.
> 
> If this is to get fixed in Precise, the hardest part is to get the fix
> tested carefully to ensure that it doesn't cause regressions. Assuming
> that the fix is accepted for Precise, it'll enter precise-proposed and
> there will be a call for testing in the bug. If you can follow the bug
> and test the proposed package when it is announced, then this would be
> great. If nobody can test a proposed fix, then it is unlikely to go in,
> and your only option will be to upgrade to the next release when it
> comes out.
> 
> Robie
> 

Please note, that I had an mdadm SRU targeting precise, but it got
rejected on a couple of technical points. I will integrate your debdiff
into that one, and reupload.

see details at:
https://bugs.launchpad.net/ubuntu/precise/+source/mdadm/+bug/1009973

-- 
Regards,
Dmitrijs.



signature.asc
Description: OpenPGP digital signature
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: mdadm bugs 946758 and 946344 (was: Re: Private bugs - mdadm)

[Robie Basak]

On Tue, Jul 03, 2012 at 08:57:15PM +1200, Tim Frost wrote:
> Now that I can see activity and comments for both bug reports, I see
> that apport-retrace has changed the summary in bug 946758, although the
> crash reports on the affected systems that I run show the same
> information as in bug 946344.
> 
> What is the best forum for discussing these specific bugs?  And, as an
> affected user, how can I assist in working to identify cause, and/or
> possible fixes [the affected systems are my work desktop, and my main
> home system, so I don't want to put alpha code on either of them]? 

I browsed the bug and from looking at the stack trace the problem seemed
obvious, so I investigated and have posted a fix. It's now in the
sponsorship queue so somebody will review it in the next week or two.

The bug doesn't exist in Quantal as it has already been fixed upstream.
It only affects Precise.

If this is to get fixed in Precise, the hardest part is to get the fix
tested carefully to ensure that it doesn't cause regressions. Assuming
that the fix is accepted for Precise, it'll enter precise-proposed and
there will be a call for testing in the bug. If you can follow the bug
and test the proposed package when it is announced, then this would be
great. If nobody can test a proposed fix, then it is unlikely to go in,
and your only option will be to upgrade to the next release when it
comes out.

Robie

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

mdadm bugs 946758 and 946344 (was: Re: Private bugs - mdadm)

[Tim Frost]

Dmitrijs,

On Mon, 2012-07-02 at 12:35 +0100, Dmitrijs Ledkovs wrote:
> On 02/07/12 12:25, Tim Frost wrote:
> > I am one of a number of people affected by an apparent bug in mdadm.
> > The official master bug in launchpad is marked as private - #946758
[trimmed]
> Automatically filed bugs via apport are all initially marked as private.
> Ubuntu BugSquad works on the bugs and trianges / makes them public if
> there is no sensitive data in the bug report and the automatically
> attached files.
> 
> I have checked the attachments on the bug, and there doesn't seem to be
> anything private (apart from hostnames, user names & mount points).
> 
> I therefore have now marked the bug public.
> 

Thanks for that.

Now that I can see activity and comments for both bug reports, I see
that apport-retrace has changed the summary in bug 946758, although the
crash reports on the affected systems that I run show the same
information as in bug 946344.

What is the best forum for discussing these specific bugs?  And, as an
affected user, how can I assist in working to identify cause, and/or
possible fixes [the affected systems are my work desktop, and my main
home system, so I don't want to put alpha code on either of them]? 



Tim

-- 
Tim Frost 


signature.asc
Description: This is a digitally signed message part
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Private bugs - mdadm

[Dmitrijs Ledkovs]

On 02/07/12 12:25, Tim Frost wrote:
> I am one of a number of people affected by an apparent bug in mdadm.
> The official master bug in launchpad is marked as private - #946758
> (https://bugs.launchpad.net/bugs/946758 for those who have access to
> it).  My best reference (which I have subscribed to) is #946344
> (https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/946344 ) and there
> is a message associated with that bug as follows:
> 
>   Remember, this bug report is a duplicate of a private bug.
>Comment here only if you think the duplicate status is wrong. 
> 
> 
> 
> From what I an tell, this bug has been around for a year, affecting
> people who use RAID, but have some partitions (in my case, it is swap
> partitions) that are not managed by the raid subsystem.
> 
> How can I (and other affected people) track progress [or update the
> master bug report with useful information/patches/...] if the master bug
> is private? 
> 
> I know that there are reasons for protecting sensitive data, but there
> should be a way of creating a master bug record in Launchpad that has
> the data needed to track the issue, without exposing any sensitive data.
> 

Automatically filed bugs via apport are all initially marked as private.
Ubuntu BugSquad works on the bugs and trianges / makes them public if
there is no sensitive data in the bug report and the automatically
attached files.

I have checked the attachments on the bug, and there doesn't seem to be
anything private (apart from hostnames, user names & mount points).

I therefore have now marked the bug public.

-- 
Regards,
Dmitrijs.



signature.asc
Description: OpenPGP digital signature
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Private bugs - mdadm

[Tim Frost]

I am one of a number of people affected by an apparent bug in mdadm.
The official master bug in launchpad is marked as private - #946758
(https://bugs.launchpad.net/bugs/946758 for those who have access to
it).  My best reference (which I have subscribed to) is #946344
(https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/946344 ) and there
is a message associated with that bug as follows:

Remember, this bug report is a duplicate of a private bug.
 Comment here only if you think the duplicate status is wrong. 



From what I an tell, this bug has been around for a year, affecting
people who use RAID, but have some partitions (in my case, it is swap
partitions) that are not managed by the raid subsystem.

How can I (and other affected people) track progress [or update the
master bug report with useful information/patches/...] if the master bug
is private? 

I know that there are reasons for protecting sensitive data, but there
should be a way of creating a master bug record in Launchpad that has
the data needed to track the issue, without exposing any sensitive data.


Tim

-- 
Tim Frost 


signature.asc
Description: This is a digitally signed message part
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

LTS regressions and duplicate bugs

[Alexandre Strube]

Hello list,

After upgrading one of my machines to Precise, I started experiencing
couple of problems. Thing is, the automatic report tool always did its job,
which was to check if the bug existed (it did [1]), and eventually point me
to askubuntu.com.

Thing is, the bug obviously exists, as I experience it over and over in a
fully upgraded machine, but this specific bug was closed as expired for
lack of response from the original poster.

I am never sure if my reports are sent or not, because I never appeared in
the list of subscribers for this bug (being the submission anonymous), and
I have no idea if the reports were sent at all.

I wonder if this happens by design or it is just something that went
overlooked by the apport team.

[1] https://bugs.launchpad.net/bugs/912134

-- 
[]
Alexandre Strube
su...@ubuntu.com
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Where to report bugs in immutable wiki pages? Plus, one such report

[Reuben Thomas]

I can't find anything on the wiki about where to report errors in
immutable pages. The one I'm thinking of is in:

 https://wiki.ubuntu.com/X/Troubleshooting/Freeze

where it says: "Alternatively, you can disable DRI support in your
xorg.conf (see below)."

This makes sense in the context (it's talking about crashes caused by
3D screensavers), but the example lower down the page shows how to
disable DPMS, not DRI. Since disabling DRI is probably impractical for
most users these days (since most default desktops require graphics
acceleration), maybe simply remove this sentence?

-- 
http://rrt.sc3d.org

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Need Support For Hardware & Live Usb Issue + Bugs version 0.1

[Navdeep Singh Sidhu]

I have Dell Xps 15 with config:-
8 Gb RAM
2nd generation i7 processor 2.2 GHz Boost 2.0 upto 3.30 GHz
Dual Graphics Card Intel HD 3000 & nvidia geforce GT 540M with Optimus
Techonology
720 GB hardisk
Motherboard Dell XPS system L502X
Intel centrino 6230 Network Card with BT 3.0

I have installed 2 linux distro on my External USB portable seagate 500 GB
hardisk fedora 15 & Ubuntu 11.04. i have installed these distro by using HP
pavilion dv 2762 tx with config:-

Core2duo 1.83Ghz
2Gb ram
nvidia geforce 9600m graphics card

Both these distro works with all other older laptops Like HP, Dell studio  1
yr old config , Compaq 5 yr old, but not on my Dell XPS 15.
To check my laptops hardware compatibility i used a Ubuntu 10.10 live Cd. it
works fine . i use this cd as a live media but when i tried same Ubuntu
10.10 on live usb it gives blank screen or error which i mentioned below.
To check that my iso file damaged or my download has been corrupted or not,
i tried different distros with different desktop enviornment like
Gnome,KDE,Xcfe & Lxde. i tried fedora 15, ubuntu 10.10, ubuntu 10.04, ubuntu
11.04. slackware,eduboss each with avail flavors.
But all i have tried gives almost same error with each distro. i don't know
what is this some kind of bug or lack of support with dell chipset
(hardware). if live cd boots well then i think there is nohardware
compatibility issue with linux. I think this is lack of usb support because
may be Linux has no support until now for latest motherboards or hardware
architects.

These are the errors i got with different distros. i am not able to figure
out what's going on bcz i'm rookie in Linux programming. But if anyone can
do it, plz help me i haven't run my linux from previous 1 and half month and
i'm a linux addicted.
starting from Fedora 15 gnome(almost same for kde except starting numbers)

error:-
[   2.571729] [drm:intel_drm_platform_mux_
info] *ERROR* MUX INFO CALL FAILED
[   2.571847] [drm:intel_drm_platform_mux_info] *ERROR* MUX INFO CALL FAILED

Dropping to debug shell.
sh.can't acess tty:job control off
dracut:/#


Fedora 15 LXDE

[   2.514402] nonveau :01:00.0:invalid ROM contents
[   2.614971] [drm] nonveau :01:00.0:POINTER to BIT load vol table
invalid
[   2.639331] [drm] nonveau :01:00.0:0xd518:12cwr fail: -6
[   2.75332] [drm] nonveau :01:00.0:PGRAPH:unsupported chipset,please
report!
[   2.753646] [drm] nonveau :01:00.0:PGRAPH:unknown config:2/0/0/0,1
[   2.755342] [drm] nonveau :01:00.0: failed to load fuc 409 d


[   2.919340] [drm:intel_drm_platform_mux_info] *ERROR* MUX INFO CALL FAILED
[   2.919447] [drm:intel_drm_platform_mux_info] *ERROR* MUX INFO CALL FAILED

Dropping to debug shell.
sh.can't acess tty:job control off
dracut:/#


Fedora 15 XCFE

[   2.563563] [drm:intel_drm_platform_mux_info] *ERROR* MUX INFO CALL FAILED
[   2.563680] [drm:intel_drm_platform_mux_info] *ERROR* MUX INFO CALL FAILED

Dropping to debug shell.
sh.can't acess tty:job control off
dracut:/#


EDUBOSS (Debian derivative) (I apologize but i have write the full error i
got bcz may be it helps somebody to find what's going on)

BOOT FAILED !
The debian live image failed to boot. Please file a bug against the
'live-initramfs' package or email the debian Live mailing list at <
debian-l...@lists.debian.org> make sure to note the exact version, name and
distribution of the image you were attempt to boot.

The file /live.log contains same debugging information but booting with
debug command line parameter will greatly increase it's verbosity which is
extremely useful when diagnosing issues.

live-initramfs will start a shell.
The error message was: Unable to find a medium containing a live file
system.

Busy Box v.1.10.2 (Debian 1:1.10.2-2) built in shell (ash)

Enter 'help' for a list of built in commands.

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Fwd: Need Support For Hardware & Live Usb Issue + Bugs version 0.1

[Navdeep Singh Sidhu]

i have Dell Xps 15 with config:-
8 Gb RAM
2nd generation i7 processor 2.2 GHz Boost 2.0 upto 3.30 GHz
Dual Graphics Card Intel HD 3000 & nvidia geforce GT 540M with Optimus
Techonology
720 GB hardisk
Motherboard Dell XPS system L502X
Intel centrino 6230 Network Card with BT 3.0

I have installed 2 linux distro on my External USB portable seagate 500 GB
hardisk fedora 15 & Ubuntu 11.04. i have installed these distro by using HP
pavilion dv 2762 tx with config:-

Core2duo 1.83Ghz
2Gb ram
nvidia geforce 9600m graphics card

Both these distro works with all other older laptops Like HP, Dell studio  1
yr old config , Compaq 5 yr old, but not on my Dell XPS 15.
To check my laptops hardware compatibility i used a Ubuntu 10.10 live Cd. it
works fine . i use this cd as a live media but when i tried same Ubuntu
10.10 on live usb it gives blank screen or error which i mentioned below.
To check that my iso file damaged or my download has been corrupted or not,
i tried different distros with different desktop enviornment like
Gnome,KDE,Xcfe & Lxde. i tried fedora 15, ubuntu 10.10, ubuntu 10.04, ubuntu
11.04. slackware,eduboss each with avail flavors.
But all i have tried gives almost same error with each distro. i don't know
what is this some kind of bug or lack of support with dell chipset
(hardware). if live cd boots well then i think there is nohardware
compatibility issue with linux. I think this is lack of usb support because
may be Linux has no support until now for latest motherboards or hardware
architects.

These are the errors i got with different distros. i am not able to figure
out what's going on bcz i'm rookie in Linux programming. But if anyone can
do it, plz help me i haven't run my linux from previous 1 and half month and
i'm a linux addicted.
starting from Fedora 15 gnome(almost same for kde except starting numbers)

error:-
[   2.571729] [drm:intel_drm_platform_mux_info] *ERROR* MUX INFO CALL FAILED
[   2.571847] [drm:intel_drm_platform_mux_info] *ERROR* MUX INFO CALL FAILED

Dropping to debug shell.
sh.can't acess tty:job control off
dracut:/#


Fedora 15 LXDE

[   2.514402] nonveau :01:00.0:invalid ROM contents
[   2.614971] [drm] nonveau :01:00.0:POINTER to BIT load vol table
invalid
[   2.639331] [drm] nonveau :01:00.0:0xd518:12cwr fail: -6
[   2.75332] [drm] nonveau :01:00.0:PGRAPH:unsupported chipset,please
report!
[   2.753646] [drm] nonveau :01:00.0:PGRAPH:unknown config:2/0/0/0,1
[   2.755342] [drm] nonveau :01:00.0: failed to load fuc 409 d


[   2.919340] [drm:intel_drm_platform_mux_info] *ERROR* MUX INFO CALL FAILED
[   2.919447] [drm:intel_drm_platform_mux_info] *ERROR* MUX INFO CALL FAILED

Dropping to debug shell.
sh.can't acess tty:job control off
dracut:/#


Fedora 15 XCFE

[   2.563563] [drm:intel_drm_platform_mux_info] *ERROR* MUX INFO CALL FAILED
[   2.563680] [drm:intel_drm_platform_mux_info] *ERROR* MUX INFO CALL FAILED

Dropping to debug shell.
sh.can't acess tty:job control off
dracut:/#


EDUBOSS (Debian derivative) (I apologize but i have write the full error i
got bcz may be it helps somebody to find what's going on)

BOOT FAILED !
The debian live image failed to boot. Please file a bug against the
'live-initramfs' package or email the debian Live mailing list at <
debian-l...@lists.debian.org> make sure to note the exact version, name and
distribution of the image you were attempt to boot.

The file /live.log contains same debugging information but booting with
debug command line parameter will greatly increase it's verbosity which is
extremely useful when diagnosing issues.

live-initramfs will start a shell.
The error message was: Unable to find a medium containing a live file
system.

Busy Box v.1.10.2 (Debian 1:1.10.2-2) built in shell (ash)

Enter 'help' for a list of built in commands.

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: How to target bugs and features to future Ubuntu releases

[Robbie Williamson]

One word to describe my feelings on thisHallelujah! 

On Thu, 2010-12-09 at 12:15 -0600, Kate Stewart wrote:
> For those of you who target bugs and features to releases, you may have
> noticed that there is now an o-series and p-series available. This means
> that it is now possible to target bugs and features to future Ubuntu
> releases, something we couldn't easily do before.  Many thanks to the
> launchpad team for making this available, to help with our release
> management!!! :)
> 
> The purpose of these future release planning buckets is so we can track
> bugs and features.  If we figure out we're not going to be able to get
> some bugs fixed or some features implemented in natty, but don't want to
> lose track of them and we can now indicate when they should get worked
> on.  Please note that code can not be uploaded to the future releases
> though, until they become active.
> 
> The use of the milestone "later" was used historically by some to
> indicate a bug or feature should be looked at in the future,  but it
> lacked release-level granularity, and was inconsistently applied.   The
> introduction of release+1 (o-series) and release+2 (p-series), will
> provide more granularity, and help us track things a bit better.  
>  
> When Natty is released, o-series will become the active release (with
> the appropriate keyword ;)), and code/fixes can start being assigned to
> it then.  When o-series becomes active development release, a q-series
> planning bucket will be introduced.  Going forward we'll be looking to
> keep a release+1 and release+2 available on a rolling basis.
> 
> If you have any questions, please let me know.  I'll be starting to work
> through the WIKI pages to update them to document this, so if you find a
> reference that looks like it needs updating, feel free to point it
> out.  :)
> 
> Thanks, Kate
> 
> 


-- 
Robbie Williamson rob...@ubuntu.com
Ubuntu robbiew[irc.freenode.net]
   

"You can't be lucky all the time, but you can be smart everyday" 
 -Mos Def

"Arrogance is thinking you are better than everyone else, while
Confidence is knowing no one else is better than you." -Me ;)


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Bugs needed to improve in ubuntu

[aakash pandey]

>. panel bug that if panel is by mistake force quit all panels will dissapear 
>till next boot
>. Buttons but somtimes they get removed
>. need of a black color theme with high graphics like mac os x 10.6.3
>. mouse bug u cannot change cursor

-- 
@@k...@$h

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: compiz 0.8.4-0ubuntu2.1 alleged bugs report

[Bruno Girin]

On Wed, 2010-06-02 at 17:50 +0200, Emmanuel Michon wrote:
> Hello,
> 
> I'd like to report few bugs I believe are due to the compiz component on
> a fresh ubuntu amd64
> 
> If this mail should not be sent here, please direct me to the proper
> location.

Hi Emmanuel,

Thanks for your interest in reporting issues with Compiz. Can you file
the bugs in Launchpad under the compiz package please? You can do that
easily from the command line by typing:

ubuntu-bug compiz

Note that you will have to register in Launchpad when you file the bugs.
This is so that bug triagers can contact you if they need more
information.

Bruno



-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

compiz 0.8.4-0ubuntu2.1 alleged bugs report

[Emmanuel Michon]

Hello,

I'd like to report few bugs I believe are due to the compiz component on
a fresh ubuntu amd64

If this mail should not be sent here, please direct me to the proper
location.

***

summary: recent upgrade has it wrong when resizing windows, running
`Window management scale', Ring switcher, about what `fullscreen' is
when using multi-display desktop

***

$ aptitude show compiz
Package: compiz
State: installed
Automatically installed: no
Version: 1:0.8.4-0ubuntu2.1
Priority: optional
Section: x11
Maintainer: Ubuntu Core Developers 
Uncompressed Size: 77.8k
Depends: compiz-core (>= 1:0.8.3), compiz-plugins, compiz-gnome |
compiz-kde,
 compiz-fusion-plugins-main (>= 0.8.3),
compiz-fusion-plugins-extra (>= 0.8.3),
 libcompizconfig0 (>= 0.8.3)

***

My graphic setup is gory but trendy

ati radeon 4850 hd x2 proprietary driver driving 2 IBM T221 displays
with 4 DVI out @1920x2400x34Hz, custom modelines.

|1-2| |3-4|
:0.0  :0.1

1-2 form a `multi-display desktop' (and 3-4 another one)
you can't drag windows between 1-2 and 3-4 but ok
within 1-2 (excepted tearing but that's unsync hardware).

kernel 2.6.31-21-generic
ati-driver-installer-10-4-x86.x86_64.run

Bugs are

***

(misbehavior of what is meant as `full screen')

- Gnome desktop bar (the Bar with Applications/Places/System ...
poweroff tray at top) reaches the topleft of 1, but stops middle of
physical screen (topright of 1) where I would like it to go topright of
2. This bug was here in previous releases.

But those have newly appeared with latest dist-upgrade:

- resizing a window with topleft in 1 shows a `wanted watermark' that
can't cross middle of desktop.

- `fullscreen' button actually makes window stitch either 1 or 2 not
encompass 1-2.

- `ring switcher' or WindowManagement `scale' will interestingly, grab
all the windows from 1 and 2 spaces, and do the animation limited to 1
or 2, not in 1-2, depending on the last active window

***

(minor) Not sure how to set a different background for each desktop.

***

(minor) resizing is awfully slow maybe 2.5sec. Ok there is lot of RAM
involved.

***

(rain effect) will freeze the hardware.

***

Informatively, I also enabled one extra virtual desktop for each
physical desktop that is properly supported by Cube and co but I rarely
use it.

***

Thanks for any clue,

Sincerely yours,

e.m.


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

logging bugs for pre-release versions

[Patrick Goetz]

Having abandoned Karmic, I've been installing Lucid Alpha 3 on a number 
of different systems, mostly for testing, and am finding lots of bugs. 
For example, on an old Acer Aspire 3000 laptop, after a completely 
generic Alpha 3 install + or - up to March 8 daily updates:

1. The console driver is broken: vt1-vt6 only display 13.5 characters 
(yes, I meant 13 and one half characters).
2. X works fine, but will sometimes come up on vt7, other times on vt8 
-- I haven't been able to determine a pattern.
3. There is a timing problem with logging in on the gdm console:  the 
first attempt to login always fails, the second always succeeds -- 
unless I wait 4-5 minutes before attempting to log in, in which case the 
first login attempt succeeds (usually).

For mission critical issues I will take the time to carefully file a bug 
report on launchpad, but for stuff like this I just don't have time. For 
example, I have no idea what package to associate the console graphics 
problem with and don't really have time to find out.  What I want to be 
able to do is have some place to state the build I'm installing, 
describe the hardware I'm installing it on (e.g. this system has an SIS 
M760GX graphics chip and an AMD Sempron processor), and then list the 
problems I'm having and done, back to work.  The someone more 
knowledgeable than me can parse and triage the issues to the right 
package maintainers.  ubuntu-bug doesn't work this way AFAIK (no idea 
how I'd use it with the problems described above), and apport isn't 
doing it for me.  After one login (I've been turning the machine on and 
off a lot trying to narrow down the specific list of problems), a dialog 
box popped up announcing that some serious kernel panic had occurred, 
that the system was now unstable, and would I like to report a bug to 
"help the developers"?  Sure, why not.  Apport then proceeded to ask me 
a series of questions not even Linus could answer:  e.g., "is this bug 
similar to any of these bugs?"  How would I know?  The only information 
I have is a dialog box telling me the kernel panicked -- I don't have 
any information.  I've been using linux for 15 years; now imagine 
throwing these dialogs at some neophyte.  This is bound to do more harm 
than good, since the experience is surreal, to say the least.

Assuming no one is available to parse these multi-bug reports, I could 
probably write a perl script in a couple of days that would search 
through them looking for keywords and then alert specific package 
maintainers based on topics they've registered to trigger an alert.  SJ 
Remnant could write an event driven version in an hour.  It seems to me 
that for pre-release code, where users/testers are likely to find 
multiple problems, it should be made as easy as possible to report these 
problems.

Also, please don't suggest the ubuntu+1 IRC, this is beyond completely 
useless.

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Triaging Bugs with Patches

[Emmet Hikory]

Brian Murray wrote:
>> To my mind, once a bug has an attached patch which the triager can verify as
>> at least being potentially useful, there should be a simple button "flag as
>> patched".
>> This flag should ping the maintainer with something like: "Project X has a
>> ticket with a patch!".
>> The maintainer (or another dev) should then check the patch, commit it, and
>> close the bug.
>
> The bugs with patches are already flagged this way in bug listings, the
> dual band-aid icon, additionally e-mail notifications now indicate when
> attachments flagged as patches are added to bug reports.
>
> The sponsorship queue is a way to collate bug reports with patches
> across packages which is something that isn't easy to do in Launchpad.
> You can either view all the bugs with patches (quite a lot at the
> moment) or only one package's bugs with patches.

The sponsorship queue isn't really intended to be a catch-all
bucket for all bugs with patches, but rather a way that those who
cannot (yet) upload to Ubuntu may present candidate packages for
review and upload.  The candidate is presented as a debdiff or diff.gz
to save bandwidth and storage requirements.  It is not uncommon that a
sponsor will unsubscribe the sponsorship queue while the patch is
being reviewed or corrected, and pushing such bugs back in queue only
complicates the sponsor assignment process.

I believe there is an Ubuntu Reviewers team, which is potentially
better used for this, but I'm not that familiar with the workflow of
that team, so it is worth checking with them first to find out whether
they have a good place to track bugs with patches.  I've generally
used custom searches in launchpad to discover them, but agree that
these URLs can be complicated to construct (and don't have links,
except by using the Advanced Search form).

-- 
Emmet HIKORY

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Triaging Bugs with Patches

[Evan]

On Thu, Feb 18, 2010 at 5:59 PM, Brian Murray  wrote:

> On Wed, Feb 17, 2010 at 10:42:34PM -0500, Evan wrote:
> > I've been triaging a few bugs, and I came across a pair of bugs in
> libpcap
> > which had patches [1][2].
> > I found and checked the wiki page on triaging bugs with patches [3], and
> > after completing the available steps, I ran into a wall.
> >
> > The complete text of the section describing what to do with a bug that
> has a
> > patch reads as follows:
> >
> > > In the event that [the patch] is not a debdiff one could incorporate
> the
> > > patch into a debdiff for the latest release of Ubuntu or apply the
> patch to
> > > a bzr branch of the package and link the branch to the bug report.
> > > If an attachment is a debdiff and applies to a recent version of the
> > > package the bug report needs to be sponsored<
> https://wiki.ubuntu.com/SponsorshipProcess>to the appropriate archive.
> This is done by subscribing (NOT assigning) the
> > > appropriate sponsorship team to the bug. For packages in main and
> restricted
> > > the ubuntu-main-sponsors team should be subscribed. For packages in the
> > > universe and multiverse repositories the ubuntu-universe-sponsors team
> > > should be subscribed. You can view their queues at main-sponsors<
> https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-main-sponsors
> >and
> > > universe-sponsors<
> https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-universe-sponsors
> >
> > > .
> > >
> >
> > 1) The two attached patches are simple diffs, not debdiffs - is there a
> way
> > to convert them, and could it be added to this page?
>
> This isn't exactly trivial as you would need to incorporate the patch in
> the package's patch system (if it has one) and update the changelog
> among other things. Some documentation that might help in this process,
> if you are interested, can be found at
> https://wiki.ubuntu.com/PackagingGuide/Complete.
>

I've added a link to the patch-related portion of that page to the wiki.


>  > 2) As a triager, how is one expected to be able to apply a patch to a
> bzr
> > branch, and what if the project isn't hosted on launchpad/bzr? This seems
> > more dev-related then triager-related.
>
> Most packages are available in bzr on launchpad so you could use bzr
> branch lp:ubuntu/libpcap.  Unfortunately, this isn't the case for
> libpcap though.  There is also a plugin so one can use bzr patch and the
> link to the patch on launchpadlibrarian.
>

I'm a little confused on this point - is it Ubuntu's goal to host all
package's sources locally on bzr,
even ones which have their own upstream versioning system? While I
appreciate the integration,
it seems a bit redundant.


> > 3) Is there a way to tell from a bug page which repository the package is
> > in? I eventually found it on the launchpad libpcap package page, but I
> > couldn't find any obvious indicator on the bug page itself. This should
> > probably be mentioned as well.
>
> When you mouse-over the package name in the bug task table you are
> presented with information about the latest package version and the
> repository it is from.  I'll update the wiki page appropriately.
>
> > To my mind, once a bug has an attached patch which the triager can verify
> as
> > at least being potentially useful, there should be a simple button "flag
> as
> > patched".
> > This flag should ping the maintainer with something like: "Project X has
> a
> > ticket with a patch!".
> > The maintainer (or another dev) should then check the patch, commit it,
> and
> > close the bug.
>
> The bugs with patches are already flagged this way in bug listings, the
> dual band-aid icon, additionally e-mail notifications now indicate when
> attachments flagged as patches are added to bug reports.
>

I've updated the wiki to mention the band-aid icon, and removed the
reference to the
out-dated greasemonkey script (it seems launchpad does this itself now?)

The sponsorship queue is a way to collate bug reports with patches
> across packages which is something that isn't easy to do in Launchpad.
> You can either view all the bugs with patches (quite a lot at the
> moment) or only one package's bugs with patches.
>
> > I'm not a workflow expert, so there may be reasons for the way the system
> is
> > currently set up, but it doesn't make sense to me.
>
> I agree that the current workflow isn't ideal but hope that I've helped
> clarify some of the process for you.
>

You have. Thank you very much!

Evan
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Triaging Bugs with Patches

[Brian Murray]

On Wed, Feb 17, 2010 at 10:42:34PM -0500, Evan wrote:
> I've been triaging a few bugs, and I came across a pair of bugs in libpcap
> which had patches [1][2].
> I found and checked the wiki page on triaging bugs with patches [3], and
> after completing the available steps, I ran into a wall.
> 
> The complete text of the section describing what to do with a bug that has a
> patch reads as follows:
> 
> > In the event that [the patch] is not a debdiff one could incorporate the
> > patch into a debdiff for the latest release of Ubuntu or apply the patch to
> > a bzr branch of the package and link the branch to the bug report.
> > If an attachment is a debdiff and applies to a recent version of the
> > package the bug report needs to be 
> > sponsored<https://wiki.ubuntu.com/SponsorshipProcess>to the appropriate 
> > archive. This is done by subscribing (NOT assigning) the
> > appropriate sponsorship team to the bug. For packages in main and restricted
> > the ubuntu-main-sponsors team should be subscribed. For packages in the
> > universe and multiverse repositories the ubuntu-universe-sponsors team
> > should be subscribed. You can view their queues at 
> > main-sponsors<https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-main-sponsors>and
> > universe-sponsors<https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-universe-sponsors>
> > .
> >
> 
> 1) The two attached patches are simple diffs, not debdiffs - is there a way
> to convert them, and could it be added to this page?

This isn't exactly trivial as you would need to incorporate the patch in
the package's patch system (if it has one) and update the changelog
among other things. Some documentation that might help in this process,
if you are interested, can be found at
https://wiki.ubuntu.com/PackagingGuide/Complete.

> 2) As a triager, how is one expected to be able to apply a patch to a bzr
> branch, and what if the project isn't hosted on launchpad/bzr? This seems
> more dev-related then triager-related.

Most packages are available in bzr on launchpad so you could use bzr
branch lp:ubuntu/libpcap.  Unfortunately, this isn't the case for
libpcap though.  There is also a plugin so one can use bzr patch and the
link to the patch on launchpadlibrarian.

> 3) Is there a way to tell from a bug page which repository the package is
> in? I eventually found it on the launchpad libpcap package page, but I
> couldn't find any obvious indicator on the bug page itself. This should
> probably be mentioned as well.

When you mouse-over the package name in the bug task table you are
presented with information about the latest package version and the
repository it is from.  I'll update the wiki page appropriately.
 
> To my mind, once a bug has an attached patch which the triager can verify as
> at least being potentially useful, there should be a simple button "flag as
> patched".
> This flag should ping the maintainer with something like: "Project X has a
> ticket with a patch!".
> The maintainer (or another dev) should then check the patch, commit it, and
> close the bug.

The bugs with patches are already flagged this way in bug listings, the
dual band-aid icon, additionally e-mail notifications now indicate when
attachments flagged as patches are added to bug reports.

The sponsorship queue is a way to collate bug reports with patches
across packages which is something that isn't easy to do in Launchpad.
You can either view all the bugs with patches (quite a lot at the
moment) or only one package's bugs with patches.
 
> I'm not a workflow expert, so there may be reasons for the way the system is
> currently set up, but it doesn't make sense to me.

I agree that the current workflow isn't ideal but hope that I've helped
clarify some of the process for you.

> If the general consensus is that my points on the wiki are valid, I'll take
> a shot at rewriting that section.

I'll be taking a look at the wiki page also.
 
-- 
Brian Murray @ubuntu.com


signature.asc
Description: Digital signature
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Triaging Bugs with Patches

[Evan]

I've been triaging a few bugs, and I came across a pair of bugs in libpcap
which had patches [1][2].
I found and checked the wiki page on triaging bugs with patches [3], and
after completing the available steps, I ran into a wall.

The complete text of the section describing what to do with a bug that has a
patch reads as follows:

> In the event that [the patch] is not a debdiff one could incorporate the
> patch into a debdiff for the latest release of Ubuntu or apply the patch to
> a bzr branch of the package and link the branch to the bug report.
> If an attachment is a debdiff and applies to a recent version of the
> package the bug report needs to be 
> sponsored<https://wiki.ubuntu.com/SponsorshipProcess>to the appropriate 
> archive. This is done by subscribing (NOT assigning) the
> appropriate sponsorship team to the bug. For packages in main and restricted
> the ubuntu-main-sponsors team should be subscribed. For packages in the
> universe and multiverse repositories the ubuntu-universe-sponsors team
> should be subscribed. You can view their queues at 
> main-sponsors<https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-main-sponsors>and
> universe-sponsors<https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-universe-sponsors>
> .
>

1) The two attached patches are simple diffs, not debdiffs - is there a way
to convert them, and could it be added to this page?
2) As a triager, how is one expected to be able to apply a patch to a bzr
branch, and what if the project isn't hosted on launchpad/bzr? This seems
more dev-related then triager-related.
3) Is there a way to tell from a bug page which repository the package is
in? I eventually found it on the launchpad libpcap package page, but I
couldn't find any obvious indicator on the bug page itself. This should
probably be mentioned as well.

To my mind, once a bug has an attached patch which the triager can verify as
at least being potentially useful, there should be a simple button "flag as
patched".
This flag should ping the maintainer with something like: "Project X has a
ticket with a patch!".
The maintainer (or another dev) should then check the patch, commit it, and
close the bug.

I'm not a workflow expert, so there may be reasons for the way the system is
currently set up, but it doesn't make sense to me.
If the general consensus is that my points on the wiki are valid, I'll take
a shot at rewriting that section.

Thanks,
Evan

[1] https://bugs.launchpad.net/ubuntu/+source/libpcap/+bug/523340
[2] https://bugs.launchpad.net/ubuntu/+source/libpcap/+bug/523349
[3] https://wiki.ubuntu.com/Bugs/Patches
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

wvdial postinst script bugs

[Forest Bond]

Hi,

The wvdial postinst script runs wvdialconf which tries to detect modems and
write out /etc/wvdial.conf.  There have been several bugs reported where
wvdialconf hangs while probing serial ports and the wvdialconf process must be
killed, leaving the package unconfigured.

You may wish to scan the bug list briefly:

https://bugs.launchpad.net/ubuntu/+source/wvdial

I have just run into this issue and have reported bug #513787.  It is indeed a
bug if wvdialconf hangs when probing serial devices.

However, I wanted to bring this issue up here because I don't think it's
appropriate for a postinst script to probe serial devices without at least
asking the user first.

It's impossible to probe serial devices without possibly disrupting
communication for processes that are already making use of the device.
Depending upon what sort of device is connected to the port, probing may cause a
network connection to fail, introduce data corruption on a connection, or a
variety of potentially worse problems, depending on what sort of device is on
the other end (consider what might happen if someone tries to install wvdial on
a machine that is using the serial ports to control some mechanical device).

wvdial does use debconf to decide if it should automatically detect modems, but
this setting is given priority "low" and defaults to "yes", so most users are
never asked.  I think the priority should be higher, and I think the default
should be "no" to avoid problems with noninteractive installation.

Thoughts?

Thanks,
Forest
-- 
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org


signature.asc
Description: Digital signature
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: making a workaround web page for bugs, in LTS release, not fixed

[Marco Pallotta]

Il giorno dom, 10/01/2010 alle 13.21 -0800, Ryein ha scritto: 
> I like that idea.  Integrate bug tracking and solutions together and
> into the OS.  If you need more developers I am sure this would spring
> board into that if a good system existed for that.  A simple tag
> system could easily link closely related topics together as well as
> solution validity.  Solutions with the highest success rate posted by
> users would be shown first. 

I think the problem is just how to find a valid system in order to
choose the right workaround. 
I think a solution could be proposing, by the user that takes part in
the bug discussion, a workaround that has to be confirmed in order to be
posted in the "workaround for bugs" web page. This is good if we want to
provide a service with careful info (for example this could be mandatory
if web page is a sort of "official" web page maintained by Canonical). 
So, to start working at the projects, we can think to restrict the
workarounds to those that have been confirmed by someone different to
the proposer and are related to confirmed bugs. 

> I'm a programmer myself.  Let me know if
> you need any help with this.  Either web side or on the desktop.
> 
> On Sun, Jan 10, 2010 at 6:12 AM, Marco Pallotta
>  wrote:
> > Il giorno ven, 08/01/2010 alle 11.58 -0600, C de-Avillez ha scritto:
> >> On 01/08/10 00:58, Marco Pallotta wrote:
> >> > 2010/1/7 Charlie Kravetz :
> >> >
> >> >>
> >> >> Ubuntu bugsquad already has a policy that workarounds should be
> >> >> identified and moved into the bug description. If that was happening,
> >> >> it should be easy to grab the section labeled "WORKAROUND:", right?
> >> >>
> >> >
> >> > Well,
> >> >
> >> > I saw not many of these labeled bugs. I think we whould start a
> >> > different process to identify a workaround solution for an issue that
> >> > will not be fixed.
> >> >
> >>
> >> Yes, they are used far less than ideal. Still, they should be used (and
> >> when I find a bug that is missing a workaround in the description, I add
> >> it in).
> >>
> >> But still, we could have a workarounds page in the Wiki (perhaps either
> >> *or*, or *also*, in answers.lp). There we could put the most important
> >> issues, and their workarounds. But not all, I think. There are some very
> >> technical issues that -- if you are hit with it, you most probably also
> >> know where to look for an asnwer.
> >
> > Well, also if there are technical issues I would expexct to find a
> > workaround in the "workaround for bugs" web page also for them if this
> > can help to save time to find a solution for an issue (also if the user
> > is not a newbieat the endtime is time for everyone). However we
> > could also link the workaround with the specific bug from which it come
> > from so that any user (if he wanted to do it) can delve into the
> > question.
> >
> >
> >> It is unrealistic to expect all Ubuntu users to browse lp.net/ubuntu/bugs.
> >>
> >
> > I think the problem may be related to how link this workaround web page
> > into the desktop. If, for example, the user knows that, for any issue
> > found in any app, he has to simply click on a icon, to find a possibile
> > solution to it, he will do it instead of spend time to surfing into the
> > web for looking for a solution.
> >
> >
> > --
> > ==
> > MARCO PALLOTTA
> >
> > e-mail: marco.pallo...@gmail.com
> >
> > CHAT:
> > msn #: pallo...@inwind.it
> > googletalk #: marco.pallo...@gmail.com
> > skype #: marco.pallotta
> >
> > Public GPG key: hkp://keyserver.ubuntu.com:11371
> > ==
> >
> >
> > --
> > Ubuntu-devel-discuss mailing list
> > Ubuntu-devel-discuss@lists.ubuntu.com
> > Modify settings or unsubscribe at: 
> > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
> >
-- 
==
MARCO PALLOTTA
 
e-mail: marco.pallo...@gmail.com

CHAT:
msn #: pallo...@inwind.it
googletalk #: marco.pallo...@gmail.com
skype #: marco.pallotta
 
Public GPG key: hkp://keyserver.ubuntu.com:11371
==


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: making a workaround web page for bugs, in LTS release, not fixed

[Marco Pallotta]

Il giorno ven, 08/01/2010 alle 11.58 -0600, C de-Avillez ha scritto:
> On 01/08/10 00:58, Marco Pallotta wrote:
> > 2010/1/7 Charlie Kravetz :
> >   
> >>
> >> Ubuntu bugsquad already has a policy that workarounds should be
> >> identified and moved into the bug description. If that was happening,
> >> it should be easy to grab the section labeled "WORKAROUND:", right?
> >> 
> >
> > Well,
> >
> > I saw not many of these labeled bugs. I think we whould start a
> > different process to identify a workaround solution for an issue that
> > will not be fixed.
> >   
> 
> Yes, they are used far less than ideal. Still, they should be used (and
> when I find a bug that is missing a workaround in the description, I add
> it in).
> 
> But still, we could have a workarounds page in the Wiki (perhaps either
> *or*, or *also*, in answers.lp). There we could put the most important
> issues, and their workarounds. But not all, I think. There are some very
> technical issues that -- if you are hit with it, you most probably also
> know where to look for an asnwer.

Well, also if there are technical issues I would expexct to find a
workaround in the "workaround for bugs" web page also for them if this
can help to save time to find a solution for an issue (also if the user
is not a newbieat the endtime is time for everyone). However we
could also link the workaround with the specific bug from which it come
from so that any user (if he wanted to do it) can delve into the
question.


> It is unrealistic to expect all Ubuntu users to browse lp.net/ubuntu/bugs.
> 

I think the problem may be related to how link this workaround web page
into the desktop. If, for example, the user knows that, for any issue
found in any app, he has to simply click on a icon, to find a possibile
solution to it, he will do it instead of spend time to surfing into the
web for looking for a solution. 


-- 
==
MARCO PALLOTTA
 
e-mail: marco.pallo...@gmail.com

CHAT:
msn #: pallo...@inwind.it
googletalk #: marco.pallo...@gmail.com
skype #: marco.pallotta
 
Public GPG key: hkp://keyserver.ubuntu.com:11371
==


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: making a workaround web page for bugs, in LTS release, not fixed

[C de-Avillez]

On 01/08/10 00:58, Marco Pallotta wrote:
> 2010/1/7 Charlie Kravetz :
>   
>>
>> Ubuntu bugsquad already has a policy that workarounds should be
>> identified and moved into the bug description. If that was happening,
>> it should be easy to grab the section labeled "WORKAROUND:", right?
>> 
>
> Well,
>
> I saw not many of these labeled bugs. I think we whould start a
> different process to identify a workaround solution for an issue that
> will not be fixed.
>   

Yes, they are used far less than ideal. Still, they should be used (and
when I find a bug that is missing a workaround in the description, I add
it in).

But still, we could have a workarounds page in the Wiki (perhaps either
*or*, or *also*, in answers.lp). There we could put the most important
issues, and their workarounds. But not all, I think. There are some very
technical issues that -- if you are hit with it, you most probably also
know where to look for an asnwer.

It is unrealistic to expect all Ubuntu users to browse lp.net/ubuntu/bugs.



signature.asc
Description: OpenPGP digital signature
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: making a workaround web page for bugs, in LTS release, not fixed

[Marco Pallotta]

2010/1/7 Charlie Kravetz :
> On Thu, 7 Jan 2010 15:51:07 -0500
> John Moser  wrote:
>
>> On Thu, Jan 7, 2010 at 6:53 AM, Marco Pallotta  
>> wrote:
>> > Often Ubuntu users (expecially new users or user that doesn't know
>> > much of Ubuntu bug fixing procedure) are disoriented by the fact that
>> > bugs, in LTS releases, aren't fixed (or they are marked as "fix
>> > released" if they aren't present anymore in next Ubuntu releases)  if
>>
>> I'm still surprised that supposedly supported versions don't have bug fixes.
>>
>> You get these kinds of reports:
>>
>>  - 7.10 is a great release
>>  - 8.04 is the worst crap I've ever seen, everything is broken
>>  - 8.10 is an amazing release, with all the broken crap in 8.04 fixed
>>
>> And you get a point in time where this becomes true:
>>
>>  - 7.10 has mostly working software.
>>  - 8.04 has about half its software still broken
>>  - 8.10 has all those bugs from 8.04 AND 7.10 fixed, and all its software 
>> works
>>  - To get any of 2 or 3 dozen apps in 8.04 to work, you should upgrade to 
>> 8.10
>>  - To get any of 1 or 2 apps in 7.10 to work, upgrade to 8.10
>>
>> Ubuntu has had at least one release that was hailed as the biggest
>> mistake in history, where the entire system seemed duct taped together
>> and very basic functionality was largely broken.  Python errors got
>> spit out by things like Serpentine.  Some apps crashed.  The MP3
>> encoder crashed immediately if you fed it output from oggdec (gtkpod
>> thus didn't function).  The kernel wasn't even stable on some systems,
>> due to a scheduler bug or something non-trivial along those lines.  I
>> think that was 8.10?
>>
>> When I finally upgraded, everything was still broken in the old
>> version, and everything was working in the new version.  Last I
>> looked, everything was still broken in that version.
>>
>> My question is:  do such versions of Ubuntu remain broken and
>> dysfunctional until they're no longer supported?  Is this proper?  Or
>> should fixes get backported to all supported releases AND LTS such
>> that the oldest version always has the fewest problems, but also fewer
>> features?
>>
>
> Ubuntu bugsquad already has a policy that workarounds should be
> identified and moved into the bug description. If that was happening,
> it should be easy to grab the section labeled "WORKAROUND:", right?


Well,

I saw not many of these labeled bugs. I think we whould start a
different process to identify a workaround solution for an issue that
will not be fixed.


>
> --
> Charlie Kravetz
> Linux Registered User Number 425914          [http://counter.li.org/]
> Never let anyone steal your DREAM.           [http://keepingdreams.com]
>
> --
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
>



-- 

==
Marco Pallotta

EMail: marco.pallo...@gmail.com

CHAT:
msn # pallo...@inwind.it
googletalk # marco.pallo...@gmail.com
skype # marco.pallotta
==

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: making a workaround web page for bugs, in LTS release, not fixed

[Charlie Kravetz]

On Thu, 7 Jan 2010 15:51:07 -0500
John Moser  wrote:

> On Thu, Jan 7, 2010 at 6:53 AM, Marco Pallotta  
> wrote:
> > Often Ubuntu users (expecially new users or user that doesn't know
> > much of Ubuntu bug fixing procedure) are disoriented by the fact that
> > bugs, in LTS releases, aren't fixed (or they are marked as "fix
> > released" if they aren't present anymore in next Ubuntu releases)  if
> 
> I'm still surprised that supposedly supported versions don't have bug fixes.
> 
> You get these kinds of reports:
> 
>  - 7.10 is a great release
>  - 8.04 is the worst crap I've ever seen, everything is broken
>  - 8.10 is an amazing release, with all the broken crap in 8.04 fixed
> 
> And you get a point in time where this becomes true:
> 
>  - 7.10 has mostly working software.
>  - 8.04 has about half its software still broken
>  - 8.10 has all those bugs from 8.04 AND 7.10 fixed, and all its software 
> works
>  - To get any of 2 or 3 dozen apps in 8.04 to work, you should upgrade to 8.10
>  - To get any of 1 or 2 apps in 7.10 to work, upgrade to 8.10
> 
> Ubuntu has had at least one release that was hailed as the biggest
> mistake in history, where the entire system seemed duct taped together
> and very basic functionality was largely broken.  Python errors got
> spit out by things like Serpentine.  Some apps crashed.  The MP3
> encoder crashed immediately if you fed it output from oggdec (gtkpod
> thus didn't function).  The kernel wasn't even stable on some systems,
> due to a scheduler bug or something non-trivial along those lines.  I
> think that was 8.10?
> 
> When I finally upgraded, everything was still broken in the old
> version, and everything was working in the new version.  Last I
> looked, everything was still broken in that version.
> 
> My question is:  do such versions of Ubuntu remain broken and
> dysfunctional until they're no longer supported?  Is this proper?  Or
> should fixes get backported to all supported releases AND LTS such
> that the oldest version always has the fewest problems, but also fewer
> features?
> 

Ubuntu bugsquad already has a policy that workarounds should be
identified and moved into the bug description. If that was happening,
it should be easy to grab the section labeled "WORKAROUND:", right?

-- 
Charlie Kravetz 
Linux Registered User Number 425914  [http://counter.li.org/]
Never let anyone steal your DREAM.   [http://keepingdreams.com]

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: making a workaround web page for bugs, in LTS release, not fixed

[Evan]

On Thu, Jan 7, 2010 at 3:51 PM, John Moser  wrote:

> On Thu, Jan 7, 2010 at 6:53 AM, Marco Pallotta 
> wrote:
> > Often Ubuntu users (expecially new users or user that doesn't know
> > much of Ubuntu bug fixing procedure) are disoriented by the fact that
> > bugs, in LTS releases, aren't fixed (or they are marked as "fix
> > released" if they aren't present anymore in next Ubuntu releases)  if
>
> I'm still surprised that supposedly supported versions don't have bug
> fixes.
>
> You get these kinds of reports:
>
>  - 7.10 is a great release
>  - 8.04 is the worst crap I've ever seen, everything is broken
>  - 8.10 is an amazing release, with all the broken crap in 8.04 fixed
>
> And you get a point in time where this becomes true:
>
>  - 7.10 has mostly working software.
>  - 8.04 has about half its software still broken
>  - 8.10 has all those bugs from 8.04 AND 7.10 fixed, and all its software
> works
>  - To get any of 2 or 3 dozen apps in 8.04 to work, you should upgrade to
> 8.10
>  - To get any of 1 or 2 apps in 7.10 to work, upgrade to 8.10
>
> Ubuntu has had at least one release that was hailed as the biggest
> mistake in history, where the entire system seemed duct taped together
> and very basic functionality was largely broken.  Python errors got
> spit out by things like Serpentine.  Some apps crashed.  The MP3
> encoder crashed immediately if you fed it output from oggdec (gtkpod
> thus didn't function).  The kernel wasn't even stable on some systems,
> due to a scheduler bug or something non-trivial along those lines.  I
> think that was 8.10?
>
> When I finally upgraded, everything was still broken in the old
> version, and everything was working in the new version.  Last I
> looked, everything was still broken in that version.
>
> My question is:  do such versions of Ubuntu remain broken and
> dysfunctional until they're no longer supported?  Is this proper?  Or
> should fixes get backported to all supported releases AND LTS such
> that the oldest version always has the fewest problems, but also fewer
> features?
>

The way I understand it, they go for consistency. Often fixing one thing can
unintentionally break another, so large enterprises (which are technically
who Canonical is targeting) will prefer to leave one known bug unfixed,
rather than try fixing it only to find some other bug pop up which they then
have to workaround separately. I imagine most home users would rather have
the original bug fixed in the first place, but they're not the ones paying
Canonical for support contracts.

Just my two cents,
Evan
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: making a workaround web page for bugs, in LTS release, not fixed

[John Moser]

On Thu, Jan 7, 2010 at 6:53 AM, Marco Pallotta  wrote:
> Often Ubuntu users (expecially new users or user that doesn't know
> much of Ubuntu bug fixing procedure) are disoriented by the fact that
> bugs, in LTS releases, aren't fixed (or they are marked as "fix
> released" if they aren't present anymore in next Ubuntu releases)  if

I'm still surprised that supposedly supported versions don't have bug fixes.

You get these kinds of reports:

 - 7.10 is a great release
 - 8.04 is the worst crap I've ever seen, everything is broken
 - 8.10 is an amazing release, with all the broken crap in 8.04 fixed

And you get a point in time where this becomes true:

 - 7.10 has mostly working software.
 - 8.04 has about half its software still broken
 - 8.10 has all those bugs from 8.04 AND 7.10 fixed, and all its software works
 - To get any of 2 or 3 dozen apps in 8.04 to work, you should upgrade to 8.10
 - To get any of 1 or 2 apps in 7.10 to work, upgrade to 8.10

Ubuntu has had at least one release that was hailed as the biggest
mistake in history, where the entire system seemed duct taped together
and very basic functionality was largely broken.  Python errors got
spit out by things like Serpentine.  Some apps crashed.  The MP3
encoder crashed immediately if you fed it output from oggdec (gtkpod
thus didn't function).  The kernel wasn't even stable on some systems,
due to a scheduler bug or something non-trivial along those lines.  I
think that was 8.10?

When I finally upgraded, everything was still broken in the old
version, and everything was working in the new version.  Last I
looked, everything was still broken in that version.

My question is:  do such versions of Ubuntu remain broken and
dysfunctional until they're no longer supported?  Is this proper?  Or
should fixes get backported to all supported releases AND LTS such
that the oldest version always has the fewest problems, but also fewer
features?

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: making a workaround web page for bugs, in LTS release, not fixed

[Markus Hitter]

Am 07.01.2010 um 12:53 schrieb Marco Pallotta:

> we cannot ignore this user perception and I think we have to study  
> to try to fix it (also because LTS has seen as a sort of a very  
> stable release).

To use some of Mark's words: I agree with you wholeheartedly.


> So the bug triager [...] should have to select (just sending it to  
> a web page maintainer)  which workaround, [...]

Likely, this can be automated.  Put a checkmark "This is a  
workaround" to bug report postings and some daemon can collect those  
to display them on the help page (and making them more accessible to  
Google). At worst, a triager would have to cut&paste partial  
workarounds or descriptions hosted elsewhere into a single post, so  
the additional burden should be manageable.

Excellent idea, Marco.


Cheers,
Markus



-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

making a workaround web page for bugs, in LTS release, not fixed

[Marco Pallotta]

Often Ubuntu users (expecially new users or user that doesn't know
much of Ubuntu bug fixing procedure) are disoriented by the fact that
bugs, in LTS releases, aren't fixed (or they are marked as "fix
released" if they aren't present anymore in next Ubuntu releases)  if
they aren't security issues or bugs from which the user can lose data
(that should be regularly fixed). We know that Ubuntu developers
haven't the power to fix every discovered bug but following what
Shuttleworth sayd on his post "Ubuntu’s role in bug management for the
whole free software stack"(http://www.markshuttleworth.com/page/2) we
cannot ignore this user perception and I think we have to study to try
to fix it (also because LTS has seen as a sort of a very stable
release).

I think that a possible solution is to create a web page "workaround
for bugs", better if linked directly from one of gnome menu or
directly inside Ubuntu Help Center, that explains a possible
workaround for single LTS bug not fixed in that distro. In fact in
almost all the bug posts, in launchpad, we can find, except the info
if the bug is fixed in next release or not, a workaround for those
that, in the specific, haven't any idea to upgrade to a not LTS
release  continuously every six month. So the bug triager (but I think
only if bug is related to an LTS release, just to restrict the work)
should have to select (just
sending it to a web page maintainer)  which workaround, among the ones
that appear in the posts, have to be just posted, near bug
description, in the "workaround for bugs" web page. An alternative of
this (or a starting point of this idea) could be making a simple page,
on the wiki, supported by the community (and not, indirectly, by bug
triagers) but I think an integration in the Ubuntu Desktop (as I sayd
before, just with a simple link in the Ubuntu Help Center) could be
just the reply to the wrong user perception of LTS bug fixing.

Regards

-- 

==
Marco Pallotta

EMail: marco.pallo...@gmail.com

CHAT:
msn # pallo...@inwind.it
googletalk # marco.pallo...@gmail.com
skype # marco.pallotta
==

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Bugs expiry

[Brian Murray]

On Tue, Dec 15, 2009 at 12:58:35PM +, Przemek Kulczycki wrote:
> Hi.
> The expirable bugs page shows over 8500 bugs.
> https://bugs.edge.launchpad.net/ubuntu/+expirable-bugs
> The oldest one is over 300 days old.
> Are these bugs going to be closed automatically?

Not at this point in time.

> What are the settings for bugs expiring in Ubuntu?

Bug expiry is currently disabled for Ubuntu in Launchpad.  When it was
turned on a couple of years ago it ended up being problematic from a
technical standpoint and controversial probably due to the technical
problems from a community standpoint.

> Is the Launchpad Janitor still working or is it turned off?

It is currently turned off for Ubuntu however there was a brief
discussion of enabling it again for a very limited set of bug reports and
then depending on how that goes expanding the set of bugs covered.

-- 
Brian Murray @ubuntu.com


signature.asc
Description: Digital signature
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Bugs expiry

[Przemek Kulczycki]

Hi.
The expirable bugs page shows over 8500 bugs.
https://bugs.edge.launchpad.net/ubuntu/+expirable-bugs
The oldest one is over 300 days old.
Are these bugs going to be closed automatically?
What are the settings for bugs expiring in Ubuntu?
Is the Launchpad Janitor still working or is it turned off?
Regards,
-- 
## Przemysław Kulczycki >><< Azrael Nightwalker ##
# jabber: azrael[na]jabster.pl | tlen: azrael29a #
### www: http://reksio.ftj.agh.edu.pl/~azrael/ ###

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: This new "report bugs using ubuntu-bug" requirement is a mess!

[Alexander Sack]

On Sun, Oct 04, 2009 at 11:26:58PM -0500, Dustin Kirkland wrote:
> On Sun, Oct 4, 2009 at 1:55 PM, Chris Coulson  
> wrote:
> > It isn't completely enforced though. There is a link on the wiki page
> > that you are redirected to, which you can use to avoid the redirection
> > and submit a bug normally through the web interface.
> 
> Append this to the report-bug URL:
> 
>  ?no-redirect

The bit cumbersome part of this was that you got redirected to the wiki page so
you couldn't just append it to the current URL in your browser ...

 - Alexander


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: This new "report bugs using ubuntu-bug" requirement is a mess!

[Dustin Kirkland]

On Sun, Oct 4, 2009 at 1:55 PM, Chris Coulson  wrote:
> It isn't completely enforced though. There is a link on the wiki page
> that you are redirected to, which you can use to avoid the redirection
> and submit a bug normally through the web interface.

Append this to the report-bug URL:

 ?no-redirect

:-Dustin

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: This new "report bugs using ubuntu-bug" requirement is a mess!

[Chris Coulson]

On Sun, 2009-10-04 at 09:55 -0700, Dylan McCall wrote:
> Okay, here is a quick, true story :)
> 
> ***snip***
> Perhaps ubuntu-bug should just be strongly encouraged instead of
> completely enforced.
> 
> 
> 
> -- 
> Dylan McCall 
> 
> 

It isn't completely enforced though. There is a link on the wiki page
that you are redirected to, which you can use to avoid the redirection
and submit a bug normally through the web interface.

Incidentally, I'm not seeing the redirect anymore.

Regards
Chris


signature.asc
Description: This is a digitally signed message part
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

This new "report bugs using ubuntu-bug" requirement is a mess!

[Dylan McCall]

Okay, here is a quick, true story :)

I wanted to file a bug report on ubuntu-wallpapers, because it is
missing some images in its gnome-background-properties file. I had to
use ubuntu-bug to get to a bug filing form. After wasting time
collecting "problem information" - which is useless in this case - and
using valuable resources uploading it to Launchpad, I punched in the
summary to learn that this bug was already filed. Interestingly, since
we are now strongly discouraging users from using the awesome web
interface for Ubuntu related bugs, there's an extra, jarring step where
before I could do it all on one swoop. (Now, consider crashers with
ginormous dumps...).

Okay, next step!

I fixed it, made a deb package to test my fix, and then noticed another
bug to report. I used ubuntu-bug again, knowing that the issue exists
with Ubuntu's version of the package...

The problem cannot be reported:

This is not a genuine Ubuntu package

Now that really just annoyed me. So, I must remove my simple amendment
and reinstall the package simply to report a trivial bug!

Granted, it makes sense in some cases, but I have a feeling this new
method will seriously cripple the flow of minor bugs (eg: papercuts) by
making them too much of a pain to file.

Perhaps ubuntu-bug should just be strongly encouraged instead of
completely enforced.



-- 
Dylan McCall 


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Reporting usability problems: please be more tolerant when you triage bugs!

[Andrew Sayers]

Hi Vincenzo,

You might have more luck if you describe your changes as feature 
requests.  Whether or not you personally think they're bugs, calling 
them new features should avoid the "always been that way" reaction from 
developers.

You might also want to try helping out with the "improved me too" 
blueprint: https://blueprints.launchpad.net/malone/+spec/improved-me-too 
- useful "me too" data would let you argue that behaviour is non-obvious.

- Andrew

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Reporting usability problems: please be more tolerant when you triage bugs!

[Davyd McColl]

> Let me suggest that Ubuntu appoint an usability triager/ombudsman,
> to determine (from the Ubuntu users' perspective, not from an Ubuntu
> developers' perspective) how much attention ought to be paid to each
> and every usability-related bug report.

My 2c: I have to whole-heartedly agree. Probably the largest focus group of
the *buntu distros are the kinds of user who are intimidated enough at
posting some kind of bug / annoyance / usability issue, let alone having to
directly contact the grumpy developer(s) of the actual project (hey, I too
can be a grumpy dev; users can get a bit much). It would (imo) be a huge
boost for Ubuntu to provide a service (for lack of a better term) whereby
requests such as these are proxied to the relevant dev(s), even better with
some kind of relevance count (eg, how many people find this issue to be a
problem).

I know this is asking for even more from the free ride, but I think it would
be in the interests of the distros involved -- a lot of devs (myself
included) may overlook usability issues because the system seems intuitive
to them. Most devs that I know, however, if faced with a 99% frustration
rate from users, would change their product (if you're not in the FOSS dev
sphere to make good software for people other than yourself, then why
exactly are you here?).

Most users, on the other hand, either don't have the time, patience or 1337
5k1llz to (a) find the "correct" person to inform of the issue and (b)
convince him/her that it actually *is* an issue. The very fact that someone
had enough motivation to report something as difficult to use should be of
interest to the projects in question: it's more often the case that people
just can't be bothered.
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Reporting usability problems: please be more tolerant when you triage bugs!

[Vishal Rao]

+1, me too, etc...

See the comments in bug 294523 at
https://bugs.launchpad.net/hundredpapercuts/+bug/294523

A few users have tried to report/push/discuss for this for a few releases
already but it seems the bug is low priority even though its a usability
pain and that too right at the start of the ubuntu experience -
installation...
I'm sure even though only a few are reporting it there are many users who
silently suffer because they are simply not aware of the fact they can go
to launchpad and/or the forums and be heard.

I wish this bug would gain higher priority - maybe for the DX team?
Looking forward to a fast and painless out-of-box ubuntu installation
experience...

Cheers,
Visha
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Reporting usability problems: please be more tolerant when you triage bugs!

[Vincenzo Ciancia]

Il 22/07/2009 22:53, Mikus Grinbergs ha scritto:
> Let me suggest that Ubuntu appoint an usability triager/ombudsman,
> to determine (from the Ubuntu users' perspective, not from an Ubuntu
> developers' perspective) how much attention ought to be paid to each
> and every usability-related bug report.
>

Do we really have so few usability related report that a single man 
could do that? I hope not!

An usability tag, which alerts the developers, so that they don't 
default to istinctive reactions such as "it's always been like that" or 
perhaps even getting to newbie-handling techniques, would be sufficient 
but is there one already?

V.

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Reporting usability problems: please be more tolerant when you triage bugs!

[Mikus Grinbergs]

>> However, it is very easy that a developer does not recognise an
>> usability-related bug report, and confuses it with a more or less
>> strange support request, and I often have to discuss to have it
>> accepted as a bug.
> 
> The issue is that Ubuntu doesn't write most of the softwares it
> distribute and the current team doesn't have the manpower to work on
> those and isn't well placed to decide on behavior changes that should be
> done a software they are not writing. Ideally submitters would open
> those bugs upstream too and argue directly there.

I would like to speak up for the users out there - they too might 
have only limited resources and time.

The following happened to me on a platform different than Ubuntu, 
but has colored my attitude ever since:  A beta release failed to 
provide one significant multimedia function.  I reported it.  The 
report was rejected (with the notation that I should go upstream), 
on the grounds that I had used an application not supplied by the 
platform developers.  That mode of response upset me:

  *  *Every* multimedia application I had tried on that particular
 beta failed to produce that kind of output, whereas on other
 versions those same applications worked correctly -- and I had
 said so in my report.  I had expected the developers to check
 into my claim (of *every* - i.e., that it was the fault of that
 beta system), rather than suggesting that it was my fault for
 choosing a third-party application.  [The application I had
 named was the one easiest to install.]

  *  It would have taken significant effort on my part to discover
 whom to contact regarding the application I had named.  And in
 my mind I could imagine that person's reaction if I requested:
 "Although your application works on platform XYZ-111, and on
 all other platforms I have tried, it fails to produce the
 expected output on beta XYZ-112.  Please fix your application."


Let me suggest that Ubuntu appoint an usability triager/ombudsman, 
to determine (from the Ubuntu users' perspective, not from an Ubuntu 
developers' perspective) how much attention ought to be paid to each 
and every usability-related bug report.


mikus


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Reporting usability problems: please be more tolerant when you triage bugs!

[Sebastien Bacher]

On mer., 2009-07-22 at 18:47 +0200, Vincenzo Ciancia wrote:
> However, it is very easy that a developer does not recognise an 
> usability-related bug report, and confuses it with a more or less 
> strange support request, and I often have to discuss to have it
> accepted 
> as a bug. 

The issue is that Ubuntu doesn't write most of the softwares it
distribute and the current team doesn't have the manpower to work on
those and isn't well placed to decide on behavior changes that should be
done a software they are not writing. Ideally submitters would open
those bugs upstream too and argue directly there.

Cheers,
Sebastien Bacher


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Reporting usability problems: please be more tolerant when you triage bugs!

[Vincenzo Ciancia]

Il 22/07/2009 19:04, Henrique Almeida ha scritto:
>   Agreed. Ubuntu developers either don't understand my usability
> reports or tag them as low priority bugs, which gets triaged for many
> releases.

This is because these are not crashers and typically just affect a small 
portion of the application and of the codebase. My conclusions are that 
priorities are absolutely bad for dealing with usability.

Alternative solutions include the use of special tags, special packages 
(e.g. the papercut approach) or whatever. But this can only happen if 
developers are interested in assigning a separate kind of priority to 
usability bugs.

E.g. one may say that a bug is high priority as an usability bug but 
certainly it's not going to be prioritised over kernel crashes!

The hundred papercut approach is absolutely perfect, so perhaps a 
"papercut-potential" tag, if accepted by developer, would be nice. The 
idea being that such tagged bug may have a different meaning for 
priorities.

Your mileage may vary. I certailny can't decide :)

Vincenzo


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Reporting usability problems: please be more tolerant when you triage bugs!

[Henrique Almeida]

 Agreed. Ubuntu developers either don't understand my usability
reports or tag them as low priority bugs, which gets triaged for many
releases. Once I have submitted a bug report on an usability issue
that caused "information loss", which is serious. In certain PDF
files, I can't search for accented characters. This affects not only,
say, evince search, it also affects tracker searches, for example. The
main (non duplicate) bug for this was reported 2 years ago by
lherrmann and, right now, it's tagged as confirmed/unknown,
triaged/low.

 https://bugs.launchpad.net/poppler/+bug/116453

 This is just an example, I have reported other bugs that have been
ignored for years.

2009/7/22 Vincenzo Ciancia :
> Dear all,
>
> sorry for crossposting, please notice it before replying to all.
>
> I tend to report all usability bugs I find, in the hope that ubuntu will
> become better. The hudred-papercut effort shows that I am not wrong in
> reporting those as bugs.
>
> However, it is very easy that a developer does not recognise an
> usability-related bug report, and confuses it with a more or less
> strange support request, and I often have to discuss to have it accepted
> as a bug.
>
> It is typical that on usability bugs I get trapped into endless
> discussions (e.g. it's always been like that, it can't be fixed, it's an
> obvious behaviour and so on).
>
> In the future, I will try to remember to add a sentence like "this is an
> usability related bug report, please handle it as such, I am reporting
> it to ease the user experience of the whole ubuntu community" and maybe
> link this e-mail, but in the meantime, could developers try to be a bit
> more careful in rejecting bugs?
>
> I am NOT going to link specific bugs here, because that would get
> personal, but this is becoming tiresome. Today I went to IRC and
> convinced a developer that a bug is a usability problem indeed. This
> costed me a quarter of hour, in addition to the time spent to identify
> and report the bug. He had just closed the bug, without at least
> reassigning to ubuntu, because it's not specific to the package I
> reported it in. But in that case one reassings it to ubuntu perhaps! The
> apparent problem is that he took me for a newbie not understanding an
> obvious fact. Which I understood perfectly, but is not correct. In the
> end I convinced him, but it was a waste of time and it happened a lot in
> the past.
>
> Discussing all the time makes bug reporting an unpleasant experience,
> and discourages especially usability reports, as some people tend to
> assume a "technician" attitude in thinking these are stupid requests
> from unexperienced users. Being constantly confused with a newbie is
> also a bit irritating :) especially because I think reporting usability
> bugs is something people do not do usually, so we all really need this
> kind of things.
>
> Thanks for listening and the work all of you do everyday on my ubuntu,
> and thanks to the developer involved in today's discussion because he
> did not discuss too much, and as soon as he recognised it as a bug, he
> kindly offered cooperation.
>
> Vincenzo
>
> --
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
>



-- 
 Henrique Dante de Almeida
 hda...@gmail.com

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Reporting usability problems: please be more tolerant when you triage bugs!

[Vincenzo Ciancia]

Il 22/07/2009 18:47, Vincenzo Ciancia ha scritto:
> Dear all,
>
> sorry for crossposting, please notice it before replying to all.
>

I am possibly a bit of an idiot for what I did, but luckily the other 
list which has nothing to do with my target has a moderator.

I generate too much noise. My apologises.

Vincenzo

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Reporting usability problems: please be more tolerant when you triage bugs!

[Vincenzo Ciancia]

Dear all,

sorry for crossposting, please notice it before replying to all.

I tend to report all usability bugs I find, in the hope that ubuntu will 
become better. The hudred-papercut effort shows that I am not wrong in 
reporting those as bugs.

However, it is very easy that a developer does not recognise an 
usability-related bug report, and confuses it with a more or less 
strange support request, and I often have to discuss to have it accepted 
as a bug.

It is typical that on usability bugs I get trapped into endless 
discussions (e.g. it's always been like that, it can't be fixed, it's an 
obvious behaviour and so on).

In the future, I will try to remember to add a sentence like "this is an 
usability related bug report, please handle it as such, I am reporting 
it to ease the user experience of the whole ubuntu community" and maybe 
link this e-mail, but in the meantime, could developers try to be a bit 
more careful in rejecting bugs?

I am NOT going to link specific bugs here, because that would get 
personal, but this is becoming tiresome. Today I went to IRC and 
convinced a developer that a bug is a usability problem indeed. This 
costed me a quarter of hour, in addition to the time spent to identify 
and report the bug. He had just closed the bug, without at least 
reassigning to ubuntu, because it's not specific to the package I 
reported it in. But in that case one reassings it to ubuntu perhaps! The 
apparent problem is that he took me for a newbie not understanding an 
obvious fact. Which I understood perfectly, but is not correct. In the 
end I convinced him, but it was a waste of time and it happened a lot in 
the past.

Discussing all the time makes bug reporting an unpleasant experience, 
and discourages especially usability reports, as some people tend to 
assume a "technician" attitude in thinking these are stupid requests 
from unexperienced users. Being constantly confused with a newbie is 
also a bit irritating :) especially because I think reporting usability 
bugs is something people do not do usually, so we all really need this 
kind of things.

Thanks for listening and the work all of you do everyday on my ubuntu, 
and thanks to the developer involved in today's discussion because he 
did not discuss too much, and as soon as he recognised it as a bug, he 
kindly offered cooperation.

Vincenzo

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Few notes on filing "papercut" bugs

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mat Tomaszewski wrote on 12/06/09 12:07:
>...
> The response so far has been overwhelming and we are already finding
> it difficult to filter out bugs that indeed are "papercuts" from the
> ones that aren't. On that note, I think we need a clearer definition
> of which bugs do qualify as papercuts.
>
> Please do file as papercuts:
>
> - bugs that are system-wide (Nautilus, Gnome panel, etc), rather than
> app-specific (F-Spot, OOo, Terminal, etc.)
>...

I suggest judging bugs by how many people they are likely to affect,
regardless of whether they're in a particular application or not. A bug
that affects 50% of people using Banshee is probably more important to
fix than a bug that affects 5% of people using gnome-panel's brightness
applet.

Cheers
- --
Matthew Paul Thomas
http://mpt.net.nz/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko3fMkACgkQ6PUxNfU6ecrOrgCfTjn1rKPKMd1UDOONVU4feulM
WX8An1jyk2xJouVHEQBCQHHt1GIdxqa+
=/xtI
-END PGP SIGNATURE-


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Few notes on filing "papercut" bugs

[Mat Tomaszewski]

Hi,

During the recent UDS we launched a "100 Paper Cuts" project 
(https://edge.launchpad.net/hundredpapercuts), aiming to target and fix 
small but significant design and usability bugs in Ubuntu. We set an 
arbitrary target of 100 to be fixed for Karmic release.

The response so far has been overwhelming and we are already finding it 
difficult to filter out bugs that indeed are "papercuts" from the ones 
that aren't. On that note, I think we need a clearer definition of which 
bugs do qualify as papercuts.

Please do file as papercuts:

- bugs that are system-wide (Nautilus, Gnome panel, etc), rather than 
app-specific (F-Spot, OOo, Terminal, etc.)
- bugs that impact standard workflows (like connecting to the network, 
copying files, browsing folders, etc.), rather than specialised or 
corner case workflows (e.g. dragging an image in evince)
- bugs that are easy to address, rather that ones that require 
significant design or development efforts
- issues with existing features, rather than requests for new features
- bugs that relate to usability and design (like size of the 
notification bubbles), rather than broken software (e.g. notifications 
flickering in fullscreen)

Please pass this message on to anyone who may be interested in making 
Ubuntu better.

Many thanks!

Mat




-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Apport retrace service invalidates valid crasher bugs...

[Martin Pitt]

Luka Renko [2009-04-05  9:40 +0200]:
> This sounds very similar to the this bug I reported recently:
> https://launchpad.net/bugs/341358

Indeed it is the same reason. I'll work on this ASAP.

At least the impact is not that big, since it only rejects those
crashes if the retrace is really unusable (majority of functions
unknown in Stacktrace).

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Apport retrace service invalidates valid crasher bugs...

[Jan Claeys]

Op zondag 05-04-2009 om 09:40 uur [tijdzone +0200], schreef Luka Renko:
> On Sunday 05 April 2009 08:21:53 Jan Claeys wrote:
> > I reported a crash in Synaptic yesterday:
> > https://bugs.launchpad.net/ubuntu/+source/synaptic/+bug/355415
> >
> > Now, the "Apport retrace service" invalidated this bug because I don't
> > have scrollkeeper installed. But scrollkeeper is deprecated and
> > replaced by rarian-compat (which is a dependency of ubuntu-desktop).
> >
> > Also, Synaptic installs & works just fine *without* scrollkeeper.

> This sounds very similar to the this bug I reported recently:
> https://launchpad.net/bugs/341358

I had already filed a bug too:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/355481
(I've marked it as a duplicate of your report.)

I see you were also concerned about other crasher bugs being "hidden",
but according to Martin those bug reports have useless stacktraces
anyway.

Maybe the stacktrace is useless, but the number of such crashes might be
important too (Synaptic has been crashing like that for some time now),
or maybe there is a reason why the stacktraces are like that?

> > Seems like something is wrong with the retrace service, and I wonder how
> > many legitimate crasher bugs have been invalidated because of this?
> > I really hope not too many other packages are impacted, and I think it
> > might be useful to have a look at the invalidated bugs reported against
> > those packages...

> Apport consistently rejected at least crasher bugs in kdebluetooth4,
> which was crashing on suspend/resume. As you can see from IRC log, it
> seems that retracing service does not select " | " dependancies
> correctly (expects the first one to be installed).

I was already suspecting something like that, but Synaptic doesn't use
"|".  I think in this case the problem is that rarian-compat "replaces",
"conflicts" & "provides" the scrollkeeper package, while synaptic has a
dependency on scrollkeeper, and ubuntu-desktop has a dependency on
rarian-compat.


-- 
Jan Claeys


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Apport retrace service invalidates valid crasher bugs...

[Luka Renko]

On Sunday 05 April 2009 08:21:53 Jan Claeys wrote:
> I reported a crash in Synaptic yesterday:
> https://bugs.launchpad.net/ubuntu/+source/synaptic/+bug/355415
>
> Now, the "Apport retrace service" invalidated this bug because I don't
> have scrollkeeper installed.  But scrollkeeper is deprecated and
> replaced by rarian-compat (which is a dependency of ubuntu-desktop).
>
> Also, Synaptic installs & works just fine *without* scrollkeeper.

This sounds very similar to the this bug I reported recently:
https://launchpad.net/bugs/341358

> Seems like something is wrong with the retrace service, and I wonder how
> many legitimate crasher bugs have been invalidated because of this?
> I really hope not too many other packages are impacted, and I think it
> might be useful to have a look at the invalidated bugs reported against
> those packages...

Apport consistently rejected at least crasher bugs in kdebluetooth4, which was 
crashing on suspend/resume. As you can see from IRC log, it seems that 
retracing service does not select " | " dependancies correctly (expects the 
first one to be installed).

Regards,
Luka
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Apport retrace service invalidates valid crasher bugs...

[Jan Claeys]

I reported a crash in Synaptic yesterday:
https://bugs.launchpad.net/ubuntu/+source/synaptic/+bug/355415

Now, the "Apport retrace service" invalidated this bug because I don't
have scrollkeeper installed.  But scrollkeeper is deprecated and
replaced by rarian-compat (which is a dependency of ubuntu-desktop).

Also, Synaptic installs & works just fine *without* scrollkeeper.


Seems like something is wrong with the retrace service, and I wonder how
many legitimate crasher bugs have been invalidated because of this?
I really hope not too many other packages are impacted, and I think it
might be useful to have a look at the invalidated bugs reported against
those packages...


PS: I'd be happy to file a bug about this, but I'm not sure where to
file it (launchpad, apport-retrace, somewhere else?).


-- 
Jan Claeys


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Best practice for reporting bugs

[John Vivirito]

On 03/29/2009 05:29 PM, (``-_-´´) -- BUGabundo wrote:
> Olá Stewart e a todos.
> 
> On Friday 27 March 2009 00:09:11 Stewart Johnston wrote:
>> Slightly to one side, when Apport starts and walks me through the 
>> process of filing a bug, the first thing I do is nip off and search 
>> Launchpad for the same bug, then if I find one I cancel apport.
> 
> Its just a petty that the apport logs are lost when you mark it as a dupe of 
> an existing one.
> I've seen triagers/devs request for that info.
> 
> I've even filed new bugs just to have apport upload the data, and then 
> manually dupe it to the master bug, mentioning that I have a dupe with new 
> apport data.
> 
> Cant the apport data still be uploaded to dupes, until some flag* is added 
> saying no more apport data is needed (saving storage on LP) ?
> 
> 
Normally if you use Apport to file bugs it will mark it as a duplicate
even if the other bug isnt the master bug.
When reporting a crash its normally a good idea not to mark it as a
duplicate since crashes can have simular back trace but not be the same
bug. By filing a new bug using Apport it gives us the information needed
to help you better if it is not marked as a duplicate.

-- 
Sincerely Yours,
John Vivirito

https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246

"How can i get lost, if i have no where to go"
-- Metallica from Unforgiven III



signature.asc
Description: OpenPGP digital signature
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Best practice for reporting bugs

[(``-_-´´) -- BUGabundo]

Olá Stewart e a todos.

On Friday 27 March 2009 00:09:11 Stewart Johnston wrote:
> Slightly to one side, when Apport starts and walks me through the 
> process of filing a bug, the first thing I do is nip off and search 
> Launchpad for the same bug, then if I find one I cancel apport.

Its just a petty that the apport logs are lost when you mark it as a dupe of an 
existing one.
I've seen triagers/devs request for that info.

I've even filed new bugs just to have apport upload the data, and then manually 
dupe it to the master bug, mentioning that I have a dupe with new apport data.

Cant the apport data still be uploaded to dupes, until some flag* is added 
saying no more apport data is needed (saving storage on LP) ?

-- 
Hi, I'm BUGabundo, and I am Ubuntu (whyubuntu.com)
(``-_-´´)   http://LinuxNoDEI.BUGabundo.net
Linux user #443786GPG key 1024D/A1784EBB
http://BUGabundo.net


signature.asc
Description: This is a digitally signed message part.
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Best practice for reporting bugs

[scj]

Quoting Martin Pitt :

> Stewart Johnston [2009-03-27 11:09 +1100]:
>> Slightly to one side, when Apport starts and walks me through the
>> process of filing a bug, the first thing I do is nip off and search
>> Launchpad for the same bug, then if I find one I cancel apport.
>>
>> Is this what I should be doing, or is it preferable to let apport finish
>> and then mark the new bug as a duplicate?
>
> When I encounter a crash, I usually let it collect data and upload,
> and then check out Launchpad's proposed list of existing bugs. For
> crash bugs, the hit rate is usually close to perfect. For bug reports
> less so, of course, since we can't have a standard title there. For
> those it probably makes sense to look beforehand.
>
> Martin
>
> --
> Martin Pitt| http://www.piware.de
> Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
>
> --
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
>

Just filed a bug and noticed that. Either it's a fairly recent change, or I've
been too daft to notice it beforehand. Cheers for that.

Stoo


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Best practice for reporting bugs

[Martin Pitt]

Stewart Johnston [2009-03-27 11:09 +1100]:
> Slightly to one side, when Apport starts and walks me through the 
> process of filing a bug, the first thing I do is nip off and search 
> Launchpad for the same bug, then if I find one I cancel apport.
> 
> Is this what I should be doing, or is it preferable to let apport finish 
> and then mark the new bug as a duplicate?

When I encounter a crash, I usually let it collect data and upload,
and then check out Launchpad's proposed list of existing bugs. For
crash bugs, the hit rate is usually close to perfect. For bug reports
less so, of course, since we can't have a standard title there. For
those it probably makes sense to look beforehand.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Best practice for reporting bugs

[Stewart Johnston]

Matt Zimmerman wrote:
> I've noticed that, even among Ubuntu devleopers, not everyone is applying
> our best practices for reporting bugs.  In particular, reporting bugs
> directly to Launchpad is usually *NOT* the best approach.  This should only
> be done if there is no better option.
>
> In almost all cases, it is preferable to report the bug using Apport.  This
> can be done in one of the following ways:
>
> 1. If the bug is a crash, apport should automatically generate a report and
> guide you in filing it.  Copies of the crash reports are stored in
> /var/crash in case you need to refer to them directly.
>
> 2. The "Help" menu in many applications includes an entry "Report a
> problem..." which will invoke Apport manually.
>
> 3. On the command line, you can run "ubuntu-bug " (or "ubuntu-bug
> ") to invoke Apport manually.  Kernel bugs should be reported with
> "ubuntu-bug linux".
>
> Using this method will automatically attach the relevant version
> information, log files, etc. where available.  This saves you time in filing
> the bug, and saves others time in analyzing it.  For example, filing a bug
> on the kernel will automatically include dmesg, lspci and so on.
>
> We're about to get flooded with bug reports from the beta, so please
> start using this method immediately, and encourage everyone else who reports
> bugs to do the same.
>
> More instructions for filing bugs can be found in the community
> documentation at https://help.ubuntu.com/community/ReportingBugs
>
> Note that if someone files a bug without using apport, you can still take
> advantage of it to add the information later (assuming it's still relevant),
> by using apport-collect(1).  See
> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-February/000535.html
> for details.
>
> If you'd like to enhance your packages to take better advantage of apport by
> attaching relevant data, please ask for help.  It's very simple once you
> know how to do it.  The basics can be found at
> https://wiki.ubuntu.com/Apport/DeveloperHowTo
>   
Slightly to one side, when Apport starts and walks me through the 
process of filing a bug, the first thing I do is nip off and search 
Launchpad for the same bug, then if I find one I cancel apport.

Is this what I should be doing, or is it preferable to let apport finish 
and then mark the new bug as a duplicate?

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Best practice for reporting bugs

[Derek Broughton]

Brian Murray wrote:

> You might be interested to know that reportbug has been modified in
> Jaunty[1] and that the package override is being changed to not point
> people to ubuntu-users[2].
> 
> [1] http://launchpad.net/bugs/228183
> [2] http://launchpad.net/bugs/326091

Not me.  I stopped being interested in these bugs years ago, when it was
clear that nobody was actually interested in fixing them.  Bug #7839 was
closed two years ago because devs (yes, Matt, you) considered it good
enough to just move reportbug out of main - never mind that it's been
broken as long as there's been an Ubuntu.  I subscribed to #7839 3 1/2
years ago, and it was already a year old.  So that's coming up to five
years so far, and I'll believe it's fixed when I see it.  Personally, I
believe there's a better chance of seeing a fix to bug #1.

-- 
derek


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Best practice for reporting bugs

[Brian Murray]

On Wed, Mar 25, 2009 at 08:44:13PM -0300, Derek Broughton wrote:
> Matt Zimmerman wrote:
> 
> >> That's going to be news to the average user, of which a noticeable number
> >> are _still_ using the old bug tools to file a bug straight
> >> to "ubuntu-users"
> > 
> > We don't install those tools by default, while we do install apport. 
> 
> I know, but there's still a significant number of people using releases
> pre-Intrepid (or maybe hardy), which had reportbug, and we still see those
> bug reports.  I know there isn't much to be done about that, but telling
> everybody about - and how to use - apport will help.

You might be interested to know that reportbug has been modified in
Jaunty[1] and that the package override is being changed to not point
people to ubuntu-users[2].

[1] http://launchpad.net/bugs/228183
[2] http://launchpad.net/bugs/326091
 
-- 
Brian Murray @ubuntu.com


signature.asc
Description: Digital signature
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Best practice for reporting bugs

[Derek Broughton]

Matt Zimmerman wrote:

>> That's going to be news to the average user, of which a noticeable number
>> are _still_ using the old bug tools to file a bug straight
>> to "ubuntu-users"
> 
> We don't install those tools by default, while we do install apport. 

I know, but there's still a significant number of people using releases
pre-Intrepid (or maybe hardy), which had reportbug, and we still see those
bug reports.  I know there isn't much to be done about that, but telling
everybody about - and how to use - apport will help.

> The missing piece is to get everyone telling
> each other about the right way to do it.

Absolutely - which is why I asked for a repost of your message that started
this thread.  Thanks for the info.
-- 
derek


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Best practice for reporting bugs

[Matt Zimmerman]

On Wed, Mar 25, 2009 at 03:46:05PM -0300, Derek Broughton wrote:
> Mackenzie Morgan wrote:
> 
> > On Wednesday 25 March 2009 11:08:11 am Derek Broughton wrote:
> >> Matt Zimmerman wrote:
> >> 
> >> > On Wed, Mar 25, 2009 at 12:38:44PM +, Chris Jones wrote:
> >> >> Matt Zimmerman wrote:
> >> >> > our best practices for reporting bugs.  In particular, reporting
> >> >> > bugs
> >> >> > directly to Launchpad is usually *NOT* the best approach.  This
> >> >> > should only
> >> >> 
> >> >> Perhaps Launchpad could specifically discourage this within /ubuntu/
> >> >> and offer up much the same information in your mail?
> >> > 
> >> > Indeed, it does give that guidance but it's usually too late to help
> >> > (i.e.
> >> > after +filebug).  
> 
> I file many bugs at launchpad, and haven't seen anything suggesting a better
> place.  In fact, I keep getting told to file bugs at launchpad...

Launchpad itself could do a much better job of telling you how to report
bugs, I agree.

The authoritative documentation for this is currently
https://help.ubuntu.com/community/ReportingBugs

> > In almost all cases, it is preferable to report the bug using Apport. 
> > This can be done in one of the following ways:
> > 
> > 1. If the bug is a crash, apport should automatically generate a report
> > and
> > guide you in filing it.  Copies of the crash reports are stored in
> > /var/crash in case you need to refer to them directly.
> 
> I think that's happened to me _once_.  iirc, it gave a message that was
> about as encouraging as the Windows "May we send a report to Microsoft...". 
> No doubt most people say "Shut up" and close the window.  It doesn't seem
> to happen with KDE apps, though I've regressed to Hardy, so perhaps it will
> when I can get back to Intrepid+.

This is only enabled during development.  For example, it's currently
enabled in Jaunty, but will be turned off for the final release, then
enabled in Karmic, etc.

> > 3. On the command line, you can run "ubuntu-bug " (or "ubuntu-bug
> > ") to invoke Apport manually.  Kernel bugs should be reported with
> > "ubuntu-bug linux".
> 
> That's going to be news to the average user, of which a noticeable number
> are _still_ using the old bug tools to file a bug straight
> to "ubuntu-users" 

We don't install those tools by default, while we do install apport.  Anyone
who searches the web looking for how to report bugs in Ubuntu should find
the above documentation.  The missing piece is to get everyone telling each
other about the right way to do it.

-- 
 - mdz

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Best practice for reporting bugs

[Derek Broughton]

Mackenzie Morgan wrote:

> On Wednesday 25 March 2009 11:08:11 am Derek Broughton wrote:
>> Matt Zimmerman wrote:
>> 
>> > On Wed, Mar 25, 2009 at 12:38:44PM +, Chris Jones wrote:
>> >> Matt Zimmerman wrote:
>> >> > our best practices for reporting bugs.  In particular, reporting
>> >> > bugs
>> >> > directly to Launchpad is usually *NOT* the best approach.  This
>> >> > should only
>> >> 
>> >> Perhaps Launchpad could specifically discourage this within /ubuntu/
>> >> and offer up much the same information in your mail?
>> > 
>> > Indeed, it does give that guidance but it's usually too late to help
>> > (i.e.
>> > after +filebug).  

I file many bugs at launchpad, and haven't seen anything suggesting a better
place.  In fact, I keep getting told to file bugs at launchpad...

>> Would you care to mention what the best practice _is_?  The post to which
>> Chris replied is not on my server, the list archive, or google.  The only
>> hint I've ever had that reporting bugs to Launchpad is not the best
>> approach is the short shrift most of them get...
> 
> That's because Chris replied to -devel-discuss when the post was on just
> plain
> -devel.  Here's the text:

Thanks.

Chris:  Please if you think it belongs on another list (I agree this belongs
here), quote the whole message you're responding to, or at least give us a
link to the original.  

> I've noticed that, even among Ubuntu devleopers, not everyone is applying
> our best practices for reporting bugs.  In particular, reporting bugs
> directly to Launchpad is usually NOT the best approach.  This should only
> be done if there is no better option.
> 
> In almost all cases, it is preferable to report the bug using Apport. 
> This can be done in one of the following ways:
> 
> 1. If the bug is a crash, apport should automatically generate a report
> and
> guide you in filing it.  Copies of the crash reports are stored in
> /var/crash in case you need to refer to them directly.

I think that's happened to me _once_.  iirc, it gave a message that was
about as encouraging as the Windows "May we send a report to Microsoft...". 
No doubt most people say "Shut up" and close the window.  It doesn't seem
to happen with KDE apps, though I've regressed to Hardy, so perhaps it will
when I can get back to Intrepid+.

> 2. The "Help" menu in many applications includes an entry "Report a
> problem..." which will invoke Apport manually.

afaik, all KDE apps still report directly to bugs.kde.org if you do that.
 
> 3. On the command line, you can run "ubuntu-bug " (or "ubuntu-bug
> ") to invoke Apport manually.  Kernel bugs should be reported with
> "ubuntu-bug linux".

That's going to be news to the average user, of which a noticeable number
are _still_ using the old bug tools to file a bug straight
to "ubuntu-users" 

-- 
derek


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Best practice for reporting bugs

[Mackenzie Morgan]

On Wednesday 25 March 2009 11:08:11 am Derek Broughton wrote:
> Matt Zimmerman wrote:
> 
> > On Wed, Mar 25, 2009 at 12:38:44PM +, Chris Jones wrote:
> >> Matt Zimmerman wrote:
> >> > our best practices for reporting bugs.  In particular, reporting bugs
> >> > directly to Launchpad is usually *NOT* the best approach.  This should
> >> > only
> >> 
> >> Perhaps Launchpad could specifically discourage this within /ubuntu/ and
> >> offer up much the same information in your mail?
> > 
> > Indeed, it does give that guidance but it's usually too late to help (i.e.
> > after +filebug).  I believe this is on the QA team's launchpad wishlist
> > already.
> 
> Would you care to mention what the best practice _is_?  The post to which
> Chris replied is not on my server, the list archive, or google.  The only
> hint I've ever had that reporting bugs to Launchpad is not the best
> approach is the short shrift most of them get...

That's because Chris replied to -devel-discuss when the post was on just plain 
-devel.  Here's the text:

I've noticed that, even among Ubuntu devleopers, not everyone is applying
our best practices for reporting bugs.  In particular, reporting bugs
directly to Launchpad is usually NOT the best approach.  This should only
be done if there is no better option.

In almost all cases, it is preferable to report the bug using Apport.  This
can be done in one of the following ways:

1. If the bug is a crash, apport should automatically generate a report and
guide you in filing it.  Copies of the crash reports are stored in
/var/crash in case you need to refer to them directly.

2. The "Help" menu in many applications includes an entry "Report a
problem..." which will invoke Apport manually.

3. On the command line, you can run "ubuntu-bug " (or "ubuntu-bug
") to invoke Apport manually.  Kernel bugs should be reported with
"ubuntu-bug linux".

Using this method will automatically attach the relevant version
information, log files, etc. where available.  This saves you time in filing
the bug, and saves others time in analyzing it.  For example, filing a bug
on the kernel will automatically include dmesg, lspci and so on.

We're about to get flooded with bug reports from the beta, so please
start using this method immediately, and encourage everyone else who reports
bugs to do the same.

More instructions for filing bugs can be found in the community
documentation at https://help.ubuntu.com/community/ReportingBugs

Note that if someone files a bug without using apport, you can still take
advantage of it to add the information later (assuming it's still relevant),
by using apport-collect(1).  See
https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-
February/000535.html
for details.

If you'd like to enhance your packages to take better advantage of apport by
attaching relevant data, please ask for help.  It's very simple once you
know how to do it.  The basics can be found at
https://wiki.ubuntu.com/Apport/DeveloperHowTo

-- 
Mackenzie Morgan
http://ubuntulinuxtipstricks.blogspot.com
apt-get moo


signature.asc
Description: This is a digitally signed message part.
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Best practice for reporting bugs

[Derek Broughton]

Matt Zimmerman wrote:

> On Wed, Mar 25, 2009 at 12:38:44PM +, Chris Jones wrote:
>> Matt Zimmerman wrote:
>> > our best practices for reporting bugs.  In particular, reporting bugs
>> > directly to Launchpad is usually *NOT* the best approach.  This should
>> > only
>> 
>> Perhaps Launchpad could specifically discourage this within /ubuntu/ and
>> offer up much the same information in your mail?
> 
> Indeed, it does give that guidance but it's usually too late to help (i.e.
> after +filebug).  I believe this is on the QA team's launchpad wishlist
> already.

Would you care to mention what the best practice _is_?  The post to which
Chris replied is not on my server, the list archive, or google.  The only
hint I've ever had that reporting bugs to Launchpad is not the best
approach is the short shrift most of them get...
-- 
derek


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Best practice for reporting bugs

[Matt Zimmerman]

On Wed, Mar 25, 2009 at 12:38:44PM +, Chris Jones wrote:
> Matt Zimmerman wrote:
> > our best practices for reporting bugs.  In particular, reporting bugs
> > directly to Launchpad is usually *NOT* the best approach.  This should only
> 
> Perhaps Launchpad could specifically discourage this within /ubuntu/ and
> offer up much the same information in your mail?

Indeed, it does give that guidance but it's usually too late to help (i.e.
after +filebug).  I believe this is on the QA team's launchpad wishlist
already.

-- 
 - mdz

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Best practice for reporting bugs

[Chris Jones]

Hi

Matt Zimmerman wrote:
> our best practices for reporting bugs.  In particular, reporting bugs
> directly to Launchpad is usually *NOT* the best approach.  This should only

Perhaps Launchpad could specifically discourage this within /ubuntu/ and
offer up much the same information in your mail?

Cheers,
-- 
Chris Jones

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Introducing apport-collect: attach apport hook information to existing bugs

[Martin Pitt]

Bryce Harrington [2009-02-19 16:27 -0800]:
> This is a very cool feature.  I notice that it sends a separate email
> for each file attached.  Any chance it could be modified to attach all
> the files in one go, so only one email is produced?

Unfortunately not, launchpadlib does not offer this possibility ATM.
The "batch all attachments in one mail" is a special magic for the
blobs (/+storeblob) that you upload when filing a new bug.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Introducing apport-collect: attach apport hook information to existing bugs

[Bryce Harrington]

Hi Martin,

This is a very cool feature.  I notice that it sends a separate email
for each file attached.  Any chance it could be modified to attach all
the files in one go, so only one email is produced?

Bryce

On Thu, Feb 19, 2009 at 02:03:26PM +0100, Martin Pitt wrote:
> Hello Ubuntu developers and bug triagers,
> 
> Apport has supported hooks to collect package specific information for
> crash reports and bug reports submitted through Apport [1] for a long
> time.
> 
> A long standing request [2] was to provide a tool which provides the
> same functionality for already existing bugs. I. e. if a submitter
> reported a bug against xorg directly through the Launchpad UI, you can
> now ask him to run
> 
>   apport-collect 12345
> 
> (with 12345 being the bug number, obviously). This will check all
> source packages in the bug tasks, run all their apport hooks, and
> upload the collected information back to the bug report.
> 
> It uses launchpadlib for authentication.
> 
> The tool has a manpage, and I also added it to [3].
> 
> Enjoy, and please let me know about any problems by filing bugs
> against apport.
> 
> Thank you,
> 
> Martin
> 
> [1] with ubuntu-bug or Help -> Report a Bug for GNOME applications
> [2] https://bugs.launchpad.net/ubuntu/+source/apport/+bug/124338
> [3] https://wiki.ubuntu.com/Apport#Tools
> -- 
> Martin Pitt| http://www.piware.de
> Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)



> -- 
> ubuntu-devel-announce mailing list
> ubuntu-devel-annou...@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Introducing apport-collect: attach apport hook information to existing bugs

[Martin Pitt]

(``-_-´´) -- BUGabundo [2009-02-19 16:10 +]:
> I would love to see this, but its failing to build
> https://launchpad.net/ubuntu/+source/apport/0.132/+build/875501

Should be fixed now, python-central had a bug which got fixed today.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: Digital signature
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Introducing apport-collect: attach apport hook information to existing bugs

[(``-_-´´) -- BUGabundo]

Olá Martin e a todos.

On Thursday 19 February 2009 13:03:26 Martin Pitt wrote:
> A long standing request [2] was to provide a tool which provides the
> same functionality for already existing bugs. I. e. if a submitter
> reported a bug against xorg directly through the Launchpad UI, you can
> now ask him to run
> 
>   apport-collect 12345

I would love to see this, but its failing to build
https://launchpad.net/ubuntu/+source/apport/0.132/+build/875501

-- 
Hi, I'm BUGabundo, and I am Ubuntu (whyubuntu.com)
(``-_-´´)   http://LinuxNoDEI.BUGabundo.net
Linux user #443786GPG key 1024D/A1784EBB
My new micro-blog @ http://BUGabundo.net
ps. My emails tend to sound authority and aggressive. I'm sorry in advance. 
I'll try to be more assertive as time goes by...


signature.asc
Description: This is a digitally signed message part.
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: How to push bugs upstream

[Charlie Kravetz]

On Fri, 26 Dec 2008 12:57:09 +0100
Markus Hitter  wrote:

> Hello all,
> 
> one of my bug reports (282379) didn't get any attention and, as it's  
> a problem likely better solved upstreams, I'd like to push the bug  
> upstreams myself. Is there any recommended or standardized procedure  
> to do so?
> 
> <https://bugs.launchpad.net/ubuntu/+source/virtualbox-ose/+bug/282379>
> 
> 
> Thanks,
> Markus / Traumflug
> 
> - - - - - - - - - - - - - - - - - - -
> Dipl. Ing. Markus Hitter
> http://www.jump-ing.de/
> 

Yes, this is what the bugsquad uses:
https://wiki.ubuntu.com/Bugs/HowToTriage#Forwarding%20upstream

Good luck,

-- 
Charlie Kravetz 
Linux Registered User Number 425914  [http://counter.li.org/]
Never let anyone steal your DREAM.   [http://keepingdreams.com]

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: How to push bugs upstream

[Dotan Cohen]

 2008/12/26 Markus Hitter :
> Hello all,
>
> one of my bug reports (282379) didn't get any attention and, as it's
> a problem likely better solved upstreams, I'd like to push the bug
> upstreams myself. Is there any recommended or standardized procedure
> to do so?
>
> 
>
>
> Thanks,
> Markus / Traumflug
>

Go to the official bugtracker and file it:
http://www.virtualbox.org/wiki/Bugtracker

-- 
Dotan Cohen

http://what-is-what.com
http://gibberish.co.il

א-ב-ג-ד-ה-ו-ז-ח-ט-י-ך-כ-ל-ם-מ-ן-נ-ס-ע-ף-פ-ץ-צ-ק-ר-ש-ת
ا-ب-ت-ث-ج-ح-خ-د-ذ-ر-ز-س-ش-ص-ض-ط-ظ-ع-غ-ف-ق-ك-ل-م-ن-ه‍-و-ي
А-Б-В-Г-Д-Е-Ё-Ж-З-И-Й-К-Л-М-Н-О-П-Р-С-Т-У-Ф-Х-Ц-Ч-Ш-Щ-Ъ-Ы-Ь-Э-Ю-Я
а-б-в-г-д-е-ё-ж-з-и-й-к-л-м-н-о-п-р-с-т-у-ф-х-ц-ч-ш-щ-ъ-ы-ь-э-ю-я
ä-ö-ü-ß-Ä-Ö-Ü
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

How to push bugs upstream

[Markus Hitter]

Hello all,

one of my bug reports (282379) didn't get any attention and, as it's  
a problem likely better solved upstreams, I'd like to push the bug  
upstreams myself. Is there any recommended or standardized procedure  
to do so?




Thanks,
Markus / Traumflug

- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/





-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: bugs

[Peteris Krisjanis]

Even, please report bug to Launchpad and then provide link here, so
someone can check it out asap and start to work on it.

Just a question about first bug - sound is crackly, but do you manage
to get sound from Totem or Rhythmbox and cracking only comes over it?
Or there is just clicks and nothing else. I also suggest you to check
Volume Control (Right click on speaker icon in top right coner) and
see volume levels for Master and PCM.

Cheers,
Mortigi tempo,
Peter.

2008/10/9 Evan Billy <[EMAIL PROTECTED]>:
> Here are some bugs I have found in the kernel (if it helps)
> 1. my sound is crackly, when a sound is supposed to play it just plays
> crackles
> 2. the new kernel has some kind of booting problem or error on my computer;
> it displays what it is doing and I have to press enter multiple times to get
> it started.
> 3. The new network manager wont work for me. It worked when i upgraded, but
> now it will not recognize my Internet connection.
>
>
> -Evan
> --
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
>
>

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: bugs

[(``-_-´´) -- Fernando]

Olá Bryce e a todos.

On Tuesday 21 October 2008 01:36:24 Bryce Harrington wrote:
> This is not the right place to report bugs.  Please use launchpad.

Bryce, you could at least provided the (new) user with Launchpad URL.
I'm always amazed by huge number of Ubuntu users that dont know about it, or 
neglect to create an account so that they can fill and track a bug.

Evan please visit https://bugs.launchpad.net/ubuntu/+filebug

Hope that helps.

-- 
BUGabundo  :o)
(``-_-´´)   http://LinuxNoDEI.BUGabundo.net
Linux user #443786GPG key 1024D/A1784EBB
My new micro-blog @ http://BUGabundo.net
ps. My emails tend to sound authority and aggressive. I'm sorry in advance. 
I'll try to be more assertive as time goes by...

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: bugs

[Bryce Harrington]

This is not the right place to report bugs.  Please use launchpad.

Also, when reporting bugs, please find and follow the bug guidelines for
the thing you're reporting bugs against.  For the linux kernel,
guidelines are at:

 https://wiki.ubuntu.com/KernelTeamBugPolicies

More info on debugging other components are found here:

 https://wiki.ubuntu.com/DebuggingProcedures

Bryce


On Thu, Oct 09, 2008 at 04:38:25PM -0400, Evan Billy wrote:
> Here are some bugs I have found in the kernel (if it helps)
> 1. my sound is crackly, when a sound is supposed to play it just plays
> crackles
> 2. the new kernel has some kind of booting problem or error on my computer;
> it displays what it is doing and I have to press enter multiple times to get
> it started.
> 3. The new network manager wont work for me. It worked when i upgraded, but
> now it will not recognize my Internet connection.
> 
> 
> -Evan

> -- 
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

bugs

[Evan Billy]

Here are some bugs I have found in the kernel (if it helps)
1. my sound is crackly, when a sound is supposed to play it just plays
crackles
2. the new kernel has some kind of booting problem or error on my computer;
it displays what it is doing and I have to press enter multiple times to get
it started.
3. The new network manager wont work for me. It worked when i upgraded, but
now it will not recognize my Internet connection.


-Evan
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Backtracing, Invalidated Bugs and Quality

[Markus Hitter]

Am 14.09.2008 um 03:32 schrieb Null Ack:

> Action Item 1: I'm not a developer, but I can help any developers with
> testing and feedback for enhancements to Apport.

Null,

your investments in enhancing Apport ist great. Now, a few weeks  
later, I've learned Apport can map coredumps to readable text  
already. One of the bugs I've filed shows how things can go wrong:

<https://bugs.launchpad.net/ubuntu/+source/evince/+bug/260715>

Another one went a lot better:

<https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/ 
269595>

Minutes after I've Apport-reported the later bug, stack traces came  
out of (apparently) nowhere and within a day, a fix was posted. Short  
of self-healing applications, this is about as good as one can imagine.


MarKus

- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/





-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Backtracing, Invalidated Bugs and Quality

[Null Ack]

Gday everyone. As part of my work with the QA Team I want to
contribute to fixing the process gaps in this area. Can I summarise
what I see as the problem:

Problem situation: I'm increasingly noticing that certain types of
bugs are being marked invalid or incomplete with boilerplate type
messages instructing the bug reporter to conduct a backtrace. The
engagement of the end user is poor, the user experience is
non-intuitve, the documentation to walk through how a user can do this
is poor and the net effect is that the "hit rate" of users actually
fulfilling the request is very low. The net result is usually that the
bug stagnates and duplicate bugs pile up. It may, or may not, then get
filled upstream if the number of duplicate bugs gets high enough for
somebody to notice it. I have a high regard for all the Ubuntu
developers, and I say this carefully, but I think if were all honest
about the situation like some developers have been to me there is an
element of "gee Im so busy and this bug report looks non trivial...I
might just copy and paste my back trace wording to this, move the
status to get it out of the way and if it's a real problem eventually
a bunch of users will report this too and then I might send it
upstream then because upsteam have the time to look at this."

There was a discussion on IRC which I've summarised here for the list
and some proposed action items:

1. The Tool Chain For Debugging is Not Robust

The point was made that the debugging toolchain is complex and will
not consistently provide the needed debugging information on all
occasions. Sometimes the retracing will fail for some reason. I simply
see this as a longer term challenge for the FOSS community to work on
bugs in the toolchain - obviously having a reliable and repeatable
method for getting right into the guts of the registers and stack is
important for fixing the more curly bugs. The toolchain being
imperfect however is not an excuse for failing to implement best
practices in Ubuntu for debugging in the meantime. We can make
progress.

2. The Volume Of Bugs Coming Through Makes The Hard Ones Too Hard

It was suggested that the number of bugs coming through is so high
that trying to fix the more tricky ones isnt worth the time given
available amounts of person power. I made the point and I'd like to
highlight it again that the complexity of fixing a bug should not be
the criteria for which bugs get developer attention. The best practice
for building quality in Ubuntu in my view is the determinants should
be how seriously it effects the user experience and how common that
user experience is. When I've got stuck in my testing work on Ubuntu
I've appealed for help in the testing section of the Ubuntu forum or
on IRC, and I've been greatly encouraged by good helpful responses
back. Im sure bug squadders and Ubuntu testers would be happy to
respond to developers with unit testing, feedback etcetc. I recently
helped Alexander Sack with performance feedback on a web browsing item
and unit testing - it was fun!

2. The Need For Improving Apport

A developer suggested that there is not a gap with Apport as it exists
now. I disagree and I sighted the example of where a package is
compiled with optimised compiler flags that a debug package will need
to be installed to get a meaningful trace. I know from experience that
automated ways of doing this, or atleast having an easier and
intuitive user workflow for this is better than documentation. I
really like Markus' ideas for improving Apports functionality he
shared earlier.

Action Item 1: I'm not a developer, but I can help any developers with
testing and feedback for enhancements to Apport. I might also be able
to assist with design / blueprints / discussing possible features. Or,
someone come up with compelling reasons why Apport is fine the way it
is and the worflow issues can be resolved another way.

Another thing that came up in the talks was that the backtrace
boilerplate copy and paste wasnt always accurate in the circumstances
its being used. Sometimes the real issue is being able to replicate
the problem not the backtrace. Or, a backtrace on a debug build is
truly needed but the user doesnt know how to help in detail and bug
squadders cant replicate the problem at will on their configurations.
Or, since there is considerable obselete info hanging around there is
confusion with bug squadders about what exactly to do and human error
has occured.

Action Item 2: A review of the documentation on both the user side and
the bug squadder / developer side to more fully explain and walk
people through the situation. I can help here too, but again I'm not a
developer so especially the more technical aspects of the backtrace,
why it sometimes fails, how to do manually, will need other peoples
involvement. Basically to improve the hit rate.

That seems to be what the IRC logs touched on, thanks.

-- 
Ubuntu-d

Re: Backtracing, Invalidated Bugs and Quality

[Null Ack]

Thanks for all the discussion on this folks. :)

Just now I had a crash in totem with apport leading me to 9 previously
reported bugs that are either invalid or incomplete because the bug
reporter did not do a backtrace to help fix the problem. Now I have
the same issue, when it was originally reported in the first bug
report all the way back in May 2007 with no concrete progress since.

On top of this, people have said that its a recurring discussion that
comes up every six months or so, so lets fix this eh.

To recap, I've suggested that all Alpha builds could be debug by default builds.

Others, such as Markus have what I frankly think is a better idea
where apport tells the user the situation and downloads a debug
version of the package and waits for it to occur again. Then it sends
the backtrace to the right bug for analysis.

Krzysztof seemed to have a promising idea similar to apparently what
MS do "The information about debugging symbols
is only needed on server, client only sends (in simplest version) MD5
sum of library and address offset, which is transformed into the
symbol by symbol serve"

Can we focus on a debate about what the best approach is? This in turn
can lead to the details with implementation.

Thanks

Nullack

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Bugs for NM 0.7

[Alexander Sack]

On Mon, Sep 08, 2008 at 10:53:42AM +0100, Matthew Garrett wrote:
> On Mon, Sep 08, 2008 at 11:51:59AM +0200, Alexander Sack wrote:
> > On Mon, Sep 08, 2008 at 10:44:49AM +0100, Matthew Garrett wrote:
> > > The thread was discussing the removal of network-admin - doesn't that 
> > > modify /etc/network/interfaces?
> > 
> > Yes it does that atm. But if network-admin is still wanted in the long
> > run - it could also write keyfile system configurations.
> 
> Right, but I believe the issue is that without network-admin there's no 
> graphical means of configuring the legacy networking interface.
> 

The upload hopefully coming today will have a more or less well
working /e/n/i backend, which is read-only. You can enable it by
enabling the "ifupdown" plugin in
/etc/NetworkManager/nm-system-settings.conf

So please test that and report network-admin managed use-cases that
dont work.

 - Alexander


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss