copr: první pokusy (diskuse)

[Radek Miček]

Má copr být něco jako openSUSE Build Service? Pokud ano, tak proč nepoužít rovnou openSUSE Build Service, který podporuje i Fedoru?

[Michal Kubeček]

NIH :-)

[pavlix]

Vzhledem k tomu, že teď všichni v okolí používají copr, když chtějí něco takhle publikovat mimo hlavní fedoří strom, tak jsem chtěl vyzkoušet prvně ten. OBS (dneska snad už Open Build Service, neutrání název) bude hned druhý na řadě, pokud se copr ukáže jako nevyhovující. Důvody, proč copr vznikl a proč případně nestaví nad OBS neznám, ale jsou pokud vím veřejně popsané, takže si je každý může přečíst a následně okomentovat.

[Marek 'marx' Grác]

OSB podporuje Fedoru, ale iba ako cieľovú platformu. Na tom, aby to korektne fungovalo na nej sa robí, s trochou šťastia bude diplomka obhájená v zime.

[pavlix]

Můžeš to nějak rozvést?

[Miroslav Suchy]

https://fedorahosted.org/copr/wiki/UserDocs#DidyouconsiderOBS Kde jsou odkazy na me tri blogposty kde jsem zvazoval OBS. Na OBS pro Fedoru momentalne pracuje Josef Stribny. Jednoho dne se tam dostaneme, ale kdybychom cekali na OBS, tak bychom jeste ted nemeli Copr a nevznikla by ta spousta projektu, ktera se kolem nej nabalila.

[pavlix]

To asi poslouží i jako odpověď Radkovi a Michalovi.

[zofrey]

rpmbuild --define "_sourcedir `pwd`" --define "_srcrpmdir `pwd`" --define "_rpmdir `pwd`" ...

[pavlix]

To bych zhruba očekával, že fedpkg --dist=f22 srpm zajistí a počítám, že si ho i upravím, aby fungoval.

[zofrey]

$ fedpkg --dist=f22 srpm

Wrote: /home/zofrey/devel/git/fedora/php-geshi/epel7/php-geshi-1.0.8.11-3.fc22.src.rpm

pokud menis Source ve spec file, musis upravit i soubor 'sources' aby se ti zbytecne nestahovalo neco co nepotrebujes

[pavlix]

pokud menis Source ve spec file, musis upravit i soubor 'sources' aby se ti zbytecne nestahovalo neco co nepotrebujes

Jakým příkazem můžu nechat sources přizpůsobit novému souboru v případě, že balík není ve Fedoře?

[zofrey]

co treba

md5sum GeSHi-1.0.8.12.tar.bz2 > sources

[pavlix]

To by šlo :).

[Miroslav Suchy]

Fedpkg to neumi (zatim - dokud nebude dist-git pro Copr). Ale je mozne pouzit bud Tito nebo dgroc. Viz https://fedorahosted.org/copr/wiki/UserDocs#CanCoprbuilddirectlyfromgit

[pavlix]

Popravdě mi nejde jen o build z gitu jako fedpkg push && fedpkg build, ale i o build z adresáře ve smyslu fedpkg build --srpm --scratch, což by navíc mělo být podstatně jednodušší.

[pavlix]

Jinak samozřejmě netrvám na tom, že se bude SRPM buildovat lokálně, to považuju spíše za workaround. Osobně bych neměl problém, kdyby se prostě vytvořil a poslal git commit, který by mimo build nikde nefiguroval (tedy ani lokálně, ani vzdáleně). Stejně tak by bylo heské mít repozitáře rozdělené na testing a stable.

[jas]

UPDATE: To tlačítko na zopakování buildu se zdá býti k ničemu, vzhledem k tomu, že ani nestáhne opravený zdrojový balík z uvedeného URL a místo toho použije ten původní špatný.

To nie je tak celkom pravda, build moze padnut aj kvoli veciam, co nesuvisia so samotnym srpm, napr. nedostatok ram alebo miesta na disku na pridelenej masine, co sa mi aj par krat stalo. Vtedy to tlacitko zmysel ma.

[pavlix]

Pak by neměl být problém poslat nový build se stejným SRPM. Jednak by to měla být zcela výjimečná situace, jednak nevidím důvod k tomu, aby byl build nového SRPM výrazně složitější než opakovaný pokus o build starého. Větší problém ale vidím v tom, že to UI vede k očekáváním, která pak nejsou splněna (jako například že stažení SRPM ze zdroje je součást buildu a rebuild se tedy ujistí, zda má aktuální kus).

