QtDMM


#1

Existuje nějaký jednoduchý způsob, jak donutit maintainera balíčku QtDMM, aby dodal do Fedory aktuální verzi programu QtDMM (0.9.3) místo obsolentní verze 0.8.12?
Zatím to řeším tak, že si rebuilduji vlastní rpm a srpm (pro FC27 byly nutné nějaké drobné zásahy do .spec). Tyto poskytuji autorovi programu a on je zveřejňuje na svých stránkách.


#2

Tady máš seznam kroků, které se mají dělat, pokud maintainer nedělá svojí práci: https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers


#3

Děkuji. Takže, první krok je postnout do Bugzilly, že stávající verze rpm neumožňuje programu např. spojení přes /dev/rfcomm0, zatímco nová verze programu ano a pak čekat, až se ozve maintainer?


#4

Normálně se dělají i bugy na to, že v upstreamu existuje nová verze a maintainer na tu verzi neaktualizoval. Není potřeba uvádět nějaký konkrétní technický problém.


#5

Dle očekávání ticho po pěšině. Takže mám počítat s tím, že po dalších 14 dnech reportování na lampárnu redhatu se mám sám stát maintainerem balíčku? Ale já se nechci stát maintainerem, tím už jsem si prošel, je to neskutečná pruda.
Narazil jsem na několik dalších zahnilých balíčku v nové fedoře. Přitom udržovat aktuální verze je práce tak asi na pět minut čistého času. Klidně bych to dělal, ale byrokratické požadavky jsou pro mne neakceptovatelné.


#6

No a psals o tom třeba na Fedora devel list? Možná se toho někdo chytne, ale nikdo nemá povinnost starat se o odložené balíčky.
Jinak balíčků ve Fedoře je 20 tisíc, správce každého z nich má de facto root přístup do milionů systémů. To bude vždy vyžadovat byrokracii. Nikdo to právo nedá hned někomu, kdo se zrovna zjevil z Internetu. Pokud už jednou jsi schválený správce balíčků, přebírání jiných je výrazně jednodušší.


#7

To je pochopitelné, že maintainer má možnost do svého balíčku propašovat maligní kód a podělat tak systém miliónu uživatelů, určitě se to i děje, stejně jako v softu pro jiné platformy. Jenže nepochopím, jak tomu mají zabránit víceméně byrokratické požadavky na nové maintainery. Jimi vkládaný kód ani osobní mravnostní profil tyto požadavky stejně nijak neprověří. Už si to přesně nepamatuji, ale jedna z věcí, které maintainerství vyžadovalo, byla instalace jakéhosi redhatího softu do mého kompu. Neměl jsem sílu prokousávat se návody ani chuť si plevelit počítadlo. A ani čas nazbyt, jsem zaměstnaný člověk. Uvidíme, co na to ten devel list. Číslo dvě ze sedmi nutných registrací.
Jen tak na okraj - Greg Kroah-Hartman s mým patchem do kernelu žádný problém neměl a vyřídit se to dalo jedním formulářem a e-mailem za pár minut. Fedora je zřejmě o kus dál. Každopádně dík za odpověď.


#8

Njn, ale to jsi narazil na aktivního správce. Problém tady je, že správce aktivní není. Jinak by klidně taky mohl přijmout patch z bugzilly nebo přes email. Věřím tomu, že pokud bys chtěl přidat patch do nějakého modulu v kernelu, který nemá aktivního správce, tak to taky nebude tak jednoduché.


#9

Proto tady ale existuje copr.fedoraproject.org kde si muzes balicek ubalit sam na infrastrukture fedory a pak ho nabizet ostatnim ale oficialnim repu nebude.


#10

Ten copr mne teda nenapadl. Pokud by se jednalo o balíček, který není ve standardní fedoře, pak bych o tom uvažoval jako o řešení. V tomto případě bych byl raději, kdyby někdo dokopal maintainera udělat jednoduché “rpmbuild -ba qtdmm.spec”.


#11

Když jsme u těch zdrojů mimo Fedoru, tak by možná stálo za to to hodit do Flathubu. Ten má za cíl právě odstranit tu mezivrstvu v podobě správce v distribuci mezi autorem a uživatelem. Stačí tam poslat funkční flatpak a jak to projde review, tak to zařadí. Pak by bylo nejlepší to předat přímo autorovi aplikace, ať si to do budoucna buildí sám. Potom můžou mít uživatelé (nejen) Fedory jednoduchý přístup vždy k té nejaktuálnější verzi.