A l'hora de desenvolupar aplicacions informàtiques en grup és molt important disposar d'un sistema de control de versions (VCS, version control system). Explicat molt breument, els VCS són eines de desenvolupament que permeten desar captures del codi font (revisions) creant tot un historial de canvis a mida que avança el desenvolupament del programa; a més, permeten compartir aquestes captures amb els companys de treball i normalment tenen capacitats per resoldre conflictes entre revisions creades en para?lel per diferents persones.

Un VCS potent utilitzat correctament pot incrementar la productivitat de forma dràstica, al reduir problemes de coordinació facilitant que diferents desenvolupadors puguin compartir fàcilment les últimes versions de la seva feina i que més d'una persona pugui fer canvis simultanis a un mateix conjunt de fitxers minimitzant els possibles conflictes resultants.

Hi ha un gran ventall de sistemes de control de versions disponibles, dels quals el més conegut és segurament el Subversion. Aquest, però, permet únicament un model centralitzat i en general és bastant limitat. Personalment prefereixo sistemes com ara el Bazaar (bzr). (El Git és encara més potent, però és molt més difícil d'aprendre a utilitzar, pel qual en aquest apunt em centraré en el Bazaar; també hi ha altres alternatives, com ara el Mercurial, però no estic familiaritzat amb aquestes).

Instal·lació

En sistemes com ara l'Ubuntu o Debian està disponible en un paquet anomenat «bzr» i segurament el mateix sigui cert per a altres distribucions de GNU/Linux. Si feu servir un altre sistema operatiu podeu baixar-lo de bazaar.canonical.com.

Com a nota al marge, el Bazaar també disposa d'una interfície gràfica (Bazaar Explorer), però ja que aquest apunt l'escric orientat a desenvolupadors només explicaré el seu ús des de la línia d'ordres.

Configuració

Abans de poder fer operacions d'escriptura cal que digueu al Bazaar com us voleu identificar. Podeu fer-ho de la següent forma:

bzr whoami "Nom Cognom <email@domini.tld>"

En cas que feu servir el portal Launchpad, també podeu habilitat la integració amb aquest (si no coneixeu el Launchpad, podeu ignorar això):

bzr launchpad-login nom_usuari

Primers passos

Imaginem que estem dins un directori «el-meu-projecte» on hi tenim un seguit de fitxers de codi («main.c» i «utils.c»). Per començar a utilitzar el Bazaar amb aquest codi el primer que hem de fer és crear una branca:

bzr init

Ara podem afegir-hi els fitxers que volem que controli:

bzr add main.c utils.c

i tot seguit podem crear una primera revisió (una captura del contingut actual dels fitxers):

bzr commit -m "Primera revisió del meu nou projecte..."

Un cop fet això, imaginem que acabem de fer uns canvis al fitxer main.c. Un cop comprovat que aquests funcionen correctament, procedirem a crear una segona revisió:

bzr commit -m "Aquí aniria una descripció dels últims canvis."

I ja tenim dues revisions en la nostra branca. Ara podem recuperar el llistat de canvis que hem fet amb:

bzr log

I veuriem alguna cosa com la següents

------------------------------------------------------------
revno: 2
committer: Nom Cognom <email@domini.tld>
branch nick: foo
timestamp: Tue 2011-05-17 18:19:48 +0200
message:
  Alguns altres canvis que he fet...
------------------------------------------------------------
revno: 1
committer: Nom Cognom <email@domini.tld>
branch nick: projecte1
timestamp: Tue 2011-05-17 18:19:29 +0200
message:

  Primera revisió del meu nou projecte...

Si voleu analitzar en més detall una revisió, podeu comparar dues (o més) revisions amb l'ordre:

bzr diff -r1..2

A més, quan arribeu a una versió estable del vostre programa podeu marcar la revisió actual amb una etiqueta, fent:

bzr tag nom-etiqueta

Llavors podreu utilitzar "tag:nom-etiqueta" per referir-vos a aquella versió en lloc d'haver de consultar el número de revisió (revno).

Compartint la branca amb altres

Fins ara només hem estat treballant en local (això és possible ja que el Bazaar -al contrari de l'SVN- és un sistema distribuït). Imaginem que ara voleu compartir el codi amb un company perquè pugui ajudar amb el desenvolupament. Per això us caldrà disposar d'un servidor (qualsevol ordinador accessible, en realitat) on els dos hi tingueu accés SFTP. Enviar-hi la vostra branca completa (amb totes les revisions) és tan fàcil com:

bzr push sftp://el-meu-servidor.tld/directori/destí/projecte1

(Si més enllà de l'SFTP també teniu accés via SSH, i el servidor té el bzr insta?lat, podeu utilitzar el mode de servidor inte?ligent amb «bzr+ssh://». D'altra banda, si el company/a no té accés al servidor, sempre es pot posar la branca en un lloc accessible des de la web i llavors hi tindrà accés només de lectura, via «http://»).

Per obtenir una còpia de la branca, l'altre persona pot fer:

bzr branch sftp://nom-d'usuari@el-meu-servidor.tld/directori/destí/projecte1

A partir d'aquí, els dos podeu fer «bzr push» per enviar els vostres canvis després d'un commit i «bzr pull» per recuperar canvis nous. En cas de produir-se un conflicte (el qual es produeix si es fa un commit sense tenir les últimes revisions de la branca del servidor) es pot arreglar amb «bzr merge».

A més d'aquests constants intercanvis, en qualsevol moment un dels dos pot decidir fer un push a una nova branca (per exemple, per desenvolupar alguna nova característica experimental) i quan la feina en aquesta estigui acabada, tornar-la a integrar (amb un merge) dins la branca principal (que, per cert, normalment s'anomena trunk).

No comments
© Siegfried-Angel Gevatter Pujals, 2011. | Permalink | License | Post tags: bzr, desenvolupament, vcs

I’ve also decided to only include commercial games in this post; if it gets positive feedback I may also post a list of my favourite free games.

Anyway, here it goes:

	Vendetta Online A massively multiplayer online first-person space-combat game featuring possibilities in trading, mining, combat, warfare, piracy… Price: $9.99 / month (free 8 hour trial) License: Proprietary
Lugaru HD A third-person action game featuring a rabbit on a fight to save his fellow rabbits from slavery in a fight against corrupt rabbits and wolves. Price: $9.99 License: Open-source code, proprietary data Humble Indie Bundle #1
	And Yet It Moves A platform game in a world of paper collage you can rotate at will, turning walls into floors, slides into platforms and moving stacks of rocks (or even enemies). Price: $9.99 / 8.99€ License: Proprietary
Savage 2 A fantasy first-person shooter, action role-playing game (in player role) and real-time strategy (in commander role) multiplayer game. Price: Free / $9.99 (Premium Account) License: Proprietary See also Heroes of Newerth, a fantasy strategy game inspired in DotA ($30).
	Enemy Territory: Quake Wars A futuristic, objective-driven and class-based multiplayer first person shooter featuring the fight between the Earth’s Global Defense Force and the alien Strogg. Available at shops License: Proprietary
Penumbra (Overture, Black Plague) A series of exploration-based horror games. Price: 16.20€ (demo available) License: Open-source code, proprietary data See also Amnesia: The Dark Descent.
	World of Goo A physics-based puzzle game. Truly a work of art. Price: $20 License: Proprietary Humble Indie Bundle #1
Bionic Heart A science-fiction visual novel with interactive scenes (you can choose between different actions which change the ending of the story). Price: 12.70€ + VAT (demo available) License: Proprietary
	Revenge of the Titans A tower defense game with RTS elements. Price: 10.66€ + VAT License: Open-source code (not yet available), proprietary data Humble Indie Bundle #2

There are many more GNU/Linux-compatible games out there. Check out the other Humble Indie Bundle games, for instance. You may also follow LinuxGames to keep up with the latest news.

Related posts:

1. Debian Games Team Meeting This announcement was provided by Martin Erik Werner. I’m reproducing...

After a quick search I learned that it’s much easier than this: it’s possible to reliably determine the language based on statistic n-gram information. Ignoring the fact that now I officially hate Firefox, Chromium, OpenOffice.org and everyone else there for not implementing this and having me spend the day changing the spell-checker’s language, I was left with the choice on how to use this in eSpeak GUI.

The first option I found was TextCat, which is also the only library I’ve found to be packaged for Debian. However, ignoring the fact that upstream isn’t maintaining it any more (such a library shouldn’t need too much maintainance, after all), the package declares incorrect dependencies (bug filled a month ago, no response yet) and the API is also pretty crappy (it requires a physical file indicating the location of the statistic models).

Unrelated to that, I’ve also found that the Catalan text samples it includes are incorrect, so the same may be true for other languages. I guess it’d make sense to work on a new (and completely Unicode) language samples collection. I’ve thought of using something like the Universal Declaration of Human Rights since this way all languages can have the same text, but being more of a legal thing it may be biased by some words being too repetitive.

Looking for other alternatives to the TextCat library I’ve only found the following:

• TextCat (same name, different code): PHP licensed, so incompatible with GPL projects.
• Mguesser (part of mnogosearch-mysql): it’s a standalone executable and not a library.
• SpamAssassin’s TextCat.pm: also a standalone executable, this time written in Perl. Apparently they were using a fork of TextCat (the original library, not the PHP licensed one) before that.

So it looks like I’ll have to start by getting a good collection of text samples I can use to generate the statistic data. Then I have several options on how to actually use it. As I see it, those are my possibilities:

1. Fixing libtextcat‘s packaging and just using that.
2. Taking it over as new upstream maintainer. Not my preferred option as I don’t really feel like maintaining a C library at this point.
3. Trying to convince the maintainer of the new TextCat (with last commit January this year and a more sane API) to re-license it in a GPL-compatible way, packaging that and seeing how that one works (haven’t tried it out yet).
4. Writing my own implementation in Python, maybe based upon this example or TextCat.pm.

Any other ideas, pointers to some library I may have missed or offers to collaborate are very welcome. Please also note that my intention in writing this post is not only to rant about there being no well-maintained ready-to-use library being available, but especially raising awareness on the topic of language identification. I’d love to see this feature all around the desktop, just like (and in combination with) spell-checking, which is already omnipresent.

11 comments
© Siegfried-Angel Gevatter Pujals, 2010. | Permalink | License | Post tags: language identification, Programari lliure, text categorization

For extra fun, I also decided to impose two rules: no reading up on existing algorithms or «weird maths» (I’ll have enough time for this when I study Computer Vision at university), and no «magic» (ie., implementing everything myself and not using existing functions for edge detection or whatever).

First steps

Of course, my first choice for trying this was Python, so I installed PIL and SciPy, and took a photo of the box. With just a function call, they give me access to each pixel’s RGB value, so it’s really easy to have it change all points that aren’t red into black and other funny stuff.

However, iterating through all the pixels in the image was quite slow (in the order of several seconds) so I decided to switch to C and OpenCV, which turned out to be really nice to work with. After a while I had written down the first algorithm I could think of, and it kinda worked (see video at right). I want to thank Michal for the idea of converting the image to the HSV colour space for colour checking.

Noise reduction

After I had a first success, I worked on some new multi-pass code with lots of loops to see if I can get some noise reduction. I started by turning everything which isn’t detected as red into black so that I get a better overview of what’s going on. Then I improved this to let it find non-matching pixels surrounded by red ones (on the top and the left they must be adjacent, but on the right and bottom the nearest red may be some distance away; this works even for groups of pixels since the image is processed from left to right and from top to bottom). Finally, I added some more code to remove any little group of red pixels surrounded by non-matching ones. The effect of this will be seen later.

Illumination

For some reason the detection gets mad if there is artificial light (or maybe it’s just that I haven’t found the right colour values to check for). No light at all (except for that of the computer screens) works better -after reducing the minimum levels of saturation and brightness I was checking for-, but it gives a lot of noise. My first program therefore fails miserably under such conditions.

However, now that I have the noise reduction this is no longer a problem. See by yourself: image at right. (The really bright points are those which didn’t match but have been converted to red since they are surrounded).

Second try at box detection

I could just have put my previous box detection algorithm on top of it, but I decided to make use of the fact that the noise reduction is successfully removing everything except for the box. Thus, instead of searching for red lines likes before I just localize the left-most, right-most, highest and lowest red points.

Using those four points, I calculate the centre of the box (and I could also reliably determine the position of the four corners, if I added some more code to find whether the box is horizontally aligned or not).

Finally I calculate the relative movement of the centre point and this way I can control a pointer (bottom right of the video). Here we go:

http://www.youtube.com/watch?v=y8qgiTQfuJE

(And it works as well at night! - Code is here)

6 comments
© Siegfried-Angel Gevatter Pujals, 2010. | Permalink | License | Post tags: color recognition, computer vision, image recognition, opencv

On behalf of the Zeitgeist Project team, I am pleased to announce the immediate availability of Zeitgeist 0.3.3. It introduces an improved relationship algorithm, new sorting types for queries, a data-source registry (providing the possibility of easily disabling individual loggers) and several bug fixes and other enhancements.

What is Zeitgeist?

Zeitgeist is an event-logging framework for desktop and mobile devices. Applications can push events into the log, and anyone can query the log via the rich query API. The logged events are semantically categorized and can come from any sort of activity, such as file usage, communications, browsing history, etc. The Zeitgeist engine is a user-level service and does not provide a GUI. It is intended to support dedicated journalling applications and deep integration with other desktop components.

Where?

Downloads: https://launchpad.net/zeitgeist/+download (zeitgeist-0.3.3.tar.gz)

About Zeitgeist: http://zeitgeist-project.com

Wiki: http://live.gnome.org/Zeitgeist

News since 0.3.2

Engine:

- Added MostPopularActor, LeastPopularActor, MostRecentActor and
LeastRecentActor as possible ReturnTypes for FindEvents and
FindEventsId (LP: #493903).
- Let {Find,Get,Insert}* hooks know the bus name of the caller, when
executed over D-Bus.
- Add an extension implementing a data-source registry (allowing to disable
data-sources from a centralized place and see their description).
- Overhauled FindRelatedUris for better results and improved performance.
- Changed FindEvents, FindEventIds and FindRelatedUris to not treat zeros in
the given TimeRange specially; "(0, 0)" can no longer be used (LP: #490242).
- Fixed a crash in the GtkRecentlyUsed data-source parsing malfored .desktop
files (LP: #526357), and added support for more file mimetypes (LP: #510761).
- Fixed a crash in the GtkRecentlyUsed data-source trying to read broken
symlinks disguised as .desktop files (LP: #523761).
- Fixed a crash in the GtkRecentlyUsed data-source which happened when there
was no display friendly version of a URI (LP: #531793).
- Renamed --no-passive-loggers option to --no-datahub. Output printed by
zeitgeist-datahub is no longer visible in zeitgeist-daemon's output.
- Added --log-level option to change the output verbosity.
- DeleteEvents now correctly removes any unreferenced values (URIs, actors,
etc.) and not only the events themselves (LP: #491646).
- Fixed insertion of events with a payload (LP: #557708).
- Fixed an exception in DeleteEvents.
- Fixed event deletions not always getting committed (LP: #566184).
- Ignore deletion requests for non-existant events.

Python API:
- Made the Interpretation and Manifestation classes iterable.
- Added symbol lookup by URI, in the form of dictionary access.
- Fixed the display name for Interpretation.SOURCECODE.
- Fixed find_events_for_values and find_event_ids_for_values (LP: #510804).
- Added a get_extension() method to ZeitgeistDBusInterface, to get convenient
access to D-Bus interfaces provided by engine extensions.

Overall:
- More fixes and code enhancements.
- Manpage updates.
- Translation updates.

Related posts:

1. Zeitgeist Data-Source Registry This post is about an upcoming feature in Zeitgeist 0.3.3...
2. Here is Zeitgeist 0.2.1! One month after the first Zeitgeist release (0.2), here is...
3. Zeitgeist 0.5.1 released! On behalf of the Zeitgeist Project team, I am pleased...

I like listening to music while I’m programming. However, I have lots of music on my computer and I don’t really like all of it (or find it appropriate as background music for when I’m programming).

I guess I could spend a few evenings going through my music collection, deleting anything I don’t like (which isn’t always such an easy decision), creating a playlist or whatever. This isn’t a permanent solution, though, since with the time my collection will continue growing, I may get sick of hearing some songs, my taste may change, etc. Also, I prefer spending my time programming, reading or doing anything else more interesting than sorting my music collection.

Unrelated to the problem itself, let me also mention that I use different media players. Currently I’m mostly using Banshee, but I’ve been intermittently toggling between it and Rhythmbox those last months, and also used a command-line player for some time. I’m saying this because I expect a optimal solution to be media player-independent. The bigger problem of each media player having its own database is also something I’d like to see addressed, maybe with some technology like Tracker, but that is another topic.

The status quo

My current way to approach this problem is basically setting my media player to choose songs randomly, and using the big “Next >>|” button on my keyboard whenever it chooses some song which annoys me.

(Banshee’s playback list interface has an option to automatically fill itself sorting songs by popularity, but it doesn’t seem to work good at all here; I also recall Amarok having some automatic playlist generation options, but I’m not using any KDE applications anymore and in any case this is outside the scope of an application-neutral solution).

The solution

It has recently occurred to me that a neat solution for this would be to gather information from a generic event log and to translate that into a numerical punctuation for each song. I think you may already guess where I’m heading, but if not: Zeitgeist!

With the appropriate data-sources installed, Zeitgeist holds information on which songs started playing automatically (because they are on a playlist or because you have your media player set to random), which were started manually, and in both cases which you listened to completely and which ones you skipped (and how long you resisted listening to them). It shouldn’t be too difficult to write a script which will periodically request this information from Zeitgeist and give songs positive points for every time you listened to them completely (extra if you chose them yourself manually) and negative points to the ones you skipped (but giving less negative points if you resisted half of the song than if you skipped it right after you recognized it).

With this punctuation information, music players can avoid playing songs you don’t like and give you only those you like or new ones for which there isn’t any information yet (if it followed the punctuation strictly this would end with the same songs being played all the time and new songs with punctuation around 0 being ignored). The importance of the play/skip actions would decay over time (it’s more important to consider whether you listened to the song yesterday than if you did six months ago), etc., etc.

If we wanted to create something really fancy we could even look at generating different ratings for separate circumstances, eg. in case you like listening to a different sort of music during the morning than during the evening, or to differentiate between what you like to hear while you are coding and while the computer is idle (maybe because you are doing paper homework and only using the computer to get some background music). The information for all this is there in Zeitgeist, so it’s only a matter of writing a good algorithm.

The implementation

I’ve already explained most of how this should work in the previous section, but here’s a bit of an overview of what’s needed for this:

• Data-sources inserting the music reproduction information. We already have a data-source for Rhythmbox implemented as an extension, but Banshee and any other players are missing.
• The actual algorithm, probably implemented as a periodically run script leaving the aggregated information at some accessible place, although this may vary depending on the degree of fanciness you choose.
• The interface, ie. plugins for Rhythmbox and other media players which take that information and use it to provide an option for semi-randomly choosing music excluding stuff you don’t like.

If I’ve got you interested on this, I’m willing to mentor someone on this, so get in touch! Feel free to jump into #zeitgeist on irc.freenode.net or drop me a mail.

19 comments
© Siegfried-Angel Gevatter Pujals, 2010. | Permalink | License | Post tags: music, zeitgeist

Last Thursday there was a talk on Acire and a snippet creation party (as part of the Ubuntu Opportunistic Developer Week) and someone mentioned it would be nice to have a web interface. So, yesterday I took a couple hours and hacked together a quick script to convert the snippets to HTML, resulting in this snippets directory which you can use to look up stuff when you haven’t Acire at hand or to give links to snippets to other people!

The new web interface to python-snippets!

And now that you’ve read this post, maybe you would like to delve into Clutter, update your application to work with Application Indicator, see how easy it is to get data from Zeitgeist or refresh the knowledge on lists you gained at Rick Spencer’s Python talk?

The code for the snippets generator is available here. Thanks go to Mako Templates, Pygments and Chardet for having made it dead easy to create this page! And, of course, patches are welcome.

Related posts:

1. Sudoku solving with Python and SAT At Logic class last week we saw how to solve...
2. Introducing espeak-gui I’m joining the hype of presenting little new projects there...

Some weeks ago I implemented a new feature in Zeitgeist and I figured I’d drop some lines about it. I’m talking about a data-source registry.

You may be wondering, «what the hell is that even, a data-source?». So Zeitgeist is a database, a global event log, but it doesn’t do any magic indexing or monitoring by itself;  the information it logs needs to come from somewhere – be it applications sending it to Zeitgeist themselves, daemons, plugins for applications, etc. Any such entity is called a «data-source».

Having a register of all data-sources interacting with Zeitgeist provides some benefits, like for example:

Prototype of a data-source management user-interface

• Having a list of them. Lists are nice :).
• Being able to disable data-sources from a centralized place instead of requiring each to write its own preferences dialogue.
• Being able to set up a blacklist rule considering which data-source the information comes from as a condition (not implemented yet).

More details

When they register, data-sources will need to provide the following information: an unique ID, a name (may be localized), a description (may be localized) and optionally a template specifying what sort of events it logs. Additionally, the last timestamp the data-source was seen by Zeitgeist, whether it is running right now and whether it is enabled will also be available.

It is important to note that registration is not compulsory; while it is highly encouraged for data-sources to use it, is it still possible to anonymously insert information into Zeitgeist (for example from a shell script). The event template is also only informational, and will not be enforced by Zeitgeist at this time.

Avoiding duplicates from GTK Recently Used

You may know that zeitgeist-datahub provides basic support for applications which have no direct Zeitgeist support but do use GTK’s RecentManager, which is not as detailed as we would like, but it is better than nothing. However, until now we had a problem: when applications had support for both, GTK’s Recently Used and Zeitgeist (be it native or as an extension), it was possible for duplicate events to be inserted or other sorts of conflicts between both data-sources. Now that we have the information from the registry available, we’ve been able to solve this modifying our Recently Used data-source to ignore any events concerning applications which already have another data-source logging the same types of events.
 

Related posts:

1. Zeitgeist 0.3.3 is out! From the release announcement: On behalf of the Zeitgeist Project...
2. Zeitgeist is out! World, the first Zeitgeist release is out! From the release...
3. Introduction to Zeitgeist 0.2′s API So now that Zeitgeist 0.2.0 is out I’ve thought I’d...

I think the time has come that I make a confession. You may be wondering why I haven’t spent much time with you those last months, and you have the right to know. The case is, I have another one. She’s called Debian.

No, it’s not because of you. It’s also not because of your parents; while they aren’t perfect, they are great in many ways and I certainly don’t want to run away from then. Just wait and let me explain this. You surely remember that I spent a week with her some time ago? Well, now that I want to join Debian’s family, I decided that after all that wasn’t much time to get to know here, so I gave her another chance, and with this second experience I fell in love with her unstable character. Ubuntu, you are really extraordinary, and I’m still telling anyone who wants to listen about your wonders, but you just can’t appease my desire for trying out new things as well as Debian does.

Now, this doesn’t mean we won’t see each other anymore. I’ll still take you with me whenever I travel, and I’ll continue helping you with the household. In fact, all this wouldn’t signify a big change at all, if it wasn’t that at the same time I also decided to refocus most of my efforts on raising children, which is what really reduced the time I spent helping you.

So, while currently I’m not seeing you as much as before, I hope you all the best, and I’ll still try to help you advance, be it indirectly (1, 2) or, while probably to a lesser degree, continuing with direct contributions.

By the way, hello Planet Debian!

8 comments
© Siegfried-Angel Gevatter Pujals, 2010. | Permalink | License | Post tags: Debian, Programari lliure, Ubuntu

By the way, if you're coming too and are interested in Zeitgeist, don't forget to poke me (or Seif)!

Related posts:

1. Zeitgeist is out! World, the first Zeitgeist release is out! From the release...
2. Zeitgeist since UDS Quite some stuff has been going on in Zeitgeist since...
3. Introduction to Zeitgeist 0.2′s API So now that Zeitgeist 0.2.0 is out I’ve thought I’d...

While several sources have already propagated the good news, what doesn’t seem to be so widely known is how easy it is to get the Activity Journal running on Ubuntu. Because it is!

Installation on Ubuntu Karmic or Lucid

sudo add-apt-repository ppa:zeitgeist/ppa
sudo aptitude update
sudo aptitude install gnome-activity-journal

Now go to Applications -> Utility -> Activity Journal and enjoy the sweetness!

Installation on other systems

Our Personal Package Archive also has packages for Ubuntu Jaunty which you can add the usual way (by adding it to System -> Administration -> Software Sources or editing your sources.list), and the same packages as for Ubuntu work for Debian Sid (to which Zeitgeist 0.3.2 and the GNOME Activity Journal will be uploaded shortly).

There may be packages for other distributions available; if you can’t find any for yours, you can do the installation by hand:

[For Zeitgeist] – Build dependencies: intltool

$ wget http://launchpad.net/zeitgeist/0.3/0.3.2/+download/zeitgeist-0.3.2.tar.gz
$ tar -xzvf zeitgeist-0.3.2.tar.gz
$ cd zeitgeist-0.3.2
$ ./configure
$ make
# make install

[For the GNOME Activity Journal] – Build dependencies: Python (2.5+), Python-DistUtils-Extra, intltool

$ wget http://launchpad.net/gnome-activity-journal/0.3/0.3.2/+download/gnome-activity-journal-0.3.2.tar.gz
$ tar -xzvf gnome-activity-journal-0.3.2.tar.gz
$ cd gnome-activity-journal-0.3.2
$ python setup.py build
# python setup.py install

But, what is the GNOME Activity Journal?

The GNOME Activity Journal is a tool for easily browsing and finding files, contacts and other resources on your computer. Using Zeitgeist, it keeps a chronological journal of your activity and supports tagging and bookmarking (using the new Tracker 0.7) and establishing relationships between resources.

While this first release only supports basic browsing of file activities, the underlying infrastructure can do much more and you can expect the missing functionality to become available in future releases.

Related posts:

1. Activity Log Manager for Zeitgeist released! On behalf of the Activity Log Manager team and the...
2. Another GNOME Shell post: what do you think about the window list? It’s already a few months since my two posts on...
3. GNOME Do – 0.8 Alpha and Docky A friend told me not much ago about a new...

The main changes are fixing a crash bug and… internationalization support. So, if you like this project but you’re not a coder, now you’ve got a way to contribute: translating it into your language (come on, it only has a few strings! :)).

The new version is already in my PPA: espeak-gui_0.2-0ubuntu1~ppa1_all.deb. A tarball is also available, and the installation instructions are the following:

$ wget -c http://launchpad.net/espeak-gui/trunk/0.2/+download/espeak-gui-0.2.tar.gz
$ tar -xzvf espeak-gui-0.2.tar.gz; cd espeak-gui-0.2
$ python setup.py build
$ sudo python setup.py install

In case you didn’t already have the previous version, you’ll also need to install the python-espeak module, for which there are also .deb’s (i386, amd64) or the manual installation option like explained in my previous post:

$ bzr get lp:python-espeak
$ cd python-espeak
$ python setup.py build
$ sudo python setup.py install

Here are the contents of the NEWS file:

2010-01-02: Version 0.2
-----------------------

 - Fixed a crash happening when there was no voice language set in
   gconf (LP: 502253). [Reported by Rugby471]
 - Added a "Plain text" filter to the Open/Save dialogues.
 - Added internationalization support.
 - Added a manpage and a gconf schemas file.
 - A couple little user interface improvements.

Translations: Catalan.

Related posts:

1. Introducing espeak-gui I’m joining the hype of presenting little new projects there...
2. GNOME Activity Journal, and installing it on Ubuntu As already announced by Seif, the first development release of...
3. Introduction to Zeitgeist 0.2′s API So now that Zeitgeist 0.2.0 is out I’ve thought I’d...

Why, when, who?

The project started almost a year ago when, out of curiosity on what writing Python bindings for C/C++ libraries is like, I started python-espeak, bindings for the espeak speech synthesizer (which, by the way, comes installed by default on Ubuntu and many other distributions).

It turned out that writing bindings isn’t as funny as I thought so they haven’t advanced much since then, but the basic functionality was there and I felt the need for some application using those bindings, so that’s how I started espeak-gui.

Some months later, in true Free Software spirit, someone else -interested in an application like this for personal usage- found my code on Launchpad and got in touch with me, providing me with quite some nice patches. Thank you, Joe Burmeister! However, I didn’t do any more work on it, as I’ve been busy with other projects (eg. Zeitgeist), and development stalled there.

Now, another half a year later, I’ve finally got back to this and decided it’s time I push it out into the wild. So, after cleaning it up a bit more and implementing some new feature, here you have espeak-gui!

(The bindings aren’t really encouraged for widespread usage at this point and I’ll probably end up rewriting them using SWIG or something else; however, if you’re interested in using them please get in touch with me).

Where do I get it?

If you’re using Ubuntu or Debian, you can find a packages for python-espeak and espeak-gui in my PPA.

For users of other distributions, you can install them manually after installing the needed dependencies (most importantly, libespeak-dev).

For the Python bindings for espeak:

$ bzr get lp:python-espeak
$ cd python-espeak
$ python setup.py build
# python setup.py install

And for the GUI:

$ wget -c http://launchpad.net/espeak-gui/trunk/0.1/+download/espeak-gui-0.1.tar.gz
$ tar -xzvf espeak-gui-0.1.tar.gz
$ cd espeak-gui-0.1
# python setup.py install

[Update: A new version is out, see espeak-gui 0.2 for details.]

I have several ideas on how to continue improving it and I think I’ll slowly continue doing so (or maybe not so slowly if I get positive feedback on this :)). Also, patches are always welcome!

Using it

Once installed, you’ll find espeak-gui under Applications -> Sound and Video (maybe Accessibility would be a better place?), or you can run it from the command line like this:

espeak [ <file 1> <file 2> ... ]

Related posts:

1. espeak-gui 0.2 Yesterday I did a first release of espeak-gui, so while...
2. Introduction to Zeitgeist 0.2′s API So now that Zeitgeist 0.2.0 is out I’ve thought I’d...

But it’s not to advertise this game that I’m writing about it, but because I want to write down some solution to the “no sound problem” which you’re likely to find if you try it out, and so that I can remember about the fixes in the future. So, here’s the different things you can try; if one of them fails just go to the next one, and let’s hope that at least the last one does the trick!

1. Install the “oss-compat” package.
As easy as that! Although this alone has never fixed the problem with me, it often does together with solution 2 (described just below), and maybe in your case it may be all you’re missing.

2. A bit of command-line magic
The next one, which seems to be the most successful option, is trying to execute the following line before running Enemy Territory:

echo "et.x86 0 0 direct" | sudo tee /proc/asound/card0/pcm0p/oss

If after doing this the sound works, you can make the change permanent by adding that line to your /etc/rc.local/, for example by running:

sudo sed -i "s:^exit 0:echo 'et.x86 0 0 direct' > /proc/asound/card0/pcm0p/oss\nexit 0:" /etc/rc.local

3. Let’s call the artillery

Hopefully you’ll be enjoying an Enemy Territory game with the sound of explosions and shots in your ears, but if the previous solutions didn’t do the trick do not despair, there’s still hope. I’ve found a different solution in this thread and it consists in the following:

a) Download this script: wolfsp-sdl-sound.sh (original download link, alternative download link), created by Pyry Haulos.

b) Open it with a text editor and customize it to match your configuration: change the line «GAME_PATH=”/home/games/enemy-territory”» to point to the location of your Enemy Territory installation (most likely «GAME_PATH=”/usr/local/games/enemy-territor”»); in case your directory with the game files isn’t called «enemy-territory» like in the example you’ll also need to adapt the GAME_DIR variable.

c) Save this file somewhere on your computer, make it executable if needed (you can do this by right clicking on it, selecting “Properties” and under the “Permissions” tab of the dialogue that will show up checking the box to allow execution of the file). Done, now whenever you want to run the game just start it by running this file.

I hope this is useful for someone out there :).

Related posts:

1. No sound on HP Pavilion dv6-1110ss I’ve recently installed Ubuntu Jaunty on an HP Pavilion dv6-1110ss...

No comments
© Siegfried-Angel Gevatter Pujals, 2009. | Permalink | License | Post tags: Programari lliure, Xorrades

From the engine side we are implementing a new database and API which does a clean cut between what is event logging and what is repository functionality. What this means for Zeitgeist is that we won’t do annotations anymore and that the basic information Zeitgeist has about items will be about those at the time of the event – for anything else there is Tracker (I tried out the new version from git yesterday and it really rocks, it’s nothing like 0.6).

We are also implementing focus tracking and the algorithms for the fancy stuff (contextual relevancy over time, focus time of documents/applications, etc).

Blackboards saved us a lot of time. In the image: Seif Lotfy, Ivan Frade (Tracker) and Markus Korn.

The User Interface team also has some quite nice design ideas. For the non-developers out there, there’ll be something (alpha-quality!) to try out soon.

Related posts:

1. Zeitgeist Hackfest Just a quick note to mention that tomorrow I’m leaving...
2. Zeitgeist Data-Source Registry This post is about an upcoming feature in Zeitgeist 0.3.3...
3. Introduction to Zeitgeist 0.2′s API So now that Zeitgeist 0.2.0 is out I’ve thought I’d...

Just a quick note to mention that tomorrow I’m leaving for Bolzano for a week, for the Zeitgeist Hackfest. I’m really looking forward to meeting all the team there!

My initial idea for this post was to write about some of the upcoming changes in the engine, as we’ve been discussing quite some improvements lately, but I’ll better leave that for after the hackfest as we’ll have a chance to go over all them again and clarify any missing chunks :). For now I’ll just say that the API will probably change quite a lot, and while I’m at it leave you with a link to a recent Status Report sent to GNOME (there’s also one for GNOME Shell, in case you care).

Related posts:

1. Zeitgeist Hackfest (II) So here we are at the Zeitgeist Hackfest and there’s...
2. Zeitgeist since UDS Quite some stuff has been going on in Zeitgeist since...
3. Zeitgeist is out! World, the first Zeitgeist release is out! From the release...

1. Comprovació de l’estat

Ara no perquè ja he arreglat el paquet, però si miravem a https://launchpad.net/ubuntu/+source/necpp veiem que la última versió del paquet era l’afectada, i que no hi havia informes d’error relacionats amb el problema (recordem que, si n’hi hagués, podríem trobar-hi pistes o bé veure que algú altre ja està treballant en arreglar aquest paquet). Comprovant els informes d’error a Debian (http://bugs.debian.org/necpp) tampoc trobem res, i a http://packages.debian.org/necpp comprovem que tampoc hi ha cap versió més nova que la de l’Ubuntu on ho hagin arreglat. Així doncs, tirem endavant, i obrim un informe d’error al Launchpad per indicar que hi estem treballant (exemple).

2. Obtenció del paquet font
Baixem el paquet font:

apt-get source necpp

Si ho proveu ara, obtindreu la nova versió del paquet que ja he arreglat, però podeu baixar-vos l’anterior a fi de seguir el tutorial fent això en lloc de l’apt-get source:

dget https://launchpad.net/ubuntu/+archive/primary/+files/necpp_1.3.0+cvs20090101-1ubuntu1.dsc
dpkg-source -x necpp_1.3.0+cvs20090101-1ubuntu1.dsc

Ara, comprovem que efectivament podem reproduir el problema, intentant compilar-lo:

pbuilder-karmic build necpp_1.3.0+cvs20090101-1ubuntu1.dsc

El missatge d’error que rebem és el següent:

[...]
XGetopt.cpp: In function 'int XGetopt(int, char**, const char*)':
XGetopt.cpp:170: error: invalid conversion from 'const char*' to 'char*'
make[3]: *** [XGetopt.o] Error 1
[...]

3. Solució del problema
Arribem així a la part més difícil, ja que aquesta no és sistemàtica.

El missatge d’error ens parla d’un fitxer XGetopt.cpp, el qual podem trobar al directori str/. Si mirem a la línia que menciona, la 170, ens trobem el següent:

cp = strchr(optstring, c);

Si cerquem informació sobre la funció strchr del C++, trobem que està sobrecarregada i té dues versions:

const char * strchr (const char * str, int character);
char * strchr (char * str, int character);

Veiem que si el primer paràmetre de la funció és constant, el resultat de la funció és una constant, i sí el paràmetre no és constant, el resultat tampoc ho és. Si mirem de quin tipus és la variable optstring, a la línia 133 trobem que és constant, de manera que el resultat de la funció també ho és. Si ara mirem com és la variable cp, a la qual s’està assignant la sortida de la funció, a la línia 136 veiem:

char *cp;

És a dir, no és constant, de manera que aquí tenim el problema. Si mirem la resta del codi on existeix aquesta variable, no trobem cap lloc on es modifiqui el valor de la cadena de text a la qual apunta, així que podem convertir la variable en constant sense problema. Per fer-ho, simplement cal canviar la línia afegint-hi «const» al davant, i com que si executem l’ordre

what-patch

ens diu que el paquet no utilitza cap sistema de pegats («patchless?») podem fer el canvi modificant el fitxer directament.

Per acabar, afegim una entrada nova al fitxer debian/changelog, declarant una revisió nova del paquet i explicant els canvis que hem fet. Executem l’ordre següent:

dch -i

I ha de quedar una cosa com ara:

necpp (1.3.0+cvs20090101-1ubuntu2) karmic; urgency=low

  * src/XGetopt.cpp (LP: #447454)
     - Change the definition of the "cp" variable from type "char*" to
       "const char*", to avoid an "invalid conversion" error when the
       result of "strchr(const char*, ...)" is assigned to it.

 -- Siegfried-Angel Gevatter Pujals   Sat, 24 Oct 2009 19:58:55 +0200

És important no oblidar-nos de referenciar el número de l’informe d’error que hem obert, i explicar clarament el motiu de tots els canvis.

4. Regenerant el paquet font

debuild -S

Això ens crearà un paquet font per a la nova revisió, que podem compilar tal com hem fet abans (però utilitzant el fitxer .dsc de la nova revisió, no el d’abans):

pbuilder-karmic build necpp_1.3.0+cvs20090101-1ubuntu2.dsc

Aquest cop funcionarà, així que ara només queda generar un fitxer de diferències i comprovar que només hi ha els canvis que hem fet intencionadament.

debdiff necpp_1.3.0+cvs20090101-1ubuntu1.dsc necpp_1.3.0+cvs20090101-1ubuntu2.dsc > necpp_1.3.0+cvs20090101-1ubuntu2.debdiff

En aquest cas, el contingut del fitxer ha de ser el següent:

diff -u necpp-1.3.0+cvs20090101/debian/changelog necpp-1.3.0+cvs20090101/debian/changelog
--- necpp-1.3.0+cvs20090101/debian/changelog
+++ necpp-1.3.0+cvs20090101/debian/changelog
@@ -1,3 +1,12 @@
+necpp (1.3.0+cvs20090101-1ubuntu2) karmic; urgency=low
+
+  * src/XGetopt.cpp (LP: #447454)
+     - Change the definition of the "cp" variable from type "char*" to
+       "const char*", to avoid an "invalid conversion" error when the
+       result of "strchr(const char*, ...)" is assigned to it.
+
+ -- Siegfried-Angel Gevatter Pujals   Sat, 24 Oct 2009 19:58:55 +0200
+
 necpp (1.3.0+cvs20090101-1ubuntu1) karmic; urgency=low

   * Merge from debian unstable, remaining changes from jaunty:
only in patch2:
unchanged:
--- necpp-1.3.0+cvs20090101.orig/src/XGetopt.cpp
+++ necpp-1.3.0+cvs20090101/src/XGetopt.cpp
@@ -133,7 +133,7 @@
 int XGetopt(int argc, char *argv[], const char *optstring)
 {
 	char c;
-	char *cp;
+	const char *cp;
 	static char *next = NULL;
 	if (optind == 0)
 		next = NULL;

5. Enviant els canvis a l’Ubuntu

Ara que tenim el fitxer de diferències, l’adjuntem a l’informe d’error que hem creat al principi, i subscrivim l’equip de revisors adequat a l’informe. En aquest cas, el paquet està al dipòsit universe, com podem comprovar:

$ apt-cache madison necpp
     necpp | 1.3.0+cvs20090101-1ubuntu1 | http://mirror.pacific.net.au karmic/universe Sources

Així doncs, l’equip és l’ubuntu-universe-sponsors. Ara només queda esperar que algú revisi el paquet i el pugi a l’Ubuntu, però com que som bons ciutadans també reportarem l’error a Debian tot donant-los-en la solució.

Related posts:

1. Com contribuir a l’Ubuntu – Arreglar paquets que no compilen correctament El passat cap de setmana va tenir lloc l’Ubuntu Global...

Prefaci

Inauguro la sèrie amb aquest primer apunt, on tot seguit explicaré conceptes generals en quant als “paquets que no compilen” i que fer amb ells; en successius apunts, i per tal de deixar-ho tot ben clar, explicaré els passos necessaris per a arreglar diferents paquets concrets. Depenent de la resposta que rebin aquests escrits, pot ser que més endavant enceti una sèrie nova que tracti algun altre tema relacionat amb els paquets, a partir dels coneixements adquirits amb aquesta.

Introducció

Si esteu llegint això ja deveu saber que en l’Ubuntu els programes venen preparats en forma de paquets; gestors de paquets (com ara l’Afegeix/Elimina, el Synaptic o l’Apt) us proporcionen una llista de tots els paquets disponibles i simplement esperen les vostres indicacions per tal de descarregar, insta?lar i mantenir actualitzats els paquets que us interessin. Ara bé, per increïble que pugui semblar, aquests paquets no apareixen del no-res, sinó que hi ha una munió de gent dedicant temps a crear-los i actualitzar-los.

Quan hom crea un paquet el que fa és agafar el codi font del programa (amb petites modificacions, si convé, com ara arreglar-ne algun error) i afegir-hi la informació necessària per a crear un programa. Un cop això està fet, el paquet font (source package) resultant és enviat al Launchpad (servidor d’Ubuntu), on és compilat per a les diferents arquitectures, tot creant els paquets binaris (.deb) que tots coneixem. Pot ocórrer que un paquet font no compili correctament (i no es creïn els paquets .deb) per a una o més arquitectures; en aquest cas, cal trobar quin és el problema i enviar una nova revisió del paquet al Launchpad. Del fet que un paquet no compili correctament se’n diu FTBFS («Fails to Build From Source»).

Normalment, poc abans que surti una nova versió de l’Ubuntu, s’intenta tornar a compilar tots els paques dels dipòsits oficials per tal de comprovar que encara compilin correctament. Aquesta operació acaba donant un llarg llistat de paquets que fallen i que convé arreglar. Els motius que els paquets no compilin correctament són diversos, i poden ser coses com ara: l’ús d’una nova versió més estricta d’un compilador (com passa sovint amb el gcc), canvis en les dependències de construcció del paquet (és a dir, en els paquets de que cal disposar per crear-lo, «build dependencies»; pot ser un canvi en el contingut d’algun d’aquests paquets el que provoqui el problema, que hagi canviat el nom d’algun d’ells i ara no el trobi…), etc.

La llista de paquets que no compilen correctament a la Karmic es troba aquí: Build status for Ubuntu Karmic. Passem a veure, en termes generals, que fer amb aquests paquets.

0. Preparació abans de tractar amb paquets (això només cal fer-ho el primer cop)

Abans de posar-nos mans a la obra ens cal preparar el nostre sistema, instal·lant-hi unes quantes eines.

sudo aptitude install ubuntu-dev-tools devscripts debhelper cdbs patchutils pbuilder build-essential

Fem saber el nostre nom a aquestes eines, obrint el fitxer .bashrc i afegint les dues línies següents al final (tot substituint les dades per les nostres pròpies, és clar!):

export DEBEMAIL=usuari@proveidor.com
export DEBFULLNAME="Nom Cognom"

[En cas que disposem d'una clau PGP, convé escriure el mateix nom i l'adreça de correu electrònica tal com els tenim a la clau, tot posant el comentari -si n'hi ha- entre parèntesis i a continuació del nom.]
També crearem un entorn Ubuntu mínim on podem provar de compilar els paquets sense que afectin (ni siguin afectats) pel nostre sistema. [Si no estem utilitzant la Karmic, cal insta?lar el paquet debootstrap del dipòsit -backports corresponent a la versió que utilitzem. També és recomanable agafar la última versió de l'ubuntu-dev-tools.]

sudo ln -s /usr/bin/pbuilder-dist /usr/local/bin/pbuilder-karmic
sudo chmod +x /usr/local/bin/pbuilder-karmic
pbuilder-karmic create

Haurem d’esperar una estona fins que tot el sistema base sigui insta?lat i actualitzat. Per acabar, ens hem d’assegurar que tinguem una línia deb-src per a la Karmic (encara que estiguem utilitzant la Jaunty o l’Intrepid, al ser de codi font això no té importància) al fitxer /etc/apt/sources.list i la llista de paquets actualitzada (sudo aptitude update).

1. Comprovació de l’estat de l’error: ja hi està treballant algú?

Un cop hem triat quin paquet volem arreglar, anem a https://launchpad.net/ubuntu/+source/nom_paquet, comprovem que la última versió indicada sigui la mateixa que a la llista de FTBFS, i comprovem els informes d’error per si ja n’hi ha algun sobre el problema en qüestió. Si és així, comprovem que no estigui assignat a ningú (si ho està, deixem el paquet per ell i ens en busquem algun altre, per no duplicar la feina), mirem si l’informe conté alguna informació rellevant, i ens l’assignem a nosaltres, canviant a  més l’estat a In Progress. Si no hi ha cap informe d’error sobre el FTBFS, en creem un i igualment ens l’assignem a nosaltres i el marquem com a en progrés.

Fet això, comprovem també http://packages.qa.debian.org/nom_paquet, on ens assegurem que a Debian no hi hagi ja una versió nova del paquet que solucioni l’error ni un informe d’error amb informació que ens pugui ser útil. Si fos el cas que a Debian el paquet ja ha estat arreglat, depenent de la situació en tindríem prou amb demanar que sigui sincronitzat a l’Ubuntu (veure sync requests) o bé, si el paquet d’allà té altres canvis que en aquest moment no volem (per exemple una versió amb funcionalitats noves, ja entrada en vigor la Feature Freeze), podem agafar la solució de Debian de forma isolada per aplicar-la al nostre paquet.

2. Obtenció del paquet font

Ara que hem comprovat que el problema encara no ha estat solucionat, potser hem trobat alguna informació útil, i que hem indicat que estem treballant en arreglar-lo, procedim a baixar el paquet font:

apt-get source nom_paquet

Això baixarà tres fitxers al nostre directori actual: nom_paquet_versió.orig.tar.gz, nom_paquet-versió-revisió.diff.gz i nom_paquet-versió-revisió.dsc. El primer és el codi font agafat de l’autor original (<em>upstream</em>), sense modificacions; el segon fitxer és un fitxer de diferències que conté la informació necessària per crear al paquet (que serà posada en un directori anomenat «debian» dins del codi font) i en alguns casos també canvis al codi original, i l’últim fitxer simplement serveix per verificar que els altres dos són correctes (que no ha estat modificats o corromputs pel camí). Automàticament, també descomprimirà el contingut del .tar.gz i li aplicarà els canvis del .diff.gz, de manera que trobarem un directori nom_paquet-versió on treballar.

[En el paràgraf anterior, «nom_paquet» es refereix al nom del paquet font, «versió» al número de versió que li ha posat l'autor original, i «revisió» al número de revisió del paquet, que pren la forma XubuntuY, on X és la revisió de Debian i Y la revisió d'Ubuntu -si el paquet ve directament de Debian, simplement serà X-].

Arribats a aquest punt, podem verificar que realment el paquet no compila correctament, tot intentant-ho amb:

pbuilder-karmic build nom_paquet-versió-revisió.dsc

Per a continuar, ens situarem dins del directori descomprimit:

cd nom_paquet-versió

3. Solució del problema

Ara que tenim el paquet de codi font, hem de trobar la solució al problema. Per a això ens és útil llegir el registre de l’intent de creació del paquet fallit, cercar informació als informes d’error d’Ubuntu i Debian (com ja s’ha mencionat abans) i del lloc web de l’autor original, llegir el registre de canvis del paquet (el fitxer debian/changelog dins del directori de codi font) per si hi ha referències útils, etc. Aquest constitueix el pas crític i més important, ja que si no sabem com solucionar l’error poc podrem fer.

[En cas que trobem un canvi al debian/changelog que sembli rellevant al problema actual, però no l'acabem d'entendre, preguntarem a la persona que l'hagi fet, ja sigui enviant-li un missatge de correu electrònic o cercant-lo a l'IRC (canal #ubuntu-motu o #ubuntu-devel a irc.freenode.org.]

Un cop haguem trobat com solucionar el problema, apliquem els canvis necessaris. Aquests acostumen a consistir en una modificació al fitxer debian/rules (per corregir les instruccions de creació del paquet), debian/control (per corregir les dependències de construcció) o als fitxers de codi font; les modificacions a aquests darrers cal fer-les utilitzant un sistema de pegats, en cas que el paquet ja disposi d’un (podem veure-ho amb l’ordre what-patch), o bé modificant els fitxers directament en cas contrari.

Fet això, haurem d’afegir a la informació del paquet una nova revisió. Per a això executarem «dch -i» i, a l’espai on descriure els canvis, explicarem detalladament què hem fet i perquè. També hi inclourem una referència a l’informe d’error que hem obert (o trobat) anteriorment, de la forma «(LP: #número)». Usualment el format utilitzat és d’aquest tipus:

  * debian/control: Add foo as a build dependency, because the build system invokes command bar provided by the former; this fixes a FTBFS (LP: #123456).

Com veieu, es comença posant el nom del fitxer (o els fitxers) modificat, dos punts, i a continuació s’expliquen detalladament els canvis; cada canvi es posa en una línia separada (començant per « *»).

4. Regenerant el paquet font

Hem arreglat el problema i hem documentat tot en una entrada nova al fitxer debian/changelog. Ara podem procedir a crear un paquet font per a la nova revisió; això ho farem amb l’ordre següent

debuild -S

[És estrany, però pot ser que algun paquet requereixi la insta?lació de part de les dependències de construcció per tal de crear el paquet font. Quan aquest sigui el cas, n'hi ha prou amb insta?lar les dependències mancants i repetir l'ordre.]

Si tot va bé, ara podem tornar al directori pare del codi font (<em>cd ..</em>) i ens trobarem amb dos fitxers nous: un <em>.diff.gz</em> i un <.dsc> per a la nova revisió (l’<em>.orig.tar.gz</em> no ens cal, ja que la versió de l’autor original és la mateixa que abans).

Ara podem tornar a provar de construir el paquet, i si hem fet bé la nostra feina aquest cop funcionarà (i deixarà un o més paquets binaris a ~/pbuilder/karmic_result/):

pbuilder-karmic build nom_paquet-versió-revisió_nova.dsc

Si ha funcionat, felicitats! Per acabar, crearem un fitxer de diferències amb els canvis entre la revisió actual de l’Ubuntu i la nova que hem preparat, tot fent:

debdiff nom_paquet-versió-revisió_original.dsc nom_paquet-versió-revisió_nova.dsc > nom_paquet-versió-revisió_nova.debdiff

El fitxer .debdiff l’obrirem amb un editor de text per comprovar que no s’hi hagi colat cap canvi que no haguem fet. [Si hi ha alguna cosa que no volem, haurem de desfer el canvi al directori del codi font i tornar a regenerar el paquet font, no s'hi val editar el fitxer .debdiff a mà ja que això segurament l'espatllarà.]

Enviant els canvis a l’Ubuntu

Un cop estiguem satisfets amb la nostra solució i haguem provat que funciona, adjuntarem el fitxer .debdiff a l’informe d’error que hem trobat o creat al Launchpad i només ens faltarà que un desenvolupador d’Ubuntu el comprovi i el pugi a l’Ubuntu. Per a això haurem de mirar en quin dipòsit està el paquet, fent:

apt-cache madison nom_paquet

Si la penúltima paraula és «universe» o «multiverse», subscriure’m l’equip «ubuntu-universe-sponsors» a l’informe d’error utilitzant l’opció que trobarem al Launchpad a la dreta; si, en cavi, és «main» o «restricted», subscriure’m l’equip «ubuntu-main-sponsors». Ara, tot és qüestió d’esperar que algú revisi els nostres canvis i els apliqui o bé proposi possibles millores.

Quan els nostres canvis hagin estat acceptats, també els enviarem a Debian, en cas que allà també hi siguin rellevants. Per això simplement enviarem un mail a número_de_l’informe_d’error@bugs.debian.org si ja existeix un informe d’error, o n’obrirem un de nou si no n’hi ha.

Conclusió

Si heu llegit tot això, us felicito, ja que realment heu mostrar voluntat. Com he promès al prefaci, els propers dies escriure uns quants apunts més explicant (de forma més breu) com arreglar alguns paquets particulars, tot veient solucions a diferents problemes.

Related posts:

1. Arreglant paquets que no compilen: necpp Una mica més tard del que tenia previst, però continuo...

When it comes to non-instantly many-to-many communication, there are to big systems currently in use: forums and mailing lists. What annoys me that much about those is that both systems are actually exactly the same, except for the frontend they use.

Mailing lists send the messages to all users by mail, and allow them to answer again by mail. Additionally, they have a website (archive) where all messages can be checked, but this website is usually pretty awful and doesn’t allow answering to the messages.

Comparably, forums show all messages -and allow to answer to them- in a website which is excellent for this purpose, but the mail subscription option isn’t useful at all (often requiring that you open the website to see the content) and doesn’t allow to answer to the messages directly.

But, let’s look again at what their key function actually is. Delivering messages. It’s just, one simple purpose that both systems share. So my point is, why isn’t there a single solution adjusting to both (mail and web) workflows. Why are there only two exclusive options, which only provide one good interface and a broken attempt at the other one?

I want a system where I can visit a website and see all messages (also being able to answer to them), and then after five months decide that I don’t want to visit the website any more and subscribe to it by mail, still getting to read and answer the discussions in the same way but now from my mail client? (And while we are at it, having an option to link several email addresses to the same account, so that I can answer using any of those – like with Launchpad’s mailing lists).

In all the years I’ve been using the Internet, I haven’t seen a single solution like the one I’m describing. Sure, there are third-party websites which show discussions from mailing lists in a more readable way, and some even allow answering to them, but it isn’t quite the same. There is Google Groups, which is quite close at providing both interfaces, but the website isn’t really like a forum either and it just doesn’t feel right (also, it’s proprietary/centralized and not appropriate for usage by, for example, the Debian project).

Am I really asking for that much? I’ve considered, several times, writing such a system myself, but I just can’t believe that nobody has thought of it before (or, in case it already exists, that it isn’t in much more widespread use).

Related posts:

1. Another GNOME Shell post: what do you think about the window list? It’s already a few months since my two posts on...