La version 0.5, qui vient de sortir, supporte la majorité des formats de fichier « courants ». Cela va de l'image PNG à la vidéo AVI en passant par les archives bzip2 ou encore le système de fichier ext2. Par contre, tous les parseurs ne sont pas encore complets : les zones inconnues sont marquées « raw ».
Le parseur a un fonctionnement totalement paresseux : les informations ne sont lues que lorsqu'elles sont demandées, et les champs ne sont crées que lorsque c'est nécessaire. Il est dès lors possible de lire des fichiers complexes et/ou de grande taille (ex: disque dur de 10 Go).
Hachoir est avant tout une bibliothèque écrite en Python, mais plusieurs scripts l'utilisant sont disponibles. hachoir-metadata permet d'extraire les méta-données : durée d'une musique, taille d'une image, commentaires, etc. hachoir-urwid est une interface interactive permettant d'explorer le contenu d'un fichier. hachoir-grep permet de rechercher une chaîne de caractère dans un fichier, ou simplement lister toutes les chaînes d'un fichier.
NdM : Hachoir est disponible sous licence GNU/GPL Nouveautés de la version 0.5
Le script "hachoir" a été découpé en plusieurs scripts plus spécifiques : chaque script a maintenant ses propres options. En particulier, le script hachoir-metadata gagne les options --level et --mime (et accepte plusieurs fichiers en entrée), hachoir-urwid gagne les option --preload et --path. Création du script hachoir-grep. Ajout des parseurs ASF (vidéo WMV et musique WMA), MOV (vidéo Quicktime), CDA (cd audio sous Windows). Ajout d'un extracteur de méta-données pour le format Matroska. Meilleure gestion des charsets pour les chaînes de caractères : elles sont maintenant stockées en Unicode. Création d'un jeu de fichiers permettant d'automatiser les tests sur Hachoir.
Cette nouvelle version marque également le début du support des containers, soit essentiellement : archives, systèmes de fichiers et containers multimédia. En plus de la structure de ces formats, on peut vouloir analyser le contenu, alors même que celui-ci est fragmenté.
La liste complète des nouveautés est disponible sur le wiki.
On recrute !
Hachoir aurait besoin :
- d'être packagé (Debian, Gentoo, etc.) ;
- d'une interface graphique (Gtk ou Qt, pygtk/pyqt) ;
- de meilleurs parseurs et de plus de parseurs.
Contactez nous si vous êtes intéressés
Aller plus loin
- Site officiel du projet Hachoir (192 clics)
- Informations sur l'installation d'Hachoir (48 clics)
- Liste des parseurs disponibles (33 clics)
- Liste des nouveautés (8 clics)
- DLFP : Journaux de l'auteur annonçant Hachoir (26 clics)
- DLFP : Précédente dépêche sur Hachoir (5 clics)
# Souvenir...
Posté par ThesmallgamerS . Évalué à 10.
Hum.
# Idées d'utilisation
Posté par Victor STINNER (site web personnel) . Évalué à 10.
hachoir-grep est assez proche du programme strings sauf qu'il ne donne aucun "faux positif" et extrait les chaînes dans différents charsets (UTF-16LE, UTF-16BE, UTF-8, latin-1, etc.), là où strings a besoin de plusieurs appels. Mais la qualité de hachoir-grep dépend de la qualité des parseurs, et certains sont encore incomplets (il n'y a pas de faux-positif, mais on zappe beaucoup de chaînes si ça se trouve).
hachoir-urwid permet de vérifier ce que contient un fichier. On y découvre des fois des surprises. J'ai appris par exemple d'une image JPEG embarque une miniature (et des fois, la miniature n'est pas mise à jour, on découvre des choses......), qu'une vidéo Matroska peut contenir d'autres fichiers (ex: fichier texte, image, etc.), qu'un document Word est basé sur un système de fichier proche de FAT, qu'un document Word contient des secteurs (512 ou 64 octets) inutilisés (là où on trouve des paragraphes soit-disant supprimés...), etc. J'ai aussi que dans une vidéo : le titre du film, un lien vers le site d'où provient la vidéo, une partie des acteurs, etc. La majorité des fichiers AVI contiennent le nom du logiciel utilisé pour générer la vidéo : et quel logiciel affiche ces informations ? Perso, je n'en connais aucun (même pas extract :-)).
--
Autre idée : écrire un programme qui va valider un fichier à la manière d'une DTD ou XML Schema pour un document XML. Un tel programme mis en amont d'un serveur (web) éviterait certaines attaques (cf. faille JPEG, faille gzip, etc.).
Une fois que Hachoir permettra l'édition d'un document. Les possibilités seront encore augmentées.
Ex: éditer/ajouter des commentaires à n'importe quel document.
Ex: pouvoir supprimer tous les "mouchards" d'un document (auteur, date de création, logiciel utilisé pour la création, coordonnées GPS (si si, ça existe dans Exif), etc.).
Ex: pouvoir injecter un document dans un autre document ("stéganographie du pauvre").
Ex: supprimer une partie inutile d'un fichier pour réduire sa taille (ex: commentaires du logiciel de création, commentaires inutiles, "padding" inutile, etc.).
Ceux ne sont que quelques idées. Avec un peu d'imagination, on peut en trouver d'autres. Après "yapluka".
Haypo
# Package
Posté par salvaire . Évalué à 4.
Il te faut absolument un .tar.gz avec autotools!
svn n'est pas aussi courant que cvs (trop jeune pour IT ...) et j'aime pas les "rm -rf $hachoir" dans ton script ...
J'ai mis en gras ce qui est très rebutant:
N'oublie pas que tes utilisateurs potentiels n'ont pas forcément les même droits et devoirs que toi sur ton pc! IT n'est pas geek ...
n'est pas "portable", configure doit insérer la bonne commande.
idem, tu dois insérer le chemin, export PYTHONPATH= c'est pas automatique.
Si tu veux je peux t'envoyer un exemple avec essentiellement du Perl, mais aussi Python. Tu n'auras qu'a retirer le superflu et modifier.
Je pense que les commandes dans script doivent être installé dans bin, et les .py de hachoir dans lib.
[^] # Re: Package
Posté par salvaire . Évalué à 1.
[^] # Re: Package
Posté par Pierre Jarillon (site web personnel) . Évalué à 3.
Je me demande bien ce que ça peut donner en anglais, espagnol, allemand ou portugais ;-)
Après tout, nous bouffons bien du grand-breton en quantité... Il faudra bien qu'ils ajoutent hachoir à mayonnaise et rendez-vous :-)
[^] # Re: Package
Posté par salvaire . Évalué à 10.
[^] # lapin compris
Posté par Olivier Jeannet . Évalué à 5.
IT n'est pas geek
De quoi s'agit-il ? Je parle de "IT" (et je suis sérieux).
Merci.
[^] # Re: lapin compris
Posté par salvaire . Évalué à 2.
[^] # Re: Package
Posté par Bader Lejmi (site web personnel, Mastodon) . Évalué à 10.
Tes remarques montrent juste que tu as une méconnaissance de la façon de faire pour les packages python AMHHA.
#!/usr/bin/env n'est certes pas portable pour windows, mais sur cette plateforme #! est considéré comme un commentaire.
De plus PYTHONPATH n'a pas à être spécifié par le programme, c'est à l'utilisateur s'il l'installe dans un répertoire non destiné à cet effet de le rajouter à PYTHONPATH.
Finalement, tu trouves à redire à installer un package en root.
Mais pourtant sur ta distribution c'est nécessaire et tu ne trouves aucun problème à ça...
De plus si l'utilisateur n'a pas les droits root il peut directement utiliser le programme sans l'installer dans un répertoire particulier.
Dire que SVN est trop jeune, c'est de l'abus.
Sur les nouveaux projets, je pense que SVN est largement devant CVS...
Finalement, dans toutes les distributions GNU/Linux, et même sur *BSD, ou Windows, les packages python ne s'installent pas dans /*/lib mais dans site-packages/ qui est un répertoire à l'intérieur de l'installation Python.
Par ailleurs il est vrai que certaines applications le font quand même et modifient le PYTHONPATH mais c'est uniquement dans le cas d'applications qui ne cherchent pas à être utilisé en tant que module python i.e. à être réutilisé dans du code python d'un autre programme.
Or Hachoir est aussi un framework qui peut être réutilisé dans d'autres applications, notamment son extracteur de métadonnées.
[^] # Re: Package
Posté par briaeros007 . Évalué à 5.
Finalement, tu trouves à redire à installer un package en root.
Mais pourtant sur ta distribution c'est nécessaire et tu ne trouves aucun problème à ça...
De plus si l'utilisateur n'a pas les droits root il peut directement utiliser le programme sans l'installer dans un répertoire particulier.
je ne connais pas trop les paquetages python etc...
Mais je sais que pour tout ce qui est "à compiler" le fait de pouvoir spécifier le prefix (donc en étant utilisateur lors de l'installation), de pouvoir compiler en dehors du répertoire de sources etc ... est un grand plus!
L'utilité est par exemple quand tu es sur un ordi ou tu n'as pas les droits root (ordi du boulot, ou portable prété par le boulot ou tu n'as pas les droits root , ou ...)
pouvoir tout compiler dans (par exemple bien entendu) ~/obj_$ARCH/nom_apps et tout installer sur ~/$ARCH/{bin,lib,include,...} est trés appréciable.
Ca évite entre autre de se farcir de rajouter un path à chaque fois dans son .bashrc ou autre, de savoir où sont les sources (dans ~/src :-D ), où faire les make, etc...
[^] # Re: Package
Posté par Bader Lejmi (site web personnel, Mastodon) . Évalué à 2.
Je comprends ton problème, mais ce n'est pas tout simplement la façon standard de faire Python. En effet on peut pas faire du specific UNIX, Python est un langage, une VM, et une bibliothèque standard multiplateforme. La règle sous unix pour les bibliothèques externes c'est /usr/lib/pythonXX/site-packages/. Pour les binaires c'est comme le reste des applications.
Si tu veux une install custom, rien ne t'empêche de le faire mais dans ce cas je vois pas l'intérêt d'utiliser un package. Tu prends le source, tu le décompresses, et tu l'utilises. Si tu veux utiliser un package tout de même avec une procédure dans laquelle tu spécifies le path, amha ça crééra plus de problèmes que de solution. Le développeur devra se soucier des divers problèmes ésotériques que ça peut entrainer. Sans compter qu'utiliser un package pour spécifier soit même les PATH de destination à la main c'est franchement superflu... Autant passer directement par le source.
[^] # Re: Package
Posté par Victor STINNER (site web personnel) . Évalué à 10.
Il te faut absolument un .tar.gz avec autotools!
Il n'y a pas pire invention que autotools pour torturer les développeurs. Aussi bien les fichiers ".ac" et ".am" que le résultat (script configure et Makefile) sont imbitables ! De la grosse saloperie.
Heureusement, en Python on n'a pas cette chose HORRIBLE : chaque programme/bibliothèque (bien foutue) a son script "setup.py" qui fait en quelques lignes tout ce qu'on peut attendre d'un script ayant ce nom, et bien plus encore (ex: générer un installateur Windows, si le bon paquet est installé).
svn n'est pas aussi courant que cvs (trop jeune pour IT ...)
Je sais pas qui est IT, mais euh c'est pas pour dire mais cvs est VRAIMENT vieux et dépassé. La majorité des projets majeurs utilisent SubVersion. D'ailleurs, svn n'est absolument pas nécessaire pour installer Hachoir : un .tar.gz existe (cherche un peu ...) et un .egg existe.
j'aime pas les "rm -rf $hachoir" dans ton script ...
C'est pour ça que je cherche des packageurs. Et d'ailleurs, tu as ma copié/collé la commande.
* Debian/Ubuntu: apt-get install python2.4-setuptools
* Other distrib: download ez_setup.py and execute it as root (another copy if needed: ez_setup.py)
setup.py peut installer Hachoir dans $HOME/<où tu veux>
it needs svn and wget (and python2.4) programs
Ceci concerne le 2e mode d'installation (quick_install.sh).
On peut installer Hachoir :
* à partir du .tar.gz avec setup.py (pas besoin d'être root)
* à partir du .egg (pas besoin d'être root, mais il faut easy_install)
* avec quick_install.sh (il faut svn, càd ne pas vivre en 1990)
IT n'est pas geek ...
Hum ?
"#!/usr/bin/env python2.4" n'est pas "portable", configure doit insérer la bonne commande.
Cela fonction sur UNIX et *BSD. Au pire il faut taper "python2.4 script" (hou là là, c'est dur !).
"from hachoir.error", idem, tu dois insérer le chemin, export PYTHONPATH= c'est pas automatique.
Non, Hachoir doit être installé pour être utilisé... ou alors les gens qui ne veulent pas l'installer peuvent modifier eux-même leur PYTHONPATH.
Si tu veux je peux t'envoyer un exemple avec essentiellement du Perl,
QUOI ?
--
La prochaine fois, renseigne _un peu mieux_ avant de critiquer stp. Par contre, les contributions nous font toujours plaisir.
Haypo
[^] # Re: Package
Posté par salvaire . Évalué à 0.
Dire que j'avais commencé par un commentaire élogieux ...
Je veux tester ton application, que je trouve intéressante, donc je vais sur ton site via le premier lien. J'ai pas trouvé une seule archive tar. Mais une méthode qui me demande d'exécuter sous root un programme -inconnu-, et une autre qui requière de compiler svn en local sur toute les distributions installées en entreprise (IT = service informatique) qui n'ont pas encore svn. Cvs est/était encore majoritairement le standard quoi que tu pense. Qu'est que ça coûte de mettre un tar.gz comme tous le monde (pour la première page de LinuxFr))?
je lis bien: as root ...
Autotools est certes une belle saloperie. Mais c'est inutile, tu peux adapter les scripts durant l'installation une fois pour toute. Qu'est ce que ça coûte?
Mais pas les commentaires. Faudra changer quand tu voudras gagner ta vie. Parce que: "j'ai programmé cela pour pas un euro, je n'accepte que les commentaires élogieux, et si ça vous plais pas allez vous faire voir." C'est pas la bonne méthode pour manger à sa faim! Le marketing ça sert! (Par expérience, il y a pleins de contributions utiles dans le libre qui traînent à l'abandon, faute de volonté du/des mainteneur(s) ... si si ça existe)
Tu fait comme tu veux. Mais si une entreprise (peut être une source de revenu qui sait?) veut tester ton programme. Ils vont essayer de l'installer en user local: "tar -xzf hashoir.tar.gz; configure --prefix=...; hashoir-...". Pas avec un package, et pas sous root. Libre à toi de choisir la méthode pour le "configure" qui va préparer le terrain pour la première et définitive impression.
Désolé de t'avoir énervé!
[^] # Re: Package
Posté par lcld . Évalué à 3.
1. .tar.gz
Je cite http://hachoir.org/wiki/HachoirYield :Ok, ça saute pas aux yeux. On admet qu'il faille réorganiser un minimum le wiki.
2. not as root
Et l'option --help ??
$ python ez_setup.py --help
=>
$ mkdir -p /tmp/usr/lib/python2.4/site-packages
$ export PYTHONPATH=/tmp/usr/lib/python2.4/site-packages
$ python2.4 hachoir/ez_setup.py --prefix=/tmp/usr
$ /tmp/usr/bin/easy_install --prefix=/tmp/usr -U hachoir
et vala, c'est installé
3. quick_install
Bon ben euh... comme son nom l'indique : ... and dirty
Ca a d'autres avantages que celui de faire une install toute propre. Il a notamment été décidé d'utiliser la commande 'checkout' de subversion plutôt que 'export' pour télécharger hachoir :
* Il y a tout les données de svn (répertoire .svn) et en particulier des fichiers en lecture seule, ce qui explique le 'rm -rf'.
* C'est plutôt orienté beta-testeur : par exemple, si quelqu'un rapporte un bug sur un chan et si un dev peut corriger rapidement, il suffit de lui répondre 'svn up'.
* ... ou développeur en déplacement : ça permet de réinstaller rapidement une copie de travail et toutes les librairies rarement installées comme python-urwid.
Quant à svn, désolé, mais je considère qu'il faut aller de l'avant en info. Il faut bien que quelqu'un se dévoue pour utiliser un nouvel outil. Oh et puis de toute façon, comme ça a déjà été dit, svn est vraiment courant maintenant.
Tu as de la chance pour le .tar.gz, tu as échappé au .cpio.7z (oui, c'est que j'utilise personnellement) :D
[^] # Re: Package
Posté par Victor STINNER (site web personnel) . Évalué à 3.
J'ai rédigé une documentation qui explique comment installer Hachoir. Il y a 5 manières différentes : easy_install, quick_install.sh, tarball, Gentoo & Arch ... bon disons 3 manières différente si on exclut les paquets.
http://hachoir.org/wiki/Install
Aucune des 3 méthodes ne demande les droits root. Par contre, mieux vaut avoir le bon module (setuptools).
Hum, il y a encore une méthode qui n'est pas détaillée... (je le ferai plus tard) et c'est pourtant celle que j'utilise quotidiennement. Enfin, ce n'est pas une « installation », mais une bidouille pour éviter l'installation.
=> Modifier PYTHONPATH, il faut le faire pointer sur le dossier hachoir (celui qui contient le sous-dossier hachoir, et non pas le sous-dossier directement). Genre : « export PYTHONPATH=$HOME/hachoir ».
--
Au sujet des centres informatiques pas très ouverts, genre « on utilise des versions stables et point barre », je dirai que sous Unix/BSD on peut se *débrouiller* tant qu'on a de l'espace disque. Il faut jouer avec LD_LIBRARY_PATH, les "--prefix" & ci. C'est très contraignant, mais ça dépanne. Pendant longtemps j'ai du utiliser des "dpkg -x ~/pouet/ paquet.deb" avec des paquets venus de (Debian) backports.org pour pouvoir utiliser autre chose que le strict minimum installé de base.
L'idéal étant d'arriver à faire comprendre le besoin de tel bibliothèque ou tel programme pour éviter quelques dpkg -x quotidient :-)
Haypo
[^] # Re: Package
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Comme julien n'était pas trop chaud pour sortir 3 versions en 2 jours, voici une version "0.5.2-batarde" :
http://www.haypocalc.com/tmp/hachoir/hachoir-0.5.2-batarde.t(...)
Et l'½uf batard :
http://www.haypocalc.com/tmp/hachoir/hachoir-0.5.2_batarde-p(...)
$ md5sum *
d30c4cbce43cd75c5150ccf7e38b6aaf hachoir-0.5.2_batarde-py2.4.egg
77af3c33c67417102c5a22c35a882549 hachoir-0.5.2-batarde.tar.gz
Le principal changement est un tout nouveau setup.py qui fonctionne sans setuptools (et qui peut être lancé de n'importe où : mais attention, il crée des dossiers dist et build).
Haypo
[^] # Re: Package
Posté par Victor STINNER (site web personnel) . Évalué à 5.
http://sourceforge.net/tracker/index.php?func=detail&aid(...)
J'ai enfin réussi à sortir la version 0.5.2 :
http://cheeseshop.python.org/pypi/hachoir
Haypo
[^] # Re: Package
Posté par fusible . Évalué à 3.
Autre chôse, dans le fichier INSTALL à propos de la désinstallation:
<$ sudo rm /usr/bin/hachoir
>$ sudo rm /usr/bin/hachoir-*
me semble plus approprié. C'est du détail, mais bon tant que j'y suis. :)
En tout cas, on ne peut pas te reprocher de ne pas tenir compte des retours/réclamations des utilisateurs (voir mini-troll plus haut :p).
[^] # Re: Package
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Normal, les ½ufs ont été introduit avec setuptools. Pas de setuptools, pas d'½uf. Le script setup.py du Hachoir tente d'utiliser setuptools et s'il ne le trouve pas, il se rabat sur la version « bas de gamme » (distutils, qui a la qualité d'être toujours dispo').
Autre chôse, dans le fichier INSTALL à propos de la désinstallation:
Ah mince, j'ai oublié de mettre à jour ce fichier. Il faut se référer à la page web. Je voudrais bien pouvoir synchroniser les deux via une commande ...
En tout cas, on ne peut pas te reprocher de ne pas tenir compte des retours/réclamations des utilisateurs (voir mini-troll plus haut :p)
Les retours font toujours plaisir. J'ai encore corrigé plein de bugs, mais ça attendra une version 0.6 je pense car des changements d'API ont été opérés (correction de l'API des chaînes de caractères).
Haypo
# Compléments
Posté par lcld . Évalué à 10.
Avant j'aimerais parler d'une des nouveautés d'Hachoir : le support du système de fichiers FAT. Euh... oops on est sur linuxfr.org... Oui, ça fait bizarre. D'ailleurs, ce format ne m'intéresse pas du tout. Mais à défaut d'être bien foutu, il a l'avantage d'être simple et de bien mettre en évidence les limitations d'Hachoir. Sans les améliorations apportées à l'API d'Hachoir, implémenter FAT aurait été presque impossible.
[1] Ce système de fichiers n'a pas une structure arborescente. Tout est à plat et pour atteindre un fichier en particulier, il faudrait presque tout parser et on finirait avec un liste de plusieurs miliers d'entrées. On ne peut plus dire qu'Hachoir reste paresseux ; on serait vite limité à des petits FS.
[2] Admettons qu'on atteigne le champ qui contient les données du fichier recherché. On peut vouloir hacher le contenu. C'était possible avec Hachoir 0.1. Voilà, la feature est de nouveau là, dans l'interface urwid.
[3] Oui mais... quel système de fichiers ne fragmente jamais ? Sûrement pas la FAT.
Hachoir 0.5 marque le début du support des containers.
J'appelle container tout format destiné à contenir des données dans un format quelconque. Les catégories les plus courantes sont :
- archives : C'est le cas le plus facile. Le contenu est en un seul morceau. (La compression est une toute autre histoire)
- systèmes de fichiers : Ca se corce. On fait souvent face à des contenus fragmentés.
- containers multimedia : Là, ça peut devenir un cauchemar. Il s'agit souvent d'un flux de paquets (un paquet pouvant être à son tour fragmenté ; avec 2 types de fragmentation, finir le parseur ogg va être un casse-tête) et le format ne peut pas se contenter d'un flux bêtement défragmenté : il peut avoir besoin de connaître le découpage.
Dans l'interface urwid, 2 raccourcis ont fait leur apparition :
1. La touche 'espace', utile pour les parseurs non terminés. Il considère le champ actuellement sélectionné comme un contenu ayant son propre format. Une nouvelle fenêtre est ouverte, Hachoir cherche un parseur approprié et commence un nouveau hachage. On peut l'utiliser n'importe où et même pour un fichier non fragmenté dans un FS. Actuellement, c'est le seulement moyen d'hacher :
- une partition si on a lancé hachoir sur un disque entier
- un fichier attaché à un fichier matroska
- ...
2. La touche 'f' qui, pour le moment, fonctionne uniquement pour le parseur FAT. Une fois que le début d'un fichier (fragmenté ou non) est sélectionné (il ne faut pas sélectionner le champ "data" mais le champ parent), une nouvelle fenêtre est ouverte et cette fois-ci, c'est tout le contenu défragmenté qui est haché.
Pour ceux qui seraient intéressés par le support des flux fragmentés, un bug sérieux affecte malheureusement la version 0.5. Je m'en suis aperçu quelques heures après que tout a été packagé. Il faudra alors appliquer le patch http://hachoir.org/changeset/726 (plutôt gruik d'ailleurs ; va falloir que je revois l'API) ou télécharger depuis le dépôt subversion.
Une autre nouveauté : le lien interne. Dans urwid, on suit un lien tout comme on développe/réduit un champ : avec la touche 'entrée'. Le lien permet de faciliter là navigation.
Pour l'instant, il y en a très peu : dans les parseurs Matroska et FAT uniquement.
Dans les fichiers Matroska, il existe une structure ('Cues') qui indexe certaines trames. En général, les trames clés d'un flux video. Il faut consulter plusieurs champs pour localiser la trame clé dans le fichier, et de toute façon, même si un seul champ suffisait, celui-ci ne serait pas forcément intelligible : indice de temps, ou position en octets par rapport à un endroit bien précis (et lire les specs pour le connaître), etc.
Dans le cas du système FAT, les liens permettent par exemple de naviguer entre les différents fragments d'un fichier.
Mais c'est surtout en suivant le lien dans une entrée de répertoire qu'on déclenche le hachage du fichier correspondant à cet entrée. Cela résoud [1]. On laisse des zones non hachées (padding) puis on hache ces zones à la demande.
# problème sous Arch x86_64
Posté par fusible . Évalué à 4.
http://bursab.free.fr/pkgs/hachoir-svn/PKGBUILD
Manque de bol, à l'exécution de n'importe quel scripts j'obtiens ça:
Une idée?
[^] # Re: problème sous Arch x86_64
Posté par lcld . Évalué à 5.
Au format diff : http://hachoir.org/changeset/727?format=diff
Ou télécharger depuis le dépôt subversion : svn co svn://hachoir.org/hachoir/hachoir/trunk hachoir
Si ça ne marche toujours pas, annule le commit 690 : http://hachoir.org/changeset/690
(attention à la récente réorganisation des fichiers sources)
[^] # Re: problème sous Arch x86_64
Posté par fusible . Évalué à 4.
Merci pour la réactivité, il est extra cet outil !
[^] # Re: problème sous Arch x86_64
Posté par Victor STINNER (site web personnel) . Évalué à 2.
Si "make test" passe, alors tu peux dire que tout marche :-) La documentation est testée, quelques tests unitaires, un jeu de fichier de tests et le packaging (setuptools).
Haypo
[^] # Hop, version 0.5.1
Posté par Victor STINNER (site web personnel) . Évalué à 3.
http://cheeseshop.python.org/pypi/hachoir
Haypo
[^] # Re: Hop, version 0.5.1
Posté par fusible . Évalué à 2.
Et toujours celui basé sur le svn pour ceux qui veulent avoir la dernière version facilement: http://bursab.free.fr/pkgs/hachoir-svn/PKGBUILD
[^] # Re: Hop, version 0.5.1
Posté par Victor STINNER (site web personnel) . Évalué à 2.
GnunuX a préparé un paquet Arch. Si arno et GnunuX ne sont pas la même personne, ça serait bien que vous travailliez ensemble :-)
Des paquets Arch et Gentoo : vous nous gattez :-) Merci. J'attend les paquets Debian et Ubuntu avec impatience.
Haypo
[^] # Re: Hop, version 0.5.1
Posté par rdem . Évalué à 2.
Pour le moment il n'y auras que debian unstable (portable a priori sur sid vu que la dependance et sarge, mais a vérifier) vu que la dependance seras python2.4
Il faudras aussi tester pour *ubuntu.
[^] # Re: Hop, version 0.5.1
Posté par Vincent Danjean . Évalué à 1.
Il faudra qu'ils soient validés par ftpmaster, ce qui peut prendre quelques jours (voire mois) en fonction de leur temps libre. Il y a moyen de voir les paquets sur un site perso en attendant ?
[^] # Re: Hop, version 0.5.1
Posté par rdem . Évalué à 2.
Le choix de la version batarde est de supprimer une dépendance.
D'ailleurs je commence maintenant, et si les auteurs ont un problème avec, qu'ils me le fasse savoir.
[^] # Re: Hop, version 0.5.1
Posté par Vincent Danjean . Évalué à 1.
[^] # Re: Hop, version 0.5.1
Posté par rdem . Évalué à 2.
L'installe se passe très bien comme il faut, mais la desinstallation, j'ai été obligé de mettre un prerem qui supprime comme il faut (sinon le uninstall ne vire pas les libs / scripts)
Ensuite, mon premier paquet debian est créé python-hachoir (le paquet regroupe TOUT hachoir, mais je pense dans un avenir proche le séparer en plusieurs paquets)
Le dépot (qui génère une erreur, je pense car je n'ai pas signé le paquet) est :
deb http://hachoir.demongeot.biz/debian ./
Il n'y as qu'une version unstable pour le moment.
Le paquet est la version 0.5.2_batarde rebaptisée en 0.5.1.1 (setuptools en moins comme dépendance)
J'attends vos commentaires ;)
[^] # Re: Hop, version 0.5.1
Posté par rdem . Évalué à 2.
Je le resort demain avec tout bien corrigé en 0.5.1.2
[^] # Re: Hop, version 0.5.1
Posté par Vincent Danjean . Évalué à 2.
[^] # Re: Hop, version 0.5.1
Posté par rdem . Évalué à 3.
Voila tous les fichiers (hors du .deb) qui sont dans le dossier. Il y as donc entre autre les 3 que tu demande ;)
[^] # Re: Hop, version 0.5.1
Posté par Victor STINNER (site web personnel) . Évalué à 2.
http://hachoir.org/wiki/DebianPackage
Il utilise python-central et semble plutôt propre.
Haypo
# Packaging
Posté par rdem . Évalué à 3.
je peux essayer de packager pour debian (instable / testing / stable)
OpenBSD (je relance bientôt mon serveur)
Gentoo (quand j'aurais réinstallé un petit pc sous gentoo)
Je n'ai jamais packagé pour aucun de ces systèmes, mais je veux bien essayer d'apprendre.
Je veux bien aussi aider pour le code, mais mon experience en python se limite pour le moment a une relecture d'un projet de cours.
En attendant, je vais déjà commencer par lire le code ;)
[^] # Re: Packaging
Posté par tgl . Évalué à 3.
Tu peux virer celui là de ta TODO, je viens de m'y coller :
https://bugs.gentoo.org/show_bug.cgi?id=144532
(par contre, j'ai rien contre les relectures / tests / critiques, évidemment...)
[^] # Re: Packaging
Posté par rdem . Évalué à 2.
Et tu viens par la même occasion de me virer une raison d'installer Gentoo par la même occasion. Enfin, je vais quand même réinstaller une gentoo ;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.