V neděli 26. května lze navštívit Maker Faire Rychnov nad Kněžnou, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Byla vydána nová stabilní verze 3.20.0, tj. první z nové řady 3.20, minimalistické linuxové distribuce zaměřené na bezpečnost Alpine Linux (Wikipedie) postavené na standardní knihovně jazyka C musl libc a BusyBoxu. Z novinek lze vypíchnou počáteční podporu 64bitové architektury RISC-V.
Společnost Jolla na akci s názvem Jolla Love Day 2 - The Jolla comeback představila telefon se Sailfish OS 5.0 Jolla Community Phone (ve spolupráci se společností Reeder) a počítač Jolla Mind2 Community Edition AI Computer.
LibreOffice 24.8 bude vydán jako finální v srpnu 2024, přičemž LibreOffice 24.8 Alpha1 je první předběžnou verzí od začátku vývoje verze 24.8 v prosinci 2023. Od té doby bylo do úložiště kódu odesláno 4448 commitů a více než 667 chyb bylo v Bugzille nastaveno jako opravené. Nové funkce obsažené v této verzi LibreOffice najdete v poznámkách k vydání.
Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 141 (pdf) a HackSpace 78 (pdf).
Byla vydána verze 2.0.0 programovacího jazyka Kotlin (Wikipedie, GitHub). Oficiálně bude představena ve čtvrtek na konferenci KotlinConf 2024 v Kodani. Livestream bude možné sledovat na YouTube.
Byla vydána nová major verze 27.0 programovacího jazyka Erlang (Wikipedie) a související platformy OTP (Open Telecom Platform, Wikipedie). Přehled novinek v příspěvku na blogu.
Byla vydána nová verze 1.8.0 svobodného multiplatformního softwaru pro konverzi video formátů HandBrake (Wikipedie). Přehled novinek v poznámkách k vydání na GitHubu. Instalovat lze také z Flathubu.
Microsoft představil nové označení počítačů Copilot+. Dle oznámení se jedná se o počítače poskytující funkce umělé inteligence. Vedle CPU a GPU mají také NPU (Neural Processing Unit). Uvnitř představených Copilot+ notebooků běží ARM čipy Qualcomm Snapdragon X Elite nebo X Plus.
Příspěvek na blogu Codean Labs rozebírá zranitelnost CVE-2024-4367 v PDF.js, tj. mj. prohlížeči PDF souborů ve Firefoxu. Při otevření útočníkem připraveného pdf souboru může být spuštěn libovolný kód v JavaScriptu. Vyřešeno ve Firefoxu 126.
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: