[gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update

[gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update

[walt]

First hint:  it's a mess -- don't do it on a critical machine.
(My main machine is ~amd64 and that's why I'm doing it on virtual
~amd64 machines first.)

The new gnome-shell demands that systemd be installed, even if you
don't intend to use it. 

The latest systemd conflicts with udev because the udev project
has been rolled into systemd, which now provides all of the files
previously installed by udev.

Therefore your machine will still boot without udev because systemd
installs all the udev files. You don't need to start or use systemd
if you don't want to, but the systemd package must be installed 
*before* you reboot and after removing udev.

Removal of udev has caused a few (temporary) problems with useflags,
because a few packages still depend directly on udev instead of the
newer (!systemd ? udev) which means accept either one but not both.
That will get fixed soon, I'm sure.

The right way to upgrade gnome is probably to remove every gnome
package on the machine, which will avoid many of the conflicts I've
had to fight for the last two days -- but of course I did it the hard
way instead :)

You can try emerge -au gnome-light early in the update, which is
simpler than emerging gnome in all its immensity, but that's no
guarantee of success -- I'm sure you'll still run into conflicts
between packages and useflags, but it might be a bit easier.

When you see conflicting packages that won't install, I suggest
deleting both packages immediately -- let portage sort out the
conflicts.  Just keep removing packages until portage finally
stops complaining.

Beware of pambase, however.  I finally took Canek's advice and
removed consolekit from the machine and unset the useflag for
all packages, including pambase and polkit.  I'd suggest you
get pambase and polkit re-installed with the proper useflags
before you try to reboot.  Dunno if that's mandatory, but I did
it that way and had no problems (yet).

I've finished updating my virtual gentoo systemd machine now,
but I'm still fighting with the virtual openrc machine and I'm
not sure how it will turn out.  More tomorrow :)

Re: [gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update

[Canek Peláez Valdés]

[-- Attachment #1: Type: text/plain, Size: 3011 bytes --]

On Jul 27, 2013 4:44 PM, "walt" <w41ter@gmail.com> wrote:
>
> First hint:  it's a mess -- don't do it on a critical machine.
> (My main machine is ~amd64 and that's why I'm doing it on virtual
> ~amd64 machines first.)
>
> The new gnome-shell demands that systemd be installed, even if you
> don't intend to use it.
>
> The latest systemd conflicts with udev because the udev project
> has been rolled into systemd, which now provides all of the files
> previously installed by udev.
>
> Therefore your machine will still boot without udev because systemd
> installs all the udev files. You don't need to start or use systemd
> if you don't want to, but the systemd package must be installed
> *before* you reboot and after removing udev.
>
> Removal of udev has caused a few (temporary) problems with useflags,
> because a few packages still depend directly on udev instead of the
> newer (!systemd ? udev) which means accept either one but not both.
> That will get fixed soon, I'm sure.
>
> The right way to upgrade gnome is probably to remove every gnome
> package on the machine, which will avoid many of the conflicts I've
> had to fight for the last two days -- but of course I did it the hard
> way instead :)
>
> You can try emerge -au gnome-light early in the update, which is
> simpler than emerging gnome in all its immensity, but that's no
> guarantee of success -- I'm sure you'll still run into conflicts
> between packages and useflags, but it might be a bit easier.
>
> When you see conflicting packages that won't install, I suggest
> deleting both packages immediately -- let portage sort out the
> conflicts.  Just keep removing packages until portage finally
> stops complaining.
>
> Beware of pambase, however.  I finally took Canek's advice and
> removed consolekit from the machine and unset the useflag for
> all packages, including pambase and polkit.  I'd suggest you
> get pambase and polkit re-installed with the proper useflags
> before you try to reboot.  Dunno if that's mandatory, but I did
> it that way and had no problems (yet).
>
> I've finished updating my virtual gentoo systemd machine now,
> but I'm still fighting with the virtual openrc machine and I'm
> not sure how it will turn out.  More tomorrow :)

I haven't upgraded yet to the last update (although I've been using GNOME
3+systemd for years), but I do know this: the primary reason of GNOME's
dependency on systemd is logind, and logind *CANNOT* run correctly if
systemd is not the running init.

So you not only need to install systemd: you need to use it as init. I
don't even think logind can start if systemd is not running.

And actually, the long term plan is for systemd --user to basically replace
gnome-session-manager, so just installing systemd is not going to work at
all in the future, even if it *may* seems to work now (which I'm pretty
sure it doesn't).

systemd provides some pretty complex functionality for logind (and
therefore GNOME) while running; it's not just some libraries.

Regards.

[-- Attachment #2: Type: text/html, Size: 3598 bytes --]

[gentoo-user] Re: [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update

[walt]

On 07/27/2013 03:08 PM, Canek Peláez Valdés wrote:
> And actually, the long term plan is for systemd --user to basically
> replace gnome-session-manager,

Is Lennart part of the gnome project now? ;)

> so just installing systemd is not
> going to work at all in the future, even if it *may* seems to work
> now (which I'm pretty sure it doesn't).

Maybe I'll be able to confirm or deny tomorrow morning :)  The update
will take all night (on my slower machine) but I fear that the build
will quit with an error as soon as my head hits the pillow. I'll let
you know in the morning.

As an aside, I got this great idea for automating the update:

Instead of removing all gnome packages before updating gnome (much too
much boring work for lazy me) I updated the glib package first because
All Things Gnome depend on glib.

Then I started revdep-rebuild, which of course will automatically re-
install every gnome package on the machine (and update to the latest
versions of everything in the process :).

Of course portage refused to do the glib update because of a zillion
or more package conflicts, so I worked around that by running:

#ebuild /usr/portage/dev-libs/glib/glib-2.36.3-r1 merge

Let's see how many hours of pain my laziness will cost me this time :)

Re: [gentoo-user] Re: [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update

[Walter Dnes]

On Sat, Jul 27, 2013 at 03:56:41PM -0700, walt wrote
> On 07/27/2013 03:08 PM, Canek Peláez Valdés wrote:
> > And actually, the long term plan is for systemd --user to basically
> > replace gnome-session-manager,
> 
> Is Lennart part of the gnome project now? ;)

  Lennart is a Redhat employee, and Gnome+systemd are Redhat's pride and
joy.  It's not linux anymore, it's REDHAT-GNOME-OS.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Re: [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update

[Canek Peláez Valdés]

[-- Attachment #1: Type: text/plain, Size: 616 bytes --]

On Jul 27, 2013 5:57 PM, "walt" <w41ter@gmail.com> wrote:
>
> On 07/27/2013 03:08 PM, Canek Peláez Valdés wrote:
> > And actually, the long term plan is for systemd --user to basically
> > replace gnome-session-manager,
>
> Is Lennart part of the gnome project now? ;)

He has been on Planet GNOME for many years now. When people talks about
GNOME OS, it implicitly includes the Linux kernel, sytemd/udev (including
journald, hostnamed, logind, etc.), dbus, Avahi, PulseAudio, and all the
GNOME stack from glib up to GNOME Shell.

Vertical tight integration from kernel to end user apps.

Regards.

[-- Attachment #2: Type: text/html, Size: 739 bytes --]

Re: [gentoo-user] Re: [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update

[Canek Peláez Valdés]

On Sat, Jul 27, 2013 at 5:56 PM, walt <w41ter@gmail.com> wrote:
> On 07/27/2013 03:08 PM, Canek Peláez Valdés wrote:
>> And actually, the long term plan is for systemd --user to basically
>> replace gnome-session-manager,
>
> Is Lennart part of the gnome project now? ;)
>
>> so just installing systemd is not
>> going to work at all in the future, even if it *may* seems to work
>> now (which I'm pretty sure it doesn't).
>
> Maybe I'll be able to confirm or deny tomorrow morning :)  The update
> will take all night (on my slower machine) but I fear that the build
> will quit with an error as soon as my head hits the pillow. I'll let
> you know in the morning.
>
> As an aside, I got this great idea for automating the update:
>
> Instead of removing all gnome packages before updating gnome (much too
> much boring work for lazy me) I updated the glib package first because
> All Things Gnome depend on glib.
>
> Then I started revdep-rebuild, which of course will automatically re-
> install every gnome package on the machine (and update to the latest
> versions of everything in the process :).
>
> Of course portage refused to do the glib update because of a zillion
> or more package conflicts, so I worked around that by running:
>
> #ebuild /usr/portage/dev-libs/glib/glib-2.36.3-r1 merge
>
> Let's see how many hours of pain my laziness will cost me this time :)

I finally updated; I had no problems whatsoever. I also stopped using
my overlay (and will soon discontinue it); with the introduction of
virtual/service-manager, it's not longer necessary to have a
systemd-only (without OpenRC) machine.

The only "special" thing I'm doing is to mask >sys-apps/systemd-204,
since 205 introduced the new cgroups management code (with systemd as
the only writer of the cgroups hierarchy), and it seems to cause some
minor problems with logind. Other than that, it works withouth a
glitch: gnome-base/gnome-3.8.0, sys-apps/systemd-204, no consolekit at
all.

Then again, this is how I've been running my machines since last year.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Re: [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update

[Stefan G. Weichinger]

Am 28.07.2013 10:04, schrieb Canek Peláez Valdés:

> The only "special" thing I'm doing is to mask >sys-apps/systemd-204,
> since 205 introduced the new cgroups management code (with systemd as
> the only writer of the cgroups hierarchy), and it seems to cause some
> minor problems with logind. Other than that, it works withouth a
> glitch: gnome-base/gnome-3.8.0, sys-apps/systemd-204, no consolekit at
> all.

Same here, yes. I run systemd-206 but I didn't notice an problem(s) yet.
Maybe there are some and I don't get it ;-)

Stefan

Re: [gentoo-user] Re: [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update

[Michael Hampicke]

[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]

Am 28.07.2013 10:07, schrieb Stefan G. Weichinger:
> Am 28.07.2013 10:04, schrieb Canek Peláez Valdés:
> 
>> The only "special" thing I'm doing is to mask >sys-apps/systemd-204,
>> since 205 introduced the new cgroups management code (with systemd as
>> the only writer of the cgroups hierarchy), and it seems to cause some
>> minor problems with logind. Other than that, it works withouth a
>> glitch: gnome-base/gnome-3.8.0, sys-apps/systemd-204, no consolekit at
>> all.
> 
> Same here, yes. I run systemd-206 but I didn't notice an problem(s) yet.
> Maybe there are some and I don't get it ;-)
> 

I had one problem, but I am not sure, if it's related to systemd > 204,
the removal of consolekit, or gnome at all.

But when logging into my gnome session, /usr/libexec/gvfsd-fuse can not
be started, because the permissions of /dev/fuse are rw------ root:root

Other distros like ubuntu have a fuse group for that, which does not
exist on gentoo. So I assume the default permissions for /dev/fuse on
gentoo machines should be rw-rw-rw- root:root?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] Re: [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update

[Canek Peláez Valdés]

On Sun, Jul 28, 2013 at 8:23 AM, Michael Hampicke <mh@hadt.biz> wrote:
> Am 28.07.2013 10:07, schrieb Stefan G. Weichinger:
>> Am 28.07.2013 10:04, schrieb Canek Peláez Valdés:
>>
>>> The only "special" thing I'm doing is to mask >sys-apps/systemd-204,
>>> since 205 introduced the new cgroups management code (with systemd as
>>> the only writer of the cgroups hierarchy), and it seems to cause some
>>> minor problems with logind. Other than that, it works withouth a
>>> glitch: gnome-base/gnome-3.8.0, sys-apps/systemd-204, no consolekit at
>>> all.
>>
>> Same here, yes. I run systemd-206 but I didn't notice an problem(s) yet.
>> Maybe there are some and I don't get it ;-)
>>
>
> I had one problem, but I am not sure, if it's related to systemd > 204,
> the removal of consolekit, or gnome at all.
>
> But when logging into my gnome session, /usr/libexec/gvfsd-fuse can not
> be started, because the permissions of /dev/fuse are rw------ root:root
>
> Other distros like ubuntu have a fuse group for that, which does not
> exist on gentoo. So I assume the default permissions for /dev/fuse on
> gentoo machines should be rw-rw-rw- root:root?

My problem was that *sometimes* (not always) I was unable to unlock my
session after suspending my laptop or desktop. Reverting back to
systemd-204 solved it, so I'm assuming that's the problem, although I
didn't really investigated the issue.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

[gentoo-user] Re: [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update

[walt]

On 07/28/2013 01:04 AM, Canek Peláez Valdés wrote:
> I finally updated; I had no problems whatsoever.

The only way I could solve all of the conflicts on my openrc machine
was to enable the systemd useflag globally (to prevent consolekit and
udev being pulled in).  It's updating to gnome-3.8 now and I'm sure
it will take all night.

With systemd being used by several critical gnome packages I'm thinking
that systemd will indeed need to be running for all those packages to
work correctly.  But I'll find out tomorrow :)

Re: [gentoo-user] Re: [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1707 bytes --]

On Sunday 28 Jul 2013 17:16:55 Canek Peláez Valdés wrote:
> On Sun, Jul 28, 2013 at 8:23 AM, Michael Hampicke <mh@hadt.biz> wrote:
> > Am 28.07.2013 10:07, schrieb Stefan G. Weichinger:
> >> Am 28.07.2013 10:04, schrieb Canek Peláez Valdés:
> >>> The only "special" thing I'm doing is to mask >sys-apps/systemd-204,
> >>> since 205 introduced the new cgroups management code (with systemd as
> >>> the only writer of the cgroups hierarchy), and it seems to cause some
> >>> minor problems with logind. Other than that, it works withouth a
> >>> glitch: gnome-base/gnome-3.8.0, sys-apps/systemd-204, no consolekit at
> >>> all.
> >> 
> >> Same here, yes. I run systemd-206 but I didn't notice an problem(s) yet.
> >> Maybe there are some and I don't get it ;-)
> > 
> > I had one problem, but I am not sure, if it's related to systemd > 204,
> > the removal of consolekit, or gnome at all.
> > 
> > But when logging into my gnome session, /usr/libexec/gvfsd-fuse can not
> > be started, because the permissions of /dev/fuse are rw------ root:root
> > 
> > Other distros like ubuntu have a fuse group for that, which does not
> > exist on gentoo. So I assume the default permissions for /dev/fuse on
> > gentoo machines should be rw-rw-rw- root:root?
> 
> My problem was that *sometimes* (not always) I was unable to unlock my
> session after suspending my laptop or desktop. Reverting back to
> systemd-204 solved it, so I'm assuming that's the problem, although I
> didn't really investigated the issue.

On my vanilla stable Gentoo with openrc, /dev/fuse permissions are:

$ ls -la /dev/fuse
crw-rw-rw- 1 root root 10, 229 Jul 29 08:22 /dev/fuse

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] Re: [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update

[Mark Pariente]

On Sun, 2013-07-28 at 11:16 -0500, Canek Peláez Valdés wrote:
> On Sun, Jul 28, 2013 at 8:23 AM, Michael Hampicke <mh@hadt.biz> wrote:
> > Am 28.07.2013 10:07, schrieb Stefan G. Weichinger:
> >> Am 28.07.2013 10:04, schrieb Canek Peláez Valdés:
> >>
> >>> The only "special" thing I'm doing is to mask >sys-apps/systemd-204,
> >>> since 205 introduced the new cgroups management code (with systemd as
> >>> the only writer of the cgroups hierarchy), and it seems to cause some
> >>> minor problems with logind. Other than that, it works withouth a
> >>> glitch: gnome-base/gnome-3.8.0, sys-apps/systemd-204, no consolekit at
> >>> all.
> >>
> >> Same here, yes. I run systemd-206 but I didn't notice an problem(s) yet.
> >> Maybe there are some and I don't get it ;-)
> >>
> >
> > I had one problem, but I am not sure, if it's related to systemd > 204,
> > the removal of consolekit, or gnome at all.
> >
> > But when logging into my gnome session, /usr/libexec/gvfsd-fuse can not
> > be started, because the permissions of /dev/fuse are rw------ root:root
> >
> > Other distros like ubuntu have a fuse group for that, which does not
> > exist on gentoo. So I assume the default permissions for /dev/fuse on
> > gentoo machines should be rw-rw-rw- root:root?
> 
> My problem was that *sometimes* (not always) I was unable to unlock my
> session after suspending my laptop or desktop. Reverting back to
> systemd-204 solved it, so I'm assuming that's the problem, although I
> didn't really investigated the issue.

This turned out to be an upstream issue. See:

https://bugs.freedesktop.org/show_bug.cgi?id=67267

and the corresponding Gentoo bug:

https://bugs.gentoo.org/show_bug.cgi?id=477954

Upstream has already fixed it on git, so we'll either have to wait until
systemd-207 or see if the systemd maintainers cherry pick the patch as
206-r1 on portage.

--Mark

Re: [gentoo-user] Re: [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update

[Canek Peláez Valdés]

On Mon, Jul 29, 2013 at 3:28 AM, Mark Pariente <markpariente@gmail.com> wrote:
> On Sun, 2013-07-28 at 11:16 -0500, Canek Peláez Valdés wrote:
>> On Sun, Jul 28, 2013 at 8:23 AM, Michael Hampicke <mh@hadt.biz> wrote:
>> > Am 28.07.2013 10:07, schrieb Stefan G. Weichinger:
>> >> Am 28.07.2013 10:04, schrieb Canek Peláez Valdés:
>> >>
>> >>> The only "special" thing I'm doing is to mask >sys-apps/systemd-204,
>> >>> since 205 introduced the new cgroups management code (with systemd as
>> >>> the only writer of the cgroups hierarchy), and it seems to cause some
>> >>> minor problems with logind. Other than that, it works withouth a
>> >>> glitch: gnome-base/gnome-3.8.0, sys-apps/systemd-204, no consolekit at
>> >>> all.
>> >>
>> >> Same here, yes. I run systemd-206 but I didn't notice an problem(s) yet.
>> >> Maybe there are some and I don't get it ;-)
>> >>
>> >
>> > I had one problem, but I am not sure, if it's related to systemd > 204,
>> > the removal of consolekit, or gnome at all.
>> >
>> > But when logging into my gnome session, /usr/libexec/gvfsd-fuse can not
>> > be started, because the permissions of /dev/fuse are rw------ root:root
>> >
>> > Other distros like ubuntu have a fuse group for that, which does not
>> > exist on gentoo. So I assume the default permissions for /dev/fuse on
>> > gentoo machines should be rw-rw-rw- root:root?
>>
>> My problem was that *sometimes* (not always) I was unable to unlock my
>> session after suspending my laptop or desktop. Reverting back to
>> systemd-204 solved it, so I'm assuming that's the problem, although I
>> didn't really investigated the issue.
>
> This turned out to be an upstream issue. See:
>
> https://bugs.freedesktop.org/show_bug.cgi?id=67267

Yeah, I suspected so; that was my theory in the mail I sent yesterday:

http://article.gmane.org/gmane.linux.gentoo.user/267762

So it is indeed the new slices code. I'm staying on 204 until 207 comes out.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update

[gottlieb]

I am a gnome-3 user, who wants to continue with gnome-3.  I understand
now that to move to 3.8 requires I move from openRC to systemd and am
trying to accomplish that now.  I have so far only done the easy first
steps.

0.  I always back up my user files and /etc daily

1.  I confirmed that my system still boots off my installation CD
    (just in case).

2.  I added enough entries to /etc/portage/package.mask to prevent
    systemd being required (list at the end if others are interested).

3.  Performed the kernel prerequisites from the wiki (most of which
    were already enabled).

4.  My /run directory was already present and populated.

Now I hit my first question

The wiki says that "upstream suggests that the /etc/mtab file should
be a simlink to /proc/self/mounts."  It then points out problems with
and without the symlink.

My current system has both files but with slightly different contents,
specifically the entries for my filesystems, root (includes /usr) and several
lvm2 lvs, say "commit=0 0 2" in /etc/mtab but say "data=ordered 0 0"
in /proc/self/mounts

Do you advising leaving it alone or executing
   ln -sf /proc/self/mounts /etc/mtab

After that comes the big one

emerge systemd
USE="... systemd ..."
emerge --change-use
/etc/init.d/udev restart

Can the system be rebooted at this point (I realize init will still not
use systemd) or must the entire conversion (including changing init) be
completed before the system is bootable?  I am hoping it is the former.

thanks in advance for any help.

allan


================================================================

My file /etc/portage/package.mask/gnome-3.8 >=gnome-base/gnome-3.8
>=gnome-base/gnome-core-apps-3.8 >=gnome-base/gnome-control-center-3.8
>=gnome-base/gnome-shell-3.8 >=x11-terms/gnome-terminal-3.8
>=gnome-extra/gnome-power-manager-3.8 >=media-gfx/eog-3.8
>=media-video/totem-3.8 >=app-crypt/seahorse-3.8 >=net-im/empathy-3.8
>=app-editors/gedit-3.8.3 >=gnome-extra/gnome-shell-extensions-3.8
>=gnome-base/gnome-extra-apps-3.8.0-r1:3.0
>=gnome-extra/evolution-data-server-3.8 >=dev-libs/folks-0.9
>=gnome-extra/gnome-calculator-3.8 >=gnome-extra/gnome-tweak-tool-3.8
>=gnome-base/gdm-3.8 >=gnome-extra/gnome-documents-3.8
>=gnome-extra/nautilus-tracker-tags-0.16 >=app-misc/tracker-0.16
>=dev-libs/totem-pl-parser-3.4.5 >=dev-libs/libpeas-1.8
>=gnome-extra/yelp-3.8 >=gnome-extra/gnome-contacts-3.8
>=app-cdr/brasero-3.8 >=net-misc/vinagre-3.8
>=app-dicts/gnome-dictionary-3.8 >=app-arch/file-roller-3.8
>=net-analyzer/gnome-nettool-3.8 >=gnome-extra/gnome-system-monitor-3.8
>=gnome-extra/gucharmap-3.8 >=media-gfx/gnome-font-viewer-3.8
>=net-misc/vino-3.8 >=media-gfx/gnome-screenshot-3.8
>=sys-apps/baobab-3.8 >=www-client/epiphany-3.8 >=dev-cpp/gtkmm-3.8
>=app-admin/gnome-system-log-3.8 >=media-video/cheese-3.8
>=net-libs/libzapojit-0.0.3 >=gnome-extra/sushi-3.8
>=mail-client/evolution-3.8 >=gnome-base/gnome-core-libs-3.8
>=gnome-base/gvfs-1.16 >=net-wireless/gnome-bluetooth-3.8
>=app-text/evince-3.8 >=net-libs/gnome-online-accounts-3.8
>=gnome-extra/gnome-color-manager-3.8 >=x11-wm/mutter-3.8
>=gnome-base/libgnome-keyring-3.8 >=net-libs/webkit-gtk-2.0.4:3/25
>=gnome-extra/zenity-3.8 >=gnome-base/gnome-session-3.8
>=x11-libs/gtksourceview-3.8 >=media-libs/clutter-gtk-1.4.4:1.0
>=x11-themes/gnome-themes-standard-3.8 >=media-video/cheese-3.8
>=gnome-extra/yelp-xsl-3.8 >=x11-themes/gnome-icon-theme-3.8
>=x11-themes/gnome-icon-theme-symbolic-3.8
>=gnome-base/gsettings-desktop-schemas-3.8
>=gnome-base/gsettings-desktop-3.8 >=gnome-base/gnome-desktop-3.8
>=x11-themes/gnome-backgrounds-3.8 >=gnome-extra/gnome-user-docs-3.8
>=gnome-base/gnome-common-3.7 >=x11-libs/gtk+-3.8
>=gnome-base/gnome-keyring-3.8 >=gnome-base/nautilus-3.8
>=app-crypt/gcr-3.8 >=net-libs/libsoup-2.42
>=gnome-base/gnome-settings-daemon-3.8 >=net-libs/webkit-gtk-2.0.3
>=media-libs/clutter-1.14 >=dev-libs/libgweather-3.8
>=media-libs/cogl-1.14

Re: [gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update

[gottlieb]

On Mon, Jul 29 2013, gottlieb@nyu.edu wrote:

> I am a gnome-3 user, who wants to continue with gnome-3.  I understand
> now that to move to 3.8 requires I move from openRC to systemd and am
> trying to accomplish that now.  I have so far only done the easy first
> steps.

OK.  Walt proved this wrong by managing, with some effort and doubtless
considerable skill, to get 3.8 on an openrc machine but he does note
that moving to systemd is the procedure supported by the gentoo devs.

I am still trying to move to systemd and would appreciate help as
mentioned in my previous msg.

thanks again,
allan

Re: [gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update

[Canek Peláez Valdés]

On Mon, Jul 29, 2013 at 7:56 PM,  <gottlieb@nyu.edu> wrote:
> I am a gnome-3 user, who wants to continue with gnome-3.  I understand
> now that to move to 3.8 requires I move from openRC to systemd and am
> trying to accomplish that now.  I have so far only done the easy first
> steps.
>
> 0.  I always back up my user files and /etc daily
>
> 1.  I confirmed that my system still boots off my installation CD
>     (just in case).
>
> 2.  I added enough entries to /etc/portage/package.mask to prevent
>     systemd being required (list at the end if others are interested).
>
> 3.  Performed the kernel prerequisites from the wiki (most of which
>     were already enabled).
>
> 4.  My /run directory was already present and populated.

Sounds reasonable.

> Now I hit my first question
>
> The wiki says that "upstream suggests that the /etc/mtab file should
> be a simlink to /proc/self/mounts."  It then points out problems with
> and without the symlink.
>
> My current system has both files but with slightly different contents,
> specifically the entries for my filesystems, root (includes /usr) and several
> lvm2 lvs, say "commit=0 0 2" in /etc/mtab but say "data=ordered 0 0"
> in /proc/self/mounts
>
> Do you advising leaving it alone or executing
>    ln -sf /proc/self/mounts /etc/mtab

AFAIU, systemd will print the following warning if /etc/mtab is not a
symlink to /proc/self/mounts:

"/etc/mtab is not a symlink or not pointing to /proc/self/mounts. This
is not supported anymore. Please make sure to replace this file by a
symlink to avoid incorrect or misleading mount(8) output."

Also, upstream will reject flatly any support for systems where this
happens. Lastly, if I understand correctly, /proc/self/mounts is how
the mounts are really mounted, so if they differ, /proc/self/mounts
contains the correct information.

If you switch to systemd, you will need to make /etc/mtab a symlink to
/proc/self/mounts.

> After that comes the big one
>
> emerge systemd
> USE="... systemd ..."
> emerge --change-use
> /etc/init.d/udev restart
>
> Can the system be rebooted at this point (I realize init will still not
> use systemd) or must the entire conversion (including changing init) be
> completed before the system is bootable?  I am hoping it is the former.

If you install systemd, sys-fs/udev will be uninstalled first (they
block each other). At this point, /etc/init.d/udev doesn't exists
anymore in your system. If you reboot, I don't believe there is any
chance your system will boot up correctly.

/etc/init.d/udev is installed by sys-fs/udev; sys-apps/systemd doesn't
provide anything similar. I recommend installing everything necessary
(and uninstalling everything that is not) before trying the reboot.

Also, instead of emerge --changed-use (not --change-use, BTW), try:

emerge --update --deep --newuse --verbose

Or its shorter equivalent, emerge -uDNv world. --deep will force a
check on the entire dependency tree, --newuse will trigger
reinstallation for flags you didn't set. I think, in this case at
least, it's better to cover as many possible packages affected by the
switch. Although I update my systems always with --deep and --newuse.

Also, I would do the whole shebang in a one step, removing all the
masked packages you did. You can try to boot to multi-user.target
instead of graphical.target, if you want to test that systemd works
correctly independently of GNOME.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update

[gottlieb]

First and foremost, thank you Canek.

On Tue, Jul 30 2013, Canek Peláez Valdés wrote:

> On Mon, Jul 29, 2013 at 7:56 PM,  <gottlieb@nyu.edu> wrote:
>
>> I am a gnome-3 user, who wants to continue with gnome-3.
>> [ I described my current state--beginning of wiki ]
>
> Sounds reasonable.
>
>> [ I asked about /etc/mtab and /proc/self/mounts
>
> If you switch to systemd, you will need to make /etc/mtab a symlink to
> /proc/self/mounts.

Done.

>> After that comes the big one
>>
>> emerge systemd
>> USE="... systemd ..."
>> emerge --newuse ...  [ a change from previous msg ]
>> /etc/init.d/udev restart
>>
>> Can the system be rebooted at this point (I realize init will still not
>> use systemd) or must the entire conversion (including changing init) be
>> completed before the system is bootable?  I am hoping it is the former.
>
> If you reboot [now], I don't believe there is any chance your system
> will boot up correctly.

I see.

> /etc/init.d/udev is installed by sys-fs/udev; sys-apps/systemd doesn't
> provide anything similar.

I don't understand.  *After* installing systemd (and setting the USE and
executing the emerge --newuse ...), the wiki tells you to 
   /etc/init.d/udev restart
Emerging systemd unmerges udev so how can I do the restart?

> I recommend installing everything necessary (and uninstalling
> everything that is not) before trying the reboot.

How far do I have to get in the wiki?  I am hoping to do smaller chunks
so that if I have to back out a step (using a bootable CD) to restore
"bootability" to the system, it won't take too long.

In particular do I have to switch init to /usr/lib/systemd/systemd
before I can boot.

I know you have had systemd installed for a long time.  Did you always
have the init= line or were you for a while running openrc with systemd
installed?

> Also, I would do the whole shebang in a one step, removing all the
> masked packages you did. You can try to boot to multi-user.target
> instead of graphical.target, if you want to test that systemd works
> correctly independently of GNOME.

I am not so worried about gnome coming up.  If the system boots and I
can get the 6 text terminals, I can survive for quite a while with emacs
and gnus.

Again thanks for the help.

allan

Re: [gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update

[Canek Peláez Valdés]

On Tue, Jul 30, 2013 at 8:31 PM,  <gottlieb@nyu.edu> wrote:
> First and foremost, thank you Canek.
>
> On Tue, Jul 30 2013, Canek Peláez Valdés wrote:
>
>> On Mon, Jul 29, 2013 at 7:56 PM,  <gottlieb@nyu.edu> wrote:
>>
>>> I am a gnome-3 user, who wants to continue with gnome-3.
>>> [ I described my current state--beginning of wiki ]
>>
>> Sounds reasonable.
>>
>>> [ I asked about /etc/mtab and /proc/self/mounts
>>
>> If you switch to systemd, you will need to make /etc/mtab a symlink to
>> /proc/self/mounts.
>
> Done.
>
>>> After that comes the big one
>>>
>>> emerge systemd
>>> USE="... systemd ..."
>>> emerge --newuse ...  [ a change from previous msg ]
>>> /etc/init.d/udev restart
>>>
>>> Can the system be rebooted at this point (I realize init will still not
>>> use systemd) or must the entire conversion (including changing init) be
>>> completed before the system is bootable?  I am hoping it is the former.
>>
>> If you reboot [now], I don't believe there is any chance your system
>> will boot up correctly.
>
> I see.
>
>> /etc/init.d/udev is installed by sys-fs/udev; sys-apps/systemd doesn't
>> provide anything similar.
>
> I don't understand.  *After* installing systemd (and setting the USE and
> executing the emerge --newuse ...), the wiki tells you to
>    /etc/init.d/udev restart
> Emerging systemd unmerges udev so how can I do the restart?

The wiki is wrong. The script /etc/init.d/udev is part of sys-fs/udev,
which you need to uninstall before installing systemd. Perhaps it's
CONFIG_PROTECT'd, but anyway sys-fs/udev and sys-apps/systemd install
the udev binary in different directories, so the script is basically
useless after the switch.

>> I recommend installing everything necessary (and uninstalling
>> everything that is not) before trying the reboot.
>
> How far do I have to get in the wiki?  I am hoping to do smaller chunks
> so that if I have to back out a step (using a bootable CD) to restore
> "bootability" to the system, it won't take too long.

I thing you should do it all in one big step. sys-fs/udev and
sys-apps/systemd conflict each other pretty badly, and the latter
changes the init program; also, several programs can work with OpenRC,
or systemd, but not both.

Doing it in "smaller chunks" seems to me a great recipe to making your
system unbootable.

> In particular do I have to switch init to /usr/lib/systemd/systemd
> before I can boot.

Yeah, I believe you have to.

> I know you have had systemd installed for a long time.  Did you always
> have the init= line or were you for a while running openrc with systemd
> installed?

No, I did the switch and almost immediately started to work in the
gentoo-systemd-only overlay[1], which I just deprecated. At the very
beggining having OpenRC could wreck the whole boot, since some stuff
(barely documented at the time) called scripts in /etc/init.d
seemingly at random, and at the time OpenRC scripts didn't even
consider that the machine was not being booted with OpenRC.

I do have an old server *running* with systemd and with OpenRC still
installed; it's my last machine waiting to switch to the new
service-manager virtual.

>> Also, I would do the whole shebang in a one step, removing all the
>> masked packages you did. You can try to boot to multi-user.target
>> instead of graphical.target, if you want to test that systemd works
>> correctly independently of GNOME.
>
> I am not so worried about gnome coming up.  If the system boots and I
> can get the 6 text terminals, I can survive for quite a while with emacs
> and gnus.

GNUS? Damn, that brings back some memories. I stopped using it for
reading email in 2002 or 2003, when Evolution become mature enough.

If you are comfortable with only a console, do the switch from a VT. A
lot of stuff will stopping working *during* the transition, and will
not become functional again until you reboot.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update

[Graham Murray]

Canek Peláez Valdés <caneko@gmail.com> writes:

> The wiki is wrong. The script /etc/init.d/udev is part of sys-fs/udev,
> which you need to uninstall before installing systemd. Perhaps it's
> CONFIG_PROTECT'd, but anyway sys-fs/udev and sys-apps/systemd install
> the udev binary in different directories, so the script is basically
> useless after the switch.

It is pulled in by sys-fs/udev-init-scripts which is a dependency of
systemd[openrc]. So the Wiki is correct.

Re: [gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update

[gottlieb]

On Wed, Jul 31 2013, Graham Murray wrote:

> Canek Peláez Valdés <caneko@gmail.com> writes:
>
>> The wiki is wrong. The script /etc/init.d/udev is part of sys-fs/udev,
>> which you need to uninstall before installing systemd. Perhaps it's
>> CONFIG_PROTECT'd, but anyway sys-fs/udev and sys-apps/systemd install
>> the udev binary in different directories, so the script is basically
>> useless after the switch.
>
> It is pulled in by sys-fs/udev-init-scripts which is a dependency of
> systemd[openrc]. So the Wiki is correct.

But the wiki doesn't specify emerging system with the openrc flag.
Should I suggest that the wiki be modified.

To be sure I understand.  At this point I would have already

1. merged systemd (perhaps with USE="openrc ..."
2. set USE="systemd ..."
3. updated with emerge --newuse --deep --verbose--ask @world
   * The wiki doesn't say --update; is that correct?

I would *not* have
1. added init=/usr/lib/systemd/systemd to the kernel line in grub
2. rebooted.

A related question.  Am I correct in believing that once I do the
   emerge ... @world
above I can *not* reboot until I have added the
   init=...
phrase to the kernel line in grub (and thus committed to systemd not OpenRC)

Thanks to all
allan

Re: [gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update

[Canek Peláez Valdés]

On Wed, Jul 31, 2013 at 5:09 AM, Graham Murray <graham@gmurray.org.uk> wrote:
> Canek Peláez Valdés <caneko@gmail.com> writes:
>
>> The wiki is wrong. The script /etc/init.d/udev is part of sys-fs/udev,
>> which you need to uninstall before installing systemd. Perhaps it's
>> CONFIG_PROTECT'd, but anyway sys-fs/udev and sys-apps/systemd install
>> the udev binary in different directories, so the script is basically
>> useless after the switch.
>
> It is pulled in by sys-fs/udev-init-scripts which is a dependency of
> systemd[openrc]. So the Wiki is correct.

Yeah, sorry: my bad. I completely forgot about the openrc USE flag.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update

[Canek Peláez Valdés]

On Wed, Jul 31, 2013 at 9:28 AM,  <gottlieb@nyu.edu> wrote:
> On Wed, Jul 31 2013, Graham Murray wrote:
>
>> Canek Peláez Valdés <caneko@gmail.com> writes:
>>
>>> The wiki is wrong. The script /etc/init.d/udev is part of sys-fs/udev,
>>> which you need to uninstall before installing systemd. Perhaps it's
>>> CONFIG_PROTECT'd, but anyway sys-fs/udev and sys-apps/systemd install
>>> the udev binary in different directories, so the script is basically
>>> useless after the switch.
>>
>> It is pulled in by sys-fs/udev-init-scripts which is a dependency of
>> systemd[openrc]. So the Wiki is correct.
>
> But the wiki doesn't specify emerging system with the openrc flag.
> Should I suggest that the wiki be modified.
>
> To be sure I understand.  At this point I would have already
>
> 1. merged systemd (perhaps with USE="openrc ..."
> 2. set USE="systemd ..."
> 3. updated with emerge --newuse --deep --verbose--ask @world
>    * The wiki doesn't say --update; is that correct?
>
> I would *not* have
> 1. added init=/usr/lib/systemd/systemd to the kernel line in grub
> 2. rebooted.

I think (now that Graham correctly pointed that you can preserve
/etc/init.d/udev with the openrc USE flag), that then you should
restart udev.

> A related question.  Am I correct in believing that once I do the
>    emerge ... @world
> above I can *not* reboot until I have added the
>    init=...
> phrase to the kernel line in grub (and thus committed to systemd not OpenRC)

That, I believe, is correct.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update

[gottlieb]

Thank you Canek and Graham.

I apologize for all the questions, but one still remains.

The wiki says to
   emerge --ask --changed-use --deep @world

One could make small additions/changes, but there is a large one that is
not clear.  Should you have --update ?

allan

Re: [gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update

[Canek Peláez Valdés]

On Wed, Jul 31, 2013 at 12:43 PM,  <gottlieb@nyu.edu> wrote:
> Thank you Canek and Graham.
>
> I apologize for all the questions, but one still remains.
>
> The wiki says to
>    emerge --ask --changed-use --deep @world
>
> One could make small additions/changes, but there is a large one that is
> not clear.  Should you have --update ?

I would do it, just in case.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 852 bytes --]

On Wed, 31 Jul 2013 13:43:55 -0400, gottlieb@nyu.edu wrote:

> The wiki says to
>    emerge --ask --changed-use --deep @world
> 
> One could make small additions/changes, but there is a large one that is
> not clear.  Should you have --update ?

--changed-use will re-emerge any packages affected by the changed flags,
and update any of those for which new versions exist. --update will also
update any other packages on your system, unaffected by the switch to
systemd, for which updates are available. I think the Wiki advice is
wise, leave the other updates until you have gone through the systemd
conversion and made everything is working. Adding extra changes increases
the chance of things going wrong, and the number of paces you have to
look if they do.


-- 
Neil Bothwick

Sir! Romulan warbird decloaki»®õ÷üÁ NO CARRIER

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] [~amd64] Some possibly (?) helpful hints re the big gnome-3.8 update

[gottlieb]

On Wed, Jul 31 2013, gottlieb@nyu.edu wrote:

> I apologize for all the questions, but one still remains.
>
> The wiki says to
>    emerge --ask --changed-use --deep @world
>
> One could make small additions/changes, but there is a large one that is
> not clear.  Should you have --update ?

Thank you canek and neil.
allan