Η ελληνική κοινότητα openSUSE σας προσκαλεί στο 1ο openSUSE collaboration weekend camp 2011, το οποίο θα πραγματοποιηθεί στις 15-17 Ιουλίου 2011 στην Ολυμπιακή ακτή (Παραλία Κατερίνης).

Μπορείτε να δείτε την ακριβή τοποθεσία στο googlemaps -> http://bit.ly/lauMqu

Για περισσότερες πληροφορίες & δήλωση συμμετοχής:
– Επικοινωνήστε μαζί μας στο info@os-el.gr ή
– Μπείτε στο κανάλι μας #openSUSE-el στον IRC server Freenode.
Οδηγίες για το πως να συνδεθείτε στο irc μπορείτε να βρείτε εδώ: http://el.opensuse.org/SDB:XCHAT

Τι θα κάνουμε…

Δουλειά & Διακοπές!

Τα sessions που θα πραγματοποιηθούν θα ποικίλουν σε μορφή & θεματολογία (το ακριβές πρόγραμμα θα ανακοινωθεί μέχρι τις 11 Ιουλίου):

* Θα επικεντρωθούμε σε πρακτικά (hands-on) sessions με ενδιαφέροντα workshops (για τα οποία περιμένουμε ιδέες και από εσάς), στα οποία ο καθένας θα μπορεί να δουλέψει πάνω στο αντικείμενο που θέλει, να βοηθήσει, να ρωτήσει και να λύσει απορίες

* Θα συζητήσουμε και θα ανταλλάξουμε απόψεις στα discussion & talk sessions

* Όπως είπαμε όμως θα είμαστε εκεί για να συνδυάσουμε τη δουλειά με διακοπές, οπότε δε θα λείψουν οι βουτιές στη θάλασσα, η χαλαρή κουβέντα και… οι μπύρες!

Ο στόχος μας είναι να βοηθήσουμε τα μέλη των κοινοτήτων να βελτιωθούν, να μάθουν και να ασχοληθούν με ακόμα περισσότερα πράγματα.

[get involved]  Θέλουμε να ενθαρρύνουμε ακόμα και τους όχι και τόσο έμπειρους χρήστες να ασχοληθούν ενεργά με την κοινότητα και να συνεισφέρουν σε αυτήν!
Θα τους δείξουμε στην πράξη πώς λειτουργεί η κοινότητα και πόσο ωραία περνάμε κάνοντας πράγματα όλοι μαζί!

[give & get help]  Θα βοηθήσουμε νέα μέλη να μάθουν πώς να συνεισφέρουν στην κοινότητα και θα τους καθοδηγήσουμε όσον αφορά τη χρήση συγκεκριμένων εργαλείων έτσι ώστε να μπορέσουν και αυτοί να προσφέρουν και να εξελιχτούν μέσα σε αυτήν.

[get the job done]  Ο απώτερος σκοπός βέβαια όλων αυτών είναι, αφού δείξουμε, λύσουμε απορίες και εξηγήσουμε, να δουλέψουμε!  Να καθίσουμε και να ασχοληθούμε όλοι μαζί με projects που μας αρέσουν, εργαλεία που μας ενδιαφέρουν και τελικά με το πέρας του event να έχουμε ολοκληρώσει πράγματα που είχαν μείνει πίσω, να έχουμε δημιουργήσει κάτι που χρειαζόταν η κοινότητα και γενικότερα αντί να κάνουμε τη δουλειά στο σπίτι μας, να την κάνουμε εκεί όλοι μαζί παρέα (και άμα πιάσει πολλή ζέστη… θα κάνουμε δροσερά διαλείμματα στη θάλασσα!)

Πού θα μείνουμε…

