Společnost Pebble představila (YouTube) prsten s tlačítkem a mikrofonem Pebble Index 01 pro rychlé nahrávání hlasových poznámek. Prsten lze předobjednat za 75 dolarů.
Společnost JetBrains v listopadu 2021 představila nové IDE s názvem Fleet. Tento týden oznámila jeho konec. Od 22. prosince 2025 již nebude možné Fleet stáhnout.
Byl vydán Mozilla Firefox 146.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 146 bude brzy k dispozici také na Flathubu a Snapcraftu.
Před rokem převzala Digitální a informační agentura (DIA) vlastnictví a provoz jednotné státní domény gov.cz. Nyní spustila samoobslužný portál, který umožňuje orgánům veřejné moci snadno registrovat nové domény státní správy pod doménu gov.cz nebo spravovat ty stávající. Proces nové registrace, který dříve trval 30 dní, se nyní zkrátil na několik minut.
IBM kupuje za 11 miliard USD (229,1 miliardy Kč) firmu Confluent zabývající se datovou infrastrukturou. Posílí tak svoji nabídku cloudových služeb a využije růstu poptávky po těchto službách, který je poháněný umělou inteligencí.
Nejvyšší správní soud (NSS) podruhé zrušil pokutu za únik zákaznických údajů z e-shopu Mall.cz. Incidentem se musí znovu zabývat Úřad pro ochranu osobních údajů (ÚOOÚ). Samotný únik ještě neznamená, že správce dat porušil svou povinnost zajistit jejich bezpečnost, plyne z rozsudku dočasně zpřístupněného na úřední desce. Úřad musí vždy posoudit, zda byla přijatá opatření přiměřená povaze rizik, stavu techniky a nákladům.
Organizace Free Software Foundation Europe (FSFE) zrušila svůj účet na 𝕏 (Twitter) s odůvodněním: "To, co mělo být původně místem pro dialog a výměnu informací, se proměnilo v centralizovanou arénu nepřátelství, dezinformací a ziskem motivovaného řízení, což je daleko od ideálů svobody, za nimiž stojíme". FSFE je aktivní na Mastodonu.
Paramount nabízí za celý Warner Bros. Discovery 30 USD na akcii, tj. celkově o 18 miliard USD více než nabízí Netflix. V hotovosti.
Nájemný botnet Aisuru prolomil další "rekord". DDoS útok na Cloudflare dosáhl 29,7 Tbps. Aisuru je tvořený až čtyřmi miliony kompromitovaných zařízení.
Iced, tj. multiplatformní GUI knihovna pro Rust, byla vydána ve verzi 0.14.0.
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:
ExclusiveArchExclusiveOSExcludeArchExcludeOSDeklaruje-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 %configureVolba --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, %ifnosSyntaxe 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
rpmrcNě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_translateZobrazení 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_compatDeklarace 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_canonPř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:
optflagsAsi 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
macrofilesSoubory, 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.
includeNic nedefinuje, ale vloží soubor, který je jeho hodnotou.
providesNetuší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: