tgl a écrit 1743 commentaires

> Aussi, je n'ai pas constaté la présence d'un menu d'inclusion de
> DSDT Custom.

Tu veux dire, même pas l'option de ma solution #2 ?

Si oui, alors c'est peut-être que tu as d'activé l'option "STANDALONE" (aka "Select only drivers that don't need compile-time external firmware", dans "Device Drivers" --> "Generic Driver Options").

Enfin toujours est-il qu'il me semble vraiment que c'est une option standard. Essayes voir, dans "make menuconfig", de taper "/ dsdt". Ça devrait te montrer l'option si elle existe bien, et ses dépendances (ici, sur un 2.6.12-pre6 : !X86_VOYAGER && !X86_VISWS && !IA64_HP_SIM && (IA64 || X86) && ACPI && ACPI_INTERPRETER && !STANDALONE).

Bah comme marqué dans le commentaire auquel tu réponds :

% [[ 12345678.pdf =~ [0-9]{8}.pdf ]] && echo "voila"
voila

Mais ça ne marche qu'en bash-3.0. En bash 2.x, tu n'as pas de "=~" pour faire des regexps, mais seulement des patterns testables avec "=". Ton test devient alors :

% [[ 12345678.pdf = [0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9].pdf ]] && echo "voila"
voila

...et c'est sûr, c'est moins joli. Dans ce cas là, effectivement, c'est effectivement plutôt par expr ou même grep ou autre qu'il faut passer.

Quant à utiliser des simples crochets, bah ça ne marchera de toute façon pas avec des regexp, et puis avec la version longue et moche ça ne marchera que si ton fichier est dans le répertoire courant et qu'il est le seul avec un nom de ce genre là. Bref l'expansion se fait sur les noms de fichiers, alors que tu veux un match sur une chaine. À éviter donc.

* La 1ère, c'est comme dit au dessus la DSDT.aml dans l'initrd. Ça a l'avantage que tu n'as pas à recompiler ton noyau à chaque fois que tu modifies la dsdt (pratique en phase de bidouille donc). Ça a l'inconvénient que, à ma connaissance, ça ne marche pas avec un noyau vanilla, mais qu'il faut ce patch :
http://gaugusch.at/kernel.shtml(...)
Est-ce que Debian utilise ce patch dans ses noyaux ? Aucune idée perso.

* La 2ème, c'est de l'inclure dans le noyau, mais c'est maintenant plus simple que ce que tu décris : option "ACPI_CUSTOM_DSDT_FILE", accessible via "Power management options (ACPI, APM)" --> "ACPI (Advanced Configuration and Power Interface) Support " --> "Include Custom DSDT". Et là tu donnes le chemin vers ta "dsdt.hex".

Attention donc, dans un cas c'est le .aml, et dans l'autre le .hex. Les deux sont générés depuis le .dsl via la commande donnée au dessus ("iasl -tc dsdt.dsl").

> Bin je sais pas avec des grep et autre macro awk dans les fichiers configure

C'est bien parcequ'il n'existe pas une liste unique et bien déterminée des dépendances d'un logiciel que ces scripts s'appellent "configure" et pas "verify".

