Re: Featured Apps for Natty

2011-04-20 Thread Michael Vogt
On Wed, Apr 20, 2011 at 10:04:49AM -0500, Jonathan Thomas wrote:
 Has there been any discussion on which featured apps will be showcased in
 the Software Center for 11.04?  If not, is it too late in the release cycle
 to update the list of applications before the release date?  I would of
 course like to suggest OpenShot be added to the
 featured applications, but I'm sure there are many other great applications
 that could and should be featured as well.

We had a very brief internal discussion about it and decided to tweak
the list a little bit, but did not change much. I don't do video
editing, but I would welcome suggestions, though we are pretty late
for natty unfortunately.


ubuntu-desktop mailing list

software-center and remove vs. purge

2010-12-07 Thread Michael Vogt

I recently came accross the following idea that
discusses remove vs purge in softare-center:
and I would like to discuss it here.

Let me briefly recap the difference between the two. The removal
means that the content of the package gets removed from the
filesystem. With purge the package content *and* the system config
files (usually in /etc) will get removed as well. Some package will
also do additional removal (like removing the mythtv-database content
when purging mythtv-database leading to people losing data).

This is not a easy problem and we need to carefully balance the needs
to keep the UI simple with the needs to keep the system from
accumulating cruft. There are good suggestions in the brainstorm
entry. I think that while in 99(,9 probably)% of all cases a purge is
fine the cost for the error in the remaining cases can be pretty high
(consider someone spending a lot of time tweaking their
squid.conf). So software-center errs on the safe side and defaults to
remove currently.

Its difficult to tell programmatically what is going to happen when
the maintainer script is called with purge as this is a shell
script. Our tools can estimate what amount of data the configuration
file was using (and even if the user ever modified it or not) but not
what additional steps the maintainer script will take (unless of
course there is not maintainer script or no purge target in it :)

That being said I think we should make it easy for the user to access
the purge functionality both inside software-center and
computer-janitor. For software-center I would like to add a option
(File/Remove with configuration). A alternative solution would be to
make purge the default and have a option File/Remove but preserve the
configuration). What do you think about what the default should be?
For most packages purge will be fine, its just the few ones where it
isn't that I'm concerned about.

For computer-janitor a plugin for packages that are removed but not
purged sounds appropriate. Combined with some intelligence about
detecting cases that a purge is harmless (like checking for purge as
a target on postrm and checking if the configuration file was actually
modified) we should get most packages right. With additional data like
looking at what date the package was removed we can get the remaining
ones right (i.e. if it was removed 3 month ago it probably is not
missed by the user).


ubuntu-desktop mailing list

[Bug 477127] Re: gnome-panel menu entry for software-center is missing

2010-03-08 Thread Michael Vogt
** Summary changed:

- menu for software-center is missing 
+ gnome-panel menu entry for software-center is missing

** Also affects: gnome-panel (Ubuntu)
   Importance: Undecided
   Status: New

gnome-panel menu entry for software-center is missing
You received this bug notification because you are a member of Ubuntu
Desktop, which is a bug assignee.

ubuntu-desktop mailing list

[Bug 405155] Re: No prompt to install codecs in totem-mozilla

2009-10-20 Thread Michael Vogt
Thanks for your bugreport.

I can not reproduce the issue that the totem plugin does not do a codec
search. For me it does and offers the right plugin packages.

** Summary changed:

- No prompt to install ubuntu-restricted-extras packages
+ No prompt to install codecs in totem-mozilla

** Changed in: gnome-codec-install (Ubuntu)
   Status: New = Incomplete

No prompt to install codecs in totem-mozilla
You received this bug notification because you are a member of Ubuntu
Desktop, which is a direct subscriber.

ubuntu-desktop mailing list

[Bug 349607] Re: Codec manager does not find bad codecs

2009-04-03 Thread Michael Vogt
I just tried this with some freely available xvid videos. It works ok
for me, if you have links (or could the videos that fail available for
me privately) I'm happy to have a second look.

Codec manager does not find bad codecs
You received this bug notification because you are a member of Ubuntu
Desktop, which is a direct subscriber.

ubuntu-desktop mailing list

Re: Desktop Team meeting, 2008-08-14

2008-08-15 Thread Michael Vogt
On Thu, Aug 14, 2008 at 03:19:28PM +0100, Matt Zimmerman wrote:
 On Thu, Aug 14, 2008 at 03:05:11PM +0100, Scott James Remnant wrote:
  == Automatic installation reports ==
  mvo asked how useful are the apt filed installation failed reports?
  Should we not file them against the failed package (e.g. gedit) but
  against a central virtual component (like install-failurs) because most
  likely the problem is not with gedit, but with e.g. scrollkeeper that is
  run in the gedit postinst? This way triaggers can pinpoint the problem
  and assign to the right packages.  I got some complaints that the apt
  bugreports clutter the buglists too much.
 I'm curious about this, because I (as a tester) find this facility very
 useful in reducing the time it takes to collect the relevant information,
 check for duplicates and file a bug.

 What is the clutter?  If it's duplicate bugs, apport could be more
 aggressive/smarter about suppressing duplicates.  If it's bugs reported
 against the wrong package, maybe we could improve the duplicate detection in

