V repozitáři AUR (Arch User Repository) linuxové distribuce Arch Linux byly nalezeny a odstraněny tři balíčky s malwarem. Jedná se o librewolf-fix-bin, firefox-patch-bin a zen-browser-patched-bin.
Dle plánu by Debian 13 s kódovým názvem Trixie měl vyjít v sobotu 9. srpna.
Vývoj linuxové distribuce Clear Linux (Wikipedie) vyvíjené společností Intel a optimalizováné pro jejich procesory byl oficiálně ukončen.
Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie).
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 12.0 (Mastodon). Forgejo je fork Gitei.
Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 155 (pdf) a Hello World 27 (pdf).
Hyprland, tj. kompozitor pro Wayland zaměřený na dláždění okny a zároveň grafické efekty, byl vydán ve verzi 0.50.0. Podrobný přehled novinek na GitHubu.
Patrick Volkerding oznámil před dvaatřiceti lety vydání Slackware Linuxu 1.00. Slackware Linux byl tenkrát k dispozici na 3,5 palcových disketách. Základní systém byl na 13 disketách. Kdo chtěl grafiku, potřeboval dalších 11 disket. Slackware Linux 1.00 byl postaven na Linuxu .99pl11 Alpha, libc 4.4.1, g++ 2.4.5 a XFree86 1.3.
Ministerstvo pro místní rozvoj (MMR) jako první orgán státní správy v Česku spustilo takzvaný „bug bounty“ program pro odhalování bezpečnostních rizik a zranitelných míst ve svých informačních systémech. Za nalezení kritické zranitelnosti nabízí veřejnosti odměnu 1000 eur, v případě vysoké závažnosti je to 500 eur. Program se inspiruje přístupy běžnými v komerčním sektoru nebo ve veřejné sféře v zahraničí.
Vláda dne 16. července 2025 schválila návrh nového jednotného vizuálního stylu státní správy. Vytvořilo jej na základě veřejné soutěže studio Najbrt. Náklady na přípravu návrhu a metodiky činily tři miliony korun. Modernizovaný dvouocasý lev vychází z malého státního znaku. Vizuální styl doprovází originální písmo Czechia Sans.
Poznámka: Pokud nerozumíte některým věcem souvisejícím s ebuildy, přečtěte si obsah seriálu o ebuildech.
Běžně se doporučuje neinstalovat software mimo balíčkovací systém. To samozřejmě platí i na Gentoo. Když narazíte na software, který si chcete nainstalovat a není pro něj ebuild v oficiálním stromu, jednou z možností je napsat si ebuild vlastní (vizte seriál Gentoo ebuild). Tyto ebuildy ovšem nemůžete dát do hlavního stromu, protože by byly během další synchronizace vymazány. Proto existují overlaye.
Pro začátek si pro overlay vytvořte nějaký adresář, řekněme třeba /usr/local/portage
(dále jen overlay).
mkdir -p /usr/local/portage
Poté editujte konfigurační soubor /etc/make.conf
. Do proměnné PORTDIR_OVERLAY
je třeba zadat zvolený adresář. V případě, že máte více overlayí, oddělujte cesty mezerou – v cestě tedy nesmí být žádné mezery.
PORTDIR_OVERLAY="/usr/local/portage"
Nyní si v overlayi vytvořte adresář profiles
a do něj přidejte soubor repo_name
, který bude obsahovat název vaší nové overlaye. Název smí obsahovat pouze malá a velká písmena bez háčků a čárek, číslice, pomlčky a podtržítka.
cd /usr/local/portage mkdir profiles echo overlay-watzke-cz > profiles/repo_name
Struktura overlaye je stejná jako u hlavního stromu, s tím rozdílem, že v overlayi musí být jen opravdu nezbytné soubory a adresáře (správně umístěné ebuildy):
overlay |-- kategorie `-- program |-- Manifest |-- files | `-- program-1.2-link.patch `-- program-1.2-r5.ebuild
Kategorii pro program, který chcete přidat, si vyberte z profiles/categories
v hlavním stromu Portage (tj. obyčejně /usr/portage/
) nebo si můžete vymyslet vlastní a dopsat ji do /etc/portage/categories
, ale tomu bych se spíše vyhýbal (dost zbytečná komplikace).
Můžete si napsat vlastní eclass, což je shellový skript, který nastavuje pomocné proměnné a obsahuje často používané funkce pro danou činnost. Eclass patří do adresáře eclass
relativně k overlayi. Lze je poté načíst v ebuildu pomocí funkce inherit
(tj. něco jako shellový source
, vizte článek Gentoo ebuild - 2 (funkce, eclass a příkazy)).
Eclass v overlayi je ovšem třeba používat opatrně, protože Portage nejenže neaktualizuje cache, když se ebuild změní, ale neaktualizuje ji ani když se změní eclass z hlavního stromu, kterou vaše eclass načítá. Při práci s eclass v overlayi můžete také narazit na upozornění "illegal inherit", přestože jste neudělali chybu (a nenačítali eclass podmíněně). Pro jistotu můžete po úpravě eclass ručně spustit touch
na všechny relevantní soubory overlaye.
Pokud chcete v ebuildu patchovat, tak vězte, že patche patří do adresáře kategorie/program/files
. V ebuildu pak načtete eclass eutils
a patch aplikujete např. takto:
epatch "${FILESDIR}/${P}-link.patch"
Pokud provozujete veřejnou overlay a máte nějaký větší patch (v hlavním stromu je limit 20 kB) nebo rovnou sadu patchů, může být vhodné je zkomprimovat a uložit na vlastní mirror. Zkomprimované patche do overlaye nepatří.
Různé alpha, beta nebo rozbité verze je vhodné maskovat přidáním do souboru profiles/package.mask
(relativně k overlayi). Nezapomeňte tam specifikovat verzi, protože pokud je stejnojmenný balík i v hlavním stromu, zamaskovali byste jej také. Do souboru tedy přidáte například:
~kategorie/program-1.0_alpha2
Totéž je třeba přidat do /etc/portage/package.unmask
pro lokální odmaskování.
Live ebuildům je dobré nedávat žádný keyword (a nechat proměnnou prázdnou), protože nelze zaručit, že se poslední revize vůbec zkompiluje, natož pak že bez problémů poběží na určitých architekturách. Pro lokální odmaskování takového ebuildu je třeba přidat do /etc/portage/package.keywords
něco jako:
~kategorie/program-9999 **
Dříve se takovým ebuildům dával keyword -*
a odmaskovávaly se pomocí:
~kategorie/program-9999 -*
ale to už je minulost, takže to nepoužívejte.
Stabilním (od upstreamu) ale neotestovaným verzím je dobré dát ~arch
keywordy (pouze architektury, na kterých víte, že se software nainstaluje a funguje). V overlayi bych si s označováním ebuildů za stabilní ani moc nelámal hlavu,
Poznámka: operátor tilda (~) na začátku znamená, že pravidlo zahrnuje i revize, takže platí i pro verzi 9999-r1, atd.
Pokud chcete, můžete si u balíčků vést záznam o tom, jak a kdy se ebuildy měnily nebo kdy se objevily nové verze. Formát těchto záznamů si prohlédněte v hlavním stromu Portage - jde o soubory s názvem ChangeLog
(v adresáři s ebuildy). Vývojáři používají nástroj echangelog
, který podporuje repozitáře GIT, CVS a SVN. Nejprve změníte, přidáte a odeberete soubory pomocí utilit pro ovládání vašeho repozitáře, poté spustíte:
echangelog "zpráva do changelogu"
a pak změny odešlete na server.
Je tu hned několik věcí, na které je třeba dát si pozor. Většina z nich platí, především když provozujete veřejnou overlay, kterou používá více lidí.
Nejdůležitější je dávat pozor, abyste za žádných okolností nehlásili chyby, které produkují vaše nebo jiné ebuildy, které nejsou z hlavního stromu. V případě, že si nejste opravdu jisti, že jde o problém Portage, nic nehlaste, protože vývojáři pak nebývají moc nadšení.
Pokud máte v overlayi ebuild se stejnou kategorií, názvem i verzí, pak vězte, že má prioritu před tím z hlavního stromu. Je to dobrý způsob, jak si například dočasně opravit ebuild, který je v hlavním stromu poškozený nebo obsahuje chyby, než jej vývojáři opraví. Ovšem pak je třeba dávat pozor, aby vás to nezmátlo a vy jste nenahlásili chybu ebuildu mimo hlavní strom, jak je popsáno o odstavec výše.
Dávejte si pozor na kolizi názvů eclass. Když si do overlaye přidáte eclass se stejným názvem, jako je v hlavním stromu, starší verze Portage nic nenamítnou a použijí eclass z overlaye i pro balíčky z hlavního stromu, což může způsobit neplechu. Novější verze Portage si to hlídají a docela důrazně vás v takovém případě upozorní. Pokud opravdu víte, co děláte, varování lze zrušit přidáním PORTAGE_ECLASS_WARNING_ENABLE="0"
do /etc/make.conf
.
Pokud ebuild pouze neupravujete a soubory, které stahuje, tedy nejsou na Gentoo mirrorech, je dobré přidat RESTRICT="mirror"
, aby tam nebyly zbytečně hledány.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
profiles
v overlayi nejde a nikdy jsem neměl potřebu vymýšlet si kategorii Používáme Gentoo jako nosný systém pro naše systémy a naše balíčky máme v našich kategoriích a jejich maskování v overlay/profiles/package.mask (a naši licenci v overlay/licences/).Jasně, ale já mluvil o use.mask.
Jen se mi ještě nepodařilo, aby si portage při stahování naše zdrojové balíky ukládala do overlay/disfiles/V Paludisu se dá pro každé repo nastavit jiný distfiles adresář, v Portage ne.(pro méně se orientující - tohle byl vtípek)
Jasně, ale já mluvil o use.mask.
Jasně, já zase mluvil o dalších souborech / adresářích, které v overlay používáme. Třeba se to někomu bude hodit.
Taky máme v /etc/make.conf (vím, tohle už přímo s overlay nesouvisí):
USE_EXPAND="MOJE" MOJE="devel vlastnost"Umožňuje to mít vlastní USE přepínače pěkně přehledně. V tomto příkladě jsou nastaveny "moje_devel" a "moje_vlastnost". A stejně jako ve Vašem případě s use.mask, ani mne se nepovedlo zařídit nastavení USE_EXPAND="MOJE" nekde v overlay.