Re: Fwd: J'arrive pas à vider /lib pour une mise à jour du noyau

2018-05-24 Par sujet Pascal Hambourg 

Inutile de me mettre en copie, je lis la liste.

Le 24/05/2018 à 20:42, Paul Ezvan a écrit :


À noter qu'une "mise à jour" du noyau est différente d'une mise à jour 
d'un paquet standard, puisque généralement c'est un nouveau paquet qui 
est installé


Généralement une mise à jour du noyau Debian stable est une mise à jour 
du paquet linux courant, pas un nouveau paquet. Les exceptions sont une 
mise à niveau de la distribution et un changement d'ABI. La situation 
actuelle où il y a eu plusieurs changements d'ABI en peu de temps est 
exceptionnelle.


Pour un noyau ce qui prend de la place dans /lib ce sont les modules, le 
noyau lui-même étant installé dans /boot


Le modules font partie du noyau, ce qui est dans /boot n'est que l'image 
du noyau. Le tout est installé par un même paquet.

Re: Utilisation de la commande gem, installation d'Asciidoctor-diagram sur Debian

2018-05-24 Par sujet Étienne Mollier 
Bonsoir,

Olivier, le 2018-05-24 :
> Quelles sont les étapes à suivre, précautions à prendre,
> spécifiques à Debian, pour installer et maintenir "proprement"
> un programme installé avec gem ?

À moins d'avoir besoin spécifiquement de travailler avec la
dernière version fournie par les dépôts de Ruby Gems, la
première chose à faire est de vérifier si ledit programme n'est
pas, par hasard, disponible dans le dépôt Debian :

$ apt-cache search asciidoctor
asciidoctor - AsciiDoc to HTML rendering for Ruby
asciidoctor-doc - AsciiDoc to HTML rendering for Ruby (documentation)
ruby-asciidoctor - AsciiDoc to HTML rendering for Ruby (core libraries)
ruby-asciidoctor-plantuml - extension for Asciidoctor to enable support 
for PlantUML diagrams

et le cas échéant, de l'installer :

# apt install asciidoctor

Cela vous permet de bénéficier immédiatement de la gestion des
dépendances apportée par apt et de conserver un système
cohérent.  Si un paquet contenant le programme A dépend de
asciidoctor, mais que vous avez installé via gem un asciidoctor
« trop moderne » par rapport à A, il se peut que ce dernier soit
appelé à la place de celui fourni par Debian, et provoque un
crash lors de l'exécution de A.

Ceci est valable pour tous les autres gestionnaires de paquets
associés aux langages modulaires, non seulement les Ruby Gems,
mais aussi les Python Eggs, les modules Perl distribués par
CPAN, les Crates Rust, les paquets installés via les source,
etc.

Bon, dans notre cas, c'est dommage, asciidoctor est bien
présent dans le dépôt Debian, mais asciidoctor-diagram n'est pas
fourni, lui.  :-(


> Est-il possible et conseillé d'opérer en tant que root pour
> l'installation.

C'est toujours mieux de ne pas opérer en tant que root, quand
c'est possible.  :-)

Opérer en tant que root est la manière de procéder par défaut,
et en tant qu'utilisateur, ça coince :

$ gem install asciidoctor-diagram
Fetching: asciidoctor-1.5.7.1.gem (100%)
ERROR:  While executing gem ... (Gem::FilePermissionError)
You don't have write permissions for the /var/lib/gems/2.5.0 
directory.

Si vous lancez cette commande en tant que root, l'installation
aura lieu dans /usr/local, donc théoriquement dans une
arborescence qui n'est pas gérée par Debian (via l'installation
de paquets), mais par vous, administrateur du système.

Toutefois, si vous voulez dédier l'application à un utilisateur
donné, vous pouvez installer le paquet dans son répertoire home
comme suit :

$ gem install --user-install asciidoctor-diagram
Fetching: asciidoctor-1.5.7.1.gem (100%)
WARNING:  You don't have /home/asciidoctor/.gem/ruby/2.5.0/bin in your 
PATH,
  gem executables will not run.
Successfully installed asciidoctor-1.5.7.1
Fetching: asciidoctor-diagram-1.5.9.gem (100%)
Successfully installed asciidoctor-diagram-1.5.9
Parsing documentation for asciidoctor-1.5.7.1
Installing ri documentation for asciidoctor-1.5.7.1
Parsing documentation for asciidoctor-diagram-1.5.9
Installing ri documentation for asciidoctor-diagram-1.5.9
Done installing documentation for asciidoctor, asciidoctor-diagram 
after 4 seconds
2 gems installed

Comme indiqué par le message, il sera alors possible de lancer
asciidoctor soit en passant le chemin complet :

$ /home/asciidoctor/.gem/ruby/2.5.0/bin/asciidoctor

soit en réglant votre path pour aller récupérer les exécutables
de ce répertoire bin/ :

$ PATH="/home/asciidoctor/.gem/ruby/2.5.0/bin:$PATH"

À noter : le numéro de version dans le chemin est celui de la
commande gem.  Si vous la mettez à jour de sorte que le numéro
de version change, il faudra adapter votre path.

Quant au Gemfile et au bundle, il n'y aura pas de réglage
particulier à faire, ruby ira chercher directement dans ~/.gem/
ses dépendances :

$ echo "gem 'asciidoctor-diagram'" > Gemfile
$ bundle
Resolving dependencies...
Using asciidoctor 1.5.7.1
Using asciidoctor-diagram 1.5.9
Using bundler 1.16.1
Bundle complete! 1 Gemfile dependency, 3 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.

La page de man de gem est très succincte, en contrepartie les
commandes associées à gem sont relativement détaillées dans
l'aide en ligne intégrée.  Vous pouvez consulter les sorties des
commandes suivantes pour en savoir plus :

$ gem help
$ gem help commands
$ gem help install

En espérant que ça réponde à vos questions,
À plus,
-- 
Étienne Mollier

Re: Fwd: J'arrive pas à vider /lib pour une mise à jour du noyau

2018-05-24 Par sujet Paul Ezvan 

Le 23/05/2018 14:40, Pascal Hambourg a écrit :

Le 23/05/2018 à 09:13, kaliderus a écrit :


contre-partie est qu'il faut disposer d'un espace libre égal à la 
taille
occupée par le paquet. Pour le noyau 3.16 de Jessie, c'est environ 
160 Mio.


11 Mio est donc très insuffisant pour mettre à jour le noyau.


Ce que je n'explique pas c'est que l'espace qui sera utilisé n'a pas à
augmenter, le message est clair sur ce point.


Qu'est-ce qui n'est pas clair dans ce que j'ai expliqué ci-dessus ?

Pour faire une mise à jour d'un paquet, il faut disposer d'un espace
libre égal à la taille occupée par le paquet. Il faut donc 160 Mio
libres pour mettre à jour le noyau. Cet espace sera occupé
temporairement pendant la mise à jour pour installer les fichiers de
la nouvelle version du paquet puis libéré à la fin de la mise à jour
lorsque les fichiers de l'ancienne version du paquet seront supprimés.


À noter qu'une "mise à jour" du noyau est différente d'une mise à jour 
d'un paquet standard, puisque généralement c'est un nouveau paquet qui 
est installé, et donc le nouveau noyau consomme de la place en plus même 
après que apt ait terminé la mise à jour.

Peut-être as-tu des noyaux installés dont tu n'as plus besoin ?
Pour un noyau ce qui prend de la place dans /lib ce sont les modules, le 
noyau lui-même étant installé dans /boot (qui est soumis au même 
problème en cas de petite partition /boot).

Par exemple sur mon système j'ai pas mal de noyau installés on dirait:

% ls -l /lib/modules

total 24K
drwxr-xr-x 3 root root 4,0K oct.   2  2017 3.16.0-4-amd64/
drwxr-xr-x 2 root root 4,0K oct.   2  2017 3.2.0-4-amd64/
drwxr-xr-x 2 root root 4,0K mars   4 17:56 4.9.0-3-amd64/
drwxr-xr-x 2 root root 4,0K mars   4 17:56 4.9.0-4-amd64/
drwxr-xr-x 3 root root 4,0K janv.  7 02:35 4.9.0-5-amd64/
drwxr-xr-x 3 root root 4,0K mai6 00:01 4.9.0-6-amd64/

Tu peux trouver la taille occupée par chaque répertoire:

% du -h --max-depth=1 /lib/modules
163M/lib/modules/3.16.0-4-amd64
3,9M/lib/modules/4.9.0-4-amd64
2,9M/lib/modules/3.2.0-4-amd64
185M/lib/modules/4.9.0-5-amd64
188M/lib/modules/4.9.0-6-amd64
3,9M/lib/modules/4.9.0-3-amd64
546M/lib/modules

On remarque que certains prennent peu de place, en fait ces noyaux ont 
été désinstallés mais il reste les fichiers générés par la commande 
depmod (non contenus dans le paquet, générés par un script 
post-install):


% ls /lib/modules/3.2.0-4-amd64
modules.alias  modules.alias.bin  modules.builtin.bin  modules.dep  
modules.dep.bin  modules.devname  modules.softdep  modules.symbols  
modules.symbols.bin


% uname -r
4.9.0-5-amd64

Le noyau courant est le 4.9.0-5-amd64, donc je peux probablement 
désinstaller le noyau 3.16.0-4-amd64 pour faire de la place. Pour cela 
je dois spécifier la version à supprimer:


% sudo apt remove linux-image-3.16.0-4-amd64

Paul

Re: Fwd: J'arrive pas à vider /lib pour une mise à jour du noyau

2018-05-24 Par sujet Paul Ezvan 

