I was wondering what the status if saucy is, is it stable enough to use already?

Best,
Bela

It might be, but probably not
Haven't done a test build on it in a few weeks but the status of it then was that systemd's bugs and integration into Gentoo/Gnome-3.8 were still being sorted in the main tree.

Everything worked, albeit slowly due to systemd (gnome-session+dbus+systemd seemed to do so much talking to each other that the function of the desktop became secondary).
And none of the dash lenses worked, though that can probably be sorted more easily.

Since then the Gnome team have done a lot of work on systemd and getting gnome-3.8 unmasked, so the state of play has probably improved (I hope).
Only one way true way to find out and is to try it

And I can't say this enough, if you enjoy using Unity and hacking on ebuilds as much as we do, then join us in maintaining and improving unity-gentoo (currently we have only two active members, myself and renegart).

I'm a little confused. Is there an easy way to put off 3.8 and keep using unity-gentoo? It's hard to fight the current though when the world keeps progressing. No hurry to get to gnome 3.8, but I would like to be able to emerge updates and other apps without too much pain.

Any suggestions? I would love to help with the ebuilds but I don't think I have the skills or the free time.

I'm a little confused. Is there an easy way to put off 3.8 and keep using unity-gentoo? It's hard to fight the current though when the world keeps progressing. No hurry to get to gnome 3.8, but I would like to be able to emerge updates and other apps without too much pain.

Any suggestions? I would love to help with the ebuilds but I don't think I have the skills or the free time.

Regards

I didn't get your point. Currently gnome-3.8 is in testing stage and will not be merged as long as you don't want it.

The current Raring version of Unity (masked with ~) is still using gnome 3.6 and the corresponding keyword files 'unity-portage.p{keywords, use, mask, unmask}' in the overlay take care only gnome-3.6 packages are merged. As long as you link this files to /etc/portage and don't unmask any gnome 3.8 packages by yourself everything should be fine.

The upcoming Saucy version will use gnome 3.8, but it's not ready yet and you have to use other keyword files.

Last edited by renegart on Fri Aug 09, 2013 1:49 pm; edited 1 time in total

Saucy is now stable enough for everyday use and testing from the overlay, so feel free to try it!!
Instructions on how to do so are contained within the 1st post of this thread.

We've done a fair amount of work over the last couple of weeks and is now to a point where it smoothly integrates with gnome-3.8 as it lies within the main portage tree.
Any issues don't hesitate to report them here or open an issue on the github page.

It's also been brought to attention that a few people are reporting issues on the [gentoo-user] mailing lists ?
Not having the time to subscribe and sift through the many many messages that get sent to that list, your message will more likely be read and replied to if directly posted here or on the github page, thanks!

Saucy is now stable enough for everyday use and testing from the overlay, so feel free to try it!!

Excellent! Thank you! I currently trying to switch to saucy, but I’m running into the problem that apparently systemd is now required (instead of udev??) w/ GNOME 3.8. Are you running systemd already or is there a workaround?

Saucy is now stable enough for everyday use and testing from the overlay, so feel free to try it!!

Excellent! Thank you! I currently trying to switch to saucy, but I’m running into the problem that apparently systemd is now required (instead of udev??) w/ GNOME 3.8. Are you running systemd already or is there a workaround?

Best,
Bela

We run systemd.
I don't guess there is a work around to use gnome-3.8 without systemd.
And on my test machine for Saucy I don't have any problems with it. So give it a try

Saucy is now stable enough for everyday use and testing from the overlay, so feel free to try it!!

Excellent! Thank you! I currently trying to switch to saucy, but I’m running into the problem that apparently systemd is now required (instead of udev??) w/ GNOME 3.8. Are you running systemd already or is there a workaround?

Best,
Bela

We run systemd.
I don't guess there is a work around to use gnome-3.8 without systemd.
And on my test machine for Saucy I don't have any problems with it. So give it a try

OK, that’s what I thought. I already gave up trying to compile it w/o systemd and I’m switching now

Anybody else having this problem? I tired the alternative method by using gconf-editor, but that doesn’t work.

Thanks,
Bela

The 'sticky-edges' option is deliberately not present in gnome-control-center because we are using gnome-control-center-3.8 from Ubuntu Gnome team's staging code.
They haven't updated the relevant 51_unity_options_in_display_panel.patch yet so it's disabled from being applied.

You'll see the 'sticky-edges' option in native Ubuntu Saucy because they're still using gnome-control-center-3.6.
They're able to mix gnome-3.6 and gnome-3.8 because they just ship the binaries, but it's not an option for us as we need everything to compile together.
We include gnome-control-center-3.8 for system sanity because while gnome-control-center-3.6 could compile against the gnome-3.8 packages, it would mostly segfault at runtime.

I would guess the option should show up within the next few weeks.
Did you try setting the pressure and velocity options in CCSM as described in that thread too ?

