L’astuce a déjà fait le tour du web, mais ça ne fait jamais de mal de la rappeler
En mode veille, le Kobo by Fnac affiche le logo de la Fnac. Y’a pire comme souci dans la vie, mais bon ça serait quand même plus sympathique d’afficher la couverture du livre en cours de lecture ! Eh bien c’est possible.
Editer le fichier /media/KOBOeReader/.kobo/affiliate.conf et remplacer :
par :
Maintenant sur votre Kobo, vérifiez bien dans Paramètres puis Mise en veille et hors tension que l’option Affichage d’une couverture de livre est bien activée.
Ca y’est, j’ai fini par craquer pour la liseuse électronique (e-book reader en anglais) Kobo by Fnac (qui n’est autre que la Kobo Touch chez les anglo-saxons), plutôt que le Kindle 4 d’Amazon, pour la bonne et simple raison que ce dernier ne supporte pas le format ouvert standardisé ePub.
De retour chez moi, je déballe la bête, et je la connecte en USB à mon PC pour la charger. Elle m’affiche alors le message suivant :
Pour configurer et associer votre appareil à un compte, téléchargez le logiciel gratuit Kobo Desktop.
Depuis votre ordinateur, allez sur : www.kobosetup.com
En débranchant la prise USB, on peut alors cliquer sur “Passer la configuration” en haut à droite de l’écran, mais dans ce cas, nouveau message :
Vous ne pourrez télécharger de livres, ni vous connecter à la Librairie tant que la configuration n’est pas effectuée. La configuration est importante, nous vous le rappellerons plus tard.
Malheureusement, le logiciel Kobo Desktop n’est disponible que pour Windows ou pour Mac OS.
En fouillant un peu, on peut trouver le lien d’un paquet Debian sur le forum MobileRead. C’est une version 32 bits non-officielle de Kobo Desktop pour Linux, pourtant fournie par les développeurs de chez Kobo.
Si vous avez une distribution Debian ou Ubuntu, voici comment la télécharger et l’installer :
$ wget http://dl.dropbox.com/u/2183775/kobo-desktop.deb
$ sudo aptitude update
$ sudo aptitude install libpng3 libzip1
$ sudo dpkg -i kobo-desktop.deb
Maintenant créez un compte sur le site de la Fnac (ça va être utile par la suite), lancez Kobo Desktop, et enfin branchez le Kobo en USB.
Vous devriez voir apparaître une icône nommée KOBOeReader apparaître sur votre bureau, ou dans votre gestionnaire de fichiers. Cliquez dessus pour que le volume amovible soit monté, et normalement la procédure d’installation va démarrer automatiquement. Il suffit alors de se laisser guider !
Suite à quelques instabilités de ma ligne ADSL, j’ai décidé de rejoindre la communauté des grenouilles.
J’en ai profité pour décrire l’installation du client Coregrenouille (qui est apparemment le nouveau client à utiliser, qui doit remplacer tous les anciens clients) sur Ubuntu.
La première chose à faire est de créer un compte sur grenouille.com.
Ensuite, nous allons installer les paquets dont nous allons avoir besoin :
$ sudo aptitude install git ocaml-nox
On télécharge les sources et on se place dans le répertoire :
$ git clone git://git.grenouille.com/coregrenouille.git coregrenouille-git
$ cd coregrenouille-git/
On va juste modifier 2 chemins pour les ajuster à notre goût
D’abord le chemin du fichier de log :
$ sed -i 's#coregrenouille.log#/var/log/coregrenouille.log#' debug.ml
Puis le chemin de l’utilitaire awk sur Ubuntu :
$ sed -i 's#awk /bin/awk#awk /usr/bin/awk#' user.config.linux
Et c’est parti pour la compilation :
$ make depend
$ make coregrenouille
Maintenant on créé le répertoire d’installation, et on y copie le binaire et le fichier de config :
$ sudo mkdir /opt/coregrenouille
$ sudo cp coregrenouille
$ sudo cp user.config.linux /opt/coregrenouille/user.config
On édite le fichier de config :
$ sudoedit /opt/coregrenouille/user.config
Et on ajuste les paramètres suivants :
username mon_nom
password mot_de_passe
interface eth0
Enfin on créé le fichier de log et on permet à tout le monde d’écrire dedans :
$ sudo touch /var/log/coregrenouille.log
$ sudo chmod a+w /var/log/coregrenouille.log
Il ne reste plus qu’à lancer coregrenouille !
$ /opt/coregrenouille/coregrenouille -f /opt/coregrenouille/user.config -t &
Pour voir ce qui se passe en direct, vous pouvez lancer la commande suivante :
$ tail -f /var/log/coregrenouille.log
There’s a new 3.0 version of ELFkickers available since may 2011, after a decade of inactivity.
You can read the changelog from the previous link to see what has changed, but concerning sstrip, the most important thing is that it now also works with 64-bit ELF files.
Let’s download, compile and install it:
$ wget http://www.muppetlabs.com/~breadbox/pub/software/ELFkickers-3.0.tar.gz
$ tar xf ELFkickers-3.0.tar.gz
$ cd ELFkickers-3.0/
$ make
$ sudo make install
Now we can try it on strip
First make a copy:
$ cp /usr/bin/strip /tmp/
Check the size before:
$ wc -c < /tmp/strip
220432
And also what file says before:
$ file /tmp/strip
strip: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0xa4aa26810da0b5672790975fc7e193520c9e2008, stripped
Now sstrip it!
This is the size after:
$ wc -c < /tmp/strip
218404
The size has been reduced by 2028 bytes:
$ echo $((220432 - 218404))
2028
And here’s what file reports now:
$ file /tmp/strip
strip: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.26, dynamically linked (uses shared libs), corrupted section header size
file complains that the section header size is corrupted, but the sstripped binary still seems to run fine.
Nous allons voir comment mettre à jour le paquet pcre de la version 8.11 vers la version 8.20, et comment créer un patch pour l’envoyer aux développeurs d’OpenWrt.
Pour info, voici l’arborescence dans laquelle je travaille :
$ ls /data/workspace/openwrt/
patches trunk
Tout d’abord, nous allons faire en sorte d’être à jour :
$ cd /data/workspace/openwrt/trunk/
$ svn up
$ ./scripts/feeds update -a
Nous sommes maintenant prêts à commencer.
On commence par télécharger la dernière version de pcre dans le répertoire dl/ :
$ wget -P dl/ ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.20.tar.bz2
Puis on calcule sa somme de contrôle MD5 :
$ md5sum dl/pcre-8.20.tar.bz2
a1931c70e1273e3450d5036fe273d25c dl/pcre-8.20.tar.bz2
On va alors dans le répertoire du paquet pour commencer à travailler :
$ cd feeds/packages/libs/pcre/
On indique à quilt de créer un nouveau patch :
$ quilt new pcre.patch
Patch pcre.patch is now on top
On lui indique qu’on veut modifier le fichier Makefile, ce qui aura pour effet de l’ajouter automatiquement au patch qui est au sommet de la pile :
$ quilt edit Makefile
File Makefile added to patch pcre.patch
On va donc mettre à jour les divers paramètres du paquet qui ont changé.
Dans tous les cas il y aura PKG_VERSION à changer pour mettre le nouveau numéro de version, PKG_RELEASE à mettre à 1 (car c’est la première release du paquet à la nouvelle version), et PKG_MD5SUM à mettre à la valeur calculée un peu plus tôt.
Dans cet exemple, PKG_SOURCE_URL change également.
Avant :
PKG_NAME:=pcre
PKG_VERSION:=8.11
PKG_RELEASE:=2
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
PKG_SOURCE_URL:=@SF/pcre
PKG_MD5SUM:=ef907b8792ec7f90f0dcd773848f0b3b
Après :
PKG_NAME:=pcre
PKG_VERSION:=8.20
PKG_RELEASE:=1
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
PKG_SOURCE_URL:=ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/
PKG_MD5SUM:=a1931c70e1273e3450d5036fe273d25c
Une fois les modifications effectuées, on indique à quilt de rafraîchir le patch :
$ quilt refresh
Refreshed patch pcre.patch
Comme nous l’avons défini dans Installation et configuration de quilt pour créer des patchs OpenWrt, le patch se trouve dans /data/workspace/openwrt/patches/.
On retourne à la racine d’OpenWrt pour vérifier que tout compile correctement :
$ cd -
/data/workspace/openwrt/trunk
$ make package/pcre/compile V=99 DEVELOPER=1
Et voilà !
A few days ago, as I was doing my periodic aptitude safe-upgrade, I got the following (irrelevant parts omitted):
$ sudo aptitude safe-upgrade
Unpacking libbison-dev (from .../libbison-dev_1%3a2.5.dfsg-2_amd64.deb) ...
dpkg: error processing /var/cache/apt/archives/libbison-dev_1%3a2.5.dfsg-2_amd64.deb (--unpack):
trying to overwrite '/usr/lib/x86_64-linux-gnu/liby.a', which is also in package liby-dev 1:2.5.dfsg-1
configured to not write apport reports
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
...
Errors were encountered while processing:
/var/cache/apt/archives/libbison-dev_1%3a2.5.dfsg-2_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
A package failed to install. Trying to recover:
...
dpkg: dependency problems prevent configuration of bison:
bison depends on libbison-dev (= 1:2.5.dfsg-2); however:
Package libbison-dev is not installed.
dpkg: error processing bison (--configure):
dependency problems - leaving unconfigured
...
Errors were encountered while processing:
bison
In fact, liby-dev has been renamed to libbison-dev to avoid name conflict with Y sound server library header files, but some fields are missing from the package control file (Provides, Conflicts and Replaces).
The correct way to rename a package is documented in the Debian Developer’s Reference in section 5.9.3. Replacing or renaming packages, and in the Debian Policy Manual in section 7.6 Overwriting files and replacing packages.
Anyway, if you don’t want to wait for the problem to get fixed, there’s a workaround:
$ sudo aptitude purge liby-dev bison
The following packages will be REMOVED:
bison{p} liby-dev{p}
0 packages upgraded, 0 newly installed, 2 to remove and 50 not upgraded.
Need to get 0 B of archives. After unpacking 2216 kB will be freed.
Do you want to continue? [Y/n/?]
(Reading database ... 166621 files and directories currently installed.)
Removing bison ...
Removing liby-dev ...
Processing triggers for man-db ...
Current status: 0 broken [-1].
$ sudo aptitude install bison
The following NEW packages will be installed:
bison libbison-dev{a}
0 packages upgraded, 2 newly installed, 0 to remove and 50 not upgraded.
Need to get 0 B/981 kB of archives. After unpacking 2216 kB will be used.
Do you want to continue? [Y/n/?]
(Reading database ... 166516 files and directories currently installed.)
Unpacking libbison-dev (from .../libbison-dev_1%3a2.5.dfsg-2_amd64.deb) ...
Selecting previously unselected package bison.
Unpacking bison (from .../bison_1%3a2.5.dfsg-2_amd64.deb) ...
Processing triggers for man-db ...
Setting up libbison-dev (1:2.5.dfsg-2) ...
Setting up bison (1:2.5.dfsg-2) ...
You can also check the following Debian bugs: #645038, #645047 and #645086 (which have been merged).
We’ve seen in a previous post How to set up repository synchronization in Trac 0.12.
The problem, however, is that calling trac-admin in the hooks can slow down the commit and log editing operations on the client side.
One solution is to start trac-admin in an asynchronous way, for example with nohup and &.
Modify the post-commit hook to look like this:
#!/bin/sh
TRAC_ENV="/var/trac"
TRAC_ADMIN=$(which trac-admin)
HOOK_LOG="$TRAC_ENV/log/$(basename $0).log"
nohup $TRAC_ADMIN "$TRAC_ENV" changeset added "$1" "$2" >> "$HOOK_LOG" 2>&1 &
And modify the post-revprop-change hook to look like this:
#!/bin/sh
TRAC_ENV="/var/trac"
TRAC_ADMIN=$(which trac-admin)
HOOK_LOG="$TRAC_ENV/log/$(basename $0).log"
nohup $TRAC_ADMIN "$TRAC_ENV" changeset modified "$1" "$2" >> "$HOOK_LOG" 2>&1 &
Another possibility is to use the trac-svn-hook script (found in /usr/share/doc/trac/contrib/). Its usage is described in great detail at the beginning of the script.
According to the Trac wiki:
Prior to 0.12, Trac synchronized its cache with the repository on every HTTP request. This approach is not very efficient and not practical anymore with multiple repositories. For this reason, explicit synchronization through post-commit hooks was added.
The preferred method of repository synchronization is explicit synchronization. We’ll see how to enable it.
The first thing is to edit trac.ini:
$ sudoedit /var/trac/conf/trac.ini
And set the repository_sync_per_request option (it can be found in the [trac] section) to an empty value:
[trac]
...
repository_sync_per_request =
...
Now we need to add a call to trac-admin in the post-commit hook of each repository.
For example, with a repository located in /var/svn/project1, the post-commit hook is located at /var/svn/project1/hooks/post-commit:
$ sudoedit /var/svn/project1/hooks/post-commit
This is how this file should look like:
#!/bin/sh
TRAC_ENV="/var/trac"
TRAC_ADMIN=$(which trac-admin)
$TRAC_ADMIN "$TRAC_ENV" changeset added "$1" "$2"
Then change the ownership and permissions of this file:
$ sudo chown www-data:www-data post-commit
$ sudo chmod ug+x post-commit
Additionally, if a repository allows changing revision metadata, a call to trac-admin must be added to the post-revprop-change hook as well:
$ sudoedit /var/svn/project1/hooks/post-revprop-change
This is how this file should look like:
#!/bin/sh
TRAC_ENV="/var/trac"
TRAC_ADMIN=$(which trac-admin)
$TRAC_ADMIN "$TRAC_ENV" changeset modified "$1" "$2"
Then change the ownership and permissions of this file:
$ sudo chown www-data:www-data post-revprop-change
$ sudo chmod ug+x post-revprop-change
A digest authentication password file is a flat-file used to store usernames, realm and password for digest authentication of HTTP users. The tool commonly used to create this file is htdigest, but we’ll also see two other ways.
Under Debian, the htdigest utility is included in the apache2-utils package, so you don’t need to install Apache to get it:
$ sudo aptitude install apache2-utils
Now let’s create a new user. In this example, the password file is .htdigest, the username is user, and the realm is realm:
$ htdigest -c .htdigest realm user
Adding password for user in realm realm.
New password:
Re-type new password:
The -c parameter is given to create the file as it doesn’t already exist. If it existed, it would have been deleted and then recreated.
This is what the password file looks like:
$ cat .htdigest
user:realm:ebbc0ff9a121dbb6789bbe5f82174fa0
The format of each line of this file is as follows:
user:realm:MD5(user:realm:password)
Let’s create another user:
$ htdigest .htdigest realm otheruser
Adding user otheruser in realm realm
New password:
Re-type new password:
We didn’t give the -c parameter this time, as we wanted to append to the existing password file, and not recreate it.
The password file now looks like this:
$ cat .htdigest
user:realm:ebbc0ff9a121dbb6789bbe5f82174fa0
otheruser:realm:c9be7a49959637333df7cd6b64e2c539
If you installed the Trac package, there’s a Python script named htdigest.py included, so you don’t need to install apache2-utils:
$ python /usr/share/doc/trac/contrib/htdigest.py -c .htdigest realm user
New password:
Re-type new password:
We get the same result as with htdigest:
$ cat .htdigest
user:realm:ebbc0ff9a121dbb6789bbe5f82174fa0
A nice feature of this script is the -b parameter to enable the batch mode, which allows us to specify the password as an argument. This can be really useful when writing a script to automate the process:
$ python /usr/share/doc/trac/contrib/htdigest.py -b -c .htdigest realm user password
And finally, another solution using only md5sum and cut, both included in the coreutils package, which should already be installed on your system.
Just set HTUSER, HTREALM and HTPASSWORD to the values you’d like to use:
$ HTUSER=user HTREALM=realm HTPASSWORD=password && (echo -n "$HTUSER:$HTREALM:" && echo -n "$HTUSER:$HTREALM:$HTPASSWORD" | md5sum | cut -b -32) > .htdigest
Now to add another user, we use >> instead of > to append to the existing file:
$ HTUSER=otheruser HTREALM=realm HTPASSWORD=otherpassword && (echo -n "$HTUSER:$HTREALM:" && echo -n "$HTUSER:$HTREALM:$HTPASSWORD" | md5sum | cut -b -32) >> .htdigest
We get the same result as with htdigest:
$ cat .htdigest
user:realm:ebbc0ff9a121dbb6789bbe5f82174fa0
otheruser:realm:c9be7a49959637333df7cd6b64e2c539
Il y a actuellement 3 listes de discussion (mailing lists) OpenWrt actives et publiques :
Les liens ci-dessus permettent de s’inscrire aux différentes listes, et également de consulter les archives.
La liste openwrt-devel est la plus intéressante pour ceux qui font du développement sous OpenWrt, et c’est d’ailleurs le moyen privilégié pour contribuer un patch.
Ces listes sont anglophones, mais il existe également un forum OpenWrt en français.