Here’s with some delay the next incarnation of Factory Progress. I’ve noticed the following changes that might interest people using and developing openSUSE Factory:

Package changes

Linux 3.0

Linux kernel 3.0 rc5 is currently on its way to factory and the header files (in package linux-glibc-devel) have already been updated for it. If your software reads the Linux kernel version, please check that it can cope with the two digits instead of the three of the new version. Best would be to not read the version at all.

Systemd

Frederic has proposed a “Road to systemd for openSUSE 12.1″. Systemd is a replacement of the SysVinit scripts that we have been using and improving in the past with many new – including some controversial – ideas. Check his blog post for additional references about systemd. The majority of the distributions are moving to systemd as well and standarizing on it, will allow to share some more code and development in this area.

We’re now in phase 1 – which means: Get systemd running as an option. Once this is working satisfactory, we can switch the default (phase 2) and decide what to do with SysVinit support.

No static glibc libraries

The C library glibc now does not come anymore with static libraries, those are in the new glibc-devel-static subpackage.

Python 3.2

The python3 package is now at version 3.2, the most important change in Python 3.2 is the implementation of “PEP 384, a stable ABI for extension modules” which means that with 3.2 and upwards there won’t be any API breakages for modules which is really important developer wise.

Another big improvement is the new GIL (Global Interpreter Lock) implementation which will speed up threaded Python code. Python 3.2 also introduces “futures” library which is used for concurrent programming, this will be useful more multi-core Python development.

Tomoyo

Tomoyo is a MAC (Mandatory Access Control) implementation for Linux – so an alternative to AppArmor and SELinux. openSUSE’s Linux kernel does now come with the module and also the tools were updated to support this.

Policy and tool changes

New Source Service mode activated and recompression of tar balls

The new source service mode has been activated, it is recommended to update to osc 0.132 version as available in the openSUSE:Tools project to work with source services. Now the download URL given in source link is checked, so it has to be accurate. If you downloaded and recompressed a tarball, read Coolo’s policy change: “please don’t recompress tarballs unless it saves >1MB for download.”.

He also mentions:

What will become policy sooner or later is that you should not have incorrect source URLs behind Source*, so _if_ you have to recompress, don’t lie in the
Source line, but put the original tar as comment and use local file names in Source:

Dropping a package from Factory

Vincent explained  How/why/when to drop a package from Factory.

Release notes in FATE

To make it easier to write release notes, it helps a lot, if you (= the so-called stakeholders) would provide a release notes snippet in the future using openFATE. We can then collect all those release notes and edit them.

Other interesting bits

openSUSE Conference

The call for papers is continuing to run, please submit session proposals at the conference site. If you like to learn what a BoF is, read this article.

The vote on the openSUSE strategy is closing on 30th of june. So official openSUSE members have the opportunity for ONE more day to express their opinion.

Take your chance. It is here: go, read the document one more time and cast your vote!

And if you are not sure if it is important, here you find some hints.



And BTW:

Since third week’s report was no report – basically because I was delayed by missing parts in the architecture (the saga hasn’t finished yet), I’m posting this late 4th week report:

Yep, the PK InstallBackend is shaping up !

Unfortunately, the only machine running this code is mine, the reason being this chain of dependencies:

- static Python bindings for PK are dead

- PK gi depends on pygobject invoke-rewrite branch of J5 (which isn’t
yet merged into master, but will make it to 3.2 release);

- PK gi breaks statically loaded glib in software-center master; therefore, the -gtk3 port of software-center should be used;

- software-center-gtk3 isn’t ready for merging into trunk – experimental design changes towards a friendlier 5.0 are being done.

Therefore I’m testing the install/remove routines on the small modules, such as the PendingView in the above screenshot, waiting for components stabilization.

Next week – and probably until week 6 report, I will continue work on the install parts and start developing the PK PackageInfo class.

PS: I’m undecided if I should make my reports biweekly or milestone based :-/

So in my head there’s a little Walter Sobchak beating on my conscience and shouting “This is what you get when you trust Facebook with your data, Will”.
The reason is that I upload photos to Facebook using KDE’s shared uploader and this has fallen victim to the whims of FB’s purge of its app biosphere. Unless the original developer can convince them that the app is not spammy, offering a bad experience or having the wrong attitude, the app, my photos (all archived elsewhere of course), but most importantly, all the kind comments from my friends and contacts that represent FB’s only value, get sent to the farm.
This is what you get when you trust one company with stuff you care about. Will.

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.