Pour feh, le ctrl+direction est un peu pénible pour bouger, mais en contre-partie tu as le zoom avec Haut/Bas, et en général ça (me ?) suffit.

Quand je fais display de mon jpeg de 20MB, mon serveur X panique completement.

et feh n'arrive pas a le lire:

erik@powell:/tmp$ feh apc_8_0gpu_15cpu_16384_16384_0_1_gantt_chart.jpg
feh WARNING: apc_8_0gpu_15cpu_16384_16384_0_1_gantt_chart.jpg - No Imlib2 loader for that file format
feh - No loadable images specified.
Use feh --help for detailed usage information
erik@powell:/tmp$ file apc_8_0gpu_15cpu_16384_16384_0_1_gantt_chart.jpg
apc_8_0gpu_15cpu_16384_16384_0_1_gantt_chart.jpg: JPEG image data, JFIF standard 1.01
erik@powell:/tmp$

mmm, en vrai si je convertis le jpeg en png avec convert, feh ne peut toujours pas l'ouvrir a cause d'erreur de crc. Peut etre que mon jpeg en entre est merdique.

J'utilise feh pour ma part ;)

J'utilise feh également, pour visionner des images seules, des dossiers complets ( -F -S name) et appliquer un fond d'écran. J'ai déjà rencontré ce problème de "No Imlib2 loader for that file format ", c'est fort possible que le jpg ait un problème, j'avais déjà eu le coup avec d'autres formats d'image..

je pense qu'on peut faire plus propre en jouant correctement avec l'initrd et en remplissant le vrai /var/run après coup

Caser "propre" et "initrd" dans la même phrase, fallait le faire

Re-enable bce(4) now that it is fixed.

Plus d'excuses, chris

J'ai plein de messages de ce genre au boot de mes Debian-likes : ata 2.00 : exception Emask 0X100 Sact 0X0 SErr 0X0 action 0X6

Quelqu'un saurait-il comment les enlever s'il vous plaît ? Et pourquoi ça ne s'affiche qu'avec les Debian-likes (debian, ubuntu, linuxmint...) ?

Je sais que ça à un rapport avec mon DD (il est défectueux depuis 2 ans).

Salut !
J'aurais besoin d'un immense service ....
L'un de vous connais ce genre de hash :

äâ!äé#äé#äé#ùe~@éf?ùe~504äâ!äé#682êe^8068689601056
êe^14401197ùe~@äê%ùe~äë&1650äê%1755184817691950êe^

Si oui, comment crypter et casser ce genre que je ne connais pas ?

Pkgsrc fait un pas de plus dans la bonne direction (celle de l’utilisabilité). Il semblerait que la branche 2011Q1 soit la dernière à fournir des packages ne supportant pas la variable DESTDIR. Grosso modo DESTDIR permet de réaliser la compilation des packages dans un sous-répertoire du WRKDIR et donc de construire les packages sans toucher à l’arbo de prod. (typiquement /usr/pkg). Jusqu’à présent, lors d’un upgrade, le processus consistait à dégager le paquet à mettre à jour, compiler la nouvelle version et l’installer. En cas d’échec, on se retrouver le bec dans l’eau. La solution retenue par la plupart des utilisateurs de pkgsrc consistait à construire les packages dans un chroot, puis de les installer. Comme ça en cas d’échec de compilation, on pouvait quand-même continuer à bosser sur les vieilles versions non mises à jour. Efficace mais très lourd et peu pratique. Grâce au support complet de DESTDIR, on n’aura plus besoin de chroot.
Il ne manquera alors plus qu’une cible d’upgrade de tous les packages bien foutue et pkgsrc deviendra enfin utilisable.

http://mail-index.netbsd.org/tech-pkg/2011/04/05/msg006932.html trouvé via http://www.shiningsilence.com/dbsdlog/2011/04/05/7558.html

« ata 2.00 : exception » ton disque dur est mort, non ?
« Je sais que ça à un rapport avec mon DD (il est défectueux depuis 2 ans). » bah, voilà…

Il y a peut-être une option obscure à donner au noyau pour faire taire le module en question. Mais :
1) comment la trouver si tant est qu'elle existe ?
2) je ne te le conseille pas.

Disons que mon DD est un mort-vivant.

Ce n'est pas grave, je vais faire avec.

http://marc.info/?l=openbsd-cvs&m=130213471205901&w=2

Prend ça dans les dents, git

Sauf que changer des messages de commit avec git ça se fait assez bien avec amend + rebase de mémoire.

$ git help amend
man: no entry for gitamend in the manual.

C'est une option de "git commit".

Je vois, ça marche si on a déjà push ça ?

Vous suivez un peu l'actualité de Capsicum ?

tu peux rebase apres avoir pusher, mais il faut etre pres a recevoir les insultes de tous les autres developpeurs

La semantique de git est que une fois que c'est pushe upstream, c'est complique de changer. Les developpeurs sont cense faire le menage AVANT de pousser upstream.

"Gnome GNOME 3.0 : le grand saut !

L’environnement de bureau du projet GNU a livré sa version 3.0, tant attendue. Contrairement au poisson d’avril de Vincent Untz, la version 3.0 n’est pas repoussée une troisième fois !"

Source et suite http://linuxfr.org/news/gnome%C2%A030%C2%A0-le-grand-saut

Vous aussi, faîtes le grand saut.

Ou pas...