Byla vydána nová stabilní verze 7.8 dnes již jedenáctiletého webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 144. Přehled novinek i s náhledy v příspěvku na blogu.
GNU gettext (Wikipedie), tj. sada nástrojů pro psaní vícejazyčných programů, dospěl do verze 1.0. Po více než 30 letech vývoje. Přehled novinek v souboru NEWS.
Chris Kühl (CEO), Christian Brauner (CTO) a Lennart Poettering (Chief Engineer) představili svou společnost Amutable. Má přinést determinismus a ověřitelnou integritu do linuxových systémů.
Byla vydána (𝕏) nová verze 26.1 open source firewallové a routovací platformy OPNsense (Wikipedie). Jedná se o fork pfSense postavený na FreeBSD. Kódový název OPNsense 26.1 je Witty Woodpecker. Přehled novinek v příspěvku na fóru.
Deník TO spustil vlastní zpravodajský webový portál ToHledej.CZ s internetovým vyhledávačem a bezplatnou e-mailovou schránkou. Dle svého tvrzení nabízí 'Zprávy, komentáře, analýzy bez cenzury' a 'Mail bez šmírování a Velkého bratra'. Rozložením a vizuálním stylem se stránky nápadně podobají portálu Seznam.cz a nejspíše je cílem být jeho alternativou. Z podmínek platformy vyplývá, že portál využívá nespecifikovaný internetový vyhledávač třetí strany.
Computer History Museum (Muzeum historie počítačů) zpřístupnilo své sbírky veřejnosti formou online katalogu. Virtuálně si tak můžeme prohlédnout 'rozsáhlou sbírku archivních materiálů, předmětů a historek a seznámit se s vizionáři, inovacemi a neznámými příběhy, které revolučním způsobem změnily náš digitální svět'.
Ruský hacker VIK-on si sestavil vlastní 32GB DDR5 RAM modul z čipů získaných z notebookových 16GB SO-DIMM RAM pamětí. Modul běží na 6400 MT/s a celkové náklady byly přibližně 218 dolarů, což je zhruba třetina současné tržní ceny modulů srovnatelných parametrů.
Národní identitní autorita (NIA), která ovlivňuje přihlašování prostřednictvím NIA ID, MEP, eOP a externích identit (např. BankID), je částečně nedostupná.
Byla vydána nová verze 1.16.0 klienta a serveru VNC (Virtual Network Computing) s názvem TigerVNC (Wikipedie). Z novinek lze vypíchnout nový server w0vncserver pro sdílení Wayland desktopu. Zdrojové kódy jsou k dispozici na GitHubu. Binárky na SourceForge. TigerVNC je fork TightVNC.
Byla vydána nová verze 4.6 (𝕏, Bluesky, Mastodon) multiplatformního open source herního enginu Godot (Wikipedie, GitHub). Přehled novinek i s náhledy v příspěvku na blogu.
2.11.2014 20:48
| Přečteno: 1725×
| linux/unix
| 
| poslední úprava: 2.11.2014 21:06
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz.spec soubor a zdrojový tarball, takže bylo potřeba vytvořit zdrojový balík lokálně. Nedařilo se mi spustit fedpkg --dist f22 srpm v adresáři s .spec se nesmyslně snaží stáhnout tarball se zdrojáky, které má k dispozici. Nakonec jsem musel použít starý dobrý rpmbuild, který však podle všeho neumí pracovat se zdrojáky v aktuálním adresáři jako to dělá fedpkg.
ln -s `realpath netresolve-0.0.1.tar.xz` ~/rpmbuild/SOURCES/ rpmbuild -bs *.specDál jsem musel výsledek publikovat někde na webu, protože copr nepřijímá nic jiného než webová URL...
scp /home/pavlix/rpmbuild/SRPMS/netresolve-0.0.1-0.4.20141102git.src.rpm data:data/fedora/Předal jsem source rpm url copru pomocí webového rozhraní k buildu. Vzhledem k úpravám v upstreamu build podle očekávání selhal a dostal jsem se k logům na jejichž základě můžu
.spec soubor ladit. Až bude úspěšný build, budu vědět o něco více.
Nicméně tento postup je značně krkolomný. Jako by nestačilo, že tomu celému předcházela ručně spuštěná kombinace ./autogen.sh a make dist, nakopírování vzniklého tarballu do adresáře s .spec souborem a úprava .spec souboru, aby balík obsahoval aktuální datum, což jsem tak nějak považoval za nutné zlo při buildování pro Fedoru.
Osobně jsem dost zhýčkaný z Gentoo, které je relativně blízko mému ideálu balení software z gitu. Jestliže už RPM nepočítá s balením software přímo z gitu, představoval bych si to tak, že za všech okolností, tedy bez ohledu na to, jaké nástroje se chystám k buildu používat, začnu tím, že vytvořím adresář ~/fedora/netresolve (pro tento balík a při použití mé současné konvence umístění fedořích balíků v domovském adresáři), v něm vytvořím netresolve.spec a rovněž do něj uložím všechny ostatní potřebné soubory včetně zdrojového tarballu. Tak přesně to dělám jako maintainer fedořích balíků. V tu chvíli očekávám, že budu moci jedním příkazem spustit build. Jako fedoří maintainer používám fedpkg push & fedpkg build poté, co udělám potřebné úpravy a vytvořím gitovský commit, což s výhradami považuju za přijatelné. Pro scratch buildy používám fedpkg build --srpm --scratch, což zajistí lokální vytvoření SRPM balíku a jeho odeslání k buildu.
Dost by mě zajímalo, jestli je vůbec možné používat copr a přitom zavést nějaký efektivní workflow nad jedním adresářem se stejnou strukturou jako pro dist-git, a proč vůbec musím při jeho použití řešit převod .spec a zdrojového tarballu na SRPM, když to s koji u finálních buildů řešit vůbec nemusím a u scratch buildů to vyřeší volba --srpm na místě. O tom, že musím ještě řešit webové úložiště pro zdrojové balíky snad raději pomlčím.
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ý.
Tiskni
Sdílej:
fedpkg --dist=f22 srpm zajistí a počítám, že si ho i upravím, aby fungoval.
pokud menis Source ve spec file, musis upravit i soubor 'sources' aby se ti zbytecne nestahovalo neco co nepotrebujesJakým příkazem můžu nechat sources přizpůsobit novému souboru v případě, že balík není ve Fedoře?
4.11.2014 08:57
pavlix | skóre: 54
| blog: pavlix
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šší.
4.11.2014 08:59
pavlix | skóre: 54
| blog: pavlix
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.
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.
V prvotnej faze vyvoja bolo to tlacitko urcite velmi uzitocneV prvotní fázi vývoje bych GUI vůbec nepoužíval, zvlášť u takového projektu ;).
copr na to afaik nema vzdialene apiOno 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.
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?
Smyslem je ochrana před MITM mezi tvým serverem a strojem, kde běží copr.
8.11.2014 20:15
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.
#!/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)