Привет всем!

Если у вас есть возможность поделиться своим опытом по поводу использования 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!

Hi all,

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.

As you can see, we still have some work to do, but we need everybody help : either on the issues I mentioned (feel free to say "I want to help on this" here) or to do more tests or even to start creating .service files (but we still need to fix the issues listed above).

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 !

Hello,

This is my 6th report concerning the progress of my gsoc project. First of all, I want to apologize because of the 5th report that is missing from last week. Due to some events, for me it was almost impossible to concentrate on work. Even though i did some things, it was not enough to create a report on. The previous week made me get out of schedule at least for a week, i will try to catch up this time by working more on weekends starting from this one. Even though in my initial plan there were about two weeks free time in the schedule that i could use in occasions like this.

Anyway, what’s up with the progress. As I have described in previous post, I am currently working on the matching code / algorithm. Some major improvements took place on the aug_process_tree method, which will be responsible for matching the initial tree with those coming as parameters. The tree traversal algorithm is now working completely, some issues however still exist in the matching of the tree nodes. Hopefully, i will be able to resolve this issues very soon, maybe even in the next couple of days.

Also, some basic drafts of the merging functions were added. Each function will complete the appropriate actions that must be carried , and will also represent each of the merging parameters /merging flags that will be used.

Finally, small changes and improvements took place in few other functions as well in the code. The plan for the next days is to complete the matching of the tree nodes and the merging. At least to a point where more more debugging tests would be able to be carried out.

Till next week,
Christos