Michal Čihař - Blog Archives for Coding

python-suseapi 0.22

The python-suseapi 0.22 has been released last week. The version number shows nothing special, but one important change has happened - the development repository has been moved.

It's now under openSUSE project on GitHub, what makes it easier to find for potential users and also makes team maintenance a bit easier than under my personal account.

If you're curious what the module does - it's mostly usable only inside SUSE, providing access to some internal services. One major thing usable outside is the Bugzilla interface, which should be at one day replaced by python-bugzilla, but for now provides some features not available there (using web scraping).

Anyway the code has documentation on readhtedocs.org, so you can figure out yourself what it includes.

Translating Sphinx documentation

Few days ago, I've started writing Odorik module to manipulate with API of one Czech mobile network operator. As usual, the code comes with documentation written in English. Given that vast majority of users are Czech, it sounds useful to have in Czech language as well.

The documentation itself is written in Sphinx and built using Read the Docs. Using those to translate the documentation is quite easy.

First step is to add necessary configuration to the Sphinx project as described in their Internationalization Quick Guide. It's matter of few configuration directives and invoking of sphinx-intl and the result can be like this commit.

Once the code in repository is ready, you can start building translated documentation on the Read the docs. There is nice guide for that as well. All you need to do is to create another project, set it's language and link it from master project as translation.

The last step is to find some translators to actually translate the document. For me the obvious choice was using Weblate, so the translation is now on Hosted Weblate. The mass import of several po files can be done by import_project management command.

And thanks to all these you can now read Czech documentation for python Odorik module.

Odorik modul 0.4

Dnes jsem vydal novou verzi Python modulu Odorik. Přidává spoustu užitečných vlastností pro zjištění stavu účtu.

Jako bonus k tomuto vydání je dokumentace přeložená do češtiny za použití Weblate.

Python modul pro Odorik

Pokud náhodou použáváte operátora Odorik, mohl by se vám hodit můj nový modul pro Python. Dokonce ani nemusíte umět Python, dá se použít i přímo z příkazové řádky.

Funkčnost je zatím velmi jednoduchá, ale čase určitě přibudou další užitečné funkce (nebojte se mi nahlásit nápady).

Zjištění zůstatku na účtu:

$ odorik balance
balance: 123.45

Zjištění aktuálního využití dat:

$ odorik mobile-data --phone 00420789123456
bytes_total: 111593707
bytes_down: 87039672
bytes_up: 24554035
price: 0

Odeslání SMS zprávy:

$ odorik send-sms 00420789123456 "Ahoj, jak se mas?"

Více příkadů naleznete v dokumentaci.

Migrating code to github

As you might have noticed from my previous posts, we've moved phpMyAdmin code to github. Now I'm going to describe some things which might be useful for you if you are about do to similar switch.

While using git, moving to another hosting provider should be pretty straightforward. Just add another remote, push code there and it should be done. On the other side you probably have dozens of things in your infrastructure which you need to adjust. So the first thing to do is write down what all services are connected to your current git repositories. Let me name some which might be worth checking:

  • continuous integration server
  • snapshots generating
  • demo server (in case you're providing something like we do)
  • commit notifications
  • various statistics services such as cia.vc
  • website generating
  • references in wiki, website and documetation

Once you think you have remembered all important things (the less important will probably show up anyway, but majority of things should work), you're ready to make the move.

I've decided to make the move in few steps. First push all data to new location, what can take some time. I'll get in more details to that later. In the same time I asked all contributors to give me their login information, so that I can allow them access to new repositories. Once all recently active developers were migrated, it was time to push all remaining commits to new git repositories and make the switch for real.

Pushing git repo to another location, should be pretty easy. On the other side if you have many branches, it get's slightly more complex, I've ended up with following shell snippet (pushing all branches present in origin to github remote):

git branch -r | grep origin/ | grep -v HEAD | sed 's@.*/@@' | while read b ; do git checkout $b ; git push github $b:$b ; done

Please ensure that you check output of this, because you may hit network problems somewhere in the middle and you end up with few branches than you expect. As the code is pretty much idempotent, you can safely run it several times until there is nothing to push. You should also push all tags to new location:

git push --tags github

Okay, we've all data on right place, so let's switch all our users to new location:

git remote set-url origin git@github.com:phpmyadmin/phpmyadmin.git # read/write
git remote set-url origin git://github.com/phpmyadmin/phpmyadmin.git # read only

Of course everybody has to do this manually.

Next good thing is to let people know when they are using wrong repo (which will stay there for some time). Unfortunately there is AFAIK no way to warn them on pull, so let's warn at least on push:

$ cat > hooks/update
echo "phpMyAdmin git repositories have moved to https://github.com/phpmyadmin"
exit 1

I think this is pretty much all. You can find some more bits in our Git migration wiki page.

PS: Thanks to github for offering us hosting and sorry for breaking their branch displaying page by too many divergent branches.

No new dictionaries tarballs on no change

I've just changed scripts used to generate dictionaries for StarDict to avoid creating new tarballs when there is no real change in the data. This should avoid needless updates of the tarballs and automatically built packages when there is no real change in the data underneath.

If you somehow relied on fact that there is new tarball/package every day (or month for "stable" versions), this is no longer true and new ones will be generated only on changes.

I only hope I've tested everything properly and tarballs will really be generated on change :-).

Making Gammu use GLib

I had this topic in mind for quite a long time, but it got more recently more attention because of discussions on gammu-users mailing list. Gammu should use some library for do basic stuff like strings or date manipulations, logging and so on.

The reason is that having own implementation of all that is not really useful and just source of another amount of bugs. Currently mi intention is to use GLib, simply because I don't know any C alternative (though there are probably lot of C++ cross platform libraries).

Of course the biggest question is how to make the change, because it will be obviously intrusive and making such big changes will probably lead to several months of work without really making another release. Even if it will be done on separate branch (what would be most likely the case), developers will spend most of time on this issue and not much time will be spent on bug fixes (and backporting them).

Getting rid of SVN

Around three years ago I've migrated my stuff to Subversion from GNU Arch. Last year I migrated most important/alive things to Git. Unfortunately not all, so I still needed to host SVN server on my own.

I think it's now time to get rid of it :-). In past weeks I've moved most Debian packaging stuff to some team/collab-maint repositories (being it Git or Subversion), because I really don't see need for hosting that stuff on my own.

The remaining repositories are mostly historical (with single exception of StarDict dictionaries conversion tools) and nobody will probably care if they are gone. Ah and there are some dead projects as well which were never finished and will never be :-).

Anyway svn.cihar.com is going to disappear soon and nobody will miss it.