1.) Ty globaly na zacatku v pripade tohoto baliku neprinaseji zadny zisk, protoze %{genericname} je uplne stejne jako %{name} a %{version} dokonce prepisuje sebe sama .... Name: totiz generuje %{name} a Version: generuje %{version} ... udelal jsi tim padem %{name} = %{genericname} a %{version} = %{version} ... Navic pak vsechna makra ve specu vzajemne michas :] Idealni je mit spec co nejjednodussi a nejprehlednejsi. Timhle se lehce zhorsuje prehlednost. 2.) Licence je LGPLv2 ... to lze vycist z prilozeneho licencniho souboru ... byva zvykem, ze upstream priklada spise TXT verzi ... nevim, co to zase upstream napadlo .... bohuzel typicky chybi ve zdrojacich licencni statement, coz je opet chyba upstreamu ... obcas tohle podle nalady upstreamu omlacime o hlavu taky, ale jeste se to da tolerovat ... 3.) # Requires(post): jpackage-utils # Requires(postun): jpackage-utils Tyhle veci byly nutne kdyz se jeste pouzivalo makro %update_maven_depmap. Ty tam tohle makro mas a presto mas jpackage-utils zakomentovane .... Doporucuju smazat makro a tim padem nebudou potreba ani tyhle Requires(post) a Requires(postun). 4.) Zapomnel jsi smazat predgenerovane apidocs ... pridej "api" do rm -rf -predgenerovane veci by se mely mazat vzdy bez ohledu na to, jestli jsou/nejsou v ramci buildu vyuzity -je to pro sichr a reviewer to pak nemusi proverovat 5.) %add_to_maven_depmap %{group_id} %{name} %{version} JPP %{name} -do tohoto makra predavas neexistujici group_id ... protoze jsi radek prevzal ze specu, kde bylo nadefinovane jako global, takze se v /etc/maven/fragments vygeneruje toto %{group_id} a melo tam byt toto net.sf.javamusictag. Group ID a Artifact ID je mozne vycist prave z POM souboru. Nicmene ... makro add_to_maven_depmap se jiz nepouziva ... misto nej se pouziva kratsi add_maven_depmap, ktere si dokaze POM soubor samo zparsovat a tuto informaci si samo vytahne. Na to se muzes mrknout do toho jsoup.spec, ktery jsem Ti poslal. 6.) Pokud je soucasti zdrojoveho balicku licencni soubor, tak ho musis vzdy pribalit jako dokumentaci a to jak do hlavniho baliku, tak i do javadoc baliku. README, CHANGELOGy a podobne kravinky staci jen v hlavnim baliku. 7.) sekci "%files javadoc" tam mas dvakrat 8.) s tou group "System Environment/Libraries" si nejsem uplne jisty ... ja tyhle veci davam do "Development/Libraries" ... zkousel jsem to uz drive hledat a v packaging guidelines to moc popsane neni. Musel bych hledat lepe a jelikoz to delam nerad, tak to zkus proverit sam :] 9.) rpmlint hlasi jid3lib.src: W: file-size-mismatch jid3lib-0.5.4.pom = 1258, http://repo1.maven.org/maven2/net/sf/javamusictag/jid3lib/0.5.4/jid3lib-0.5.4.pom = 1259 tady si nejsem jisty, jestli je spravna velikost 1258 nebo 1259 ... firefox to stahne jako 1258 a curl jako 1259 ... wget mi selhal uplne ... patrne proto, ze na maven.org bude nejaky divoky redirect ... Kazdopadne ... zdrojove soubory je nutne ponechavat v jejich originalnim tvaru .... reviewer ma za ukol zkontrolovat, jestli se zdroj z netu shoduje s tim, co je zabaleno ve zdrojovem baliku ... Do review se bezne dava MD5SUM obou. V tomto pripade jde o problem pri stahovani, kteremu se mozna nekdy casem i nekdo bude venovat (az to nekoho vytoci). Budto je blbe firefox a nebo curl ... vlastne ani nevim, co rpmlint interne pouziva ... muzeme to pak dohledat. 10.) pribalene release*.txt soubory jsou ukoncene CR+LF ... tohle nemame na linuxu radi a konvertujeme vse na ciste LF 11.) Changelog ve specu radeji ukoncuj prazdnym radkem 12.) build pomoci mocku neprosel ... ve specu Ti chybi zavislosti. Na nasledujicim linku jsem zanechal tri skripty na build http://jcapik.fedorapeople.org/files/jid3tag/ jid3lib.sh ... lokalne bez mocku jid3lib.mock.sh ... pomoci mocku - trva dlouho, ale pomuze ti odhalit chybejici BuildRequires jid3lib.koji.sh ... vzdalene na buildsystemu pomoci koji v rezimu testovaciho buildu staci je zkopirovat do adresare ~/rpmbuild/SPECS a proste je z toho mista rovnou spustit prvni dve varianty vesele pouzivej .... treti variantu s koji zatim nepouzivej !!!BACHA!!! .... maze to vse v SRPMS, RPMS, BUILDROOT a BUILD ... neni dobre si v techto mistech cokoliv nechavat