Všem vše nejlepší do nového roku 2026.
Crown je multiplatformní open source herní engine. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT a GPLv3+. Byla vydána nová verze 0.60. Vyzkoušet lze online demo.
Daniel Stenberg na svém blogu informuje, že po strncpy() byla ze zdrojových kódů curlu odstraněna také všechna volání funkce strcpy(). Funkci strcpy() nahradili vlastní funkcí curlx_strcopy().
Byla vydána nová verze 25.12.30 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Shotcut je vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Společnost Valve publikovala přehled To nej roku 2025 ve službě Steam aneb ohlédnutí za nejprodávanějšími, nejhranějšími a dalšími nej hrami roku 2025.
Byly publikovány výsledky průzkumu mezi uživateli Blenderu uskutečněného v říjnu a listopadu 2025. Zúčastnilo se více než 5000 uživatelů.
V dokumentově orientované databázi MongoDB byla nalezena a v upstreamu již opravena kritická bezpečností chyba CVE-2025-14847 aneb MongoBleed.
Při úklidu na Utažské univerzitě se ve skladovacích prostorách náhodou podařilo nalézt magnetickou pásku s kopií Unixu V4. Páska byla zaslána do počítačového muzea, kde se z pásky úspěšně podařilo extrahovat data a Unix spustit. Je to patrně jediný známý dochovaný exemplář tohoto 52 let starého Unixu, prvního vůbec programovaného v jazyce C.
FFmpeg nechal kvůli porušení autorských práv odstranit z GitHubu jeden z repozitářů patřících čínské technologické firmě Rockchip. Důvodem bylo porušení LGPL ze strany Rockchipu. Rockchip byl FFmpegem na porušování LGPL upozorněn již téměř před dvěma roky.
K dispozici je nový CLI nástroj witr sloužící k analýze běžících procesů. Název je zkratkou slov why-is-this-running, 'proč tohle běží'. Klade si za cíl v 'jediném, lidsky čitelném, výstupu vysvětlit odkud daný spuštěný proces pochází, jak byl spuštěn a jaký řetězec systémů je zodpovědný za to, že tento proces právě teď běží'. Witr je napsán v jazyce Go.
Na vytvoření jednoduchého repozitáře existuje nespočet nástrojů. Pro účely
tohoto článku jsem zvolil reprepro, protože nabízí jednoduché rozhraní a přesto poskytuje velmi mnoho funkcí.
Pro začátek si vytvoříme adresář, kde budeme chtít, aby reprepro pracovalo:
$ mkdir reprepro $ cd reprepro
Dále potřebujeme adresář pro nastavení:
$ mkdir conf
Minimálně musíme říci, jaké distribuce budeme v repozitáři mít, vytvoříme tedy
conf/distributions (tato ukázka obsahuje jenom jednu distribuci, ale můžeme jich použít, kolik jen chceme):
Origin: Stojan Jakotyč Label: Unofficial Packages Suite: unstable Codename: sid Architectures: i386 amd64 source Components: main contrib non-free Description: My playground
Nyní již reprepro můžeme normálně používat. Pokud jsme použili v konfiguraci
distribucí Suite, můžeme si třeba nechat vygenerovat symbolické odkazy na kódová jména:
$ reprepro -b . createsymlinks
Parametr -b určuje cestu k pracovnímu stromu reprepro, v tomto případě je to tedy aktuální adresář. Jak vidíme, reprepro už si nijak nestěžuje, takže můžeme přidat první balíček do repozitáře:
$ reprepro -b . include unstable /tmp/ukolovnik_1.0-4_i386.changes Exporting indices...
Když se nyní podíváme do pracovního adresáře, zjistíme, že se vytvořilo
několik nových adresářů a souborů. Struktura je podobná jako na jakémkoliv
mirroru Debianu - tedy adresář pool obsahuje vlastní balíčky, kdežto dists seznamy balíčků pro dané distribuce. Dále si reprepro vytvoří adresář db, kde jsou uloženy jeho interní informace o repozitáři a balíčcích.
Ručně přidávat balíčky je ale dost práce, tak je určitě lepší tento proces
zautomatizovat. Podporu už pro to reprepro má, stačí mu v souboru
conf/incoming říci, odkud si balíčky brát:
Name: incoming IncomingDir: /tmp/reprepro/incoming TempDir: /tmp/reprepro/tmp Allow: unstable>sid Default: sid
První řádek určuje jméno této fronty, můžeme použít cokoliv. Druhý adresář,
kde se fronta nachází, a třetí místo, kam se mohou odkládat dočasné soubory.
Parametry Allow a Default určují pravidla pro nahrávání balíčků. Zde tedy balíček určený pro unstable skončí v distribuci sid a všechny ostatní také v distribuci sid. Zpracování pak spustíme následujícím příkazem, případně ho můžeme dát do cronu a nechat frontu zpracovávat automaticky:
$ reprepro -b . processincoming incoming Exporting indices... Deleting files no longer referenced...
Pokud Debian používáte již nějakou chvíli, asi víte, že program apt-file umí vyhledávat v seznamech souborů nenainstalovaných balíčků. Aby to ovšem fungovalo, musí být v repozitáři seznam souborů v balíčcích (soubor Contents). Program reprepro umí generovat i tento seznam, stačí zapnout tuto volbu v conf/distributions. Když už budeme v tomto souboru něco měnit, můžeme ještě zapnout bz2 kompresi pro všechny seznamy:
DebIndices: Packages Release . .gz .bz2 DscIndices: Sources Release . .gz .bz2 Contents: . .gz .bz2
Pokud máme pocit, že by se balíček mohl hodit i někomu dalšímu, tak je dobré ho dostat do distribuce. Jakékoliv nové balíčky musejí před přijetím projít frontou nových balíčků, kde čekají na to, až je správce ftp repozitáře zkontrolují a přijmou do distribuce. Po této kontrole už není nahrávání nových verzí omezeno.
Než se však pokusíme dostat náš výtvor do distribuce, měl by být balíček v co
nejlepším stavu, abychom ušetřili práci sobě i dalším lidem, kteří se s
balíčkem budou muset poprat. Pro základní kontrolu poslouží lintian popsaný dříve v seriálu, ale nemalou pozornost bychom měli věnovat také licencím
jednotlivých souborů a jejich popisu v debian/copyright.
Když si myslíme, že máme vše správně, můžeme pokročit k nahrávání. Jako naprostý nováček máme možnost jen si nechat balíček nějakým vývojářem nahrát do distribuce. Tomuto se říká sponzorování a sponzor je zodpovědný za kvalitu balíčku, přestože se o něj stará někdo jiný. Poté, co získáme dostatek zkušeností, je možné se pokusit postoupit na vyšší úroveň a stát se Debian maintanerem, kdy už můžeme nahrávat svoje balíčky samostatně. Další možností k růstu je Debian developer, kdy již můžeme do distribuce nahrávat cokoliv (samozřejmě při dodržování daných pravidel).
Jak již jsem napsal dříve, sponzorování balíčku je zpočátku jediný způsob, jak dostat balíček do distribuce. Nejtěžším úkolem je (hned po vytvoření bezvadného balíčku) nalezení vývojáře, který bude ochotný balíček zkontrolovat a nahrát do distribuce. Pro tento účel nám poslouží server http://mentors.debian.net, kam balíčky pro sponzory můžeme nahrávat, a mailing list debian-mentors, na kterém se pokusíme nalézt sponzora.
Lidí hledajících sponzora pro svůj balíček je hodně a čas vývojářů je omezený, takže je nutné zaujmout a dobře odvést svojí práci. Pokud se snažíme do distribuce dostat stopadesátý editor, tak určitě budeme mít mnohem těžší pozici, než při práci s nějakým zajímavým nástrojem nebo hrou. Snažte se proto při psaní mailu myslet na to, že musíte někoho zaujmout a uvést všechny relevantní informace, které by sponzor mohl potřebovat (na stránkách mentors.debian.net si můžete zkopírovat šablonu, která bude všechny potřebné informace obsahovat).
V prvních balíčcích budou obvykle snadno dohledatelné chyby, takže když má někdo k našemu balíčku připomínky, jedná se většinou o dobře míněné rady; snažte se jimi řídit. Nicméně se nebojte diskutovat o případných alternativních řešeních, nikdo není neomylný. Většina sponzorů má seznam věcí, které kontrolují, jeden z nich je například Checklist for sponsored packages. Občas nebývá od věci si takový seznam projít ještě před předhozením balíčku na mailing list a jeho veřejným pranýřováním :-).
Pokud už se s nějakým sponzorem dohodneme na jednom balíčku, obvykle bývá i přístupnější nahrávání našich dalších balíčků, ale nemusí to být pravidlem.
V současné době je poměrně velká část balíčků spravována v týmech. Jedná se o poměrně snadnou možnost, jak spravovat balíček bez toho, aby se člověk musel stát Debian maintainerem nebo developerem nebo musel složitě shánět sponsora, protože se v týmu snáze najde nějaký Debian developer, který balíček nahraje. Jinak se jedná o stejný případ jako sponzorování.
Pokud už máme za sebou nějakou práci na sponzorovaném balíčku, můžeme zkusit
za tento balíček kompletně převzít zodpovědnost a stát se Debian maintainerem.
Když se jím staneme, můžeme nahrávat svoje balíčky, které sponzor nahraje do
distribuce s nastaveným příznakem DM-Upload-Allowed. Informace o tom, jak se stát Debian maintainerem, najdeme na wiki.debian.org/Maintainers.
Jako Debian developer už můžeme nahrávat do distribuce cokoliv a musíme tedy splnit o něco přísnější podmínky. Nicméně tento postup je jasně definovaný a při troše štěstí není problém ho celý absolvovat během půl roku.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej: