L’avantage d’être un blogueur influent, outre le jet privé, les plages paradisiaques et les groupies qui se pâment à chaque fois que je sors acheter du chocolat, ce sont les ponts d’or que nous offrent les publicitaires.

Il ne se passe généralement pas une semaine sans qu’arrive dans ma boîte une « proposition de partenariat ». Il y a l’indémodable « proposition d’échange de liens » qui me fait à chaque fois vérifier mon calendrier pour voir si je ne suis pas revenu en 1997. Il y a eu les bannières personnalisées à coller un peu partout, les propositions de commissions ou de billets complètement sponsorisés pour parler d’un produit. Souvent, c’est sans rémunération : en échange du produit en question, je dois en parler. Ou alors on me propose de « faire la promotion de mon site ». Ou on essaie de faire du buzz (j’ai une fois reçu par la poste un rouleau de PQ. Comme j’ai du faire une heure de file au guichet pour arriver à retirer ce mystérieux colis, j’ai moyennement apprécié l’humour).

Cependant, tous avaient pour point commun de me demander de vous convaincre vous, mes sympathiques et adorés lecteurs, d’acheter une quelconque merde dont je ne connais rien.

Depuis quelques mois, les propositions sont un peu différentes : il s’agit cette fois d’insérer, dans un billet, un simple lien vers un site partenaire. On se fout des lecteurs, la seule chose qui intéresse le client c’est de bénéficier de mon page rank. Le nombre de propositions que je reçois prouve que les SEO ne sont pas rancuniers.

Les offres varient, chez moi, de 70€ à 150€ le billet. Certains me fournissent des billets déjà écrits, d’autres exigent que le billet soit accepté par le client et, enfin, certains se contentent de me donner une phrase qui doit être un lien vers le site du client. Autre exigence : pour paraître légitime aux yeux de Google, le billet doit comporter un ou deux autres liens, si possible internes, ou vers des sites reconnus.

Ce genre d’offres m’a placé devant un cas de conscience. Contrairement à d’autres pubs, cela n’est pas du tout intrusif pour mes lecteurs et cela me laisse entière liberté pour mes billets. De plus, le challenge littéraire de placer un mot précis dans un de mes billets m’amuse au plus haut point. Il me suffirait, par soucis de transparence, d’annoncer « Ce billet est sponsorisé à hauteur de 100€ par la société Machin ».

Mais, à ce niveau, les offres sont unanimes : il ne faut pas que ce soit trop clair. Certaines interdisent purement et simplement d’informer le lecteur. D’autres acceptent une sibylline mention « Article partenaire ». Les blogueurs que j’ai interrogé estiment que c’est suffisamment clair pour le lecteur. Mais une mention plus explicite risquerait d’attirer l’attention de Google qui interdit la vente de liens sous peine de diminution du Pagerank. Les SEO, qui ne sont pas à une contradiction près, prétendent que Google le tolère et que ça fait partie du business. Mais qu’il faut se cacher quand même.

Faire 100€ en s’amusant ou accepter le diktat de Google sur la définition d’un « site de qualité » ? Devenir vendeur de jus de page rank en échange d’une perte de transparence ? Pour le moment, je reste dubitatif.

Au moins, si vous voyez une mention « article partenaire » sur un blog, vous saurez désormais ce que ça veut dire. Ou même si vous n’en voyez pas, certaines agences exigeant de ne pas informer les lecteurs…

 

Photo “Fuck the System” par ACB

When I started producing content for the web, as hobbyist film maker, I was very enthusiastic about Creative Commons licenses. But not for my videos. Someone could use them in a bad way. I didn’t want that. The “bad way” was not clearly defined, something about nazis or paedophiles, but I was nonetheless fearing it.

Then I created a blog. I decided to publish my posts under a CC By license, moving a step forward to openness. Except some more important texts, which were under the CC By-ND license. Because I didn’t want them to be modified. You know, those texts were “important”, I was an artist, I had to keep full power over my creations.

Comments were a metric for my success. The more the comments, the better. When comments started to fade out, replaced by social networks, my new metric for success was the number of visitors per day. I could spend hours watching my statistics, exploring the sources of visitors.

I gradually switched everything to a CC By license, realizing that my fear of being misused was too abstract for not giving freedom to my readers. But I still asked a link to my blog each time I could in order to attract visitors, to see them in my statistics. I rarely posted on other blogs. My creations had to stay centralized.

Like moths on a sparkling light, bloggers are attracted by statistics. Google analytics, Page Rank, Twitter followers, Klout, Ebuzzing. It is addictive, time consuming and useless. I decided to quit.

I started to cross post my content over multiple places where I don’t have full control, such as Medium. I removed everything but the Flattr button. Yes, everything, including the G+/Facebook buttons and the Piwik/Google Analytics plugins. I don’t know any more how many people are reading me, how many reshares I have. I don’t care. I want to be free and, in order to achieve that, I had to free my creation first.

It took me ten years to overcome my irrational fears of the web. Today, I feel like I’m just discovering a new world. I’m a newborn. I’m not a creator asking to be admired by the non-creator mass. I’m someone contributing and dropping some little creation into a huge creative chaos where everybody is, in a way or another, a creator. Which is awesome.

If you like something, copy it, modify it, share it, re-create it. A text lives only when someone is reading it. A creation needs an audience.

Thanks for caring, thanks for sharing.

 

Picture by Epoxides

Visiblement, la Poste utilise des machines qui, parfois, ont faim et doivent se nourrir :

Dommage pour cette lettre !

J'enfile ma casquette de secrétaire de l'association pour vous signaler que l'équipe GNOME-FR vous accueillera au stand B25 du village des associations du salon Solutions Linux les 28 et 29 mai 2013, au CNIT de Paris - La Défense.

Ce sera l'occasion de nous rencontrer et discuter entre utilisateurs, développeurs ou simples curieux de l'environnement GNOME, sa communauté et ses projets. Voire même pour des membres potentiels à l'association de se manifester ;-)

1991

You: “I’d like to install a file server for the LAN – can I have the root password for the server, please”
Admin: “You’re kidding, right? Submit a ticket, we’ll install it when we get around to it”
crickets

1996

You: “I installed a Samba file server for the LAN on my own Linux machine”
Admin: “Gah! You messed up my workgroup. What happens when you turn it off? Bloody amateurs…”

2000

You: “I’d like to install a bug tracker for the dev team”
Admin: “The existing servers are overloaded – you’ll need a hardware req. Lodge a ticket, and get management approval first.”

2005

You: “I’d like to install a bug tracker for the dev team”
Admin: “I’ll create a VM for you to use. Lodge a ticket”

2013

You: “I’d like to install a bug tracker for the dev team”
Admin: “You have a self-service account on OpenStack, don’t you? What are you talking to me for?”

 

J'animerai ce mercredi, dans le cadre du hackerspace de l'ULB, un atelier sur le système de versioning Git.

Le contenu exact de l'atelier n'est pas encore arrêté mais devrait être accessible à toute personne ayant peu d'expérience avec Git. Selon le temps disponible et le niveau des participants, on abordera peut-être des fonctionnalités plus avancées, mais il y a de bonnes chances que celles-ci soient plutôt étudiées lors d'un atelier futur.

Si le sujet vous intéresse, vous êtes les bienvenus (inscription optionnelle mais appréciée).

Today, during the round table at distro recipes there was a short discussion about LSB usefulness and future. I was not participating but will share my opinion here instead.

Basically, I think xdg-utils from Freedesktop is doing what LSB Desktop should have been.

LSB wants distributions to provide a set of binary API (gtk2, qt3, now also qt4...). I don’t think that’s what vendors need.

Freedesktop provides a set of commands, providing a set of features with very simple API, allowing to easily integrate in any distribution and desktop environment (not even only under Linux).

Distributing the libraries with your application is easy (I think LSB can make sense for things like libc, etc). What vendors want is to integrate with the distribution (appear in the user menu, be associated with mimetypes, be able to start a browser, disable screensaver while the play a movie, get proxy configuration, maybe send an email...) without writing much code.

Freedesktop doesn’t mandate distributions to keep obsolete unmaintained libraries, it just asks them to provide a set of simple commands implementing the features in any way they may desire.

xdg-utils is now required by LSB 4.1 and that’s a good thing, but I believe most vendors are just interested in it, not in the rest of LSB.

Over the past couple of months, Satabdi has been working during her Outreach Program for Women on geocode-glib, and Zeeshan more recently joined us to help with cleaning up some of the code.

As Satabdi's program is now finished (though not her involvement!), and a new GNOME development cycle has started, I'll try to explain where geocode-glib fits in, and answer some questions on the future of Geoclue.

(Reverse-)Geocoding

First and foremost, geocode-glib is a geocoding and reverse geocoding library. It uses Yahoo! web services for this, though we're investigating using Nominatim for this in the future.

This replaces the convoluted implementations for those two services in geoclue (3 if you include Address as a service). The API should be mostly stable now, and we'll soon start porting a few applications to it (Evolution and Empathy come to mind).

The library also includes a GeocodeLocation object. This will be useful later.

GeoIP

geocode-glib, thanks to Satabdi's work, includes a GeoIP server, to be installed on GNOME servers eventually, which uses data from MaxMind to  locate a user connected to the Internet from the IP address. We also have a client library to access this server.

This is usually good enough to locate a user in a city, or a country, which would help us with many integration points in GNOME, such as the upcoming Date and Time panel re-design.

But this code isn't really for you, app developers.

Geoclue

A fine project, but the codebase is showing its age (dbus-glib!), and the decision, well, not to take decisions on which backends to use for various services make it fragile. This is a maintenance problem, both for in terms of making sure all the services are kept working, and that geoclue itself is kept stable.

So we'll start a reimplementation of Geoclue. The goals are:

• Trimmed down API, just for positioning
• Smaller, but more integrated, selection of ways to get the positioning (GPS from your integrated WWAN modem, Wi-Fi AP data, IP address, no discrete GPS or manual location)
• Power-saving, by aggregating requests from all the applications
• and finally, privacy, where only applications that you allow to request your location can get it, and only with an accuracy as needed for the application.

The code currently in geocode-glib for IP geocoding will likely move there when the project has been kickstarted.

I hope this clears any misconceptions people might have about geocode-glib, or, more likely, about the future of geoclue.

As most of you know, Ekiga 4.0 is still based on older technologies like GTK+-2.0. The goal is to remove all deprecated or outdated dependancies before Ekiga 4.2.

The GTK+-3.0 porting work is now terminated. Much work has been done by Víctor Manuel Jáquez Leal from Igalia. More changes will happen in the future, for example to replace the current display system with a new one based on GStreamer and/or Cairo.

The GSettings migration has started in a separate ds-gsettings branch.

Help is welcome to replace other older technologies like HAL for example.

Share on Facebook

Long time without any activity here, and more generally less time with computers those past months, even though I visited Lyon for the JDLL in November and I was of course present in Brussels for the FOSDEM and the developer experience hackfest that happened just before. (I didn't write about it but it was totally unexpected for me to find myself there with two other motivated devhelp developers, many thanks to Aleksander and Thomas.)

But I am now finally back in action, installed in my new place, and for the occasion here are some pictures, starting perhaps with the most raw moment, after a few weeks:

I kept my other flat for a few months but had to let it go by December, and by chance my new upstairs neighbour offered me her spare bedroom, as well as her attic to store my boxes (thanks Fleur!). Still it kept for longer than expected and I became quite impatient of settling in my new place, and that finally happened ~10 days ago.

The packing boxes left the attic but most of them are still unopened.

The kitchen is almost done, not shown in the picture: a fridge is still missing.

And I have the most fabulous bathroom.

Thanks to my good friend Macha for the architect work she did, it's that nice because she always had the eyes on the smallest details.

Have you heard about it? openSUSE 12.3 is out!

I did an upgrade earlier today on my main laptop (with a simple zypper dup after having updated the repos configuration, which went surprisingly fast), and this release looks great! But the best part: it comes with OpenStack love!

Enjoy Folsom!

For the first time, an openSUSE release provides a fully working set of OpenStack packages. We had some OpenStack packages in the previous release, but they were not in such a great shape and some components were even missing (although we fixed that later on with packages in the build service).

With 12.3, you can finally enjoy OpenStack with the Folsom release in a very straight-forward way, and therefore you can easily deploy your own cloud. The packages that we provide are built from the stable/folsom branch, and there's an online update coming soon so you can enjoy the stable/folsom code as of end of last week.

To help people who might not want to learn everything needed to properly deploy OpenStack, we also have a small openstack-quickstart package, that comes with a script that can be used to deploy everything locally. It is obviously not recommended to run this on your main computer (I usually run this in a virtual machine), but it gets you quickly to the point where you can play with OpenStack.

Dashboard of an OpenStack cloud running on openSUSE 12.3

Play today with Grizzly!

Of course, Folsom is relatively old at this point and the new version, Grizzly, is to be released in three weeks. But don't be sad! We've been working on Grizzly packages for some time now: you can grab them from the Cloud:OpenStack:Master project in the build service (hey, look, it's even building packages for SLE and openSUSE 12.2! the build service is a rather convenient tool!). I guess we'll properly move them to Cloud:OpenStack:Grizzly once Grizzly is officially released.

Develop with DevStack!

I mentioned a few months ago that I had finished porting DevStack to openSUSE 12.2, and I wrote some small documentation on how to use it. It's really a neat tool, both for playing with OpenStack and for developing for it.

However, I realized earlier this week that I had never double-checked everything was still okay for 12.3. It turns out there's a small issue that completely breaks it, oops ;-) But once the fix is checked in, DevStack will be usable on the latest openSUSE. I'll do some more tests before marking this version of openSUSE as supported in DevStack, but that shouldn't block anyone from using DevStack on 12.3.

Join us!

We're pretty open about how we develop OpenStack in openSUSE. Andreas wrote a post about all this a few days ago. We've opened up (or rather, revived) a mailing list dedicated to the cloud recently, which developers, packagers and users can all use to discuss OpenStack. And unsurprisingly, we also have an #opensuse-cloud channel on Freenode. But most importantly, we've worked on making public the infrastructure we use to build OpenStack for openSUSE.

I think the important bit on this is that everybody is able, and welcome, to join this effort. It's not just about being able to say "see, we have OpenStack"; it's about building a rock-solid experience for OpenStack, and enjoying doing that!

Now, let's celebrate the release: party time! :-)

I hope that everyone enjoyed the new virtual UDS format as we did.

However, don't despair, it's not really *over* yet! The discussion around the application lifecycle^[1] was covering a too large spectrum and we didn't get time to properly finish discussing it. As we didn't want to run over other sessions, we decided to reschedule it just after UDS.

The new follow-up session "Application model: lifecycle" will happen this Friday, March 8, 16:00 – 16:25 UTC. It will be a hangout on air and people will follow up questions on #ubuntu-devel, IRC, freenode. We'll try to set up with the community an ubuntu on air session so that links are easier to find (this blog post will be updated with exact information near the event time).

Happy post vUDS session!

Today I received some spam from a guy, sent by linkedin (it comes from their servers).

The message had the email address of all the recipients in the To field, meaning they gave away that email address to that random people I don't know! I was annoyed at their password leak, but it seems they deliberately give email addresses away...

Their privacy policy states that Your contact information will only be shared with another User if both of you have indicated that you would like to establish contact with each other. but this is a lie, it will be also shared if someone sends a message to both of you.

I tried to contact them, the first step to prevent it is their infinite scrolling preventing from clicking on the links at the bottom of the page unless you are very fast.

The second problem is their help center (which it seems you have to go through to contact them) which doesn't load "There has been an error with your request.".

Je viens de constater que je suis encore sur Planète Mandriva. Pourtant cela fait bientôt 2 ans que je suis passé à Mageia, et je suis content de ce choix. Par conséquent, je viens d'envoyer un mail pour être retiré de la planète...

Bye bye Mandriva, nous aurons passé de bons moments ensemble, depuis la Mandrake 9.1.

This post is part of the Unity daily release process blog post suite.

After a week to let people ask questions about the daily release process, I guess it's time to catch up and conclude this serie with a FAQ and some thoughts for the future.

FAQ

The FAQ is divided in multiple sequences depending on your role in the development of ubuntu, with the hope that you will be able to find what you are looking for quicker this way. If you have any question that isn't addressed below, please ping didrocks on IRC freenode (#ubuntu-unity) and I'll complete this page.

Upstream developers

What's needed to be done when proposing a branch or reviewing?

As discussed in this part, when proposing a branch or reviewing a peer's work, multiple rules have been established. The developers needs to:

• Design needs to acknowledge the change if there is any visual change involved
• Both the developer, reviewer and the integration team ensure that ubuntu processes are followed (UI Freeze/Feature Freeze for instance). If exceptions are required, they check before approving for merging that they are acknowledged by different parts. The integration team can help smooth to have this happened, but the requests should emerge from developers.
• Relevant bugs are attached to the merge proposal. This is useful for tracking what changed and for generating the changelog as we'll see in the next part
• Review of new/modified tests (for existence)
• They ensure that it builds and unit tests are passing automated
• Another important one, especially when you refactor, is to ensure that integration tests are still passing
• Review of the change itself by another peer contributor
• If the change seems important enough to have a bug report linked, ensure that the merge request is linked to a bug report (and you will get all the praise in debian/changelog as well!)
• If packaging changes are needed, ping the integration team so that they acknowledge them and ensure the packaging changes are part of the merge proposal.

When you approve a change, do not forget to check that there is a commit message in launchpad provided and to set the global status to "approved".

When do changes need to land in a coherent piece?

Some changes can happen and touch various components (even across different stacks). To avoid loosing a daily release because only half of transition landed in some upstream projects (and so, tests will fail because they catch this issues, isn't it? ;)), it's asked to ensure that all transitions are merged by 00 UTC. Then, you can start approving again transition starting from 06 UTC. We can try to make this window shorter in the future, but let's see first how this work in practice. For any big transition, please coordinate with the ubuntu-unity team team so that they can give a hand.

I have a change involving packaging modifications

As told in a previous section, just ask for the ubuntu-unity team to do some review or assisting in doing those changes.

I want to build the package locally myself

If you have done some packaging changes, or added a C symbol, you maybe want to ensure that it's building fine. Quite simple, just go into your branch directory and run $ bzr bd (from the bzr-builddeb package). This will build your package on your machine using the same flags and checks than on the builders. No need to autoreconf if you are using autotools, everything is handled for you. You will get warned as well if some installed files are missing.

I need to break an API/ABI

The first question is: "are you sure?". Remember that API changes are a PITA for all third parties, in particular if your API is public. Retro-compatibility is key. And yes, your dbus interface should be considered as part of your API!

If you still want to do that, ensure that you bump your soname if the ABI is broken, then, multiple packaging changes are needed. Consequently, ensure to ping your lovely ubuntu-unity team to request assistance. The transition should happen (if no retrocompatibility is provided) within the previously mentionned timeframe to have everything landing in coherence.

You also need to ensure that for all components build-depending on the API you changed, you bumped the associated build dependency version in debian/control.

To what version should I bump the build dependency version?

Let's say you added an API to package A. B is depending on A and you want to start using this new awesome API. What version should be used in debian/control to ensure I'm building against the new A?

This is quite easy, the build-dependencies in debian/control should look like: A >= 6.0daily13.03.01 (eventually ended by -0ubuntuX). Strip the end -0ubuntuX and append then bzr<rev_where_you_added_the_api_in_trunk>. For instance, let's imagine you added the API in rev 42 in trunk, so the build-dep will change from:

A >= 6.0daily13.03.01

to:

A >= 6.0daily13.03.01bzr42

This is to ensure the upstream merger will be able to take it.

If no "daily" string is provided in the dependency you add, please check with the ubuntu-unity team.

I'm exposing a new C symbols in my library, it seems that some packaging changes are needed…

Debian packages have a debian/<packagename>.symbols file which lists all exposed symbols from your library (we only do that for C libraries as C++ does mangle the name per architecture). When you try to build the package containing a new symbol, you will see something like:

--- debian/libdee-1.0-4.symbols (libdee-1.0-4_1.0.14-0ubuntu2_amd64)

+++ dpkg-gensymbolsvPEBau 2013-02-05 09:43:28.529715528 +0100

-4,6 +4,7

dee_analyzer_collate_cmp@Base 0.5.22-1ubuntu1

dee_analyzer_collate_cmp_func@Base 0.5.22-1ubuntu1

dee_analyzer_collate_key@Base 0.5.22-1ubuntu1

+ dee_analyzer_get_type@Base 1.0.14-0ubuntu2

dee_analyzer_new@Base 0.5.22-1ubuntu1

dee_analyzer_tokenize@Base 0.5.22-1ubuntu1

dee_client_get_type@Base 1.0.0

The diff shows that debian/libdee-1.0-4.symbols doesn't list the exposed dee_analyzer_get_type new symbol. You see a version number next to it, corresponding to the current package version. The issue is that you don't know what will be the package version in the future when the next daily release will happen (even if you can infer), what to put then?

The answer is easier than you might think. As explained in the corresponding section, the daily release bot will know what version is needed, so you just need to give a hint that the new symbol is there for the upstream merger to pass.

For than, just include the symbol, with 0replaceme^[1] as the version for the branch you will propose as a merge request. You will thus set in your symbols file:

dee_analyzer_collate_cmp@Base 0.5.22-1ubuntu1

dee_analyzer_collate_cmp_func@Base 0.5.22-1ubuntu1

dee_analyzer_collate_key@Base 0.5.22-1ubuntu1

dee_analyzer_get_type@Base 0replaceme

dee_analyzer_new@Base 0.5.22-1ubuntu1

dee_analyzer_tokenize@Base 0.5.22-1ubuntu1

dee_client_get_type@Base 1.0.0

The dee_analyzer_get_type@Base 0replaceme line will be replace with the exact version we release in the next daily release.

My name deserves to be in the changelog!

I'm sure you want the world to know what great modifications you have introduced. To get this praise (and blame ;)), we strongly advise you to link your change to a bug. This can be done in multiple ways, like link bugs to a merge proposal before it's approved (you link a branch to the bug report in launchpad), or use "bzr commit --fixes lp:XXXX" so that automatically links it for you when proposing the merge for reviewing, or put in a commit message something like "this fixes bug…". This will avoid the changelog to have only empty content.

I invite you to read "Why not including all commits in debian/changelog?" from this section to understand why we don't include everything, but only bug reports title in the changelog.

Ubuntu Maintainers

I want to upload a change to a package under daily release process

Multiple possibilities there.

The change itself can wait next daily release

If it's an upstream change, we strongly advise you to follow the same procedure and rules than the upstream developers, meaning, proposing a merge request and so on… bzr lp-propose and bzr branch lp:<source_package_name> are regularly and automatically adjusted as part of the daily release process to point to the right branches so that you can find them easily. Vcs-Bzr in debian/control should point to the right location as well.

Then, just refer to the upstream merging guidelines above. Once approved, this change will be in the next daily release (if tests pass).

An urgent change is needed

If the change needs to be done right away, but can wait for a full testing round (~2 hours), you can:

• Propose your merge request
• Ping someone from the ubuntu-unity team who will ensure the branch is reviewing in priority and rerun a daily release manually including your change. That way, your change will get the same quality reviews and tests checking than anything else entering the distro.

It's really urgent

You can upload right away your change then, the next daily will be blocked for that component though (and only for that component) until your change reaches upstream. So please, be a good citizen and avoid more churn in proposing your change back to the upstream repo (including changelog), pinging the ubuntu-unity team preferably.

I'm making a change, should I provide anything in debian/changelog?

Not really, as mentioned earlier, if you link to a bug or mention in a commit message a bug number in your branch before proposing for review, this will be taken into account and debian/changelog will be populated automatically with your name as part of the next daily release. You can still provide it manually and the daily release will ensure there is no duplication if it was already mentionned.

If you provide it manually, just: dch -i and ensure you have UNRELEASED for an unreleased version to ubuntu (without direct upload).

ubuntu-unity team

Note that in all following commands, if -r <release> is not provided, "head" is assumed. Also, ensure you have your credentials working and be connected to the VPN (the QA team is responsible for providing those jenkins credentials).

Where is the jenkins start page?

There it is.

Forcing a stack publication

After reviewing and ensuring that we can release a stack (see section about manual publication causes, like packaging changes to review or upstream stack failing/in manual mode). Then run:

$ cu2d-run -P <stack_name> -r <release>

example for indicators, head release:

$ cu2d-run -P indicators

Remember that the master "head" job is not rerun, so it will stay in its current state (unstable/yellow). The publish job should though goes from unstable/yellow to green if everything went well.

Rerun a full stack daily release, rebuilding everything

$ cu2d-run -R <stack_name> -r <release>

Rerun a partial stack daily release, rebuilding only some components

$ cu2d-run -R <stack_name> -r <release> <components>

/!\ this will keep the state and take into account (failure to build state for instance) and the binaries packages for the other components which were part of this daily release, but not rebuilt.

for instance, keeping dee and libunity, but rebuilding compiz and unity from the unity, head release stack:

$ cu2d-run -R unity compiz unity

The integration tests will still take everything we have (so including dee and libunity) at the latest stack with the new trunk content for compiz and unity when we relaunched this command.

Rerun integration tests, but taking all ubuntu-unity ppa's content (like transition needing publication of the indicator and unity stacks):

$ cu2d-run -R <stack_name> -r <release> --check-with-whole-ppa

This command doesn't rebuild anything, just run the "check" step, but with the whole ppa content (basically doing a dist-upgrading instead of selecting only desired components from this stack). This is handy when for instance a transition involved the indicator and unity stack. So the indicator integration tests failed (we don't have the latest unity stack built yet). Unity built and tests pass. To be able to release the indicator stack as well as the unity stack, we need the indicator stack to publish, for that, we relaunch only the indicator tests, but with the whole ppa content, meaning last Unity.

In that case, the publish for the indicators will be manual (you will need to force the publication) and as well, you should ensure that you will publish the unity stack at the same time as well to have everything in coherence copied to the -proposed pocket. More information on the stack dependency in this section.

Adding/removing components to a stack

The stack files are living in jenkins/etc/. This yaml file structure should be straightforward. Note that the tuple component: branch_location is optional (it will be set to lp:component if not provided). So add/change what you need in those file.

Be aware that all running jobs are stopped for this stack.

$ cu2d-update-stack -U <path_to_stack_file>

This will reset/reconfigure as well all branches, add -S if you don't have access to them (but ensure someone will configure them still at least once)

Different level of failures acceptance.

We do accept some integration tests failing (no unit tests should fail though as ran as part of package building). The different level of those triggers are defined in a file like jenkins/etc/autopilot.rc. Those are different level of failures, regressions, skipped and removed tests per stack. The real file depends on stackname and are found in $jenkins/cu2d/<stack_name>.autopilotrc as described in the -check template.

Monitoring upstream uploads and merges

Remember to regularly look at the -changes mailing list to pick if a manual upload has been done and port the changes back (if not proposed by the ubuntu developer making the upload) to the upstream branch. The component which had a manual upload is ignored for daily release until this backport is done, meaning that no new commits will be published until then (you can see the prepare job for that component will turn unstable).

Also, ensure as you are watching all upstream merges to follow our acceptance criterias that the "latestsnapshot" branches generated automatically by the daily release process has been merged successfully by the upstream merger.

Boostrapping a new component for daily release

A lot of information is available on this wiki page.

Conclusion

Phew! This was a long serie of blog post. I hoped that you appreciated to have a deeper look of what daily release means, how this work, and also that the remaining questions have been answered by the above FAQ. I've just ported all those information on the https://wiki.ubuntu.com/DailyRelease.

Of course, this is not the end of the road, I have my personal Santa Claus wishlist like UTAH being more stable (this is under work), the daily image provisionning with success more often than now, refactorisation work taking integration tests into account, less Xorg crashes when completing those tests… This is currently adding a little bit of overhead as of course, any of this will reject the whole test suite and thus the whole stack. We prefer to always be on the safe side and not accepting something in an unknown state!

Also, on the upstream stack and daily release process as well, there are rooms for improvments, like having less upstream integration tests failing (despite awesome progress already there), I wish I can soon turn that down to 3% of accepted failure at most for unity instead of the current 7% one. Dedicated integrations tests for indicators would be awesome as well (stealing the unity ones for now and only running those involving indicators, but of course, not everything is covered). Having also some oif, webapps and wecreds integration tests is one of my main priority, and we are working with the various upstream developers to get this done ASAP so that we have a better safety net than today. On the daily release process itself, maybe freezing all trunks in a go would be a nice improvement, more tests for the system itself as well is under work and my personal goal to reach 100% test coverage for the scripts before making any additional changes. Finally, some thoughts for later but a dashboard would enable to have a higher view than just using jenkins directly for reporting, to get a quicker view on all stack statuses.

Of course, I'm sure that we'll experience some bumpy roads with this daily release process through the cycle, but I'm confident we'll overcome them and I am really enthousiast about our first releases and how smoothly they went until now (we didn't break the distro… yet :p^[2]. I'm sure this is a huge change for everyone and I want again give a big thank you to everyone involved into that effort, from the distro people to upstream and diverse contributors on the QA team. Changing to such a model isn't easy, it's not only having yet another process, but it's really a change of mindset in the way we deliver new features and components to Ubuntu. This might be frightening, but I guess it's the only way we have to ensure a systematic delivery, continuous and increasing quality while getting well a really short feedback loop to be able to react promptly to the changes we are introducing to our audience. I'm confident we are already collecting all the fruits of this effort and going to expand this more and more in the future.

For all those reasons, thanks again to all parties involved and let's have our daily shot of Unity!

I couldn't finish without a special thanks to Alan Pope for being a patient first reader, and fixing tediously various typos that I introduced into the first draft of those blog posts.

Hi folks,

for those of you who are attending FOSDEM this year and were planning to attend my talk about Secure Boot on openSUSE on Sunday, I'm sorry to announce I had to cancel my travel to Brussels (and my talk) for family reasons.

Since my slides were already written, I thought I could still share them with you Feel free to ask questions / comments on this blog post.

In the past couple of weeks, apart from reviewing very many patches for gnome-control-center (especially for new and re-designed panels), I've been working on updating the power management handling in GNOME.

Test suite

The first change is that we have a test suite (currently with 15 separate tests) to test interaction between gnome-settings-daemon's power management and various session and system components. This is thanks to Martin Pitt, and his work on python-dbusmock.

We'll try and add new tests as bug reports come in to avoid regressions, although some cases will remain untested because of limitations in our logging.


Screensaver and backlight interaction

With gnome-shell becoming the sole screensaver (after the removal of fallback mode, and the obsoletion of gnome-screensaver), we've been able to streamline the code handling the various screen backlight power levels.

Your screen will now turn off as soon as the screensaver kicks in, moving your mouse in the screensaver will turn it back on for 20 seconds before turning off again, and when to dim (if you've chosen so) is dependent on whether you're on battery or not, and the default idle time (eg. if your screen turns off after 5 minutes of inactivity, the screen will dim after 4). This makes the behaviour more consistent, and predictable, compared to the mish-mash of settings we had before, where some delays were available for change in the UI, and others only through GSettings or gnome-tweak-tool.

Those constants are separate from the code, and exported to the test suite so they are flexible and can be changed if the behaviour doesn't exactly match what users are expecting.

The other change relating to that, is that the screen shield will now always pop down when the screensaver kicks in (thanks to Giovanni for the gnome-shell work). This doesn't mean that you'll have to enter your password each time, but only after the "lock delay" if you've set one.

We've also added a number of nice touches, like the screen turning back on for a short period when you plug or unplug your laptop, made sure that your laptop screen gets turned off and your session locked when closing the lid and turn off the backlight for machines where suspend causes the backlight to come back on temporarily (as seen on MacBooks).

Very very idle

We've also added a long-requested feature: the ability to force logout after a period of idle. This is useful in kiosk and computer lab situations, and is only available through GSettings. As we've added support for this feature (warning prior to logging out, with the screen turning on for a couple of seconds when the warning shows up), we've realised that the infrastructure is the same for automatic suspend/hibernate situation. This means I expect to change the default "long idle" behaviour to suspending. This will still be changeable in the Power preferences. This should land after 3.7.5, and don't worry, we'll make this change very visible in the release notes :)

For anyone who saw the recent launch of the new oVirt website a while back and was wondering how we could make such an attractive theme and lay-out for a MediaWiki wiki, wonder no more. In fact, you don’t even have to be jealous! Because the theme, called Strapping, so called because it’s based on the Bootstrap web framework, has just been published by my colleague Garrett on GitHub.

Kudos to Garrett, who did amazing work on this theme to make it as beautiful and reusable as possible, and I’m looking forward to using it for other websites in the near future. And so can you!

Wandering in embedded land: part 2, Arduino turned remote control

Now with the Midea AC remote control being mostly deciphered,
the next step is to emulate the remote, with an arduino since it's
the system I use for that embedded greenhouse control. While waiting
for my mail ordered IR LED (I didn't want to solder off one from my
existing AC controllers), I started doing a bit of code and looking
at the integration problems.

The hardware side

One of the challenge is that the Arduino system is already heavy
packed, basically I use all the digital Input/Output except 5 (and 0 and
1 which are hooked to the serial support), and 2 of the 6 analog inputs,
as the card already drives 2 SHT1x temp/humidity sensors, 2 light sensors,
an home made 8 way relay board, and a small LCD display, there isn't much
room left physically or in memory for more wires or code ! Fortunately
driving a LED requires minimal resources, the schematic is trivial:

I actually used a 220 Ohms resistance since I didn't had a 100 Ohms one,
the only effect is how far the signal may be received, really not a problem
in my case. Also I initially hooked it on pin 5 which shouldn't had been
a problem, and that's the free slot I have available on the Arduino

The software side

My thinking was: well I just need to recreate the same set of light
patterns to emulate the remote control and that's done, sounds fairly simple
and I started coding royines which would switch the led on or off for
1T, 3T and 4T durations. Thus the core of the code was like:

void emit_midea_start(void) {

    ir_down(T_8);

    ir_up(T_8);

}

void emit_midea_end(void) {

    ir_down(T_1);

    ir_up(T_8);

}

void emit_midea_byte(byte b) {

     int i;

     byte cur = b;



     for (i = 0;i < 8;i++) {

         ir_down(T_1);

         if (cur & 1)

             ir_up(T_3);

         else

             ir_up(T_1);

         cur >>= 1;

     }

     cur = ~b;

     for (i = 0;i < 8;i++) {

         ir_down(T_1);

         if (cur & 1)

             ir_up(T_3);

         else

             ir_up(T_1);

         cur >>= 1;

     }

}

where ir_up() and ir_down() were respectively activating or deactivating
the pin 5 set as OUTPUT for the given duration defined as macros.

Playing with 2 arduinos simultaneously

Of course to test my code the simplest was to set up the new module on
another arduino positioned in front of the Arduino with the IR receptor
and running the same code as used for decoding the protocol.

The nice thing is that you can hook up the arduinos on 2 different USB
cables connected to the same machine, they will report as ttyUSB0 and ttyUSB1
and once you have looked at the serial output you can find which is which.
The only cumbersome part is having to select the serial port to the other one
when you want to switch box either to monitor the output or to upload a new
ersion of the code, so far things are rather easy.

Except it just didn't worked !!!

Not the arduino, I actually replaced the IR LED by a normal one from
time to time to verify it was firing for a fraction of a second when
emitting the sequence, no the problem was that the IR receiver was detecting
transitions but none of the expected duration, or order, nothing I could
really consider a mapping of what my code was sending. So I tweaked
the emitting code over and over rewriting the timing routines in 3
different ways, trying to disable interrupts, etc... Nothing worked!

Clearly there was something I hadn't understood ... and I started
searching on google and reading, first about timing issues on the Arduino
but things ought to be correct there, and then on existing remote control
code for Arduino and others. Then I hit
Ken Shirriff's blog on his IR library for the Arduino and realized
that the IR LED and the IR Receiver don't operate at the same level. The
LED really can just be switched on or off, but the IR Receiver is calibrated
for a given frequency (38 KHz in this case) and will not report if it
gets the IR light, but report if it gets the 38 KHz pulse carried by
the IR light. In a nutshell the IR receiver was decoding my analogic 0's
but didn't for the 1's because it was failing to catch a 38 KHz pulse,
I was switching the IR led permanently on and that was not recognized as
a 1 and generating erroneous transitions.

Emitting the 38KHz pulse

Ken Shirriff has another great article titled
Secrets of Arduino PWM explaining the details used to generate a pulse automatically
on *selected* Arduino digital output ans explains the details used to set this
up. This is rather complex and nicely encapsulated in his infrared library
code, but I would suggest to have a look if you're starting advanced
developments on the Arduino.

The simplest is then to use Ken's
IRremote library
by first installing it into the installed arduino environment:

• create a new directory /usr/share/arduino/libraries/IRremote (as root)
• copy IRremote.cpp IRremote.hIRremote.h IRremoteInt.h there

and then use it in the midea_ir.ino program:

#include <IRremote.h>



IRsend irsend;



int IRpin = 3;

This includes the library in the resulting program, define an IRsend
object that we will use to drive the IR led. One thing to note is that
by default the IRremote library drives only the digital pin 3, you can
modify it to change to a couple of other pins, but it is not possible to
drive the PWM for digital pin 5 which is the one not used currently on
my greenhouse Arduino.

Then the idea is to just replace the ir_down() and ir_up() in the code
with the equivalent low level entry points driving the LED in the IRsend
object, first by using irsend.enableIROut(38) to enable the pulse at
38 KHz on the default pin (Digital 3) and then use irsend.mark(usec)
for the equivalent ir_down() and irsend.space(usec) for the ir_up():

void emit_midea_start(void) {

    irsend.enableIROut(38);

    irsend.mark(4200);

    irsend.space(4500);

}



void emit_midea_end(void) {

    irsend.mark(550);

    irsend.space(4500);

}

void emit_midea_byte(byte b) {

     int i;

     byte cur = b;

     byte mask = 0x80;



     for (i = 0;i < 8;i++) {

         irsend.mark(450);

         if (cur & mask)

             irsend.space(1700);

         else

             irsend.space(600);

         mask >> 1;

     }



...

Checking with a normal led allowed to spot a brief light when emitting
the frame so it was basically looking okay...

And this worked, placing the emitting arduino in front of the receiving
the IRanalyzer started to decode the frames, as with the real remote control,
things were looking good again !

But failed the real test ... when put in from of the AC the hardware didn't
react, some improvement is still needed.

Check your timings, theory vs. practice

I suspected some timing issue, not with the 38KHz pulse as the code from
Ken was working fine for an array of devices, but rather how my code was
emitting, another precious hint was found in the blog about the library:

IR sensors typically cause the mark to be measured as longer than expected and the space to be shorter than expected. The code extends marks by 100us to account for this (the value MARK_EXCESS). You may need to tweak the expected values or tolerances in this case.

remember that the receptor does some logic on the input to detect the
pulse at 38 KHz, that means that while a logic 0 can be detected relatively
quickly, it will take at least a few beats before the sync to the pulse is
recognized and the receiver switch its output to a logic 1. In a nutshell
a 1 T low duration takes less time to recognize than an 1 T high duration.
I was also afraid that the overall time to send a full frame would drift
over the fixed limit needed to transmit it.

So I tweaked the emitting code to count the actual overall duration of
the frames, and aslo added to the receiver decoding code the display of the
duration of the first 10 durations between transitions. I then reran the
receiver looking at the same input from the real remote control and the
arduino emulation, and found that in average:

• the emulated 8T down was 200us too long
• the emulated 8T up was 100us too short
• the emulated 1T down at the beginning of a bit was 100us too long
• the emulated 1T up at the end of logical 0 was 80us too short
• the emulated 3T up at the end of logical 1 was 50us too short

After tweaking the duration accordingly in the emitter code, I got
my first successful emulated command to the AC, properly switching it off,
SUCCESS !!!

I then finished the code to provide the weird temperature conversions
front end routines and then glue that as a test application looping over
a minute:

• switching to cooling to 23C for 15s
• switching to heating to 26C for 15s
• switching the AC off for 30s

The midea_ir_v1.ino code
is available for download, analysis and reuse. I would suggest to not
let this run for long in fron of an AC as the very frequent change of mode
may not be good for the hardware (nor for the electricity bill !).

is available for download

Generating the 38KHz pulse in software

While the PWM generation has a number of advantages, especially w.r.t.
regularity of the pattern and no risk of drift due for example to delays
handling interrupts, in my case it has the serious drawback of forcing use
of a given pin (3 by default, or 9 if switching to a different timer in the
IRremote code), and those are not available, unless getting the soldering
iron and changing some of the existing routing in my add-on board. So
the next step is to also implement the 38KHz pulse in software. First
this should only affect the up phase, the down phase consist of no emission
and hence implemented by a simple:

void send_space(int us) {

    digitalWrite(IRpin, LOW);

    delayMicroseconds(us);

}

The up part should divised into HIGH for most of the duration, followed
by a small LOW indicating the pulse. 38 KHz means a 26.316 microseconds
period. Since the delayMicroseconds() of the arduino indicates it can be
reliable only for more than 3 microseconds, it seems reasonable to use
a 22us HIGH/ 4us LOW split, and expect the remaining computation to fill
the sub-microsecond of the period, that ought to be accurate enough. One
of the point of the code below is to try to avoid excessive drift in two
ways:

• by doing the accounting over the total lenght for the up period,
  not trying to just stack 21 periods
• by running a busy loop when the delay left is minimal rather than
  call delayMicroseconds() for a too small amount (not sure it's effective
  micros() value seems periodically updated by an timer interrupt handler
  doesn't look like the chip provides a fine grained counter).

The resulting code doesn't look very nice:

void send_mark(int us) {

    unsigned long e, t = micros();

    e = t + us;

    while (t < e) {

        digitalWrite(IRpin, HIGH);

        if (t - e < 4) {

            while ((t = micros()) < e);

            digitalWrite(IRpin, LOW);

            break;

        }

        if (t - e < 22) {

            delayMicroseconds(t-e);

            digitalWrite(IRpin, LOW);

            break;

        }

        delayMicroseconds(22);

        digitalWrite(IRpin, LOW);

        t = micros();

        if (t - e < 4) {

            while ((t = micros()) < e);

            break;

        }

        delayMicroseconds(4);

        t = micros();

    }

}

But to my surprize once I replaced all the irsend.mark() and irsend.space()
by equivalent calls to send_mark() and send_space(), the IRanalyzer running on
the second arduino properly understood the sequence, proving that the IR
receiver properly picked the signal, yay !

Of course that didn't worked out the first time on the real hardware,
after a bit of analysis of the resulting timings exposed by IRanalyzer
I noticed the mark at the beginning of bits were all nearly 100us too long,
I switched the generation from 450us to 350us, and bingo, that worked with the
real aircon !

the midea_ir_v2.ino resulting module
is very specific code, but it is tiny, less than 200
lines, and he hardware side is also really minimal, a single resistor and
the IR led.

Epilogue

The code is now plugged and working, but v2 just could not work in the
real environment with all the other sensors and communication going on.
I suspect that the amount of foreign interrupts are breaking the 38KHz
pulse generation, switching back to the PWM generated pulse using the
IRremote library works in a very reliable way. So I had to unsolder pin 3
and reaffect it to the IR led, but that was a small price to pay in
comparison of trying to debug the timing issues in situ !

The next step in the embedded work will be to replace the aging NSLU2
driving the arduino by a shiny new Raspberry Pi !

This entry will be kept at http://veillard.com/embedded/midea.html.

The legendary GNU/Linux softphone is back for more!

Three years after the 3.2 release, Ekiga 4.0 aka “The Victory Release” is finally available.

This is a major release with many major improvements.

Please read the full announcement at: http://www.ekiga.org/news/2012-11-27/ekiga-4.0-aka-victory-release-available.

Share on Facebook

Wandering in embedded land: part 1, Midea 美的 aircon protocol

I have been a user of Arduino's for a few years now, I use them to
control my greenhouse (I grow orchids). This mean collecting data
for various parameters (temperature, hygrometry, light) and actionning
a collection of devices in reaction (fan, misting pump, fogging machine,
a heater). The control part is actually done by an NSLU2 which also
collects the data, export them as graph on the internet and allows me
to manually jump in and take action if needed even if I'm far away
using an ssh connection.

This setup has been working well for me for a few years but since our
move to China I have had an airon installed in the greenhouse like in
other parts of the home. And that's where I have a problem, this AC of
brand Midea (very common home appliance brand in China) can only be
controlled though a remote control. And until now that meant I had no
way to automtate heating or cooling, which is perfectly unreasonnable :-)

After some googling the most useful reference I found about those
is the Tom's
Site page on building a remote adapter for those. It explained most
parts of the protocol but not all of them, basically he stopped at the
core of the interface but didn't went into details, for example didn't
explained the commands encoding. The 3 things I really need are:

• Start cooling to a given temperature
• Start heating to a given temperature
• Stop the AC

I don't really need full fan speed control, low speed is quite sufficient
for the greenhouse.

Restarting the Arduino development

I hadn't touched the Arduino development environment for the last few
years, and I remember it being a bit painful to set up at the time. With
Fedora 17, things have changed, a simple

yum install arduino

and launching the arduino tool worked the first time, actually it asked me
the permission to tweak groups to allow me as the current user to talk
through the USB serial line to the Arduino. Once done, and logging in again
everything worked perfectly, congratulation to the packagers, well done !
The only sowtware annoyance is that is often take a dozen seconds between the
time an arduino is connnected or powered and when it appears in the
ttyUSB? serial ports options in the UI, but that's probably not arduino's
fault.

The arduino environment didn't really change in all those years,
the two notable exception is the very long list of different boards supoorted
now, and the fact that arduino code files are renamed from .pde to .ino !

Learning about the data emitted

The first thing needed was to double check the result from Tom with
our own hardware, then learn about the protocol to be able to construct
the commands above. To do this I hooked a IR receptor to the Arduino on
digital pin 3, the graphic below show the logic, it's very simple:

Then I loaded a modified (for IRpin 3) version of Walter Anderson's
IRanalyzer.pde
onto the Arduino and started firing the aircon remote control at the
receiver and looked at the result: total garbage ! Whatever the key
pressed the output had no structure and actually looked as random as
input without any key being pressed :-\

It took me a couple of hours of tweaking to find out that the metal
enclosure of the receiver had to be grounded too, the GRD pin wasn't
connected, and not doing so led to random result !

Once that fixed, the data read by the Arduino started to make some
sense and it was looking like the protocol was indeed the same as the
one described in Tom's site.

The key to the understanding of how the remote work is that it
encodes a digital input (3 Bytes for Midea AC protocol) as a set of
0 and 1 patterns each of them being defined by a 0 analogic duration
followed by a short anlogic pulse at 38KHz to encode 0, or a long
analogic pulse at 38KHz to encode 1:

Each T delay correspond to 21 pulses on a 38KHz signal, this is
then a variable lenght encoding

As I was making progresses on the recognition of the patterns sent
by the aircon I was modifying the program to give a more synthetic view
of the resulting received frames, you can use my own
IRanalyzer.ino
it is exended to allow recording of a variable number of transition,
detects the start transition as a 3-4 ms up, and the end as a 3-4 ms
down from the emitter, then show the transmitted data as bit field and
hexadecimal bytes:

Waiting...

Bit stream detected: 102 transitions

D U 1011 0010 0100 1101 1001 1111 0110 0000 1011 0000 0100 1111 dUD Bit stream end : B2 4D 9F 60 B0 4F !

4484 4324 608 1572 604 472 596 1580 600 1580  !

Waiting...

So basically what we find here:

• the frame start markers 4T down, 4T up
• 6 Bytes of payload, this is actually 3 bytes of data but after
  each byte is sent its complement is sent too
• the end of the frame consist of 1T down, 4T up and then 4T down

there is a few interesting things to note about this encoding:

• It is redundant allowing to detect errors or stray data coming from
  other 38KHz remotes (which are really common !)
• All frames are actually sent a second time just after the first one,
  so the amount of redundancy is around 4 to 1 in the end !
• by reemitting inverted values, the anmount of 0 and 1 sent is the
  same, as a result a frame always have a constant duration even if the
  encoding uses variable lenght
• A double frame duration is around : 2 * (8 + 8 + 3*2*8 + 3*4*8 + 1 + 8) * 21 / 38000 ~= 186 ms

The protocol decoding

Once the frame is being decoded properly, we are down to analyzing
only 3 bytes of input per command. So I started pressing the buttons
in various ways and record the emitted sequences:

Cool 24 fan level 3

1011 0010 0100 1101 0011 1111 1100 0000 0100 0000 1011 1111  B2 4D 3F C0 40 BF

Cool 24 fan level 1

1011 0010 0100 1101 1001 1111 0110 0000 0100 0000 1011 1111  B2 4D 9F 60 40 BF

Cool 20 fan level 1

1011 0010 0100 1101 1001 1111 0110 0000 0010 0000 1101 1111  B2 4D 9F 60 20 DF

Cool 19 fan level 1

1011 0010 0100 1101 1001 1111 0110 0000 0011 0000 1100 1111  B2 4D 9F 60 30 CF

Heat  18 fan level 1

1011 0010 0100 1101 1001 1111 0110 0000 0001 1100 1110 0011  B2 4D 9F 60 1C E3

Heat  17 fan level 1

1011 0010 0100 1101 1001 1111 0110 0000 0000 1100 1111 0011  B2 4D 9F 60 0C F3

Heat  29 fan level 1

1011 0010 0100 1101 1001 1111 0110 0000 1010 1100 0101 0011  B2 4D 9F 60 AC 53

Heat  30 fan level 1

1011 0010 0100 1101 1001 1111 0110 0000 1011 1100 0100 0011  B2 4D 9F 60 BC 43

Stop Heat  30 fan level 1

1011 0010 0100 1101 0111 1011 1000 0100 1110 0000 0001 1111  B2 4D 7B 84 E0 1F

Cool 28 fan 1

1011 0010 0100 1101 1001 1111 0110 0000 1000 0000 0111 1111  B2 4D 9F 60 80 7F

Stop Cool 28 fan 1

1011 0010 0100 1101 0111 1011 1000 0100 1110 0000 0001 1111  B2 4D 7B 84 E0 1F

The immediately obvious information is that the first byte is the constant
0xB2 as noted by Tom's Site. Another thing one can guess is that the command
drom the control is (in general) absolute, not relative to the current state
of the AC, so commands are idempotent,if it failed to catch one key, it will
get a correct state if this is repeated, this just makes sense from an UI
point of view ! After a bit of analysis and further testing the
code for the 3 bytes seems to be:

[1011 0010] [ffff 1111] [ttttcccc]

Where tttt == temperature in Celcius encoded as following:

17: 0000, 18: 0001, 19: 0011, 20: 0010, 21: 0110,

22: 0111, 23: 0101, 24: 0100, 25: 1100, 26: 1101,

27: 1001, 28: 1000, 29: 1010, 30: 1011, off: 1110

I fail to see any logic in the encoding there, I dunno what the Midea
guys were thinking when picking those values. What sucks is that the protocol
seems to have a hardcoded range 17-30, while basically for the orchids
I try to keep in the range 15-35, i.e. I will have to play with the
sensors output to do the detection. Moreover my test is that even when
asked to keep warm at 17, the AC will continue to heat until well above
19C, I can't trust it to be accurate, best is to keep the control and logic
on our side !

cccc == command, 0000 to cool, 1100 to heat, 1000 for automatic selection
and 1101 for the mode to remove moisture

Lastly ffff seems to be the fan control, 1001 for low speed, 0101 for
medium speed, 0011 for high speed, 1011 automatic, and 1110 for off. There
is also a mode which is about minimizing energy, useful at night, where
the fan is quite slower than even the low speed, but i didn't yet understood
how that actually work.

There is still 4 bytes left undeciphered, they could be related to 2
function that I don't use: a timer and oscilation of the air flow, I
didn't try to dig, especially with a remote control and documentation
in Chinese !

Last but not least: the stop command is 0xB2 0x7B 0xE0, it's the same
whatever the current state might be.

At this point I was relatively confident I would be able to control the
AC from an Arduino, using a relatively simple IR LED control, it ought to
be a "simple matter of programming", right ?

Well, that will be the topic of the next part ;-) !

This entry will be kept at http://veillard.com/embedded/midea.html.

At openSUSE Conference in Prague last month, we had a BoF about Secure Boot, where I describe the various tasks which are needed to ensure openSUSE can support Secure Boot. They are listed on my slides, but I thought it would be more useful to describe them here.

Before we begin, if you need some refresh about Secure Boot, I suggest the blog posts from Olaf Kirch and Vojtěch Pavlík on SUSE Blog (overview, details and approach to it) and of course, all the war stories of Matthew Garrett on this topic ;)

To have openSUSE installable (and runnable) on a Secure Boot enabled system, without any additional user intervention (like adding your own key in UEFI firmware or disabling Secure Boot), we need to do the following to the distribution :

• to the kernel (many of those features are in 3.7 or in upcoming 3.8):

• convert the kernel as a EFI executable (it will be used to store kernel signature)
• UEFI variable access
• UEFI clock support (nice to have)
• UEFI getvideomode (if we want flicker-free boot)
• UEFI reboot (we already have 4 other way to reboot a system, why not add yet another one ;)
• KMS drivers (for old chipsets like Matrox, AST).
• sign main kernel
• sign all in-tree kernel modules
• generate a private/public key pair to be used out of tree modules
• add Secure Boot support in KExec / KDump and Xen (optional)
• disable hibernation in Secure Boot mode (or have a secure way to save / restore suspended system)
• add signature check in kernel
• to bootloader:
• package shim loader
• modify grub2 so it uses shim loader to check kernel signature at boot
• to Build Service:
• to be able to build external kernel modules (think KMP) using the private/public key generated at kernel build
• but do not allow this key to be used for any random KMP build (otherwise, you defeat the purpose of signing the module)
• to userspace tools:
• package xf86-video-modesettings, for graphics chipset with non-accelerated KMS drivers
• add support for signature check in modutils / kmod
• package tools to sign kernel / modules
• package tools to manage UEFI variables and keys
• to the installer / DVD image
• maybe display some warnings about installing a system in Secure Boot mode (not 100% sure we should do this)
• maybe signing the initial installer (and make sure it can't load non-signed modules)
• ensure the DVD image has shim + grub2 as bootloader when booting on UEFI system
• and we also need to do the signing part:
• if we want Secure Boot to be transparent to users, we need our shim loader to be signed by the authority handling UEFI key, ie Microsoft
• this requires some legal paperwork (getting MS developer account, getting a Authenticode certificate, etc..), some obligation (making sure you can't circumvent Secure Boot once Linux is booted) and once it is done, sending shim loader to be signed by MS and package the result.

As you can see, this is a lot of work but I think we will be able to have everything in order for next openSUSE release !

For quite some time the access to recent files has been put forward in GNOME, it happened even more so in 3.6 with a "Recent Files" view in Files (née Nautilus), that makes use of a new recent files backend in gvfs.

This is all very nice but my daily activities still involve a lot of command line usage, and I didn't find any way to mark as recents the files I receive via mutt, the text files I create in vim, the pictures I resize with ImageMagick, etc. That always bothered me at the moment I wanted to access those files, but then I just copied a copy of the file to a scratch directory I had bookmarked, and went on with my work.

Until yesterday, as I finally decided to fix that, and quickly put together recent, a command line utility that just puts the file it gets as argument in the recent files list. It's very simple, uses GFile and GtkRecentManager, and the code is located there: recent.c. It's so simple I guess many others wrote something similar, but here you have, perhaps it will be useful.

Next week GNOME 3.6 will be released upon the world. That's the perfect excuse to meet the day after the release (Thursday 27th) and share some beers together. All the infos are on the wiki.

Mark his words and laugh in two years.

That’s a new milestone in my life, I’m father again and now it’s a girl; Her name is Soline, she is birth on May 29rth. Mother and daughter are okay.

…No release since October 2011, not a lot of commits since last 7 months, and the main maintainer, Alvaro Lopez Ortega got hired by Canonical.
Too bad, I guess it’s time to play with another webserver.

If you expect 'Alt + d' wil only remove the first part 'foo_' of 'foo_bar' with the great python-mode, you can make this change to python-mode.el:

- (modify-syntax-entry ?\_ "w" py-mode-syntax-table)
+ (modify-syntax-entry ?\_ "_" py-mode-syntax-table)


Thank you Ivan.

Update with python-mode v6.0.4, add this line to python-mode-syntax-table (line 153):

(modify-syntax-entry ?\_ "_" table)


Bientôt 2 ans après avoir exprimé ma volonté de créer une extension pour Nautilus afin de pouvoir lancer un découpage ou un assemblage avec GNOME Split, cette extension est enfin arrivée.

Le but de l'extension est de proposer deux nouvelles entrées dans le menu contextuel de Nautilus. Lors d'un clic droit sur un fichier quelconque l'item "Découper le fichier..." apparaît, l'utiliser permet de lancer GNOME Split avec les arguments qui vont biens pour découper le fichier sélectionné. Lors d'un clic droit sur un fichier étant considéré comme la première partie d'un fichier qui a été découpé auparavant, l'entrée "Assembler les fichiers..." apparaît permettant de lancer GNOME Split pour assembler les parties.


Concrètement, cette extension de Nautilus est codée en C, publiée sous GPL version 3 et déjà présente dans le PPA pour la version 11.10 d'Ubuntu.

    ~$ sudo add-apt-repository ppa:gnome-split-team/ppa
    ~$ sudo aptitude update
    ~$ sudo aptitude install nautilus-gnome-split

N'étant pas expert en développement d'extensions pour Nautilus toute aide est la bienvenue.
En espérant que cette extension soit utile.

I arrived in Belgium yesterday.

I'm glad to see people that were at DebConf in Bosnia and Herzgovina. I'll try to assistat many conferences about Java, Debian, GNOME and more if I can. I will also participate to the LibreDinner tomorrow.

Well, see you at FOSDEM 2012!

FOSDEM 2012

My last FOSDEM participation was in 2004, and I always keep in mind many good moments with my French and Belgian GNOME's Friends !

Archives

So I'm totally excited to meet them again in 2012 ... :)

The GNOME Montréal Summit was held a month ago now, and not only was it lots of fun, but also a very productive time. Marina held a session about the outreach in GNOME, and we spent time discussing different ways to improve welcoming and attracting people in GNOME. Let me share some of the points we raised, supplemented by my own personnal opinions, that do not reflect those of my employer, when I’ll have a job.

A warm welcome

There has been a lot of nice work done structuring and cleaning up GNOME Love page. We now have a list of people newcomers can contact if they are interested in a particular project. Feel free to add your name and project to the list, the more entry points we get, the better for them!

I tend to think there is still a bit too much content on the GNOME Love page, maybe we could use more pretty diagrams (platform overview, ways to get involved) to keep the excitement growing and to reduce the amount of text we have right now (GUI tutorials, books about GNOME,  tips & tricks). Feedback appreciated!

Start small

We tend to think of contributions as patches and a certain amount of code added in a project. Howeverit’s not easy at all for newcomers to just pop in and work on a patch, especially in GNOME where most software follows strict rules (as in coding style, GObject API style, etc.). And since GNOME maintains (again, for the most part) a very high quality in its code backed by many hackers, whether they’re part of a company or independent contributors, it makes the landing of a patch even tougher.

Which is why we should encourage everyone who wants to get involved to work on small tasks, would it be fixing a string typo, rewording or marking plural forms for translation. Working on manageable changes ensures that the patches are completed and landing these patches builds confidence to work on bigger patches. Having your name in the commit log is a great reward, that encourages sticking around and digging for more.

Advertise early, advertise often

If we want to get loads of people coming toward GNOME, we should definitely talk more and spread the word about the GNOME Outreach Program for Women (GOPW) and the Google Summer of Code (GSoC) earlier.

Google doesn’t announce the program very far in advance and approved organizations are only published three weeks before the application deadline, but we should encourage students to get involved in GNOME early and keep an eye out for such announcements. Having a list of mentors who can help newcomers anytime throughout the year and having that list included on the Google Summer of Code wiki page of organizations that provide year-round informal mentorship should help attract students to GNOME.

On our side, we could definitely gather ideas and promote the programs earlier. Don’t have exact dates in head, but our KDE fellows promote the Summer of Code early March if not before. Not only will that help better spreading the word, but students might get involved earlier, and get to know the tools/community before the actual program.

Communication is key to success

We have to get better at communicating with interns, and make sure they get the help and feedback they need. We have different channels of communication in GNOME, mainly IRC and mailing lists. Both are a bit intimidating to the newcomer (I still proceed with extreme care when I use them), so it would be good to have a short tutorial about the main mailing lists around, how to connect on IRC and what to expect out of it.

Always two there are, no more, no less

In order to increase the chances of success for the interns, we need good mentors. Most people underestimate what it takes to be a good mentor: being nice, supportive, competent, enthusiastic. You have to remember you’re helping someone to land in the big GNOME land without too much hassle, so consider it carefully. I encourage you to read this very informative blog post if you’re thinking about mentoring a student.

The Summer of Code administrators at GNOME could perhaps keep an eye on mentors as well as students, not with weekly reports but just by poking them from time to time and making sure everything is going well.

Show me the way

To help students set up their workflow, it would be great to have full-length screen-casts demonstrating how to fix a bug in GNOME, starting on the Bugzilla page and finishing on the same page when attaching the final patch. This means going through cloning the module with Git, using grep to find the faulty line, editing the code, using Git to look at the diff and format the final patch. All this in one video would really help connect the parts and suggest a way to work for students.

GNOME Love bug drive

Please consider attaching the gnome-love keyword when you file or triage a bug that is easy to fix. A selection of current GNOME Love bugs is essential to help newcomers figure out how they can start contributing.

Good GNOME Love bugs are trivial or straight forward bugs that everyone agrees on, e.g. paper cut bugs or corner cases. It’s helpful to specify the file or files that will need to be modified and any reference code that does something similar in the bug. Even most trivial bugs are suitable candidates, because in the end, fixing a GNOME Love bug is as much about learning the process, as about the fix itself!

Get involved

If you want to help us gather more people around GNOME and help them find their spot in our community, make sure to suscribe to the outreach-list mailing list.

Thanks for reading!

And thanks to Marina and Karen for reviewing this post!

Due to unintentional behavior breakage in the newest versions of GUPnP and GSSDP, the UPnP NAT traversal in all VoIP applications that use Farsight2 is currently broken. This includes Empathy, Pidgin, aMSN, etc. I advise distributors to just stay with the older GUPnP 0.16 (and GSSDP 0.10) releases until this is sorted out. For those who care, the details are on bugzilla.

Update: I’ve released GUPnP-IGD 0.2.1 that works around these problems.

After 5 months with GNOME 3.0, I'm really happy with the experience. At the end of work day,
my mind is no more exhausted of windows placement fighting and application finding.

GNOME 3.0 is really stable, except with the Open Source driver on my Radeon 5870 (4 crashes in 2 months).

I really like the behavior of dual-head where the secondary screen has only one virtual screen.
For me, there are just 3 annoying points:

• Ctrl + Del to remove a file in Nautilus, may be it's a Fedora settings but this change is just @!# I've already a Trash to undo my mistakes (http://www.khattam.info/howto-enable-delete-key-in-nautilus-3-fedora-15-2011-06-01.html)
• Alt key to shutdown, no I don't want to waste energy for days and my PC boots quickly.
• only vertical virtual screens, I found a bit painful to move down two screens when the screen is reachable with one move with a 2x2 layout but I understand this layout doesn't fit well with the GNOME 3 design.

To have a good experience with GNOME 3, I use:

• Windows key + type to launch everything
• Ctrl + Shift + Alt + arrows to move the application between the virtual screen
• Ctrl + click in the launcher when I really want a new instance (the default behavior is perfect)
• snap à la Windows 7 is great
• Alt + Tab then the arrow keys to select an app

Don't forget to read https://live.gnome.org/GnomeShell/CheatSheet or the Help (System key + 'Help').

It's not specific to GNOME 3 but you can change the volume when your mouse is over the applet (don't click, think hover) and a mouse scroll.
With GTK+, do you know you can reach the end of scrolled area with a left click on the arrow and a specific position by middle click?

I'm impressed by the new features of GNOME 3.2 and I'm waiting for Fedora 17 to enjoy it!

In case you are in the Paris area and don't know already, there is a a GNU Hackers Meeting event being held from Thursday 25th to Sunday 28th August, 2011 at IRILL If you are a GNU user, enthusiast, or contributor of any kind, feel free to come. I guess you can still drop an email to ghm-registration@gnu.org.

For folks around on Wednesday (yeah, that's tomorrow), we are having a dinner around 8 PM at the Mussuwam, a Senegalese restaurant in Paris, near Place d'Italie. When you get there, just give them the secret password (which is 'GNU') and they'll show you were the rest of the crowd sits. Be sure to keep that password secret though. No one else should be in the know.

Happy hacking and I hope to see you guys there.

This is just as a reminder for myself, as I keep forgetting about this stuff.

If like me you run a server with services that depends on SSL and need to install a certificate issued by a Certificate Authority (CA) like CACert, this might be interesting to you as well.

On Red Hat based systems the CA certificate for SSL is usually installed in the /etc/pki/tls/certs directory. The certificate is basically just dropped there in a file which name is its hash – built with the openssl program.

I wrote the shell scriptlet http://dodji.seketeli.net/install-ca-cert.txt. Download it, save it as install-ca-cert.sh and turn it into an executable.

Then, assuming your certificate is in a file named your-ca.crt, install it by doing:

sudo ./install-ca-cert.sh ./your-ca.crt

Voila. I don't know how that works on other distributions, though.

Update

A wise person taught me about the c_rehash utility from openssl, that does the same thing as my dirty script above. To use it, you need to install the openssl-perl package. Thank you, Daniël.

Next week, I’ll head to Strasbourg for Rencontres Mondiales du Logiciel Libre 2011. On monday morning, I’ll be giving my Debian Packaging Tutorial for the second time. Let’s hope it goes well and I can recruit some future DDs!

Then, at the end of July, I’ll attend Debconf again. Unfortunately, I won’t be able to participate in Debcamp this year, but I look forward to a full week of talks and exciting discussions. There, I’ll be chairing two sessions about Ruby in Debian and Quality Assurance.

It’s been a long time since I blogged about Libgda (and for the matter since I blogged at all!). Here is a quick outline on what has been going on regarding Libgda for the past few months:

• Libgda’s latest version is now 4.2.4
• many bugs have been corrected and it’s now very stable
• the documentation is now faily exhaustive and includes a lot of examples
• a GTK3 branch is maintained, it contains all the modifications to make Libgda work in the GTK3 environment
• the GdaBrowser and GdaSql tools have had a lot of work and are now both mature and stable
• using the NSIS tool, I’ve made available a new Windows installer for the GdaBrowser and associated tools, available at http://www.gnome.org/~vivien/GdaBrowserSetup.exe. It’s only available in English and French, please test it and report any error.

In the next months, I’ll work on polishing even more the GdaBrowser tool which I use on a daily basis (and of course correct bugs).

I have been toying with webkit lately, and even managed to do some pretty things with it. As a consequence, I haven’t worked that much on ekiga, but perhaps some of my experiments will turn into something interesting there. I have an experimental branch with a less than fifty lines patch… I’m still trying to find a way to do more with less code : I want to do as little GObject-inheritance as possible!

That little programming was done while studying class field theory, which is pretty nice on the high-level principles and somewhat awful on the more technical aspects. I also read again some old articles on modular forms, but I can’t say that was “studying” : since it was one of the main objects of my Ph.D, that came back pretty smoothly…

I found a few minutes to enter a brick-and-mortar shop and have a look at the ebook readers on display. There was only *one* of them : the sony PRS-600. I was pretty unimpressed : the display was too dark (because it was a touch screen?), but that wasn’t the worse deal breaker. I inserted an SD card where I had put a sample of the type of documents I read : they showed up as a flat list (pain #1), and not all of them (no djvu) (pain #2) and finally, one of them showed up too small… and ended up fully unreadable when I tried to zoom (pain #3). I guess that settles the question I had on whether my next techno-tool would be a netbook or an ebook reader… That probably means I’ll look more seriously into fixing the last bug I reported on evince (internal bookmarks in documents).

Bonjour à tous,

je vous délaisse depuis quelques temps. Est-ce le temps qui fait cela, une période dans ma vie ou simplement autre chose, je n'en ai pas la moindre idée.

Je tenais juste à vous annoncer que je vais quitter mon employeur actuel qui est un Agence Gouvernementale pour chercher de l'expérience dans le secteur privé. En effet, je suis de plus en plus déçu par l'Administration.

Depuis quelques années, comme vous le savez, je me passionne pour la sécurité de l'Information. Ceci ajouté à une formation en Management de la Sécurité de l'Information, j'ai l'ambition de faire valoir mes expériences auprès d'un employeur (à définir) qui pourrait me permettre de les améliorer tout en lui faisant bénéficier de mes compétences.

Si vous avez de bonnes adresses, je suis preneur évidemment. ^^

With the beginning of the year comes new releases of Libgda:

• version 4.0.6 which contains corrections for the stable branch
• version 4.1.4, a beta version for the upcoming 4.2 version

The 4.1.4′s API is now considered stable and except for minor corrections should not be modified anymore.

This new version also includes a new database adaptator (provider) to connect to databases through a web server (which of course needs to be configured for that purpose) as illustrated by the followin diagram:

The database being accessed by the web server can be any type supported by the PEAR::MDB2 module.

The GdaBrowser application now supports defining presentation preferences for each table’s column, which are used when data from a table’s column need to be displayed:

The UI extension now supports improved custom layout, described through a simple XML syntax, as shown in the following screenshot of the gdaui-demo-4.0 program:

For more information, please visit the http://www.gnome-db.org web site.

For the third year in a row, I’ll be flying to Brussels, Belgium next month to attend the XMPP Summit/FOSDEM combo. I didn’t look through the FOSDEM schedule yet but when it comes to XMPP, I’m looking forward to some discussions on Jingle Nodes and Publish-Subscribe. I’ve been working more and more with XMPP in the past months, especially hacking on ejabberd, and attending is a good motivation to get some of my Jingle Nodes related code shaped up on time. See you there!

Le hacker est un passionné d'informatique, souvent très doué, dont les seuls objectifs sont de "bricoler" programmes et matériels (software et hardware) afin d'obtenir des résultats de qualité pour lui-même, pour l'évolution des technologies et pour la reconnaissance de ses pairs.

Les conventions de hackers sont des rassemblements où ces férus d'informatique se rencontrent, discutent et comparent leurs travaux.

Depuis de nombreuses années, la tendance est de confondre à tort le hacker avec le cracker, dont les buts ne sont pas toujours légaux.

Or, on ne le répétera jamais assez, les objectifs du hacker sont louables et contribuent de manière active aux progrès informatiques et aux outils que nous utilisons quotidiennement.

I have been a little stuck for some weeks : a new year started (no, that post hasn’t been stuck since january — scholar year start in september) and I have students to tend to. As I have the habit to say : good students bring work because you have to push them high, and bad students bring work because you have to push them from low! Either way, it has been keeping me pretty busy.

Still, I found the time to read some more maths, but got lost on something quite unrelated to my main objective : I just read about number theory and the ideas behind the proof of Fermat’s Last Theorem (Taylor and Wiles’ theorem now). That was supposed to be my second target! Oh, well, I’ll just try to hit my first target now (Deligne’s proof of the Weil conjectures). And then go back to FLT for a new and deeper reading.

I only played a little with ekiga’s code — mostly removing dead code. Not much : low motivation.

I just released the first version of gwt-strophe, GWT bindings for the Strophe XMPP library. Nothing much to say else than it is pretty young, with all that can imply. The project is hosted at https://launchpad.net/gwt-strophe

So, I’m back from the Rencontres Mondiales du Logiciel Libre, which took place in Nantes this year. It was great to see all those people from the french Free Software community again, and I look forward to seeing them again next year in Bordeaux (too bad the Toulouse bid wasn’t chosen).

The Debian booth, mainly organized by Xavier Oswald and Aurélien Couderc, with help from Raphaël, Roland and others (but not me!), got a lot of visits, and Debian’s popularity is high in the community (probably because RMLL is mostly for über-geeks, and Debian’s market share is still very high in this sub-community).

I spent quite a lot of time with the Ubuntu-FR crew, which I hadn’t met before. They do an awesome work on getting new people to use Linux (providing great docs and support), and do very well (much better than in the past) at giving a good global picture of the Free Software world (Linux != Ubuntu, other projects do exist and play a very large role in Ubuntu’s success, etc). It’s great to see Free Software’s promotion in France being in such good hands. (Full disclosure: I got a free mug (recycled plastic) with my Ubuntu-FR T-shirt, which might affect my judgement).

I gave two talks, on two topics I wanted to talk about for some time. First one was about the interactions between users, distributions and upstream projects, with a focus on Ubuntu’s development model and relationships with Debian and upstream projects. Second one was about voting methods, and Condorcet in particular. If you attended one of those talks, feedback (good or bad) is welcomed (either in comments or by mail). Slides are also available (in french):

• L’écosystème du Libre: interactions entre projets amonts, distributions et utilisateurs – l’exemple de Debian et Ubuntu
• Méthodes de vote: Comment consulter un groupe de personnes sans fausser le résultat ?

On a more general note, I still don’t understand why the “Mondiales” in RMLL’s title isn’t being dropped or replaced by “Francophones“. Seeing the organization congratulate themselves because 30% of the talks were in english was quite funny, since in most cases, the english part of the talk was “Is there someone not understanding french? no? OK, let’s go on in french.“, and all the announcements were made in french only. Seriously, RMLL is a great (probably the best) french-speaking community event. But it’s not FOSDEM: different goals, different people. Instead of trying (and failing) to make it an international event, it would be much better to focus on making it a better french-speaking event, for example by getting more french-speaking developers to come and talk (you see at least 5 times more french-speaking developers in FOSDEM than in RMLL).

I’m now back in Lyon for two days, before leaving to Montreal Linux Symposium, then coming back to Lyon for three days, then Debconf from 23rd to 31st, and then moving to Nancy, where I will start as an assistant professor in september (a permanent (tenured) position).

Dear Lennart,

You should probably know that typing the correct URL would work better for cloning a bzr branch (yes a branch, not a repository).

This is what I get when I try to feed git a random invalid URL:

$ git clone git://github.com/idontexist
Initialized empty Git repository in /home/asabil/Desktop/idontexist/.git/
fatal: protocol error: expected sha/ref, got ‘
*********’

No matching repositories found.

*********’

Now is probably the time to stop this non constructive “my DVCS is better than yours”, and focus on writing code and fixing bugs.

On September I finish my studies of computer science, so I start to search a job. I really enjoyed my current job at Collabora maintaining Empathy, I learned lots of things about the Free Software world and I would like to keep working on free software related projects if possible. My CV is available online here.

Do you guys know any company around the free software and GNOME looking for new employees? You can contact me by email to xclaesse@gmail.com

On peut, au regard des concepts développés par Slavoj Zizek dans "La Parallaxe", tenter une nouvelle interprétation, plus fondamentale, des aventures de Suzumiya Haruhi.

La mélancolie de Suzumiya Haruhi est due au sentiment de malaise créé par l'incomplétude fondamentale qui nous caractérise tous. Haruhi part donc à la recherche du grand Autre, réponse censée venir combler ce vide, ici fétichisé dans les extra-terrestres, extra-lucides et voyageurs dans le temps. Ce comportement peut être vu comme semblable à ceux des individus cherchant la réponse à leur malaise constitutif dans la religion, voir, et nous y reviendrons, dans la philosophie et la politique.

Cependant, la réalité du monde de Haruhi est qu'il n'existe pas de grand Autre, aucun extra-ordinaire comblant les vides ennuyeux de la réalité, aucun personnage tirant les ficelles dans l'ombre. Ou plutôt, de façon plus importante, que ce grand Autre est Haruhi elle-même, ce qui constitue la réponse fondamentale : c'est bien elle-même qu'elle cherche en voulant résoudre cette incomplétude.

Selon ces hypothèses, le récit de ses aventures peut donc ultimement être vu comme celui de la recherche de la Vérité par les humains, les réflexions autour de son comportement précisant de façon très intéressantes plusieurs problématiques liées à ce processus.

L'interprétation de la fin de la série, où Haruhi semble trouver son bonheur avec Kyon, reste toujours problématique. Il n'existe pas de grand Autre, le manque ne peut donc pas être réellement comblé par quelque chose d'extérieur, donc pas par quelque chose qui soit matérialisé dans un fétiche, même humain, comme Kyon. Cependant Kyon n'est pas non plus quelque chose d'extérieur, puisqu'il est, comme tous les objets du monde de Haruhi, un produit de son imagination. Il s'agirait donc d'une pure matérialisation à figure humaine de la véritable réponse à son manque, ce qui ferait de Kyon une partie de Haruhi et non un personnage distinct. On peut donc avec un peu d'audace avancer que Kyon et Haruhi ne sont qu'un, qu'il est réellement sa moitié, ce qui n'est pas sans rappeler tout en lui redonnant une piquante nouvelle perspective le "happy end" chrétien par excellence. Malgré tout, le fait que Haruhi ne le reconnaisse pas comme tel, puisqu'ils sont clairement toujours deux personnes distinctes, laisse supposer que le problème n'est pas réglé.

On ne reconnaît habituellement qu'une religion pose problème que lorsqu'elle constitue un risque potentiel pour le système capitaliste libéral dans lequel nous vivons. De fait, ces religions ont donc on potentiel subversif.

C'est à cause de celui-ci que les nombreux individus touchés de plein fouet par le malaise créé par cette société se tournent en nombre de plus en plus important vers ce type de communautés religieuses.

Or, qu'est-ce que le processus de laïcisation tel que nous l'entendons dans la bouche des libéraux, sinon le fait de rendre les religions aptes à rentrer dans le cadre libéral, ou, à défaut, de marginaliser et stigmatiser celles qui ne le feraient pas, leur retirant ainsi tout aspect nocif pour lui ?

Ce processus peut donc être vu comme la condition sine qua non du fonctionnement de l'opium du peuple comme instrument des puissances qui font l'ordre social, même si la résurgence des intégrismes en période de crise nous montre qu'il est de toute façon voué à l'échec.

L'attitude ambivalente de la laïcité promue par la droite, qui dit oui à, voir encourage, la croyance qui se veut inconditionnelle, et simultanément y porte des restrictions, reflète d'ailleurs cette contradiction.

Pour illustrer ceci, on peut prendre l'exemple des lois interdisant à la religion tout caractère visible en public, par lesquelles on leur enlève tout caractère choquant pour ceux qui n'y prennent pas part, tout en ne faisant rien contre leur effet idéologique sur les populations concernées.

La gauche radicale n'a donc aucun intérêt à aider l'ordre libéral à se maintenir en normalisant la religion pour l'intégrer, puis se renforcer, par cette laïcité.

Ce qu'elle devrait favoriser, c'est la prise de conscience par la classe dominée du fait que son malaise est dû à la structure de la société et que le seul moyen d'y remédier est la lutte politique permettant de le dépasser. Par conséquent, la seule laïcité qu'il ait un sens pour elle de défendre est celle qui permette l'émancipation de chacun, pour parvenir à ce fait.

Enterprise Social Search is a way to search, manage, and share information within a company. Who can help you find relevant information and nothing but relevant information? Your colleagues, of course

Today we are launching at Whatever (the company I work for) a marketing campaign for our upcoming product: Knowledge Plaza. Exciting times ahead!

There was some blog entries this week about GNOME stable updates on Ubuntu. There is no reason new bug fix versions could not be uploaded to stable out of the fact that the SRU rules require to check carrefully all the changes and doing this job on all the GNOME tarballs is quite some work, or the ubuntu desktop team is quite small and already overworked.

There is a list of packages which have a relaxed rules though, we have discussed adding GNOME to those since the stable serie usually has fixes worth having and not too many unstable changes (though the stable SVN code usually doesn’t get lot of testing) and decided than the stable updates which look reasonable should be uploaded to hardy-update.

There was also some concerns about gnome-games, 2.20.3 has been uploaded to gutsy-proposed today which should reduce the number of bugs sent to the GNOME bugzilla. The new dependencies on ggz has also been reviewed and 2.21 should be built soon in hardy.

The FOSSCamp and UDS week has been nice and a good occasion to talk to upstream and people from other distributions. We had desktop discussions about the new technologies landing in GNOME this cycle (the next Ubuntu will be a LTS so we need a balance between new features and stability), the desktop changes we want to do, and how Ubuntu contributes to GNOME.

Some random notes about the Ubuntu upstream contributions:

• Vincent asked again for an easy way to browse the Ubuntu patches and Scott picked up the task, the result is available there
• The new Canonical Desktop Team will focus on making the user experience better, most of the changes will likely be upstream material and discussed there, etc
• Canonical has open Ubuntu Desktop Infrastructure Developer and Ubuntu Conceptual Interface Designer positions, if you want to do desktop work for a cool open source company you might be interested by those

GNOME updates in gutsy and hardy

• Selected GNOME 2.20.1 changes have been uploaded to gutsy-updates
• The GNOME 2.21.2 packaging has started in hardy, some updates and lot of Debian merges are still on the TODO though
• We have decided to use tags in patches to indicate the corresponding Ubuntu and upstream bugs so it’s easier to get the context of the change, technical details still need to be discussed though

Update: Scott pointed that you can use http://patches.ubuntu.com/n/nautilus/extracted to access to the current nautilus version

I’ve been working wit git lately but I have also missed the darcs user interface. I honestly think the darcs user interface is the best I’ve ever seen, it’s such a joy to record/push/pull (when darcs doesn’t eat your cpu)

I looked at git add --interactive because it had hunk-based commit, a pre-requisite for darcs record-style commit, but it has a terrible user interface, so i just copied the concept: running a git diff, filtering hunks, and then outputing the filtered diff through git apply --cached.

It supports binary diffs, file additions and removal. It also asks for new files to be added even if this is not exactly how darcs behave but I always forget to add new files, so I added it. It will probably break on some extreme corner cases I haven’t been confronted to, but I gladly accept any patches

Here’s a sample session of git-darcs-record script:

$ git-darcs-record
Add file:  newfile.txt
Shall I add this file? (1/1) [Ynda] : y

Binary file changed: document.pdf

Shall I record this change? (1/7) [Ynda] : y

foobar.txt
@@ -1,3 +1,5 @@
 line1
 line2
+line3
 line4
+line5

Shall I record this change? (2/7) [Ynda] : y

git-darcs-record
@@ -1,17 +1,5 @@
 #!/usr/bin/env python

-# git-darcs-record, emulate "darcs record" interface on top of a git repository
-#
-# Usage:
-# git-darcs-record first asks for any new file (previously
-#    untracked) to be added to the index.
-# git-darcs-record then asks for each hunk to be recorded in
-#    the next commit. File deletion and binary blobs are supported
-# git-darcs-record finally asks for a small commit message and
-#    executes the 'git commit' command with the newly created
-#    changeset in the index
-
-
 # Copyright (C) 2007 Raphaël Slinckx
 #
 # This program is free software; you can redistribute it and/or

Shall I record this change? (3/7) [Ynda] : y

git-darcs-record
@@ -28,6 +16,19 @@
 # along with this program; if not, write to the Free Software
 # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.

+# git-darcs-record, emulate "darcs record" interface on top of a git repository
+#
+# Usage:
+# git-darcs-record first asks for any new file (previously
+#    untracked) to be added to the index.
+# git-darcs-record then asks for each hunk to be recorded in
+#    the next commit. File deletion and binary blobs are supported
+# git-darcs-record finally asks for a small commit message and
+#    executes the 'git commit' command with the newly created
+#    changeset in the index
+
+
+
 import re, pprint, sys, os

 BINARY = re.compile("GIT binary patch")

Shall I record this change? (4/7) [Ynda] : n

git-darcs-record
@@ -151,16 +152,6 @@ def read_answer(question, allowed_responses=["Y", "n", "d", "a"]):
        return resp

-def setup_git_dir():
-       global GIT_DIR
-       GIT_DIR = os.getcwd()
-       while not os.path.exists(os.path.join(GIT_DIR, ".git")):
-               GIT_DIR = os.path.dirname(GIT_DIR)
-               if GIT_DIR == "/":
-                       return False
-       os.chdir(GIT_DIR)
-       return True
-
 def git_get_untracked_files():

Shall I record this change? (5/7) [Ynda] : y

# On branch master
# Changes to be committed:
#   (use "git reset HEAD file..." to unstage)
#
#       modified:   document.pdf
#       modified:   foobar.txt
#       modified:   git-darcs-record
#       new file:   newfile.txt
#
# Changed but not updated:
#   (use "git add file file..." to update what will be committed)
#
#       modified:   git-darcs-record
#
What is the patch name? Some cute patch name
Created commit a08f34e: Some cute patch name
 4 files changed, 3 insertions(+), 29 deletions(-)
 create mode 100644 newfile.txt

Get the script here: git-darcs-record script and put in somewhere in your $PATH. Any comments or improvements is welcome !

Voilà, j’y pensais depuis longtemps et c’est maintenant chose faite, je me suis acheté un tout nouveau ordinateur portable.

Je l’ai acheté sur le site français LDLC.com et me suis renseigné pour savoir si il était possible d’acheter les ordinateurs de leur catalogue sans logiciels (principalement sans windows). Je leur ai donc envoyé un email, et à ma grande surprise ils m’on répondu que c’était tout a fait possible, qu’il suffi de passer commande et d’envoyer ensuite un email pour demander de supprimer les logiciels de la commande. J’ai donc commandé mon laptop et ils m’ont remboursé de 20€ pour les logiciels, ce n’est pas énorme sur le prix d’un portable, mais symboliquement c’est déjà ça.

Toutes fois je me pose des questions, pourquoi cette offre n’est pas inscrite sur le site de LDLC ? En regardant sous mon tout nouveau portable je remarque une chose étrange, les restes d’un autocollant qu’on a enlevé, exactement à l’endroit où habituellement est collé la clef d’activation de winXP. Le remboursement de 20€ tout rond par LDLC me semble également étrange vue que LDLC n’est qu’un intermédiaire, pas un constructeur, et donc eux achètent les ordinateurs avec windows déjà installé. Bref tout ceci me pousse à croire que c’est LDLC qui perd les 20€ et je me demande dans quel but ?!? Pour faire plaisir aux clients libre-istes ? Pour éviter les procès pour vente liée ? Pour à leur tours se faire rembourser les licences que les clients n’ont pas voulu auprès du constructeur/Microsoft et éventuellement gagner plus que 20€ si les licences OEM valent plus que ça ? Bref ceci restera sans doutes toujours un mistère.

J’ai donc installé Ubuntu qui tourne plutôt bien. J’ai été même très impressionné par le network-manager qui me connecte automatiquement sur les réseaux wifi ou filaire selon la disponibilité et qui configure même un réseau zeroconf si il ne trouve pas de server dhcp, c’est très pratique pour transférer des données entre 2 ordinateurs, il suffi de brancher un cable ethernet (ça marche aussi par wifi mais j’ai pas encore testé) entre les 2 et hop tout le réseau est configuré automatiquement sans rien toucher, vraiment magique ! Windows peut aller se cacher, ubuntu est largement plus facile d’utilisation !

I hate having to write about bugs in the documentation. It feels like waving a big flag that says ‘Ok, we suck a bit’.

Today, it’s the way fonts are installed, or rather, they aren’t. The Fonts folder doesn’t show the new font, and the applications that are already running don’t see them.

So I’ve fixed the bug that was filed against the documentation. Now it’s up to someone else to fix the bugs in Gnome.