when you had issues with xlib/xcb using original library names, did you try rebuilding gtk and/or qt?

I'm not sure, if I really understand your question. If you mean rebuilding Gtk/Qt4 against the old version of libx11 but with xcb: no I didn't try it, because it seemed too radical and I didn't expect the gtk build to be different if it is built against a libx11 version with xcb and thought that xcb was disabled intentionally because of some bug. Furthermore there are some applications using some other toolkits like tk, that we'd have to rebuild, too.

TLDR: you might try it (especially if you have to rebuild the core anyway,i.e. thumb repo or those who work on the software for the neo900), but don't expect too much

@marmistrz: Merging without regressions (and without using all workarounds that were necessary for 5.1 but are obsolete or even bad for 5.2) is actually what takes the most time (at least human time - computing time is not the issue here).

Would building without workarounds (or only with the build-time ones) and then bug-hunting be easier?

I've now already merged everything with surprisingly few and minor conflicts. There were changes bewtween 5.1 and 5.2 in the file with the crucial cache that caused the TextItem bug, but disabling this cache should still work in the same manner.

TLDR; merge went well, you can try building now if you like (scratchbox guide in the wiki should still work). I'll start it myself in some hours, so the first 5.2 debs might be ready by the end of the week (a guess, no promise).

I've just been trying to do some digging on possible causes for the issue as I don't really like the libxc11 idea. I salute those involved for getting it to work but I feel in the long run a cleaner solution should be found.

Rebuilding Gtk/Qt was a suggestion I found regarding 1.4 upgrades. I'm not 100% sure if Gtk uses xcb. I'm not sure about time lines here, but have you tried normal names since fmg's vkb work.

It was never intended to be the final solution. Once we have libx11 with working xcb, we just change back the few flags and debian package dependencies from xc11 to x11 and everything works. What I didn't want is to stop Qt developers (and to some degree users) until this day, since writing Qt apps / building Qt libraries and providing the libraries Qt (and other toolkits) need are three independent tasks. I'm concerned with task 1 (e.g. flatboat) and 2 and did only as much for 3 (the dirty libxc11 hack) to keep the other 2 going.

TLDR: I don't oppose a solution, I'm just not able to provide one.


Sorry, but I have no time to dig into libx11 or Gtk details beyond the scope of Qt. IIRC marmistrz tried to build a newer version of libx11 which in turn required other stuff. What do you mean by "normal names"?

Sorry, wasn't very clear. Know what I want to put but can't get the words right.

Have you tried replacing the actual libx11 with the one you built (libxc11). I didn't know if the updates made to the rest of the system since you'd encountered this issue had been resolved. IIRC the issues resolved around the vkb? which I believe fmg reverse engineered so may have somehow fixed in the process.

Originally yes, I first tried to replace and after that failed, I renamed the library to allow the installation of both with and without xcb. Are there any changes to Gtk and/or Hildon (and if yes - in which repo) that do suggest that they work with an xcb-enabled libx11 now?

IIRC the problems with libx11 with xcb enabled concerned the hardware keyboard and not the virtual one. I remember trying to get back the old library with just the virtual keyboard (which has no return key) on the terminal emulator. Luckily I had sshd installed, too.

Well, most libraries on N900 should be updated. I guess we'd benefit most from newer libc6. I pinged the Maemo Reloaded thread for status updates. Unfortunately, Aapo gave no instructions how to contribute, and my personal efforts to set up a sane building environment were all in vain. I'm gonna ask for such instructions straight after some status update.

My Qt5 repo (see http://wiki.maemo.org/Qt5-Maemo5) now contains 5.2.1 versions (actually 5.3 development versions in some cases) of qtbase, qtdeclarative, quickcomponents, qtlocation (i.e. the requested QtPosition), qtmultimedia and some others. I have to iron out some bugs (some samples crashed) and the webkit build will take a while (the old QtWebkit 5.1 will not work, s.b.). If you installed a previous version a simple apt-get update and upgrade should work .

Note that this build is binary incompatible to the previous Qt 5.1 libraries, because qreal is now a double for linux on arm. So any application linked against some function with a qreal as an argument has to be rebuilt (you'll see a missing symbol error).