Byla vydána nová major verze 7.0 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Nově je postavena je na Debianu 13 (Trixie) a GNOME 48 (Bengaluru). Další novinky v příslušném seznamu.
Společnost Meta na dvoudenní konferenci Meta Connect 2025 představuje své novinky. První den byly představeny nové AI brýle: Ray-Ban Meta (Gen 2), sportovní Oakley Meta Vanguard a především Meta Ray-Ban Display s integrovaným displejem a EMG náramkem pro ovládání.
Po půl roce vývoje od vydání verze 48 bylo vydáno GNOME 49 s kódovým názvem Brescia (Mastodon). S přehrávačem videí Showtime místo Totemu a prohlížečem dokumentů Papers místo Evince. Podrobný přehled novinek i s náhledy v poznámkách k vydání a v novinkách pro vývojáře.
Open source softwarový stack ROCm (Wikipedie) pro vývoj AI a HPC na GPU od AMD byl vydán ve verzi 7.0.0. Přidána byla podpora AMD Instinct MI355X a MI350X.
Byla vydána nová verze 258 správce systému a služeb systemd (GitHub).
Byla vydána Java 25 / JDK 25. Nových vlastností (JEP - JDK Enhancement Proposal) je 18. Jedná se o LTS verzi.
Věra Pohlová před 26 lety: „Tyhle aféry každého jenom otravují. Já bych všechny ty internety a počítače zakázala“. Jde o odpověď na anketní otázku deníku Metro vydaného 17. září 1999 na téma zneužití údajů o sporožirových účtech klientů České spořitelny.
Byla publikována Výroční zpráva Blender Foundation za rok 2024 (pdf).
Byl vydán Mozilla Firefox 143.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Nově se Firefox při ukončování anonymního režimu zeptá, zda chcete smazat stažené soubory. Dialog pro povolení přístupu ke kameře zobrazuje náhled. Obzvláště užitečné při přepínání mezi více kamerami. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 143 bude brzy k dispozici také na Flathubu a Snapcraftu.
Byla vydána betaverze Fedora Linuxu 43 (ChangeSet), tj. poslední zastávka před vydáním finální verze, která je naplánována na úterý 21. října.
Ne všechny programy bohužel pracují na všech operačních systémech a architekturách. A některé jsou natolik speciální, že to od nich ani nikdo nečeká. Spec soubor proto může deklarovat, pro které architektury, případně i pro které operační systémy, lze balíček zkompilovat.
Architekturu, na níž lze balíček zkompilovat, deklaruje položka BuildArch
hlavičky (kdo rád píše dlouhé názvy, může použít i synonymum BuildArchitectures
)
BuildArch: i386 i586 i686 ppc64 alphaev67
Při kompilaci se pak rpmbuild
pokusí najít shodu mezi hodnotami
v BuildArch
a architekturou, na níž kompilujeme. Nepodaří-li se mu najít vůbec žádnou kompatibilní, kompilace selže.
První nalezená přípustná hodnota v BuildArch
pak určuje koncovku rpm, tj. ono i386
v lobster-1.10-1.i386.rpm
. Jenže pro jaký procesor se balíček opravdu kompiluje, to určuje volba --target
. To moc nedává smysl, že? Položka BuildArch
se tak v praxi používá k jedinému účelu:
BuildArch: noarch
označuje balíčky obsahující jen data či skripty nezávislé na platformě. Ty pak dostanou
koncovku noarch
.
Procesory a systémy, pro něž je možno balíček zkompilovat, deklarujeme následujícími položkami hlavičky:
ExclusiveArch
ExclusiveOS
ExcludeArch
ExcludeOS
Deklaruje-li spec soubor
ExclusiveArch: i686 pentium4 athlon x86_64
a naše implicitní architektura je i386
, balíček nezkompilujeme – musíme použít --target i686
. Tím se drasticky odstraňuje neshoda mezi deklarovanou architekturou a realitou.
Na Intelu se nám často bude hodit standardní makro %{ix86}
, které expanduje na seznam všech možných IA32 procesorů.
--target
a makro %configure
Volba --target
určuje cílovou platformu. To také znamená koncovku balíčku – neobsahuje-li tedy spec soubor položku BuildArch
, která má vyšší prioritu. Zejména však definuje hodnoty maker %_target
, %_target_cpu
a %_target_os
; dále hodnotu makra %optflags
a proměnné RPM_OPT_FLAGS
obsahujících volby kompilátoru vhodné pro daný procesor (odkud se berou, to uvidíme níže), a tím i chování standardního makra %configure
, jež tyto proměnné využívá a nastavuje podle nich CFLAGS
, CXXFLAGS
a FFLAGS
, které už opravdu ovlivňují vlastní kompilaci.
Balíme-li program, který nemá configure
, nebo nepoužíváme makro
%configure
, a chceme, aby na jeho kompilaci měl --target
vliv, musíme do CFLAGS
(případně dalších proměnných) přiřadit či přidat hodnotu
RPM_OPT_FLAGS
sami
export CFLAGS="$RPM_OPT_FLAGS"
Argument volby --target
je obecně tzv. kanonický triplet
procesor-vendor-operační_systém
, např.
i686-pc-linux-gnu
. Nebo i nekanonický; v označení platforem je pěkný guláš a rpmbuild
si dokáže přebrat ledasco. Zejména mu můžeme napsat jen procesor, a zbytek si doplní podle operačního systému, na němž běží. Toho jsme ostatně už využili výše.
Navzdory všem složitostem tak nakonec --target
obyčejně používáme jednoduše.
Chceme-li zkompilovat balíček pro svou distribuci, který pojede jen na procesoru i686 (a vyšších) a bude pro něj optimalizován, spustíme:
rpmbuild -bb --target i686 lobster.spec
Povolování a zakazování platforem položkami ExclusiveArch
je dosti hrubé. Programy často lze zprovoznit na různých architekturách a operačních systémech, ovšem za cenu úprav a nastavení – pro každou platformu samozřejmě jiných. Spec soubory proto lze větvit podle architektury a/nebo operačního systému. Máme k disposici podmínky:
%ifarch
, %ifnarch
%ifos
, %ifnos
Syntaxe podmínek velmi připomíná preprocesor C, vypadá totiž:
%iftyp_testu seznam_hodnot … %else … %endif
přičemž část s %else
je nepovinná. Rovná-li se cílová architektura (resp. systém) kterékoli hodnotě ze seznamu, je podmínka splněna (v případě negativní podmínky se výsledek pak přirozeně ještě zneguje).
Aplikovat patch číslo 3 jen na sparc64 a ppc64 tak můžeme:
%ifarch sparc64 ppc64 %patch3 -p1 -b .multilib-hack %endif
rpmrc
Některé informace o platformách jsou zadrátovány přímo do rpm
; další jsou jsou v souboru rpmrc
. Obsahuje několik tabulek (či zobrazení) ve formě řádků:
název_tabulky: platforma: hodnota
Platforma je označení procesoru nebo operačního systému. Názvy tabulek jsou utvořeny ze dvou částí oddělených volitelným podtržítkem. První část je arch
, os
, buildarch
nebo buildos
. Druhá část je typ tabulky: canon
– kanonické jméno, compat
– co je s čím kompatibilní, nebo translate
– převod na implicitní kompatibilní platformu. Ne všechny kombinace dávají smysl, jen některé se
používají, a ještě méně jich budeme někdy chtít měnit. Několik relativně zajímavých příkladů:
buildarch_translate
Zobrazení z architektury, na níž kompilujeme, na architekturu, pro niž kompilujeme. Standardní nastavení pro všechny IA32 procesory je
buildarchtranslate: cokoli: i386
tj. ať kompilujeme na čemkoli, kompiluje se pro i386. Má-li se na i686 implicitně kompilovat pro i686, změníme definici na
buildarchtranslate: i686: i686
arch_compat
Deklarace kompatibilních architektur. Řádek
arch_compat: athlon: i686
říká, že balíčky pro i686 jsou kompatibilní s athlonem. Kompatibilita je transitivní, tudíž například pro intelí procesory stačí deklarovat kompatibilitu s nejbližším nižším, a na konci pak
arch_compat: i386: noarch
zajišťuje, že noarch
balíčky lze instalovat na kterýkoli (intelí)
procesor.
arch_canon
Převod na kanonický název (sub)architektury, hodnota je kanonický název a číslo architektury. Nejspíš nikdy nebudeme potřebovat měnit. Příklad:
arch_canon: sun4c: sparc 3
To ale není vše, co v rpmrc
můžeme najít (nebo změnit). Kromě tabulek se v něm nastavuje několik proměnných. Řádky nastavující proměnné mají tvar:
proměnná: hodnota
přičemž proměnné existují tyto:
optflags
Asi nejzajímavější proměnná, definuje vhodné volby kompilátoru pro daný procesor. Právě tato hodnota se při kompilaci objeví v %optflags
a RPM_OPT_FLAGS
. První slovo v hodnotě je procesor, pro nějž volby překladače nastavujeme. Implicitní nastavení optflags
pro ppc64 tak kupříkladu vypadá:
optflags: ppc64 -O2 -g -fsigned-char
macrofiles
Soubory, z nichž mají rpm
a rpmbuild
načíst při spuštění makra (v uvedeném pořadí), oddělené dvojtečkami, jak je v Unixu zvykem. Standardní hodnota je docela dlouhá a najdete si ji v rpmrc
, za zmínku však stojí, že začíná
/usr/lib/rpm/macros:/usr/lib/rpm/%{_target}/macros:…
Po implicitním souboru s makry se tedy načte např. /usr/lib/rpm/i686-redhat-linux
, existuje-li a kompilujeme-li na i686 RedHatu, a může změnit definice maker pro tuto konkrétní cílovou platformu.
include
Nic nedefinuje, ale vloží soubor, který je jeho hodnotou.
provides
Netuším, co dělá, ani jsem ji nikdy neviděl.
Soubor rpmrc
tedy určuje, kde se hledají soubory s makry, ale kde se hledá rpmrc
sám? Buď v adresářích, které dáme jako argument rpm --rcfile
, nebo v implicitním seznamu adresářů, který je zakompilován do rpm
a typicky vypadá:
/usr/lib/rpm/rpmrc:/usr/lib/rpm/redhat/rpmrc:/etc/rpmrc:~/.rpmrc
Nejvíce nás zajímá ~/.rpmrc
, který si můžeme vytvořit v domovském adresáři a má nejvyšší prioritu. Do souboru /etc/rpmrc
bychom případně psali společnou konfiguraci. Do /usr/lib/rpm/rpmrc
nepíšeme nic, protože obsahuje implicitní hodnoty a nejbližší aktualizace RPM by nám jej přepsala.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej: