Bug 199322 - stabilization of gnome 2.20, first pass
|
Bug#:
199322
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P1
|
|
Resolution: FIXED
|
Assigned To: gnome@gentoo.org
|
Reported By: leio@gentoo.org
|
|
Component: GNOME
|
|
|
URL:
|
|
Summary: stabilization of gnome 2.20, first pass
|
|
Keywords: STABLEREQ
|
|
Status Whiteboard:
|
|
Opened: 2007-11-16 04:12 0000
|
it's time to start stabilizing gnome-2.20. as arches that want to have gnome
2.20 in the release will have to get things done really quickly, i split this
up a bit to allow starting of this work before i finish the rest of the list.
the list i'm going to attach contains mostly only bug fix releases and
translation updates and so on, that should be working just fine in combination
with gnome 2.18 as well, so they can be stabilized right away.
i will finish the list for the rest within 20 to 30 hours probably, at which
point i will file a second pass stabilization bug and make it depend on this
one. it would be nice if those arches that wish to have 2.20 in the release
have taken care of the list attached here by then.
no arch specific lists this time right now, because my modifier keys suddenly
stopped working for some reason on my unstable tree system. however the
attachment contains a clear lines up table - eshowkw style but with arch names
written out on each line - so it shouldn't be hard to see your list there.
obviously bug 198845 should be taken care of first if it isn't already.
so, again, if you would like to see gnome 2.20 in the release, like i do, then
this is unfortunately urgent. sorry.
I can take care of this on Saturday evening CET. So if anyone wants to do it
before, I can tell that most from the list run stable on x86.
arm/sh done by Mike...what do you need s390 and m86k for, Gnome team?
(In reply to comment #9)
> arm/sh done by Mike...what do you need s390 and m86k for, Gnome team?
Exactly what is listed in the attachment.
I don't see any ChangeLog entries saying that arm/sh is done on any of the
packages.
(In reply to comment #10)
> (In reply to comment #9)
> > arm/sh done by Mike...what do you need s390 and m86k for, Gnome team?
> Exactly what is listed in the attachment.
Sorry, missed it. They are done.
> I don't see any ChangeLog entries saying that arm/sh is done on any of the
> packages.
Check again. The SpanKY has no need for ChangeLog entries:
vapier 07/12/11 11:02:58
Modified: cairomm-1.4.4.ebuild
Log:
arm/sh stable
(Portage version: 2.1.4_rc9)
Revision Changes Path
1.8 dev-cpp/cairomm/cairomm-1.4.4.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-cpp/cairomm/cairomm-1.4.4.ebuild?rev=1.8&view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-cpp/cairomm/cairomm-1.4.4.ebuild?rev=1.8&content-type=text/plain
diff :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-cpp/cairomm/cairomm-1.4.4.ebuild?r1=1.7&r2=1.8
Index: cairomm-1.4.4.ebuild
===================================================================
RCS file: /var/cvsroot/gentoo-x86/dev-cpp/cairomm/cairomm-1.4.4.ebuild,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- cairomm-1.4.4.ebuild 24 Nov 2007 15:03:15 -0000 1.7
+++ cairomm-1.4.4.ebuild 11 Dec 2007 11:02:57 -0000 1.8
@@ -1,6 +1,6 @@
# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/dev-cpp/cairomm/cairomm-1.4.4.ebuild,v 1.7
2007/11/24 15:03:15 jer Exp $
+# $Header: /var/cvsroot/gentoo-x86/dev-cpp/cairomm/cairomm-1.4.4.ebuild,v 1.8
2007/12/11 11:02:57 vapier Exp $
inherit eutils
@@ -10,7 +10,7 @@
LICENSE="GPL-2"
SLOT="0"
-KEYWORDS="alpha amd64 ~arm hppa ia64 ppc ppc64 ~sh sparc x86 ~x86-fbsd"
+KEYWORDS="alpha amd64 arm hppa ia64 ppc ppc64 sh sparc x86 ~x86-fbsd"
IUSE="doc examples"
RDEPEND=">=x11-libs/cairo-1.4.0"
(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #9)
> > > arm/sh done by Mike...what do you need s390 and m86k for, Gnome team?
> > Exactly what is listed in the attachment.
>
> Sorry, missed it. They are done.
>
> > I don't see any ChangeLog entries saying that arm/sh is done on any of the
> > packages.
>
> Check again. The SpanKY has no need for ChangeLog entries:
This is a violation of existing policies. I am not going to waste my time on
waiting on cvs log to gets its output in 30 seconds. Yet I have to do it,
because I don't know if a package that I'm being maintained is being touched
for stabling or screwing something up without a ChangeLog entry.
(In reply to comment #12)
> > Check again. The SpanKY has no need for ChangeLog entries:
> This is a violation of existing policies. I am not going to waste my time on
> waiting on cvs log to gets its output in 30 seconds. Yet I have to do it,
> because I don't know if a package that I'm being maintained is being touched
> for stabling or screwing something up without a ChangeLog entry.
Sorry, not my fault, I just do his job by unccing and closing several bugs.
dev-python/pygobject-2.14.0 is not done for arm and s390. Beats me why s390 has
a keyword in the first place, but it's holding up potential 2.12.0 cleanout in
the future.
pygtk and some others seem missing too for arm/sh. Don't have time right now to
make a complete list of what's left - but everything is certainly not completed
yet
here are some details about what is still needed to do to complete this bug and
start cleaning the tree from old ebuilds.
mips, please keyword the mentionned release of media-sound/esound,
net-libs/libsoup and x11-libs/vte
ppc-macos, please keyword gnome-extra/libgsf-1.14.7 or tell us if it's ok to
remove it while cleaning old releases or libgsf
ppc64, please have a look at keywording
>=gnome-extra/gnome-power-manager-2.18.3-r1
thanks for your attention
(In reply to comment #17)
> ppc64, please have a look at keywording
> >=gnome-extra/gnome-power-manager-2.18.3-r1
we will mark it stable once bug #176380 is solved.
eva: please drop the ppc-macos keyword where necessary to do your cleaning.
waaaa, joy, arm/sh/s390 are finally done, without changelog entry nor notifying
us as usual...
Closing