Re: Call for testing - unity-control-center (fork of gnome-control-center so we can stay on an old version)
Hey Robert, Robert Ancell [2013-12-12 16:21 +1300]: > > The upgrade went fine, and it replaced most of the > > gnome-control-center* packages with the unity-* counterparts, except > > for gnome-control-center-data > [...] > u-c-c doesn't need this package. Good, all is well then. > It is only depended on by gnome-control-center. The only way that it > will be removed is by an apt-get autoremove right? Or by adding a Breaks:/Replaces:, to clean up. But this is a bit tricky as people might actually want to install the (future) real g-c-c in parallel, so they need to be versioned to the saucy version. > > 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. Yes, that menu item. For me it didn't do anything after the upgrade, because that dist-upgrade removed gnome-control-center. Thanks! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- 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)
On Wed, Dec 11, 2013 at 9:12 PM, Martin Pitt 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
Re: Some desktop updates for this cycle
Le 29/11/2013 18:27, Sebastien Bacher a écrit : * GTK: the default option is to stay on 3.8, we are looking at updating to 3.10 though Thanks to the tireless work from Lars we have candidate packages to test in the desktop ppa: https://launchpad.net/~ubuntu-desktop/+archive/ppa Hey everyone, New update, GTK 3.10 got good feedback from the ppa testing, it has been uploaded to trusty and is available there since today. (Having the new version is not an open door to upload new GNOME components though, we still didn't sort out the GtkHeaderBar integrations issues so please refrain from updating GNOME 3.10 components that use those.) On other news we also got webkigtk 2.3.2 to build on all archs and moved to trusty. Cheers, Sebastien Bacher -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Fwd: Call for testing - unity-control-center (fork of gnome-control-center so we can stay on an old version)
On 11 December 2013 10:14, Kai Mast wrote: > I did not run into any problems on my machine until now when using the PPA. > :) > > > On 12/11/2013 10:26 AM, Dimitri John Ledkov wrote: > > On 11 December 2013 09:09, Martin Pitt wrote: > >> Dimitri John Ledkov [2013-12-11 9:05 +]: > >>> I see what you mean. one could iterate all user sessions and restart >>> indicator-session in each one, but that is also intrusive. > >> >> That sounds interesting, and would avoid pkilling processes that you >> run in chroots, source trees, etc. How would you do this? >> > > for i in `ls /run/user/*/upstart/sessions/*.session`; do (export `cat > $i`; initctl restart indicator-session) ; done > > > Isn't this a general thing that should be done when any user-level service > is upgraded? it is true for system daemons, but up until now it was not possible to do for per-user session services (e.g. session dbus, session dconf, etc.) > Would be nice if you defined a proper behavior for all those upgrades once. > I personally would prefer if the services restarted directly and users don't > have to relogin or do some manual process killing. > At the moment it is out of scope for Debian Policy, which defines when and how daemons should be restarted on upgrade. And at the moment we will not be able to do if for all applications because there is no distinction at the moment between user session daemons and applications (with possibly unsaved user data). While, e.g. we do know that indicators are generally stateless, that may not be the case with other processes in the user session. Furthermore, for some processes there is no sensible way to restart them, e.g. gnome-session. I believe at the moment, per Debian Policy, no files in home directories should be automatically changed in dpkg .deb package upgrades and restarting user session applications/daemons is undefined. -- Regards, Dimitri. -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Fwd: Call for testing - unity-control-center (fork of gnome-control-center so we can stay on an old version)
I did not run into any problems on my machine until now when using the PPA. :) On 12/11/2013 10:26 AM, Dimitri John Ledkov wrote: > On 11 December 2013 09:09, Martin Pitt wrote: >> > Dimitri John Ledkov [2013-12-11 9:05 +]: >>> >> I see what you mean. one could iterate all user sessions and restart >>> >> indicator-session in each one, but that is also intrusive. >> > >> > That sounds interesting, and would avoid pkilling processes that you >> > run in chroots, source trees, etc. How would you do this? >> > > for i in `ls /run/user/*/upstart/sessions/*.session`; do (export `cat > $i`; initctl restart indicator-session) ; done Isn't this a general thing that should be done when any user-level service is upgraded? Would be nice if you defined a proper behavior for all those upgrades once. I personally would prefer if the services restarted directly and users don't have to relogin or do some manual process killing. Kai -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Fwd: Call for testing - unity-control-center (fork of gnome-control-center so we can stay on an old version)
On 11 December 2013 09:09, Martin Pitt wrote: > Dimitri John Ledkov [2013-12-11 9:05 +]: >> I see what you mean. one could iterate all user sessions and restart >> indicator-session in each one, but that is also intrusive. > > That sounds interesting, and would avoid pkilling processes that you > run in chroots, source trees, etc. How would you do this? > for i in `ls /run/user/*/upstart/sessions/*.session`; do (export `cat $i`; initctl restart indicator-session) ; done -- Regards, Dimitri. -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Fwd: Call for testing - unity-control-center (fork of gnome-control-center so we can stay on an old version)
Dimitri John Ledkov [2013-12-11 9:05 +]: > I see what you mean. one could iterate all user sessions and restart > indicator-session in each one, but that is also intrusive. That sounds interesting, and would avoid pkilling processes that you run in chroots, source trees, etc. How would you do this? Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Fwd: Call for testing - unity-control-center (fork of gnome-control-center so we can stay on an old version)
On 11 December 2013 08:57, Martin Pitt wrote: > Dimitri John Ledkov [2013-12-11 8:54 +]: >> Well, it's managed by session upstart, so one could simply do/trigger >> $ restart indicator-session > > Nope, postinst runs in a system/root context, not in a desktop > session: > > # restart indicator-session > restart: Unknown job: indicator-session > > pkill'ing *all* running session indicators is quite a large hammer > indeed. But requiring a session restart isn't that big of a deal, I > was just bringing it up as a possibility. > I see what you mean. one could iterate all user sessions and restart indicator-session in each one, but that is also intrusive. We already have desktop migrations running on login, but re-login is all that is needed here -- Regards, Dimitri. -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Fwd: Call for testing - unity-control-center (fork of gnome-control-center so we can stay on an old version)
Dimitri John Ledkov [2013-12-11 8:54 +]: > Well, it's managed by session upstart, so one could simply do/trigger > $ restart indicator-session Nope, postinst runs in a system/root context, not in a desktop session: # restart indicator-session restart: Unknown job: indicator-session pkill'ing *all* running session indicators is quite a large hammer indeed. But requiring a session restart isn't that big of a deal, I was just bringing it up as a possibility. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Fwd: Call for testing - unity-control-center (fork of gnome-control-center so we can stay on an old version)
On 11 December 2013 08:12, Martin Pitt wrote: > 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? > Well, it's managed by session upstart, so one could simply do/trigger $ restart indicator-session -- Regards, Dimitri. -- 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)
Hey Robert, Robert Ancell [2013-12-11 17:42 +1300]: > 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). Nice! So it happens at last. > 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: $ dpkg -l *control-center*|grep ^ii ii activity-log-manager-control-center 0.9.7-0ubuntu4+unity all blacklist configuration for Zeitgeist (transitional package) ii gnome-control-center-data 1:3.8.6-0ubuntu1+unity all configuration applets for GNOME - data files ii libgnome-control-center1 1:3.6.3-0ubuntu49 amd64utilities to configure the GNOME desktop ii libunity-control-center1 1.0 amd64utilities to configure the GNOME desktop ii unity-control-center 1.0 amd64utilities to configure the GNOME desktop ii unity-control-center-data 1.0 all configuration applets for GNOME - data files ii unity-control-center-signon 0.1.7~+14.04.20131126.2-0ubuntu1+unity amd64Unity Control Center extension for single signon 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) 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 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. 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? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
