Étiquette : geekeries

Aperçu rapide de la Zenwalk 6.4 beta 1

La ZenWalk, c’est un mélange de Slackware Linux avec Xfce. Ayant lu sur distrowatch l’arrivée d’une nouvelle version béta remplie de nouveautés (dont un noyau très récent), j’ai décidé d’y jeter un oeil.

J’en avais déjà parlé à l’époque de la première RC de la version 6.0, ce qui remonte à mars 2009.

J’ai donc utilisé l’outil wget pour récupérer une image iso de cette distribution en 32 bits.

fred@frugalware:~/download$ wget -c http://chronos.iut-bm.univ-fcomte.fr/distributions/zenwalk/people/jp/28032010/zenwalk-6.4beta.iso
–2010-04-01 07:00:01– http://chronos.iut-bm.univ-fcomte.fr/distributions/zenwalk/people/jp/28032010/zenwalk-6.4beta.iso
Résolution de chronos.iut-bm.univ-fcomte.fr (chronos.iut-bm.univ-fcomte.fr)… 193.52.61.12
Connexion vers chronos.iut-bm.univ-fcomte.fr (chronos.iut-bm.univ-fcomte.fr)|193.52.61.12|:80…connecté.
requête HTTP transmise, en attente de la réponse…206 Partial Content
Longueur: 540936192 (516M), 540723200 (516M) restant [application/x-iso9660-image]
Sauvegarde en : «zenwalk-6.4beta.iso»

100%[======================================>] 540 936 192 710K/s ds 12m 57s

2010-04-01 07:12:58 (680 KB/s) – «zenwalk-6.4beta.iso» sauvegardé [540936192/540936192]

J’ai ensuite utilisé la machine virtuelle habituelle en utilisant les lignes de commande suivantes :


fred@frugalware:~/download$ qemu-img create -f qcow2 zen.img 32G
Formatting 'zen.img', fmt=qcow2 size=34359738368 encryption=off cluster_size=0
fred@frugalware:~/download$ kvm32 -hda zen.img -cdrom zenwalk-6.4beta.iso -boot d &

kvm32 est le raccourci pour la commande suivante :


qemu --enable-kvm -m 1500 -soundhw all -localtime -k fr

Après un démarrage en mode texte, on arrive directement sur l’outil d’installation.

Zenwalk 6.4 beta 1

Continuer la lecture de « Aperçu rapide de la Zenwalk 6.4 beta 1 »

Double claque pour Microsoft ?

Je publie volontairement ce billet le 31 mars, pour éviter d’être accusé de faire un gros poisson d’avril.

Première claque : SCO encore débouté sur ses prétentions sur Unix.

Pourquoi est-ce que je dis que c’est Microsoft qui se prend une claque ? Il faut se souvenir que SCO Unix s’appellait à l’origine Microsoft Xenix…

Et que Microsoft a soutenu SCO au début de l’affaire SCO contre Novell… En 2004 !

Deuxième claque : elle concerne Windows et sa conception même. Car il faut se souvenir qu’entre 1985 (sortie de MS Windows 1.0) et Windows Vista – début 2007 – une faille énorme de sécurité a existé : le premier compte avait des droits administrateurs, root en langage unix.

Or, toute personne qui a utilisé un unix ou un BSD dans sa vie sait une chose : un compte root, cela ne s’utilise que pour des taches administratives. D’ailleurs, en 2009, Microsoft a déposé un brevet sur une procédure qui copie la commande Sudo qui existe depuis… 1980 ! l

Un rapport récemment publié annonce qu’un minimum de 64% des failles comblées dans MS Windows l’année dernière étaient inactivées par l’utilisateur d’un compte utilisateur normal, en clair n’ayant pas les droits administrateurs (ce qui est par défaut le cas sur les windows jusqu’à Vista).

Si on prend le cas d’Internet Explorer, les failles sont désactivées à hauteur de… 94%…

Bref, un rapport annonce ce que les utilisateurs d’unix savent depuis environ 30 ans… Ne pas utiliser un compte root réduit les risques d’attaques dans une proportion énorme, de l’ordre de 90 à 95%

Comme disait Henry Spencer , « Those who do not understand Unix are condemned to reinvent it, poorly. » ce qu’on peut traduire par « Ceux qui ne comprennent Unix sont condamné à le réinventer, malheureusement en moins bien. »

Avec UAC (qui ressemble à sudo et sur KDESu / GKSu), que fait Microsoft au final ? 😉

L’histoire – en cours – d’un bug vicieux : le bug 4145 de la Frugalware Linux.

Comme toute histoire, il faut un commencement. Ce commencement, c’est le 17 mars qu’il arrive.

Ce jour là, arrive la version 1.7.6 du paquet xorg-server. Faisant la mise à jour du paquet et redémarrant ma session, je m’aperçois que compiz ne se lance plus. J’avais déjà parlé de ce problème.

Horreur, plus de fenêtres molles, de zolies animations lors de la réduction des fenêtres.

Je ferme l’icone de Fusion-Icon qui s’occupe de lancer Compiz, et je la relance en utilisant le terminal et je tombe sur un simple message d’erreur :

fred@frugalware:~$ fusion-icon &
[1] 3493
fred@frugalware:~$ * Detected Session: gnome
* Searching for installed applications...
* NVIDIA on Xorg detected, exporting: __GL_YIELD=NOTHING
* Using the GTK Interface
* Starting Compiz
... executing: compiz --replace --sm-disable --ignore-desktop-hints ccp
compiz (core) - Fatal: No damage extension

J’ouvre donc un rapport de bug, histoire de faire connaître le problème, le bug 4145.

Mon premier réflexe est de vérifier si un bug de ce style est connu, et je tombe sur quelque chose d’équivalent sur le suivi de bugs de la mandriva sur le bug 57889.

Mais le correctif proposé ne change rien.

Le seul correctif que je trouve, est plus un contournement qu’autre chose : rétrograder la version de xorg-server, en utilisant la 1.7.5 qui fonctionnait parfaitement. Et en la réinstallant, Compiz revient à la vie.

Je me dis alors que ce doit être un bug du pilote propriétaire nvidia, et je me débrouille pour empaqueter la nouvelle version, la 195.36.15. Mais aucun changement quand je repasse à la version 1.7.6 de xorg-server.

Entre temps, devil505 parle de mon problème dans son billet du 20 mars. J’ai droit par la même occasion d’être le premier lauréat du prix Cyrille de la semaine.

Le 23 mars, Hermier qui s’occupe du pilote nvidia se décide à me donner un coup de main. Et depuis 4 soirs, tout a été essayé, en essayant rester exhaustif :

  • Recréer le fichier xorg.conf avec le pilote récent et xorg-server 1.7.6
  • Désactiver xinerama et record dans le fichier xorg.conf
  • Utiliser des versions de xorg-server 1.7.6 avec des correctifs suspects
  • Empaqueter de manière officielle le dernier pilote propriétaire nvidia
  • Utiliser l’option composite de gnome
  • Recompilation de Xorg-Server aussi bien en local qu’avec l’aide de bouleetbil et d’hermier
  • Enlever le module nouveau du noyau à la sauvage
  • Mettre à jour la version de libdrm
  • Recompiler libxdamage
  • Rétrograder dri2proto

Les logs du canal irc #frugalware.fr 25 mars, du 26 mars – , et du 27 mars, liste tout ce qui a été tenté.

Maintenant, je dois avouer que je suis à court d’idées devant un tel bug, aussi vicieux…

Mieux vaut en rire qu’en pleurer, au final, et j’espère que ce billet permettra d’apporter des idées nouvelles pour mettre à mort ce bug qui me facilite un brin le transit intestinal dans ma vie d’utilisateur d’informatique libre.

Un espoir serait peut-être l’arrivée de la version 1.8.0 de Xorg-server, prévue pour la fin du mois.

Qui vivra verra !

2 bugs à la c** en une semaine sur ma Frugalware-current…

En l’espace de quelques jours, j’ai été confronté à deux bugs à la c** sur ma Frugalware Linux, en version current. Je connais les « risques et les joies » d’une distribution en rolling-release, donc c’est assez normal que cela arrive. Mais je dois être comme Cyrille Borne, je dois attirer les bugs 😉

Et les deux sont suite à des mises à jours majeures de paquets. Le premier, le bug 4145 concerne un bug lié au passage à xorg-server 1.7.6 qui tue purement et simplement la composition sous Xorg avec le pilote propriétaire Nvidia. Après avoir rapporté le bug et posté un message sur le forum francophone de la Frugalware, je ne suis pas le seul à être apparemment concerné.

Ce n’est pas trop ennuyeux dans l’absolu, mais  quand on est devenu accroc aux fenêtres molles de Compiz-Fusion…

L’autre bug que j’ai rapporté est cependant plus handicapant, car il empêche purement et simplement d’imprimer quoique ce soit avec mon imprimante HP PhotoSmart C3180. C’est le bug 4148. Devant imprimer un document, j’ai alors essayé de lancer l’outil HP-Toolbox, mais rien ne s’affichait. En lançant l’outil en ligne de commande, j’ai droit à ceci :


fred@frugalware:~$ hp-toolbox &
[1] 32677
fred@frugalware:~$ Traceback (most recent call last):
File "/usr/bin/hp-toolbox", line 39, in
from base import status, tui, module
File "/usr/share/hplip/base/status.py", line 40, in
import hpmudext
ImportError: libnetsnmp.so.15: cannot open shared object file: No such file or directory

Un fichier manquant ? En rétrogradant le paquet net-snmp, comme par miracle, l’outil HP-Toolbox est redevenu fonctionnel…

C’est quand même étrange qu’un bug aussi gros que celui-ci soit passé inaperçu durant près d’une semaine, car le paquet net-snmp fautif a été mis en ligne le 14 mars…

Au moins, les bugs ont été signalés, on verra le temps qui sera mis pour les faire disparaître 😉

Mon premier FrugalBuild – avec sa version « modifiée »

A peine une journée sous Frugalware Linux, et voici que je propose mon premier FrugalBuild. En me basant sur le travail de Jercel pour Liferea, j’ai empaqueté la version subversion de Liferea.

# Based on Jercel work for liferea-stable.

pkgname=liferea-svn
pkgver=5302
pkgrel=1
pkgdesc= »Liferea is a news aggregator for online news feeds. »
license= »GPL2″
groups=(‘gnome-extra’)
archs=(‘i686’ ‘x86_64’)
depends=(‘gconf’ ‘libxslt’ ‘libglade’ ‘webkit’ ‘libice’ ‘libnotify’ ‘atk’ ‘libxau’ ‘libxdmcp’ ‘zlib’ \
‘libxinerama’ ‘libxi’ ‘libxrandr’ ‘libxcursor’ ‘libxdamage’ ‘libjpeg’ ‘libxt’ ‘e2fsprogs’ ‘libgcc’ ‘lua’ ‘unique’)
makedepends=(‘intltool’)
options=(‘scriptlet’)
replaces=(‘liferea’)
_F_gnome_schemas=(‘/etc/gconf/schemas/liferea.schemas’)
_F_gnome_desktop= »y »
_F_gnome_iconcache= »y »

_F_scm_type= »subversion »
_F_scm_url= »https://liferea.svn.sourceforge.net/svnroot/liferea/trunk »
_F_scm_module= »liferea »
Finclude scm
build()
{
Funpack_scm
cd liferea
autoreconf -i
intltoolize
sh autogen.sh
./configure
Fbuild
}

# optimization OK

Bien que ce soit encore assez « sale », c’est déjà un premier pas 🙂

J’attends les commentaires de Jercel et bien entendu de Devil505 sur ce premier paquet. Prochaine étape ? Gthumb-git 😉

Ajout du 16 février :

Voici une version « plus propre » du fichier, d’après les conseils éclairés de Devil505 et d’Exceed.

# Based on Jercel work for liferea-stable.
# Just to make a package for frugalware and my own fun.
# Only tested on x86_64 🙂
# Basé sur le travail de Jercel pour Liferea-stable
# Dans le but de faire un paquet pour frugalware et mon propre plaisir.
# Uniquement testé sur x86_64

pkgname=liferea-svn
pkgver=5302
pkgrel=1
pkgdesc= »Liferea is a news aggregator for online news feeds. »
license= »GPL2″
groups=(‘gnome-extra’)
archs=(‘x86_64’)
depends=(‘gconf’ ‘libxslt’ ‘libglade’ ‘webkit’ ‘libice’ ‘libnotify’ ‘atk’ ‘libxau’ ‘libxdmcp’ ‘zlib’ \
‘libxinerama’ ‘libxi’ ‘libxrandr’ ‘libxcursor’ ‘libxdamage’ ‘libjpeg’ ‘libxt’ ‘e2fsprogs’ ‘libgcc’ ‘lua’ ‘unique’)
makedepends=(‘intltool’)
options=(‘scriptlet’)
replaces=(‘liferea’)
_F_gnome_schemas=(‘/etc/gconf/schemas/liferea.schemas’)
_F_gnome_desktop= »y »
_F_gnome_iconcache= »y »

_F_scm_type= »subversion »
_F_scm_url= »https://liferea.svn.sourceforge.net/svnroot/liferea/trunk »
_F_scm_module= »liferea »
Finclude scm
build()
{
Funpack_scm
cd liferea
Fautoreconf
intltoolize || Fdie
Fconf
Fbuild
}

# optimization OK

Pour les codeurs de gwibber, ubuntu n’est que la seule distribution à gérer ?

Je parlais il y a quelque jours de la nouvelle version de Gwibber, qui paraissait bien alléchante, malgré l’ajout d’une couche supplémentaire de dépendance, répondant au nom de Desktopcouch qui installe une bonne dizaine de paquets supplémentaires.

Il y a 5 jours, arrive la révision 503, qui part d’une bonne idée. Comme desktopcouch est indispensable au fonctionnement de cette version de gwibber, autant vérifier qu’elle démarre avant gwibber… Et patatras… Gwibber se viande en beauté au démarrage, balançant une erreur qui met clairement en cause desktopcouch :

Traceback (most recent call last):
File « /usr/bin/gwibber », line 45, in
obj = dbus.SessionBus().get_object(« org.desktopcouch.CouchDB », « / »)
File « /usr/lib/python2.6/site-packages/dbus/bus.py », line 244, in get_object
follow_name_owner_changes=follow_name_owner_changes)
File « /usr/lib/python2.6/site-packages/dbus/proxies.py », line 241, in __init__
self._named_service = conn.activate_name_owner(bus_name)
File « /usr/lib/python2.6/site-packages/dbus/bus.py », line 183, in activate_name_owner
self.start_service_by_name(bus_name)
File « /usr/lib/python2.6/site-packages/dbus/bus.py », line 281, in start_service_by_name
‘su’, (bus_name, flags)))
File « /usr/lib/python2.6/site-packages/dbus/connection.py », line 622, in call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1

[1]+ Exit 1 gwibber

Un bug dédié est ouvert, mais impossible de faire comprendre la culpabilité de la révision citée au-dessus. Tant que cela fonctionne avec Ubuntu, les autres distributions, vous savez où vous pouvez aller ?

J’ai donc pris le taureau par les cornes, et j’ai adopté le paquet qui permettait à une époque de compiler Gwibber 2.0 sur Archlinux. Ayant corrigé le PKGBUILD en question, désormais – même si la branche 2.0 de Gwibber n’aura plus de mise à jour, au moins, il y aura un gwibber fonctionnel sur Archlinux !

C’est quand même assez écoeurant de voir un tel manque de respect envers les non-utilisateurs d’ubuntu… Je sens que je vais me faire traiter de tous les noms, mais comme les infos sont disponibles…

En vrac’ rapide et libre

Un petit en vrac’ rapide et libre.

gwibber 2.29.1 sous Archlinux

C’est tout pour aujourd’hui 🙂

Test rapide de la Omega Fedora Remix 12, l’autre linux mint du monde Fedora.

Dans un précédent article j’ai taillé un costume 3 pièces à un remix de la Fedora, la Fedora Community Remix. J’ai ensuite appris l’existence d’une autre linux mint du monde Fedora, j’ai nommé l’Omega Fedora Remix.

Après avoir téléchargé l’image iso de la distribution en question depuis le site officiel j’ai lancé une machine virtuelle virtualbox pour tester l’engin.

Au premier démarrage, l’écran nous parle d’un « generic 12 » peu avenant. Cependant, la distribution – uniquement 32 bits pour le moment est franchement l’opposé de sa consoeur. Elle est légère, agréable, bref, bien conçu.

Déjà, la connexion automatique est gérable, et on peut tranquillement choisir clavier et langage à l’utilisation 😉

L’installation se passe sans problème. Le seul gros hic, c’est le nombre de paquets qui demande à être mis à jour ! Plus de 300 corrections, alors que l’image de base est dérivée de la fedora 12 + correctifs jusqu’au 14 décembre :

« This release is a remix of Fedora 12 and includes all the updates till Monday 14th of December 2009 from Fedora, RPM Fusion and Livna repositories. »

Une grosse partie des mises à jour viennent d’ailleurs des dépots tiers comme rpm-fusion ou encore livna.

Après le redémarrage, un Gnome 2.28.2 nous accueille.

Malgré cela, on sent que le travail a été fourni pour que la distribution reste légère et agréable à l’emploi. Seul point noir : l’absence de flash… Mais comme on peut l’installer facilement…

Pour tout dire, j’avoue que j’ai été des plus agréablement surpris par cette distribution qui redore un peu le blason des versions remix de la Fedora Linux.

A suivre de près, donc.

Fedora Community 12.1 Remix : la « linux mint » ratée du monde fedora ?

Dans le monde d’Ubuntu Linux, la Linux Mint est une version « aux hormones » de la Ubuntu Linux : en plus de la distribution mise à jour, il y a l’ensemble pour la lecture des formats propriétaires (mp3, flash et compagnie) qui ne sont pas activés par défaut dans la Ubuntu Linux de base, en plus d’un outil amélioré pour la gestion des paquets.

Comme la route de l’enfer est pavée de bonnes intention, le groupe derrière la Fedora Community 12.1 remix est parti d’un principe simple : la fedora de base, avec le maximum de paquets du dépot rpm fusion (qui offre la lecture des formats propriétaires). En utilisant le principe du remix qui est chez Fedora les versions dérivées non officiellement supportées, un peu à l’image de la Linux Mint pour Canonical.

Fedora Community Remix 12.1

Continuer la lecture de « Fedora Community 12.1 Remix : la « linux mint » ratée du monde fedora ? »

L’avenir des distributions linux à destination du « bureau » appartient-il aux « rolling releases » ?

Il y a un peu plus de deux mois, je faisais un article fortement commenté (55 commentaires !) sur lequel j’exprimais mon point de vue en ce qui concerne le modèle de publication semestrielle des distributions actuelles.

Je me cite :

Je me demande si l’avenir n’est pas plus dédié à des distributions qui proposent à un instant T une version installable, puis qui serait continuellement mise à jour, à l’image de ce que propose ArchLinux ou encore la version de développement de la Frugalware Linux.

Car l’informatique – libre ou pas – est en constante évolution. Et ce qui semblait être le haut de gamme se retrouve 6 mois plus tard complètement obsolète. Je ne prétends pas détenir la vérité, mais j’ai pu constater depuis mon retour sur Archlinux (en mai 2009) que je n’ai jamais prise la distribution à défaut. Et j’ai connu quand même 4 versions majeures du noyau (de la 2.6.28.x à la 2.6.31.5 actuellement), deux générations de Gnome (la 2.26 et la 2.28), sans oublier une nouvelle génération d’OpenOffice.org.

En gros, on peut rajouter une génération de noyau de plus avec l’arrivée entre temps du noyau 2.6.32.x

Si je déterre la hache de guerre, c’est pour citer le cas d’un outil qui est devenu dans notre informatique actuelle le nerf de la guerre : le navigateur internet, et dans notre cas, Mozilla Firefox qui est sorti en version 3.6 assez récemment.

Même si – au moment où j’écris cet article – la version 3.6 n’est pas la version officiellement disponible sur archlinux stable, elle est toujours disponible dans le dépot « testing »

fred ~ $ yaourt -Si firefox
Dépôt : testing
Nom : firefox
Version : 3.6-2
URL : http://www.mozilla.org/projects/firefox
Licences : MPL GPL LGPL
Groupes : —
Fournit : —
Dépend de : xulrunner=1.9.2 desktop-file-utils
Dépendances opt. : —
Est en conflit avec : —
Remplace : firefox3
A télécharger : 1017,93 K
Taille (installé) : 3676,00 K
Paqueteur : Biru Ionut
Architecture : x86_64
Compilé le : jeu. 21 janv. 2010 22:47:31 CET
somme MD5 : 29c91c303201d5da689c07304dd3e03d
Description : Standalone web browser from mozilla.org

Donc d’ici quelques jours, si je le désire, ma machine pourra utiliser Mozilla Firefox 3.6 sans passer par le dépot testing.

Voyons donc comment les grands noms des distributions linux ont géré le passage de la version 3.0 à 3.5 de Mozilla Firefox, qui sauf grand changement stratégique appliqueront la même politique pour la transition Mozilla Firefox 3.5 vers la version 3.6. A savoir : une nouvelle version majeure de Mozilla Firefox sera disponible dans la future nouvelle version stable.

Je vais prendre les trois principaux noms : Fedora, Ubuntu et OpenSuSE. Et prendre chaque version qui correspond au passage de la version 3.0 à la version 3.5 de Mozilla Firefox, à savoir :

  • Fedora 10
  • Ubuntu 9.04
  • OpenSuSE 11.1

Je me suis basé sur ce choix en utilisant la page suivante sur le site Distrowatch : http://distrowatch.com/dwres.php?resource=major

Continuer la lecture de « L’avenir des distributions linux à destination du « bureau » appartient-il aux « rolling releases » ? »