openSUSE Linux

The GNU C Library (glibc) version 2.14 was released on the 31th of May but we haven't switched to it for openSUSE yet since one of the major changes was the obsoletion of the sunrpc code in glibc and that caused problems. The TI-RPC library ... [More] (libtirpc) is the proposed replacement of the sunrpc code. One benefit of the TI-RPC library is that it supports - unlike the old sunrpc code in glibc - IPv6. libtirpc is used successfully already by a couple of Open Source projects like autofs or nfs. Unfortunately some code in libtirpc seems to be broken, like the NIS support. The package missed also some header files to make it a full replacement but those can be easily copied over from glibc. So, building everything with libtirpc instead of glibc' sunrpc code was not possible, and the libtirpc developers seemed not to be interested in helping here.So, I've took now the same route that Fedora did and reenabled the sunrpc code in glibc again and thus everything works as before. I encourage everybody that has packages that work with libtirpc to switch to it - and help changing apps and libtirpc itself as needed so that eventually we really can obsolete glibc's sunrpc code.Today, the updated glibc has been submitted and checked into openSUSE's Factory distribution and thus will be in openSUSE 12.1.The new glibc contains lots of bugfixes and also these changes (full list):New Linux interfaces: clock_adjtime, name_to_handle_at, open_by_handle_at, syncfs, setns, sendmmsg* New locales: os_RU, bem_ZA, en_ZA, ff_SN, sw_KE, sw_TZ, lb_LU, wae_CH, yue_HK, lij_IT, mhr_RU* New encodings: CP770, CP771, CP772, CP773, CP774* New program sotruss to trace calls through PLTs. Implemented by Ulrich Drepper.* The malloc hook implementation is marked deprecated and will be removed from the default implementation in the next version. The design never worked ever since the introduction of threads. Even programs which do not create threads themselves can use multiple threads created internally.After installing the newly build library on my own system I noticed that LibreOffice crashed and added a bandaid fix that my colleague Michael Matz developed already for glibc 2.11.2 which contained a backport of the buggy change. The submitted glibc contains this fix as well. [Less]

How to avoid the Akonadi PIM framework of KDE is a very frequently asked question. Akonadi is started when logging into a default KDE session – and includes a mysql server – this is a bit of a waste of system resources since (in my personal ... [More] estimation) the majority of KDE users won’t use Akonadi for anything at all. So here’s how to make Akonadi not start in KDE SC 4.7. Step 1 Disable KRunner runners that will start Akonadi. Press Alt+F2, click on the “wrench”, uncheck “Calendar Events” and “Contacts” runners, click on “Apply”. Step 2 Tell the digital clock not to display calendar events. Right click the digital clock (in your panel), Digital Clock Settings, Calendar, uncheck “Display Events”, click “Apply”. Step 3 Don’t use applications that need/start Akonadi, such as Kontact/KMail/KOrganizer, Konversation and Kopete. That’s it. Next time you boot Akonadi won’t start anymore – at least not until needed. PS Personally I’m a huge user of Akonadi and the applications mentioned above, so this post should not be seen as any kind of vendetta against Akonadi or KDEPIM developers or anyone else. The purpose is solely to help KDE users who – unlike me – don’t need Akonadi get a leaner and cleaner system. [Less]

Yet another advertisement for openSUSE Conference 2011. Something I’ll be participating in as well. But this time, all the glory belongs to Manu Gupta. I’ll be just helping out. We will have together presentation about SaX3. Have you already heard ... [More] about SaX3? If not,continue reading SaX2 was X configuration tool. It was using xorg.conf file and it allowed people to set various X properties in GUI. It was a user friendly way how to set up Xorg. But X developers made automatic configuration much better and xorg.conf file obsolete. They replaced it with something much better – configuration directory xorg.conf.d. You can place just snippets of original xorg.conf file in there to override some properties. It’s much better, but unfortunately it also made SaX2 obsolete. And even though automatic configuration is great, there still people that want to tweak just a few details. These people missed SaX2. One of the GSoC projects was to create SaX3 that will be aware of xorg.conf.d directory, respect it and would create just the necessary snippets. So your X configuration will stay as simple as possible, but you’ll also have possibility to configure it easily from GUI. Manu started working on this project. He had to learn a lot of new things, but he put a lot of effort into that and in the end, there is completely new SaX3. It uses libyui for GUI toolkits abstraction. It is able to run as Qt, GTK or even ncurses application. It uses Augeas to parse xorg.conf.d files and during the summer even the Augeas Xorg lens was improved to support things that were needed. During the SaX3 talk, you will learn, what SaX3 can do for you, how it works and also a little bit about interesting technologies beneath. If you are eager to see, what it already can do, you can check Manu’s blog about SaX3 and especially Get your hand dirty post [Less]

As most of you reading this post would know, separating libYUI was one of the topics for GSoC 2011 by openSUSE. Over the last three months, a lot of work has gone into the project. As the deadline approaches, we am happy to announce that libYUI is an independent framework! Let me summarize the changes [...]

More mail chew; sync. call with Caolan, created a freedesktop repo gitdm-config to make our stats more accessible to all. Re-based feature/gtk3 onto the new onegit repos. Lunch. Merge Xapantu's initial gtk3 native widget theming work. Burned through a couple of k of spam. Reviewed Ricardo's nice, cleaned up new VCL layout code.

Just a quick note – at the beginning of August, I have submitted my master thesis, titled Information Sharing in MCTS. MCTS means Monte Carlo Tree Search and it is a powerful technique for finding moves in games with large state space and difficult ... [More] evaluation functions, such as Go. The thesis presents the modern Computer Go techniques and open problems, my (not too weak) Go-playing program Pachi and some modest improvements of the MCTS algorithms. It might make a good introduction to state-of-art Computer Go. [Less]

Today I've submitted a new extundelete package to my repo with following fixes:added man(8) page to the package fixed --help output to print also info about --restore-directory added --dump-names option to search for - and print the full name of - ... [More] deleted and (potentially fully) recoverable files on a given partition  Feel free to test and report problems back. The package is now also part of the filesystems project. [Less]

Its quite some work to get to a reasonable schedule for a FOSS conference done. You want a balanced program with topics where all visitors can find their interests in. Moreover the level of the talks must be taken care of as well as there should be ... [More] gravitation centers for key topics within the community. As you usually also seek out for new community members with a conference, some topics which attract new people are also a very good idea. And all that needs to be sorted between rooms with different sizes, the times people can be around, the tracks you think are useful on the event and such. Quite some parameters to take into account. That said, I am very happy that we could issue the schedule for the openSUSE Conference 2011 today. For conference organization there is tooling. Or should I say: Should be? Given the huge amount of FOSS conferences around, the number of free alternatives of conference organization systems is fairly small. We decided to go again with Indico, a python based system developed by CERN. It provides support for the whole conference life cycle such as the call for abstracts, the internal judging process, the scheduling and such. With nice help from the developers we got it running smoothly and integrated. Sometimes the interface is not really straightforward, but finally its a very feature rich yet flexible tool that feels like it has managed some large (CERN) conferences already. For the openSUSE conference 102 contributions were scheduled into four rooms in four days, so it will be quite a exhausting event . Unfortunately we still had to reject quite some submissions as the program is stuffed already. Please bear with us. This year we are really happy to have a joint event with the former SUSE Labs Conference for the first time. That not only brings a lot of high potential speaker to the event, but also much more low level topics around kernel, gcc and such. I think we lacked that a bit at the last conference. Also cool that Greg KH, well known kernel hacker, will enlighten us with a keynote. Beside the low level topics, we will hear a lot about community affairs, such as social skills for geeks or impressions from our ambassadors work. Another big block is around packaging and the organization and management of openSUSE Factory, our next stable distribution. Some knowledge sharing is always appreciated, I personally look forward to “Working Effectively with GIT” as I am still dreaming of svn in the nights And what we need to continue to grow our identity as openSUSE project are contributions around our setup and the relationship to SUSE, the commercial offering of SUSE and the importance of openSUSE in that. Michael Miller, SUSE Vice President of Global Alliances & Marketing, will give a keynote here, and there are other talks in that space. The motto of osc2011 is rwx³ which is a synonym of the idea of interactivity and creativity on the conference. That is a success already as more than the half of the contributions to the conference are BoFs, Workshops or hacking sessions. You do not have to fear to fall asleep in lengthy talks instead you will do stuff And finally there is the venue. If you have been to the conference last year I need to say its different this year. Nobody will serve you Coke, instead with Zentrifuge you are at a place where usually artists work and do exhibitions. This spirit of hands-on work quickly jumped over on us as the orga team and we are sure that spirit is good for openSUSE I hope you have registered for oSC 2011 already…. [Less]

This is another performance win. I’ve just pushed changes to the master branch to improve the import performance of binary Excel documents containing tons of form controls. The test document I used had an upward of 500 form controls which, prior to ... [More] the change, Calc would spend at least several minutes to load. I don’t know the exact amount of time it took to open the document because each time I tried to open it, I had to kill the app after I became too impatient to wait. Long story short, the same document now opens under 6 seconds on my machine. The poor performance in this particular case consisted of several different bottlenecks. They are inefficient algorithm in registering event listeners for VBA events, inefficient algorithm in querying the code name from the parent application, unnecessary VBA event registration for form controls, and sending unnecessary notifications to property value change listeners during import for each and every property value insertion. Registering event listeners for VBA events When each control is inserted, we register several VBA events for it in order to handle events from the VBA code. For each event, we would register by passing the target and listener pair to the handler that handles event notification. As it turned out, however, each time that happens, the handler has to introspect the type of the target because it is passed as UNO’s Any object. While each instance of that may take only a fraction of a second to complete, when calling it literally millions of times it adds up not to mention the fact that the target remains the same for 12 or so listeners that are being registered for each control. To solve this, I added a new method to register multiple event listeners for an identical target in a single call, to avoid repeated and unnecessary introspection of the target type. This alone has resulted in reducing the load time significantly (66% load-time reduction with my test document). However, this was still not enough with a larger number of controls since, as the number of controls grew, the load time would increase almost quadratically. Querying the code name from the parent application Another issue was the algorithm responsible for looking up the “code name” of the VBA module that the control belongs to. The code name is the name associated with each VBA module that Excel creates for each sheet. The name of the module does not necessarily equal the name of the sheet, and is unique to each sheet. The old algorithm would go through all existing form control instances in order to find a match, then backtrack the sheet it is on in order to determine the correct code name. But because it had to iterate through all existing controls, as the number of the controls grew, so would the time it takes to find a match. Since the code name is identical for each sheet, there was no reason to check every single control. So I added a new method to get the code name directly from the parent container of the controls. Since we only create one container per sheet at most, this has resulted in making the code name lookup independent of the number of controls, and has resulted in quasi-constant time lookup since the number of sheets doesn’t grow during the import. Unnecessary VBA event registration for form controls There are two types of controls that Excel supports. One is the older form controls that you can insert via Forms toolbar, while the other is the newer, OLE controls that you can insert via Control Toolbox toolbar. As luck would have it, Excel doesn’t support bindings to VBA with the form controls, so it was not necessary to register events for these guys when we import them (as Noel told me). Turning off event registration for form control import has surely cut down the load time significantly. Many thanks to Noel for giving me a patch to turn this off for form controls. Property value change listeners Even after all these performance bottlenecks squashed, the load time still didn’t feel as fast as it should be. So, I did another round of profiling. It indicated that, every time we set a new property value to a control via XPropertySet, we would notify all property value change listeners to allow them to react to the change or veto the change, and this happened unconditionally for every single property value insertion for every single control. Since the likelihood of having to veto or change other property values based on a new property value insertion during file import is close to nil if not zero, I added a new API to temporarily turn off this notification. This has cut down the last few seconds off the overall load time, down to 6 seconds in total. This notification is turned back on after the loading is complete. Future consideration There are several opportunities for future work. For one thing, the code name lookup also applies to the VBA event support in Writer. But because I wasn’t aware of how Writer organizes form controls, I didn’t touch its lookup algorithm. So, if the same inefficiency applies to Writer (which I’m not sure it does), then there may be a way to improve performance in that area. Another area to consider is reducing the number of VBA events to register. As Noel told me, we currently register 12 or so events unconditionally for all controls imported from Excel documents. But technically we only have to register events that are actually needed. So, if we can find a way to determine what events we need to register by either parsing the VBA code or any other ways, we can reduce the number of VBA event registrations during the import. This is all I can think of at the moment. Thank you ladies and gentlemen. [Less]

Some days ago SUSE released a new version of WebYaST, WebYaST 1.2. It provides better performance, a polished layout and new role management. For those of you who are not familiar with WebYaST. It is an easy-to-use, web-based configuration and ... [More] administration tool. That means that you can configure hardware, network, services, security, and many more in a browser. Since we offer a one-click configuration for WebYaST for a while we decided to upgrade it to 1.2. If you want to add WebYaST 1.2 to your appliance, you just need to go to the configuration tab of and click on the appliance icon. Then scroll down to the 'Additional options' and check the 'Enable WebYaST' checkbox. This will add the WebYaST 1.2 repository which matches with your applaince's basesystem, add all neccessary WebYaST patterns & packages and do some additional configuration. For more information take a look at this Blog. In case your appliance already has WebYaST 1.1 enabled you can upgrade to 1.2 by un-checking the Enable WebYaST checkbox and proceed with the instructions above. This is not required for openSUSE 11.4 appliances, as the 11.4 WebYaST repository got the newer packages since a while. And that is how WebYaST 1.2 looks like: [Less]