Due to the growing length of this thread, we now have a #unity-gentoo channel created on Freenode's IRC network.
Feel free to join us there for any support, issues or just chat in general about the Unity desktop on Gentoo.

Thanks for providing the overlay. I run an ~amd64 system and I'm trying to install saucy. I've already worked around a number of problems, but I figured I'd try to be more useful and mention them here when I find more.

dev-util/xxd-1.10 - source file doesn't download/doesn't exist. As far as I can tell it's gone uni-erlangen.de forever since they moved servers and deleted old files in the process. I couldn't find the file for download anywhere else, so I avoided the problem by disabling the webapps USE-flag on unity-meta.
dev-libs/libappindicator-12.10.1a_p0_p01-r2 - didn't compile with vala-0.22.0. masking it and using vala-0.20.1 instead worked
app-accessibility/sphinxbase-0.8 - I got automake errors, "error: using '$(srcdir)' in TESTS is currently broken.". I solved it by running "WANT_AUTOMAKE="1.12" emerge -1 sphinxbase". There's already a bug filed.
unity-lens-applications-7.1.0_p0_p01-r3 - "configure.: error: unable to find xapian.h. Please install the package libxapian-dev". Unfortunately there was no libxapian-dev to emerge, but masking xapian-1.3.1-r1 and using 1.2.15 instead fixed it.
gnome-control-center-unity-1.3_p0_p01-r1 gave me a lot of sandbox errors. See log below:

Thanks for providing the overlay. I run an ~amd64 system and I'm trying to install saucy. I've already worked around a number of problems, but I figured I'd try to be more useful and mention them here when I find more.

dev-util/xxd-1.10 - source file doesn't download/doesn't exist. As far as I can tell it's gone uni-erlangen.de forever since they moved servers and deleted old files in the process. I couldn't find the file for download anywhere else, so I avoided the problem by disabling the webapps USE-flag on unity-meta.
dev-libs/libappindicator-12.10.1a_p0_p01-r2 - didn't compile with vala-0.22.0. masking it and using vala-0.20.1 instead worked
app-accessibility/sphinxbase-0.8 - I got automake errors, "error: using '$(srcdir)' in TESTS is currently broken.". I solved it by running "WANT_AUTOMAKE="1.12" emerge -1 sphinxbase". There's already a bug filed.
unity-lens-applications-7.1.0_p0_p01-r3 - "configure.: error: unable to find xapian.h. Please install the package libxapian-dev". Unfortunately there was no libxapian-dev to emerge, but masking xapian-1.3.1-r1 and using 1.2.15 instead fixed it.

Hello alacheesu,
the issues above should be fixed. The sandbox issue is not reproducible at my side, maybe shiznix has an idea going wrong.

If you still have (other) problems feel free to join us at IRC channel

