Byla vydána nová verze 2.16 svobodného video editoru Flowblade (GitHub, Wikipedie). Přehled novinek v poznámkách k vydání. Videoukázky funkcí Flowblade na Vimeu. Instalovat lze také z Flathubu.
TerminalTextEffects (TTE) je engine pro vizuální efekty v terminálu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Od čtvrtka 30. 5. do soboty 1. 6. lze v Praze navštívit Veletrh vědy, tj. největší populárně naučnou akci v České republice, kterou každoročně od roku 2015 pořádá Akademie věd ČR. Vstup zdarma.
Canonical představil Ubuntu optimalizované pro jednodeskový počítač s RISC-V procesorem Milk-V Mars.
Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu optimalizovaná pro jednodeskové počítače na platformě ARM a RISC-V, ke stažení ale také pro Intel a AMD, byl vydán ve verzi 24.5.1 Havier. Přehled novinek v Changelogu.
Společnost xAI založena Elonem Muskem a stojící za AI LLM modelem Grok získala investici 6 miliard dolarů.
Finálový zápas mistrovství světa v ledním hokeji přinesl nový rekord NIX.CZ (𝕏): "Dosavadní absolutní maximum našeho propojovacího uzlu bylo překonáno v čase 21:10, kdy jsme při přenosu dat dosáhli 3,14 Tbps. Je třeba také doplnit, že po deváté hodině večerní byly na maximu i ostatní datové přenosy nesouvisející s hokejovým šampionátem".
Přihlaste svou přednášku na další ročník konference LinuxDays, který proběhne 12. a 13. října na FIT ČVUT v pražských Dejvicích. CfP poběží do konce prázdnin, pak proběhne veřejné hlasování a výběr přednášek.
Na crowdsourcingové platformě Crowd Supply byla spuštěna kampaň na podporu open source biometrického monitoru ve tvaru hodinek HealthyPi Move. Cena je 249 dolarů a plánovaný termín dodání listopad letošního roku.
Pokud je patch dostatečně kvalitní, tak jistě chcete v duchu svobodného softwaru ušetřit práci balíčkáři, který za balíček zodpovídá. Jistě, můžete tento patch poslat maintainerovi e-mailem, ale proč to dělat, když má buildservice takovou skvělou funkci, které říká Build Service Collaboration?
Princip spolupráce je poměrně prostý, nejdříve si ve svém domácím namespace home:nick
(např. home:m4r3k
) vytvoříte branch nadřazeného projektu, ve kterém chcete něco změnit. Pak provedete požadované úpravy a pomocí příkazu osc submitreq
provedete odeslání požadavku na začlenění vašich změn. Správci patřičného balíčku v nadřazeném projektu přijde e-mail, ve kterém bude o události informován, a jakmile si najde chvilku, tak provede kontrolu (code-review) a v případě, že nenajde problém, tak vaše úpravy začlení. Pokud problém nalezne, není nic snažšího, než vaše úpravy spolu s komentářem, co musíte ještě opravit/pozměnit, zamítnout.
Poněkud komplikovanější to je, pokud chcete přispívat do projektu openSUSE:Factory
. Struktura je následující: Balíčky, které spravuje maintainer A ve Factory, má maintainter také ve svém home:A:Factory (jeden příklad za všechny, Anička, která má pod palcem balíčky jako perlovské moduly, eject nebo openssh, má svůj vývojový strom k testování v projektu s názvem home:anicka:Factory
). A to je právě ten repositář, který byste měli branchovat, pokud chcete přispět patchem do některého z balíků ve Factory. Proč to tak je, se dá snadno odpovědět: Aby mohl správce balíček dostatečně otestovat a do distribuce se tak nezavleklo více zbytečných problémů. Jakmile správce uzná, že je balíček dostatečně otestován, provede také osc submitreq
. Až bude správcem projektu openSUSE:Factory tento požadavek přijat, tak se změna promítne do openSUSE Factory stromu. Více o struktuře vývoje openSUSE Factory prostřednictvím Collaboration je vidět na těchto slidech.
Řekněme, že mám projekt home:m4r3k:R-project a vy mi chcete poslat takový malý, hezký patch na balíček R-base (ten projekt opravdu mám a každý patch je opravdu vítán :-)). Nejdříve pomocí příkazu
marek@mantisha:~/Files/prace/buildservice> osc branch home:m4r3k:R-project R-base A working copy of the branched package can be checked out with: osc co home:m4r3k:branches:home:m4r3k:R-project/R-base marek@mantisha:~/Files/prace/buildservice>
provedete vytvoření virtuální kopie projektu home:m4r3k:R-project
ve vašem jmeném prostoru home:nick:branches
. Vznikne tak projekt home:nick:branches:home:m4r3k:R-project
(např. home:m4r3k:branches:home:m4r3k:R-project
) , který má jako sestavovací cíl nastaven projekt home:m4r3k:R-project/openSUSE_11.0
, což znamená, že se budou primárně používat balíčky z repositáře home:m4r3k:R-project/openSUSE_11.0
a až poté z jiných repositářů (jako třeba openSUSE_11.0
). Nyní si checkoutněte projekt home:nick:branches:home:m4r3k:R-project/R-base
příkazem
marek@mantisha:~/Files/prace/buildservice> osc co home:m4r3k:branches:home:m4r3k:R-project/R-base A home:m4r3k:branches:home:m4r3k:R-project A home:m4r3k:branches:home:m4r3k:R-project/R-base A home:m4r3k:branches:home:m4r3k:R-project/R-base/R-2.7.1.tar.lzma A home:m4r3k:branches:home:m4r3k:R-project/R-base/R-base.spec marek@mantisha:~/Files/prace/buildservice>
Když se podíváte na to, co osc
stahoval, a pak se podíváte třeba pomocí webového rozhraní do skutečného obsahu nově vytvořené kopie, tak zjistíte, že osc
stáhl skutečné soubory ze serveru, kdežto ve vytvořené kopii je jen soubor _link
, který již jistě důvěrně znáte z druhého dílu seriálu. Pokud jste četli i třetí díl tohoto seriálu, pak jistě vítě, že soubor _link
může obsahovat i různé patche, a to je v podstatě způsob, jak funkce Collaboration funguje. Vždycky, když v branchnutém balíčku něco změníte a provedete osc commit
, tak se vygeneruje diff
, který se na serveru uloží, a poté se balíček zkusí sestavit i s provedenými změnami.
Zde bych si dovolil apelovat na každého uživatele OBS: Vyzkoušejte prosím nejdříve baliček lokálně pomocí
osc build cílová-distribuce cílová-architektura nějaký.spec
a až poté provádějte commit
- šetříte tím cenný strojový čas buildovacích serverů.
Pokud máte zdrojové kódy úspěšně stažené, tak se můžete přesunout do adresáře, kam jste si je stáhli, a provést libovolné úpravy. Přidávat a odebírat soubory, upravovat jednotlivé soubory, ... jakmile své úpravy provedete a patřičně otestujete jak lokálně, tak na buildserveru, není nic snazšího, než je poslat správci nadřazeného projektu kontrole. Napište příkaz
osc submitreq create -m "Nějaká zpráva, nejlépe anglicky"
a systém automaticky vygeneruje zprávu pro správce cílového projektu a pošle mu e-mail, aby o vašem požadavku věděl.
Případně můžete vytvořit požadavek i bez toho, abyste měli stažený obsah repositáře. Provedete to pomocí příkazu
osc submitreq create home:nick:branches:home:m4r3k:R-project R-base home:m4r3k:R.project -m "nějaká zpráva, nejlépe anglicky"
Nyní už víte, jak takový "submit request" vytvořit - možná by vás však také zajímalo, co všechno musí udělat správce nadřazeného projektu, aby váš požadavek přijal, nebo zamítl. Opět se nejedná o nic složitého. Když se správce podívá na svou stránku My Projects, tak tam mimo jiné najde část Requests concerning me. Obsahuje všechny submit requesty, u nichž má právo rozhodnout o začlenění, nebo odmítnutí. Každý takový požadavek má své vlastní ID. Prostřednictvím tohoto ID může správce s požadavkem dále pracovat. Například příkazem osc submitreq show -d ID
si může maintainer zobrazit, co všechno pozměnil ten, kdo zaslal požadavek. O koho se jedná (tedy zdrojový projekt požadavku), cílový projekt požadavku a zprávu, která byla k požadavku přiložena pomocí parametru -m
. Dále se správci zobrazí diff
mezi původní verzí balíčku a větví, z níž požadavek přichází. Správce tak má k dispozici všechny důležité informace k tomu, aby mohl o požadavku rozhodnout - zda má skončit v jeho opečovávaném projektu, nebo raději v /dev/null
.
Svůj názor na balíček může správce vyjádřit pomocí dvou příkazů - buď příkazem
osc submitreq accept ID
pro přijetí, nebo příkazem
osc submitreq decline -m "jistě je slušné říci, proč požadavek zamítáme, nemyslíte?" ID
poslat požadavek do /dev/null
.
Na již zmiňované stránce My Projects vidíte také seznam všech submit requestů, které jste sami vytvořili a které dosud nebyly obslouženy správcem. Nacházejí se v části s nadpisem Requests by me.
Nástroje: Tisk bez diskuse
Tiskni Sdílej: