It’s nice to see someone showing interest, and also picking up the code .

I must definitely get the time to fix my experimental OBS build, and see the openSUSE version running again. For the record, there is room for improvement on the performance part (especially starting up speed).

Software Center with PackageKit backend in openSUSE Factory

Today the official coding period of GSoC 2011 ends. It’s been a four months journey, with challenges, failures and achievements, but nevertheless fun .

You may be wondering what is the status of my project; here it goes: current version of Software Center can be tested in openSUSE Factory; it can populate its database with data from an AppStream XML; it shows application information (fetched from the package manager); it installs and removes software, in the same friendly manner the ubuntu does (showing progress, handling dependencies).

Moreover, my patches to gobject-introspection, PackageKit and obviously software-center, are all upstream and released; kudos to the project managers and the community for helping me get them there.

There are still parts that need work; some of then have been intentionally left with lower priority from my initial plan, in order to get a functional version up by the end of the program; others weren’t covered by the planed feature set. These are: performance (current version is rather slow on first load, and also on showing list, due to many resolve calls), transaction history (it can be implemented using the almighty PackageKit), reviews (currently these are fetched from ubuntu servers), screenshots (same as reviews). Software Center itself passes a period of active development and changes, once its fancy Gtk+3 interface stabilizes, more work can be done into polishing the <other-distro> experience.

Although I’m generally happy with the result of the project, since this is a report, I want to outline what differed from my expectations and slowed me down from bringing a full feature set cross-distro Software Center:

• fast development – when I started hacking on software-center’s GUI, it was pygtk Gtk+2 based; a Gtk+3 branch existed, but was far from being usable; under the last few weeks, it was merged, and actively developed into a newly designed interface (which will become software-center 5.0);
• Gio, GLib, GMenu, GObject, usually libs starting with a capital G, which introspection bindings are about to stabilize; having to get them from trunk, and dealing with API breakage;
• waiting for the pygobject release; when it came, it broke my pygtk mixed work (since static vs GI are no longer permitted in the same program – which is the right choice. btw), and left me with no working GUI; luckily, I took the best advices on IRC, and also software-center devs fixed things along, so that the new UI isn’t affected by the underlying changes.

Something worth mentioning in this finale post is that OBS totally rocks.

Overall, I hope this effort won’t stop here, and with a bit of luck, it will be shipped by your favorite distribution

PS: for more implementation/testing/plan details, I have created this page on openSUSE wiki, please check it out.

- personal OBS project (playing around, tutored by DimStar), work in progress

- code tide-up, ready for merging into master

- features, usage and testing documentation, work in progress

I’m now focusing on the gtk3 part, and also documenting things around. Packaging has decreased priority, waiting for the pygobject release.

And done

It’s nice to write to you again. I’ve been having a 10 days vacation (that’s why there was no week 8 report), enjoyed it and now I’m back with fresh forces.

This short (started slowly on Tuesday) week’s activity regards:
- almost fixing a bug that prevents my PackageKit software-center from prime time: package information isn’t correctly refreshed after an installation/removal
- starting work on the openSUSE integration (the corresponding Distro class, removal of forgotten apt related imports, dependency identification and testing).

I will continue work on this side and hope that by the end of the next week, will have everything working and up for testing in openSUSE.

Cya

NB: I will have to provide for testing a trunk version of pygobject since a release is delayed by another awaited merge;

- 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

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

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!

Yep, the PK InstallBackend is shaping up !

Unfortunately, the only machine running this code is mine, the reason being this chain of dependencies:

- static Python bindings for PK are dead

- PK gi depends on pygobject invoke-rewrite branch of J5 (which isn’t
yet merged into master, but will make it to 3.2 release);

- PK gi breaks statically loaded glib in software-center master; therefore, the -gtk3 port of software-center should be used;

- software-center-gtk3 isn’t ready for merging into trunk – experimental design changes towards a friendlier 5.0 are being done.

Therefore I’m testing the install/remove routines on the small modules, such as the PendingView in the above screenshot, waiting for components stabilization.

Next week – and probably until week 6 report, I will continue work on the install parts and start developing the PK PackageInfo class.

PS: I’m undecided if I should make my reports biweekly or milestone based :-/

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.

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!