As part of the RC phase, I got to check the status of the 50-60 PHP extensions we provide, especially the PECL extensions which have different release cycles than the main PHP. With minor versions, this usually doesn’t really matter, but for major versions this means that some extensions need a little bit of love and fixes to work well with the new PHP version. This of course with the help of our developers.

The changes are usually one-liners due to a variable type change, or finding commits in the extension’s SCM and applying/back-porting it to the current versions (e.g. pecl memcache). Our policy regarding the patches we have, is that they should at least be sent to upstream (a core member or a bug report, e.g. #55703). I think I’m in the best position to enforce that patch policy, so in a few recent cases, I found myself asking one of our developers if the patch he sent me was already accepted upstream before willing to take it into the build process (in this case they are used temporarily, till we’ll work with the next RC or final release).

So far, 6 RTL related bugs were resolved in the 3.5 cycle (#32530, #34222, #40950, #43790, #43793, #44078), and a few minor issues reported directly to the developer’s mailing list got quick responses. Most importantly, the new features of page break and header/footer not only support RTL but actually looks good. During the LibreOffice conference I was suggested to help with these features, providing feedback, and I’m glade the needed attention was given to it.

Besides that, a few l10n and translation issues were solved in the process of doing the Hebrew translation (which also reflects on other RTL languages). At a few cases, these issue because a general l10n issues which affects all the languages.

In general, I found the core developers responsive to mails about RTL support. I’m sure the talk about RTL problems during the conference helped, as well as being more active in the project and having more personal acquaintance with the developers.

That’s being said, RTL support for LibreOffice still has problems, which I hope will be pushed during the 3.5.x cycles (full list at Bug 43808, the rtl meta bug). As to get some focus regarding was is to be done, I’m listing the top problems:

1. #44657 – RTL UI: Horizontal scrollbar in calc main window is broken
2. #33302 – brackets inverted in rtl text (mac only)
3. #37692 – RTL list numbering reverses its direction
4. #42070 - RTL support in broken in presenter Console extension
5. #32531 - Incorrect cursor key movement between table cells of different directionality
6. #104515 - RTL UI: moving active embedded object to the left moves it to the right (reported for OO.org, but verified in LibO)
7. #37128 - Writer saves text alignment of RTL paragraph not according to the ODF specification

I hoped to have the first two done for 3.5.0, but didn’t succeed in getting them fixed. Will keep trying…

Earlier this week, Raphael Geissert, tested some PHP extensions with the new version and reported 16 bugs (severity: important) against those who failed to build with PHP 5.4. As they will become RC bugs when 5.4.0 will enter unstable (probably around mid February), I preferred to handle them sooner than later. The result is 3 patches sent (one already uploaded) and 5 NMUs done.

During the process I poked through a lot of upstream SCMs. In the way I found out a trivial change was done in PECL’s SVN two years ago for all the extensions located there, which got me suspicious regarding some extensions we have. For non PECL hosted extensions, I had to track if and when a fix was done and use it for building or do a trivial fix myself. Packages using the 3.0 (quilt) source format were extremely easy to fix, and I was quite happy it generally went fast.

In general I’m a passive subscriber to the Debian PHP Maintainers mailing list, and finally could help actually and not just reply emails. For me it’s also doing some Debian work after a few months of focusing on the coming LibreOffice 3.5 release.

update [26/1/2012]:

From the 16 issues, only 2 aren’t fixed already or will be on the next upstream release. As their upstreams are dead, this is in the hands or the debian people, at least till they’ll FTBFS on unstable (instead of experimental).

Two years ago the patent registrar have started to consider revising the the issue and got many position papers (e.g. Hamakor’s papter). At the end he decided not to accept patents on software. De facto, at least one such patent (US patent 7,596,609) was accepted to be valid in Israel after that ruling. Now that the rulings is reverted, I guess will see many more software patents granted here. I wonder about the implications on the local software market… hopefully it won’t stagnate due to patent wars such as the ones we see every now and then in the US.

See you there…

“We are on the map! And we are staying on the map – not only in sports, but in everything.”

I found out through Invar Hovav that there’s a regression in the Ubuntu installation doesn’t believe this is true anymore, as according to lp#905754, you can’t select Israel or its major cities, and instead get suggestions for Gaza and Hebron. This is a regression from past installers when you could at least choose Tel Aviv, Jerusalem and Gaza. It used to be hard to pin point each location, but was still possible. This might be part of a bigger problem of selecting close/adjacent cities, but the default behavior in the past was different.

From the technical point of view, the Gaza and Hebron TZ files are weird (tzdata version 2011n-1). Both don’t have info for 2012 daylight saving time (usually start in late March or early April). Hebron switches twice a year to DST, hopefully nothing critical uses this time zone.

$ zdump -v Asia/Hebron | grep 2011
Asia/Hebron Fri Apr 1 10:00:59 2011 UTC = Fri Apr 1 12:00:59 2011 EET isdst=0 gmtoff=7200
Asia/Hebron Fri Apr 1 10:01:00 2011 UTC = Fri Apr 1 13:01:00 2011 EEST isdst=1 gmtoff=10800
Asia/Hebron Sun Jul 31 20:59:59 2011 UTC = Sun Jul 31 23:59:59 2011 EEST isdst=1 gmtoff=10800
Asia/Hebron Sun Jul 31 21:00:00 2011 UTC = Sun Jul 31 23:00:00 2011 EET isdst=0 gmtoff=7200
Asia/Hebron Mon Aug 29 21:59:59 2011 UTC = Mon Aug 29 23:59:59 2011 EET isdst=0 gmtoff=7200
Asia/Hebron Mon Aug 29 22:00:00 2011 UTC = Tue Aug 30 01:00:00 2011 EEST isdst=1 gmtoff=10800
Asia/Hebron Thu Sep 29 23:59:59 2011 UTC = Fri Sep 30 02:59:59 2011 EEST isdst=1 gmtoff=10800
Asia/Hebron Fri Sep 30 00:00:00 2011 UTC = Fri Sep 30 02:00:00 2011 EET isdst=0 gmtoff=7200

And Gaza only have a 3 months daylight saving time, while Israel has 6 and European eastern time has 7 months (all are UTC+2 region).

$ zdump -v Asia/Gaza | grep 2011
Asia/Gaza Sat Apr 2 10:00:59 2011 UTC = Sat Apr 2 12:00:59 2011 EET isdst=0 gmtoff=7200
Asia/Gaza Sat Apr 2 10:01:00 2011 UTC = Sat Apr 2 13:01:00 2011 EEST isdst=1 gmtoff=10800
Asia/Gaza Sun Jul 31 20:59:59 2011 UTC = Sun Jul 31 23:59:59 2011 EEST isdst=1 gmtoff=10800
Asia/Gaza Sun Jul 31 21:00:00 2011 UTC = Sun Jul 31 23:00:00 2011 EET isdst=0 gmtoff=7200

p.s.
This isn’t a political post, don’t make it into one.

9 languages at 100%: Catalan (ca), Danish (da), French (fr), Scottish Gaelic (gd), Portuguese (pt), Portuguese (Brazil) (pt_BR), Russian (ru), Slovenian (sl) and Chinese (China) (zh_CN).

15 languages at 99%: Asturian (ast), Bulgarian (bg), Breton (br), Welsh (cy), Belarusian (be), German (de), English (United Kingdom) (en_GB), Esperanto (eo), Estonian (et), Galician (gl), Latvian (lv), Norwegian Bokmål (nb), Polish (pl), Turkish (tr) and Slovak (sk).

1 languages at 98%: Hungarian (hu)

15 languages at 97%: Assamese (as), Czech (cs), Chinese (Taiwan) (ch_TW), Spanish (es), Basque (eu), Finnish (fi), Irish (ga), Gujarati (gu), Croatian (hr), Italian (it), Icelandic (is), Kannada (kn), Marathi (mr), Dutch (nl) andTelugu (te).

2 languages at 96%: Hebrew (he) and Japanese (ja).

1 languages at 95%: Vietnamese (vi)

5 languages at 94%: English (South Africa) (en_ZA), Indonesian (id), Khmer (km), Tamil (ta) and Uighur (ug).

4 languages at 93%: Arabic (ar), Bengali (bn), Catalan (Valencia) (ca_XV) and Korean (ko).

1 languages at 92%: Oriya (or).

1 languages at 91%: Swedish (sv).

1 languages at 90%: Greek (el).

11 languages between 80%-89%: Afrikaans (af), Bosnian (bs), Hindi (hi), Lithuanian (lt), Macedonian (mk), Burmese (my), Norwegian Nynorsk (nn), Occitan (oc), Oromo (om), Sinhala (si) and Ukrainian (uk).

11 languages between 70%-79%: (no list)

10 languages between 60%-69%: (no list)

13 languages between 50%-59%: (no list)

During the conference I had the chance to work on LibreOffice related issues:

• Hebrew translation for version 3.5 (up by 2%).
• Fixes to the Hebrew translation for version 3.4 (noticed a few string changes in 3.3 not included in 3.4).
• Patch to fix a small typo in the code (noticed while trying to find the meaning of the string before translating).
• Patch to fix the appearance of the BrOffice logo in RTL UI instead of LibreOffice (fix to the 3.3 branch, already fixed in 3.4).
• 3 patches (1, 2, 3) to cleanup unused “.chaos” file types with Michael Meeks‘s encouragement and help with doing some digging in the code.
  Apparently, even non programmers can write patches with the appropriate help.
• Check about 30 RTL and Hebrew related bug reports for my RTL issues presentation, verifying them with 3.4.3.

The 3 patches began when I noticed a few weird strings to translate in the context of installation media – good luck to those who will try to install LibreOffice from 5.25″ disk, 3.5″ disk or a tape drive. These 3 strings are now removed from the code with other 36 unused strings. So translators – please take the strings to translate with a grain of salt.

Post conference tasks (always ending up with more stuff to do after a conference):

• Recreate my RTL issues presentation so that the live example of bugs could be presented as slides.
• Keep advancing with the Hebrew translation (3.5 and 3.4 fixes).
• Finish the fdo bugzilla search for RTL bugs. I found out some other people who reports bugs (and try to coordinate with them).
  A list of RTL related bugs in LibreOffice I know of is here: http://wiki.hamakor.org.il/index.php/עברית_בליברה_אופיס (still work in progress, in Hebrew).
• Create a meta bug for the RTL bugs, and prioritize the issues to focus on what’s important to make sure is fixed for version 3.5.
• Start testing version 3.5 for RTL bugs (daily / weekly builds).
• Help Christoph Noack with finding which PaperCuts we have in LibreOffice and try to get them fixed.

The office itself looks very nice, and reminds me of the work space of many software companies. But the unique part of the tour was David pointing to people and telling us what they are working on. It’s interesting to see the people behind the sciences, although we didn’t talk with them in order not to disturb the work.

I remember most when we David pointed to a guy and said he’s the one doing composer. Maybe because it’s very clear what he doesn’t, while some people work on more internal parts or more conceptual concepts like “performance”.

After seeing some cool posters on the wall, I got a chance for a short chat with Tristan Nitot and ask him some questions about Mozilla Europe and the office. I’m still trying to understand how Mozilla works (as an organization), and this was a good chance to get familiar with the European branch.

For me, the highlight of the tour was the chance to say to the people at the office “thanks for the software” just before leaving and saying goodbye. Not in everyday you get a chance to see the faces behind the software you use daily.