Donc non, une telle liste ne peut pas être extraite des fichiers "configure", même par un gourou suprême des expressions régulières. Arriver à cette liste demande de nombreux choix parfaitement arbitraires (est-ce que je veux le support de gtk2 ? est-ce que j'installe sur un système Glibc ou bien µlibc ? etc.).

Et c'est bien (entre autres) aussi pour ça qu'il existe des distributions Linux d'un peu plus haut niveau que LFS, qui font des choix pour t'installer les logiciels dans une configuration bien connue (éventuellement une parmi plusieures bien connues, cf. les découpages de paquets des distribs binaires, ou bien les USE flags de Gentoo, etc.), de telle sorte que leurs dépendances le sont alors aussi. C'est une partie du boulot des mainteneurs de paquets, où ils ne peuvent pas être remplacés par des scripts (au mieux, un peu aidés).

'llo

Alors commençons par la fin :
> mais je comprends pas trop la syntaxe.

La syntaxe, c'est du shell Bash tout ce qu'il y a de plus normal. Je te conseille pour t'y mettre de consulter l'excellent Advanced Bash Scripting Guide :
http://www.tldp.org/LDP/abs/html/(...)

Bon, maintenant, ce qu'il ne faut pas perdre de vue c'est que l'environnement dans lequel est exécuté l'ebuild est largement plus chargé que celui d'un simple script "#!/bin/bash". On peut dire qu'en gros on à affaire à un framework : on bosse avec un language générique, mais on a à disposition tout un tas de fonctions et variables utiles ; en plus, on ne fait pas vraiment ce qu'on veut, mais on se contente de (re)définir des fonctions aux noms bien connu (les src_*() et autres pkg_*()) qui seront appelées par emerge (enfin, par ebuild.sh) en temps voulu. Ça, plus quelques variables (IUSE, DESCRIPTION, URI, les *DEPEND, etc., m'enfin ça c'est vraiment pas le plus dur).

À mon avis, le mieux pour s'y mettre c'est d'en lire déjà quelques uns, et de s'assurer qu'on comprend ce qu'ils font.

Quelques suggestions en vrac :
- si tu utilises Vim, installe le paquet "app-vim/gentoo-syntax", comme ça tu auras la coloration syntaxique spécialement adaptée aux ebuilds (ça aide à reconnaitre par exemple les appels aux fonctions du framework, etc.).
- garde la doc officielle sous le coude évidemment, mais aussi son indispensable complément : "The Doc", par Ciaran Mc Creesh :
http://dev.gentoo.org/~plasmaroo/devmanual/(...)
- apprends si ça n'est pas déjà fait à utiliser la commande "ebuild", indispensable pour lancer des étapes particulières de l'installation de ton paquet (genre "ebuild foobar-3.0.ebuild compile").
- installe les manpages de développement ("app-portage/portage-manpages"), parceque c'est là que sont les documentations des "eclass" (par exemple, "man eutils").
- perso je trouve mieux pour commencer de se baser sur /usr/portage/skel.ebuild que sur un ebuild réél : le truc, c'est que quand tu manques d'habitude, tu ne sais pas trop dans l'ebuild que tu auras recopié ce qui est réellement requis en général et ce qui lui est spécifique. Le "skel.ebuild" lui par contre te montre vraiment ce qui est requis et juste ça.

Quelques autres points :

> verifier que qt, SDL, avifile sont installés

Ça, pas besoin de t'en préoccuper dans un premier temps. C'est juste dans les variables (R)DEPEND que ça se passe, il sera toujours temps de compléter ça quand tu fignoleras ton ebuild.

> prendre le CVS de qastrocam

Outch, alors là attention : il est techniquement possible de faire des ebuilds qui font ça (en utilisant la "cvs.eclass"), mais pour des question d'assurance qualité, tes chances de faire arriver un tel paquet dans l'arbre portage sont à peu prêt nulle. Bah oui, un CVS c'est mouvant, cassé parfois, alors comment pour un mainteneur d'ebuild prendre la responsabilité de dire "c'est bon mon paquet il marche" ? Ce qui est préférable :
- le mieux, c'est s'en tenir aux vraies version releasées (éventuellement beta). Genre tu fais un "qastrocam-4.0_beta4.ebuild" qui utilise "qastrocam-4.0.beta.4-sources.tar.gz".
- sinon, si les dernières releases sont trop vieilles, tu peux éventuellement utiliser un snapshot de CVS. Genre tu fais un "qastrocam-4.0_pre20050523.ebuild" qui utilise "qastrocam-2005-05-23-sources.tar.gz".


Et puis bah à part ça, y'aurait mille choses à dire mais je ne sais pas les quelles te serviraient. Par contre, n'hésites pas à coller tes tentatives sur un coin de page web si tu veux que je te les commente/corrige... enfin, que j'essaie :)

Et si tu veux plus de paires d'yeux, tu peux aussi aller coller tout ça dans la section francophone de http://forums.gentoo.org(...)
Y'a plus de monde qu'ici, et tu seras pas le premier à t'y faire dépanner sur une écriture d'ebuild. Si tu ne connais pas ce forum, n'oublie pas de commencer par lire le sujet en annonce intitulé "[IMPORTANT] Comment se servir du forum !!".

> Il y a eu une proof of concept sur sha-1 ca me suffit !

Il faut relativiser, il n'y a pas encore d'attaque franchement utile sur SHA-1 : ce que sauraient faire Wang et compagnie, c'est générer une collision parfaitement quelconque, mais il ne savent pas pour autant viser un hash particulier. Pas moyen pour l'instant donc de trouver, par exemple, un password imitant (par son empreinte SHA-1) celui d'un autre utilisateur, où encore de forger un programme avec backdoor pour qu'il ait la même empreinte que l'original. Bref, SHA-1 a encore quelques beaux jours devant lui, et on aura probablement changé plusieurs fois nos Thinkpad d'ici à ce qu'il soit utilement compromis.

> Si tu arrives à exploiter une faille pour modifier un de ces pointeurs,
> tu peux modifier frauduleusement le comportement du programme.

Ouais, mais est-ce que justement ça n'est pas aussi là que la randomization du mmap intervient ? J'imagine que, typiquement, ce que voudrait l'attaquant c'est pointer une fonction système bien connue qui lui ouvrirait des portes, mais là a priori il ne sait plus vraiment où elle est, non ?

C'est planqué dans "Kernel Hacking", en activant "Kernel debugging". Je suppose que par défaut c'est donc 8K, vu que l'option c'est "CONFIG_4KSTACKS" et qu'elle est désactivée.

(astuce : retrouvé dans "make menuconfig" en tapant "/ 4k entrée")

> C'est la description dans la depeche qui m'a induit en erreur.

Yep, déso, j'ai un peu over-résumé vu que je voulais pas en mettre toute une tartine non plus. J'ai parlé d'allocation en général parceque ça concerne en plus des piles les mmap pour des libs dynamiques, mais effectivement du coup on comprend "toutes les types d'allocation" :/

> Au fait le tas ou l'espace data sont il excecutable ?

Non justement, c'est pour ça qu'il n'y a pas besoin de ce type de protection préventive là. (Enfin, j'suis loin d'être un gourou du C et du système, donc toute {con,in}firmation sera la bienvenue.)

Pas sûr que ça suffise à résoudre l'enigme de ses motivations (dont perso j'aurais surtout tendance à me foutre - c'est sa vie et ça le regarde), mais voilà toujours quelques éléments à se mettre sous la dent pour ceux que ça intrigue :
http://killer.leclipse.be/drobbins.txt(...)

> a quoi ca va servir (ou sert deja puisque'il y avait deja un patch
> pour le 2.6.11) ?

Pour l'instant, à ma connaissance ça sert pas à peu prêt à rien. Mais y'a une API en développement qui devrait permettre d'en faire quelquechose si les distribs décident d'aller dans ce sens et que des softs qui font/utilisent de la crypto décident de s'y mettre aussi :
http://trousers.sourceforge.net/faq.html(...)
À voir quoi...

Tu peux aussi jetter un oeil sur ce journal à propos d'un patch pour Grub (rejeté) qui implémentait le boot sécurisé façon TCG :
http://linuxfr.org/~albancrequy/18368.html(...)
Y'a une discussion dans le genre de celle que tu proposes, avec en gros deux tendances : les plutôt pour qui se disent que c'est une techno qui peut s'avérer utile pour remplacer certains des mécanismes de sécu actuels, et les carrement contre qui se disent que le véritable objectif est l'autentification distante à des fins de contrôle DRM, et que donc il faut rejeter cette techno en bloc. (J'espère avoir résumé à peu près objectivement le troll...)

Pour garder juste le dernier caractère, tu as ça aussi qui est rigolo :
% echo "${plop#${plop%?}}"
C'est donc "la chaine privée d'un préfixe qui correspond à la chaine privée de son dernier caractère".

Et puis aussi, en Bash-3 avec une regexp, pour garder tous les derniers chiffres si c'est bien par des chiffres que la chaine termine :
% [[ "${plop}" =~ "[0-9]+$" ]] && echo "${BASH_REMATCH}"
(pratique parceque tu peux en même temps gérer les chaines incorrectes avec un if/then/else)

Bref, que de solutions... :)

Dans un répertoire initialement vide :

 % [ foo == f* ] && echo oui || echo non
non
 % touch foo
 % [ foo == f* ] && echo oui || echo non
oui
 % touch foo2
 % [ foo == f* ] && echo oui || echo non
-bash: [: too many arguments
non

Bref tu l'a compris, dans un [ ... ] bash fait l'expansion des jokers sur les noms de fichiers. [[ ... ]] ne le fait pas lui, il utilise les jokers comme des patterns dans la comparaison de chaine, et donc [[ foo == f* ]] sera toujours vrai. En plus, le [[ ... ]] de bash-3 introduit un opérateur très intérressant, =~, pour évaluer des regexp. Y'a pas ça dans [ ... ] :

% [[ XXXfoo123XXX =~ "(foo)([0-9]+)" ]] && echo plop
plop
% echo ${BASH_REMATCH[0]}
foo123
% echo ${BASH_REMATCH[1]}
foo
% echo ${BASH_REMATCH[2]}
123

Et puis [[ ... ]] il est souvent plus robuste, genre il ne t'en voudra pas de ne pas quoter un variable vide :

% unset plop
% [ foo == $plop ] && echo plop
-bash: [: foo: unary operator expected
% [ foo == "$plop" ] && echo plop
% [[ foo == $plop ]] && echo plop

Pareil avec le "word spliting" des chaines avec des espaces :

% foo="a b c"
% [ "a b c" == $foo ] && echo plop
-bash: [: too many arguments
% [ "a b c" == "$foo" ] && echo plop
plop
% [[ "a b c" == $foo ]] && echo plop
plop

(m'enfin bon, ça reste une bonne habitude de quoter systématiquement ceci dit). En résumé, voilà les 2 différences aux quelles j'ai pensé perso :

• expansion différente (pas de filename ou de word splitting dans le [[ ... ]], or c'est souvent ce qu'on ne veut pas justement, donc ça tombe bien)
• un opérateur =~ qui permet d'éviter bien des forks de grep et autres sed inutiles pour les cas simples

Comme ça là je n'en ai pas d'autre qui me vienne.

Ou bien on peut utiliser du pur bash aussi :

% plop="SNMPv2-SMI::enterprises.3582.1.1.3.1.7.0.0.0"
% echo ${plop##*.}
0

(question de goût, mais c'est vraiment infiniment plus rapide si jamais il y a beaucoup de lignes à traiter en boucle)

> Moi je tourne sous winXP avec Cygwin+Gnome 2.8, pour me
> connecter au serveur Exchange de la boite j'utilise Evolution/win32

drobbins, on t'a reconnu :)

'osd_cat', probablement dans un package nommé xosd. Par exemple :

# echo "Attention, tu piques du nez..." | osd_cat -f "-bitstream-bitstream vera sans-bold-r-normal--30-0-0-0-p-0-iso8859-15"  -A center -p bottom -c blue -l 1 -d 0

C'est le "-d 0" qui fait que c'est permanent (sinon, c'est un temps en secondes). Le reste, c'est des options de mise en forme, je te laisse lire la man.

> si ça se trouve je suis un nerd

...ou un geek : Je me souviens avoir fait le test il y a qlqs temps, et je crois bien que sur la page des résultats il y avait un laïus expliquant que beaucoup de gens avaient écrit pour dire que le test était plus geek que nerd, et que en fait son auteur n'avait pas vraiment d'opinion sur la question. Enfin, c'est vague, j'ai pas une mémoire de nerd/geek :)

Ils ne réinvente pas vraiment la roue puisqu'ils prennent la relève d'un projet moribond. Bon après, je sais pas comment ces softs se comparent, mais en tout cas ils n'ont pas fait l'erreur de partir de rien sans regarder l'existant.

Yep, j'arrêtais pas de faire pareil avec la keymap fr-latin9, alors du coup j'ai fini par ajouter ça dans un script de démarrage ("/etc/conf.d/local.start" sous Gentoo, mais ça doit vraiment dépendre de la distrib... enfin bref, n'importe où tant que c'est exécuté au démarrage mais après le chargement de la keymap) :

echo "altgr keycode 57 = space" | loadkeys

> http://sourceforge.net/projects/dvd/(...) (pour libdvdnav)

En l'occurence, un petit "string | grep" sur le machin installé avec Wine montre qu'il utilise une version provenant de la xine-lib. M'enfin bon, j'dis ça j'dis rien, c'est GPL aussi bien entendu.

Y'a la page info de coreutils qui est un peu moins pire que la page man, c'est là qu'est décrit le format des chaines qu'il sait parser. On y apprend plein de trucs utiles, du genre `date -d "1 month ago"`, etc.

# info coreutils

(ou bien installe "pinfo" si tu veux un lecteur plus joli avec des couleurs et tout et tout)

J'avais mis un peu de temps à trouver aussi le jour où j'en ai eu besoin, mais l'astuce est d'utiliser la capacité de 'date' à faire des additions (ici depuis EPOCH en l'occurence) :

# date -d "1970-01-01 00:00:00 UTC +1118913465 second" +"%Y-%m%d %T"
2005-0616 11:17:45

Enfin si il y a plus simple, je suis preneur aussi.

Tes souhaits sont assez vagues, mais de ce que j'en comprends, les BSD ou MIT qui t'ont déjà été proposées sont effectivement des possibilités satasfaisantes, si tu ne tiens pas au copyleft.

Ceci dit, juste pour compléter un peu le débat, moi je te propose la LGPL :

- il sera sans problème possible de faire des jeux proprios (au niveau du programme principal, des scripts, des graphismes, des sons, etc.) en utilisant ton moteur par liaison dynamique (enfin, pour être précis, la liaison statique n'a rien d'interdite non plus, moyennant qu'il y ait possibilité de se procurer une version liée dynamiquement)

- les éventuelles modifications que les éditeurs des jeux feraient directement sur ton moteur tomberont elles par contre sous le coup du copyleft, et devront donc être publiée aussi sous forme source. Mon opinion là dessus est que si un éditeur veux utiliser ton moteur, ça n'est pas de publier une part aussi mineure de son travail qui l'arrêtera, et l'avantage c'est que tout le monde en profitera si ça comprends des améliorations. Bref, ça me semble être un marché très équilibré et bénéfique pour tous.


Un autre truc envisageable pourrait être une double licence, qui a l'avantage de permettre pas mal de modèles économiques. Par exemple, les gens qui veulent faire du libre se procureraient gratos la version GPL, avec ce qu'elle offre comme droits et impose comme devoirs, et ceux qui veulent faire du proprio avec des modifications secrètes et tout et tout achèteraient ton code sous une licence sur-mesure qui le permettrait. Bon, c'est juste une idée comme ça, c'est pas forcement ton optique.

Argh, désolé. J'ai pensé à rajouter cette mention après l'avoir vue sur un des sites que j'ai consulté, mais (paf!) j'ai effectivement pas vérifié à la source :/
Mea culpa.

je ne pense pas que dh_shlibdep peut s'utiliser betement et facilement sur un executable

En l'occurence si, probablement. Enfin j'ai pas de Debian pour tester, mais je viens de voir que sous Gentoo le paquet 'dpkg' installe, parmi d'autres utilitaires, un /usr/bin/dpkg-shlibdeps (peut-être que le préfixe "dpkg-" est ajouté par le paquet Gentoo, je sais pas), qui a l'air très bien :

% dpkg-shlibdeps -h
Debian dpkg-shlibdeps 1.10.28.
Copyright (C) 1996 Ian Jackson.
Copyright (C) 2000 Wichert Akkerman.
This is free software; see the GNU General Public Licence version 2 or
later for copying conditions.  There is NO warranty.

Usage:
  dpkg-shlibdeps [<option> ...] <executable>|-e<executable> [<option>] ...
Positional arguments/options (order is significant):
       <executable>           } include dependencies for <executable>
       -e<executable>         }  (use -e if <executable> starts with `-')
       -d<dependencyfield>    next executable(s) set shlibs:<dependencyfield>
Overall options (have global effect no matter where placed):
       -p<varnameprefix>      set <varnameprefix>:* instead of shlibs:*.
       -O                     print variable settings to stdout
       -L<localshlibsfile>    shlibs override file, not debian/shlibs.local
       -T<varlistfile>        update variables here, not debian/substvars
Dependency fields recognised are Suggests/Recommends/Depends/Pre-Depends

J'ai regardé rapidement les sources (script perl), et il fait justement un "objdump -p ...", avec tout ce qu'il faut autour :)