PackageKit backend for Software Center: short week 7 report
Short weekly report is short, this week’s achievements:
- fixed the install/remove simulation bits (it can now tell what packages will be removed after applying changes)
- improved PackageInfo testing (works with both AptCache and PackageKit)
- found the problem with dynamic/static libs conflict: it is gio statically loaded from gtk and then Gio dynamically loaded from PackageKitGlib; loading Gio before everything seems to fix the conflict for now;
- got another round of refactor changes into trunk, thanks to mvo; this way my PK branch is one step closer to merging into software-center
ktnxbye
Exchange WebServices Offline AddressBook
It is now possible to download GAL contents for offline usage through exchange web services in Evolution. Offline GAL is termed as Offline Address-book (OAB) in Exchange WebServices and it may contain one or more Offline Address-lists (OAL).
The check-box, ‘Cache offline address-book’ would be sensitive if the OAB url is discovered using the AutoDiscover service from the previous page (‘Receiving’). On clicking the fetch buton, the available offline address-lists would be displayed in the combo box. The user can select the address-list which he is interested in.
If the GAL is not selected for offline usage. A GAL folder would be created in Contacts component and would be used just for auto-completion when Evolution is online.
To change an offline address-list, one just needs to go back to ‘Receiving page’ in preference and select a different address-list. This would remove the old OAL folder and its contents and create a new OAL folder. At the moment, evolution-ews supports caching only one OAL, though it is very easy to extend it to support many. I feel it would sufficient to have one at the moment, but if a need arises, the plugin can be extended to create new OAL folders on demand.
If an address-list is chosen for offline usage, one CAN auto-complete while the caching is in progress!! All operations are asynchronous and cancellable.
Internals
OAL’s would be listed in the link <OABUrl> + ‘oab.xml’. They would be available as compressed files, compressed using LZXD format. There are three versions of OAB ‘2, 3, 4’ and Evolution supports downloading, version 4 OAB Full Details file.
LZXD
To put it simply, lzxd extends the lzx decompression format adding support for differential updates. I have picked up the lzx decompression code from libmspack and modified it to make it decompress the lzxd file. The support for differential update is yet to added.
OAB
The format for the uncompressed OAB Version 4 file is available at http://msdn.microsoft.com/en-us/library/cc463914%28v=EXCHG.80%29.aspx . Evolution-ews has the decoder which decodes the oab file, converts to EContact and then we populates the address-book sqlitedb in chunks of 1000 contacts.
And now the contents are available for offline use 
CamelUrl props
“oab_offline” – says if oab is marked for offline.
“oal_selected” – contains the selected “oal id:oal name”
“oaburl” – contains the oab url
ESource props
“hosturl” – contains the host url, used for auto-completion.
“oaburl” – contains the oab url.
“oalid” – id of the OAL.
“gal” – a boolean that it indicates that its gal folder.
Designing the missing Web UI for Bongo
Improved Kernel Package Retention in 12.1
A long awaited feature of the openSUSE update stack is finally here!
Since some time, it has been possible to tell libzypp to not delete old
kernels on update:
multiversion = provides:multiversion(kernel)
in /etc/zypp/zypp.conf. That way, you don’t have to worry that a
brand new -rc kernel from Factory makes your system unbootable. This however
solves one problem and brings another one – you have to manually delete the
old kernel so that your /boot partition does not fill up. openSUSE 12.1 will
provide a solution to this, you will be able to tell what kernels you want to
keep after an update, other kernels will be deleted. The configuration is the
same file, /etc/zypp/zypp.conf:
## Comma separated list of kernel packages to keep installed in parallel, if the ## above multiversion variable is set. Packages can be specified as ## 2.6.32.12-0.7 - Exact version to keep ## latest - Keep kernel with the highest version number ## latest-N - Keep kernel with the Nth highest version number ## running - Keep the running kernel ## oldest - Keep kernel with the lowest version number (the GA kernel) ## oldest+N - Keep kernel with the Nth lowest version number ## ## Default: Do not delete any kernels if multiversion = provides:multiversion(kernel) is set multiversion.kernels = latest,running
If you configure this and the above multiversion variable, then after each
kernel update, during a subsequent reboot, a script will compare the list of
installed kernels with the multiversion.kernels setting and delete those that
are no longer needed. Examples:
- Keep the latest kernel and the running one if it differs. This is similar to
no enabling the multiversion feature at all, except that the old kernel is
removed after reboot and not immediatelly after installation. BTW, you
probably always want to include “running”:multiversion.kernels = latest,running
- Keep last two kernels and the running one:
multiversion.kernels = latest,latest-1,running
- Keep the latest kernel, the running and a my test kernel with a fancy
patch:multiversion.kernels = latest,running,3.0.rc7-test
If you want to try it, it’s all in Factory already. Check if these packages are
recent enough and uncomment the two variables in zypp.conf:
$ rpm -q --changelog kernel-desktop mkinitrd libzypp | grep -B2 312018
* Fri Jun 17 2011 mmarek@suse.cz
- rpm/post.sh: Touch /boot/do_purge_kernels on package install
(fate#312018).
--
- Add purge-kernels script to automatically delete old kernel packages
on boot, based on configuration in /etc/zypp/zypp.conf, variable
multiversion_kernels (fate#312018).
--
* Tue Jun 21 2011 dmacvicar@suse.de
- Add configuration template for automatic kernel
purge (feature#312018) to zypp.conf
$ grep ^multiversion /etc/zypp/zypp.conf
multiversion = provides:multiversion(kernel)
multiversion.kernels = latest,running
Happy updating!
First debugging session of LibreOffice code on iOS (simulator)

I am just debugging (well, not really, I am not expecting anything to actually do much interesting) for the first time cross-compiled LibreOffice code on the iOS Simulator. (So yeah, technically instruction-set-wise this is not cross-compiled, as the Simulator runs i386 code, too, but under a simulated iOS environment.) Not really that exciting, but still, couldn't help blogging. No, there is still nothing to "beta test", there is still no actual LibreOffice UI showing up or even any code to draw a single pixel on iOS.
A utility for merging configuration / sysconfig files – Week 7 Report

Source: http://www.openclipart.org
Hello again,
This is the 7th week report for my GSoC project. During the implementation of the matching procedures, i talked in my last blog post, there were some new developments concerning the project. That made the actual matching procedure halt for a while, because there are no effective way at the moment to test the matching progress in the actual implementation. Where is the problem? The problem that occurred is the handling of the special comments that are used in many of the sysconfig files. These comments may appear next to simple description comments but contain useful information that are then interpreted by the program, such information could be for example the type of a variable etc. So what now? This week I am trying to find an effective way to deal with this problem, the initial idea i have is to modify the sysconfig lens, used by Augeas, in order to represent the sysconfig files in a tree form (with more levels that the current) that will be suitable for the matching/sorting algorithms i have already implemented.
What else?
I got a response for my first patch i submitted in Augeas too, and i have learn many useful things from the tips. So among other things this week i had the chance to rework that patch in order to achieve a better result.
What i need to do this week?
– finish the modification of the sysconfig.aug lens.
– implement a way to effectively deal with the comments (special and simple ones).
Conclusion
During the last weeks I am on the toughest part of my gsoc project. I hope that when i finish this part of the project, there will be a burst of progress for the last parts of the initial schedule.
Till next week,
Christos
PackageKit backend for Software Center: week 6 report
Hi everyone, for this week report I would like to show you a screencast with the packagekit-backend branch of software-center:
As you can see in the video above, I’m using PackageKit in Software Center for the install/remove operations and also for fetching package information, such as summary, description and version.
The install backend lacks updates and addon management; also the dependency simulation is missing. For package information, work is still needed into getting license, installed_size and other custom fields, but all these seam doable.
Before you jump into running it by yourself, please note that to get PackageKit introspection working, you need the invoke-rewrite branch of pygobject, which will hopefully be merged into main and released next week.
This milestone being set, my work continues by completing the backend and then moving forward to other things such as optimizing or distro integration, packaging and testing
Off to Croatia!
I'll be enjoying the nice seaside of Dalmatia (Croatia) for the next 3 weeks and, hence, won't be updating packages or be otherwise reachable to fix stuff.
That being said, I really haven't been very active (to say the least) the last few weeks. Lost the moment(um), somehow. Dunno. Maybe the motivation problem will have fixed itself after my holidays. I sure hope so.
For really urgent matters, a few people in the openSUSE and FOSDEM projects have my phone number, just poke the right people ;), e.g. Andreas Jaeger.
I most probably won't be checking my email, but I should be tweeting, so that's an option to poke me as well.
PackageKit backend for Software Center: short week 5 report
This week I continued work on the install backend, especially connecting the PackageKit transaction signals to the software-center’s TransactionWatcher (also abstracted by me some time ago).
The challenge stands in differences from PackageKit and AptDaemon, such as in AD, after preparing a transaction and manually commiting it, one has access to the transaction object, and can watch for progress changes; in PK, after a transaction is launched, there are two ways of getting access to it: first by listening to a TransactionListChanged signal in D-Bus and second by watching the objects returned by the progress_callback callback.
The current approach, helped closely by hue-see (hughsie) on #PackageKit is to get the transactions from the callback and listen to the gobject notify::<property> signals.
More to come next week, stay tuned!
Status update on systemd for openSUSE Factory
here is a update on the work done on systemd for Factory :
(beware, post is long !)

- basic support for systemctl in chkconfig and insserv is done : it is pending review by maintainer before integration
- support for --root in systemctl was merged upstream and will be used by chkconfig/insserv patches above.
- a patch has been submitted to upstream systemd to parse insserv.conf : this patch only handles the "system facility" part of insserv.conf and automatically adds depencies specified in the file
- quick investigation on Yast2 to adapt runlevel editor for systemctl support : we really need help from other people, as I don't have any knowledge of Yast internal and it seems the yast dbus client part might be missing some parts, needed for runlevel editor to talk with systemd.
- no work done on /usr as separate partition : it is not a systemd issue in itself but from other programs which might be using data from /usr before /usr is available. The best solution would be to mount /usr from initrd => help needed !!
- (open)SUSE is using unofficial LSB target named $ALL which is supposed to put services requiring it at the end of the boot sequence (or at the beginning of shutdown sequence); After discussing with upstream : on a static boot system (sysvinit), it is easy to resolve such dependencies, but it isn't on a dynamic system (systemd). There is a ugly hack to handle that (creating a ALL.target file which is starting after default.target is done) but it would be probably better to just fix the 4 initscripts which are still using $ALL ( amazon-late, stoppreload, Susefirewall2_setup and vboxes). I'll open bug for them.
- X-Interactive support in systemd is not working properly : it will only work before getty is started and is broken if you try to start a service after boot. We need to transition packages which are still using X-Interactive to systemd-ask-password (which takes care of the async conversation). Only two packages need to be ported :
- apache2, when querying password for SSL certificate : apache allows to start a script to handle the password request. We only need to plug the script and configuration part in our package
and get it used when booting with systemd. - openvpn : this one is a bit complex because we can either write a daemon which would do the interface between systemd and openvpn management interface or we can try to patch openvpn to have a similar feature as apache and get this patch upstreamed. The latter has the preference of systemd upstream.
- For both packages, help is welcome.
- For compability with sysvinit, support for
from /etc/insserv.conf in systemd was not added, so we could remove X-Interactive from openvpn/httpd sysvinit scripts but still have the function when booting from /sbin/init, thanks to /etc/insserv.conf list. - /etc/init.d/kbd was not handled properly : this should be fixed inFactory today or tomorrow, with systemd taking care of setting up keyboard properly. However, we might need to improve /etc/sysconfig/keyboard parsing in systemd. More tests are needed (and of course, help is welcome).
- discussion in progress on opensuse-packaging mailing list and upstream on a set of cross distribution RPM macros to handle systemd unit files.
Thanks everybody for your attention.
I would be great if we could get the ball moving and maybe get one of
the next Factory milestone be a "systemd" test release but to reach this
point, we need YOU !
