In the past few days, the openSUSE KDE team has been working hard, following the footsteps of the nice work done by the Kubuntu and Arch Linux communities, to provide Qt5 packages for the distribution. In fact, work was already done in the past, but the packages were not coinstallable with the existing Qt4 installation.

Thanks to a renewed effort, the OBS holds now Qt5 packages that won’t overwrite the existing Qt4 install: they currently live in the KDE:Qt51 repository (Factory and openSUSE 12.3) and they have been submitted to Factory itself, with the plan of having a full set of Qt5 packages for the next version of the distribution. PyQt5 was also packaged, for those who are interested in using Python with Qt.

These packages are deemed as stable and usable without issues (although, not being part of the distribution, not supported): if you spot a problem in packaging, file a bug to Novell’s Bugzilla.

Up to this point we have talked about stable releases. But as KF5 depends on the yet-unreleased Qt 5.2,  new repositories were created:

• KDE:Qt5, which hosts snapshots off the current Qt tree (5.2);

• KDE:Frameworks, which contains snapshots of the current state of KF5.

In particular KF5 is installed to /opt/kf5, ensuring that it won’t overwrite your current install. Bear in mind that these packages are absolutely not meant for end users (we’re talking pre-alpha here!), but only for people who want to help developing KF5. For those daring enough, there is even a kf5-session package to start a whole KF5 + frameworks workspace session.

Credit where it’s due: the packaging work is mostly the effort of Hrvoje “shumski” Senjan and Raymond “tittiatcoke” Wooninck, the two major KDE packaging powerhouses in the team. ;)

Happy hacking!

Last week Andreas did an upstream release of the file synchronization software csync. Frequent readers know that csync is the sync engine that is used in the ownCloud client, so this is a very important and special release for us.

The new release contains a lot of features and changes me and my collegues worked on during the last 18 month: First we added the ownCloud module to csync upstream, so that csync now is able to sync local directories to an ownCloud server. The ownCloud client works on platforms Linux and MacOSX and Windows. That required a lot of (tricky) changes to the csync platform which we carefully backported to csync upstream.

There are much more changes, such as: More compilers supported, a new logging framework, a new base lib to do unit testing, removal of not so common dependencies and other infrastructure changes. But also on the feature side there are more improvements, mainly to focus on a more easy and broader use of the csync library that allows to embed the sync functionality to various backends into other applications.

I am very happy that we kept our promise to contribute a lot of our changes back to upstream. Primarily that is the way to go in the open source world, you will say. But it was distressing to see how quickly people were whispering stuff like “Well, wouldn’t it be easier if you do a fork? Remember, you have to come to good results quickly for the company, why bother with an upstream project?”

For me, that wouldn’t be like companies in FOSS world should behave, and I know that on the long run, it would not be beneficial for the company either. So very good that the relevant people supported the idea of going with upstream from the beginning.

Does that mean that csync 0.50.0 and ocsync as shipped with ownCloud are the same now? No, unfortunately not. We did more changes on the ownCloud branch which need to be reviewed and probably won’t fit to csync the way they are now. More work to be done, but we’re on the way!

As I’ve discussed in the past, I will be selecting one “longterm stable” kernel release every year, and maintain that kernel release for at least two years.

Despite the fact that the 3.10-stable kernel releases are not slowing down at all, and there are plenty of pending patches already lined up for the next few releases, I figured it was a good time to let everyone know now that I’m picking the 3.10 kernel release as the next longterm kernel, so they can start planning things around it if needed.

As already announced on Factory, yast-devel, and by Lukáš: YaST, the SUSE installation and configuration tool, has been automatically translated from YCP, an in-house custom language, to Ruby. In the past 6 months, we have built a tool to translate 600.000 lines of code developed over the course of 12 years.

My role in the project was mainly shedding light on ancient details of the YCP language and its interpreter. Stop pulling my beard, kids! Also, knowing Bison (the tool used to implement the YCP parser in C++) I designed a part that transfers the comments. Mind you, not only at the function or statement level, but from inside of expressions too. Fun!

Thanks to the team, it was great working on the project with you!

All YaST modules have been just automatically converted from YCP programming language to Ruby. Transition has been done using special tool called YCP-Killer developed in SUSE. See the announcement at yast-devel mailing-list.

Many thanks to the team, especially David Majda, Josef Reidinger, Ladislav Slezak, Jiri Suchomel, Vladimir Moravec, Martin Vidner, and many others testing and checking the converted code, and providing feedback and other good ideas.

All modules have been already submitted to YaST:Head in OBS and packages already are or will be available shortly in its download repository. All packages converted to Ruby are available in version 3.0.0 or higher.

Here is how you can upgrade your YaST packages in openSUSE 12.3:

zypper ar -f http://download.opensuse.org/repositories/YaST:/Head/openSUSE_12.3/
YaST:Head
zypper dup --from YaST:Head

You actually might need to wait a few minutes or hours before 12.3 build is finished. Factory should be ready by now.

See you soon at GitHub/yast!

The latest release of the KDE Platform, Workspaces, and Applications (4.11) is around the corner: in fact, the last RC was recently made available. We’re almost there, but it doesn’t mean that testing and reporting should stop: on the contrary, it is needed even more to ensure that no bad bugs crawl up in the final release.

As part of this effort, openSUSE packages for RC2 have been released through the OBS, and are available in the KDE:Distro:Factory repository. Like always, please report upstream bugs to KDE directly, and use Novell’s Bugzilla for packaging or openSUSE specific issues.

While 4.11 will be part of openSUSE 13.1, users of older versions will be able to install packages through the KDE:Release:411 repository which will be created after the official release. And now, back to testing!

This summer, our family planted a few vegetables and fruit. It also accidentally let some sunflower seeds fall on the ground and they germinated. Now that the summer is full on and the skies are blue, I decided to play with the beautiful yellows coming from the sunflowers. I think these could do for an excellent and poppy screen background.

Enjoy!

Last week-end I was in Greece, in Thessaloniki, enjoying the openSUSE Conference 2013. If I had to summarize the event in one word, that would be: wow! It was the first time we had this event in another city than Nuremberg and Prague (two places where SUSE has offices), and it was the first time the organization was fully lead by the community. I was quite confident that things couldn't go wrong since, after all, what matters is that we're all in the same place. But I was amazed that the whole event went so smoothly! This was really a great job from a whole team of volunteers:

Just to give an example of the hard work that was accomplished: most (all?) talks were successfully streamed, and the recordings are already online! Stella and Kostas definitely deserve credits for the overall success, as they kept leading the organization in the right direction since last year, and the event wouldn't have been possible without their dedication. Our sponsors also helped make all this happen, so many thanks to SUSE, ARM, DevHdR and Oracle!

Having people from all over the world was once again an opportunity to meet up with old and new friends, who were coming from Brazil (Izabel, Carlos), the US, all over Europe obviously, but also India (Manu, Saurabh) and China as well as Taiwan (Sunny, Max, David, etc.)... The conference is the global event of the openSUSE community, without any doubt. With 250 attendees, there were a lot of hallway chats and informal meetings; I'm sure the GNOME couch tradition that we initiated with Dominique and Richard will stay over the years ;-)

Unsurprisingly, the openSUSE Board took opportunity of having so many community members to discuss several topics with as many people as possible. The board also organized for the first time a session about team reports. Even though several teams didn't participate to that session (generally because no team members was there), we had more than ten teams joining the party on stage, and this was probably one of the best way to see how broad our community really is and to learn the latest developments in various areas of the project. We also had our usual town hall meeting which went rather nicely, with useful feedback to the board.

The bad thing for me is that I had to stay only for a few days due to work, but there's already a next opportunity to meet with the community: this will be the openSUSE Summit in Orlando next November. And if you cannot make it, then I can only recommending making sure that you will join us next year, for the openSUSE Conference in Dubrovnik!

What can I say more, The Greeks sure now how to make an event more enjoyable. This conference was definitely something I was not expecting, apart from high technical standards of the conference and also the excellent Geeky People, who knew I guess anything and everything from the world to the parties that the Greeks hosted and the way they managed to skew the timeline to add a bit of surprise to whatever we do plus the sleepless nights and the amazing Greek house along with a random encounter with a bunch of hippies, this trip was nothing but a NIRVANA trip

Thanks a lot again guys for putting the hard work and rounding up an excellent conference.

 

 

I put a script in /etc/cron.daily and would like to know what time it will run. And, more importantly, how does the system determine this time value?

On SUSE Linux Enterprise and openSUSE, the time is determined by the CRON_DAILY parameter in the /etc/sysconfig/cron file. If this parameter is not set, it defaults to 15 minutes after the time of the last boot.

Because of how the mechanism for running scripts in the /etc/cron.{houry,daily,weekly,monthly} directories works, the time value must be a multiple of 15 minutes (i.e. 0, 15, 30, or 45 minutes past the hour). The exact functioning of this mechanism can be seen by studying the following:

# cat /etc/crontab
SHELL=/bin/sh
PATH=/usr/bin:/usr/sbin:/sbin:/bin:/usr/lib/news/bin
MAILTO=root
#
# check scripts in cron.hourly, cron.daily, cron.weekly, and cron.monthly
#
-*/15 * * * *   root  test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons >/dev/null 2>&1

This basic cronjob simply runs /usr/lib/cron/run-crons every 15 minutes. The real magic happens inside that script.

A nice discussion of how cron works in SUSE/openSUSE is available in the Support Data Base (SDB): http://en.opensuse.org/SDB:Cron