My deep world update is blocked since weeks. Today I tried again with a whole new set of /etc/portage/package.*/* files.

Non-saucy I end up here:

Code:

The following USE changes are necessary to proceed:
(see "package.use" in the portage(5) man page for more details)
# required by x11-libs/gtk+-2.24.22
# required by dev-python/pygtk-2.24.0-r3
# required by dev-vcs/git-1.8.1.5-r1[python,gtk]
# required by sys-devel/gettext-0.18.2[git]
# required by dev-libs/glib-2.36.4-r1
# required by dev-libs/atk-2.8.0
>=x11-libs/libXi-1.7.2 abi_x86_32
# required by x11-libs/gtk+-2.24.22
# required by dev-python/pygtk-2.24.0-r3
# required by dev-vcs/git-1.8.1.5-r1[python,gtk]
# required by sys-devel/gettext-0.18.2[git]
# required by dev-libs/glib-2.36.4-r1
# required by dev-libs/atk-2.8.0
=x11-libs/libXfixes-5.0.1 abi_x86_32

Use --autounmask-write to write changes to config files (honoring
CONFIG_PROTECT). Carefully examine the list of proposed changes,
paying special attention to mask or keyword changes that may expose
experimental or unstable packages.

emerge: there are no ebuilds built with USE flags to satisfy ">=x11-proto/xextproto-7.0.3[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]".
!!! One of the following packages is required to complete your request:
- x11-libs/libXi-1.7.2::gentoo (Change USE: -abi_x86_32)
(dependency required by "x11-libs/libXi-1.7.2" [ebuild])
(dependency required by "x11-libs/gtk+-2.24.22" [ebuild])
(dependency required by "dev-python/pygtk-2.24.0-r3" [installed])
(dependency required by "dev-vcs/git-1.8.1.5-r1[python,gtk]" [ebuild])
(dependency required by "sys-devel/gettext-0.18.2[git]" [installed])
(dependency required by "dev-libs/glib-2.36.4-r1" [ebuild])
(dependency required by "dev-libs/atk-2.8.0" [ebuild])

So the conflict here is:

Code:

- x11-libs/libXi-1.7.2::gentoo (Change USE: -abi_x86_32)

vs.

Code:

>=x11-libs/libXi-1.7.2 abi_x86_32

and going for saucy I get stuck here:

Code:

The following USE changes are necessary to proceed:
(see "package.use" in the portage(5) man page for more details)
# required by x11-libs/cairo-1.12.16
# required by dev-libs/gobject-introspection-1.38.0::unity-gentoo[cairo]
# required by dev-libs/atk-2.8.0[introspection]
# required by dev-python/pygtk-2.24.0-r3
# required by dev-vcs/git-1.8.1.5-r1[python,gtk]
# required by sys-devel/gettext-0.18.2[git]
# required by dev-perl/Locale-gettext-1.50.0
# required by sys-apps/help2man-1.40.11[nls]
# required by sys-devel/automake-1.13.4
# required by dev-lang/python-3.2.5-r3
# required by app-admin/python-updater-0.11
>=media-libs/freetype-2.5.0.1 abi_x86_32

Use --autounmask-write to write changes to config files (honoring
CONFIG_PROTECT). Carefully examine the list of proposed changes,
paying special attention to mask or keyword changes that may expose
experimental or unstable packages.

The limitation here seems to be the new multilib.eclass and perhaps the way it is being used.

I don't think enabling both 64 and 32 ABIs globally for every package is the intended usage and is not necessary on a multilib system as most libs will need to be just one type installed that is native to the system.
The way I understand it, if you have a 64bit machine, set ABI_X86="64" and if a 32bit machine, set ABI_X86="32".
Any package that requires both 32 and 64 bit libraries to be installed, will automatically set and resolve it's needed +abi_x86_32 +abi_x86_64 USE depends.

Thanks for your reply. I got the ABI_X86 stuff from some howto I think. I removed it completely from make.conf now. I think there is no need to tell my 64bit hardware *explicitly* that I need 64bit packages mainly.

Saucy ends up in:

Code:

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

app-arch/bzip2:0

(app-arch/bzip2-1.0.6-r3::gentoo, ebuild scheduled for merge) pulled in by
app-arch/bzip2[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] required by (media-libs/freetype-2.5.0.1::gentoo, ebuild scheduled for merge)

(app-arch/bzip2-1.0.6-r3::gentoo, installed) pulled in by
(no parents that aren't satisfied by other packages in this slot)

It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously. If such a conflict exists in
the dependencies of two different packages, then those packages can
not be installed simultaneously. You may want to try a larger value of
the --backtrack option, such as --backtrack=30, in order to see if
that will solve this conflict automatically.

For more information, see MASKED PACKAGES section in the emerge man
page or refer to the Gentoo Handbook.

Thanks for your reply. I got the ABI_X86 stuff from some howto I think. I removed it completely from make.conf now. I think there is no need to tell my 64bit hardware *explicitly* that I need 64bit packages mainly.

Saucy ends up in:

Code:

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

app-arch/bzip2:0

(app-arch/bzip2-1.0.6-r3::gentoo, ebuild scheduled for merge) pulled in by
app-arch/bzip2[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] required by (media-libs/freetype-2.5.0.1::gentoo, ebuild scheduled for merge)

(app-arch/bzip2-1.0.6-r3::gentoo, installed) pulled in by
(no parents that aren't satisfied by other packages in this slot)

It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously. If such a conflict exists in
the dependencies of two different packages, then those packages can
not be installed simultaneously. You may want to try a larger value of
the --backtrack option, such as --backtrack=30, in order to see if
that will solve this conflict automatically.

For more information, see MASKED PACKAGES section in the emerge man
page or refer to the Gentoo Handbook.

Not sure about the bzip2 stuff... There is no abi_x86_32 abi_x86_64 use avilable for that package obviously.

The main problem is dev-qt/qtdbus:5 anyways I think. Do i need an extra qt overlay? Or should this be part of unity-gentoo?
I have only:

Code:

Available versions: (4) 4.8.4 ~4.8.5

available as it seems. Any hints?

Yes, you'll need to add the QT overlay to get QT5... 'layman -a qt'.

For the bzip2 problem, freetype-2.5.0.1 references abi_x86_32 abi_x86_64 for bzip2 and this is available in >=bzip2-1.0.6-r4
However, installing freetype-2.5.0.1 comes with it's own set of problems (see bugs.gentoo.org #487646 and #488222).

thank you! worked finally out after weeks. 522 packages to go.
EDIT: Compiling over night didn't work out. On one of the first few packages fails:

Code:

* Messages for package dev-libs/jsoncpp-0.5.0-r1:

* No Python implementation found for the build. This is usually
* a bug in the ebuild. Please report it to bugs.gentoo.org
* along with the build log.
* ERROR: dev-libs/jsoncpp-0.5.0-r1 failed (setup phase):
* No supported Python implementation installed.

Is this maybe a missing python dependency in th ebuild? This is what I have installed: