Gnome 2.28.1 full steam

My CIA profile went from about one commit every 17.35 housr to one every 16.56. The difference does not seem big but the calculation is diluted on about 6 years due to a KDE dev sharing the same nick. This amounts to 158 commits tonight.

~arch is now at about 85% of completeness for Gnome 2.28.1, a few commits are missing due extra complexity (hey it still took my 3 hours to do that). Beware that this release still has a few rough edges, especially policykit migration buts. So if you get cut, please come to bugzilla but do not expect sweet words and attention if I see comments like “dude why do you keep on breaking ~arch”. It’s ~arch, beat it.

Gnome 2.28.1 is there

Just added gnome-2.28.1 ebuild to the overlay, only had to keep two dependencies down. Since we are now finished with gnome-2.28 core, time to squash bugs, there is quite a number of them already, if you want to participate, just visit the overlay status/TODO or status/BUGS files, or visit gnome 2.28 official release tracker bug

Played with gnome-shell, kind of nice but still needs applet work done as I can’t use gnome-globalmenu applet anymore and I’d like to keep to vertical space real estate. Plus I don’t like the actual replacements for notification area and clock applet, they do less. I bit worried about speed in activities menu as well, it’s damn slow on my Core2@2.2Ghz which I can’t understand.

Also worked on some other ebuilds like geoclue, emerillion and seed, not easy on downstream packaging so delayed until further notice.

The unending tale

Ok guys, buckle up, I’ve finished reviewing Gnome 2.28 ebuilds except for the gnome-shell stuff. Now Gnome 2.28.1 is expected on wednesday so we can start bumping like crazy to be half-decently on time this time (feels like we’ll never be done with the catch-up). There are still quite a few problems with packages as noted in my papers and files under status/ in overlay but upgrade experience should be smoother.

If you are about to test the overlay, please keep us posted on your problems (or your non-problems too) by contacting us on #gentoo-desktop or by filling bug reports. Thanks again to everyone who kept the overlay updated during 2.27 cycle.

edit: fix typo thanks to remi.

To sleep or not to sleep

It’s over 1AM again, and I’m still not finished with Gnome 2.28 review. I’ve spent quite some time this weekend and tonight looking at what was wrong with gnote, gnome-system-monitor, gparted and a few other c++ apps suddendly starting to crash after I updated glib on Friday. Turns out something in the mm stack is doing something wrong so I filled Gnome bug #598209.

Updated to epiphany-2.28 since I got sick of epiphany-2.26 crashing when I wanted to make it remember a new password. Turns out it’s not as nice as I would have thought a nearly two years efforts would be. Lots of problems where loading of a page would stop in the middle of the process. I had to install firefox to fill bug reports and access the pages that fails. That’s quite a regression but upstream is now aware of it through Gnome bug #598115. Hopefully it’ll be fixed for Gnome 2.28.1.

I also spent some time cleaning up unneeded revisions in tree since I had to occupy myself when building all those c++ bindings. So where are we now, a bit less than 41 packages to go for review and about 80% of completeness on my gnome 2.28 status page.

News from the front

For those that might have been wondering where was that guy speaking about imminent stabilization of gnome 2.26, well I was taking some time off (sort of). The Gnome 2.26 situation got a bit better in the last weeks as due to the production of a release media, a lot of dependencies we were waiting on are finally getting stabilized. You can still see progress on bug #263083, closer than ever !

Since I can’t stand working on Gnome 2.26 anymore and since upstream has been kind enough to drop their new almost shiny 2.28, I started doing some QA on ebuilds in overlay before allowing them to move to the tree. Over 92 ebuilds, all of which are not necessarily interesting for gnome 2.28, I’ve currently reviewed 25 and that’s with current 65% of completeness of the ebuild bumps, so there is still quite some work, and don’t expect the overlay to be safe for use just yet.

One last word on 2.26, there will be a migration guide, it’s still getting a few modifications before it all goes public with stabilization but I’m spreading the word in the hope that we won’t see any new bugs concerning what has been documented.

On ELOG

Figured I’d visit forums today, seen at least 4 topics about lost menus while updating gnome-menus to 2.26.2, banged head 4 times because of users not reading elog messages and doing random fixes instead of searching the real cause of the change (in changelog, ebuild, elog, bugzilla). Good thing I have added that to the migration guide that will be up for stable users.

For those of you who still don’t know about elog, man make.conf.

Update: fix typo.

The road to stable

Many of you might wonder what the hell is the gnome team up to for not stabilizing gnome 2.26 yet. Well gnome 2.26.3 is finally as complete as I want it to be in tree (as of a few hours ago) and we can finally focus on writing an upgrade guide and working out a stabilization list. There are still a few rough edges, like the libsoup problem but things should be a lot smoother than earlier 2.26 revisions.

Update: There have been a few users and devs alike who asked me why is it that my status page only shows ekiga-2. The explanation is simple, since I can’t install ekiga-3, it doesn’t show up on the page. This is because of a bug which prevents me from compiling it that I should report with a solution soonish.

How to ease maintainance a bit

A foreword, this post is mainly aimed at fellow devs or people doing a lot of ebuild work.

As many of you might know, bumping ebuilds is often not the hardest thing to do but to ensure a good QA, a number of little things have to be checked. There are various ways to go with QA, in no specific order:

  • build with stricter package manager settings than usual (think FEATURES=”test stricter”)
  • carefully read/grep throug build.log (a lot more tedious)
  • verifying some files don’t contain known bugs (gtk-doc, intltool)
  • check that the user just gets the locales s/he asked for
  • check that no lib is using a built-in when it should use a system lib
  • check that RDEPEND/DEPEND actually match what the ebuild needs

and there is obviously a lot more that could go wrong that you don’t always think about. Sure that’s what ~arch and the infamous tinderboxes are for, some might say, but what if you could check for most of this with no extra cost for you than renaming the ebuild and trying to build it. Here comes the portage hooks (don’t know if other PM supports this).

Let’s take a real world example, recently intltool had a seriously buggy release (filled as gentoo bug #577133) and now most upstreams using intltool are shipping tarballs with these broken rules. With portage hooks, I wrote a little snipped that would tell me if there was not enough or actually too much locales installed for a given LINGUAS setting (ok that’s not exactly it, but let’s say it works this way). Then collected a list of md5sum of problematic files and wrote the following in /etc/portage/bashrc:


#!/bin/bash

post_src_prepare() {
if [ ! -e "${S}/po/Makefile.in.in" ]; then
return 0
fi

checksum=$(md5sum "${S}/po/Makefile.in.in" | cut -f1 -d' ')
tempfile=$(tempfile)

cat >> $tempfile <<EOF
26d0fa167a5a49e7f2b57b99d08c6586
f81285d13b63167be6981aad0e1a2038
955fb57559c7d112f749e185fc34e07f
EOF

if grep -q "$checksum" $tempfile; then
eerror "Bad intltool rules detected"
die "Bad intltool rules detected"
fi
}

And then any package using those bad rules will just die after src_prepare. No wasted time building broken stuff anymore. This example is obviously not perfect, yadi yada, but it’s just here to show a lot can be achieved without touching portage code directly. Actually interesting tests would probably be gladly integrated into a PM so don’t hide it if you write some. I’ll try to drop a rewrite of this using my git hooks model in my dev space if there is interest in it.

Gnome 2.26 status page

Just a reminder that I’m maintaining a status page for Gnome 2.26 work in my devspace. It’s generated by a post-commit hook so it’s only updated when I work on the overlay but it’s generally accurate. I know it should move to infra if possible but I don’t have time to explore that and make it fit for them yet (yeah shame on me). Anyway this page currently shows status of packages that landed in portage already, not the ones in overlay. We’re closing in to 96% which is the usual compliance percentage we reach for each release.