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) );
with:
  quotactl, QCMD(Q_GETINFO,USRQUOTA), NULL, -1, (caddr_t) 
);

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

[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

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

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: 

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

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: Reporting bugs directly to Launchpad?

[Simos Xenitellis]

On Sat, Aug 3, 2013 at 12:06 AM, Patrick Goetz pgo...@mail.utexas.eduwrote:

 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/saucyhttps://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/ReportingBugshttps://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

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 pgo...@mail.utexas.eduwrote:
  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/saucyhttps://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/ReportingBugshttps://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: 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

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

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 timfr...@xtra.co.nz


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

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 timfr...@xtra.co.nz


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

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

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

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 ubuntu-devel-discuss@lists.ubuntu.com
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

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

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 br...@ubuntu.com 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/SponsorshipProcessto 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

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 
 sponsoredhttps://wiki.ubuntu.com/SponsorshipProcessto 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-sponsorshttps://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-main-sponsorsand
 universe-sponsorshttps://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 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 c...@teamcharliesangels.com:

 
  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

[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
 marco.pallo...@gmail.com 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 c...@teamcharliesangels.com:
  
  
   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

[C de-Avillez]

On 01/08/10 00:58, Marco Pallotta wrote:
 2010/1/7 Charlie Kravetz c...@teamcharliesangels.com:
   

 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

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: 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 cutpaste 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

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 marco.pallo...@gmail.com 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

[Evan]

On Thu, Jan 7, 2010 at 3:51 PM, John Moser john.r.mo...@gmail.com wrote:

 On Thu, Jan 7, 2010 at 6:53 AM, Marco Pallotta marco.pallo...@gmail.com
 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

[Charlie Kravetz]

On Thu, 7 Jan 2010 15:51:07 -0500
John Moser john.r.mo...@gmail.com wrote:

 On Thu, Jan 7, 2010 at 6:53 AM, Marco Pallotta marco.pallo...@gmail.com 
 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

[Marco Pallotta]

2010/1/7 Charlie Kravetz c...@teamcharliesangels.com:
 On Thu, 7 Jan 2010 15:51:07 -0500
 John Moser john.r.mo...@gmail.com wrote:

 On Thu, Jan 7, 2010 at 6:53 AM, Marco Pallotta marco.pallo...@gmail.com 
 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

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: 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

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 dylanmcc...@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: 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 dylanmcc...@gmail.com
 
 

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

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 chrisccoul...@ubuntu.com 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: 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!

[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

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: 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

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 cian...@di.unipi.it:
 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 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!

[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!

[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!

[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!

[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: 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

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: 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

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...

[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: 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

[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

[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

[scj]

Quoting Martin Pitt martin.p...@ubuntu.com:

 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

[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

[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 package (or ubuntu-bug
 PID) 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

[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: 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

[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

[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 package (or ubuntu-bug
PID) 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]

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 package (or ubuntu-bug
 PID) 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

[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 package (or ubuntu-bug
  PID) 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]

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: 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

[(``-_-´´) -- 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: 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

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?

https://bugs.launchpad.net/ubuntu/+source/virtualbox-ose/+bug/282379


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: How to push bugs upstream

[Dotan Cohen]

 2008/12/26 Markus Hitter m...@jump-ing.de:
 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


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

Re: How to push bugs upstream

[Charlie Kravetz]

On Fri, 26 Dec 2008 12:57:09 +0100
Markus Hitter m...@jump-ing.de 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: 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

[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

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: 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

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-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings

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:44:49AM +0100, Matthew Garrett wrote:
 On Mon, Sep 08, 2008 at 11:31:07AM +0200, Alexander Sack wrote:
  On Mon, Sep 08, 2008 at 12:26:50AM +0100, Matthew Garrett wrote:
   To be fair to NM, this is a Debian/Ubuntu integration issue. System-wide 
   configuration is present but requires a system-specific backend.
   
  
  NetworkManager has a distro independent system-wise backend called
  keyfile. And thats enabled by default in ubuntu. What isnt enabled
  by default yet is the legacy backend for /etc/network/interfaces, but
  that isnt the problem this is about afaict.
 
 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.

 - 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: Bugs for NM 0.7

[Matthew Garrett]

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.

-- 
Matthew Garrett | [EMAIL PROTECTED]

-- 
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

Re: Bugs for NM 0.7

[Matthew Garrett]

On Mon, Sep 08, 2008 at 11:31:07AM +0200, Alexander Sack wrote:
 On Mon, Sep 08, 2008 at 12:26:50AM +0100, Matthew Garrett wrote:
  To be fair to NM, this is a Debian/Ubuntu integration issue. System-wide 
  configuration is present but requires a system-specific backend.
  
 
 NetworkManager has a distro independent system-wise backend called
 keyfile. And thats enabled by default in ubuntu. What isnt enabled
 by default yet is the legacy backend for /etc/network/interfaces, but
 that isnt the problem this is about afaict.

The thread was discussing the removal of network-admin - doesn't that 
modify /etc/network/interfaces?

-- 
Matthew Garrett | [EMAIL PROTECTED]

-- 
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 12:26:50AM +0100, Matthew Garrett wrote:
 On Sun, Sep 07, 2008 at 10:27:10PM +0300, Peteris Krisjanis wrote:
 
  Btw, I haven't seen that system wide configuration on OpenSUSE and
  Fedora. I would like to see it in action. So far I am very nervous
  about ditching network-admin, because no matter how it was stuck in
  development, or it lacked features, it worked, it had over the
  distros feel and so far Network Manager  has been let's repeat
  PulseAudio all over the place. There should be very good
  network-admin and NM integration or at least NM should heavily improve
  their configuration dialogs and menus. Otherwise I still suggest to
  leave network-admin and work on NM to improve it to get it finally
  worthy to ditch good old g-s-t tool for good.
 
 To be fair to NM, this is a Debian/Ubuntu integration issue. System-wide 
 configuration is present but requires a system-specific backend.
 

NetworkManager has a distro independent system-wise backend called
keyfile. And thats enabled by default in ubuntu. What isnt enabled
by default yet is the legacy backend for /etc/network/interfaces, but
that isnt the problem this is about afaict.

 - 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: Bugs for NM 0.7

[Wouter Stomp]

On Fri, Sep 5, 2008 at 7:49 PM, Jordan Mantha [EMAIL PROTECTED] wrote:
 On Fri, Sep 5, 2008 at 9:24 AM, Peteris Krisjanis [EMAIL PROTECTED] wrote:
 Btw, a slight offtopic from this message, but does it mean that there
 will be no network-admin from g-s-t in Ibex?

 Would be very sad if that happened.

 It won't be installed by default. However, it is still in the archive
 in the gnome-network-admin package. NM 0.7 seems to have gotten to the
 place where it has basically all the same features so having 2 tools
 to do the same thing becomes an issue. I was really against removing
 the g-s-t network admin tool, but after using and testing NM 0.7 in
 Intrepid for a while I think it'll be a good move for users.

 -Jordan

Please replace this with something to configure the networkmanager
system wide configuration. Networkmanager has had this ability for a
while, and both fedora and opensuse support, but as far as I know
Ubuntu doesn't.

Wouter

-- 
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

[Peteris Krisjanis]

2008/9/7 Wouter Stomp [EMAIL PROTECTED]:
 On Fri, Sep 5, 2008 at 7:49 PM, Jordan Mantha [EMAIL PROTECTED] wrote:
 On Fri, Sep 5, 2008 at 9:24 AM, Peteris Krisjanis [EMAIL PROTECTED] wrote:
 Btw, a slight offtopic from this message, but does it mean that there
 will be no network-admin from g-s-t in Ibex?

 Would be very sad if that happened.

 It won't be installed by default. However, it is still in the archive
 in the gnome-network-admin package. NM 0.7 seems to have gotten to the
 place where it has basically all the same features so having 2 tools
 to do the same thing becomes an issue. I was really against removing
 the g-s-t network admin tool, but after using and testing NM 0.7 in
 Intrepid for a while I think it'll be a good move for users.

 -Jordan

 Please replace this with something to configure the networkmanager
 system wide configuration. Networkmanager has had this ability for a
 while, and both fedora and opensuse support, but as far as I know
 Ubuntu doesn't.

Btw, I haven't seen that system wide configuration on OpenSUSE and
Fedora. I would like to see it in action. So far I am very nervous
about ditching network-admin, because no matter how it was stuck in
development, or it lacked features, it worked, it had over the
distros feel and so far Network Manager  has been let's repeat
PulseAudio all over the place. There should be very good
network-admin and NM integration or at least NM should heavily improve
their configuration dialogs and menus. Otherwise I still suggest to
leave network-admin and work on NM to improve it to get it finally
worthy to ditch good old g-s-t tool for good.

Just my two cents,
Peter.

-- 
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

[Mackenzie Morgan]

On Sun, 2008-09-07 at 22:27 +0300, Peteris Krisjanis wrote:
 So far I am very nervous
 about ditching network-admin, because no matter how it was stuck in
 development, or it lacked features, it worked, 

It worked?  When?  I don't remember this.  Was this back during Breezy
or earlier?

Probably the first thing I installed on Dapper (when I started using
Linux) was NM because network-admin couldn't do WPA.  It's caught up as
far as WPA goes, but, in my experience at least, it doesn't really work.
Try connecting to a WEP network with network-admin.  Tell it to use
DHCP.  Guess what?  Still have to manually dhclient.  At least that's
been my experience with it.  Pretty sure you also have to run a sudo
iwlist wlan0 scan before using network-admin because it doesn't list
available networks either.  If you have to use the command line to find
the network and to get a DHCP lease...why even bother with the GUI?  I'm
not saying NM is perfect, of course; it still rejects all WEP keys if
you use an Intel wireless card (yes, bugs are filed, driver is being
blamed), but at least it can handle DHCP and show the available
networks!

-- 
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: Bugs for NM 0.7

[Matthew Garrett]

On Sun, Sep 07, 2008 at 10:27:10PM +0300, Peteris Krisjanis wrote:

 Btw, I haven't seen that system wide configuration on OpenSUSE and
 Fedora. I would like to see it in action. So far I am very nervous
 about ditching network-admin, because no matter how it was stuck in
 development, or it lacked features, it worked, it had over the
 distros feel and so far Network Manager  has been let's repeat
 PulseAudio all over the place. There should be very good
 network-admin and NM integration or at least NM should heavily improve
 their configuration dialogs and menus. Otherwise I still suggest to
 leave network-admin and work on NM to improve it to get it finally
 worthy to ditch good old g-s-t tool for good.

To be fair to NM, this is a Debian/Ubuntu integration issue. System-wide 
configuration is present but requires a system-specific backend.

-- 
Matthew Garrett | [EMAIL PROTECTED]

-- 
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 introduced in GCC?

[Richard M. Stallman]

In terms of actual volume of patches against upstream, and excluding SVN
updates, the diff from the base Debian 4.2.3-2 version and Ubuntu 8.04's
4.2.3-2ubuntu7 is about 40 KB.

 If so, what is it meant to change?

Matthias (CCed) should be able to give more information on any
particular patches that are of concern.

I didn't even imagine trying to read them myself!

It's just that the added bug (which I forwarded) made me worry.
I'm glad you are working on fixing this, and I hope you will
make a new release.

-- 
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