This time it was my pleasure not to announce first the greek translated issue of openSUSE Weekly News. Of course I am talking about issue 179. The reason is simple: since a fair number of issues I didn’t coordinate the procedure and the most interesting part is that this thing happened in the middle of the exam period for university students, a period when the contribution generally is reduced. But NO, this doesn’t apply for the greek openSUSE community, which is still growing even in this time of the year. Still, as normally, free time is not available for the student contributors, especially for those that are reaching at the end and they want to graduate (this also applies to me). The fact that the things keep going as (almost) usual makes me feel that great things are coming in the future and that this future is not so far away.

Historically, the coordination of this translation activity, which is very demanding because of the strict timeline that has to be followed, started from Kostas Koudaras (warlordfff). At those times I was participating just as a translator. Then it passed to me (efagra) and George Bratsos (Etern4L) with whom and for a long time we coordinated it weekly. I was responsible for the evens (xxo, xx2, xx4 etc), while he was for the odds (xx1, xx3 etc). However, lately, I was doing it alone. Luckily, another person showed up with a great appetite for work, very effective and a great cooking talent (that last one may seem irrelevant to the community, but I can assure you it is relevant and I will come back to it in another post). I am talking about Stella Rouzi (differentreality), thanks to her coordination greek issue 179 was in time, since this week I had a lot of work to do and time was just not enough. With her, we will coordinate weekly and I hope that soon enough other community members will step up and help with that also. In addition, we developed a new procedure for the coordination of this time demanding activity. We are currently applying it to the translation of issue 180 and we hope that not only the procedure will be accelerated but also the translators and the future coordinators will be doing it more easily and concurrently. From the beginning of the activity the translators came back with a lot of feedback and useful advice. Now it is the effectiveness of it that remains to be seen. I will be back on that with more details about both the new procedure and the feedback we had.

Ooof, once again I started with little in mind to wright down, but more and more came out. That’s ok, after all I’m not writing very often. One last thing: Have a LOT of fun! In this issue you will read (if not already):

* openSUSE Medical 11.4
* World Ipv6 Day Results
* Ekiga and SIP to replace Skype
* Automatic daily fstrim from SSD
* Vote for the openSUSE strategy

And of course many many interesting news about openSUSE plus useful tutorials that will make your life a little bit easier! Find it in:
http://own.opensuse.gr or at
http://el.opensuse.org/Weekly_news

Looking forward to hearing your comments and advice, plus what you would like to read on the next issue.

openSUSE Weekly News is translated in greek from issue #150.
You can read all previous issues in greek here:
http://el.opensuse.org/Κατηγορία:Weekly_news_issues

Enjoy it!

I’m happy to announce LibreOffice 3.3.3 bugfix release for openSUSE. The packages are available in the Build Service LibreOffice:Stable project. They fix various crashers, usability and translation problems, see the libreoffice-3.3.3.1 release news for more details. See also some notes about openSUSE LibreOffice build.

The openSUSE LO team hopes that you will be happy with this release. Though, any software contains bugs and we kindly ask you to report bugs. It will help us to fix them in the future releases.

Other information and plans:

The bugfix release 3.3.4 is planed two months from now. Though, I would rather provide LO-3.4.2 packages instead.

I am already working on the LO-3.4 packages. They are more complicated because there were significant changes in the build stuff. You might expect something within the next few weeks in the LibreOffice:Unstable project.

One thing I missed after switching from rekonq to Firefox are KDE's web shortcuts. It turns out that Firefox allows something similar, you can set shortcuts for your registered search engines: Nothing new so far, it turned out that the only thing I missed was a search for Novell Bugzilla entries and for openSUSE's feature … Continue reading Two little Firefox search helpers

Hello,

This is the 4rth week report, a lot of coding this week, you can see some code on my project github under branch working. Yes the code there is still not stable, but I am improving it constantly. Till this moment, i didn’t have any feedback except from my mentor, so if you check it out and have some suggestion or something, please feel free to contact me.

What is new in few words?

There have been improvements in many of the functions i did, several new functions have been added in my augeas branch repo, i try to split things up as much as possible, to help me debug things.

Functions Changed/Added:

aug_find_lense
aug_load_file
tree_child_sort_label
aug_process_tree
int label_compare

merge command in augtool was changed a bit too.

What is next?

The basic steps for tree matching have already been implemented, the goal now is to finish it and actually include the merging functions too. The tree matching is the most complex part as far i have understood in this project. By completing it, the other steps in the initial schedule will be implemented easier.

Till next week,
Christos

Firstly: This is very experimental work in progress, "baby steps". A lot remains to be done.

