Microsoft představil nové označení počítačů Copilot+. Dle oznámení se jedná se o počítače poskytující funkce umělé inteligence. Vedle CPU a GPU mají také NPU (Neural Processing Unit). Uvnitř představených Copilot+ notebooků běží ARM čipy Qualcomm Snapdragon X Elite nebo X Plus.
Příspěvek na blogu Codean Labs rozebírá zranitelnost CVE-2024-4367 v PDF.js, tj. mj. prohlížeči PDF souborů ve Firefoxu. Při otevření útočníkem připraveného pdf souboru může být spuštěn libovolný kód v JavaScriptu. Vyřešeno ve Firefoxu 126.
Lazygit byl vydán ve verzi 0.42.0. Jedná se o TUI (Text User Interface) nadstavbu nad gitem.
K open source herní konzole Picopad přibyla (𝕏) vylepšená verze Picopad Pro s větším displejem, lepšími tlačítky a větší baterii. Na YouTube lze zhlédnout přednášku Picopad - open source herní konzole z LinuxDays 2023.
Byla vydána (𝕏) nová major verze 17 softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech GitLab (Wikipedie). Představení nových vlastností i s náhledy a videi v oficiálním oznámení.
Sovereign Tech Fund, tj. program financování otevřeného softwaru německým ministerstvem hospodářství a ochrany klimatu, podpoří vývoj FFmpeg částkou 157 580 eur. V listopadu loňského roku podpořil GNOME částkou 1 milion eur.
24. září 2024 budou zveřejněny zdrojové kódy přehrávače Winamp.
Google Chrome 125 byl prohlášen za stabilní. Nejnovější stabilní verze 125.0.6422.60 přináší řadu oprav a vylepšení (YouTube). Podrobný přehled v poznámkách k vydání. Opraveno bylo 9 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Textový editor Neovim byl vydán ve verzi 0.10 (𝕏). Přehled novinek v příspěvku na blogu a v poznámkách k vydání.
Byla vydána nová verze 6.3 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.15.
Podstatná část funkcí RPM se ukrývá v makrech. Jeho chování lze proto překonfigurovat do té míry, že téměř nic z toho, co napsal v minulých dílech, nebude pravda. To zde ale demonstrovat nebudu a zaměřím se na jednoduché změny standardních maker, které mi připadají užitečné a/nebo zajímavé.
Konfigurační makra týkající se GnuPG/PGP jsem již podrobně popsal v sekci o podepisování, proto je znovu rozebírat nebudu.
%_topdir
%{_usrsrc}/redhat
, ale všichni kromě RedHatu ji předefinovávají. Už jsme se s ním
seznámili v úvodní části.%_builddir
, %_rpmdir
, %_sourcedir
,
%_specdir
, %_srcrpmdir
%{_topdir}/BUILD
, %{_topdir}/RPMS
,
%{_topdir}/SOURCES
, %{_topdir}/SPECS
a %{_topdir}/SRPMS
.
Chceme-li zcela oddělit kompilace jednotlivých balíčků, definujeme buď %_topdir
, nebo
tyto jednotlivé adresáře, aby jejich názvy obsahovaly %name
, %version
a %release
. Musíme pak ale zajistit, aby existovaly, když je jich třeba – nejspíš wrapperem kolem rpmbuild
u.%_tmppath
%_dbpath
%{_var}/lib/rpm
; volba
--dbpath
je ve skutečnosti jen alias popt, jenž nastavuje toto makro.%buildroot
%install
. Obvykle jej definujeme ve spec
souboru, ovšem pozor, hodnota v souboru s makry má v tomto případě přednost před hodnotou ze spec souboru. I kdyby tak nastavoval %buildroot
na /
, máme možnost přepsat ji rozumnou hodnotou.%_defaultdocdir
%_docdir
,
nepředefinuje-li ho balíček. Hodnotu %{_usr}/doc
z RPM distribuce obvykle
předefinovávají na %{_usr}/share/doc
.%_prefix
, %_bindir
, %_sbindir
,
%_mandir
, …configure
a make
standardními makry
%configure
a %makeinstall
.%_repackage_dir
--repackage
. Implicitní hodnota
je /var/spool/repackage
.%_unpackaged_files_terminate_build
%buildroot
, ale
nezabalené do žádného balíčku. Implicitní hodnota je už delší dobu 1
. K zabalení hodně starých nebo rozbitých balíčků (např. těch od checkinstallu) může být nutné tuto kontrolu vypnout.%_missing_doc_files_terminate_build
%doc
, jež však neexistují.
Implicitní hodnota je už delší dobu 1
.%_use_internal_dependency_generator
rpmbuild
u namísto
změti skriptů, jež se používala dříve. Implicitní hodnota je 1
.%_repackage_all_erasures
--repackage
. Implicitní hodnota je 0
.%_build_name_fmt
%%{ARCH}/%%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm
(hodnota se nejprve expanduje
jako makro a následně teprve používá jako formát, proto jsou procenta zdvojená). Nechceme-li
kupříkladu třídit balíčky do podadresářů podle architektury, odstraníme počáteční
%%{ARCH}/
.%_query_all_fmt
rpm -q
, tj. argument --qf
. V hodnotě %%{name}-%%{version}-%%{release}
jsou opět zdvojená procenta kvůli dvojímu formátování. Chceme-li zde například přidat informaci o architektuře, připojíme na konec .%%{arch}
.Za našimi zády se děje při balení rpm docela dost věcí. Liší se mírně distribuci od distribuce (budu-li dále uvádět konkrétní definice maker, budou implicitní, resp. redhatí), ale patří mezi ně kupříkladu:
strip
nutí programů a/nebo knihoven, umožuje-li to platforma,-debuginfo
balíčků,Jak se jim daří vetřít se do našeho precizně specifikovaného postupu balení? Obsah sekce
%build
či %install
zjevně není vše, co rpmbuild
v dané fázi spouští. Už ostatně víme, že ve skriptu /var/tmp/rpm-tmp.6502
, který ji realizuje,
najdeme kromě vlastního obsahu odpovídající sekce spec souboru třeba nastavení proměnných
prostředí, jež jsme rozhodně nikam nepsali.
Skripty nejsou do rpmbuild
u zadrátovány, ale každou fázi skládá ze tří maker:
%__spec_fáze_cmd
(příkaz), %__spec_fáze_template
(vzor) a %__spec_fáze_post
(dodatečné příkazy). Zatím to takto funguje pro fáze balení, ale v budoucnu by měly být podobně konstruovány i další pomocné skripty.
Například pro instalační fázi, %install
, vytvoří rpmbuild
skript,
který obsahuje expansi:
%{__spec_install_template} cd lobster-1.10 obsah sekce %install %{__spec_install_post}
a tento skript dá jako argument příkazu %__spec_install_cmd
. Řádek
s cd
se přitom nevkládá při %prep
, kdy adresář ještě nemůže existovat, a při --clean
, kdy se namísto toho vloží jeho smazání.
Makro %__spec_install_cmd
se v případě, že nejsou nakonfigurovány žádné chrooty, sudo a vzdálené shelly (viz kompletní definici v macros
), redukuje na
%{___build_shell} %{___build_args}
přičemž shell je obyčejně /bin/sh
a argumenty -e
, aby vykonávání
skriptu skončilo při první chybě. Vzory %__spec_fáze_template
vypadají
všechny stejně, např. pro instalaci:
#!%{__spec_install_shell}\ %{__spec_install_pre}\ %{nil}
První řádek dá #!/bin/sh
. Přípravné makro %__spec_install_pre
pak
obsahuje všechna ta nastavení proměnných prostředí a přechod do adresáře BUILD
.
Přesněji je tedy obsahuje makro %___build_pre
, které je jediným obsahem všech
přípravných maker.
Zajímavé věci se ovšem dějí v %__spec_install_post
.
Většina maker %__spec_fáze_post
maker s dodatečnými příkazy implicitně obsahuje jen %___build_post
, což je exit 0
. Tedy nic zvláštního. Ne tak %__spec_install_post
, jehož tělo vypadá:
%{?__debug_package:%{__debug_install_post}}\ %{__arch_install_post}\ %{__os_install_post}\ %{nil}
Provede se tedy extrakce ladících informací, je-li definováno %__debug_package
;
a pak makra specifická pro danou architekturu a daný operační systém. A ta právě expandují na různé dodatečné úkony. Kupříkladu na RedHatu má %__os_install_post
hodnotu
/usr/lib/rpm/brp-compress \ /usr/lib/rpm/brp-strip \ /usr/lib/rpm/brp-strip-static-archive \ /usr/lib/rpm/brp-strip-comment-note \ %{nil}
kdežto na Mandrivě je to jen
/usr/lib/rpm/brp-mandrake \ %{nil}
a brp-mandrake
(časem snad brp-mandriva
) spouští jednotlivé
podskripty. Všechny skripty se z nějakého mystického důvodu jmenují
brp-něco
.
Činnost většiny dodatečných skriptů je dána konvencemi distribuce a nelze ji kontrolovat
(nepočítám-li samozřejmě předefinování %__os_install_post
na něco úplně jiného).
Extrakci ladících informací a vytvoření -debuginfo
balíčku můžeme zakázat
likvidací makra %debug_package
, např.
%debug_package %nil
v souboru ~/.rpmmacros
.
Probrali jsme téměř všechny aspekty balení rpm, tak ještě několik dobrých rad do života:
rpmbuild
u ručně upravený zdrojový kód. Cokoli lze zkompilovat
a nainstalovat ručně, lze zautomatizovat do spec souboru.cp -p
, install -p
, wget -N
, curl -R
, …BuildRequires
. Je několik balíčků, jejichž existenci implikuje
přítomnost rpm-build
samého. Všechno ostatní potřebné ke kompilaci má být
v BuildRequires
.Nástroje: Tisk bez diskuse
Tiskni Sdílej: