Po Canonicalu a SUSE oznámil také Red Hat, že bude podporovat a distribuovat toolkit NVIDIA CUDA (Wikipedie).
TrueNAS (Wikipedie), tj. open source storage platforma postavená na Linuxu, byl vydán ve verzi 25.10 Goldeye. Přináší NVMe over Fabric (NVMe-oF) nebo OpenZFS 2.3.4.
Byla vydána OpenIndiana 2025.10. Unixový operační systém OpenIndiana (Wikipedie) vychází z OpenSolarisu (Wikipedie).
České základní a střední školy čelí alarmujícímu stavu kybernetické bezpečnosti. Až 89 % identifikovaných zranitelností v IT infrastruktuře vzdělávacích institucí dosahuje kritické úrovně, což znamená, že útočníci mohou vzdáleně převzít kontrolu nad klíčovými systémy. Školy navíc často provozují zastaralé technologie, i roky nechávají zařízení bez potřebných aktualizací softwaru a používají k nim pouze výchozí, všeobecně známá
… více »Během tradiční ceremonie k oslavě Dne vzniku samostatného československého státu (28. října) byl vyznamenán medailí Za zásluhy (o stát v oblasti hospodářské) vývojář 3D tiskáren Josef Průša. Letos byly uděleny pouze dvě medaile Za zásluhy o stát v oblasti hospodářské, druhou dostal informatik a manažer Ondřej Felix, který se zabývá digitalizací státní správy.
Tor Browser, tj. fork webového prohlížeče Mozilla Firefox s integrovaným klientem sítě Tor přednastavený tak, aby přes tuto síť bezpečně komunikoval, byl vydán ve verzi 15.0. Postaven je na Firefoxu ESR 140.
Bylo oznámeno (cs) vydání Fedora Linuxu 43. Ve finální verzi vychází šest oficiálních edic: Fedora Workstation a Fedora KDE Plasma Desktop pro desktopové, Fedora Server pro serverové, Fedora IoT pro internet věcí, Fedora Cloud pro cloudové nasazení a Fedora CoreOS pro ty, kteří preferují neměnné systémy. Vedle nich jsou k dispozici také další atomické desktopy, spiny a laby. Podrobný přehled novinek v samostatných článcích na stránkách Fedora Magazinu: Fedora Workstation, Fedora KDE Plasma Desktop, Fedora Silverblue a Fedora Atomic Desktops.
Elon Musk oznámil (𝕏) spuštění internetové encyklopedie Grokipedia (Wikipedia). Zatím ve verzi 0.1. Verze 1.0 prý bude 10x lepší, ale i ve verzi 0.1 je podle Elona Muska již lepší než Wikipedia.
PSF (Python Software Foundation) po mnoha měsících práce získala grant ve výši 1,5 milionu dolarů od americké vládní NSF (National Science Foundation) v rámci programu "Bezpečnost, ochrana a soukromí open source ekosystémů" na zvýšení bezpečnosti Pythonu a PyPI. PSF ale nesouhlasí s předloženou podmínkou grantu, že během trvání finanční podpory nebude žádným způsobem podporovat diverzitu, rovnost a inkluzi (DEI). PSF má diverzitu přímo ve svém poslání (Mission) a proto grant odmítla.
Balík nástrojů Rust Coreutils / uutils coreutils, tj. nástrojů z GNU Coreutils napsaných v programovacím jazyce Rust, byl vydán ve verzi 0.3.0. Z 634 testů kompatibility Rust Coreutils s GNU Coreutils bylo úspěšných 532, tj. 83,91 %. V Ubuntu 25.10 se již používá Rust Coreutils místo GNU Coreutils, což může přinášet problémy, viz například nefunkční automatická aktualizace.
Portage má USE flagy, RPM má zase makra, a tak si můžeme USE flagy implementovat sami. Není k tomu zapotřebí žádná zvláštní podpora ze strany rpmbuildu. Mechanismus, jenž nyní popíši, se zatím nepoužívá ani příliš široce ani obzvlášť systematicky, avšak existuje.
Nejrpve určíme makro, řekněme %with_sandals, které má řídit kompilaci podpory
libsandals do balíčků. Pak upravíme spec soubory, aby se do programů zakompilovala podpora
libsandals, má-li %with_sandals hodnotu 1, a nezakompilovala, má-li hodnotu 0. To mimo jiné obnáší úpravu BuildRequires
%if %with_sandals BuildRequires: libsandals-devel %endif
předání správných parametrů configure
%configure \ %if %with_sandals --with-sandals \ %else --without-sandals \ %endif
a podobné úpravy Provides či v sekci %files. Častý obrat je též vytvoření vedlejšího balíčku, jenž je celý podmíněný:
%if %with_sandals %package sandals Summary: Supplementary sandals for lobster … %description sandals … %endif
Další postup záleží na poměru naší lenosti a megalomanie.
V nejjednodušším případě přidáme na začátek spec souboru
# Define to 1 to enable sandals %define with_sandals 0
a s pocitem dobře vykonané práce se půjdeme věnovat nečemu jinému, například odpočinku. Podobných spec souborů můžeme potkat spousty.
Kdo bude ovšem chtít takové zdrojové rpm překompilovat s jinou hodnotou
%with_sandals, musí upravit spec soubor. To není právě praktické. Změníme proto
alespoň definiční řádek na potlačitelnou implicitní hodnotu:
%{!?with_sandals:%define with_sandals 0}
Nyní už může uživatel zapnout podporu sandálů jak jednorázově při kompilaci:
rpmbuild --define 'with_sandals 1' -bb lobster.spec
tak trvale definicí v ~/.rpmmacros:
%with_sandals 1
Novější verze RPM, tj. alespoň 4.4, přímo podporují volby --with sandals
a --without sandals, jež definují makra %_with_sandals, resp. %_without_sansals, a můžeme tak jednoduše spouštět
rpmbuild --with sandals -bb lobster.spec
Ve skutečnosti tedy RPM nic přímo nepodporuje, uvedené dvě volby jsou jen aliasy popt pro
--define, definované v /usr/lib/rpm/rpmpopt-verze, které si můžeme do staršího rpm případně doplnit sami (nebudeme ovšem měnit tento soubor, ale doplníme je do /etc/popt).
Stále však cosi schází – volba --with sandals vytvoří makro
%_with_sandals, kdežto my bychom rádi %with_sandals. A také musíme zpracovat negativní argument --without sandals. Tedy nemusíme, protože implicitní je kompilace bez sandálů, a tak můžeme v tomto případě --without sandals klidně ignorovat, ale potřebovali bychom ji zpracovat, kdyby se implicitně sandály zakompilovávaly.
Chybějící dílek skládačky doplňují standardní makra %bcond_with
a %bcond_without:
%define bcond_with() %{expand:%%{?_with_%{1}:%%global with_%{1} 1}}
%define bcond_without() %{expand:%%{!?_without_%{1}:%%global with_%{1} 1}}
Porozumění definicím si necháme na dlouhé zimní večery a zaměříme se na praktické použití. Volitelnou součást balíku deklarujeme jedním z následujících způsobů:
%bcond_with sandals %bcond_without sandals
První přitom použijeme, má-li --with sandals zapínat implicitně vypnutou podporu sandálů; druhou pak, má-li --without sandals vypínat implicitně zapnutou podporu. V obou případech se pak řídíme existencí makra %with_sandals. Abychom to měli ještě jednodušší, byla zavedena makra %with a %without (vidíme, že to jsou jen specializované varianty %defined a %undefined)
%define with() %{expand:%%{?with_%{1}:1}%%{!?with_%{1}:0}}
%define without() %{expand:%%{?with_%{1}:0}%%{!?with_%{1}:1}}
s nimiž můžeme psát čitelné podmínky
%if %{with sandals}
…
%endif
Jsme-li osamělí baliči, na další stupínek megalomanie už nedosáhneme. Tvoříme-li však
distribuci, můžeme se pokusit udělat ve with_… makrech pořádek, aby každý balíček nepoužíval, jaká jeho autora zrovna napadla, zdokumentovat je a definovat standardní formu, jak a kam se do spec souboru píší, abychom usnadnili zjišťování, která daný spec soubor podporuje (od rpm lze stěží očekávat, že je dokáže vypsat, když o žádných %with_… nemátušení).
Přemístitelné (relocatable) balíčky mohou být nainstalovány do jiného než implicitního adresáře (obvykle /usr) pomocí volby --prefix, případně podrobněji
--relocate starý_adresář=nový_adresář. Kupříkladu
rpm -ivh --prefix /opt/lobster lobster-1.10-1.i386.rpm
nainstaluje lobster do /opt/lobster namísto do /usr.
Postavíme-li si hlavu, můžeme, pravda, nainstalovat cokoli kamkoli s volbou
--badreloc, ale následky padají na naši hlavu. Balíčky, jež přemístitelnost samy
deklarují, by měly po instalaci do jiného adresáře i fungovat.
Přemístitelný balíček vyrobíme přidáním položky Prefix do hlavičky. Ta jednak
deklaruje, že se všechny soubory instalují do tohoto adresáře – to rpmbuild kontroluje a obsahuje-li balíček soubory i v jiných adresářích, kompilace selže. A jednak určuje, který adresář bude nahrazen hodnotou z --prefix při případném přemístění. Typická deklarace vypadá
Prefix: %{_prefix}
Instaluje-li se rpm i do dalších adresářů, např. /etc, ale je přitom přemístitelné (to není právě obvyklá situace), můžeme uvést několik hlaviček Prefix, pro každý adresář jednu, a při přemisťování si pak už nejspíš nevystačíme s --prefix a musíme použít --relocate. Ve starších verzích pro to existovala položka Prefixes, dnes je ale synonymní s Prefix.
Zda nějaký program je či není možné po kompilaci pro určitý prefix přemístit, samozřejmě závisí na tom, jak hledá své komponenty a jak ho využívají další programy. Není-li přemístitelný sám od sebe, položka Prefix to sama magicky nezařídí, proto se při jejím přidávání musíme zamyslet, bude-li program po přemístění opravdu fungovat.
Metadata balíčku lze lokalizovat, takže se pak uživateli např. při rpm -qi vypíší informace v jeho rodném jazyce. Smysluplnost tohoto kroku je zapotřebí zvážit. Jednak mají lokalizované informace tendenci rozcházet se s originálem, za druhé je kupříkladu celý zbytek výstupu rpm -qi prakticky nelokalizovatelný, neboť je to alias popt pro rpm -q --qf=… se správným formátem – frontendy k RPM toto omezení, pravda, mít nemusejí.
Položky hlavičky lokalizujeme přidáním jména jazyka do závorky za její název:
Summary: A poor human doctor emulator Summary(cs): Ubohá napodobenina lidského lékaře
Lokalizovat lze tyto položky hlavičky: Summary, Group,
Requires, PreReq, BuildPrereq, BuildRequires. Skupinu je ovšem nesmysl překládat ve spec souboru každého balíčku znovu (a nejlépe pokaždé jinak), a k čemu má sloužit lokalizace závislostí, netuším (balíček vyžaduje sjednocení množin závislostí uvedených pro všechny jazyky). Zbývá tedy stejně jen Summary.
Jediná další věc, již lze přeložit, je sekce %description. Název locale pak
uvádíme volbou -l:
%description -l cs …
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
).
Ja spise resim jiny problem, evidentne az novejsimu RPM systemu vadi, ze po instalaci do chrootu zustanou nejake polozky, ktere nemaji zadny obraz ve files sekcich... (a tedy nebudou do RPMkem zahrnuty). Novejsi RPM system na to upozornuje a odmita dokoncit vytvoreni RPMek, je nejaky zpusob, jak zabranit fatalnimu ukonceni? (vesmes se jedna o cosi, co sice via make install je nainstalovano, ale nikdo to nechce a tak pred %clean mi nezbyva nic jineho nez rm -f $RPM_BUILD_ROOT/soubor(y)...)
Tahle vlastnost me taky pekne nastvala, zvlast kdyz to bylo po kompilaci KOffice :) Nechapu, kdo na to prisel? Warning by uplne stacil, ale ukoncit vyrobu balicku? ufff...
Nicmene nastesti vse resi makro %_unpackaged_files_terminate_build 0
viz http://www.rpm.org/hintskinks/unpackaged/
).
..no to ste mě teda nepotěšil, právě mi spadlo vytváření vlastního balíčku OpenOffice
V samém závěru na jedné chybičce %files
Po 20ti hodinach buildovani!
Tak dám rpmbuild -bi --short-circuit a pořád hledám ty balíčky...