Archive for the ‘gnome’ Category

Jhbuild’ing GNOME 3.0: No fun.

Sunday, September 19th, 2010

Hadn’t compiled GNOME for a while so I gave it a shot yesterday evening. I ran jhbuild build evolution which should build everything required for Evolution. I had a fresh and empty install directory.
I don’t post this to blame anybody but I wonder how many people give up at this stage and how many potential non-1337h4x0r5 contributors GNOME loses because of such build problems. Teh fun.

gtk+-3 and gtk+:

Problem: This atk bug.
Workaround: Edit /home/user/installdir/share/gir-1.0/Atk-1.0.gir by changing the line <repository version=”1.0″ to <repository version=”1.2″.

gnutls-2.8.6:

Problem:
make[4]: Entering directory `/home/user/checkoutdir/gnutls-2.8.6/doc/examples’
[...]
/usr/bin/ld: ex-serv1.o: undefined reference to symbol ‘gcry_control@@GCRYPT_1.2′
/usr/bin/ld: note: ‘gcry_control@@GCRYPT_1.2′ is defined in DSO /home/user/installdir//lib/libgcrypt.so.11 so try adding it to the linker command line
/home/user/installdir//lib/libgcrypt.so.11: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make[4]: *** [ex-serv1] Error 1
Workaround: Edit doc/examples/Makefile.am and change AM_LDFLAGS = -no-install to AM_LDFLAGS = -no-install -lgcrypt. See this bug report.

nss-3.12.6

Problem:
drbg.c: In function ‘RNG_RandomUpdate’:
drbg.c:510: error: size of array ‘arg’ is negative
drbg.c:513: warning: large integer implicitly truncated to unsigned type
make[4]: *** [Linux2.6_x86_glibc_PTH_OPT.OBJ/Linux_SINGLE_SHLIB/drbg.o] Error 1
make[4]: Leaving directory `/home/user/checkoutdir/nss-3.12.6/mozilla/security/nss/lib/freebl’
make[3]: *** [libs] Error 2
Workaround: Could not find any, hence ugly: Commented line 510.
Next problem: Now the next modules will fail with
/usr/bin/perl: /home/user/installdir/lib/libfreebl3.so: version `NSSRAWHASH_3.12.3′ not found (required by /lib/libcrypt.so.1)
Workaround: Tried adding #module_makeargs['nss'] = makeargs + ‘CFLAGS+=”-FREEBL_NO_DEPEND=1″‘ to ~/.jhbuildrc but that did not help. Just deleting the offending file /home/user/installdir/lib/libfreebl3.so worked though (probably uses the system one in that case). Hmm.

NetworkManager (branch NETWORKMANAGER_0_7)

Problem:
configure.ac:64: warning: AM_NLS is m4_require’d but not m4_defun’d
Workaround: See this thread.
Next problem:
checking for POLKIT… configure: error: Package requirements (polkit-dbus) were not met:
No package ‘polkit-dbus’ found
Workaround: jhbuild build PolicyKit (which will create the missing file /home/user/installdir/lib/pkgconfig/polkit-dbus.pc)

sqlite3-3.6.23.1

Problem:
tclsh ./tool/mksqlite3h.tcl . >sqlite3.h
/bin/sh: tclsh: Command not found
make: *** [sqlite3.h] Error 127
Workaround: Using module_autogenargs['sqlite3'] = autogenargs + ‘ –disable-tcl’ in ~/.jhbuildrc did not work anymore, hence after reading the upstream bug report I grumpily installed TCL from the system repository.

gtkhtml

Problem:
In file included from html.c:32:
../gtkhtml/htmlengine.h:63: error: expected specifier-qualifier-list before ‘GdkGC’
html.c: In function ‘html_a11y_get_extents’:
html.c:321: error: ‘HTMLEngine’ has no member named ‘x_offset’
html.c:322: error: ‘HTMLEngine’ has no member named ‘y_offset’
make[2]: *** [html.lo] Error 1
make[2]: Leaving directory `/home/user/checkoutdir/gtkhtml/a11y’
Reason: GdkGC does not exist in GTK3 anymore, hence rendering needs porting to Cairo. Filed bug 630072 and gave up on this module.

avahi-0.6.27

Problem:
GISCAN Avahi-0.6.gir
g-ir-scanner: warning: Option –strip-prefix has been deprecated;
see –identifier-prefix and –symbol-prefix.
AvahiCore-0.6.gir: Incompatible version 1.0 (supported: 1.2)
make[3]: *** [Avahi-0.6.gir] Error 1
make[3]: Leaving directory `/home/user/checkoutdir/avahi-0.6.27/avahi-gobject’
Reason: Old .gir format. I edited avahi-gobject/AvahiCore-0.6.gir and replaced <repository version=”1.0″ by <repository version=”1.2″, and in configure.ac I replaced GOBJECT_INTROSPECTION_CHECK([0.6.7]) by GOBJECT_INTROSPECTION_CHECK([0.9.5]).
But that did not help – next problem:
GISCAN Avahi-0.6.gir
[...]
AssertionError: Failed to parse toplevel type
After finding the corresponding bug report I gave up on this module.

After all I couldn’t build evolution of course (No package ‘libgtkhtml-4.0′ found).
Not very productive, and right now I’m too annoyed to edit the JhbuildIssues wikipage.

Identifying projects and localization teams in need / GUADEC 2010

Monday, August 2nd, 2010

The talk (at GUADEC).

Apart from the usual Release Team service announcement and its charming follow-up street fights and the two short Bugsquad and Localization reports at the AGM meeting I also had the pleasure to present a talk about something that I’ve been thinking about for a while:

Identifying software projects and translation teams in need

My theory in short: We lose people that attach patches in Bugzilla to dead modules and never get a response. We waste time translating/localizing modules that will never see a release again. We are stalled as we have always been around 50 “supported” languages for the last GNOME releases. And we need ways out of all this.

For those who could not attend my talk and for further investigation, its slides (pdf/odp), data (cvs/odt) and code (sh) are available. The hardest part really is to find the meaningful data in all that noise. While I plan to continue thinking about this any input is welcome.

The translations (L10N).

For the translations part of my talk, as a first step the Releases Comparison table could get a neater URL and another column that calculates the difference in coverage between the last two years, plus linking the entries in the Languages column against the corresponding teams (yes, teams). Teams that lost more than 10% coverage in the last 2 years are: mk, dz, sq, si, ne, en_CA, cy, hr, fa, vi.
Another data source are those languages with no Git activity (0-2 commits in the last 2 years: an, bal, bem, dv, ff, fur, gn, ha, km, ks, ky, nap, tg, yo, zh_trad, zu; 3-20 commits: en_AU, ha, kk, la, ug).
Contacting these drowning translation teams / maintainers in order to ask for problems or if they still have enough time could for example be handled by the Coordination Team.

In case of no response a translation team can be considered dead.
Now one could take a look whether some contributions exist in damned-lies by people that could be interested to become the new coordinator. And/or downstream teams could be contacted and asked whether they are interested in contributing in upstream GNOME, e.g. teams in Fedora, openSUSE, Ubuntu or other distributions.
While becoming the new translation team coordinator is usually handled quite quickly on gnome-i18n mailing list once it is clear that the old coordinator is not around anymore, changing the assignee data in GNOME Bugzilla and getting Git commit access usually take a bit longer and could currently be demotivating bottlenecks. Time to review the rules or to have a survey about this?

The modules (Git).

For the modules part of it, two warnings could be added to Bugzilla, damned-lies and when checking out via Git for those modules that have not had much activity lately in GNOME Git.

Maintainers of modules that have not seen any commits for a long time (two years?) could be contacted to get a statement about the module’s status (this was done in the past already with mixed results). In case of no answer or a negative answer this could mean “Note: This module is obsolete or abandonned. No work is planned to take place and you might waste your time by filing a bug report or attaching a patch here”.

If we don’t know (yet) this could mean “Note: This module has not seen much activity in the code repository lately” (plus a hint what to do). Of course this first needs a definition for time period and commits thresholds in order to define “not much activity lately”. This could warn patch contributors in Bugzilla to either be patient for a patch review or to contact the maintainer first and it could help translation teams to set priorities and not to translate inactive modules. Another email contact should be provided (probably not the release team but a new team in GNOME?) for the potential case that the maintainer does not respond. However technically I don’t know where the Git activity results could be cached in order to not continiously be queried by several other parts of GNOME’s infrastructure.
As written before, comments, ideas and criticism are welcome. This is still an early stage.

GUADEC (In general).

And to talk in general about GUADEC: As usual it felt like holidays but I finally managed to not spend the entire day at the conference venue in order to also see a bit of the city (like the ICJ, the Scheveningen beach and the city center on Saturday). It was great to have my girl with me and to meet with old and new colleagues of the Openismus crew. And I had interesting chats with Amir H. Moin about datamining and the Evolution crew about non-coderelated stuff, both while lying on a beach couch.

GNOME 3.0 in March 2011

Thursday, July 29th, 2010

It’s 3 AM, GUADEC is big fun as usual, I’m in the hotel lobby, and as I have only seen one summary blogpost on planet.gnome.org yet I’d like to mention that GNOME 3.0 will be released in March 2011.

Good night.

Stallman keynote‽

Thursday, June 24th, 2010

Having attended last year’s GCDS keynote one sentence in the latest GNOME Foundation board meeting minutes scared me: “GNOME.Asia/COSCUP: Richard Stallman will be doing a keynote”.

As I was told that he has received a copy of GNOME’s new Speaker guidelines I still have some (naive?) hope left that people have learned something in the meantime. Time will tell.

GNOME modules that do not yet work with GTK3

Tuesday, June 22nd, 2010

Quick update of the list of modules (not necessarily complete) that do not yet work with GTK3.

  • Note: The table does not cover porting apps to use both GTK2 and GTK3.
  • Tickets with background color are blocked by missing GTK+ API.
GSeal Deprec. symbols GTK+ modules
bug-buddy to do
epiphany to do
gdl to do to do
gdm to do
glade3 to do
gnome-panel to do to do
gnome-screensaver to do
gnome-terminal to do
gnome-utils to do
gtk-engines to do to do
gtk-vnc to do (fixed in git but needs new tarball)
libnotify to do (fixed in git but needs new tarball)
libslab to do
libwnck to do
metacity to do to do
raptor to do
swfdec to do
vinagre to do
vte to do

For a longer list of issues remaining for GNOME 3, take a look at Bugzilla.
Also Migrating to GSettings is required and not covered by this table.

Heads up: GNOME 2.31 soon to ship GTK+ 2.90

Thursday, June 10th, 2010

(copying from devel-announce-list)

The GNOME Release Team plans to ship GTK+ 2.90 from GNOME 2.31.4 on.

This requires module maintainers to port their modules now (if you don’t want an angry release-team mob soon in front of your house).

We strongly encourage maintainers to

The following modules are affected (list not necessarily complete):

GSeal Deprec. symbols GTK+ modules
bug-buddy to do
ekiga to do
empathy to do
epiphany to do to do
evolution to do
gdl to do to do
gdm to do to do
glade3 to do
gnome-disk-utility to do
gnome-netstatus to do
gnome-panel to do to do
gnome-screensaver to do
gnome-terminal to do
gnome-utils to do
gtk-engines to do to do to do
gtk-vnc to do
libcanberra to do
libnotify to do (fixed in git but needs new tarball)
librsvg to do
libslab to do
libwnck to do
metacity to do to do
nautilus to do
raptor to do
seahorse to do
seahorse-plugins to do
sound-juicer to do
swfdec to do
system-monitor to do
vala to do
vinagre to do
vino to do
vte to do
webkit-gtk to do to do

For a longer list of issues remaining for GNOME 3, take a look at Bugzilla.

GNOME 3.0 cleanup status.

Monday, May 3rd, 2010

The first 2.31 release ahead and something you should do:
Cleaning up your module.

73 known issues left (three weeks ago: 93 issues).

GNOME modules:

Some external dependencies:

(Note that these lists obviously miss the conversion from gconf to GSettings and GTK+ single includes.
Data comes from the GSEAL wikipage, the overview stats and my brain. Hence it might be partially incorrect.)

GNOME 3.0 cleanup: Call to module developers

Tuesday, April 13th, 2010

I was recently asked (Czech link) “On a scale from 0 to 10 for GNOME 3 as planned to be where would the development be now?” My answer was “From my limited point of view currently a 7: Lots of work done, lots of work still to do.” And I started wondering: How much work is left in the cleanup area?

Now that 2.30 is out module developers must spend some time now to get their module(s) ready for GNOME 3.0.

It might not be clear to everybody that there is quite some work left.
If you don’t start now it might be too late to properly fix issues (e.g. adding missing accessor functions in GTK+ for the uncommon usecase in your module).
I’ll list the known bug reports per module. (Obviously this is not a list of all outstanding GNOME 3.0 issues but only known cleanup tickets.)

Take a look at your module. Most of the open issues (like GSEAL or Deprecated GTK+ symbols) are trivial and will require less than an hour to fix. Just making your module compile with -DGSEAL_ENABLE for example will already help a lot. Or if you are a volunteer just contribute a patch for your favorite module.

Getting this done is a requirement to get the next major release out in time and in a good quality.

GNOME modules:

Some external dependencies (definitely not a complete list):

(Note that these lists obviously miss the conversion from gconf to GSettings/dconf and GTK+ single includes.
Data comes from the GSEAL wikipage, the overview stats and my brain. Hence it might be partially incorrect.)

GNOME 2.30 released.

Wednesday, March 31st, 2010

GNOME 2.30

Personally especially happy to see the first modules using topic based help (Mallard) and that Czech language has 100% UI translation for the first time in years, probably for the first time ever.
Big thanks to everybody who was involved.

GNOME 3.0 schedule proposal published

Tuesday, February 23rd, 2010

Today the GNOME release schedule proposal for 2.31/3.0 was published. Please keep discussion streamlined on desktop-devel mailing list.

It also lists high risk areas and potential showstoppers (please note the word “potential”) as I want to communicate them clearly to users, distributions and the community. Currently I personally don’t expect everything to work out as planned, as manpower is missing in crucial areas. Distributions and the community can help minimizing such potential regressions by providing more developer manpower, or at least help in testing. Please contribute if you can.

Another issue are of course those modules that are defacto unmaintained. Peer reviews could be arranged in such cases.