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.

Привет всем!

Если у вас есть возможность поделиться своим опытом по поводу использования Linux дома или на работе, приглашаю сделать это на страницах этого дневника. Тематика статей может быть любой.

Об условиях. Для того чтобы получить право публикации здесь - необходимо написать не менее трех статей. Желательно, чтобы они были грамотными, но это не проблема. Главное - интересное содержание. Три статьи - для того, чтобы я мог убедиться, что автор не иссякнет после написания одной-двух статей. Все присланные статьи будут опубликованы от имени тех авторов, которые пришлют эти статьи и в том виде, в котором они сами пожелают указать себя (или ники или полное имя). Адрес электронной почты приведен в моем профиле.

Привет всем!

Если у вас есть возможность поделиться своим опытом по поводу использования Linux дома или на работе, приглашаю сделать это на страницах этого дневника. Тематика статей может быть любой.

Об условиях. Для того чтобы получить право публикации здесь - необходимо написать не менее трех статей. Желательно, чтобы они были грамотными, но это не проблема. Главное - интересное содержание. Три статьи - для того, чтобы я мог убедиться, что автор не иссякнет после написания одной-двух статей. Все присланные статьи будут опубликованы от имени тех авторов, которые пришлют эти статьи и в том виде, в котором они сами пожелают указать себя (или ники или полное имя). Адрес электронной почты приведен в моем профиле.

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

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

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.

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!