Στο ξενοδοχείο Grand Platon Hotel (http://www.grandplaton-hotel.gr/)στην Ολυμπιακή ακτή Κατερίνης, μόλις 400 μέτρα από τη Θάλασσα.

Τιμές (συμπεριλαμβάνεται πρωινό):

* Μονόκλινο – 35 ευρώ/βραδιά

* Δίκλινο – 50 ευρώ/βραδιά

* Τρίκλινο – 67 ευρώ/βραδιά

Πώς θα έρθετε…

1.  Με αυτοκίνητο (δείτε και τον χάρτη στο googlemaps):

Συντεταγμένες:  40.249513,22.585809

2.  Με ΚΤΕΛ (Τηλ. 2351023313 – website: http://ktelpierias.blogspot.com/):
Με το ΚΤΕΛ Κατερίνης, το οποίο θα σας αφήσει στον σταθμό μέσα στην πόλη της Κατερίνης.

Δρομολόγια ΚΤΕΛ:
(Για αποφυγή προβλημάτων επιβεβαιώνετε με το ΚΤΕΛ τα δρομολόγια που σας ενδιαφέρουν)

Από Αθήνα για Κατερίνη: 9.45 – 15.00 – 22.00
(Κάθε Παρασκευή υπάρχει έξτρα δρομολόγιο στις 17.00)

Από Κατερίνη για Αθήνα: 9.30 – 15.00 – 24.00
(Κάθε Πέμπτη υπάρχευ έξτρα δρομολόγιο στις 17.00)

Διάρκεια: 5 ώρες
Κόστος:
– Κανονικό εισιτήριο: 30 ευρώ η απλή μετάβαση – 40 ευρώ με επιστροφή
– Φοιτητικό εισιτήριο:  22.5 ευρώ η απλή μετάβαση – 33 ευρώ με επιστροφή

Από Θεσ/νίκη προς Κατερίνη:
Δευτ – Παρ : 6.30 – 7.00 – 7.45 – 8.15 – 8.45 – 9.15 – 9.45 – 10.15 – 10.45 – 11.15 – 11.45 – 12.15 – 12.45 – 13.15 – 13.45 – 14.15 – 14.45 – 15.15 – 15.45 – 16.15 – 16.45 – 17.15 – 17.45 – 18.15 – 18.45 – 19.15 – 19.45 – 20.15 – 20.45 – 21.30 – 22.30

Από Κατερίνη για Θεσ/νίκη:
Δευτ – Παρ : 5.15 – 5.40 – 6.30 – 7.00 – 7.30 – 8.00 – 8.30 – 9.00 – 9.30 – 10.00 – 10.30 – 11.00 – 11.30 – 12.00 – 12.30 – 13.00 – 13.30 – 14.00 – 14.30 – 15.00 – 15.30 – 16.00 – 16.30 – 17.00 – 17.30 – 18.00 – 18.30 – 19.15 – 19.45 – 20.30 – 21.30

Διάρκεια:  45 λεπτά & Κόστος:  6,3 ευρώ η απλή μετάβαση
*ΤΑ ΣΑΒΒΑΤΑ ΓΙΑ ΘΕΣ/ΝΙΚΗ ΤΑ ΠΡΩΤΑ ΔΡΟΜΟΛΟΓΙΑ ΕΙΝΑΙ ΣΤΙΣ 6.00 – 7.00 – 8.00 ΚΑΙ ΣΤΗ ΣΥΝΕΧΕΙΑ ΟΠΩΣ ΤΙΣ ΚΑΘΗΜΕΡΙΝΕΣ.

*ΤΙΣ ΚΥΡΙΑΚΕΣ ΚΑΙ ΤΙΣ ΑΡΓΙΕΣ ΤΟ ΠΡΩΤΟ ΕΙΝΑΙ ΣΤΙΣ 6.00, ΤΑ ΕΠΟΜΕΝΑ ΑΝΑ ΩΡΑ ΑΚΡΙΒΩΣ ΕΩΣ ΤΙΣ 14.00 ΚΑΙ ΜΕΤΑ ΑΝΑ ΜΙΣΗ ΩΡΑ)

3.  Με Τρένο/ Προαστιακός( http://tickets.trainose.gr/dromologia/):

* Από Θεσσαλονίκη προς Κατερίνη:
5:11 (IC), 5:37, 6:40, 7:04 (IC), 8:00, 9:20, 10:04 (IC), 10:22, 12:04 (IC), 12:58, 14:25, 15:04 (IC), 15:37, 16:17 (απλό), 17:14, 18:04 (IC), 18:37, 20:45, 21:47, 23:00 (απλό)

* Από Κατερίνη προς Θεσσαλονίκη:
00:23, 5:07(απλό), 6:46, 8:06, 09:16, 10:31 (απλό), 11:32, 11:57 (IC), 12:36, 13:38, 14:57 (IC), 15:36, 16:57 (IC), 17:31, 18:24, 19:02 (IC), 19:46, 20:46 (IC), 21:55, 22:57 (IC)

* Από Αθήνα προς Κατερίνη (είναι όλα IC εκτός από το τελευταίο):
7:18, 10:18, 12:18, 14:18, 16:15, 18:18, 23:55 (απλό)

* Από Κατερίνη προς Αθήνα (είναι όλα IC εκτός από το τελευταίο):
5:56, 7:49, 10:49, 12:49, 15:49, 18:49, 23:55 (απλό)

Hello out there,

I am very pleased to announce the new issue (180) of openSUSE Weekly
News in Greek. This issue is somehow an anniversary one, as it is the 30th translated in a row. In this one you will read about:

* openSUSE Conference and RW sessions – the BoF
* TechRepublic/Jack Wallen: Five tips for collaborating in LibreOffice
* Jos Poortvliet: openSUSE and online services
* Bruno Friedmann: ATI/AMD fglrx 8.861 Catalyst 11.6 available for openSUSE
* LinuxJournal/Bruce Byfield: Tweaking text in Scribus

And of course many many interesting news about openSUSE, plus useful
advice for making our lives easier.

Enough… read more at: own.opensuse.gr or at
http://el.opensuse.org/Weekly_news.

Looking forward to hearing your comments, advice and anything you would
like to read about at the next issue.

The openSUSE Weekly News is translated in the Greek language from issue #150. You can read older translated issues here: http://el.opensuse.org/Κατηγορία:Weekly_news_issues

Enjoy it!

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.