[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% ;)

A week of fail and win has almost ended.

On the fail part, I had a hard time building pygobject, gobject-introspection and glib from git.gnome.org. At first I’ve trying pulling from git, configuring and building, without luck. Then I switched to jhbuild, which after a few sanitychecks, bootstraps and configuration, worked; a day after I found that I’m on the stable branch (-2-28/gnome-3) which wasn’t good enough for my aim at patching master, and have switched branches to master, trying build -n. Of course it didn’t work until I hacked PKG_CONFIG_PATH to include paths such as /usr/share/pkgconfig, /usr/lib/pkgconfig and /usr/lib/i386-linux-gnu/pkgconfig – with help from walters on #introspection. This week my hard drive was about to die – because of a bug in the kernel driver for ata, it was reset every 30 seconds, causing everything to freeze. Different liveCDs have failed, the symptoms were ambigous and hard to reproduce – almost an entire day of fun.

On the win side, I figured out the hdd problem, and locked the kernel version to 2.6.38-9 for now. Hacked pygobject, posted patch in bugzilla B-), I’m one step further into making packagekit python bindings work; also I used the remaining time to push forward some more preparation refactor on software-center.

I have also updated the GSoC timeline – I’ll try to keep it up to date.

For the next week, same objectives remain.

PS: If you’re a python hacker and feel like helping out , please check this bug report out.

Hello out there,

I am very pleased to announce the new issue (178) of openSUSE Weekly
News in Greek.

In this one you will read about:

* First step towards 12.1 with Milestone 1
* Andreas Jaeger: Factory Progress 2011-06-03
* Sebastian Kügler: kollaboration in at platform 11
* Linus Torvalds: Linux 3.0-rc1
* Sean Michael Kerner: Oracle gives OpenOffice to Apache

And of course many many interesting news about openSUSE, plus usefull
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!
Efstathios Agrapidis (efagra)

This week was a good week for coding, and the best part about it: most of my changes are now in s-c’s upstream trunk.

I started out trying to populate s-c database with only a few applications; this meant updating the update-software-center tool, and also changing some bits on the database update module. I was glad to discover that some functionality I have planned to develop in week 6 (parsing AppStream app-data xmls) was already there, thus making my job easier

After that, work continued by abstracting backend parts, such as InstallBackend and TransactionsWatcher, and also isolating as much as posible apt and apt_pkg usage. I have then expanded the PackageInfo abstraction to implement a dictionary like interface, containing _Package objects (before that, apt.Package were returned). It took some small steps, and sometimes mistakes from my side, but in the end, I guess I have got it done right. Work still needs to be done regarding usage of candidate and installed properties (which currently are apt.Version objects), and also on AptCache try_install_and_*depends methods (this should be either abstracted, either made apt-backend specific.

At the end of the week, preparing the next point of focus, I have managed to get a developing environment with PackageKit with Python gobject introspection data. Here comes the bad news: the py GI for packagekit is not ready for prime time. Reasons for that: GI is relatively new, there are no other users of PK from Python (only C and Vala). With help from ximion, hughsie, dantti and tomeu (and many other kind souls on #PackageKit, #introspection or #python), we isolated the problem inside pygobject, apparently an incomplete implementation of GPtrArray. I hope to get it fixed next week , so that I can continue work with PK.

Although I am a bit worried seeing segfaults in Python, it’s a sunny day out here (so I can finish my report on a non-technical note) so I’m sure that with help from these awesome people on IRC,  problem will be solved, and my project will continue according to the plan.

Next week: gi ninja and more PK!

This week saw the release of the first milestone of openSUSE 12.1 and work on factory is continuing, I’ve found the following changes important:

GNU C Library (glibc) 2.13

We’ve updated glibc from version 2.11 to 2.13 which brings many bug fixes and AFAIK no major breakages to packages. The package itself got cleaned up a little bit as well, so please report any problems.

GO Programming Language

Factory now contains a compiler for the GO language which is “is an expressive, concurrent, garbage collected systems programming language that is type safe and memory safe.”. More details about GO are available on the openSUSE Wiki, the devel project with additional packages is devel:languages:go.

Packaging: Source Processing

The usage of _service files in Factory confused many packagers and resulted in broken packages so that these will be deprecated. As a replacement, Adrian implemented now a new source processing method and asks for testers.

Packaging: Adding useful Provides to cups drivers

Vincent “updated python-cups to a new version, and it is now shipping
files to automatically add Provides tag to packages that are shipping
cups drivers.”. This allows desktop packages to install the right printer driver – or users to do it via zypper. Packages with cups drivers just need to add a “BuildRequires: python-cups”.

Open Build Service Improvement

The “My Work” view has been updated to better show packages that are in review state and need your review. I suggest everybody to check out the page and cleanup your list.

Multiple Buildroots with osc

If you like to use more than one build at the same time, there are several options like pointed out on the opensuse-packaging mailing list:

• Use of the environment variable OSC_BUILD_ROOT to define a build root.
• Editing of the osc config file ~/.oscrc and setting build-root to contain the variables %(repo), %(arch),  %(project) or %(package).

Correction on auto-legal build service check

Jürgen corrected my report from last week: He would love to see the checks for auto-legal moved and welcomes any help.

Thanks

Thanks for the words of encouragement to my first blog post. I’ll try to continue this series. If there’s anything you think should be added to it, please contact me via email at aj at opensuse dot org.

This is my second report about my gsoc project, well what is new: This week I occupied my self with augeas, it is the first time I try to use and expand an already existing library and utility. Even thought Augeas is very well documented and the people in their community are very helpful, i had some problems combining my thoughts and ideas with the existing code, because i was trying to find out the best way to avoid code duplication etc. That was at least at the start, now at the end of the week I can say that I am more familiar with the Augeas API and this will certainly help me in the coming weeks.

As long as it concerns the actual merging procedure, i began coding an implementation i have thought. Unfortunately, the approach i used was not sufficient generalized to work with all the configuration files. Therefor i had, to erase most of the coding i did these days. However, from every negative thing comes a positive, in this case, I was able to find a better solution that rise some new problems, however i hope I will be able to find out an answer for them in the following days and implement the right code.

Finally, a merge tool command was added in augtool that is able to use the aug_merge command i added in the library, the particular command will accept a source and a dest tree/path and will then try to combine them according to the flags that i will add as enumeration. The final conclusion I must speed up things a bit cause there are unexpected problems that may occur at the implementation at any time.

Best Regards,
Christos