Catégorie : développement – divers

vim howto : comment installer un plugin

J’ai vu cet exceptionnel exemple de plugin ici.
Petite parenthèse : regardez d’ailleurs le site vimcasts.org, c’est vraiment un site exceptionnel pour tous ceux qui veulent apprendre des astuces géniales de vim.

Donc, comment installer un plugin ? Moi, habitué de Windows © je me suis dit « ça doit être très compliqué, je vais chercher sur la toile ».
Mais… c’est tellement simple que j’avais beau chercher partout, je n’ai pas trouvé de réponse !
Voilà en pratique comment j’ai fait.
Le plugin génial que j’ai vu ici, se trouve là : https://github.com/godlygeek/tabular

Je vais donc à cette adresse :
Page Internet du plugin Tabularize

Je le télécharge, et voici les fichiers que je trouve dedans :
Fichiers dans le plugin Tabularize

Je me dis « bon sang comment l’installer dans vim ? ».
En pratique, rien de plus simple. Très souvent, dans votre répertoire « home » (auquel vous accédez en tapant le tilde en ligne de commande : ~), concernant vim, il y a un dossier caché qui commence par un point : « .vim » (n’oubliez pas le point au début).
Allez dans ce dossier et regardez s’il y a un sous-dossier plugin. S’il n’y en a pas, créez le. Moi qui suis sous Windows, et qui m’en éloigne de plus en plus jour après jour, j’ai installé cygwin et mon « home » est dans C:\cygwin\home\Olivier. Voilà ce que ça donne après avoir crée le bon dossier :
Fichiers dans le plugin Tabularize
Ensuite il vous suffit de copier simplement les dossiers du plugin dans le répertoire « ~/.vim/plugin » et… tout fonctionne (dans mon cas c’est donc C:\cygwin\home\Olivier\.vim\plugin) !
Copier les fichiers du plugin Tabularize dans le répertoire plugin de vim

Si vous avez des suggestions n’hésitez pas !

UglifyJS : meilleur et plus rapide que Google Closure Compiler et YUI

Merci à Mathieu Robin, ici, pour les petites explications de jQuery 1.5, dans lequel on peut lire qu’ils ont laissé tomber Google Closure Compiler pour UglifyJS.

UglifyJS est une librairie de compression/optimisation de code JavaScript. Dit autrement, vous écrivez votre code en JavaScript, vous le testez, avec les commentaires et tout et tout, et puis dès que vous pensez qu’il est prêt, hop, vous le passez à la moulinette UglifyJS et vous aurez un code super compressé, sans aucun commentaire, mais qui fonctionnera à l’identique de l’original, et vous pourrez le mettre sur votre serveur de production.

PS : Si si il est bien 2:44 du matin, j’ai fini de donner le bib’ à mon fils (^_^)

shell : remplacer un retour chariot par un espace

Super facile : l’outil tr.
Exemple concret : je veux lister les fichiers d’un répertoire et tous les passer à vim, par exemple pour y appliquer une macro.

Je les liste à la main du genre :

~/ # find ws -type f
ws/jsDecision.php
ws/jsDossierDocuments.php
ws/jsInfosEmprunt.php
ws/jsInternetDocumentDossierEditer.php
ws/jsListeFormulesGaranties.php
ws/jsLogin.php

Il suffit d’ajouter | tr '\r\n' ' ' (qui signifie « transforme tous les retours chariots en espaces ») :

~/ # find ws -type f | tr '\r\n' ' '
ws/jsDecision.php ws/jsDossierDocuments.php ws/jsInfosEmprunt.php ws/jsInternetDocumentDossierEditer.php ws/jsListeFormulesGaranties.php ws/jsLogin.php

Compilation du serveur JACK

