Bugzilla Bug 119872

tracker bug for 2.14 issues & things we target for this release.

Deskbar applet should be part of GNOME 2.14 right?
Bug #103785

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.

Please remove.

Will there be an extra gnome-light-2.14.0 ebuild?

kind regards

(In reply to comment #18)
> Will there be an extra gnome-light-2.14.0 ebuild?
> 
> kind regards
> 

Check http://bugs.gentoo.org/show_bug.cgi?id=128782

Gnome 2.14.1 is released (just if some of you missed that).
http://mail.gnome.org/archives/gnome-announce-list/2006-April/msg00027.html

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-2.14.1.1 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 ?
 #127075 https://bugs.gentoo.org/show_bug.cgi?id=127075
 #130140 https://bugs.gentoo.org/show_bug.cgi?id=130140
I think they should be considered.

Kind regards,
Guillaume

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).

Regards.

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 :).