Byla vydána nová verze 9.13 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Byla vydána nová stabilní verze 3.22.0, tj. první z nové řady 3.22, minimalistické linuxové distribuce zaměřené na bezpečnost Alpine Linux (Wikipedie) postavené na standardní knihovně jazyka C musl libc a BusyBoxu. Přehled novinek v poznámkách k vydání.
FEL ČVUT vyvinula robotickou stavebnici pro mladé programátory. Stavebnice Brian byla navržená speciálně pro potřeby populární Robosoutěže. Jde ale také o samostatný produkt, který si může koupit každý fanoušek robotiky a programování od 10 let, ideální je i pro střední školy jako výuková pomůcka. Jádro stavebnice tvoří programovatelná řídicí jednotka, kterou vyvinul tým z FEL ČVUT ve spolupráci s průmyslovými partnery. Stavebnici
… více »Ubuntu bude pro testování nových verzí vydávat měsíční snapshoty. Dnes vyšel 1. snapshot Ubuntu 25.10 (Questing Quokka).
Společnost Netgate oznámila vydání nové verze 2.8.0 open source firewallové, routovací a VPN platformy pfSense (Wikipedie) postavené na FreeBSD. Přehled novinek v poznámkách k vydání.
Byla vydána nová verze 6.16 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Tor Browser byl povýšen na verzi 14.5.3. Linux na verzi 6.1.140. Další změny v příslušném seznamu.
Člověk odsouzený za obchod s drogami daroval letos ministerstvu spravedlnosti 468 kusů kryptoměny bitcoin, které pak resort v aukcích prodal za skoro miliardu korun. Darováním se zabývá policejní Národní centrála proti organizovanému zločinu (NCOZ). Deníku N to potvrdil přímo ministr spravedlnosti Pavel Blažek (ODS). Podle resortu bylo nicméně vše v souladu s právem.
Svobodný a otevřený multiplatformní editor EPUB souborů Sigil (Wikipedie, GitHub) byl vydán ve verzi 2.5.0. Stejně tak doprovodný vizuální EPUB XHTML editor PageEdit (GitHub).
Na základě národního atribučního procesu vláda České republiky označila Čínskou lidovou republiku za zodpovědnou za škodlivou kybernetickou kampaň proti jedné z neutajovaných komunikačních sítí Ministerstva zahraničních věcí ČR. Tato škodlivá aktivita, která trvala od roku 2022 a zasáhla instituci zařazenou na seznam české kritické infrastruktury, byla provedena kyberšpionážní skupinou APT31, veřejně spojovanou se zpravodajskou službou Ministerstvo státní bezpečnosti (MSS).
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: