Older blog entries for StephanPeijnik (starting at number 11)

update-manager on alioth

As I noted in this weeks update-manager progress update one of my tasks was to create an alioth.debian.org project and get my branches uploaded to Debian.

I did not imagine that alioth admins (hi there, a huge "thank you" goes to you guys) would be this fast with reviewing and accepting the project and enabling bazaar support for me.
Anyways, the project has been accepted and its new home is on alioth. I have also already uploaded both my update-manager branch and python-apt branch to bzr.debian.org

Additionally I have generated the API documentation, which is also hosted on alioth, and created a development disccusion mailing list, update-manager-devel at lists.alioth.debian.org.

If you are interested in this project feel free to have a look at what I've done so far and join the development discussion. Comments, critizism and ideas are always welcome.

Syndicated 2009-05-28 11:44:00 (Updated 2009-11-09 20:21:28) from sp

update-manager weekly update #0

It has been more than a month since I last wrote about my work on update-manager during this year's Google Summer Of Code and I am somewhat ashamed I wasn't able to provide you with updates more regularly.

So first of all, yes, I did do some work and yes, there has been quite some progress. Basically both private and university stuff have kept me from writing and that's why I'd like to start with this series of weekly updates today.
This series are meant to summarize what has happened during a week of writing code and give you an overview of what's happening. This first issue however will sum up the past month.

So let me begin explaining what has happened since my last post.

update-manager bazaar repository

All code I have written so far is available through a public bazaar branch on launchpad.net. My branch's page can be found here and provides you with its history and of course instructions on how to obtain the code. The location is only temporary though, as I am going to move hosting over to alioth.debian.org. This is on my task list for next week.

modular design

I have ripped apart nearly all of update-manager and put it together in a more modular way, which should implementing new frontends or backends more easy, whilst also simplifying code maintenance.

The new design consists of four major parts:

• The application class is responsible for parsing command line arguments, initializing all other components correctly and coordinate communication between the frontend and the backend.


• The backend itself is defined through the UpdateManager.Backend.BackendBase class and each implementation subclasses BackendBase. It is responsible for interacting with apt.


• The frontend is again defined through a base class, UpdateManager.Frontend.FrontendBase. This part of update-manager provides the userinterface, handles user input and starts operations accordingly.


• Lastly there is the distribution-specific part, which lives inside the UpdateManager.DistSpecific Python module and is defined by its own base class, DistBase.

backend implementation

When I started working on update-manager it heavily relied on synaptic and used it to do the dirty-work. However, together with my mentor, mvo, I decided to drop synaptic support and rather concentrate on using python-apt. This means that the only backend implementation right now is a python-apt backend.

The python-apt backend is currently a work in progress, but already includes some basic functionality. Right now it can (re-)load the package cache and package lists and is able to provide a list of packages which are upgradable to the frontend.
Whilst implementing these functions I noticed some shortcomings of python-apt itself, fixed those and got mvo included in his python-apt branch at launchpad.

frontend implementation

I started re-implementing the Gtk frontend as provided through current update-manager and right now it visualizes the package cache reloading process and provides users with a list of upgradable packages. However, that's pretty much all of the functionality it includes right now, which is why implementing more functions is pretty much on the top of my todo list.

Additionally I have ported the text frontend, as included in Ubuntu, to the new modular system, and this frontend's code really shows how easy adding a frontend with the new modular design is. This frontend contains the same functionality as the Gtk frontend.

distribution specific code

The core described above does not include any distribution specific code anymore, which is the main focus of this project. The implementations of distribution-specific functionality contains classifiers for update categories for both Debian and Ubuntu, whilst I focused on getting things right with the Debian implementation for now. These classifiers allow the frontend to let the user know which kind of update they are about to install, like a security update, a recommended upgrade or a third-party (unofficial) upgrade.

documentation

As update-manager was poorly (read: hardly at all) documented I started documenting the API using sphinx. However, right now the generated documentation cannot be found anywhere yet. This should change as soon as an alioth project for update-manager has been created.

next week's tasks

I would also like to provide you with my task list for the coming week. The list, ordered by priority, is:

• Register an alioth project and move the bazaar branch to bzr.debian.org


• Generate an HTML version of the API documentation and put it on alioth.


• Implement changelog-fetching for the Debian-specific module and make use of that from within the code and the Gtk frontend.

As you can see this list is rather short. This can mainly be attributed to a few university assignments, and instead of providing a long list of tasks which I probably won't be able to finish I rather keep the list short and hopefully get things not on this list done too.

Syndicated 2009-05-27 23:52:00 (Updated 2009-11-09 20:21:28) from sp

update manager to become more modular

In my last post I wrote about how I got accepted for GSoC09 and am going to work on update manager. Now I couldn't wait for the actual GSoC09 coding period to start and created my own update manager branch right away and started hacking.

So far I have only written a few lines of code, but my mentor Michael Vogt and me came to the conclusion that whilst working on the internals of update manager it might be a good idea to make the whole program more modular.
Right now all the different functions of update manager (being the UI/frontend and the package manager interface/backend) are mixed up in various files, which makes not only reading the code harder, but also extending update manager more difficult. This was reason enough for me to have a look into making update manager more modular in its design and some of my efforts can already be seen in my update manager branch.

If you have any comments on the proposed backend interface or see major problems with it, please let me know, I would really appreciate some input on that. Also, the UI and the distribution-specific code interfaces are next on my list, before beginning to actually move existing code around. I hope to be able to finish that work before the GSoC hacking period starts, so I can concentrate entirely on my task of making update-manager distribution independent.

Syndicated 2009-04-24 17:41:00 (Updated 2009-11-09 20:21:28) from sp

Summer Of Code 2009: Working for Debian

Yesterday Google announced the students and projects that have been accepted for Google Summer Of Code 2009 and guess what: my project was accepted. This means I will be working full-time on FOSS this summer.

So I guess it's about time to introduce my project to you: Distribution-independent update manager, mentored by Michael Vogt (mvo).

Okay, I believe some of you might wonder what this project is all about, as update-manager is in the Debian package archive already. There is a problem with update-manager though. As you see in the package's version number (it contains ".debian") update-manager has been adapted for use in Debian. Also, Debian contains update-manager 0.68 right now, whilst upstream (Ubuntu in this case) has released 0.111.6 (actually there were quite a few upstream versions meanwhile). The reason Debian is nowhere near being up-to-date with upstream is that right now a lot of effort has to be put into porting update-manager to Debian every time a new upstream release is made, because certain Ubuntu-specific functionality breaks update-manager in more or less severe ways on Debian.

This leads me directly to what my project is about: making update-manager (Ubuntu-) distribution-independent, but not package manager independent.
There are 6 main goals for this project, which I will be working on in the order below.

• Analyzing the code and identifying Ubuntu-specific parts.


• Creating a distribution-plugin interface and moving the Ubuntu-specific parts into a distribution-plugin, creating a core package that is distribution-independent.


• Creating a special notification for important/security related updates and providing the code that handles updates from security.debian.org as such.


• Creating a backend-plugin interface, moving the synaptics backend into a backend-plugin and optionally create a python-apt based plugin.


• UI redesign, providing a simpler interface to average joe, whilst allowing more experienced users to optionally display more information.


• Automatic downloading & installation of updates. This is still up to discussion, as automatic downloading is already provided by software-properties (-gtk and -kde) and automatic installation can be handled by unattended-upgrades. Both packages are part of Debian already.

Please note that this list should not be considered final and may be extended or modified over time. It exists to give you an overview of what exactly my project is about and how I am planning on carrying out the tasks.

Finally I wanted to let you know that I will keep you posted on the progress I am making, via this blog. Alternatively a blog aggregator for Debian's GSoC students has been set up over at http://soc.alioth.debian.org/feeds/blogs/, where you can not only find my posts, but those of all of Debian's students.

Syndicated 2009-04-21 07:10:00 (Updated 2009-11-09 20:21:28) from sp

Python everywhere: computer games

This is the second article in my series Python everywhere and covers the use of Python for in computer games. The first article of this series covered the use of Python for the conficker worm scanner tool and can be found here.
Games written in Python

As PyGame provides a nice library for writing games purely in Python it is becoming more common to use Python for this task too. The book "Beginning Game Development with Python and Pygame" is linked directly from the PyGame homepage, and thus is probably a good resource if you want to start writing games in Python.

However, I do not want to go into detail on how this library works, but rather provide you with a few examples of games written in Python. To provide you with a few examples I had a look at the PyWeek homepage. PyWeek is a Python Game Programming Challenge which invites everyone to participate, so the winners of this contest are of high-quality, and I'm showing you the latest two winners.

There are always two winners of PyWeek in for indivduals who have created games and teams. The latest winners are "Team Rambo" in the individual effort category and "Midnight Sun" with their two-man team.

PyWeek: Team Rambo's Stringrolled (individual)

Stringrolled makes use of the pygame library I mentioned earlier and is a platform game. In a mere 2377 lines of code, including comments and blank lines, Team Rambo created an impressive game, coming with a story, easy-to-learn controls and nice 2D-graphics, screenshot below.

PyWeek: Midnight Sun's Kite Story

Kite Story is yet another interesting game, with game mechanics I have not seen ever before. You are controlling a kite with your mouse and are trying to catch objects, such as bees and birds, with the kite's rope. So what you basically do you draw a loop around an object with your mouse and that way catch it. Every third cought object you advance to the next level, but keep in mind not to collide with the objects, because you will lose them and in turn be doing the previous level again, screenshot below. It should be noted that this game does not make use of PyGame at all, but rather relies on pyglet, and is 1997 lines of code in length, again counting blank lines and comments too.

Games using Python

You have seen now that it is possible to write a game completely in Python, but there's another use-case of Python in games: scripting.
Some (proprietary) games, such as Civilization IV, offer Python support in their editors and SDKs. This quote from the article at 2kgames.com should give you a good idea of what can be done using Python in Civilization IV:

The next level offers Python and XML support, letting modders with more experience manipulate the game world and everything in it. XML (eXtensible Markup Language) files can be edited in standard text editors or in special XML file editors that have ease-of-use features like a grid view. Editing these files will allow players to tweak simple game rules and change or add content. For instance, they can add new unit or building types, change the cost of wonders, or add new civilizations. Players can also change the sounds played at certain times or edit the play list for your soundtrack. NOTE: You can have custom soundtracks simply by adding music to the custom folder. You only need to edit the XML in order to assign certain pieces to specific eras or remove certain pieces.

The Python scripting language is fully integrated throughout the game and offers experienced modders a chance to really strut their stuff! People with some programming skills will be able to do things to alter the game in interesting and extraordinary ways. For instance, all of the game interface screens are exposed to Python, so modders will be able to change the information that's displayed, as well as how it's positioned on the screen. We also use Python to create and generate all of the random map scripts that are included in the game. So, players will now have the ability to add scripted events to the game like automatically generating units when a tile is reached, having specific situations trigger automatic war, or get this, bringing back Civil Wars caused by unrest, Civ II style!

EVE Online is another game making use of Python, as an article over at eveonline.com points out.

Python everywhere - also in compuater games

Even though I am sure you can come up with a lot more examples of Python being used in computer games I think I have proven my point. Python is being used not only to create computer games, but sometimes also to provide developers with a way of extending games. To me personally it feels as if adoption of Python for this very task is increasing too, and I expect Python to be used even more by the game development community in the future.

You can expect the third part of this series to be released in about a week, so please check back regularly if you like the series.

Syndicated 2009-04-02 17:35:00 (Updated 2009-11-09 20:21:28) from sp

Problems running PHP as a separate FastCGI process

As some of you might have noticed this webserver has not been that responsive in the past few hours and I have been working hard on getting that fixed. I finally identified the problem and was able to fix it.

The root of the problem was my setup running PHP as a separate FastCGI process. Unfortunatly it seems as if PHP can only handle 500 requests per FastCGI process and then seems to lock up.
The old setup of this site didn't cause such problems and it seems the problem lies in not setting the PHP_FCGI_CHILDREN and PHP_FCGI_MAX_REQUESTS environment variables with the new setup.



I initially thought that the default values of those environment variables were safe, but they are not. As I already wrote PHP seems to lock up after 500 requests and the solution lies in changing PHP_FCGI_CHILDREN, which defaults to 0 (no additional processes) to something bigger than 0 (I am using 2 children to make sure I have at least one PHP process reading for answering requests at any time).
Why? Quite simple, if you increase the value the PHP root process becomes some sort of manager and delegates requests to the children, as expected. However, using PHP_FCGI_MAX_REQUESTS it only forwards the specified number of requests to a child process before killing it and starting a new one. Problem solved.

Information on this behaviour can not be found in the PHP online manual, but rather at http://lxr.php.net/source/php-src/sapi/cgi/README.FastCGI.

Syndicated 2009-04-01 12:06:00 (Updated 2009-11-09 20:21:28) from sp

Python everywhere: extending applications with Python

Extending applications with Python: gimp, Evolution, Inkscape, Paint Shop Pro, [...]

Syndicated 2009-03-31 14:33:00 (Updated 2009-11-09 20:30:21) from sp

Feeding spamassassin with fresh spam cont'd

A few days ago I wrote about how I wanted to attract some spam in order to feed my spamassassin's bayes filter with a lot of 'known-bad' emails. However, until now this experiment has not worked out as I thought it would. Even though links to the page providing the email addresses which are meant to be spammed have been placed on quite a few pages not a single spam email has been received by my system.

I am wondering if I have done something wrong or if those nasty email crawlers simply haven't stumbled across my little page yet. Does anyone have something similar up and running and would like to provide me with some input or tell me what exactly I am doing wrong?

Feeding your spamassassin with fresh spam

Recently I set up a new mailserver and the spamassassin's bayes filter running on that machine has not been feeded with enough spam yet to be working properly. So how would one go about getting that little bugger some usable information?

The way I chose was setting up a special sub domain having both a web and mailserver running. The webserver does nothing but present a robots.txt which basically disallows all access from good web crawlers and for all other requests it presents the requester with an email address. That address is randomly generated and information about the requester stored in a text-file. An email to that address will cause the email to be stored in a special mailbox. A small script in turn issue 'spamc -L spam' for all new messages in that mailbox and so feeds the bayes filter.

I am curious about how well that is going to work, but actually it should attract quite some spam

 

The iPhone is out...

And DefectiveByDesign has sent out an action alert. On his blog Gregory Heller of DefectiveByDesign explains the problems that exist with the iPhone and asks people to take action.

Personally I believe the iPhone is not worth buying. Besides running proprietary software and implementing digital restrictions management it doesn't support UMTS and HSDPA, which are supported by nearly every other phone out there. One should rather call that thing iPodMobileWithTouchscreen if you ask me.