OK ça me fait bien plaisir.
J'ai changé le %{_bindir}/ciso en %{_bindir}/%{name} .
Je n'ai pas tenté de rebuilder le paquet (pas trop le temps malheureusement), mais si rpmlint est clean et que le paquet passe mock, c'est tout bon 🙂
J'ai proposé ce paquet sur bugzilla.redhat : Bug 524423 - Review Request: ciso - iso to cso converter .
Je croise les doigts, j'espère que cette première contribution sera concluante...

Merci à vous

Je donnerai le résultat sur ce post.
Je pense que tu as oublié quelques trucs pour une permiere soumission 🙁.
Il faut que tu mette la sortie complete de rpmlint. Il faut aussi que tu indique que c'est ton premier paquet, et que tu n'as pas de sponsor (et que donc tu en cherche un). Et ensuite il faut le flag FE_NEEDSPONSOR.

epo
J'ai fais le nécessaire sur Bugzilla.

J'ai encore une petite question, un patch existe dans le paquet ubuntu de ciso, or le paquet source original de l'auteur n'a pas changé..
--> https://bugs.launchpad.net/ubuntu/+source/ciso/+bug/163308

Si je patche les sources dans mon paquet, comment je dois faire ? Il faut peut-être que je cite l'auteur original de la correction quelque part et la référence du bug Launchpad ?
Où puis-je mettre ces infos ? En commentaire dans le patch ?

Merci
Pour ce qui est des patches, la politique de Fedora est simple : il faut les limiter au maximum s'il ne s'agit pas de patches « Fedora-centriques », ce n'est pas au packager d'assurer le développement du logiciel packagé.
Ici, le vrai souci est de faire remonter ce patch au développeur, de lui citer la référence Launchpad, de façon à ce qu'il publie une nouvelle version de son programme avec les corrections. Et accessoirement qui mieux que lui peut juger de l'efficience d'un patch ?
Néanmoins, si ce patch est justifié et que son intégration upstream n'est pas immédiate, tu peux (dois) donner l'URL du patch dans ta clause Patch0, et la précéder d'un commentaire qui explique le but de ce patch.
6 jours plus tard
J'ai effectué quelques modifs suite aux recommandations de lonu? Ar??ri?i sur bugzilla .
Cependant il demeure un truc qui me chiffonne (et qui existe depuis le début) : rpmlint sur le paquet ciso-debuginfo:

chdorb@chdorb-desktop:~/rpmbuild/SPECS$ rpmlint ../RPMS/i386/ciso-*
ciso-debuginfo.i386: E: debuginfo-without-sources
3 packages and 0 specfiles checked; 1 errors, 0 warnings.
chdorb@chdorb-desktop:~/rpmbuild/SPECS$ rpmlint -I debuginfo-without-sources
debuginfo-without-sources:
This debuginfo package appears to contain debug symbols but no source files.
This is often a sign of binaries being unexpectedly stripped too early during
the build, or being compiled without compiler debug flags (which again often
is a sign of distro's default compiler flags ignored which might have security
consequences), or other compiler flags which result in rpmbuild's debuginfo
extraction not working as expected. Verify that the binaries are not
unexpectedly stripped and that the intended compiler flags are used.

Je ne comprends rien à cette erreur...

Si quelqu'un peut m'aider

J'ai mis à jour les fichiers:
URL Spec : http://chdorblog.free.fr/ciso.spec
URL SRPM : http://chdorblog.free.fr/ciso-1.0.0-1.fc10.src.rpm

Merci
Bonjour,

est-ce que le paquetage redhat-rpm-config est installé chez toi ? Dans le cas contraire, installe-le et reconstruis tes paquets ensuite.
Bonjour,

Oui redhat-rpm-config est installé
Après avoir consulté les sources, je pense avoir identifié le problème.
Tu compiles le programme sans utiliser les flags de compilation de Fedora (cf. variable $RPM_OPT_FLAGS). Or ces flags incluent l'option « -g » de GCC pour générer des info. de débogage, info. que rpmlint ne trouve pas.
Tel qu'il est, le Makefile de ciso ne permet pas de lui passer nos propres options de compilation. Utilise plutôt ce Makefile-ci ; appelle-le par exemple Makefile.fedora et déclare-le en tant que SOURCE1 : 
DESTDIR     = 
prefix      = /usr
USRBINDIR   = $(DESTDIR)$(prefix)/bin

CC = $(CROSS_COMPILE)gcc
LD = $(CROSS_COMPILE)gcc
LDFLAGS = -lz
INSTALL = install

all : ciso
ciso : ciso.o

ciso.o : ciso.c

install :
        $(INSTALL) -m 755 ciso $(USRBINDIR)/ciso

clean:
        rm -rf *.o
À la construction, tu n'aurais plus qu'à appeler ce Makefile ainsi : 
%build
make %{?_smp_mflags} -f %{SOURCE1} CFLAGS="$RPM_OPT_FLAGS"
D'ailleurs pourquoi avoir commenté la variable %{?_smp_mflags} ? Quoiqu'ici elle soit peu utile, compte tenu du peu à compiler, cette variable contient des options de make pour paralléliser les compilations. Il faut la laisser.

Tu peux aussi passer par un patch du Makefile, à ta convenance, pour cette correction, mais compte tenu de la petite taille du Makefile, le patch serait aussi gros que ce dernier. ^^


Au passage, rajoute un « BuildRequires : zlib-devel » à ton .spec. Et un paquet devel est ici inutile. Le développeur de ciso n'a rien prévu pour, donc pas de zèle.
En fait comme je l'ai dit plus haut j'ai suivi quelques recommandations à la réponse de mon post dans bugzilla redhat.
C'est pourquoi
- j'ai enlevé le %{?_smp_mflags} (car apparemment inutile...)
- j'ai fait un paquet zlib-devel avec le fichier .h ("MUST: Header files must be in a -devel package." dans le review guidelines )

Sinon le BuildRequires : zlib-devel est déjà dans mon spec .

En tout cas je vais prendre la solution du Makefile.fedora

Merci
Sorry pour le zlib-devel, je l'avais esquivé 🙂.

Pour le paquet ciso-devel, encore une fois, aucune bibliothèque n'est construite et le développeur n'a rien prévu de particulier (tant dans l'API de son programme que pour ce qu'il a décidé de faire installer dans son Makefile). Tu n'as pas à faire de paquet devel ici.

Quant à l'option %{?_smp_mflags}, pourquoi serait-elle inutile ? J'ai suggéré qu'elle était peu utile du fait du peu à compiler, mais par respect pour les guidelines et parce qu'on ne sait pas comment peut évoluer le code de ciso en taile, je la laisserai. Quelle raison a invoqué la personne sur Bugzilla ?
Quelle raison a invoqué la personne sur Bugzilla ?
Il indique que le Makefile ne l'interprète pas

Sinon j'ai fait le Makefile.fedora, commenté tout ce qui concerne le ciso-devel et ça passe OK tous les paquets dans rpmlint (ciso-1.0.0-1.fc10.src.rpm , ciso-1.0.0-1.fc10.i386.rpm et ciso-debuginfo-1.0.0-1.fc10.i386.rpm )

Par contre avec les flags de Fedora gcc gueule pas mal :
ciso.c: In function 'decomp_ciso':
ciso.c:142: warning: format '%ld' expects type 'long int', but argument 2 has type 'long long unsigned int'
ciso.c:143: warning: format '%d' expects type 'int', but argument 2 has type 'long unsigned int'
ciso.c:213: warning: format '%d' expects type 'int', but argument 4 has type 'long unsigned int'
ciso.c:90: warning: unused variable 'buf4'
ciso.c:87: warning: unused variable 'total_sectors'
ciso.c:84: warning: unused variable 'file_size'
ciso.c: In function 'comp_ciso':
ciso.c:283: warning: format '%ld' expects type 'long int', but argument 2 has type 'long long unsigned int'
ciso.c:284: warning: format '%d' expects type 'int', but argument 2 has type 'long unsigned int'
ciso.c:310: warning: format '%3d' expects type 'int', but argument 3 has type 'long long unsigned int'
ciso.c:243: warning: unused variable 'total_sectors'
ciso.c:289: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result
ciso.c:292: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result
ciso.c:390: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result

C'es gênant ? Fédoramment parlant...

J'ai remis à jour
URL Spec : http://chdorblog.free.fr/ciso.spec
URL SRPM : http://chdorblog.free.fr/ciso-1.0.0-1.fc10.src.rpm
Les flags de compilation de Fedora incluent des options de contrôle du code plus stricts. Mais ces messages d'avertissement sont bénins, tu peux les ignorer.