Re: [Merge] ~3v1n0/ubuntu/+source/gnome-software:ubuntu/bionic into ~ubuntu-desktop/ubuntu/+source/gnome-software:ubuntu/bionic

2019-08-14 Thread Robert Ancell
Review: Approve


-- 
https://code.launchpad.net/~3v1n0/ubuntu/+source/gnome-software/+git/gnome-software/+merge/358489
Your team Ubuntu Desktop is subscribed to branch 
~ubuntu-desktop/ubuntu/+source/gnome-software:ubuntu/bionic.

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


[Merge] ~vanvugt/ubuntu/+source/mutter:fix-1809407-eoan into ~ubuntu-desktop/ubuntu/+source/mutter:ubuntu/master

2019-08-05 Thread Robert Ancell
The proposal to merge ~vanvugt/ubuntu/+source/mutter:fix-1809407-eoan into 
~ubuntu-desktop/ubuntu/+source/mutter:ubuntu/master has been updated.

Status: Needs review => Rejected

For more details, see:
https://code.launchpad.net/~vanvugt/ubuntu/+source/mutter/+git/mutter/+merge/368536
-- 
Your team Ubuntu Desktop is requested to review the proposed merge of 
~vanvugt/ubuntu/+source/mutter:fix-1809407-eoan into 
~ubuntu-desktop/ubuntu/+source/mutter:ubuntu/master.

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


[Bug 1572456] Re: Software (gnome-software) icon shown twice inside Launcher

2017-08-30 Thread Robert Ancell
** Changed in: gnome-software (Ubuntu)
   Importance: Undecided => Low

-- 
You received this bug notification because you are a member of Ubuntu
Desktop, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1572456

Title:
  Software (gnome-software) icon shown twice inside Launcher

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1572456/+subscriptions

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Ubuntu Desktop default apps Wiki page

2017-08-08 Thread Robert Ancell
On Tue, Aug 8, 2017 at 6:33 PM Jean-Baptiste Lallement <
jean-baptiste.lallem...@canonical.com> wrote:

> Hi Robert,
>
> Le 08/08/2017 à 06:02, Robert Ancell a écrit :
> > Hi all,
> >
> > One thing that came out of discussions at GUADEC was a request that
> > Ubuntu ship the core GNOME apps. We've also had a few discussions
> > recently on this list about including some of these.
> >
> > I proposed that we should make a list of the reasons that we ship / do
> > not ship certain apps so it would be clear to everyone why this is the
> > case (and perhaps indicate any features that would make us change our
> > minds). Here it is:
> >
> > https://wiki.ubuntu.com/DefaultApps
> Thanks for making this list. In the criteria you mention "They are good
> quality apps" I think this criteria should be more detailed and the
> upstream QA process documented and linked. I propose to add the
> following information:
>   - There is a reliable test suite executed at least for every release.
>   - Description of the coverage of the test suite(s) (unit, functional,
> API, ...)
>   - The tests are executed at build time on all the arch we support and
> if not a rationale is provided to explain why some arch are excluded.
>   - autopkgtest are enabled and executed on Ubuntu releases against the
> actual binary packages.
>   - The test plan is documented.
>

I reverse-engineered the existing criteria but I agree we should be be more
stringent for new apps (as well as applying this over time to the existing
apps).

No opposition from me for you adding this.

--Robert
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Ubuntu Desktop default apps Wiki page

2017-08-08 Thread Robert Ancell
Thanks for the feedback Paul!

On Tue, Aug 8, 2017 at 5:16 PM Paul Smith <p...@mad-scientist.net> wrote:

> On Tue, 2017-08-08 at 04:02 +0000, Robert Ancell wrote:
> > I've tried to summarise the status quo - feedback / changes welcome!
>
> I didn't understand the gnome-boxes / Remmina comments on the wiki page.
>
> In the "Core Apps" section gnome-boxes is not included and it is not
> marked "Proposed for inclusion" but it does say "Replaces/will replace
> functionality in Remmina".
>

Sorry for the confusion.

It's not marked proposed for inclusion because no-one has (yet?) proposed
it here on the list. When we briefly looked at it at GUADEC the size was
too large. But if anyone thinks it should still be proposed please email
this list and update the Wiki page.

The note about replacing Remmina functions came out of a discussion at
GUADEC - apparently the upstream vision for the project is for Boxes to
completely cover both virtual machines and remote desktops. I don't believe
the remote desktop support is complete yet. But in the future it might be a
compelling replacement.

>
> Then in the "Other Default" section, Remmina is marked "Proposed for
> removal" saying it will be replaced by gnome-boxes.



> So I don't quite understand the state of these two.  Should "gnome-
> boxes" be marked as "Proposed for inclusion"?  Or are you proposing no
> remote desktop app installed in the base system?  I think that would be
> unfortunate as I think it's something people would expect to find these
> days, if it can be made to fit.
>

I've reworded this to hopefully be clearer. Note that the "proposed for
removal" links just means it's been brought up on this list, but doesn't
mean that proposal would be successful (someone will change it to "was
proposed for removal in 17.10" or similar at the conclusion of that
discussion).

Finally, as far as I can tell gnome-boxes doesn't support RDP (Windows
> Remote Desktop Protocol).  If true this means it's not useful to me as a
> replacement for Remmina.
>

I've linked to the RDP bug to be more specific.
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Default Apps: gnome-music and gnome-photos

2017-08-07 Thread Robert Ancell
There are two core GNOME apps that we do not currently ship:
- Photos (we have Shotwell instead)
- Music (we have Rhythmbox instead).

Based on in-person discussions it seems likely we will continue to ship our
existing apps for the immediate future because:
- These apps rely on Tracker, which has not been considered to work well in
Ubuntu (at least in the past?).
- The currently shipping apps work well and have more functionality.

Advantages to switching:
- The new apps fit better in with the GNOME style.
- They may have more developer focus in the future (Rhythmbox and Shotwell
may become less maintained).

My reading is most people are of the opinion we won't switch at this time,
but will re-assess at each Ubuntu release if things have changed. What do
others think?

Is there anything we can add to https://wiki.ubuntu.com/DefaultApps about
why these are not shipping by default?

--Robert
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Default App: GNOME Contacts

2017-08-07 Thread Robert Ancell
gnome-contacts is an address book and is part of the core GNOME apps. It
has all dependencies in main except for folks (which used to be in main).

While this seems to work well in managing your e-d-s based contacts, I'm
not sure if there's a particular use for it in Ubuntu. Address book
functionality seems tied to your email client of choice which is probably
Thunderbird (installed by default, has own tools) or an online service
(e.g. GMail, and also has own tools).

We should ship it by default or give a reason in
https://wiki.ubuntu.com/DefaultApps why it should not be included.

--Robert
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Default App: GNOME Characters

2017-08-07 Thread Robert Ancell
gnome-characters is a character browser and is part of the core GNOME apps.
All its dependencies are in main. It replaces the older gucharmap that we
continue to ship. gnome-characters has a GUI that fits in with the GNOME
style, while gucharmap has an old fashioned interface.

I found it simpler to find useful characters than gucharmap (which is more
of a Unicode browser) and the use of a Headerbar makes it more consistent
with the rest of the desktop.

We should ship it by default or give a reason in
https://wiki.ubuntu.com/DefaultApps why it should not be included.

--Robert
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Default App: GNOME To Do

2017-08-07 Thread Robert Ancell
gnome-todo is a task manager / note taker and is part of the core GNOME
apps. All its dependencies are in main.

We should ship it by default or give a reason in
https://wiki.ubuntu.com/DefaultApps why it should not be included.

--Robert
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Ubuntu Desktop default apps Wiki page

2017-08-07 Thread Robert Ancell
Hi all,

One thing that came out of discussions at GUADEC was a request that Ubuntu
ship the core GNOME apps. We've also had a few discussions recently on this
list about including some of these.

I proposed that we should make a list of the reasons that we ship / do not
ship certain apps so it would be clear to everyone why this is the case
(and perhaps indicate any features that would make us change our minds).
Here it is:

https://wiki.ubuntu.com/DefaultApps

I've tried to summarise the status quo - feedback / changes welcome!

Thanks,
--Robert
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Remove default app: xterm?

2017-07-23 Thread Robert Ancell
I know we previously had issues where gnome-terminal could fail to work
reliably under certain bad driver cases (it was the case for virtual
machines for some time). I think these issues haven't been a problem for
some time though.

+1 from me for removal.

On Sat, Jul 22, 2017 at 4:34 AM Bryan Quigley 
wrote:

> Xterm takes up two menu items (xterm and uxterm) and doesn't provide
> any more functionality then gnome-terminal.  In an installed setup,
> those two menu items make gnome-shell have 3 pages instead of 2 in my
> testing.
>
> The comment in seeds for adding it is "Provide a backup terminal and
> complete X env.":
>
> Backup terminal - I don't think we really need a backup and we don't
> do it for other apps.   There is always a VT and if someone wants to
> use a GUI they can install another terminal with gnome-software.
>
> complete X env.  -  Especially with us considering wayland, if it
> actually pulls in anything (that other packages don't) then we want to
> bring it in explicitly.
>
> Thanks!
> Bryan
>
> --
> ubuntu-desktop mailing list
> ubuntu-desktop@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
>
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Help verifying SRUs

2017-07-17 Thread Robert Ancell
Hi all,

I've got some SRUs that need verifying, if you have a few minutes could you
have a look and check if these work for you? If you can confirm these work
then change the tag on the bug from verification-needed-xenial to
verification-done-xenial (replace xenial with zesty when testing on 17.04).

GNOME Software (16.04 and 17.04):
https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1663097
https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1697565
https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1697565
https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1702122

snapd-glib (16.04 and 17.04):
https://bugs.launchpad.net/ubuntu/+source/snapd-glib/+bug/1646784
https://bugs.launchpad.net/ubuntu/+source/snapd-glib/+bug/1699005

appstream-glib (16.04 and 17.04):
https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1700994

Thanks,
--Robert
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Testing GNOME Software 3.20.5 in Xenial

2017-07-10 Thread Robert Ancell
Thanks for spotting that Amr! Fixed in 3.20.5-0ubuntu0.16.04.4

On Fri, Jul 7, 2017 at 8:56 PM Amr Ibrahim <amribrahim1...@hotmail.com>
wrote:

> I don't see any user reviews in gnome-software 3.20.5. Neither for
> installed nor non-installed applications. Does anyone have the same issue?
>
> On 07/07/17 04:20, Robert Ancell wrote:
>
> Thanks for testing everyone, I've now uploaded this to xenial-proposed to
> go through the SRU process.
>
> On Thu, Jul 6, 2017 at 12:34 AM Amr Ibrahim <amribrahim1...@hotmail.com>
> wrote:
>
>> Hallo,
>>
>> I am also testing gnome-software 3.20.5 in Xenial. It's working well so
>> far. In fact, I think it fixes this bug
>> https://bugs.launchpad.net/ubuntu/xenial/+source/wine1.6/+bug/1571816,
>> even though it was not affecting gnome-software in the first place.
>>
>> Regards,
>> Amr
>> --
>> ubuntu-desktop mailing list
>> ubuntu-desktop@lists.ubuntu.com
>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
>>
>
>
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Testing GNOME Software 3.20.5 in Xenial

2017-07-06 Thread Robert Ancell
Thanks for testing everyone, I've now uploaded this to xenial-proposed to
go through the SRU process.

On Thu, Jul 6, 2017 at 12:34 AM Amr Ibrahim 
wrote:

> Hallo,
>
> I am also testing gnome-software 3.20.5 in Xenial. It's working well so
> far. In fact, I think it fixes this bug
> https://bugs.launchpad.net/ubuntu/xenial/+source/wine1.6/+bug/1571816,
> even though it was not affecting gnome-software in the first place.
>
> Regards,
> Amr
> --
> ubuntu-desktop mailing list
> ubuntu-desktop@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
>
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Testing GNOME Software 3.20.5 in Xenial

2017-06-22 Thread Robert Ancell
Confirmed. The 3.20.1 -> 3.20.2 release changed the PackageKit plugin name
from "PackageKit" to "packagekit" and I didn't update the APT plugin. Fixed
in 3.20.5-0ubuntu0.16.04.1.1 in the PPA.

On Fri, Jun 23, 2017 at 3:42 AM Sebastien Bacher <seb...@ubuntu.com> wrote:

> Hey Robert,
>
> Le 18/06/2017 à 12:11, Robert Ancell a écrit :
> > If you are running Xenial I would love some testing of this from a PPA:
>
> I give it a go on my xenial/i386 installation and installing debs isn't
> working, clicking on the "install" button in the list of info page
> doesn't do anything (same action triggers the polkit auth dialog with
> the current xenial version)
>
> What I do exactly:
>
> - stop gnome-software
>
> - start a new instance
>
> - type "gtg" to find "get things gnome"
>
> - click "install" in the list result
>
> or
>
> - click on the item and then install on the gtg summary
>
>
> The behaviour is not specific to gtg, I tried some other debs and they
> behave the same. Downgrading to the active version makes it work again.
>
>
> The verbose log looks like that
>
>
> (gnome-software:21381): As-DEBUG: run
> 0xafc09830~GsPlugin::snap(gs_plugin_add_search;gs_plugin_refine)
> (gnome-software:21381): As-DEBUG: run
> 0xafc09830~GsPlugin::appstream(gs_plugin_add_search;gs_plugin_refine)
> (gnome-software:21381): As-DEBUG: run
> 0xafc09830~GsPlugin::moduleset(gs_plugin_add_search;gs_plugin_refine)
> (gnome-software:21381): As-DEBUG: run
>
> 0xafc09830~GsPlugin::hardcoded-blacklist(gs_plugin_add_search;gs_plugin_refine)
> (gnome-software:21381): As-DEBUG: run
> 0xafc09830~GsPlugin::apt(gs_plugin_add_search;gs_plugin_refine)
> (gnome-software:21381): GsPlugin-DEBUG: ignoring
> /usr/share/applications/gtg.desktop as does not exist
> (gnome-software:21381): Gs-DEBUG: gtg.desktop non-transient state now
> available
> (gnome-software:21381): As-DEBUG: run
>
> 0xafc09830~GsPlugin::menu-spec-refine(gs_plugin_add_search;gs_plugin_refine)
> (gnome-software:21381): As-DEBUG: run
> 0xafc09830~GsPlugin::icons(gs_plugin_add_search;gs_plugin_refine)
> (gnome-software:21381): As-DEBUG: run
> 0xafc09830~GsPlugin::provenance(gs_plugin_add_search;gs_plugin_refine)
> (gnome-software:21381): GsPlugin-DEBUG: prov: considering gtg.desktop
> (gnome-software:21381): GsPlugin-DEBUG: prov: GsApp:
>   kind:   desktop
>   compulsory: False
>   state:  available
>   id: gtg.desktop
>   kudo:   featured-recommended
>   kudo:   has-keywords
>   kudo-percentage:25
>   name:   Getting Things GNOME!
>   match-value:00118
>   version:0.3.1-3
>   update-version: 0.3.1-3
>   summary:Personal tasks and TODO-list items organizer for
> the GNOME desktop environment.
>   description:Getting Things GNOME! est un un organisateur pour
> le gestionnaire de bureau GNOME, GTG se concentre sur l'ergonomie et la
> facilité d'usage. Son principal objectif est de fournir un outil
> d'organisation simple, et donc flexible, pour la vie réelle et le travail.
>   provenance: yes
>   source-00:  gtg
>   license: href="http://www.ubuntu.com/about/about-ubuntu/licensing;>Libre
>   open source:yes
>   management-plugin:  packagekit
>   origin: ubuntu-xenial-universe
>   origin-ui:  Ubuntu
>   reviews:0
>   pixbuf: 0x8d0fe70
>   category:   Office
>   category:   ProjectManagement
>   keyword:Organizer
>   keyword:Task
>   keyword:Activity
>   keyword:Plan
>   keyword:Time
>
> (gnome-software:21381): As-DEBUG: run
> 0xafc097b0~GsPlugin::snap(gs_plugin_app_install)
> (gnome-software:21381): As-DEBUG: run
> 0xafc097b0~GsPlugin::apt(gs_plugin_app_install)
> (gnome-software:21381): As-DEBUG: run
> 0xafc097b0~GsPlugin::snap(gs_plugin_app_install;gs_plugin_refine)
> (gnome-software:21381): As-DEBUG: run
> 0xafc097b0~GsPlugin::appstream(gs_plugin_app_install;gs_plugin_refine)
> (gnome-software:21381): As-DEBUG: run
> 0xafc097b0~GsPlugin::moduleset(gs_plugin_app_install;gs_plugin_refine)
> (gnome-software:21381): As-DEBUG: run
>
> 0xafc097b0~GsPlugin::hardcoded-blacklist(gs_plugin_app_install;gs_plugin_refine)
> (gnome-software:21381): As-DEBUG: run
> 0xafc097b0~GsPlugin::apt(gs_plugin_app_install;gs_plugin_refine)
> (gnome-software:21381): GsPlugin-DEBUG: ignoring
> /usr/share/applications/gtg.desktop as does not exist
> (gnome-software:21381): As-DEBUG: run
>
> 0xafc097b0~GsPlugin::menu-spec-re