For iOS and Android there is nothing yet to test on an actual device, emulator (Android) or simulator (iOS). Don't ask to be a "beta tester", there is nothing to beta test. Only people working on actual code can participate at this stage. There are no concrete plans what end-user deliverables, if any, this will result in, or who would offer them. Even if a lot of code actually compiles already, whether it makes any sense at run-time is very unclear.

Secondly: I am bypassing all licensing aspects at this stage. I am hacking on at least the iOS and Android aspects just in my own time, for the hacking pleasure. Don't bother adding comments that bring up alleged license incompatibilities with the iTunes App Store, or Android Market, or whatever.

That said, let's get to the actual technical contents. This is mostly an edited version of the README.cross file in LibreOffice master.

Searching for information about cross-compilation of OpenOffice.org (the sibling of LibreOffice) you will find information about what actually was as far as I understand not cross-compilation, but running parts of the build process, and/or produced binaries, on emulated target hardware, using QEMU, or on emulated target OS, using Wine.

Building for Windows on Cygwin (which is in a way a separate OS, hosted on top of Windows) using the MinGW compiler is not really true cross-compilation either, as it is obviously possible to just run the produced (Windows) binaries, which is not possible in true cross-compilation scenarios.

My cross-compilation experimentation is targeting four platforms: Windows, iOS, Android and Mac OS X on PowerPC. So far I have done this work on the master branch of LibreOffice. As my changes don't intentionally affect normal builds or the working of existing code on existing platforms, I haven't wanted to use a feature branch.

Even though the LibreOffice build mechanism is highly unorthodox, the configure script takes the normal --build and --host options like any GNU Autoconf -based configure script. To cross-compile, basically you would need just to specify a suitable --host option and things should work out nicely. In practise, quite a lot of more details are needed.

What is so hard, then?

Despite the fact that the configure script takes normal --build and --host options, that is just the beginning. A lot of work was necessary to separate tests for "host" and "build" platforms in the configure script. The reasonably standard configure.in is just the top level; when we get down to the actual makefilery used to build the bits of LibreOffice, it gets much worse. Plus there are two different build mechanism for the LibreOffice bits: the old dmake-based one and the new GNU Make -based one. For third-party libraries there are then a mix of normal configure scripts and more exotic contraptions.

And then, for the totally new platforms (iOS and Android), there are of course changes that will be necessary in the actual code. Beside fixing obvious stuff that caused compilation errors, I haven't done much to that yet.

General ideas

The first thing you will notice when running the configure script for a cross-compilation setup is that the configure script actually gets run a second time, for the build platform, in the middle of being run for the cross-compilation configuration. This is because a build of LibreOffice requires many build-time tools that are built themselves as part of the process. So in order to be able to build these build-time tools, a separate configure run is needed. Its output is saved separately.

Then when you run make at the top level, it will first build the necessary build-time tools (and their pre-requisites) for the build platform. Then later when building for the cross-compilation host platform, build-time tools as built for the build platform are used. This all works quite nicely by now- Quite a lot of unnecessary stuff gets built for the build platform, but this can hopefully be streamlined once more modules are converted to the GNU Make -based build mechanism.

For third-party modules (external libraries that need to be built for platforms where they are not available as system libraries), in the cases where they use a normal configure script, cross-compilation is in theory fairly easy: Just pass --host and --build options to the library's configure script.

But of course, LibreOffice depends on some third-party libraries that just are too clever to use a standard configure script. I hopefully have sorted out those problems too by now.

For LibreOffice's own code modules, most required little change in their makefilery. Most changes were in the build mechanism (both of them) files in solenv.

Windows

Normally OpenOffice.org / LibreOffice is built for Windows using MSVC. There is some support in it already for building locally on Windows with the GNU tool-chain, i.e. what is commonly known as MinGW. [Edit: this is untrue: But as far as I know, cross-compilation to Windows has never been attempted.] Cross-compilation to Windows has been attempted a couple of times before, but I did not remember that when I started this hacking, and in any case, my current approach is a bit more generic at least at the confugure stage, I hope. But certainly I will re-use suitable stuff from the earlier attempts.

This OOo-originated MinGW support attempts to support both running Cygwin gcc in its -mno-cygwin mode, and a native MinGW compiler. The -mno-cygwin mechanism in the Cygwin gcc is rapidly being obsoleted, if it isn't already, and I have not attempted to check that it keeps working. Ditto for native MinGW.

In my opinion, it makes sense to use MinGW only when doing cross-compilation. (Because of obvious benefits like speed improvement, easier automation in systems like the Open Build Servce, etc.)

MinGW is available as cross-build toolchains pre-packaged in more or less official packages for many Linux distros including Debian, Fedora and openSUSE. Personally I use the mingw32 packages in the Open Build Service, running on openSUSE.

It is somewhat unclear how well thought-out the conditionals and code for MinGW inside the LibreOffice code actually are. The little I have noticed of it seems a bit randomish, and not necessarily relevant with the more complete set of headers in the version of the MinGW cross tool-chain in OBS, for instance.

Note that I want to do the cross-compilation to Windows as a true cross-compilation, with no use of Wine.

iOS

iOS is the operating system of Apple's mobile devices. Clearly for a touch-based device it would be totally unacceptable to run a normal LibreOffice application with overlapping windows and mouse-oriented GUI widgets. I don't think any work has been done (at least publicly) to design a touch GUI for LibreOffice, so the work on cross-compiling LibreOffice for iOS is extremely experimental, and of course partly pointless;) But it is interesting and fun nonetheless.

Obviously it will make sense to build only a part of LibreOffice's code for iOS. Possibly all GUI-oriented code should be left out, and some iOS app that eventually wants to use the remaining bits will handle all its GUI in a platform-dependent manner. How well it will be possible to do such a split remains to be seen. As I said, this is highly experimental and just in its baby steps phase.

Technically, one important special aspect of iOS is that apps are not allowed to load own dynamic libraries. (System libraries are used in the form of dynamic libraries, just like on Mac OS X, of which iOS is a variant.) So all the libraries in LibreOffice that normally are shared libraries (DLLs on Windows, shared objects (.so) on Linux, dynamic libraries on Mac OS X (.dylib)) need to be built as static archives instead. Obviously this will have some interesting consequences on how UNO works. None of that has been spared much thought yet.

The Apple tool-chain for iOS cross-building is available only for Mac OS X, so that is where I have been doing it.

Android

I don't know much about Android, but from a technical point of view it is a kind of Linux, of course. As far as I know it is allowed for an Android app to use shared objects, but if it isn't, then just the same approach as used on iOS will need to be used.

As for the GUI, the same holds as said above for iOS.

I have done my Android cross-compilation work on Linux (openSUSE 11.4 in particular), but it could as well be done on some other Linux or Mac OS X. The Android cross-buld tool-chain (the "Native Development Kit", or NDK) is available for Linux, Mac OS X and Windows. (Trying to cross-compile from Windows will probably drive you insane, though.)

PowerPC Mac OS X

Cross-compiling for PowerPC Mac OS X from Intel Mac OS X will probably be relatively easy. The API is after all closely identical to that on Intel Mac OS X, and OOo/LO builds fine natively on PowerPC Mac already. I want to do this in a true cross-compilation fashion, too, not involving Rosetta, I don't even have Rosetta installed on my Mac.

[Edit: Actually in this case the situation is not as it first appeared to me. See comments]

From the ooo-dev list at ASF, talking about binfilter:

There is a consensus that only the import part is needed, but removing just the export part is tedious work so no one has done it yet

Except over at LibreOffice, where one of our new contributors, Pierre-André Jacquod, worked on this earlier this year. This work is present already in our 3.4.

On Friday, I was able to spend a bit of time on UI hacking which I love. Those small and tiny pieces that when combined, do a big difference - do you remember my GSoC task proposal in this area? ;-) Unfortunately, no student has picked that; but let's see if somebody else gets interested.

This time it was the toolbar's menus. So far those menus were too prominently visible on the toolbar, while not that much used. Additionally, you can get the same functionality as a context menu - when you right-click on the toolbar. Together with our UX guys, we agreed that the best will be to remove them, and show the ">>" marks only when there are hidden toolbar items. You can see the changes on a "Before/After" screenshot:

And how does it look like when there are hidden items:

This will be available in LibreOffice 3.5. There is a small follow-up Easy Hack, see EasyHack: Make the toolbar menu easier. I'll be happy to provide you with details if you want to try this one - just drop me a mail.

As a guy who use openSuSE daily for my work, I like the direction that openSuSE has been treading in the past and now. I am not that intune with the community but then the direction they always take seem to walk the fine line between bring in the latest and greatest changes and maintaining a stability that allow for the majority of the users being able to use it for work. While guys like Fedora and Arch seems to throw caution to the wind bring in the changes with seemingly little regard for stability, openSuSE in my books have always been successful at the almost impossible task of maintaining a stable environment with the slew of changes coming from all directions. One thing that comes to my mind when writing this is their decision to maintain kde3 together with kde4 when kde4 was born to aid the transition 4.x.

With this in mind I look forward to the systemd integration into OpenSuSE planned for 12.1. Looks like there are a lot of overwhelming wins using systemd compared to the old systems. I was beginning to think that the OpenSuSE camp was a bit quiet compared to Ubuntu opting for upstart and Fedora going the Plymouth way. The only downside I can see for this is that untypical of something that is usually brought into the OpenSuSE, systemd seems to be the youngest of all the projects and I envision a lot of work ahead to stabilize it down for the future. This is something that I am definitely looking forward to in the Roadmap for openSuSE.

Hello,

This my regular weekly post on my GSoC project. Even though this week I had to give my last exams for my bachelor degree and some days of the week I had to spent them on reading, I did some progress on the actual project. First of all, I created my first patch for Augeas, yes this is my first patch not for this particular project, but in general. Every week I found my self, reading learning and carrying out new things, this is the coolest and most exciting thing in the GSoC experience until now.

Back to the actual patch, below you can see the description of the patch:


Subject: [PATCH] Added aug_find_lense function to find and return used for loading a
specific file

Aug_find_lense is a function that accepts a path of a file, and tries to
find the lense that was used to load this file in Augeas. Returns either
a string representing the lense if it is located succesfully either null
if the lense could not be found, or the file is not loaded in augeas.

As i had told you before, i am working on a merge method for augtool as well. This command works like this,

merge destination merging-parameters files-to-be-merged

example:
merge /etc/hosts/ (merging-parameters) /tmp/myfile1 /tmp/myfile2 ….. /tmp/myfile3

Until now I am able to use the aug_find lense to locate the lense used for the destination file. Then i have implemented an extra function that can use the name of the lense to load the files-to-merged to augeas. This permits me to have all these files in tree form used by Augeas. The plan now is to finish the code with aug_process_tree function[1] that will try to match the destination with the files-to-be-merged, and will then call the right function according to merging-parameters if a match is found.

What is next?

By having a merge command in augtool, that can load files in the way I mentioned above, i now have a test basis that will permit me to implement and test the merging functions. This must be done in the next two weeks, so i can be in the initial schedule. I am quite optimistic, things will go as planned. This week among with the coding there has been quite a lot of research on tree pattern matching algoriths, I am grateful that there are always nice people in open source communities that provide help and tips. I am back to coding…

Kind Regards,
Christos

[1] Work in Progress – The aug_process_tree function will be like: int aug_process_trees(struct augeas *aug, const char *dest, void (*process)(struct augeas *aug, const char *first, const char *second, void* data), void* data,const char *sources,…);

Hi all,



systemd is coming for next openSUSE (12.1) scheduled next fall.

I'll help for systemd integration in openSUSE Factory and will act as an interface between you (openSUSE testers, packagers, developers) and systemd upstream.

As you might guess, switching boot manager is not a trivial task and issues will be found. So, we want to have as much feedback and testing as possible, to try to tackle as much (if not all) issues in time for 12.1.

Here is our action plan, in several phases:

• phase 1: detecting current issues with systemd. Install systemd package and "manually" boot with it, by adding "init=/bin/systemd" at you kernel boot command line. In this setup, we want to find ALL the issues caused by switching to systemd, so please, check systemd on Factory status page and follow the instructions there to fill bug reports. We also want to ensure there is no regression, when using legacy sysvinit initscripts with systemd as boot manager.
• phase 2: systemd-sysvinit package installed by default and replace sysvinit.
• phase 3: providing systemd unit files to replace legacy sysvinit initscripts: this is a huge task which won't be completed before openSUSE 12.1, but it can be parallelized among a lot of people (ideally, each packager should be able to create unit systemd file). And we should also split this effort in manageable milestones :
• phase 3.1: GNOME and KDE live CDs should only use "native" systemd, without any sysvinit involved
• phase 3.2: installed system using GNOME and KDE live CDs be a "native" systemd (this involves testing additional paths in live installer)
• phase 3.3: install from DVD for GNOME and KDE should be "native" systemd

Of course, providing systemd unit file should not be a pure "openSUSE" task, because the ultimate goal for those files is to be cross-distribution and merged in relevant upstream projects. And we also don't want to duplicate effort which is starting in other distributions like Fedora, so, collaboration is key. I strongly recommend reading systemd for Administrators, Part III post about the conversion (and also all other posts : systemd for Administrators #1, #2, #3, #4, #5, #6, #7,#8 they are highly instructive).

For discussing / helping with systemd integration for Factory, please use opensuse-factory mailing list or go to #opensuse-factory IRC channel on Freenode.

We need your help to make sure openSUSE 12.1 will use systemd at 200% ;)