Le 23/05/2018 14:40, Pascal Hambourg a écrit :

Le 23/05/2018 à 09:13, kaliderus a écrit :


contre-partie est qu'il faut disposer d'un espace libre égal à la 
taille
occupée par le paquet. Pour le noyau 3.16 de Jessie, c'est environ 
160 Mio.


11 Mio est donc très insuffisant pour mettre à jour le noyau.


Ce que je n'explique pas c'est que l'espace qui sera utilisé n'a pas à
augmenter, le message est clair sur ce point.


Qu'est-ce qui n'est pas clair dans ce que j'ai expliqué ci-dessus ?

Pour faire une mise à jour d'un paquet, il faut disposer d'un espace
libre égal à la taille occupée par le paquet. Il faut donc 160 Mio
libres pour mettre à jour le noyau. Cet espace sera occupé
temporairement pendant la mise à jour pour installer les fichiers de
la nouvelle version du paquet puis libéré à la fin de la mise à jour
lorsque les fichiers de l'ancienne version du paquet seront supprimés.


À noter qu'une "mise à jour" du noyau est différente d'une mise à jour 
d'un paquet standard, puisque généralement c'est un nouveau paquet qui 
est installé, et donc le nouveau noyau consomme de la place en plus même 
après que apt ait terminé la mise à jour.

Peut-être as-tu des noyaux installés dont tu n'as plus besoin ?
Pour un noyau ce qui prend de la place dans /lib ce sont les modules, le 
noyau lui-même étant installé dans /boot (qui est soumis au même 
problème en cas de petite partition /boot).

Par exemple sur mon système j'ai pas mal de noyau installés on dirait:

% ls -l /lib/modules

total 24K
drwxr-xr-x 3 root root 4,0K oct.   2  2017 3.16.0-4-amd64/
drwxr-xr-x 2 root root 4,0K oct.   2  2017 3.2.0-4-amd64/
drwxr-xr-x 2 root root 4,0K mars   4 17:56 4.9.0-3-amd64/
drwxr-xr-x 2 root root 4,0K mars   4 17:56 4.9.0-4-amd64/
drwxr-xr-x 3 root root 4,0K janv.  7 02:35 4.9.0-5-amd64/
drwxr-xr-x 3 root root 4,0K mai6 00:01 4.9.0-6-amd64/

Tu peux trouver la taille occupée par chaque répertoire:

% du -h --max-depth=1 /lib/modules
163M/lib/modules/3.16.0-4-amd64
3,9M/lib/modules/4.9.0-4-amd64
2,9M/lib/modules/3.2.0-4-amd64
185M/lib/modules/4.9.0-5-amd64
188M/lib/modules/4.9.0-6-amd64
3,9M/lib/modules/4.9.0-3-amd64
546M/lib/modules

On remarque que certains prennent peu de place, en fait ces noyaux ont 
été désinstallés mais il reste les fichiers générés par la commande 
depmod (non contenus dans le paquet, générés par un script 
post-install):


% ls /lib/modules/3.2.0-4-amd64
modules.alias  modules.alias.bin  modules.builtin.bin  modules.dep  
modules.dep.bin  modules.devname  modules.softdep  modules.symbols  
modules.symbols.bin


% uname -r
4.9.0-5-amd64

Le noyau courant est le 4.9.0-5-amd64, donc je peux probablement 
désinstaller le noyau 3.16.0-4-amd64 pour faire de la place. Pour cela 
je dois spécifier la version à supprimer:


% sudo apt remove linux-image-3.16.0-4-amd64

Paul

Utilisation de la commande gem, installation d'Asciidoctor-diagram sur Debian

2018-05-24 Par sujet Olivier 
Bonjour,

La page [1] indique une installation d'Asciidoctor-diagram par:
gem install asciidoctor-diagram

Quelles sont les étapes à suivre, précautions à prendre, spécifiques à
Debian, pour installer et maintenir "proprement" un programme installé avec
gem ?

Est-il possible et conseillé d'opérer en tant que root pour l'installation


[1] https://asciidoctor.org/docs/asciidoctor-diagram/

Slts

Auto-complétion d'URL avec Firefox ESR/Chromium sur Jessie ou Stretch

2018-05-24 Par sujet Olivier 
Bonjour,

Connaissez-vous un mécanisme d'auto-complétion ou équivalent, utilisable
dans Firefox et Chromium qui permette l'auto-complétion du nom de domaine.
Ce mécanisme est-il factorisable avec celui de bash ?

Exemple, dans mon fichier /etc/hosts, ou mieux avec un serveur dns local,
j'ai défini l'entrée:
192.168.12.12 foobar toto

Quand dans ma barre d'URL, je saisi foo+TAB ou tot+TAB (TAB étant la touche
de tabulation), mon navigateur complète intelligemment ma saisie.

J'imagine qu'on peut tromper le navigateur en ajoutant par programme des
entrées dans l'historique de navigation.

Slts