ludoka.net

Aller au contenu | Aller au menu | Aller à la recherche

C'est bientôt noël : faites vous-même vos paquets cadeaux !

Il peut arriver que l'on ait besoin de bidouiller un paquet existant, le plus souvent pour appliquer une correction de bogue à une application non encore publié sous une version plus récente. La procédure est relativement simple :

  1. Récupérer le paquet source via apt-get source nom-du-paquet-source ;
  2. Rendez-vous dans le répertoire du paquet source et faîtes ce qui doit fait (patch, etc) ;
  3. Exécuter debchange --nmu "bla bla bla" en tapant une description appropriée de la modification effectuée, cela incrémentera le numéro de version de sorte que le système n'écrasera pas votre paquet par celui d'origine ;
  4. Exécuter debuild ;
  5. Installer et profitez de votre paquet !

Bon, j'espère sincèrement ne pas vous saturer par la haute fréquence de mes billets…

Nuit blanche pour les gorilles

Découvert grâce à un billet de Ars Technica, j'ai fait l'acquisition d'un Samsung Galaxy S[1] tournant sous Android. La critique du Journal du Geek ainsi que la revue de FrAndroid sont globalement très positives, et je dois dire que je suis particulièrement content de cet androphone.

Toutefois, trois raisons[2] m'ont inévitablement amené à le bidouiller :

  1. Le GPS était défaillant, il était impossible de l'utiliser tel quel, or c'est pour moi un élément primordial d'un smartphone moderne ;
  2. Il semblait possible d'accélérer le firmware, et même si ce n'est pas toujours essentiel, cette fois j'avais bien envie de profiter d'un peu plus de rapidité ;
  3. La version d'Android livrée était Eclair, or Froyo étant sortie, le geek en moi rêvait de l'essayer !

Pour mettre à jour le firmware il faudra procéder en quatre étapes, en commençant par rooter le Galaxy S, puis après avoir pris soin de sauvegarder tout ce qui peut être important on procèdera au flashage d'un nouveau firmware, avant de terminer par quelques corrections et optimisations.

Traiter à la racine

Avant toute manipulation, il va falloir rooter le Galaxy S. Pour cela, je recommande fortement l'utilisation de z4root qui permet de rooter et dérooter son téléphone à partir d'une application installable sur le téléphone et de se passer de l'installation d'un logiciel sur l'ordinateur, ce qui est plus pratique sachant que ce dernier est sous Ubuntu, et que la plupart des logiciels pour rooter le Galaxy S fonctionnent sous Windows…

Sauvegarder sa santé d'esprit[3]

Pour se préparer au pire (ou presque), il faut sauvegarder le système dans son ensemble, il semblerait que la référence soit de faire un nandroid backup. À cette fin, j'ai utilisé une méthode basée sur ROM Manager de ClockWorkMod qui exploite un recovery modifié. Mais ce n'est peut-être pas la méthode la plus simple si l'on se réfère au premier lien…

Pour effectuer une sauvegarde par application, Titanium Backup est l'application la plus connue, mais il en existe d'autres.

Il faut s'assurer de bien comprendre la différence entre Nandroid Backup et Titanium Backup car leurs finalités sont différentes. Peut-être ai-je mal réalisé mon Titanium Backup, mais les applications SMS Backup & Restore et Call Logs Backup & Restore m'ont également été fort utiles pour conserver (respectivement) mes SMS et mon journal d'appel.

Se mettre à la page

Afin de flasher le Galaxy S sous GNU/Linux, il est possible d'utiliser Heimdall. Pour les utilisateurs d’Ubuntu il existe le PPA d'Heimdall. La procédure à suivre est relativement simple :

  1. Charger complètement le téléphone (ça va plus vite avec une prise de courant) ;
  2. Brancher votre Galaxy S en mode download, pour cela il faut l'éteindre, le brancher en USB, puis l'allumer en appuyant sur « Volume bas + Home + Power », il s'affiche un gros panneau travaux mettant en scène un android creusant avec une pelle (si l'accès au mode download est impossible, c'est que votre Galaxy S est bridé et il va falloir suivre ce tutoriel pour débrider votre Galaxy S) ;
  3. Récupérer un firmware pour le Galaxy S, pour cela on pourra utiliser la liste de firmwares de FrAndroid ou SamFirmware, en pensant également à télécharger le fichier PIT correspondant au firmware choisi ;
  4. Extraire toutes les archives du firmware (CODE, MODEM et CSC) dans un même répertoire en finissant par le CSC qui effacera éventuellement quelques autres fichiers (c'est normal), placer également le fichier PIT associé au firmware dans ce répertoire ;
  5. Enfin, dans un terminal, naviguer jusqu'au répertoire du firmware et flasher ce dernier grâce à Heimdall.

Voici un exemple de flash complet, mais il ne faut utiliser que les paramètres correspondant aux fichiers du firmware flashé :

sudo heimdall flash --pit s1_odin_20100512.pit --factoryfs factoryfs.rfs --cache cache.rfs --dbdata dbdata.rfs --boot boot.bin --secondary Sbl.bin --param param.lfs --kernel zImage --modem modem.bin

Le choix du firmware est probablement l'étape la plus importante. Il existe également des firmwares alternatifs, comme par exemple CyanogenMod même si ce dernier ne publie pas encore de version pour le Galaxy S. Suivant le firmware choisi, il faudra éventuellement réaliser un premier flash intermédiaire. Par exemple, dans mon cas, pour passer de la version JF3 à la version JPA, j'ai d'abord du flasher une version JM8 puis la version JPA désirée. Heimdall ne permettant pas encore de re-partitionner, j'ai utilisé le PIT 503 avec le firmware JPA et cela à fonctionné correctement malgré tout…

Il existe également gHeimdall, une interface graphique pour Heimdall, appréhendable facilement grâce au tutoriel de gHeimdall de Galaxy S Team. Toutefois, au vu du site de Heimdall, il semblerait qu'il existe désormais une interface graphique officielle.

Attention ! Suite à un flash raté, il est possible que vous ayez « briqué » votre Galaxy S : il sera complètement inutilisable, ce ne sera plus qu'une brique… Vous pourrez alors tenter de fabriquer un cable Micro USB modifié pour débriquer le Galaxy S et pouvoir à nouveau accéder au mode download pour tenter un nouveau flash. Ou, le cas échéant, le renvoyer au service après-vente, mais rien ne garanti que ce sera gratuit ou même réparable, donc effectuez les manipulations décrites ci-dessus à vos risques et périls !!

Minimaxer

En vrac, voici en quoi optimiser le Samsung Galaxy S :

Les chandelles, ça marche…

Pour conclure, je dirais que le passage de Eclair à Froyo et le Voodoo Lagfix de Curio ont fait un bien immense lors de l'utilisation au quotidien de mon Galaxy S. Quadrant, qui permet d'évaluer la puissance de son androphone, m'affiche une amélioration d'environ +80% par rapport à la puissance initiale.

Quand au GPS, il fonctionne maintenant à merveille… pour un téléphone ! C'est GPS Test qui m'a permit d'évaluer les performances et améliorations de mon GPS. Toutefois, le GPS n'est utilisable correctement en voiture qu'à la condition d'avoir un bras avec un ventouse à clip (c'est plus solide) et un chargeur (pour l'autonomie).

Références

Notes

[1] Sammy de son petit nom :D !

[2] Deux étant le chiffre du doute, ce n'était pas suffisant…

[3] L'humour renforce notre instinct de survie et sauvegarde notre santé d'esprit. (Charlie Chaplin)

Il faut savoir se mobiliser dans la vie…

Ou une petite remise en question pour la route…

L'article récemment paru « Penser mobile d’abord » de Pompage par Luke Wroblewski m'amène à reconsidérer le thème de ce blog… Pour le moment, je pense toujours que l'utilisation de Dotclear est un atout, malgré une multitude d'article qui mettent en évidence que développer sa propre solution est plus pertinent.

Toutefois, il va falloir que je me plonge dans l'élaboration de mon propre thème pour l'adapter (au moins) aux mobiles, tout d'abord pour la consultation, puis peut-être même pour la publication de billet, auquel cas il me faudra probablement contribuer à Dotclear, ce qui n'est pas une mauvaise chose… L'article évoque également quelques capacités alléchantes à exploiter !

Ré-insurrection !

Après une longue période d'inactivité, ce blog va enfin revenir à la vie.

Pendant longtemps mon blog a été connu[1] sous le nom de « La Voix de Damocles ». Désormais il sera connu[2] comme « ludoka.net ». Ceci simplement pour se mettre en harmonie avec sa nouvelle url[3] : http://www.ludoka.net/. Mon objectif est toujours qu'il soit une vitrine sur l'ensemble de mes projets et de mes passions.

Je commence par un changement de thème : j'ai choisi Duo de annso, que je trouve très chouette. Toutefois, il a nécessité et nécessitera encore quelques adaptations pour être parfaitement à ma convenance.

Évidemment, ce qui compte le plus, c'est surtout mon flux de syndication et son contenu… Donc @ bientôt ;)[4] !

Notes

[1] Enfin, un peu quoi…

[2] Enfin, on verra bien…

[3] Enfin, c'est tout relatif : j'ai modifié l'url il y a presque un an…

[4] Enfin !

Et pis ton organisation alors ¿

Dernièrement, je me suis acharné à empaqueter anoX pour Debian/Ubuntu, ce qui m'a amené à créer un installateur Python, à penser au support d'autres langues, à me demander quels fichiers d'information je devais fournir avec mes sources. Bref : Comment organiser les fichiers sources d'un projet libre ?

Mon idée est que quelque soit le projet, sa nature et ses langages de développement, je puisse adopter une organisation analogue qui me permettent de me repérer facilement tout en étant pratique et transparent pour un intervenant extérieur (créateur de paquet, contributeur, curieux, etc).

Je ne suis pas le seul à m'être posé ce genre de question : cet article de Jean-Paul Calderone[1] apporte quelques conseils sur l'organisation d'un projet Python.

Ma solution, qui diffère de celle de Jean-Paul Calderone :

  • Un répertoire data contenant toutes les données qui ne sont pas du code source (documentation, traduction, image, configuration, …) ;
  • Un répertoire src contenant le code source et les fichiers intermédiaires créés lors de la compilation ;
  • Un répertoire lib contenant les bibliothèques après compilation ;
  • La racine du projet ne contenant que les fichiers utiles à un utilisateur tels que un ou plusieurs exécutables (sans extension), un installateur (Makefile et/ou setup.py), ainsi que quelques classiques comme une licence (COPYING), un fichier lisez-moi (README), et tout ce qui semblera utile (attention toutefois, le moins sera le mieux).

Évidement un projet en python a quelques spécificités :

  1. Les exécutables à la racine ne doivent toujours pas avoir d'extension « .py » ;
  2. Les répertoires lib et src ne forment qu'un seul répertoire nommé :
    • du nom du projet pour une bibliothèque (par exemple mutagen),
    • du nom du projet précédé de lib pour une application (par exemple libquodlibet pour quodlibet).

Du point de vue du développement, le premier avantage est qu'il n'y a pas besoin de réorganiser les fichiers du projet au fil de son développement. Pour une application en python on commencera par créer un exécutable (par exemple anox, sans extension), puis on ajoutera plus tard une bibliothèque si le besoin s'en fait sentir (dans notre exemple, ce sera libanox) qui contiendra tous les modules et packages nécessaires.

De plus, l'installateur python est également facile à développer, puisqu'il n'y a pas besoin d'user de magie pour installer les scripts sans extension (anox dans notre exemple). Les sources et les données sont également clairement séparées, ce qui facilite l'empaquetage lorsque l'on veut créer un paquet de données à part (par exemple pour les jeux).

Mais surtout, une telle organisation est claire d'un point de vue extérieur, la racine du projet ne contient que ce qui est utile à l'utilisateur. C'est important car c'est la première chose que constate un utilisateur qui explore le projet en vue de le tester, l'utiliser ou y contribuer. Ainsi une application est également facilement exécutable après compilation et avant installation manuelle.

Notes

[1] Jean-Paul Calderone est un des auteurs de Twisted.

anoX « Not So Early » : Jouer dans une autre session X

Avertissement : L'installation ou l'utilisation d'un script tiers, ainsi que les manipulations décrites dans ce billet peuvent s'avérer dangereux pour la sécurité, la stabilité et l'intégrité de votre système.

Une multitude de problèmes peuvent se montrer assez gênant vis-à-vis du jeu sous GNU/Linux. Comme par exemple les fenêtres des applications Wine qui disparaissent lorsque l'on change de bureau avec Compiz activé, ou encore les jeux SDL qui ne permettent pas de retourner au bureau lorsqu'ils sont lancés. La meilleure solution serait sans doute de corriger un à un ces problèmes pour que l'expérience utilisateur soit parfaite. Mais en attendant que ce soit fait, il est agréable d'avoir une solution de contournement.

anoX vous permet de lancer un jeu (ou n'importe quelle application) dans un autre serveur X, évitant ainsi que Compiz fasse disparaître votre jeu Wine ou que SDL ne vous empêche de retourner sur votre bureau…

Pour l'utiliser, il vous suffit de :

  1. Télécharger l'archive d'anoX
  2. Copier le fichier anox qu'elle contient dans votre répertoire /usr/bin/ (en vous assurant qu'il soit exécutable)
  3. Lancer vos jeux ou autre de la façon suivante : anox "tremulous -q"

Si ces explications ne suffisent pas, il vaut peut-être mieux passer son chemin…

Deux problèmes peuvent toutefois se poser :

  • Il faut être autorisé à lancer un autre serveur X : pour cela il faut éditer le fichier /etc/X11/Xwrapper.config pour remplacer « allowed_users=console » par « allowed_users=anybody »
  • Pulseaudio va isoler le son de chaque serveur X, empêchant ainsi de dialoguer via Mumble avec un ami tout en jouant à un jeu. La meilleure solution est de le désactiver avec un « killall pulseaudio » au démarrage de la session (Système → Préférence → Session).

Pour la suite, il faudrait maintenant que je mette en place un script d'installation et un paquet pour Ubuntu, mais je ne sais pas encore comment m'y prendre pour un programme Python. Il va falloir apprendre…

Retour d'hibernation ;) !

Ayant rencontré moultes problèmes avec la mise en veille et l'hibernation, je vais expliquer très brièvement comment les régler.

Avant toute chose, ce que je vais dire concerne principalement les possesseurs de carte nVidia. De plus, les manipulation que je vais décrire peuvent se révéler très dangereuses pour l'intégrité de votre système (tant matériel que logiciel). Avant d'éditer un fichier système, il est fortement conseillé d'en faire une copie de sauvegarde.

Problèmes dûs à la carte graphique nVidia GeForce 8600M GT

Éditer le fichier /etc/X11/xorg.conf pour ajouter à la section « Device » (carte graphique) :

Option "NvAGP" "1"
Option "NoLogo" "1"

Éditer le fichier /etc/default/acpi-support pour changer :

SAVE_VBE_STATE=false
POST_VIDEO=false

Éditer /etc/modprobe.d/blacklist pour ajouter :

blacklist intel_agp
blacklist agpgart

Sources :

Problèmes dûs à la carte son Intel Corporation 82801H

Éditer /etc/modprobe.d/alsa-base pour ajouter :

options snd-hda-intel model=toshiba

Source inconnue.

Meme(me)

Via LE Standblog

Self portrait of myself

  1. Take a picture of yourself right now.
  2. Don’t change your clothes, don’t fix your hair... just take a picture.
  3. Post that picture with NO editing.
  4. Post these instructions with your picture.

Calton Hill

- page 1 de 7

Thème Time Flies par David Yim