Re: Default App: GNOME Maps

2017-06-08 Thread Robert Ancell
On Fri, Jun 9, 2017 at 11:52 AM Sebastien Bacher <seb...@ubuntu.com> wrote:

> Hey there,
>
> Le 08/06/2017 à 23:52, Robert Ancell a écrit :
> > I'd like to propose GNOME Maps. This uses gjs so it is include-able
> > now gnome-shell is in main. Maps is a core GNOME app.
>
> Since we are copying the previous discussion ... how well is it
> maintained upstream and in Debian/Ubuntu (as well as its depends like
> libchamplain, geoclue?)? Does it have any know CVE?
>

Debian is using 3.22, we're using 3.24 so both distros are fairly up to
date with appropriate dependencies.

I think you mean gfbgraph not geoclue (already in main).

No CVE that I could find in any of those packages.


> It's worth looking at and could be a nice addition but I wonder how many
> users are going to use it rather that just opening google map in their
> webbrowser?
>

I was also thinking that. It's much like the email client case we have.
While I think a lot of users will use Google Maps in their browser, you can
still get a nicer experience with a local map app.

The one advantage of an app is offline map browsing. This was being worked
on [1] but I'm not sure of the current state of it.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=708799
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Default App: GNOME Maps

2017-06-08 Thread Robert Ancell
Jeremy pointed out that folks dropped out of main in artful, so that would
have to go back in.

On Fri, Jun 9, 2017 at 9:52 AM Robert Ancell <robert.anc...@canonical.com>
wrote:

> I'm going to copy Jeremy [1] and propose a new default app for 17.10...
>
> I'd like to propose GNOME Maps. This uses gjs so it is include-able now
> gnome-shell is in main. Maps is a core GNOME app.
>
> Mapping is a standard feature of modern operating systems. By including
> maps we also encourage Ubuntu users to improve OpenStreetMap and that
> aligns with our open-source culture.
>
> There are two Universe dependencies:
> - gfbgraph - A fairly simple wrapper library to access some Facebook
> services
> - libchamplain - Map rendering library, Reasonably complex but doesn't
> have any complex dependencies. Probably useful for other apps.
>
> --Robert
>
> [1] https://lists.ubuntu.com/archives/ubuntu-desktop/2017-June/004970.html
>
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Default App: gnome-sushi

2017-06-08 Thread Robert Ancell
On Fri, Jun 9, 2017 at 12:13 PM Jeremy Bicha <jbi...@ubuntu.com> wrote:

> On Thu, Jun 8, 2017 at 7:35 PM, Robert Ancell
> <robert.anc...@canonical.com> wrote:
> > The functionality of Sushi seems very good but the discoverability is
> > terrible. Has this been raised with upstream at all?
>
> Not that I'm aware of, but how would you make something like this more
> discoverable except install it by default and mention it as a feature?
>
> I was expecting the right click menu to have a "Preview" entry (i.e.
beside the open with entries) and spacebar would be a shortcut. It seems
you can only know this feature exists if you've read the docs / been told.

--Robert
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Default App: GNOME Maps

2017-06-08 Thread Robert Ancell
GNOME Maps has been a core app since GNOME 3.20

On Fri, Jun 9, 2017 at 9:52 AM Robert Ancell <robert.anc...@canonical.com>
wrote:

> I'm going to copy Jeremy [1] and propose a new default app for 17.10...
>
> I'd like to propose GNOME Maps. This uses gjs so it is include-able now
> gnome-shell is in main. Maps is a core GNOME app.
>
> Mapping is a standard feature of modern operating systems. By including
> maps we also encourage Ubuntu users to improve OpenStreetMap and that
> aligns with our open-source culture.
>
> There are two Universe dependencies:
> - gfbgraph - A fairly simple wrapper library to access some Facebook
> services
> - libchamplain - Map rendering library, Reasonably complex but doesn't
> have any complex dependencies. Probably useful for other apps.
>
> --Robert
>
> [1] https://lists.ubuntu.com/archives/ubuntu-desktop/2017-June/004970.html
>
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Default App: gnome-sushi

2017-06-08 Thread Robert Ancell
The functionality of Sushi seems very good but the discoverability is
terrible. Has this been raised with upstream at all?

On Fri, Jun 9, 2017 at 8:33 AM Jeremy Bicha  wrote:

> Now that gnome-shell is in the default Ubuntu 17.10 daily image, I
> think we could maybe start talking about other default apps. If we
> want new stuff in main, I think it's good to start the Main Inclusion
> process early.
>
> First, how about gnome-sushi? (Upstream's name is just 'sushi').
>
> Sushi is a file previewer for nautilus. It can be activated by
> pressing the spacebar when a file is selected. Sushi has been a part
> of core GNOME since GNOME 3.2. It is described in the default user
> help bundled with GNOME. [1]
>
> Sushi was never really considered for inclusion in Ubuntu's default
> install earlier because it uses gjs which was not desired in Ubuntu
> main until we needed GNOME Shell.
>
> There is one universe dependency: libmusicbrainz5. An earlier version
> of this library, libmusicbrainz3, was in main in Ubuntu 12.04 LTS.
>
> [1] https://help.gnome.org/users/gnome-help/stable/files-preview.html
> or you can run the installed version:
> yelp help:gnome-help/files-preview
>
> Thanks,
> Jeremy Bicha
>
> --
> ubuntu-desktop mailing list
> ubuntu-desktop@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
>
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Default App: GNOME Maps

2017-06-08 Thread Robert Ancell
I'm going to copy Jeremy [1] and propose a new default app for 17.10...

I'd like to propose GNOME Maps. This uses gjs so it is include-able now
gnome-shell is in main. Maps is a core GNOME app.

Mapping is a standard feature of modern operating systems. By including
maps we also encourage Ubuntu users to improve OpenStreetMap and that
aligns with our open-source culture.

There are two Universe dependencies:
- gfbgraph - A fairly simple wrapper library to access some Facebook
services
- libchamplain - Map rendering library, Reasonably complex but doesn't have
any complex dependencies. Probably useful for other apps.

--Robert

[1] https://lists.ubuntu.com/archives/ubuntu-desktop/2017-June/004970.html
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: lightdm or gdm?

2017-06-07 Thread Robert Ancell
Hi all,

Where we are today:
- GDM is undergoing a security check to be included in main [1].
- We've got GNOME Shell onto the 17.10 image, running under LightDM.
- We've attempted to get the GNOME Shell lock screen running with LightDM
and using GNOME Shell as a LightDM Greeter. Which this still seems
possible, it's not easy to patch GNOME Shell as the GDM code is hard to
decouple.
- Other tasks have left not much time to work on GNOME Shell / LightDM
integration.

When we started investigating LightDM with GNOME Shell we wanted to
re-assess after about a month and see if it was still worth continuing
with. That time is now.

Given the workload we have and the risks in modifying GNOME the decision is
to use GDM for 17.10 and thus 18.04 LTS.

Where this leaves LightDM:
- We continue to support LightDM for the supported Ubuntu releases.
- We will support LightDM for use in the other flavours, though this is
likely to be limited to bug fixes from the Ubuntu desktop team.
- Others are still welcome to contribute to LightDM.

Thanks,
--Robert

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

On Thu, Apr 20, 2017 at 2:32 AM Sebastien Bacher  wrote:

> Hey there,
>
> That's a topic that was mentioned during the meeting yesterday and
> something we need to decide on early in the cycle since there is going
> to be work needed on that front to have a fully working session.
>
> I'm doing a small summary of what I think are the pro (+) and con (-) of
> each
>
> * lightdm
>
> + well tested in Ubuntu
> + we have people in the team knowing the codebase
> + shared with other flavors/greeters selection
> + guest session
> - divergence from upstream
> - we are the maintainers so it's more work for us
> - gnome-shell uses gdm for its lockscreen so work is needed to make it
> work with lightdm
>
> * gdm
>
> + that's the GNOME solution, works today with wayland & gnome-shell
> - we started lightdm because we found the gdm codebase not easy to work
> on, that might still be true
> - ?keeps an active session from the greeter even after logging which
> uses resources? (it was mentioned on IRC, to be confirmed, is that
> needed due to the lockscreen?)
> - no guest session, we need to work on that or decide to drop the
> feature from Ubuntu
>
>
> I talked a bit with Robert yesterday who said he could make lightdm use
> the gdm greeter (he has some work started on that a few cycles ago)
> which means it could be used as GNOME lockscreen instead of gdm. He's
> probably the best placed to comment on the work and pro/con of the
> solutions though so I'm going to let him go into the details when he
> replies.
>
> Cheers,
> Sebastien Bacher
>
>
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Experience on switching to GNOME Shell

2017-05-17 Thread Robert Ancell
On Thu, May 18, 2017 at 1:42 PM Daniel van Vugt <
daniel.van.v...@canonical.com> wrote:

>
> So I would log enhancement ideas in launchpad, with some tag like
> 'gnome-18.04'...
> https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bugs
> But that's just me.
>
>
I agree logging things in Launchpad is useful, and there are certainly
obvious things on the list that I'll do that for. The problem with everyone
tagging things is we get a giant list of random bugs that aren't
necessarily common / worthwhile. This could be the first step though, and
the list then culled down.

I guess there's I'm looking for:
- Are there things that we have experienced in common that suggest they're
good things to fix?
- Are these things fixable by us?
- What is a realistic set of things we would like to be seen done by 18.04?

--Robert
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Look ahead at GNOME 3.26

2017-04-25 Thread Robert Ancell
On Tue, Apr 25, 2017 at 11:51 PM Martin Pitt  wrote:

>
> FTR, upstream systemd is currently converting to meson [1], and we
> successfully
> run builds of it both in Debian unstable as well as in Ubuntu 16.04 with
> ninja+meson backports [2]. Not having debhelper support is not a big
> blocker --
> either we could just upload and use debhelper git master, or directly call
> meson in debian/rules, as we did in the systemd package for now [3].
>
>
I just updated simple-scan in Artful, which is a simple case of using meson:
http://bazaar.launchpad.net/~ubuntu-desktop/simple-scan/ubuntu/view/head:/debian/rules

--Robert
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: lightdm or gdm?

2017-04-21 Thread Robert Ancell
On Sat, Apr 22, 2017 at 8:56 AM Bryan Quigley 
wrote:

>
> Lastly, I wanted to know if there are any security differences in how
> the login/lock screens work?
> Specifically:
> Is their a process I can kill from a user session to break the lock?
> If I'm able to crash the lock screen, is the user session destroyed or
> unlocked?
> Which would be easier to add functionality to block new USB
> drives/other devices from being connected when the screen is locked?
>
>
I'm not 100% familiar with the source but as I understand it gnome-shell is
the lock screen, so killing the lock screen could only be done by killing
the whole shell. A bug in the lock screen code will cause the session to be
unlocked. This is the same behaviour as Unity since Yakkety (I think?).

--Robert
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: lightdm or gdm?

2017-04-20 Thread Robert Ancell
On Fri, Apr 21, 2017 at 12:57 AM Tim  wrote:

>
>
> On 20/04/17 00:32, Sebastien Bacher wrote:
> > - gnome-shell uses gdm for its lockscreen so work is needed to make it
> > work with lightdm
> That is not entirely right, the GUI for gdm is actually a cut-down
> gnome-shell session, this applies to both lock screen and greeter. gdm
> does however handle all user authentication, which is a little different
> from how lightdm work afaict (Robert correct me on this If I am wrong).
>
>
Support for allowing lock screens to do authentication was added in LightDM
1.20 and Unity used this (i.e. the same as the GDM lock screen). Running a
cut-down gnome-shell session is no different from runing any greeter (Unity
Greeter was effectively a cut-down Unity session with a simple shell).

--Robert
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: lightdm or gdm?

2017-04-19 Thread Robert Ancell
On Thu, Apr 20, 2017 at 3:58 AM Jeremy Bicha  wrote:

> On Wed, Apr 19, 2017 at 10:32 AM, Sebastien Bacher 
> wrote:
> > - gnome-shell uses gdm for its lockscreen so work is needed to make it
> > work with lightdm
>
> Generally, lightdm works with GNOME, but it hasn't been tested much so
> it sometimes take a while before bugs are noticed and fixed. Here's
> some lightdm with GNOME bugs I just learned about:
>
> https://launchpad.net/bugs/1632772 (No Wayland support)
> https://launchpad.net/bugs/1684205 (Missing lock button)
>


LightDM has supported Wayland since 1.16 (Ubuntu 15.10). This has however
not been actively used or enhanced by me due to the conflict of interest
with the development of Mir. Now we are using Wayland on the desktop I
expect to be much more involved in this feature.

--Robert

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: lightdm or gdm?

2017-04-19 Thread Robert Ancell
Thanks Seb,

= Disclaimer =

Firstly, I should disclose my interests - I am the founder and maintainer
of LightDM. I'll try and minimise any biases I might have. Ultimately I
want the best outcome and I'm happy with either way we go as long as it
makes sense.

= History (simplified) =

In the beginning there was one Display Manager - XDM. Various desktops
forked this project to produce their own display managers that displayed
appropriate UI for their desktop (e.g. Qt on KDE with KDM, GTK+ on GNOME
with GDM).

LightDM was started for two reasons:
- We were having quality / maintenance issues with GDM in Ubuntu. GDM was
highly complex.
- None of the display managers allowed you to change greeter technology
outside of a bit of themeing.

The goal was to have a common display manager daemon (LightDM) and allow
each desktop to develop their own greeter against a stable greeter API
(liblightdm).

Ubuntu switched to LightDM in 11.10 and developed Unity Greeter. I gave up
pushing LightDM in GNOME (which I regret) amidst the Unity-GNOME flamewars.
KDE came super close to picking LightDM as a replacement for KDM with a
huge list of positives (including having the second most active LightDM
developer being from KDE). The major point against it was the CLA. That was
very disappointing. Most of the small desktops seem to have chosen LightDM
and seem quite happy with it.

= Pros and cons =

In addition to Seb's list:

* LightDM
+ an extensive test suite that contains 370 test cases. The test cases run
a full LightdDM setup and simulate all components.
+ a sophisticated configuration system that allows packagers and sysadmins
to override configuration. Some sysadmins may have work in switching from
LightDM to GDM (I can't quantify how significant this is).
+ Extensive logging that helps in debugging issues.
+ Support for greeters in multiple languages / platforms (C, Qt, Python etc
via GIR, Vala).
+ VNC support.
+ Remote login support (this has not been used for sometime and may or may
not be useful in the future).
+ Support for Mir (I don't know if this is important anymore, but dropping
LightDM would mean no DM supports it).

* GDM
- no significant tests (make check runs one thing from 2007)

= My conclusion =

My preference is to continue with LightDM for the following reasons:
- I think the tests and features of LightDM are superior to GDM (I could be
biased here).
- To switch would create some work for sysadmins who use existing features.
- I think the amount of work to get LightDM to work with GNOME Shell is
roughly equivalent to getting new features into GDM.
- LightDM is not an enormous amount of work to maintain - it's quite mature.
- If we were to stop developing LightDM this would be a huge loss to the
community outside of GNOME. Being used across various projects means we
have a larger pool of developers testing and fixing bugs. I'll have to
defer to my manager(s) to decide if this investment / divergence is
considered worth it.
- We always have the option of switching to GDM in the future if we want
to, the switch back would be harder.

Finally a clarification - when you refer to "LightDM" this never means any
UI that you see (LightDM is a daemon and contains no UI code). So
continuing with LightDM does not mean using Unity Greeter. The Unity
Greeter code has bitrotted to such a point we clearly would not use it (it
was to be replaced with Unity8 Greeter).

--Robert

On Thu, Apr 20, 2017 at 2:32 AM Sebastien Bacher  wrote:

> Hey there,
>
> That's a topic that was mentioned during the meeting yesterday and
> something we need to decide on early in the cycle since there is going
> to be work needed on that front to have a fully working session.
>
> I'm doing a small summary of what I think are the pro (+) and con (-) of
> each
>
> * lightdm
>
> + well tested in Ubuntu
> + we have people in the team knowing the codebase
> + shared with other flavors/greeters selection
> + guest session
> - divergence from upstream
> - we are the maintainers so it's more work for us
> - gnome-shell uses gdm for its lockscreen so work is needed to make it
> work with lightdm
>
> * gdm
>
> + that's the GNOME solution, works today with wayland & gnome-shell
> - we started lightdm because we found the gdm codebase not easy to work
> on, that might still be true
> - ?keeps an active session from the greeter even after logging which
> uses resources? (it was mentioned on IRC, to be confirmed, is that
> needed due to the lockscreen?)
> - no guest session, we need to work on that or decide to drop the
> feature from Ubuntu
>
>
> I talked a bit with Robert yesterday who said he could make lightdm use
> the gdm greeter (he has some work started on that a few cycles ago)
> which means it could be used as GNOME lockscreen instead of gdm. He's
> probably the best placed to comment on the work and pro/con of the
> solutions though so I'm going to let him go into the details when he
> replies.
>
> Cheers,
> Sebastien 

Re: Proposal: (No?) email client for Ubuntu 17.10

2017-04-18 Thread Robert Ancell
On Wed, Apr 19, 2017 at 10:34 AM Dimitri John Ledkov 
wrote:

> On 18 April 2017 at 21:07, Jeremy Bicha  wrote:
> >
> > If we do include an email client, which one?
>
> I am worried about this, especially in the enterprise environment
> people do want to access corporate mail.
>

My guess is most enterprises add/change the default apps as part of their
provisioning. So I think not having one by default will not be an issue for
them. Bryan made a good point though that perhaps we should have one in
main that is supported.
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


GUADEC 2017 talk submissions close 23rd April

2017-04-18 Thread Robert Ancell
Hi all,

Given the recent Ubuntu desktop changes I suspect we'll have some people
attending GUADEC 2017 [1] this year. The talk submissions close 23rd April
(i.e. in four days). Not sure if anyone knows yet if they'll be there / has
something appropriate Ubuntu / GNOME related they can write up in the next
few days.

--Robert

[1] https://2017.guadec.org/
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Proposal: (No?) email client for Ubuntu 17.10

2017-04-18 Thread Robert Ancell
I'm supportive of not including an email client by default given the
current selection. If there was a light-weight client available with good
features (e.g. Geary) I think there would be a decision but the listed
candidates are too big / old.

I think if there's no client though there should be good support for
handling mailto: links - i.e. either we have common web mail provider
support (e.g. Gmail) installed by default or at least a good dialog to help
you redirect to your provider when you click on these links.

--Robert

On Wed, Apr 19, 2017 at 8:08 AM Jeremy Bicha  wrote:

> In 2011, we switched Ubuntu's default email client from Evolution to
> Thunderbird. Six years later, I think it's time to take another look.
>
> Should we even install an email client by default? The question is not
> whether it's useful, but whether it's useful enough to enough people
> to justify it being installed for everyone.
>
> - Ubuntu GNOME 16.10 included Evolution but 17.04 has no email client
> installed at all. The decision disappointed a few people but there
> hasn't been much negative feedback at all yet.
>
> - GNOME Release Team member Michael Catanzaro recommends not
> installing an email client by default since there isn't an app that is
> both well-maintained and very well-integrated into the GNOME 3 style.
> [1]
>
> - It's believed that most people just use web mail now, often along
> with apps on their smart phone.
>
> - A problem is that those who do prefer to use an installed email
> client do not all prefer the same one!
>
> If we do include an email client, which one?
>
> Thunderbird (TB)
> -
> 1. TB is still built with GTK2.
> 2. TB is a community project now and Mozilla no longer pays developers
> to work on it.
> 3. It looks like TB will have a lot of work to do next year once
> Firefox drops traditional extension support with FF57. This work might
> be shared with other apps that use Mozilla code.
> 4. TB does not integrate with GNOME Online Accounts.
> 5. TB has better Unity integration than Evolution.
> 6. There was a proposal a year and a half ago to turn TB into a web
> app but I don't think that went anywhere. [2]
>
> Evolution
> --
> 1. The UI doesn't fully embrace GNOME3 app design style, but it is
> closer than TB.
> 2. Small development team.
> 3. Evolution is not available on other operating systems.
> 4. Evolution is relatively easy to co-maintain with Debian.
>
> [1] https://blogs.gnome.org/mcatanzaro/2016/09/21/gnome-3-22-core-apps/
> [2] https://groups.google.com/forum/#!topic/tb-planning/h97q9cDUZOU
>
> Thanks,
> Jeremy Bicha
>
> --
> ubuntu-desktop mailing list
> ubuntu-desktop@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
>
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Does GNOME Software run lintian against third-party debs before installing them?

2016-04-03 Thread Robert Ancell
It does not, please file a bug if you think that is required.

On Sun, Apr 3, 2016 at 12:34 AM Amr Ibrahim 
wrote:

> Hello everyone,
>
> Does GNOME Software run lintian against third-party debs before
> installing them? I think Ubuntu Software Center used to do that.
>
> Running lintian warns users from installing sloppy debs and push
> third-parties to clean their Debian packaging.
>
> Thanks,
>
> Amr
> --
> ubuntu-desktop mailing list
> ubuntu-desktop@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
>
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


GNOME Software in 16.04 LTS

2016-01-15 Thread Robert Ancell
Hi all,

As you may be aware, we're currently looking at switching from Ubuntu
Software Center to GNOME Software for Ubuntu 16.04 LTS [1].

If you're interested in playing around / helping out:
- I've set up a ppa:ubuntu-desktop/gnome-software [2] for which currently
holds PackageKit 1.0 and GNOME Software with some patches to support the
Ubuntu review server. Installing this will boot out software-center /
aptdaemon.
- We're blocked from pushing this directly to the Xenial archive [3] - but
we hope to have some progress on that soon.
- The GNOME software work is being done upstream in GNOME git. It should be
upstreamable.
- Please file bugs against the gnome-software package [4]
- I'm still working on the Ubuntu One support for posting reviews - ideally
this would use libaccounts but that doesn't seem to be working in desktop
Ubuntu anymore. Any help here would be appreciated. Plan B is to put the
account signup UI in GNOME Software (not too hard, but would be nicer to
use the proper services).
- I've tagged some bugs on things that need working on [5].
- The appstream data is being worked on - I'll let Iain Lane update about
that.

Have fun!
--Robert

[1]
http://www.omgubuntu.co.uk/2015/11/the-ubuntu-software-centre-is-being-replace-in-16-04-lts
[2] https://launchpad.net/~ubuntu-desktop/+archive/ubuntu/gnome-software
[3] https://bugs.launchpad.net/bugs/+bug/1470655
[4] https://bugs.launchpad.net/ubuntu/+source/gnome-software/+filebug
[5] https://bugs.launchpad.net/bugs/+bugs?field.tag=gnome-software-ubuntu
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Drop Ubuntu Software Centre and Adopt GNOME Software

2015-08-11 Thread Robert Ancell
For us to use GNOME Software we probably want to update to the latest
version [1]. That's currently blocked because it needs PackageKit 1.0 [2].
And that's blocked until we get a Click update. If anyone knows more
migration issues please add information to those bugs. I suspect we might
also need some work in aptdaemon - please comment if you know.

--Robert

[1] https://bugs.launchpad.net/bugs/1470656
[2] https://bugs.launchpad.net/bugs/1470655

On Wed, Aug 12, 2015 at 1:40 AM Sebastien Bacher seb...@ubuntu.com wrote:

 Le 30/07/2015 19:13, Amr Ibrahim a écrit :
  I suggest putting a roadmap for this to see if it's possible or not.

 Hey Amr,

 Having a roadmap and people interested in working on the transition
 seems like a good first step!

 Before suggesting a replacement the alternative should be proved to be
 good enough, which means identifying the gaps and working on resolving
 those.

 If you/others start working on that please share the wiki document on
 the list so others can look at it and maybe help/contribute

 Cheers,
 Sebastien Bacher

 --
 ubuntu-desktop mailing list
 ubuntu-desktop@lists.ubuntu.com
 https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


[Bug 1378188] Re: [GNOME3 Staging PPA] strange shadow rendered where client-side decorations are used

2015-02-01 Thread Robert Ancell
** Changed in: xserver-xorg-video-intel (Ubuntu)
   Status: Confirmed = Triaged

** Changed in: xserver-xorg-video-intel (Ubuntu)
   Importance: Low = Medium

-- 
You received this bug notification because you are a member of GNOME3
Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1378188

Title:
  [GNOME3 Staging PPA] strange shadow rendered where client-side
  decorations are used

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1378188/+subscriptions

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


[Bug 1378188] Re: [GNOME3 Staging PPA] strange shadow rendered where client-side decorations are used

2015-02-01 Thread Robert Ancell
** Description changed:

- When using apps where client-side decorations are being used, a strange
- shadow render appears below the window. Screenshots are attached. If
- CSDs are not being used, then shadows are rendered correctly.
+ [Impact]
+ The Intel video driver has a bug that can cause to incorrectly draw certain 
trapezoids. This is visible when using client side decorations in GNOME 3 (see 
attached screenshots).
  
- WORKAROUND: Remove the GNOME3 Staging PPA.
+ [Test Case]
+ Run GNOME 3 with client side decorations on Intel hardware.
+ Observed result:
+ Shadow under window is missing corners.
+ Expected result:
+ Shadow looks correct.
  
- ProblemType: Bug
- DistroRelease: Ubuntu 14.10
- Package: mutter 3.14.0-1ubuntu1~utopic1 [origin: 
LP-PPA-gnome3-team-gnome3-staging]
- ProcVersionSignature: Ubuntu 3.16.0-20.27-generic 3.16.3
- Uname: Linux 3.16.0-20-generic x86_64
- ApportVersion: 2.14.7-0ubuntu3
- Architecture: amd64
- CurrentDesktop: GNOME
- Date: Mon Oct  6 22:50:17 2014
- InstallationDate: Installed on 2014-06-13 (115 days ago)
- InstallationMedia: Ubuntu-GNOME 14.04 LTS Trusty Tahr - Release amd64 
(20140416.2)
- ProcEnviron:
-  TERM=xterm
-  PATH=(custom, no user)
-  XDG_RUNTIME_DIR=set
-  LANG=en_US.UTF-8
-  SHELL=/bin/bash
- SourcePackage: mutter
- UpgradeStatus: Upgraded to utopic on 2014-10-03 (3 days ago)
- ---
- ApportVersion: 2.14.7-0ubuntu8
- Architecture: amd64
- CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
- CompositorRunning: None
- CurrentDesktop: GNOME
- DistUpgraded: 2014-10-03 08:48:19,347 DEBUG enabling apt cron job
- DistroCodename: utopic
- DistroRelease: Ubuntu 14.10
- DistroVariant: ubuntu
- DkmsStatus:
-  vboxhost, 4.3.16, 3.13.0-35-generic, x86_64: installed
-  vboxhost, 4.3.16, 3.16.0-20-generic, x86_64: installed
-  vboxhost, 4.3.16, 3.16.0-21-generic, x86_64: installed
-  vboxhost, 4.3.16, 3.16.0-25-generic, x86_64: installed
- ExtraDebuggingInterest: Yes, if not too technical
- GraphicsCard:
-  Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics  Display 
[8086:0f31] (rev 0c) (prog-if 00 [VGA controller])
-    Subsystem: Acer Incorporated [ALI] Device [1025:0845]
- InstallationDate: Installed on 2014-06-13 (171 days ago)
- InstallationMedia: Ubuntu-GNOME 14.04 LTS Trusty Tahr - Release amd64 
(20140416.2)
- MachineType: Acer E1-510P
- Package: xorg 1:7.7+7ubuntu2
- PackageArchitecture: amd64
- ProcEnviron:
-  TERM=xterm
-  PATH=(custom, no user)
-  XDG_RUNTIME_DIR=set
-  LANG=en_US.UTF-8
-  SHELL=/bin/bash
- ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.16.0-25-generic.efi.signed 
root=UUID=87cb643d-4e85-4be4-9864-0e13b0ed0382 ro quiet splash acpi_osi=Linux 
i915.invert_brightness=1 vt.handoff=7
- ProcVersionSignature: Ubuntu 3.16.0-25.33-generic 3.16.7
- Tags: third-party-packages utopic gnome3-ppa ubuntu
- Uname: Linux 3.16.0-25-generic x86_64
- UpgradeStatus: Upgraded to utopic on 2014-10-03 (59 days ago)
- UserGroups: adm cdrom dip libvirtd lpadmin plugdev sambashare sudo vboxusers
- _MarkForUpload: True
- dmi.bios.date: 04/07/2014
- dmi.bios.vendor: Acer
- dmi.bios.version: V2.11
- dmi.board.name: E1-510P
- dmi.board.vendor: Acer
- dmi.board.version: V2.11
- dmi.chassis.type: 10
- dmi.chassis.vendor: Acer
- dmi.chassis.version: Chassis Version
- dmi.modalias: 
dmi:bvnAcer:bvrV2.11:bd04/07/2014:svnAcer:pnE1-510P:pvrV2.11:rvnAcer:rnE1-510P:rvrV2.11:cvnAcer:ct10:cvrChassisVersion:
- dmi.product.name: E1-510P
- dmi.product.version: V2.11
- dmi.sys.vendor: Acer
- version.compiz: compiz N/A
- version.ia32-libs: ia32-libs N/A
- version.libdrm2: libdrm2 2.4.56-1
- version.libgl1-mesa-dri: libgl1-mesa-dri 10.3.0-0ubuntu3
- version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
- version.libgl1-mesa-glx: libgl1-mesa-glx 10.3.0-0ubuntu3
- version.xserver-xorg-core: xserver-xorg-core 2:1.16.0-1ubuntu1
- version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.9.0-1ubuntu2
- version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.4.0-2ubuntu2
- version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.914-1~exp1ubuntu4.1
- version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 
1:1.0.11-1ubuntu2
- xserver.bootTime: Mon Dec  1 22:16:33 2014
- xserver.configfile: default
- xserver.errors:
- 
- xserver.logfile: /var/log/Xorg.0.log
- xserver.outputs:
-  product id4588
-  vendor AUO
- xserver.version: 2:1.16.0-1ubuntu1
+ [Regression potential]
+ Low. The fix is from upstream and just changes the logic error in the 
CompositeTrapezoids routine.

-- 
You received this bug notification because you are a member of GNOME3
Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1378188

Title:
  [GNOME3 Staging PPA] strange shadow rendered where client-side
  decorations are used

To manage notifications about this bug go to:

[Bug 1378188] Re: [GNOME3 Staging PPA] strange shadow rendered where client-side decorations are used

2015-02-01 Thread Robert Ancell
The patch looks good to me and the package builds fine. I haven't
uploaded since there's currently 2:2.99.914-1~exp1ubuntu4.2 waiting for
verification in utopic-proposed.

-- 
You received this bug notification because you are a member of GNOME3
Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1378188

Title:
  [GNOME3 Staging PPA] strange shadow rendered where client-side
  decorations are used

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1378188/+subscriptions

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


[Bug 1400002] Re: Sync gnome-mines 1:3.14.1-2 (main) from Debian unstable (main)

2014-12-07 Thread Robert Ancell
We can't do this until we have gnome-themes-standard 3.14 and that
requires GTK+ 3.14 (see bug 1399046)

-- 
You received this bug notification because you are a member of Ubuntu
Desktop, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/142

Title:
  Sync gnome-mines 1:3.14.1-2 (main) from Debian unstable (main)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-mines/+bug/142/+subscriptions

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


[Bug 1338801] Re: Update to 3.14

2014-12-03 Thread Robert Ancell
** Changed in: gnome-screenshot (Ubuntu)
 Assignee: (unassigned) = Artur Rona (ari-tczew)

** Changed in: gnome-screenshot (Ubuntu)
   Status: Confirmed = In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Desktop, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1338801

Title:
  Update to 3.14

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-screenshot/+bug/1338801/+subscriptions

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Please test lightdm stable release 1.10.2 in trusty

2014-09-17 Thread Robert Ancell
Hi all,

I've just uploaded LightDM 1.10.2 [1] to the ubuntu-desktop PPA so it
can have some early testing. This release backports a number of
important features but shouldn't change any behaviour by default.
Please let me know if anyone finds any problems!

Thanks,
-_Robert

[1] https://launchpad.net/lightdm/+milestone/1.10.2

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Why do we have the glade-3 (glade 3.8) package?

2014-09-01 Thread Robert Ancell
Does anyone know why we still have the glade-3 package in the archive?
This just seems to be to support an old version of glade (3.8), is
that still necessary?

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Ubuntu 14.10 onwards: Convergence is coming...

2014-04-15 Thread Robert Ancell
On Tue, Apr 15, 2014 at 8:37 PM, Adam Dingle a...@medovina.org wrote:
 If you replace all these apps with something else, I think that will be the
 largest change in Ubuntu's history - most of these apps have been around
 since the dawn of time and are very familiar to Ubuntu users.  I'd go so far
 as to say that the new desktop would be pretty much unrecognizable to
 existing users, for better or for worse.

I agree this is an enormous change but the reality of what convergence
means. We want the same apps to run on the phone as the desktop so
when you dock your phone the apps work in both form factors.

What's crucially important is that we start working on getting them
desktop capable so we're not changing everything at the point of
convergence. We need to follow something like:
1. Getting the app to run on the desktop
2. Getting the app to have appropriate functionality for a desktop use case
3. Promoting the app as an alternative
4. Making the app a default
The majority of this work will probably be done by each app
development team, not necessarily the desktop team. We do want to make
sure this is progressing however.

If we can chip away at these the migration will not be so sudden,
though LTS-LTS upgraders will probably see huge changes.

I'm not proposing any specific apps to change, just the ones that
become viable alternatives. The existing apps still remain in the
repository of course. I imagine by convergence not all apps will be
changed unless someone is motivated to make a (better) Ubuntu SDK
alternative. Also, if solutions appear that make apps suitable in
their current form they may not need to be replaced at all.

--Robert

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Ubuntu 14.10 onwards: Convergence is coming...

2014-04-14 Thread Robert Ancell
With 14.04 wrapping up it's time to start thinking about what we can
do with the desktop post LTS. I think there's one big theme we need to
focus on - Convergence. All the Unity 8 goodness that is going into
the phone / tablet builds is coming our way and we need to be prepared
for that migration.

These are some tasks I think we could achieve between now and convergence:

Task: Deprecate gnome-session
gnome-session used to be the root process for a session. Now we have
upstart/systemd that should be the root process. So no need for
gnome-session.

Task: Put screensaver management into the shell.
We currently use gnome-screensaver but upstream has deprecated it. We
replaced the first part of this in 14.04 by using the shell to render
the lock screen. We should be able to get rid of all of
gnome-screensaver now.

Task: Put PolicyKit handling into the shell.
We use policykit-gnome for the dialogs but GNOME uses the shell for
this. We should be doing the same. A nice to have would be to
implement this in both Unity 7 and Unity 8 but as long as it is there
by convergence then we're good to go.

Task: Gut unity-settings-daemon
We forked gnome-settings-daemon so we could stick with the version we
have currently. Now we should start pulling out the plugins and
migrating to the new services (e.g. power). Any remaining services
need to be rehomed / made into standalone services. By convergence
there should not be u-s-d anymore.

Task: Make Ubuntu System Settings [1] desktop capable
ubuntu-system-settings doesn't cover a lot of the use cases that
unity-control-center does. So we should add functionality to
ubuntu-system-settings so that it first a capable alternative to u-c-c
then eventually can completely replace it.

Task: Replace core apps
Help get core apps in a state so that they can replace our current
defaults. Candidates are things like calculator, file manager.

Are there any other good opportunities for us to start tackling?

--Robert

[1] https://launchpad.net/ubuntu-system-settings

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Call for testing - unity-control-center (fork of gnome-control-center so we can stay on an old version)

2014-02-20 Thread Robert Ancell
Here is an update on the unity-control-center / unity-settings-daemon migration:

- unity-control-center has been the default for some time now and all
major packages have been updated to use it when appropriate. Please
make sure to file any bugs against any applications that still try and
call gnome-control-center (or don't when they should). If you are
using a standard Ubuntu desktop you can uninstall gnome-control-center
now.

- unity-settings-daemon has been available for a few weeks and has
just been switched to the default. You should be able to uninstall
gnome-settings-daemon on a standard Ubuntu desktop. Please look out
for bugs!

- gnome-session has been split into gnome-session (containing the
GNOME X session) and ubuntu-session (containing the Unity X session).
You should be able to uninstall gnome-session on a standard Ubuntu
desktop.

IMPORTANT NOTE

If you uninstalled ubuntu-desktop at some point then nothing will
depend on ubuntu-session at the moment. So make sure you have
ubuntu-session installed or install ubuntu-session manually otherwise
you might not be able to log into Unity from the greeter. We are going
to have unity depend on ubuntu-session temporarily to catch this case
but long term this dependency will go away. People upgrading using the
GUI will not have this problem as the upgrader always ensures
ubuntu-desktop is installed.

Thanks for testing
--Robert

On Wed, Dec 11, 2013 at 5:42 PM, Robert Ancell
robert.anc...@canonical.com wrote:
 Hi all,

 Ubuntu makes use of a heavily patched gnome-control-center (61 patches) and
 we will in future move to the new Ubuntu System Settings [1] once we achieve
 convergence. We are already running an old version of gnome-control-center
 (3.6) and the value for Ubuntu in upgrading this is low since it would take
 a lot of work to update our changes. Running an old version until
 convergence blocks those who do use GNOME (i.e. Ubuntu GNOME).

 For these reasons it has been discussed that we should fork
 gnome-control-center 3.6 for Unity into unity-control-center [2].

 To be very clear, this is a fork with a limited lifespan. We don't expect to
 make significant changes to it outside of stability and security fixes.

 This change affects a number of packages, and I have attempted to find and
 fix all the side-effects (See bug 1257505 [3]). The proposed changes are in
 a PPA [4].

 Please test this PPA and post any problems in the bug report. I'd like to
 land this change into the archive if there are no reasons to block it.

 I also have a fork of gnome-settings-daemon for the same reasons which I am
 running successfully, I will do a similar call for testing when we have
 landed the control center changes.

 Thanks,
 --Robert

 [1] https://launchpad.net/ubuntu-system-settings
 [2] https://launchpad.net/ubuntu-control-center
 [3]
 https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1257505
 [4] https://launchpad.net/~ubuntu-desktop/+archive/unity-control-center

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Call for testing - unity-control-center (fork of gnome-control-center so we can stay on an old version)

2013-12-18 Thread Robert Ancell
Hi all,

Thanks for the testing.

I've updated the PPA, could you please purge this PPA [1] and reinstall it
and see if any problems remain for anyone?

There does seem to be reports of some translations not being there, but I
can't find any that aren't in unity-control-center now. Not sure if there's
some bad interaction with the existing language packs.

--Robert

[1] $ sudo ppa-purge ppa:ubuntu-desktop/unity-control-center


On Wed, Dec 11, 2013 at 5:42 PM, Robert Ancell
robert.anc...@canonical.comwrote:

 Hi all,

 Ubuntu makes use of a heavily patched gnome-control-center (61 patches)
 and we will in future move to the new Ubuntu System Settings [1] once we
 achieve convergence. We are already running an old version of
 gnome-control-center (3.6) and the value for Ubuntu in upgrading this is
 low since it would take a lot of work to update our changes. Running an old
 version until convergence blocks those who do use GNOME (i.e. Ubuntu GNOME).

 For these reasons it has been discussed that we should fork
 gnome-control-center 3.6 for Unity into unity-control-center [2].

 To be very clear, this is a fork with a limited lifespan. We don't expect
 to make significant changes to it outside of stability and security fixes.

 This change affects a number of packages, and I have attempted to find and
 fix all the side-effects (See bug 1257505 [3]). The proposed changes are in
 a PPA [4].

 Please test this PPA and post any problems in the bug report. I'd like to
 land this change into the archive if there are no reasons to block it.

 I also have a fork of gnome-settings-daemon for the same reasons which I
 am running successfully, I will do a similar call for testing when we have
 landed the control center changes.

 Thanks,
 --Robert

 [1] https://launchpad.net/ubuntu-system-settings
 [2] https://launchpad.net/ubuntu-control-center
 [3]
 https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1257505
 [4] https://launchpad.net/~ubuntu-desktop/+archive/unity-control-center

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Call for testing - unity-control-center (fork of gnome-control-center so we can stay on an old version)

2013-12-11 Thread Robert Ancell
On Wed, Dec 11, 2013 at 9:12 PM, Martin Pitt martin.p...@ubuntu.com wrote:

 Robert Ancell [2013-12-11 17:42 +1300]:



  Please test this PPA and post any problems in the bug report. I'd like to
  land this change into the archive if there are no reasons to block it.

 The upgrade went fine, and it replaced most of the
 gnome-control-center* packages with the unity-* counterparts, except
 for gnome-control-center-data

 It seems to me that if we want to add a real gnome-control-center,
 -data should be migrated as well? Or does u-c-c not need this at all?
 (Then it should be cleaned up on upgrade, or get owned by the real
 g-c-c)


u-c-c doesn't need this package. It is only depended on by
gnome-control-center. The only way that it will be removed is by an apt-get
autoremove right?


 After upgrading, the menu entry from the session indicator doesn't
 work. This needs a pkill -f indicator-session-service or a reboot;
 could the pkill perhaps be put into the postinst?


The System Settings menu item? I guess we should prompt a restart after
installing unity-control-center as all in-memory apps will try and launch
gnome-control-center instead of unity-control-center.


 The new control-center window is too wide, but this is probably
 related to the transition to GTK 3.10, not due to u-c-c itself.


I believe so - it used to work fine before the GTK 3.10 upgrade.


 Many entries are now untranslated, I guess this also changed the
 translation domain? Can we copy the translations from g-c-c, so that
 they get imported into LP?


I copied all the translations from g-c-c and I'm currently merging in
https://translations.launchpad.net/ubuntu/saucy/+source/gnome-control-center-unity/+pots/gnome-control-center-unity-
are there any others that I don't know of? In particular, I couldn't
seem
to find any Ubuntu specific translations for gnome-control-center.
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Call for testing - unity-control-center (fork of gnome-control-center so we can stay on an old version)

2013-12-10 Thread Robert Ancell
Hi all,

Ubuntu makes use of a heavily patched gnome-control-center (61 patches) and
we will in future move to the new Ubuntu System Settings [1] once we
achieve convergence. We are already running an old version of
gnome-control-center (3.6) and the value for Ubuntu in upgrading this is
low since it would take a lot of work to update our changes. Running an old
version until convergence blocks those who do use GNOME (i.e. Ubuntu GNOME).

For these reasons it has been discussed that we should fork
gnome-control-center 3.6 for Unity into unity-control-center [2].

To be very clear, this is a fork with a limited lifespan. We don't expect
to make significant changes to it outside of stability and security fixes.

This change affects a number of packages, and I have attempted to find and
fix all the side-effects (See bug 1257505 [3]). The proposed changes are in
a PPA [4].

Please test this PPA and post any problems in the bug report. I'd like to
land this change into the archive if there are no reasons to block it.

I also have a fork of gnome-settings-daemon for the same reasons which I am
running successfully, I will do a similar call for testing when we have
landed the control center changes.

Thanks,
--Robert

[1] https://launchpad.net/ubuntu-system-settings
[2] https://launchpad.net/ubuntu-control-center
[3]
https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1257505
[4] https://launchpad.net/~ubuntu-desktop/+archive/unity-control-center
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Call for Testing: Mir multi-monitor

2013-08-26 Thread Robert Ancell
Instructions are here:
http://unity.ubuntu.com/mir/debug_for_xmir.html

But in short, first look at /var/log/lightdm/lightdm.log and then
/var/log/lightdm/unity-system-compositor.log and /var/log/Xorg.0.log if the
lightdm.log indicates there is a problem with either.

--Robert


On Tue, Aug 27, 2013 at 2:20 PM, Robert Park robert.p...@canonical.comwrote:

 On Mon, Aug 26, 2013 at 2:10 PM, Nicholas Skaggs 
 nicholas.ska...@canonical.com wrote:

 The Mir team is calling for a round of testing for Mir and multi-monitor
 support specifically starting today through August 28th. Help us during
 this round of testing to make sure Mir and features are thoroughly tested
 on as many devices as possible.


 Eh, i can't get this working? I added the PPA, added the apt pref,
 dist-upgraded, installed unity-system-compositor, rebooted (all as per the
 instructions), and unity-system-compositor is not running. Is there a log
 file somewhere that might explain why it isn't running? What steps should I
 take to troubleshoot this?

 --
 ubuntu-desktop mailing list
 ubuntu-desktop@lists.ubuntu.com
 https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Update on the new ibus-1.5 and gnome-settings-daemon gnome-control-center 3.6 situation

2012-11-20 Thread Robert Ancell
On 21/11/12 07:13, Sebastien Bacher wrote:
 Hey,

 I've been looking at the new ibus/g-s-d/g-c-c stack recently to update
 in raring and I'm not convinced it's a good idea to update to those.
 We have discussed the issue a bit on IRC today but I figured I would
 write an email to the list to document and share the thinking.

 There seem to be several annoying issues with the new ibus/GNOME
 keyboard stack.

 The most annoying one is the drop of the Separate layout per window
 feature. That feature might come back at some point but it's not in
 GNOME 3.6 and still is on need for design upstream so we shouldn't
 hold on it for this cycle.

 The new ibus is having the same issue...


 Some pointers on discussion around those topics:

 * https://bugzilla.gnome.org/show_bug.cgi?id=684210 - 'Separate
 layout per window' is missing
 upstream discussion on the feature being dropped

 * http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692424 -
 the bug is about some ubuntu ibus packaging fixes but it turned into a
 discussion between the ibus maintainers about the new ibus version,
 they don't consider it ready for end users

 *
 https://lists.ubuntu.com/archives/ubuntu-desktop/2012-October/004014.html
 One discussion on the ibus topic we had early on this list


 Note that no major distribution has been released yet with that new
 stack (Debian has it in experimental only and the Debian ibus
 maintainer seem to have issues with the new version, the OpenSuse
 maintainer seem to have concern about it as well and it's not decided
 if they will ship it for their next version due in march, fedora 18
 will have it but it has been delayed to january) which means the new
 stack didn't get much of real world feedback yet, I don't think we
 should be in the first one to push it.

 Based on that it seems a safer bet to stay on the current ibus until
 we know better were things are going.

 Our options, if we stay on the current ibus, are:
 - stay on g-s-d/g-c-c 3.4 (the current version)
 - update g-s-d/g-c-c to 3.6 fully using the upstream code without
 building with ibus (they have a fallback mode without ibus
 integration), that's not going to restore the 'Separate layout per
 window' option but would avoid the ibus issues at least. We will need
 to update our keyboard indicator still if doing that
 - update g-s-d/g-c-c to 3.6 and revert the keyboard changes (e.g go
 back to the 3.4 codebase for the region panel and the g-s-d keyboard
 handling). If we do that we avoid the need to get the keyboard
 indicator this cycle

 There are good reasons to not keep delaying the g-s-d/g-c-c updates so
 I would try to avoid 1 and would suggest to start with 2 and see what
 issues we get from it and what we can build from there. We can then
 consider doing the extra work to add the missing bits then or go for 3
 and revert the 3.6 keyboard change.

 Note that option 2 and 3 might have an impact on the replace
 language-selector by the region capplet work, especially if we go
 back to the 3.4 codebase on that panel, we might want to postpone that
 work for yet another cycle in that case...

 That's my thinking on the topic ... comments are welcome as usual ;-)

 Cheers,
 Sebastien Bacher


I think option 3 is our best bet if it's feasible to revert the ibus
changes easily. This way we can solve all the other merging issues
immediately and then move to 2 if we can get it working in time for
release (my guess is this wont happen).

--Robert

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: [Desktop13.04-Topic] GNOME plans review

2012-10-17 Thread Robert Ancell
On 17/10/12 18:25, Allison Randal wrote:
 On 10/16/2012 03:56 PM, Robert Ancell wrote:
 My point is we *shouldn't* take the time to update Debian as it is all
 cost and no benefit. If you think of Debian as being directly upstream
 from Ubuntu it sounds good but in reality it is a more sidestream. If
 it is outdated in Ubuntu we should update it in Ubuntu and if Debian
 also wants the update they should merge our changes across as we do the
 other direction. The most appropriate person to decide if the changes
 are appropriate is a Debian developer, not an Ubuntu developer.
 No benefit is a pretty serious overstatement. Debian has ~2000
 volunteer packagers who maintain the majority of packages available in
 Ubuntu, with automated imports. Ubuntu has ~200 volunteer packagers who
 mostly work with forward-porting small deltas to the Debian packages
 that can't be automatically merged, or making sure Ubuntu integrates the
 latest security fixes from Debian/upstream.

 And then there's a small set of packages that are custom to Ubuntu or
 heavily modified for Ubuntu. For this last set, I agree, it is more work
 to port the changes back to Debian, and the changes don't always make
 sense for Debian to apply. But, spending a bit of time considering
 Debian even for these odd packages is a small price to pay for the
 vast benefit we get from Debian overall.

 You probably spend most of your time in this last set of packages, so I
 understand where your perspective comes from. But, it's important to
 keep the wider context in mind.

 Allison

Note that here we are discussing GNOME packages, though I would assert
this statement is true for pretty much all the packages that make up the
Ubuntu Desktop image (i.e. the packages that are most crucial to us).
The time taken to ensure synchronisation and the additional work ensure
those changes are in Debian has a non-significant cost but little to no
benefit to us (because we are unlikely to ever be synchronised).

The GNOME packages that are not on the image or any other package for
that matter, sure, the majority of them come from Debian. And that is of
great benefit to us.

Iain's original statement was that since we can't be in sync with GNOME
then we should try and be more in sync with Debian. And it's that I
disagree with - there are no great GNOME packaging improvements flowing
from Debian to Ubuntu and we should focus on making our packages high
quality and updating them faster. If anyone wants to push our changes
back into Debian or a Debian developer pull them that is a good thing
but it should be done in parallel and not block our progress.

--Robert




-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Collaboration with Debian [was: Re: [Desktop13.04-Topic] GNOME plans review]

2012-10-17 Thread Robert Ancell
On 17/10/12 18:02, Martin Pitt wrote:
 Robert Ancell [2012-10-17 10:48 +1300]:
 - By updating packages in Debian and waiting for them to flow down to
 Ubuntu kills our velocity. It can change the time from upstream release
 to being in Ubuntu from hours (which is too long in my opinion) to days.
 Yes, I agree that this is an issue at times. It usually works
 reasonably well for me to upload a new version to Debian and fakesync
 it into Ubuntu at the same time, but I have (1) DD upload powers and
 (2) everything set up to build packages for Debian, which is not true
 for the majority of Ubuntu Desktop developers.

 However, at the same time I strongly believe that directly working
 on Debian's packaging VCSes has some major benefits: Technically we
 avoid duplicate work and potential conflicts (such as naming new
 packages slightly differently, or a bug fix independently done on both
 sides works in a different way/with different API), and socially it's
 a great way of giving something back to Debian in return for having
 Debian do the vast majority of work of building Ubuntu. It also avoids
 the need of having to wade through large and mostly pointless merge
 deltas every so often, a work that nobody is really very fond of.

 Would an acceptable compromise be to commit fixes and new releases to
 Debian's GNOME svn, but then just do  a -Nubuntu1 upload from those,
 at least for the packages which we want to keep in sync by and large?

 Martin

I'm always hesitant to commit to a Debian repository since I don't run
Debian my changes are never going to be tested properly.

As you state, no-one likes to wade through the deltas and in my
experience after doing that no real benefit is gained. The changes
mostly come down to build-dependencies and addition/removal of patches
(which are put into/come from upstream bug/git). It is faster to compare
the upstream tarball changes than doing the merge from Debian.

So what I suggest we do is admit merge bankruptcy. If the attempt to
be in synchronisation is not bringing us more up to date or higher
quality packages (I'll assert it's having the opposite effect) then we
should stop trying to do it.

Note of course this doesn't stop changes flowing back from Ubuntu to
Debian if anyone wants to do that - we just shouldn't be using it as a
criteria to judge the quality of our packages.

--Robert


-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: [Desktop13.04-Topic] GNOME plans review

2012-10-16 Thread Robert Ancell
On 16/10/12 23:47, Sebastien Bacher wrote:
 Le 16/10/2012 06:08, Jeremy Bicha a écrit :
 On 15 October 2012 13:50, Sebastien Bacher seb...@ubuntu.com wrote:
 That's going to be a controversial topic but I want to suggest we
 stay on
 stable GNOME this cycle, the reasons are (in random order):
 Well you've been following GNOME development for longer than many of
 us. What is it that's making GNOME 3 releases more unstable than GNOME
 used to be? Is it just that GNOME development has sped up and the
 developers don't care enough about API stability?
 I think there a different factors there:

 - we never had great quality, Ubuntu is trying to address that and aim
 at better testing, less bugs, no regression, etc where GNOME didn't
 make that shift (yet?)

 - GNOME2 has been less dynamic than GNOME3  (at least the 2.n
 version during the Ubuntu time, which was not the start of the 2
 serie, by then things were already settled down and in maintenance
 mode) which also made for less breakages

 - GNOME started to focus on GNOME OS and give less importance to
 what distributors think or do. It's a fair choice, they think they
 should better focus on building the best system they can do and should
 not compromise to accommodate others. I'm not even sure they see
 distributors as partners or if they just aim at deprecating those by
 shipping GNOME OS directly...

From what I have gathered GNOME OS is a number of things:

- It's about standardising the stack from the kernel to the
applications. This is mostly a non-issue for Ubuntu as the stack that is
being standardised on is pretty much what we have in Ubuntu. There is a
mismatch if GNOME standardises on systemd and we continue with upstart,
but from what I understand about the technical differences the issues
are being exaggerated and it is not something we can't solve.

- It's about making GNOME testable [1]. It has been (correctly)
identified that through distributors GNOME cannot ensure a consistent
experience. In advisor board discussions at GUADEC it was suggested that
perhaps the GNOME OS term should be dropped and Testable used instead
due to the confusion surrounding GNOME OS. Testable is obviously a great
thing for Ubuntu in that it will hopefully improve quality (so Seb GNOME
is making that shift now) and allow people to run the Vanilla GNOME at
any point.

- Part of standardising the stack is increasing the scope of what GNOME
is. So there's experimentation going on around packaging and user
feedback which is the bread and butter of the traditional distributions.
This seems like it could be a challenge for us, but it's too early to
see where these experiments are going.

- There's a logical conclusion that once you have Testable complete then
that is a distribution. I get the impression that this is what some
people want to go to but I've heard no actual strategy on how this will
be a success for GNOME. I think this idea is built on the naive idea
that you build the perfect OS the users will come. It would be suicide
for GNOME to ruin their current distributor relationships at this point
unless there was a strong chance of this succeeding and I haven't seen
anything close to that.

In conclusion I don't think we have anything to be worried about with
GNOME OS at this point and by the time it did matter we may be
sufficiently different anyway that it doesn't matter.

--Robert

[1] https://live.gnome.org/GnomeOS/Testable


-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: [Desktop13.04-Topic] GNOME plans review

2012-10-16 Thread Robert Ancell
On 16/10/12 22:36, Iain Lane wrote:
 Given the way that both projects are now design led, and the fact that
 it's design decisions / philosophies that are driving many of these
 difficulties, it would seem prudent for the respective design teams to
 try to work together a bit more closely. I wonder if we can facilitate
 something here, either at UDS depending on the people there or
 elsewhere.
It would be good to keep communication lines open here. I don't think
there's going to be any meaningful Unity influence on GNOME as their
focus is on things working with GNOME but we need to make sure that
GNOME apps can work effectively in Ubuntu by making Unity handle them
correctly. In terms of Ubuntu Design wanting to modify GNOME packages we
do have to go to GNOME first as it's unsustainable to make the changes
with Ubuntu engineering and then expect them to go upstream easily.
 Back to the initial proposal quoted above. My initial reaction was that
 I disliked it because my philosophy that I generally prefer to work as
 close to upstreams as possible so that we can have a more productive
 feedback loop when it comes to bugs and features. But it seems that
 perhaps this is slightly broken for us, so neither party is getting much
 benefit out of it. A benefit would be that tracking stable series lets
 us work more closely with our other big upstream, Debian. We might be
 able to reduce our deltas there quite a lot if we're tracking the same
 stuff.
I really question the idea that Debian is an upstream to us in the
traditional sense. I see Debian as more of a sidestream project that
we can transfer work between.

Things that I think are bad about our close dependency on Debian:
- We have wildly different release schedules and quality standards which
means packages are constantly diverging
- By updating packages in Debian and waiting for them to flow down to
Ubuntu kills our velocity. It can change the time from upstream release
to being in Ubuntu from hours (which is too long in my opinion) to days.
- Debian carries a number of patches that have no relevance to Ubuntu
(e.g. Hurd patches). This just complicates the packaging.
- By leaving some packages to be fully maintained by Debian we easily
end up shipping old packages without noticing it. I was quite shocked
when I updated the version tracker [1] how many out of date packages we
ship. If we're going to ship a quality product we really should be more
aware of the code we ship.

I don't think any of the above is likely to change at any point so I
think the best way of reducing the delta is to not have a delta on our
core packages (i.e. don't try and be in sync at all). The current work
to be in sync is not really benefiting us or Debian and the more
important upstream is the software author not Debian.

Where we do need to be in sync:
- Platform behaviour (e.g. library compatibility) so Universe continues
to work (though I hope Universe will disappear at some point nullifying
this).
- Package naming. This is a problem that's getting worse not better with
extras.ubuntu.com and the like.

--Robert

[1] http://people.canonical.com/~platform/desktop/versions.html


-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: [Desktop13.04-Topic] GNOME plans review

2012-10-16 Thread Robert Ancell
On 17/10/12 11:28, Ma Xiaojun wrote:

 - By leaving some packages to be fully maintained by Debian we easily
 end up shipping old packages without noticing it. I was quite shocked
 when I updated the version tracker [1] how many out of date packages we
 ship. If we're going to ship a quality product we really should be more
 aware of the code we ship.
 The page you mentioned is nice.
 There ain't no such thing as a free lunch.
 If a Ubuntu contributor/developer find something outdated in Debian,
 she should help Debian as well as Ubuntu.
 If you want a more updated upstream, consider Arch?

My point is we *shouldn't* take the time to update Debian as it is all
cost and no benefit. If you think of Debian as being directly upstream
from Ubuntu it sounds good but in reality it is a more sidestream. If
it is outdated in Ubuntu we should update it in Ubuntu and if Debian
also wants the update they should merge our changes across as we do the
other direction. The most appropriate person to decide if the changes
are appropriate is a Debian developer, not an Ubuntu developer.

We don't need to switch from Debian to Arch as we don't need any
particular packaging. If you look at the versions page you see we
already maintain the majority of packages in Ubuntu anyway.



-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: [Desktop13.04-Topic] Default file manager

2012-10-14 Thread Robert Ancell
On 14/10/12 08:33, Dylan McCall wrote:
 Before talking about file managers, people should talk about how Unity
 fits with the direction GNOME applications are going. Because that is
 the problem: Unity has a very different vision for how applications
 should work than the GNOME project, which it depends on for
 applications and development tools. I think there needs to be a
 detailed plan for how Ubuntu is going to solve that problem with
 upstream. Barring that, there needs to be some consensus around why
 solving it upstream is unacceptable. Without that understanding, I
 think it would be impossible to make an informed decision on what to
 do about Nautilus. Dylan 

Even worse, we don't even have a definition of what a Unity application
is. So upstreams can never really tell if they are excluding their
applications from use in Unity and how do we determine if an upstream
fits? Note that GNOME has a similar problem in that a GNOME3 app is not
clearly defined (yet) so there is quite some divergence in designs.

--Robert

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: [Desktop13.04-Topic] Drop gconf from the default installation

2012-10-14 Thread Robert Ancell
On 09/10/12 03:58, Sebastien Bacher wrote:
 It seems we could finally get ride of libgconf2-4 users next cycle

That would be a great package to finally bury :) +100


-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: System compositor progress

2012-07-13 Thread Robert Ancell
On 14/07/12 03:49, John Lenton wrote:
 On Wed, Jul 11, 2012 at 7:04 AM, Robert Ancell
 robert.anc...@canonical.com wrote:
 Hi,

 We're now at the point where the system compositor [1] is starting to
 work. Any brave souls who want to start playing with this can have a
 look at the instructions in the blueprint. Obviously THIS IS HIGHLY
 EXPERIMENTAL, so play at your own risk! In saying that, early feedback
 is most welcome and anyone who wants to hack on this contact Chris
 (RAOF) and I and we can point you at code to play with.
 should this work for people who have full-disc encryption?
 (loath i am to try it if not...)
Full disk encryption should not affect it, but it has not been
explicitly tested.


-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: System compositor progress

2012-07-12 Thread Robert Ancell
On 12/07/12 23:00, Jonas Platte wrote:
 Am 12.07.2012, 06:58 Uhr, schrieb Christopher James Halse Rogers
 r...@ubuntu.com:

 On Wed, 2012-07-11 at 18:04 +1200, Robert Ancell wrote:
 Hi,

 We're now at the point where the system compositor [1] is starting to
 work. Any brave souls who want to start playing with this can have a
 look at the instructions in the blueprint. Obviously THIS IS HIGHLY
 EXPERIMENTAL, so play at your own risk! In saying that, early feedback
 is most welcome and anyone who wants to hack on this contact Chris
 (RAOF) and I and we can point you at code to play with.


 This is now ready to roll, for intel, nouveau, and radeon. Intel is most
 tested, and should essentially work; nouveau and radeon are less tested.

 amd64 packages of weston are still publishing: you need at least
 0.89.0~system-compositor4-0~raof3.

 Other than that, go to town!

 Chris

 I tried installing the system compositor, but lightdm doesn't start if
 I have type=weston set under [SetDefaults]. Should I now open a bug
 in lightdm or in weston?

Open bugs against LightDM with your logs from /var/log/lightdm and we
will reassign if required.

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


System compositor progress

2012-07-11 Thread Robert Ancell
Hi,

We're now at the point where the system compositor [1] is starting to
work. Any brave souls who want to start playing with this can have a
look at the instructions in the blueprint. Obviously THIS IS HIGHLY
EXPERIMENTAL, so play at your own risk! In saying that, early feedback
is most welcome and anyone who wants to hack on this contact Chris
(RAOF) and I and we can point you at code to play with.

--Robert

[1]
https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-system-compositor

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


[Desktop 12.10 Topic] System compositor

2012-04-19 Thread Robert Ancell
Hi,

A change I'd like to make for 12.10 is to use a compositor to control
video from boot to shutdown.

This gives us the following benefits:
- We can have smooth transitions from the splash screen to the greeter
to the session and back again
- We don't use VT switching anymore which has been shown to be problematic
- We use one consistent monitor layout for all stages of the boot
- We can use the greeter as the lock screen (couldn't get it to work
this cycle for the above reasons)
- We can ensure that you can never accidentally switch to a locked session
- We can show the greeter while the session loads

The technology used will probably be Wayland, and in some ways this
change is to implement the Wayland Tech Preview that was proposed for
Precise [1].

Note that not all video drivers will support this, and we will continue
to support the current system for those that do not support it
(primarily the nvidia driver).

--Robert

[1]
https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-wayland-tech-preview

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


[Bug 676578] Re: Support projects, not just Ubuntu packages

2012-01-17 Thread Robert Ancell
** Changed in: launchpad-integration
   Status: New = Triaged

** Changed in: launchpad-integration (Ubuntu)
   Status: Confirmed = Triaged

** Changed in: launchpad-integration
   Importance: Undecided = Wishlist

** Changed in: launchpad-integration (Ubuntu)
   Importance: Undecided = Wishlist

-- 
You received this bug notification because you are a member of Ubuntu
Desktop, which is the registrant for launchpad-integration.
https://bugs.launchpad.net/bugs/676578

Title:
  Support projects, not just Ubuntu packages

To manage notifications about this bug go to:
https://bugs.launchpad.net/launchpad-integration/+bug/676578/+subscriptions

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Login and lock screen dialog should be the same

2011-12-07 Thread Robert Ancell

On 07/12/11 21:49, Steffen Holanger wrote:

Hi.
I posted this idea on brainstorm. 
http://brainstorm.ubuntu.com/idea/28767/
I was told to forward it to this mailing list. The description of the 
problem/idea is in the link.

Cheers
Steffen



That is the plan for 12.04:
https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-lock-screen
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


[Desktop12.04-Topic] Handling Failure Gracefully

2011-10-25 Thread Robert Ancell
Late topic...

In the real world there are always going to be failures, triggered by
things like software bugs, hardware failures and misconfiguration. 
Ubuntu should where possible handle common failures and provide
predictable feedback to the user that the system is broken.

I think we have the intention that most of this should work already, but
it would be good to check we've worked out the right failures to handle
and to methodically test they all work in 12.10.

Some common failure cases and what should happen:
- Failure to start X server - Run failsafe X server
- Failure to start any X server - Show error on text console
- Failure to start greeter - Run X server with error message
- Failure to start session - Return to greeter with error message
- Failure of compiz/unity during session - restart compiz/unity
- Failure to start application - show error message
- ...

--Robert


-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: [Desktop12.04-Topic] Wayland tech preview

2011-10-07 Thread Robert Ancell
On 06/10/11 18:35, Bryce Harrington wrote:
 On Wed, Oct 05, 2011 at 03:33:32PM +1100, Robert Ancell wrote:
 It would be nice to be able to optionally run Wayland in 12.04 to try
 out the technology.  This will involve:
 - Modifying LightDM to support Wayland
 - Writing a Wayland compositor
 Would the demo compositor be sufficient?  If not, what additional
 capabilities did you have in mind?
Don't know, I'd like to get all our Wayland expertise into one room at
UDS and work out how much work needs doing.  My goal is to have Wayland
as an easily enabled option in 12.04 for early adopters to try out so we
can get some real world feedback.  It would be fine for it not to work
for certain drivers for example, but we would need enough features
working for it to be usable for all the normal desktop tasks.

 - Running an X server that writes to the compositor
 - Making it easy to enable this
 - Disclaiming all responsibility

 This would be a low priority task.

 -- 
 ubuntu-desktop mailing list
 ubuntu-desktop@lists.ubuntu.com
 https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop



-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


[Desktop12.04-Topic] Improved Authentication

2011-10-04 Thread Robert Ancell
It would be nice to improve the authentication mechanisms in Ubuntu to
be more user friendly and make it easier to enable modern authentication
schemes.  This will probably involve:
- Reviewing the messages/prompts in PAM for appropriateness
- Adding hints to PAM to allow GUIs to better display the prompts (i.e.
if a prompt is for a password, key number, if prompting for a password
change).
- Improving the Unity Greeter prompts to interpret the hints
- Improving PolicyKit to interpret the hints
- Making it easier to enable non-password authentication (e.g. LDAP, two
factor).

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


[Desktop12.04-Topic] Wayland tech preview

2011-10-04 Thread Robert Ancell
It would be nice to be able to optionally run Wayland in 12.04 to try
out the technology.  This will involve:
- Modifying LightDM to support Wayland
- Writing a Wayland compositor
- Running an X server that writes to the compositor
- Making it easy to enable this
- Disclaiming all responsibility

This would be a low priority task.

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Language chooser at login

2011-07-11 Thread Robert Ancell
On 09/07/11 19:23, Gunnar Hjalmarsson wrote:
 1. For users who change display language once in a while - for whatever
reason - it provides a more convenient way for doing so than doing it
from the Language Support UI or its successor. There is a fresh bug
report about it, btw: https://launchpad.net/bugs/803858
If we can define for whatever reason and it is appropriate then we
should support this feature.  This is what we are missing.  There are
thousands of features we could add because they can be used for whatever
reason, but that doesn't mean we add them.
 Storing of language settings
 
 As an input to the suggested code refactoring, I believe it's
 appropriate to talk about where the user language settings are stored.
 The primary place in Natty is /var/cache/gdm/$USER/dmrc, which file both
 GDM and language-selector read from and write to. language-selector also
 writes to ~/.profile, but as long as GDM is the dm, the language
 settings in ~/.profile are ignored.

 One advantage with using /var/cache/gdm/$USER/dmrc in this way is that
 the user language is dealt with correctly even if $HOME is not
 available, e.g. because it's stored on a separate device that is not
 mounted or because it's encrypted.

You really really shouldn't write to /var/cache/gdm/$USER/dmrc - it is a
_cache_, which means it's a mirrored copy of ~/.dmrc.  It is the
responsibility of GDM to keep this synchronised and mirror any changes
that are made to ~/.dmrc.

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Language chooser at login

2011-07-07 Thread Robert Ancell
On 05/07/11 19:11, Oliver Grawert wrote:

 Note that this doesn't necessarily have to be implemented in the
 greeter, i.e. you can run zenity in the guest accounts .profile and that
 prompts the user on login for language.  Or you can make multiple
 sessions for each installed language, i.e. there is a single menu for
 the login settings which has English, Japanese, German which each
 load Unity with differing settings.  I expect in these cases you don't
 want to provide an option to choose session type (Unity/GNOME) anyway.
 that sounds quite hackish, and up to that selection the whole UI would
 be english also i know a good bunch of internet cafes and school setups
 where you can (and people do) select between different desktops, its not
 an uncommon combination ...
One idea we played with was to have a language selector (as an
indicator?) which would set the language of the greeter only.  So when
you logged in it wouldn't change your stored language.  There is so
little text in the greeter we weren't sure if it needed translating. 
This language would also be used when creating the guest session.

would it be possible to provide a plugin system for the UI ? so someone
from the community could code some langauge selector that would hook
visually proper into the theme, hand over variables to the greeter etc ?
that way you would not have to do it in the DM code itself nor would
have to maintain it but people could still get the feature.

The Ubuntu greeter won't be pluggable, but you can write a new greeter,
basing it off the Ubuntu one if required.

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Language chooser at login

2011-07-04 Thread Robert Ancell
On 04/07/11 21:57, Marc Deslauriers wrote:
 On Mon, 2011-07-04 at 12:44 +1000, Robert Ancell wrote:
 From what I've gathered talking to people the classes of user are:
 1. Users who set the system language at install/first boot time, and
 never change it (the vast majority)
 2. English as a second language users, who switch between their native
 language and English (this is a class of user I don't understand well). 
 I think the reason for this is because the translations are not always
 good enough?  Is this a power user feature?
 3. Testers/developers who want to easily change language for testing
 (their requirements should not be exposed to normal users)
 There is also:

 4. People who create accounts for additional users

 In that scenario the tools that create accounts need to be modified to
 have a place to set the user's language and keyboard.
The Oneiric Control Center allows the language to be set for a user when
they are created.  There is not a setting for keyboard, however as a
computer has a single physical keyboard and the system layout will match
it this doesn't seem to be a big issue (i.e. if a user wants to use a
keyboard layout that does not match the keyboard they are probably
advanced, and can select it from the control center with the mouse only).

 This is a _legal_ issue in certain multilingual countries where it's
 unacceptable for a user to login to the wrong language and keyboard and
 try and find a control panel setting to change the default.
Could you elaborate on what this legal issue is?  Note as above if the
system administrator has correctly setup a user their language will be
correct on login.

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Language chooser at login

2011-07-04 Thread Robert Ancell
On 04/07/11 20:11, Matthew Paul Thomas wrote:
 Robert Ancell wrote on 04/07/11 03:44:

  If you change the display language within a session, it does not take
  effect in that session, but only after you have logged out and
  logged in again. The language setting is one of the few things that
  works that way.

  Yes, it's an unfortunate limitation of the system we use.

 So far, this discussion seems to be assuming that that limitation is
 unfixable. Windows has the same limitation, but Mac OS X (except for the
 Finder) does not, and many multilingual Web sites do not either.

 So, what would it take to remove that limitation in Ubuntu? What would
 it take to switch languages on the fly?

Definitely able to be improved on what we have currently, but not for
Oneiric.

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Language chooser at login

2011-07-04 Thread Robert Ancell
On 04/07/11 21:00, Gunnar Hjalmarsson wrote:
 I take it that you would like to see a solid base for decision that we
 do not have access to. Given that, to me the natural conclusion is that
 Ubuntu keeps providing the feature for now.
For a feature to exist, it needs a justification.  I see no reason why
the result of this discussion cannot produce one if it exists.  If there
is no justification, then we should not continue a feature.
 Btw, your position on this topic seems to have changed rapidly. The
 language chooser is included in the design description at
 http://www.freedesktop.org/wiki/Software/LightDM/Design, which I suppose
 formed a part of the base for the decision to make LightDM the default
 dm in Ubuntu. And a few weeks ago you stated explicitly on this list
 that the feature will be included in the Oneiric release. What happened?
I don't think it's changed rapidly.  The design process for the greeter
to be used in Oneiric originally started with a language selector, but
we couldn't find a strong reason for it.  So the current design (still a
work in progress) doesn't have one.  We're now having a discussion about
it, and this will influence the design.

Also, please note that the decision to include or not include a language
selector in Ubuntu does not necessarily reflect the design of LightDM or
any other greeters that may be developed for it.
 Can you provide some examples of these types of users, and why/how they
 currently switch language?
 I probably wouldn't do that better than you. But if you think about it,
 if you would require that sort of insight about every feature we are
 currently providing, there are a lot of features that should be wiped
 out right away. ;-)
And they should.  Unity/GNOME Shell wiped out a whole lot of features of
GNOME Panel and it was a good move.

 There are disadvantages to keeping this feature:
 - This feature is quite complex to support.
 How? Once in place, I fail to see that complexity. Ok, since I worked
 with the current Natty solution, I'm about as biased as anyone can be...
This feature involves setting a number of environment variables, which
may be overridden by login scripts.  It needs to be synchronised with
the session.  Implementing a feature is only one part of the work,
keeping it working in the future when other parts of the code change is
not free.
 - By having this feature both in the login screen and in the control
 center we are duplicating functionality but providing an inconsistent
 method of configuring it.
 Agreed. Certainly there is room for organizing the code better,
 including sharing code between the dm and language-selector. I'd be
 happy to help with that.
Think of how you would answer this question from a user:
How do I change my language?
Would the answer be - from the login screen or from the control center. 
But if you want to change the number format, then only in the control
center.
Or should you say - from the control center, where all the other
settings are.

 As I said in a bug comment, I understand that you are loaded with
 various other aspects of LightDM, to make it stable before the Oneiric
 release, and that you may not feel for struggling with a language
 chooser on top of it. But you also know that I have offered to help out
 with getting the functionality in place. You just need to open the door.
This is not a question of having the time to work on the feature, it is
the question Should there be a language option in the greeter?.

 Then let's develop this aspect of the desktop further after having
 considered various options more carefully and in a more structured way
 than currently is the case.

This is what we're doing right now!

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Language chooser at login

2011-07-03 Thread Robert Ancell
I've cc'd in Mika and John, who worked on the design of the new greeter
(not the greeter that is currently delivered with Oneiric) and Charline
who does user testing as they will probably have good opinions on this
feature.
 I'm of the opinion that we should keep providing a language chooser
 widget on the login screen, either in the greeter or on the top panel.
 Before giving the reasons for my view, I'd like to clarify which kind of
 language chooser it is that I advocate.
This seems to be completely the opposite way we should tackle this.  We
need to know what requirements the user has for language support, and
this will determine what GUI elements are appropriate to achieve this.
 If you change the display language within a session, it does not take
 effect in that session, but only after you have logged out and logged in
 again. The language setting is one of the few things that works that way.
Yes, it's an unfortunate limitation of the system we use.
 Those who typically make use of the language chooser on the login screen
 are reasonably users who alter between two or more display languages.
 Maybe that group is a small share of the Ubuntu users, but to them it's
 much more convenient to be able to set the language before logging in,
 compared to logging in, opening language-selector, changing the
 language, logging out and then logging in again.
Can you provide some examples of these types of users, and why/how they
currently switch language?

From what I've gathered talking to people the classes of user are:
1. Users who set the system language at install/first boot time, and
never change it (the vast majority)
2. English as a second language users, who switch between their native
language and English (this is a class of user I don't understand well). 
I think the reason for this is because the translations are not always
good enough?  Is this a power user feature?
3. Testers/developers who want to easily change language for testing
(their requirements should not be exposed to normal users)

I haven't heard of any standard user requirements to switch between more
than two languages, or two languages that do not include English (please
post here if you know of any).
 Future growth of Ubuntu users will probably be higher outside the
 English speaking countries than the average growth, so both the number
 and percentage of multi-lingual users, and consequently also the group
 that appreciate an opportunity to change language at login, ought to
 increase.
And I'd expect these users to use their preferred language and not need
to change it at all.  We need to work out what the group that
appreciate an opportunity to change language at login are trying to
achieve.  The multi-lingual users I've talked to do not change their
language settings frequently.
 From an Ubuntu user perspective, the question isn't if we should add a
 language chooser to the login screen, but the question is whether it
 would be a good idea to remove the feature. Is there any disadvantage
 with it worth mentioning for those who don't use it? Has anybody
 complained of its pure existence? ;-)
Users who don't use this feature are not going to miss it.  Users who do
need to be able to achieve the functionality they had before, but not
necessarily using the same method.

There are disadvantages to keeping this feature:
- This feature is quite complex to support.
- By having this feature both in the login screen and in the control
center we are duplicating functionality but providing an inconsistent
method of configuring it.
- Users can accidentally change it, giving an opportunity to make their
session unusable.


-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Reports for Desktop Bugs

2011-06-15 Thread Robert Ancell
Nice work!

I'd recommend adding a Development tab that tracks development
packages.  I had this problem with the versions page in that it
automatically tracks packages on the CD, but not the packages that were
used to build them.  Things like intltool which are just as critical as
the applications we deliver, but often get forgotten about.

On 06/16/2011 04:29 AM, Pedro Villavicencio Garrido wrote:
 Hello folks,

 During the last week I've been working on writing some reports for the
 desktop team using launchpadlib, I've added the link of the prototype to
 yesterday Meeting and in case you missed it, please have a look to:

 http://people.canonical.com/~pedro/desktop/

 This is a launchpadlib script and its updated every two hours.

 The basic purpose of the pages is to have a central place where you can
 look for bugs having a high heat (good quantity of dups and users
 affected) also every bug marked as High or Critical is being listed
 there, right now it has 5 categories:

 * Desktop Bugs: all the bugs of packages being tracked on
 https://bugs.launchpad.net/~desktop-bugs/+packagebugs
 * Other Packages: Gwibber, Telepathy*, Network-Manager, etc (look at the
 page for full list)
 * Compiz: Bugs just for compiz.
 * Unity: unity, nux, unity-place-applications, unity-place-files.
 * Mozilla : Thunderbird and Firefox.

 There's an extra category: Assigned Bugs , which basically lists all the
 bugs assigned to the canonical-desktop-team or to any of the members of
 it.

 Please review the page and let me know what you'd like to
 include,remove,etc. If I'm missing a package you're looking please also
 tell me and if you'd like to have a separate category (ie: Messaging for
 empathy+telepathy bugs) also tell me so i can create it.

 I'll rework on the code of it and hopefully move it to
 ~platform/desktop.

 Looking forward to your feedback!. Have a nice day!,

 pedro.




-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Call for testing: LightDM

2011-06-09 Thread Robert Ancell
On 06/07/2011 08:03 PM, Matthew East wrote:
 On 7 June 2011 10:02, Alan Bell alanb...@ubuntu.com wrote:
 yeah, I would very much hope that lightdm does not introduce more
 accessibility regressions.
 I'm taking this opportunity to post a link to this comment on the
 proposed switch to lightDM from Matthew Garrett, in case people
 reading here haven't seen it, it seems relevant to this discussion and
 I haven't seen it mentioned before.

 It also briefly discusses impact on accessibility, albeit without
 going into detail.

 http://mjg59.livejournal.com/136274.html

Needless to say, I disagree with most of the points Matthew has raised.  :)

The argument that LightDM does less because it is smaller is weak.  The
features listed as missing are the ones currently provided by GNOME
session.  However, you could very easily write a LightDM greeter that
ran a GNOME session (i.e. just copy the relevant code from GDM) that
would provide all that same functionality for almost no significant
additional lines of code (as the lines are all external modules).  So
LightDM could provide all the same functionality as GDM with it's
current size.  However, if you produce a greeter that does implement
this functionality by the numbers given in the blog post you would have
a whopping 49,000 lines of code to use before you became bigger than GDM.

My preferred design is not to use GNOME session, with the main reasons
being startup cost, complexity and the security risks of running a full
session in a login screen (as pointed out by Chris earlier in this
thread).  However, the assumption seems to be this will involve
rewriting every service.  Not the case; of course a GNOME greeter would
leverage as much as is appropriate of the GNOME platform e.g. using
gnome-power-manager if that was the best solution.

A point that is incorrect (which I pointed out to Matthew but he didn't
correct) is things like power management are not performed in the
backend.  So the backend is not going to swell to support different
desktops.  Sharing policy between login screen and session is up to the
greeter.  A GNOME greeter should have the same policy as a GNOME
session.  It wont be the same as KDE policy.

Finally I think Matthew massively underestimates the value of being able
to differentiate on the greeter.  A number of projects - including
Ubuntu - have wanted to have a greeter that matches their desktops but
have been unable to do so with GDM.  No-one really cares (or wants to
know) how the lower layers of display management work (I certainly
didn't), they just want to work on the GUI.  If we were to modify GDM to
provide the UI we want (has been attempted a few times) we would be
carrying a huge patch on top of the already 35 we are carrying in
Natty.  Using LightDM we are able to run the daemon unpatched and
differentiate to our hearts content with the greeter.  With GDM we would
effectively be forking the project.

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Call for testing: LightDM

2011-06-07 Thread Robert Ancell
On 06/06/2011 10:30 PM, Kevin Huang wrote:
 On Mon, 2011-06-06 at 18:01 +1000, Robert Ancell wrote:
 This feature is just not implemented yet.  It will be in Oneiric.

 Any target date that loco can start to test?

Definitely by Beta, ideally by A2.
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Call for testing: LightDM

2011-06-07 Thread Robert Ancell

 This feature is just not implemented yet.  It will be in Oneiric.
 Good to know, Robert. Are you able to say something about e.g. the
 keyboard layout and universal access?

This is an area where I'm definitely not an expert, and your help is
greatly appreciated here!  Most of my knowledge has come from picking
Martin Pitt's brain and talking to others. 

The keyboard design as I see it is:
- The layout is left as X sets it up
- Selecting a user switches to the keyboard layout they have configured
in their ~/.dmrc.  If not present, keep the default layout
- There will be a layout switcher, which will be applied to the .dmrc so
it is preserved on login
- Cancelling a login will revert to the default layout

The real difficulty is in making sure that I've handled all the keyboard
config correctly.  I'm using libxklavier, I just need to know how many
config items to save/restore correctly.

With universal access the goal is as much as we can get.  The greeter
will probably be built with the same tech as Unity so as well as Unity. 
Ideally we'll have full AT-SPI with Orca running if required and an
onscreen keyboard.

 Great.  Is Gunnar Hjalmarsso involved in this feature implementation,
 I'm not yet, but I plan to make myself involved to assist with the i18n
 matters. :)  I'll try to ensure that the current functionality with
 respect to languages and locales is preserved in the Oneiric release.

Please do!  File bugs on anything that's not up to scratch.

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Call for testing: LightDM

2011-06-06 Thread Robert Ancell
Thanks, I've updated the information.

On 06/06/2011 04:04 AM, Steven wrote:
 Would you mind providing a little more information in the wiki about
 explicitly how to report and triage LightDM bugs? I'm assuming you
 want people to report it in Ubuntu with 'ubuntu-bug lightdm' and then
 add a tracker for the upstream project (
 https://launchpad.net/lightdm)? Thanks.

 -Stenten


 On Thu, Jun 2, 2011 at 2:52 AM, Robert Ancell
 robert.anc...@canonical.com mailto:robert.anc...@canonical.com wrote:

 Hi all,

 As LightDM is scheduled to be the default display manager in Oneric by
 Alpha 2 it would be awesome if we can get as many testers as possible,
 so please be a guinea pig!

 If you are using Oneric you can install it from Universe:
 $ sudo apt-get install lightdm lightdm-greeter-example-gtk

 If using Natty you can install it from the PPA:
 $ sudo apt-add-repository ppa:lightdm-team/ppa

 Expect less features than the current GDM (e.g. user switching not yet
 implemented).  I've been using LightDM exclusively for over a week
 without any major issues and others have indicated they are also using
 it without issue.

 The GUI will be replaced with something more Unity like during the
 cycle
 so look out for lacking functionality but don't worry too much
 about the
 style.

 For more information see this page:
 https://wiki.ubuntu.com/LightDM

 Thanks,
 --Robert


 --
 ubuntu-desktop mailing list
 ubuntu-desktop@lists.ubuntu.com
 mailto:ubuntu-desktop@lists.ubuntu.com
 https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop



-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Call for testing: LightDM

2011-06-02 Thread Robert Ancell
Hi all,

As LightDM is scheduled to be the default display manager in Oneric by
Alpha 2 it would be awesome if we can get as many testers as possible,
so please be a guinea pig!

If you are using Oneric you can install it from Universe:
$ sudo apt-get install lightdm lightdm-greeter-example-gtk

If using Natty you can install it from the PPA:
$ sudo apt-add-repository ppa:lightdm-team/ppa

Expect less features than the current GDM (e.g. user switching not yet
implemented).  I've been using LightDM exclusively for over a week
without any major issues and others have indicated they are also using
it without issue.

The GUI will be replaced with something more Unity like during the cycle
so look out for lacking functionality but don't worry too much about the
style.

For more information see this page:
https://wiki.ubuntu.com/LightDM

Thanks,
--Robert


-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


[Bug 699893] Re: AisleRiot: Card style will not install properly

2011-06-01 Thread Robert Ancell
Note that aisleriot has been split out of GNOME Games for the 3.1
release, so it's important that this change is made to the new aisleriot
package when it is packaged.

-- 
You received this bug notification because you are a member of Ubuntu
Desktop, which is a bug assignee.
https://bugs.launchpad.net/bugs/699893

Title:
  AisleRiot: Card style will not install properly

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Proposing to add Rodrigo Moya to ~ubuntu-desktop

2011-04-20 Thread Robert Ancell
On 04/20/2011 06:44 PM, Martin Pitt wrote:
 Hello all,

 Rodrigo has worked in the desktop team for several months now, and
 will continue to do so. In my experience he has picked up all the
 necessary packaging skills, is familiar with our processes, freezes,
 revision control handling, and our goals. In the last couple of months
 I did not have anything major to complain about his commits/uploads.

 I propose to add him to the ~ubuntu-desktop team, so that he can
 commit to our branches and upload GNOMEish packages directly.

 He has already been a PPU for a while:
 https://wiki.ubuntu.com/RodrigoMoya/PerPackageUploadApplication

 As per https://wiki.ubuntu.com/DesktopTeam/Developers we need two more
 supporters for this.

 Opinions?

 Thanks,

 Martin
+1 from me.  I've sponsored a number of his packages and have found his
work to be of high quality.

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: [Oneiric-Topic] Packaging branches

2011-04-12 Thread Robert Ancell
On 04/12/2011 01:55 AM, James Westby wrote:
 On Mon, 11 Apr 2011 10:36:51 +1000, Robert Ancell 
 robert.anc...@canonical.com wrote:
 Some issues that will remain:
 - It is possible to screw up the branches so that bzr merge-package
 throws a confusing error (I keep doing it).  Perhaps we need some hooks
 in bzr to stop this from occurring.  If it can be broken, it will be
 broken (repeatedly).
 Do you have details on what the mistake is, or at least what the error
 you get is? I'd like to prevent it in some fashion if possible.

 Thanks,

 James

I'm still 100% not sure what I did wrong but there was a discussion on
the UDD list about it

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: [Oneiric-Topic] Packaging branches

2011-04-12 Thread Robert Ancell
On 04/12/2011 03:09 AM, Sebastien Bacher wrote:
 Le lundi 11 avril 2011 à 10:36 +1000, Robert Ancell a écrit :
 So, I propose that we move all the current packaging branches to using
 lp:ubuntu/package_name branches.  We have a few branches using this
 mode and have had good success with them. 
 Hi,

 I don't think the situation with those changed since previous cycle,
 they are still much slower to checkout and give no real benefit out of
 using a standard location and making sponsoring a bit easier, I'm not
 convinced we should switch while we are no compelling reason to do it.
 One other questions is to know how team work would be handled on the
 standard locations?

 --
 Sebastien Bacher


I think using a standard location, working with manual dputs, easier
sponsoring, easier checking of changes are real benefits worth getting. 
I think there also easier to explain to new contributors.

The checkout issue is definitely a problem, however I have been
surprised that it hasn't been the big issue I expected.  It only really
seems to be a problem the first time you check them out.

By team work do you mean packages in progress (use branches) or
permissions for accessing the branches?

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: [Oneiric-Topic] Packaging branches

2011-04-12 Thread Robert Ancell
On 04/12/2011 06:34 PM, Martin Pitt wrote:
 Robert Ancell [2011-04-11 10:36 +1000]:
 - People are often ignoring the branches and uploading directly (or
 forgetting do a bzr push) which means changes are sometimes dropped by
 accident
 - People often do merge requests to lp:ubuntu/package_name, even when
 there is a packaging branch
 I agree that these are annoying indeed.

 However, after having worked with the normal mode branches for a
 while, I still don't like them better:

  * They come with quilt patches pre-applied in the source, which is
not only horribly confusing and error prone, but also breaks
merge-upstream pretty thoroughly.
I hadn't noticed that.  The seems like absolutely the wrong behaviour. 
Can this be fixed?
  * They still ignore the actually interesting problem: maintaining
patches themselves with revision control, with
looms/threads/pipelines/name du jour. I. e. they throw all this
bzr overhead on the bits that we don't need in bzr (the upstream
code), but don't actually help us with patch management.
That certainly is the goal we want to get to sometime.  However I do
think they are easier to make patches.