I personally like this feature. I think that each maintainer script
failure/install failure is a problem and that we should try harder to
prevent those. Ideally we would have a system in place that
automatically rolls back in case of errors to the original state. But
because this is currently not possible I think we need to try to make
the maintainer scripts as robust as possible. 

Let me summaize the discussion during the meeting. It was argued that
the reports clutter the bug list because:

1. the information is often not useful (postinst script failed with
   exit code 1 without further clues in the log
2. the bug gets assigned to the wrong package. most of the time its
   something in the postinst failing (e.g. scrollkeeper segfaulting) so
   the bug should be really on scrollkeeper, but it is first assigned
   to e.g. gedit because it happens to run scrollkeeper in its postinst
3. there is a lot of noise in the report, e.g. hardware problems
   (bad RAM) to cause some failure, customized systems that have
   random files removed (e.g. /etc/init.d/foo got removed and
   start-stop-daemon fails with a exit code) or simply the disk is
4. those are not bug reports but incident reports that can be turned
   into bugreports with manual labor (extract the right information

We discussed the following solutions:
- better client side filtering (e.g. don't report disk full errors)
- better server side filtering from the apport duplicate detector
- pushing all reports to a new pseudo package called
  install-failures and let the QA team triage those

I implemented some improvements to the client side filtering
(disk-full is filtered out now, better detection of folloup errors
directly in libapt) and I plan to discuss the install-failures
component with the qa team.

To get a better idea of the problem, I gathered some data from
launchpad and the apport-package tagged bugs there:

We currently have 2012 packages with the tag apport-package in
launchpad. Of these, 963 are open (not invalid, won't fix or fix
released). I looked at the most recent bugs to get a idea what
those are about and found:
(1) maintainer failure because of syntax error/incorrect use of
  programms/diverts: #258353, #257522, #257490, #257213, #257162,
  #257131, #257003, #256930, #254969
(2) file overwrite issues: #257736, #257299, #257244, #257133, #256743,
(3) pkgs/programms with default that cause the maintainer scripts to fail
  when they install: #258042, #257989, #257832, #257737, #257527,
  #257142, #257040, #256737, #256423
(4) local customization/hardware that causes breakage: #257989, #257745,
  #257375, #256987, #256968, #235164, #256461, #256276
(5) unknown: #257418, #257386, #256766, #256653, #256454, #256204, #256184

I made the classification up on the spot and ordered by usefulness
for us. Category 1 and 2 are bugs that can be fixed or at least
diagnosed with the information in the bugreports.

Category 3 is bad default or bad recovery from problematic
conditions. E.g. a package that needs to connect to a database fails
when it can't for some reason (wrong passowrd) instead of re-trying or
to write a debconf note that some more configuration is required. Or a
package like java-doc that prompts the user to download some files
into a location and will fail if those files are not available.

Category 4 is problematic, some stuff like pycentral not overwriting
local python files could be improved (or we could provide a way to
override this restriction on dist-upgrades). Some others like fork()
failures because of low mem are much harder to deal with (or
filesystem corruption).

Catgeory 5 are the ones that I found no useful information in. Stuff
like capplet-data postinst failed with error code 1 without any
further indication what went wrong.

From looking at this (unscientific) sample it seems like we have some
noise in the reports, but also 

Re: Turning the low disk space notifications back on

2007-11-13 Thread Michael Vogt
On Sat, Nov 10, 2007 at 12:00:19PM +0100, David Prieto wrote:
  and warning when your removable disk is getting full.
 Any chance to add a free space button that empies .Trash, there?

We discussed this at the ubuntu developer sumit and the plan is to add
a tool that helps freeing up space. The current draft can be found
under Some initial code
is available in the system-cleanup package/bzr tree.


ubuntu-desktop mailing list

Re: Team packages maintained in bzr, one branch for the team or one for each debian directory?

2007-07-31 Thread Michael Vogt
On Sat, Jul 28, 2007 at 05:28:35PM +0200, Sebastien Bacher wrote:
 We are looking at maintaining the ubuntu-desktop packages in bzr. The
 idea is to store the debian directories there and to use
 bzr-buildpackage and some other tools making the work easier.

 * One branch by package:
 + that's the clean way using bzr
 + you can checkout and look at updates for the packages you are
 interested in only
 - you need to checkout or update ~100 different branches when you work
 on all the packages
 - you need to branch for every package when gutsy+1 opens

I like this approach much better. One disadvantage here is that
launchpad requires a upstream product for each branch but there is no
mapping for every current source packages to a upstream products. So
some will have to be created first with the webgui in LP. Better
support from LP would be helpful here I think (either auto creating
upstream product or allowing bzr branches for source package names).


ubuntu-desktop mailing list