Ouf ! J’ai enfin réussi à compiler une version du serveur JACK 1.9.6.
A chaque fois il me disait qu’il manquait quelque chose, et je devais l’installer.
Voilà comment ça s’est passé : j’ai récupéré la dernière version de JACK, puis je l’ai décompressée et je suis allé dans le répertoire en shell :
cd ~/Bureau/jack-1.9.6
De là, j’ai commencé à essayer de compiler :
> sudo ./waf clean && sudo ./waf configure --alsa
A chaque fois, il y avait des lignes où il me disait « no » au lieu de « yes », par exemple :
Checking for alsa >= 1.0.18 : ok
Checking for libfreebob >= 1.0.0 : no
Checking for libffado >= 1.999.17 : no
Checking for header sndfile.h : no

Alors voici la solution pour la plupart des choses manquantes : il faut installer la version de développement.
Donc (1) demander de chercher parmi tous les packages existants : prenons l’exemple avec sndfile :
sudo apt-cache search sndfile
Et là malheureusement il trouve plein de fichiers. Alors on filtre en précisant qu’on ne veut que du « développement » = « dev » :
sudo apt-cache search sndfile | grep dev
Et là il ne reste plus que deux lignes :

libsndfile1-dev - Development files for libsndfile;
mffm-libsndfilew-dev - wrapper for the libsndfile

Avec ces deux lignes, il faut prendre la plus « logique », ici donc la première, et installer en copiant collant le premier mot, ici « libsndfile1-dev » :
sudo apt-get install libsndfile1-dev

Vous continuez comme ça jusqu’à ce que vous n’ayez plus que des « yes » partout.
Ensuite, il se peut que vous ayez l’erreur :
«Unknown driver "alsa"»

La solution est simple (mais encore une fois il fallait la trouver) : il vous faut lors de la configuration de la compilation, préciser qu’il faut ajouter le driver « alsa » :
sudo ./waf clean && sudo ./waf configure --alsa
Et enfin l’ordre qui devrait fonctionner jusqu’au bout :
sudo ./waf install
Ensuite, peut être que vous êtes dans le même cas que moi à savoir que sous Ubuntu, vous avez installé la version « officielle ». Cette dernière est installée dans /usr/bin :
/usr/bin/jackd
Mais la nouvelle que vous venez tout juste de compiler a peut être été installée ailleurs !
Mettez à jour la liste de tous les fichiers de votre ordinateur :
> sudo updatedb
Et cherchez tous les fichiers « jackd » :

> sudo locate /jackd | grep ckd$ | more
/etc/default/jackd
/home/olivier/Bureau/jack-1.9.6/build/default/linux/jackd
/home/olivier/Téléchargements/jackd
/usr/bin/jackd
/usr/local/bin/jackd
/usr/share/doc/jackd
>

Vous voyez qu’il y en a deux qui semblent identiques. Voyons en détail :

> l /usr/bin/jackd
-rwxr-xr-x 1 root root 23096 2010-02-23 17:48 /usr/bin/jackd
olivier@olivier-laptop:~/Bureau/jack-1.9.6$ l /usr/local/bin/jackd
-rwxr-xr-x 1 root root 18727 2011-01-08 00:26 /usr/local/bin/jackd
>

Eh oui, effectivement, celui que vous avez compilé se trouve dans « /usr/local/bin » et le vieux dans « /usr/bin »
Donc il vous suffira de changer la ligne de commande du JACK Audio Connexion Kit :
/usr/bin/pasuspender -- /usr/local/bin/jackd
Et enfin, halleluja, tout fonctionnera !

Un très grand merci à LinuxMAO où j’ai trouvé cette information.

Enfin tout ça n’est que pour réussir à faire tourner une dernière version du serveur JACK…
C’est marrant avec Linux. Parce qu’on a toujours l’impression que c’est compliqué, mais au final on maitrise tellement mieux la chose que c’est bien plus agréable en fait que sur Windows, où, lorsqu’il arrive quelque chose qui ne fonctionne pas, on ne sait jamais comment le corriger… et pourtant ça fait 17 ans que je suis exclusivement sous Windows !

Ubuntu : installation du serveur JACK : comment faire

Voilà le résumé :

  • Je suis sous Ubuntu 10.04 ;
  • J’ai un piano avec deux prises MIDI (in et out) ;
  • J’ai acheté un adaptateur LogiLink USB Cable pour pouvoir transférer les informations de mon piano à mon PC et vice versa ;

Mon objectif est simple : faire en sorte que, quand j’appuie sur les touches du piano, ça se voie sur l’ordinateur.
Lancez le gestionnaire de paquets Synaptic.
Tapez « jack » dans « Recherche rapide ».
Une fois la liste affichée, sélectionnez pour l’installation : jackd, jack-tools, et celui auquel on ne pense pas mais qui est aussi important que le reste, j’ai nommé : qjackctl.

Voilà, une fois que tout est installé, il y a une nouvelle application qui est apparue dans le menu Applications => Sons et Video : c’est JACK Control.

La plupart des ordinateurs récents sous Linux ont un programme pour gérer le son qui est « PulseAudio ». Malheureusement il n’est pas compatible avec le serveur JACK. Donc il faut ajouter « /usr/bin/pasuspender — » qui va suspendre le programme « PulseAudio », pendant que le serveur JACK est actif. Bien sûr, dès que vous arrêterez le serveur, automatiquement le programme « PulseAudio » reprendra sa place de manière transparente. Que la vie est belle !
Ce qui suit ne concerne donc que les gens qui ont « PulseAudio », mais c’est la grande majorité.
Lancez le programme JACK Control (Applications => Sons et Video => JACK Control), et cliquez immédiatement sur le bouton « Réglages ».
Là, allez dans « Chemin du serveur », effacez tout et mettez :
/usr/bin/pasuspender -- /usr/bin/jackd

Voilà pour la première étape de « base ». Ensuite, je vais décrire comment compiler à la main une version plus récente du serveur JACK, afin de profiter des toutes dernières améliorations.

bazaar : tutoriel, et exemple concret d’utilisation

Je fais quelques petites notes personnelles au fur et à mesure de l’utilisation de Bazaar, au cas où cela serve à quelqu’un :

La première chose, la plus importante à savoir, pour les non-anglophones :

Du point de vue de bazaar, « checkout«  signifie « faire un lien entre« .

Par exemple :

  • on fait un lien entre deux répertoires A et B (« bazaar checkout A B »)
  • pour toute validation de modification avec bazaar (« bazaar commit » ou autre), que ce soit sur A ou sur B, bazaar va aussitôt les répercuter de l’autre côté (sur B ou A).

(1) Créer un dépôt « central » distant qui hébergera TOUS les projets

Ici, dans « /rep_bazaar/iwn_bazaar/ » :

> bzr init-repo --no-trees \
    sftp://bazaar@serveur_ftp/rep_bazaar/
bazaar@serveur_ftp's password:
Shared repository (format: 2a)
Location:
  shared repository: sftp://bazaar@serveur_ftp/rep_bazaar/
>

(2) Créer un projet distant : ici, le projet est « projet_web« 

– D’après la config précédente, il faut le créer dans une branche du dépôt central = « /rep_bazaar/projet_web/ » :

> bzr init sftp://bazaar@serveur_ftp/rep_bazaar/projet_web
bazaar@serveur_ftp's password:
Created a repository branch (format: 2a)
Using shared repository: sftp://bazaar@serveur_ftp/rep_bazaar/
>

(3) En local, initialiser un répertoire ‘vide’ qui sera celui de référence à partir duquel toutes les branches futures (dev, preprod et prod, etc.) vont dériver

(!!) dans la ligne de commande, il y a le répertoire distant ET un répertoire destination, ici « website_reference » :

> mkdir website_reference
> bzr  \
    checkoutsftp://bazaar@serveur_ftp/rep_bazaar/projet_web \
    website_reference

Attention !

D’après ce que j’ai compris, il ne faut pas toucher aux sources de références, parce qu’elles vont être copiées sur les environnements de dev, preprod et prod.

(4) Ajouter les fichiers source dans le répertoire de référence :

