archives/2008/08

directive

2009-11-13T20:06:57Z

Directives are similar to a WikiLink in form, except they begin with ! and may contain parameters. The general form is:

[[!directive  param="value" param="value"]]

This gets expanded before the rest of the page is processed, and can be used to transform the page in various ways.

The quotes around values can be omitted if the value is a simple word. Also, some directives may use parameters without values, for example:

[[!tag  foo]]

A directive does not need to all be on one line, it can be wrapped to multiple lines if you like:

[[!directive  foo="baldersnatch"
bar="supercalifragilisticexpialidocious" baz=11]]

Also, multiple lines of quoted text can be used for a value. To allow quote marks inside the quoted text, delimit the block of text with triple-quotes:

[[!directive  text="""
1. "foo"
2. "bar"
3. "baz"
"""]]

ikiwiki also has an older syntax for directives, which requires a space in directives to distinguish them from wikilinks. This syntax has several disadvantages: it requires a space after directives with no parameters (such as [[pagecount ]]), and it prohibits spaces in wikilinks. ikiwiki now provides the !-prefixed syntax shown above as default. However, ikiwiki still supports wikis using the older syntax, if the prefix_directives option is disabled.

jornadas-en-pagina12

2009-01-22T04:24:04Z

Juanjo nos cuenta que hay un resumen de las Jornadas Regionales (a las que no fui, lo siento Facu) en Página/12. Yo me tomé un minutito más y los busqué (y encontré) online.

packaging-python-in-debian

2009-01-22T04:24:04Z

Just a note: from now on some posts will be in English. I just want to make sure some of them are worlwide readable.

During DebConf8 I met John Wright, who works in HP. He packages a couple of python things, like trac-mercurial (currently in sid only), and he offered to teach me how to package python things.

I've been trying to do that for a couple of years, but Debian's Python Policy is just too much for me. Call me lazy, $DEITY knows I know I am, but I just can't cope with so much and dense info.

So, I tried to look for automatical tools to do it. Two years ago the only thing I could find was (WARNING: ugly colors ahead) packer, but its vitality is rather low: according to FreshMeat, it was added on Dec 2005 and last updated on Feb 2006. I started using it, but its interface is not very good, so realeasing further versions was not an easy task. Also, I think now it's very out-of-date to Debian Policy.

This week I tried again, now trying to find something that could use either python-support or python-central to manage the python package, and also that it used the info from setuptool's setup.py, but I only could find some incomplete tutorials.

So John explained it to me. It really comes down to using dh_make, the starting point of debhelper. Before you run it you have to make sure everything's in place for it. That means to put the code in a directory which name is the name of the program, followed by a dash, followed by the version, like psync-0.4.1.

Now you just run dh_make --createorig, who asks what kind of package you're about to build. Normaly a 'single binary' is enough. It will show you some info it has gathered from your environment, about who you are and what package you're building. This will also create a .orig directory in the parent directory (making if a sibling of the current one) from the current directory, so make sure no cruft goes in. Here is the point were if there is no setup.py file, you just add it with the proper info.

This creates the debian directory with a lot of files on it. Those who already read about Debian packaging will find familiar files. If you're not, the best way to figuring out what goes where is the proper Debian Policy.

The first file you have to edit is control; just make sure that you add python and python-support as BuildDeps and ${python:Depends} as Deps.

The rules file is a little more complicated. It's a Makefile with several targets. configure must have the commands needed to configure the project prior to building it. Most python programs don't need this or the next one, which is the build target. This one obviously should have the commands needed to build the program. The third one is clean, where you usualy just neet to replace the boilerplate $(MAKE) clean with python setup.py clean. The install target will need a python setup.py install --prefix=$(CURDIR)/debian/psync/usr. Just check out the $(MAKE) invocation and you'll figure it out.

The last one is the binary-arch target. This one has lots of calls to debhelper functions. If you read it carefully, you'll see a dh_python call, commented out. Don't use it, use dh_pysupport. This is the hook for python-support support. This is the part that does all the magic to make sure that you don't break the Debian Python Policy. And that's mostly it. You can comment out a couple of dh_ functions, like dh_strip or dh_shlibdeps (shared libs deps).

Another file to edit, and this might be the last one, is changelog. This one has a particular format, so I suggest to use dch from the devscripts package. The one you'll find is a template the dh_make left for you to fill. You just need to put the bug number of the ITP bug. What, you haven't send an ITP but yet? Well, do it! Then you can use dch -a to add new entries to the current version's entries, dch -i to increment the Debian version and maybe dch -r to update the date at the bottom of the current version. See its manpage for further options.

Last, there is some junk in the debian directory, most of them the *.ex files, which are just examples. You can safely get rid of them, or read them to see if they suit you.

The next step is to build it. This is as easy-peasy as running dpkg-buildpackage. This will build a .deb file, a .dsc file, a .orig.tar.gz file, a .diff.gz and a .changes file in the parent directory. This is the outcome of all the work you've done so far, but is not finished yet. You better run lintian on the .dsc file and the .deb file. If you add the -i option you'll get some explanation on why you failed to give a proper, no-lint package.

So, that's it. It's a longish post, but should get you up packaging python apps in a few minutes. The are still a few problems: you end up dup'ing info: in the setup.py file and in various files in the debian directory. Maybe I'll hack something to workaround this.

debian python

search-bg.gif

2009-11-13T20:06:57Z

openstreetmap-update

2009-01-22T04:24:04Z

De acuerdo a la FAQ, los mapas se actualizan los miércoles. Habrá que esperar...

openstreetmap

2009-01-22T04:24:04Z

openstreetmap-update

De acuerdo a la FAQ, los mapas se actualizan los miércoles. Habrá que esperar...

openstreetmap

Posted Sat 02 Aug 2008 06:40:17 PM CEST

Tags:

openstreetmap

Map Junkie. Ése es el título que me corresponde por haber estado más de 5 horas culo en silla agregando calles, avenidas y otras sarazas al OpenStreetMap de mi querida ciudad natal. Completé un poco Nueva Córdoba, hice casi toda Ciudad Universitaria y estiré las avenidas que luego se transforman en rutas: Vélez Sarsfield, Colón, Juan B. Justo, Núñez, la ruta 20, Pajas Blancas, y muchas las supercalles/subavenidas de esta ciudad. Hasta hice algunos pedazos de barrios donde me gusta el trazado de calles (nada de esos aburridos cuadriculados, sino más cercano a las callecitas de Europa).

¿Cómo hice todo eso sin un GPS y sin mover el culo de la silla? Simple, el sitio tiene un flash applet que te muestra de fondo las fotos satelitales de Yahoo! Y la verdad es que anda muy muy bien, hasta me anduvo en konq4 y todo.

Es notable todo lo que conozco de mi ciudad, los pocos nombres de calles que recuerdo (¡Quiero un auto! ¿Nadie tiene uno que le sobre?) y lo muuucho que falta por hacer. El resultado no parece estar disponible ya ya, aunque cuando estás por empezar a usar el applet te advierten que estás editando los datos en vivo. Mañana veremos qué pasa...

openstreetmap

Posted Sat 02 Aug 2008 08:33:41 AM CEST

Tags:

openstreetmap

2009-01-22T04:24:04Z

openstreetmap