tracker bug for 2.14 issues & things we target for this release.
Deskbar applet should be part of GNOME 2.14 right?
GNOME 2.14.0 beta 1 (2.13.90) should be out today (http://mail.gnome.org/archives/devel-announce-list/2006-January/msg00008.html) as planned (http://live.gnome.org/TwoPointThirteen).
This will be into the official tree like 2.11.90 for the previous 2.12 release? I hope yes :D
we already have an overlay up and running with the 2.13 stuff.
2.12.3 comes out soon.
(we will wait until 2.12.3 is stable before putting the 2.13 RC into portage)
the official overlay does not have anon access, but dang sync's his ( for now manually ) with the official overlay at somewhat regular intervals.
dang's is at https://nemesis.fprintf.net/svn/gnome-experimental/
please remember that until it makes its way into portage, it is unsupported and in as-is format.
Yes I know, if "a" package isn't into the official portage tree isn't supported.
I've just asked because the last time you putted 2.11.90 into the tree when was out, I hoped the same this time ;)
Please use some bits of #88978 for overlay's fast-user-switch-applet
A little question, can I use the BMG overlay? is there a copy of these ebuild in that overlay? or are these ebuilds different?
I don't know if BMG is pulling these or if they're rolling their own, but these are maitained by the gnome herd, not the BMG guys. Unless they're pulling them from us, they're completely separate.
You might want to add bug 122494, bug 122562, bug 122566 - issues with the gnome-terminal TERM="gnome" change (bug 91055).
in connecttion with bug #120310
could you please make the yelp depend again on firefox and mozilla in the overlay, leaving alone the fact that the gecko-sdk thing will not work if you don't have some real path having gtkmozembed.so in it exported to ld.so.conf - read binary mozilla/firefox or simply mozilla-source install, why will someone want to install gecko-sdk if he has firefox-source install and all could work just perfectly well with it.
Is it possible to make totem and librsvg depend on firefox? I'm using firefox-source, and the of course it using gecko-sdk, why should I using both to compile totem and librsvg? Each of this(firefox and gecko-sdk) cost me more than one hour to build.
I mean gnome, sorry, epiphany need firefox to build, but totem and librsvg need gecko-sdk. ( at least in gnome-2.12.3 )
You might want want to add bug 126241 gnome-media access violation.
we are in the process of adding the 2.14 packages to package.mask as they are released upstream.
Shouldn't ekiga be included in the gnome meta package now? AFAIK it was an official part of the desktop platform for GNOME 2.14.
It should be included as well as pessulus, I think.
http://bugs.gentoo.org/show_bug.cgi?id=127539 and http://bugs.gentoo.org/show_bug.cgi?id=126758 should be added I think.
Bug #124131 should not be blocking gnome-2.14 since it only affects 2.12. the problem is fixed in 2.14.
Will there be an extra gnome-light-2.14.0 ebuild?
(In reply to comment #18)
> Will there be an extra gnome-light-2.14.0 ebuild?
> kind regards
Gnome 2.14.1 is released (just if some of you missed that).
gnome-extra/gnome-screensaver-2.14.x is missing in meta /usr/portage/gnome-base/gnome/gnome-2.14.x.ebuild, right?
When is it going to come to unstable?
gnome-base/gnome-desktop-188.8.131.52 will fail to build/configure if not set +doc USE flag (that will pull gnome-doc-utils as DEPEND package). I feel this is not correct done in ebuild. "doc" use flag is for extra documentation and shouldn't bother compilation process as far as I understand gnome ebuild decisions.
What about these two ?
I think they should be considered.
considered for what, they're both problems outside of gnome.
> considered for what, they're both problems outside of gnome.
Well, they both come in as a (indirect) dependancy for gnome-base/gnome-2.14 ...
gedit-2.14 (with USE=python) depends on gnome-python-desktop-2.14.0
totem-1.4.0 (with USE=nsplugin) depends on gecko-sdk
I'm sorry to disturb again, but please have a look at bug 130808.
Are the remaining bugs so bad as to keep the block? I might be wrong, but they don't look so important like to block 2.14 in unstable...
moved to unstable as of about 6 hours ago.
bug 131695 is related to an indirect gnome-2.14 dependency that most people would want (beagle with USE=evo for indexing of their Evolution mails).
Adding myself as yet another testing goon (and probably the one that ends up marking gnome 2.14 for x86.. :p...)
Why has #120958 been added?
As far as I am concerned, that bug is invalid because totem in Gnome 2.14 does not profess to play dvd's. Making it a blocker on getting Gnome 2.14 in stable is stupid.
Re: comment #32 - I imagine that's because totem in 2.12 *does* have a DVD USE flag. Losing function in upgrading might be a legitimate thing to consider in a tracker. Now if you want to talk silly bugs, there are others in here that have existed in 2.12 and before.
Gnome 2.16 is stable now. So we can start forgeting 2.14.
Thanks everyone for your help we'll meet you again with Gnome 2.16 i hope :).