> cp -R website/* website_reference/

(5) Dire à bazaar d’ajouter tous les fichiers :

> cd website_reference/
~/website_reference # bzr add
(
Énorme liste de fichiers :
adding blabla/blabla.png
..
adding drupal/blabla/..
...
adding drupal/.../blabla.gif
)

(6) Valider les modifs en local avec un commentaire pour le dépôt #1 :

~/website_reference # bzr commit -m "Fichiers originaux"
(
Énorme liste de fichiers :
adding ...
..
added ws/blabla.php
...
added xml/xx/blabla.xml
)
~/website_reference #

(!!) On peut donner en local un nom différent du nom de la branche distante !

Mais comme ça risque de devenir rapidement le bazar (ahah), j’ai choisi de donner des noms identiques au répertoire du dépôt distant et aux répertoires locaux :

(7) Création de la branche de développement sur le dépôt distant :

> bzr branch sftp://bazaar@serveur_ftp/rep_bazaar/projet_web \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/dev

(8) Lier la branche distante à un répertoire local

(!) je répète : on peut donner en local un nom différent du nom de la branche distante, mais je pense que c’est à éviter, donc :

> mkdir projet_web
> mkdir projet_web/dev
> bzr checkout \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/dev \
    projet_web/dev
bazaar@serveur_ftp's password:
>

(9) Création de la branche de préproduction :

Deux mêmes ordres que pour la branche de développement (sauf répertoire final) :

> bzr branch \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/preprod
> bzr checkout \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/preprod \
    projet_web/preprod
bazaar@serveur_ftp's password:
>

(9) Création de la branche de production :

Deux mêmes ordres que pour la branche de développement (sauf répertoire final) :

> bzr branch \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/prod
> bzr checkout \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/prod \
    projet_web/prod
bazaar@serveur_ftp's password:
>

(10) Arrivé ici, le schéma est ainsi :

Sur le site de dépôt commun, mais aussi en local :

projet_web
  |
  +--- dev
  |
  +--- preprod
  |
  +--- prod

(11) Créer les sous-branches pour les développeurs :

> bzr branch \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/dev \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/dev/autre_dev
> bzr branch \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/dev \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/dev/olivier

(12) Arrivé ici, le schéma est ainsi :

Sur le site de dépôt commun :

projet_web
  |
  +--- dev
  |     |
  |     +--- autre_dev
  |     |
  |     +--- olivier
  |
  +--- preprod
  |
  +--- prod

NB : en local, les branches n’ont pas été créées, donc en local c’est ainsi :

projet_web
  |
  +--- dev
  |
  +--- preprod
  |
  +--- prod

(13) Exemple personnel : ma branche de développement pour la cellule médicale v 2.0 :

Nb : on crée encore une branche distante, rien n’est encore fait en local :

> bzr branch \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/dev/olivier \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/dev/olivier/nouveau_developpement

(13) Arrivé ici, le schéma est ainsi :

Sur le site de dépôt commun :

projet_web
  |
  +--- dev
  |     |
  |     +--- autre_dev
  |     |
  |     +--- olivier
  |            |
  |            +--- nouveau_developpement
  |
  +--- preprod
  |
  +--- prod

NB : en local, les branches n’ont pas été créées, donc en local c’est ainsi :

projet_web
  |
  +--- dev
  |
  +--- preprod
  |
  +--- prod

A partir de maintenant, on peut refaire en local toutes les branches qui n’y sont pas encore (autre_dev, olivier, nouveau_developpement).

Mais je choisis, par exemple, de ne faire que mes branche locales à moi (= olivier) :

Je fais le lien (= checkout) entre olivier et olivier distant :

>bzr checkout \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/dev/olivier \
    projet_web/dev/olivier

Je fais le lien (= checkout) entre nouveau_developpement et nouveau_developpement distant :

>bzr checkout \
    sftp://bazaar@serveur_ftp/rep_bazaar/projet_web/dev/olivier/nouveau_developpement \
    projet_web/dev/olivier/nouveau_developpement

(14) Résultat final :

Sur le site de dépôt commun :

projet_web
  |
  +--- dev
  |     |
  |     +--- autre_dev
  |     |
  |     +--- olivier
  |            |
  |            +--- nouveau_developpement
  |
  +--- preprod
  |
  +--- prod

En local, certaines branches n’ont pas été créées (volontairement) donc en local c’est ainsi :

projet_web
  |
  +--- dev
  |     |
  |     +--- olivier
  |            |
  |            +--- nouveau_developpement
  |
  +--- preprod
  |
  +--- prod

A partir de maintenant, en pratique

En pratique, il me suffit : de travailler sur le répertoire nouveau_developpement puis de faire toutes mes modifs, mes évolutions.

Une fois que je pense que tout est bon :

  • Aller dans le répertoire nouveau_developpement
  • Faire un commit :
    bazaar commit -m "Commentaire mise à jour"
  • Automatiquement, les modifications vont être répercutées sur ma branche distante (= sur le site de dépôt commun).

Motivation : mais bon sang ! T’as fait quoi là ?

C’est la traduction d’un article que j’ai lu ici.

Je crois qu’il y a un équilibre sain que tous les développeurs ont besoin d’établir, entre …

  1. S’enfermer dans un bureau privé et avoir un dialogue intime avec un compilateur et son programme ;
  2. Sortir en public et avoir un dialogue ouvert avec les autres êtres humains au sujet de son programme.

La plupart des programmeurs sont introvertis, ils n’ont pas besoin d’encouragements pour partir en courant, se retrouver seuls et passer du temps avec leur ordinateur. Ils le font naturellement. Livrés à eux mêmes, c’est la seule chose qu’ils feraient de toute façon. Je ne les blâme pas pour ça ; les ordinateurs sont incroyablement plus rationels que les gens. C’est d’ailleurs ce qui nous amène le plus souvent dans ce domaine. Mais il est possible d’aller trop loin dans l’autre sens aussi. C’est beaucoup plus rare, parce que cela va dans le sens inverse de l’introversion naturelle de la plupart des développeurs de logiciels, mais cela arrive.  Prenons moi, par exemple. Parfois, je crains de passer plus de temps de parler programmation que de programmer tout court.

Le jour où j’en suis arrivé au point de passer plus de temps à parler de développement que de développer, ma plus grandeur peur a été concrétisée : je suis devenu un expert. La dernière chose dont le monde a besoin, c’est d’avoir encore plus d’experts. Les experts ajoutent systématiquement des commentaires éphémères au lieu de faire quelque chose de concret et de réel. Ils ne participent en rien de matériel à la construction de quelque chose qui dure ; à l’inverse, ils observent passivement le travail des autres et se contentent de faire des commentaires à la blablablabla qui n’en finissent jamais en tournant des phrases dans un style complexe et tourmenté, de manière à se gonfler un peu l’ego. C’est pathétique.

C’est peut-être pour ça que cet article de SEO Black Hat m’a autant inspiré et motivé :

Do it F***ing Now.

Traduction :

P*tain, Fais Le Maintenant.

N’attends pas. Ne procrastine pas. Les vainqueurs ne sont pas ceux qui trouvent les meilleures excuses pour ne pas faire ce qu’ils savent comme un potentiel de gain d’argent. Les vainqueurs sont ceux qui savent organiser leurs priorités et remplir leurs journées.

Fais une liste des actions correspondantes aux tâches importantes et assure toi qu’elles soient réalisées. Tous les projets que tu as en tête devraient être en mouvement. Si tu n’avance pas, tu stagne.  Chaque pas que tu fais ne dois jamais se transformer en « pour le reste je m’y consacrerai la semaine prochaine ». Si ça peut te faire gagner de l’argent :

P*tain, Fais Le Maintenant.

Certains d’entre vous peuvent penser que le « P*tain » est en trop. C’est faux. Il vous faut l’impact. Il vous faut cette force, pour arriver à créer cet appel à agir, ce coup de pied au derrière qui va vous faire bouger. Sinon, vous allez finir comme la plupart des gros loosers qui avaient eu une super idée il y a longtemps mais qui n’ont jamais rien fait. Les rêveurs ne gagnent jamais d’argent. Ceux qui se bougent, si. Et ceux qui se bougent, p*tain, le font maintenant.

Note personnelle : cette suite d’expressions est intraduisible, mais j’aime bien

  1. Do it.
  2. Do it right.
  3. Do it right now.
  4. Do it f***ing right now.

vim : l'efficacité par la preuve directe

Depuis que j’ai vu ces vidéos, je sors avec plein de femmes, j’ai plein d’argent, et je suis aimé de la France entière.

Si vous parlez couramment l’Anglais, il faut absolument que vous voyez les vidéos de ce qu’il est possible de faire avec vim et qu’on n’a pas forcément en tête.

http://vimcasts.org/

Laissez d’autre sites en commentaire si vous avez des liens intéressants. Je n’hésiterai pas à les valider !

pygame : exemple de transparence

Voici un exemple simple pour gérer la transparence : cet exemple est très simple, il crée un petit carré qui suit la souris partout, et un autre « gros » carré qui apparait autour de la souris puis ne bouge plus, et dès que la souris sort de ce carré, hop, il fait un fondu au noir. Vous pouvez donc vous baser sur cet exemple pour comprendre comment transformer votre Surface en surface transparente destinée à être rapidement affichée à l’écran. Je parle de convert_alpha(). Avec cet appel, pour vous donner une idée, le temps pris est presque 40 fois plus rapide que sans l’appel. Vous pouvez tester par vous même !

Attention !
Le plus important c’est de faire dans l’ordre :

        self.image.set_alpha(valeur_transparence)
        pygame.Surface.convert_alpha(self.image)

Car l’ordre self.image.set_alpha(valeur_transparence) fera créer un masque au complet, et ce n’est qu’après qu’il vous faudra convertir la totale via pygame.Surface.convert_alpha(self.image).

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import os, pygame, sys, time, random, copy, pprint
from pygame.locals import *

class MySprite(pygame.sprite.Sprite):
    def __init__(self,width,height):
        # (!) Avant toute chose appeler le constructeur parent :
        pygame.sprite.Sprite.__init__(self)
        self.width = width
        self.height = height
        self.rect  = pygame.Rect(0, 0, width, height)
        self.image = pygame.Surface( (self.rect.width, self.rect.height) )
        self.image.set_colorkey((0,0,0))
        self.image.fill((0, 0, 0))

class SMouse(MySprite):
    def __init__(self,width,height):
        MySprite.__init__(self,width,height)
        pygame.draw.rect(self.image, (205,250,130), self.rect, 5)
        self.image = self.image.convert()

    def update(self):
        self.rect.topleft = pygame.mouse.get_pos()

class Contour(MySprite):
    def __init__(self,width,height,speed):
        MySprite.__init__(self,width,height)
        pygame.draw.rect(self.image, (105,250,230), self.rect, 5)
        self.fadeout = False
        self.speed = speed
        self.alpha = 250
        self.done = False
        self.image.set_alpha(self.alpha)
        # Convertir en transparent :
        pygame.Surface.convert_alpha(self.image)

    def update(self):
        if not self.fadeout:
            if not self.rect.collidepoint( pygame.mouse.get_pos() ):
                self.fadeout = True
        else:
            self.alpha -= self.speed
            if self.alpha<0:
                self.alpha = 0
                self.done = True
            self.image.set_alpha(self.alpha)

def main():
    pygame.init()
    pygame.mouse.set_visible(0)
    screen = pygame.display.set_mode( (0,0),
        pygame.FULLSCREEN | pygame.DOUBLEBUF | pygame.HWSURFACE )
    if pygame.display.Info().bitsize < 24:
        print "This game needs a 24 bits display"
        pygame.quit()

    background = pygame.Surface(screen.get_size())
    background = background.convert()
    background.fill((0, 0, 0))
    screen.blit(background, (0, 0))
    pygame.display.flip()
    clock = pygame.time.Clock()
    c = Contour(500, 500, 5)
    c.rect.center = pygame.mouse.get_pos()
    group_sprites = pygame.sprite.RenderPlain( [ SMouse(50, 50), c ] )

Linux mount : erreur 12. Solution à appliquer.

C’est la traduction d’un article trouvé ici.

Ci-suit comment appliquer un patch sur l’erreur assez commune « mount error 12 = Cannot allocate memory ».

[snip]
La bonne chose c’est que je l’ai corrigé, d’un point de vue Linux.
Et on est dans un groupe de discussion Linux.
Je vais donc être un bon citoyen (euh… « Internetoyen ») et expliquer comment j’ai fait afin d’aider éventuellement d’autres personnes qui se retrouveraient face à ce problème.
Il y a vraiment très peu de chose sur Internet, concernant ce sujet.

[snip]

Je fais mon article ici pour tous les autres qui pourraient être déstabilisés par cette erreur mount  :

mount error 12 = Cannot allocate memory

Ok, c’est qu’il devait sûrement y avoir quelque chose de mauvais dans la ligne de commande ou avec le système mount.cifs. C’est une erreur classique qui s’affiche sous Linux, lorsque vous tentez de monter un partage Windows XP, 2000, ou NT share et que ça ne fonctionne pas :

mount error 12 = Cannot allocate memory

Ce n’est pas un problème Linux… on s’en doute (sourire). Le problème vient de la machine Windows : c’est elle qui cause ce problème et qui refuse d’autoriser le « mount ». J’ai trouvé ce problème en faisant sous un terminal, tourner tail sur la liste des messages système d’un côté, et sous un autre terminal, tenter le mount pour voir quelles étaient les erreurs générées par la ligne de commande.

La commande qui génère l’erreur est :

[root@ohmster ~]# mount -t cifs //missy/ohmster_music /mnt/test -o username=my_user,password=my_password,rw
mount error 12 = Cannot allocate memory
Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)
[root@ohmster ~]#

Les résultats du tail qui m’ont montré l’erreur :

[root@ohmster samba]# tail -f /var/log/messages
Oct 23 21:15:40 ohmster kernel: CIFS VFS: cifs_mount failed w/returncode = -12
Oct 23 21:19:43 ohmster kernel: Status code returned 0xc0000205 NT_STATUS_INSUFF_SERVER_RESOURCES
Oct 23 21:19:43 ohmster kernel: CIFS VFS: cifs_mount failed w/return code = -12
[root@ohmster samba]#

Le message NT_STATUS est suffisamment explicite, c’est bel et bien la machine Windows qui est la cause du problème, pas la machine Linux.

Ci-suit comment appliquer un patch. Le patch Windows, bien sûr.

The Solution !

Regardez le log des Events sur la machine Windows machine qui pose problème. Cherchez une croix rouge, et le mot « Error » ou « Erreur ». La source est « Srv ». L’erreur ressemblera à :

The server's configuration parameter "irpstacksize" is too small for the server to use a local device. Please increase the value of this parameter.

Si vous avez cette erreur système sur la machine Windows, alors faites ce qui suit.

Modifiez (ou créez si nécessaire) la clé de registre :

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters\IRPStackSize

Si la clé n’est pas présente, créez une clé de type DWORD, appelez la IRPStackSize. Validez.

Ensuite, qu’elle soit présente, ou que vous l’ayez crée, la procédure est la même :

  • Double-cliquez dessus pour l’éditer ;
  • Mettez le bouton radio sur Décimal afin d’être sur que c’est une valeur décimale (et non pas hexadécimale) ;
  • Entrez la valeur 15 ;
  • Redémarrez la machine.
  • Si cela ne fonctionne toujours pas :
    • Montez la valeur à 18 ;
    • Redémarrez la machine une nouvelle fois.

Le problème est résolu. Allez faire vos montages partagés Samba l’esprit tranquille.


~Ohmster

Si vous avez des commentaires / suggestions, n’hésitez pas à laisser un message !