http://www.gnomedesktop.org/article.php?sid=1850 gnome 2.6.2 has been officially released. Many of the bug fix releases for each individual part of gnome have been out for a long time. I have been updating these in my local portage for some time, and they all appear to work without problem, simply by renaming the previous 2.6* ebuilds.
I would be interested to see if there is a way to upgrade to Gnome 2.6.2 in ~x86. Are any of these packages currently being tested in Portage ? Either seperately, or as a whole ?
[Attempt to exercise this bug as a meta bug for this subject (per my email to gentoo-dev)]: If anyone knows of reasons (ie other bugs here in Gentoo bugzilla) that Gnome 2.6.2 cannot be marked arch stable, please make this bug depend on them. Obviously we need to get ebuilds corresponding to the 2.6.2 release into ~arch first... AfC
some issues before moving anything to stable: (just the ones that struck me on a browse of bugs as things that need to be dealt with ) http://bugs.gentoo.org/show_bug.cgi?id=51699 http://bugs.gentoo.org/show_bug.cgi?id=45228 http://bugs.gentoo.org/show_bug.cgi?id=47018 http://bugs.gentoo.org/show_bug.cgi?id=56323 http://bugs.gentoo.org/show_bug.cgi?id=53075 http://bugs.gentoo.org/show_bug.cgi?id=55923 http://bugs.gentoo.org/show_bug.cgi?id=55708 http://bugs.gentoo.org/show_bug.cgi?id=56329
#55923 can be fixed easily - requires a simple dependancy update in the ebuild. There seem to be a lot of issues with "doc" stuff. Surely this can be fixed at the same time as bumping all the ebuilds to gnome 2.6.2 versions.
yeah, I know some of them are easy to fix, however others are not (for the people complaining about gimp not going stable / in tree, look at the gcc issues, hardened and pic ones. ) The doc issues are a big pain, since I really have no clue on what is wrong there, and haven't been able to relibably reproduce it, and its actually not direct "Gnome" land, but text-markup who know about such.
I'd have to say that 47018, the one about aterm cut and paste in aterm, is not a blocker [to Gnome 2.6.2 release. I mean, if cut and paste didn't work between gnome-terminal and epiphany, that'd be one thing. But aterm? There is the vaguest of possibilities that the problem is related to GTK-2.4.x, but GTK-2.4 largely works, and has been out for a while; it's not like we're going to pull GTK! Just MHO. AfC
55708 is not a blocker. It's a quality issue, sure, but does not impact the migration of 2.6.2 to ~arch testing. [After all, it's there all over the place now in existing unmasked 2.6.0 builds] AfC
I think we should get the ebuilds for 2.6.2 into ~arch and work on closing the existing bugs from there. It would be redundant to put all the work into 2.6.1 at this stage fixing bugs, when quite possibly 2.6.2 could fix some of these by simple package updates. You also run the risk of fixing 2.6.1 and those fixes causing problems running 2.6.2. Using the latest official release and checking bugs off is a better work process IMO. I believe USE="doc" is related to documentation to install with a particular package. I could be wrong there, but I don't like USE="doc" should be a blocker for anything, but more akin to a enhancement request for adding package documentation by the author/maintainer.
Agree that most of them aren't blocking release, but things that need to be dealt with before going from ~x86 to x86, especially the "compile aborts with USE="doc"" issues. Those are blockers for mainline stability. Do note that nothing here has been listed as blocking me updating to .2 release, except the time ;) However, people also wanted .1 to go into stable, and that has worse problems.
for those who didn't notice, 2.6.2 is in ~ barring a broken update for gnome-speech (which was masked due to freetts on some arches) and a completely unworking intltool release (configure broken ), amd64 issues with libbonobo, some borkage due to gst-plugins-flac isn't in ~ for arches and therefore limiting it in nautilus, things should be okayish. Will look at the latest gtk+ release as well, seems this might have some things updated with regards to the outstanding whine about missing icon-themes (stock icons included)
Can we look into getting gdm 2.6.x into ~ for the sake of consistancy?
It strikes me that glib-2.4.4 and gtk+-2.4.4 should be built before the rest of the gnome stuff that gnome-2.6.2 brings in. (The dependency graph I got would have brought gtk+ in about 8th, and glib almost last!) Maybe make gnome-applets, gnome-panel, and gnome-desktop depend on >= these versions? >= 2.4.1? Or does it matter? AfC
technically it doesn't really matter a) they aren't part of gnome 2.6.2 b) they are binary compatible the only reason they got into the meta was the timing (Released the same day I made the meta) and the fact that they fix a couple of bugs that are good to have in.
spider, do you have a definitive list of all the packages that we can put in package.keywords for ~arch so that we can make sure all the packages are there for 2.6.2 I'm not sure what the 'best' or 'safest' way is to work out dependencies for 2.6.2, but I want to add them all to package.keywords to make sure I'm not bug testing old packages on Gnome 2.6.2
I merged in the 2.6.2 meta - so far so good. The one stock icon glitch I was aware of seems to have gone away. AfC
the meta contains all the necessary parts of gnome 2.6.2, so if that merges okay, you're in the clear.
Not strictly within the meta, but glade 2.6.0 built and merged fine. I've been using it for development and it seems solid. Gnome 2.6.2 remains solid for me, although I have not tried attacking the +doc problem yet. AfC
With a thought of gdm: its versioning is now synced with the rest of the gnome. Some requests of having new ebuilds for it into portage and some attempts on making them (bug #51374) has been made, but still it seems like little to no interest has come from the gentoo-gnome-team. Why?
We should close this now, no? AfC
yep.. you might be interested in the new tracker for 2.6.3 (#59768)