[jas]

V prvotnej faze vyvoja bolo to tlacitko urcite velmi uzitocne, tam sa to rozsypavalo urcite skoro stale. Ja som zachytil ostru testing fazu a aj tam som mal problemy, kde som to vyuzil. Samozrejme to chce nieco narocnejsie na buildenie, aby na tie problemy clovek narazil.

S tym, ze by to chcelo nejaky lepsi sposob nez manualny upload samozrejme suhlasim. Napr. koji toto riesi moznostou uploadu src.rpm na ich servere (preto funguje fedpkg --srpm --scratch), copr na to afaik nema vzdialene api. Rozmyslal som nad zneuzitim koji na tieto ucely, ale v pripade koji api to nie je vseobecne zneuzitelne -- vracia to nieco ako lokalny identifikator uploadu toho src.rpm, ktory nie je stiahnutelny z vonka.

[pavlix]

V prvotnej faze vyvoja bolo to tlacitko urcite velmi uzitocne

V prvotní fázi vývoje bych GUI vůbec nepoužíval, zvlášť u takového projektu ;).

copr na to afaik nema vzdialene api

Ono by se to dalo schovat i tím, že by dotyčný tool nahrál data třeba na fedorapeople, když už stejně člověk potřebuje fedoří account.

[Miroslav Suchy]

Copr vzdy stahne novy balik. Akorat pokud pouzijete stejne NEVRA, tak musite rict vasemu prohlizeci at si reloadne cache, kdyz si prohlizite logy: https://fedorahosted.org/copr/wiki/UserDocs#WhyCoprdoesnotdownloadmyupdatedpackage

[pavlix]

Dobrá poznámka. Nedalo by se nějak prohlížeči říct, ať tyhle věci necachuje? Na to přece má HTTP prostředky, ne? Navíc se mi vůbec nelíbí ta poznámka, že dělám něco špatně. Nevidím důvod bumpovat release při každé úpravě, která má vést k tomu aby vznikl první úspěšný build, a nejsem si vědom, že by se to v koji dělalo. Bumpuje se pokud vím vždy kvůli buildům (ve smyslu úspěšně zbuildovaných výsledků), nikoli kvůli commitům.

[jasom]

ja mam dnes riadny copr

[xkucf03]

Předal jsem source rpm url copru pomocí webového rozhraní k buildu.

Jak je to s kontrolou podpisu nebo alespoň otisku zdrojového balíčku?

[pavlix]

Nechápu smysl otázky, na zdrojovém balíku není, co kontrolovat. Smyslem té služby je zpracovat libovolný zdrojový balík, který službě předám.

[xkucf03]

Smyslem je ochrana před MITM mezi tvým serverem a strojem, kde běží copr.

[pavlix]

Good catch. Bezpečnostní slabina, na kterou narážíš je důsledkem toho, že copr vůbec umožňuje stahovat data z libovolných serverů. Správně by měl umět stahovat výhradně z fedoří infrastruktury a tím by byl problém vyřešen. Navíc by měl CLI klient zvládat přímý upload na fedoří infrastrukturu (zda to bude copr nebo třeba fedorapeople považuju za imlementační detail). Tohle by se rozhodně mělo pořešit.

[pavlix]

Tak jsem se rozhodl vrátit ke copru a nainstalovat si ho do Gentoo. Ten software je v pythonu, takže očekávám buď setup.py nebo alespoň Makefile.am. Objevil jsem setup.py až v podadresáři cli, ale ten sám o sobě stejně nefunguje. Hlavně že se mezi zdrojáky nachází soubor README, ve kterém ovšem není ani slovo o tom, jak software správně instalovat. Tak snad se to zlepší a nebudu muset dopisovat vlastní build systém jako součást ebuildu.

[pavlix]

Tak musím přiznat, že to nakonec bylo jednodušší než jsem čekal, ale musel jsem zcela nestandardně vytvořit několik ebuildů nad jednom zdrojem a ručně nastavovat cestu ke zdrojákům.

[pavlix]

Pár řádků, které zdá se řeší největší usability fail copru a za předpokladu, že je fedoří infrastruktura schopná bezpečně komunikovat, tak i ten bezpečnostní problém, na který upozornil Franta.

#!/bin/sh

user="$USER"
project="$1"
srpm="$2"

scp $srpm fedorapeople.org:public_html/ || exit 1
copr-cli build "$project" "http://fedorapeople.org/$user/$srpm" || exit 1

(~/bin/copr-build)