Current method (perhaps I'm missing something here):
1. Checkout bzr branch of debian/ directory
2. Get tarball of current version (I use apt-get source, though you have
to be careful that it is the same version)
3. Get tarball of latest version (I use bzr-buildpackage and then ctrl-C
once I have the tarball in the build-area/ directory)
4. Unpack tarballs somewhere manually
5. Copy debian directory
6. Diff two versions for changes (i.e. NEWS and configure.ac) - I use
meld here
7. Update debian/rules debian/control etc
8. Muck around with quilt/edit-patch to add/update/remove patches
9. Copy back debian/ directory changes to bzr branch
10. bzr-buildpackage
11. debcommit / bzr push

Normal mode method:
1. Checkout branch of source and debian/ directory (Sloo
first time)
2. bzr merge-upstream
3. bzr diff to check for changes in package (i.e. NEWS and configure.ac)
4. Update debian/rules debian/control etc
5. Muck around with quilt/edit-patch to add/update/remove patches
6. bzr-buildpackage
7. debcommit / bzr push
  * They are incompatible with upstream bzr branches even for those
projects whose native trunks are in Launchpad and bzr already.
Again, is this fixable?
 So in summary I must say that the main effect from the full branches
 is that people make a lot more errors and everything is slower :-(

 Martin


-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: [Oneiric-Topic] LightDM for display management

2011-04-12 Thread Robert Ancell
On 04/11/2011 01:39 PM, James Westby wrote:
 On Fri, 08 Apr 2011 19:02:35 +1000, Robert Ancell 
 robert.anc...@canonical.com wrote:
 Last cycle I proposed using LightDM to replace GDM [1].  It was deferred
 due to the Unity work, so time to repropose!

 The main reasons for switching are:
 - Simpler code to maintain (GDM is a huge ~50,000 line C program and we
 carry 36 patches.  LightDM is nearer 10,000 lines of C).
 - More flexible greeter development - greeters are as easy as X
 applications to write, which means we can have an Ubuntu specific
 greeter that without branching the rest of the code
 I assume that the greeters can be written to be accessible via
 screenreaders etc, and that they can be localised etc as well?

 Thanks,

 James

That is the intention.  If we use a GTK based greeter (as I would
expect) there would be localization via the normal methods. 
Screenreader support is also a requirement.

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: [Oneiric-Topic] LightDM for display management

2011-04-12 Thread Robert Ancell
On 04/11/2011 07:30 PM, Loïc Minier wrote:
 On Fri, Apr 08, 2011, Robert Ancell wrote:
 - Speed improvements - we can run a greeter without running a full GNOME
 session
  Running a full GNOME session sounds like a waste, but it kind of
  makes sense to run a mini-session to start the essential GNOME services
  and reuse GNOME infrastructure as much as possible.  Screen readers
  came up, but there is also:
  - networking -- you might need it for login
  - suspend/resume support -- you might want to close the lid just after
you booted, but before you entered you logged in
  - shutting down the screen and/or computer if nobody logs in for a
while
  - sound -- you might want to mute / lower the volume to prevent any
specific login sound from popping up
  - keyboard configuration -- to type your password in the right layout
when you have multiple layout configured
  - screensaver?  I don't care about that one, maybe some do

  There is also a case to be made for starting dconf to store the
  settings of the session so that LDM would reuse GNOME infrastructure
  for settings.

Sure, there are definitely a number of required services.  Note I'm not
ruling out running a GNOME session, it just depends if you can have a
cut down enough session to make it work.  The services you require in a
login screen (basically power management, networking, audio) really are
all system services - I hope that GNOME is working towards taking these
things out of the session in the future.

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: [Oneiric-Topic] GTK3/GNOME3

2011-04-12 Thread Robert Ancell
On 04/12/2011 05:31 AM, Javier Jardón wrote:
 On 8 April 2011 00:23, Robert Ancell robert.anc...@canonical.com wrote:

 Can we get all our CD applications using GTK3?  I'm thinking of Firefox
 here, we really don't want to have one or two applications requiring
 both packages on the CD..
 FYI: Firefox GTK+3 port: https://bugzilla.mozilla.org/show_bug.cgi?id=627699

Awesome!

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


[Oneiric-Topic] Packaging branches

2011-04-10 Thread Robert Ancell
We currently maintain most Ubuntu Desktop packages in bzr branches and
use bzr-builddeb in merge mode [1] with packaging stored in
lp:~ubuntu-desktop/package_name/ubuntu.  The other option was to use
normal mode [2], but this was not chosen at the time due to the size of
checkouts.

My experience since moving to bzr branches:
- Much, much faster updating of packages
- Branching packages is possible (e.g. working in a PPA)
- Patches are a little bit harder to do, as the branch doesn't contain
the files from the source tarball
- People are often ignoring the branches and uploading directly (or
forgetting do a bzr push) which means changes are sometimes dropped by
accident
- People often do merge requests to lp:ubuntu/package_name, even when
there is a packaging branch

So, I propose that we move all the current packaging branches to using
lp:ubuntu/package_name branches.  We have a few branches using this mode
and have had good success with them.

Some issues that will remain:
- It is possible to screw up the branches so that bzr merge-package
throws a confusing error (I keep doing it).  Perhaps we need some hooks
in bzr to stop this from occurring.  If it can be broken, it will be
broken (repeatedly).
- Branches with a lot of history take a lot of time/bandwidth to check
out.  This adds a barrier to contributors, but is something that bzr
hopefully will solve in the future [3]

--Robert

[1] http://jameswestby.net/bzr/builddeb/user_manual/merge.html
[2] http://jameswestby.net/bzr/builddeb/user_manual/normal.html
[3] https://bugs.launchpad.net/bzr/+bug/46561

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: [Oneiric-Topic] LightDM for display management

2011-04-10 Thread Robert Ancell
On 04/08/2011 07:42 PM, Milan Bouchet-Valat wrote:
 Le vendredi 08 avril 2011 à 19:04 +0930, Jason Warner a écrit :
 Thanks for proposing this. I'm particularly interested in any and all
 speed improvements that could come from this...and if we have less
 overhead in general, great!
 If you're using GNOME, loading a whole GNOME session when starting GDM
 won't induce much overhead, since you'll need to load all of those apps
 and libraries anyway in the login phase. It might even be better to read
 those files early since it makes sure ureadahead will catch them.

 And it ensures that once you've typed your password, the login is fast
 (less disk reads): since at that point we know you're sitting in front
 of your keyboard, better spend less time in that phase, and more in the
 boot per se.

 Of course only testing can decide which one is faster, but (for GNOME
 users) I don't think that's a priori so obvious.
There is additional overhead in that you have to initialize the GNOME
session twice, once for the gdm user and once for the user who logs in. 
And loading a session just to display ~10 fairly simple UI elements
seems like a huge waste.  I don't know enough about ureadahead, but it
certainly should cache the gnome-session libraries etc, perhaps we have
to whitelist them somewhere?

So I think in theory it should be faster.

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: [Oneiric-Topic] GTK3/GNOME3

2011-04-07 Thread Robert Ancell
On 04/07/2011 05:59 PM, Martin Pitt wrote:
 Hello all,

 kind of obvious topic, but next cycle we'll need to move to GTK3 and
 GNOME3. Aside from the obvious update the package versions, I see
 the following particular challenges:

  * Review our patches, and be rather aggressive about removing those
which are intrusive and which we have carried for ages without
upstream acceptance. Of course there are also still patches which
we haven't even proposed upstream, these should be discussed in
bugzilla.gnome.org.

  * Port pygtk2 apps to PyGI with GTK3. The biggest ones are
ubiquity and software-center, but there is also quite a long tail
of smaller upstream software.

  * Discuss GTK3 theming with UX/design. Our current murrine based
Humanity theme doesn't work with GTK3.

 I expect that this will bind a lot of developer capacity next cycle,
 but at the same time it's very important that we do this to not lose
 track with GNOME.

 Martin
One issue we need to tackle is the use of clutter.  Applications are
moving towards using clutter (e.g. cheese) and my experience with
clutter has been:
- Requires good 3D support
- Has never seemed to work well for me...

We need to work out early if we can have a hard dependency on clutter or
not, and what happens if you can't run clutter applications.

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: [Oneiric-Topic] Reducing number of patches in our packages

2011-04-07 Thread Robert Ancell
On 04/07/2011 09:23 PM, Rodrigo Moya wrote:
 Priority: medium?

 While working on the GNOME3 PPA during this cycle, I found we have a lot
 of patches in many packages, which makes things harder when upgrading to
 major versions, and also introduces new ways for the apps to fail, as
 the fixes are rebased to apply to the new upstream version.

 While some patches make a lot of sense, others are better kept in the
 upstream source, where the upstream developers can guarantee the quality
 accross major versions upgrades.

 So, for next cycle, I would suggest a small goal of trying to do patch
 upstreaming/cleaning days, maybe once a week or every 2 weeks.

 Also, some Ubuntu-specific patches, like the appindicators ones are
 duplicated in lots of packages, so it would be good if we could find a
 better way to make upstream apps use them, like, for instance, patching
 gtk_status_icon_* in GTK itself to use the indicators when available,
 instead of having to patch dozens of apps (and keep those patches
 up-to-date and working for every major version upgrade).

 Another candidate for that could be the launchpad integration patches,
 which are present in many more packages than the appindicators ones. I'm
 sure we can find a way to have that in GTK itself, so that whenever a
 Help menu is created, and given we have the name of the app, it could
 just create the LPI entries.


+100 for this topic.  The amount of patches we carry is a huge but
mostly silent overhead.  I'd like to make a website like versions [1]
that shows our diff against vanilla GNOME to make this more visible.

[1] http://people.canonical.com/~platform/desktop/versions.html

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: [Oneiric-Topic] GTK3/GNOME3

2011-04-07 Thread Robert Ancell
On 04/07/2011 05:59 PM, Martin Pitt wrote:
 Hello all,

 kind of obvious topic, but next cycle we'll need to move to GTK3 and
 GNOME3. Aside from the obvious update the package versions, I see
 the following particular challenges:

  * Review our patches, and be rather aggressive about removing those
which are intrusive and which we have carried for ages without
upstream acceptance. Of course there are also still patches which
we haven't even proposed upstream, these should be discussed in
bugzilla.gnome.org.

  * Port pygtk2 apps to PyGI with GTK3. The biggest ones are
ubiquity and software-center, but there is also quite a long tail
of smaller upstream software.

  * Discuss GTK3 theming with UX/design. Our current murrine based
Humanity theme doesn't work with GTK3.

 I expect that this will bind a lot of developer capacity next cycle,
 but at the same time it's very important that we do this to not lose
 track with GNOME.

 Martin
Can we get all our CD applications using GTK3?  I'm thinking of Firefox
here, we really don't want to have one or two applications requiring
both packages on the CD..

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


[Bug 722491] Re: evolution crashed with SIGSEGV in send_dbus_message()

2011-03-10 Thread Robert Ancell
Note, you should be able to workaround this problem by going to
EditPlugins, then select the Mail Notification plugin, and disable
Generate a D-Bus message in the configuration tab.

-- 
You received this bug notification because you are a member of Ubuntu
Desktop, which is a bug assignee.
https://bugs.launchpad.net/bugs/722491

Title:
  evolution crashed with SIGSEGV in send_dbus_message()

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


[Bug 722491] Re: evolution crashed with SIGSEGV in send_dbus_message()

2011-03-09 Thread Robert Ancell
** Changed in: evolution (Ubuntu)
   Status: Opinion = New

-- 
You received this bug notification because you are a member of Ubuntu
Desktop, which is a bug assignee.
https://bugs.launchpad.net/bugs/722491

Title:
  evolution crashed with SIGSEGV in send_dbus_message()

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


[Bug 722491] Re: evolution crashed with SIGSEGV in send_dbus_message()

2011-02-22 Thread Robert Ancell
Can you reproduce this problem?  Can you run evolution from the terminal
and see what output is printed?

It appears what might be happening is the email doesn't contain valid
UTF-8, and dbus/gvariant doesn't handle this case.

** Changed in: evolution (Ubuntu)
 Assignee: (unassigned) = Ubuntu Desktop (ubuntu-desktop)

-- 
You received this bug notification because you are a member of Ubuntu
Desktop, which is a bug assignee.
https://bugs.launchpad.net/bugs/722491

Title:
  evolution crashed with SIGSEGV in send_dbus_message()

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


New GTK3 package naming

2011-02-21 Thread Robert Ancell

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all,

You may have noticed that the GTK3 packages have been renamed to match
their new library names (e.g. libgtk3.0-0 is not libgtk-3-0).  This
matches what Debian has implemented in Debian experimental.

This will be a transition period where packages are rebuilt against
these new packages.  Please update any packages you are able to!

Thanks,
- --Robert

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1jVNYACgkQGOqhiQ98iC6kFgCdFsbA9h2bJia6EsqSoqzEmA/w
6nIAoN6YMcLT5VbMTLMwgn2tX/jmRMpB
=oLsW
-END PGP SIGNATURE-


-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: GNOME Shell has been removed from the repositories?

2011-02-20 Thread Robert Ancell

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

This was driven by the following issues:
- - We're not delivering the GNOME3 applications in Natty, so we moved
them to a PPA [1].  This was due to us not having the time to do a
good job on both Unity and GNOME3.
- - To have GNOME Shell in Natty would have required a number of
packages to be updated that may have conflicted with GNOME2, so we
decided to put it in the PPA too.  We also thought putting it in the
PPA would make it easier for people to contribute (as you don't need
to be sponsored to upload to it).

If GNOME Shell works in the PPA AND all the dependencies do not
conflict with GNOME2 then it could be uploaded to Natty Universe, but
at the moment this seems unlikely.  If it depends on any GNOME3
applications (e.g. GNOME control center) then it will have to remain
in the PPA.  I think the most likely situation is it will be in
Natty+1 and Natty users will be able to use it using the PPA.

Note that we need more help keeping the PPA up to date, so anyone who
is interested do merge proposals into
lp:~gnome3-team/package_name/ubuntu and/or jump onto #ubuntu-desktop!

- --Robert

[1] https://launchpad.net/~gnome3-team/+archive/gnome3

On 19/02/11 20:51, Bilal Akhtar wrote:
 Hi Jo-Erland,

 This was discussed in the below bug:

 https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/690045

 GNOME shell depends on several GNOME 3 libraries, most of which haven't
 (yet) made their way into Ubuntu. This will be fixed very soon when
 packages from the Ubuntu GNOME 3 ppa will be uploaded to Natty. After
 that only we'll re-add GNOME shell into the archive.

 Bilal Akhtar.

 On 02/19/2011 07:52 AM, Jo-Erlend Schinstad wrote:
 I've noticed that gnome-shell is not provided in the repositories for
 Natty. It used to be available in universe, from Karmic to Maverick.
 Why is this no longer the case?

 I strongly believe that GNOME Shell should be available in the
 repositories, and preferably in main. There is already too much talk
 about Ubuntu moving away from GNOME. Removing gnome-shell from the
 repositories will encourage that misconception. I personally remain
 somewhat sceptical about both Unity and GNOME Shell, but I loudly
 applaud the efforts of both projects to innovate and modernize the
 desktop. I also think both projects show great promise, and I'm really
 looking forward to see how they progress as they mature and are
 exposed to a greater audience.

 And I am a little concerned that by both switching to use Unity by
 default and removing the main competitor -- GNOME Shell -- from the
 repositories, it may seem like Ubuntu is using its power as the most
 popular distro to eliminate competition. You will get Unity for free,
 it will be installed and used by default. GNOME Shell, on the other
 hand... You'll need to search the web, try to find a good PPA, add the
 repository and then install it -- if you're really that interested. I
 am really hesitant to mention the comparison that automatically
 springs to my mind: Microsoft killed Netscape by providing Internet
 Explorer for free and, more importantly, installing it by default. No
 doubt, it's quite an efficient means of ridding oneself of
 competition, but it really doesn't seem to be in the spirit of Ubuntu.

 I don't want to come across as accusing anyone of doing that. But I am
 concerned that's the way people will interpret it and that it'll help
 fuel tribalism. I strongly believe that the competition between GNOME
 Shell and Unity will bring out the best in both of them, but that will
 require both of them to be exposed to as vast an audience as possible.
 I'm not saying that GNOME Shell should be promoted or installed by
 default, only that it should be available from the repositories, at
 the very least in universe. I think that by promoting it to main, that
 would send a strong signal that Canonical and Ubuntu are not in
 conflict with GNOME. Also, if people are able to easily try GNOME
 Shell, then if people do stick with it, developers of Unity has a much
 better chance of learning why they do so, which will enable them to
 improve. The same would be true for GNOME Shell, of course: if people
 try it and chooses to use Unity instead, then they will have the
 opportunity to learn. The question, therefore, is is Ubuntu going to
 enable the community around it to be able to improve?. These are the
 important things in the free software community, and if Ubuntu can do
 that, then it will have done something important, that will be
 appreciated... :)

 In summary: The current situation makes Unity a symbol of conflict and
 an excuse for tribalism, which is as ironic as it is sad. The best
 solution is to promote it to main.

 Thanks for reading,

 Jo-Erlend Schinstad




-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1hp+IACgkQGOqhiQ98iC4aZwCg0WiMxf1LN/Xi0hZvhYN4frG+

[Bug 700370] Re: Please rename gir1.2-mutter-2.31 to gir1.2-mutter-2.91

2011-01-13 Thread Robert Ancell
Closing as fixed as we are syncing mutter from Debian.

** Changed in: mutter (Ubuntu)
   Status: New = Fix Committed

-- 
You received this bug notification because you are a member of Ubuntu
Desktop, which is a direct subscriber.
https://bugs.launchpad.net/bugs/700370

Title:
  Please rename gir1.2-mutter-2.31 to gir1.2-mutter-2.91

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Ubuntu Desktop weekly meetings

2010-11-30 Thread Robert Ancell

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all,

So this concludes the trial of the desktop meeting summary...  Results
are here:
https://wiki.ubuntu.com/DesktopTeam/Meeting/2010-11-30

It seemed the consensus was the categories were important, so I
reformatted the list to include them.  I suggest we have a policy that
anything of ongoing importance/churn should have it's own category,
and these will change over time (e.g. I suspect the Unity category
will be not so important in a few cycles whereas we might be doing a
lot of developer experience work that would require one).

I also bolded some key words to make it easier to skim-read, these are
easy to add in the wiki as you enter items (use three apostrophes
'''), and/or they can be quickly updated during the meeting (only
takes a minute or so).

I propose we keep this format for now on.  Yes/no/should we change it?

- --Robert

On 18/11/10 10:50, Robert Ancell wrote:

 Today in the Eastern Edition of the Desktop meeting we discussed
 the structure and purpose of the weekly Desktop meetings. I'll try
 and summarise some of the points raised and propose some ideas.

 While the current meetings are working well, some of the
 challenges raised were: * Participants being split across
 timezones * Most participants work in different domains so
 traditional meeting structure may not be appropriate * The team is
 growing * How useful is the meeting summary? [1]

 I propose we more tightly define what the meeting purpose is, such
 as: * The meeting scope is the Ubuntu Desktop product * The purpose
 of the meeting is to share information about progress/issues * The
 meetings are open to everyone in the community * The meetings
 should not take significant time * There will be more than one
 meeting so participants from around the world can join in * The
 output of the meetings will be a wiki page summarising the weekly
 progress: * Actions to be taken * New work completed * Issues
 raised

 The summary should be useful to the following people: * Ubuntu
 Desktop team members * Potential Desktop team members who want to
 know what is going on / look for areas where they can contribute *
 Media (e.g. OMG Ubuntu) who want an official record of what is
 going on in the Desktop product

 We also discussed some technology, but I'll leave that to follow
 up emails to keep this email short.

 --Robert

 [1] https://wiki.ubuntu.com/DesktopTeam/Meeting/2010-11-16

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkz17cwACgkQGOqhiQ98iC7mpQCg0G7PX+7uO/DfLDOcHaV+aBlu
ZRkAn33UgvDCLWblCzp4BTSqvoZ1R9Rw
=2Sqg
-END PGP SIGNATURE-

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Re: Ubuntu Desktop weekly meetings

2010-11-24 Thread Robert Ancell

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all,

There was a discussion about this email in the western edition and
this continued into the eastern edition.  The decision was to trial a
new weekly summary format, which we will use for the next meeting (30
November).

The instructions:
 * The summary is here:
https://wiki.ubuntu.com/DesktopTeam/Meeting/2010-11-30
 * Any Ubuntu desktop team member can update this list.
 * You can add any item to the list that you consider useful to
another team member or someone interested in what the desktop team is
doing.
 * Insert new items where you think the importance is, the list is
sorted highest to lowest.
 * You can update this list at any time during the week (and you are
encouraged to).
 * At the end of the week, before the meeting, this list will be
cleaned up by Jason and I and emailed to this mailing list.

Notes:
 * This should not take any more time than the current system.  Note
if it does.
 * There are no categories (e.g. USC, U1, X).  This is to keep the
experiment simple and it will hopefully be clear if we need them.
 * There are no per-person lists, add an attribution after the item if
you want.
 * Feedback, feedback, feedback!

- --Robert

On 18/11/10 11:11, Robert Ancell wrote:

 And to follow up about technology etc...

 In my opinion the current activity reports are more about proving
 you've done a weeks worth of work, than providing a good summary
 of what's happened in a week. I'd like to see the summary more
 like this:

 * x new bugs were opened, y were closed * We completed x items in
 the work tracker. We are ahead of the trend line. * x packages
 were updated in natty. * The CD size grew by xMB to yMB. * The
 FooBar app is now 10x more awesome! Thanks to the x for making
 this change. * Remmina has replaced tsclient on the CD, please try
 it an let us know if it is an improvement. * We are behind in
 updating GNOME, please have a look at
 http://people.canonical.com/~platform/desktop/versions.html and
 help out if you can * Compiz is delayed due to issues with the
 packaging, please have a look at the
 lp:~ubuntu-desktop/compiz/new_version branch for the current
 progress * Intel users may have some issues with the updated video
 driver, please report bugs to z.

 Note that some of this information can be automatically pulled
 from Launchpad etc.

 We discussed how to produce the manual information. The options
 seem to be: - The Wiki - Etherpad - status.net

 If people are interested in producing the high-detail reports we
 need to consider where/how to produce those, and then boil them
 down to a good summary.

 --Robert

 Today in the Eastern Edition
 of the Desktop meeting we discussed

 the structure and purpose of the weekly Desktop meetings.
 I'll try

 and summarise some of the points raised and propose some
 ideas.



 While the current meetings are working well, some of the

 challenges raised were: * Participants being split across

 timezones * Most participants work in different domains so

 traditional meeting structure may not be appropriate * The
 team is

 growing * How useful is the meeting summary? [1]



 I propose we more tightly define what the meeting purpose
 is, such

 as: * The meeting scope is the Ubuntu Desktop product * The
 purpose

 of the meeting is to share information about
 progress/issues * The

 meetings are open to everyone in the community * The
 meetings

 should not take significant time * There will be more than
 one

 meeting so participants from around the world can join in *
 The

 output of the meetings will be a wiki page summarising the
 weekly

 progress: * Actions to be taken * New work completed *
 Issues

 raised



 The summary should be useful to the following people: *
 Ubuntu

 Desktop team members * Potential Desktop team members who
 want to

 know what is going on / look for areas where they can
 contribute *

 Media (e.g. OMG Ubuntu) who want an official record of what
 is

 going on in the Desktop product



 We also discussed some technology, but I'll leave that to
 follow

 up emails to keep this email short.



 --Robert



 [1] https://wiki.ubuntu.com/DesktopTeam/Meeting/2010-11-16


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkztpLIACgkQGOqhiQ98iC40bgCgtWtO6nlCmw8ChGUSAz4yDmA1
mjUAnjozeYj4ufqHOjgI/ZfkDL6d1CV+
=xsJL
-END PGP SIGNATURE-

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


Ubuntu Desktop weekly meetings

2010-11-17 Thread Robert Ancell

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Today in the Eastern Edition of the Desktop meeting we discussed the
structure and purpose of the weekly Desktop meetings.  I'll try and
summarise some of the points raised and propose some ideas.

While the current meetings are working well, some of the challenges
raised were:
 * Participants being split across timezones
 * Most participants work in different domains so traditional meeting
structure may not be appropriate
 * The team is growing
 * How useful is the meeting summary? [1]

I propose we more tightly define what the meeting purpose is, such as:
 * The meeting scope is the Ubuntu Desktop product
 * The purpose of the meeting is to share information about
progress/issues
 * The meetings are open to everyone in the community
 * The meetings should not take significant time
 * There will be more than one meeting so participants from around the
world can join in
 * The output of the meetings will be a wiki page summarising the
weekly progress:
* Actions to be taken
* New work completed
* Issues raised

The summary should be useful to the following people:
 * Ubuntu Desktop team members
 * Potential Desktop team members who want to know what is going on /
look for areas where they can contribute
 * Media (e.g. OMG Ubuntu) who want an official record of what is
going on in the Desktop product

We also discussed some technology, but I'll leave that to follow up
emails to keep this email short.

- --Robert

[1] https://wiki.ubuntu.com/DesktopTeam/Meeting/2010-11-16

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzkajIACgkQGOqhiQ98iC6lCwCgvPQW8x0sjnuZSxXzIynM4ryw
hBQAoLATqQKOtvwKnfF/ATn77T8pI4Ve
=8lIC
-END PGP SIGNATURE-


-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop


  1   2   >