Americká technologická společnost Meta Platforms se dohodla, že zaplatí až zhruba 18 miliard dolarů (asi 373 miliard Kč) za mimosoudní urovnání sporu o závislosti dětí na sociálních sítích a provede významné změny pro jejich používání mladistvými. Téměř tři desítky států USA firmu v roce 2023 obvinily z toho, že sítě Facebook a Instagram vědomě navrhla tak, aby u dětí vyvolávaly závislost, a zatajovala tyto dopady před veřejností. Firma se
… více »Byl publikován aktuální přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Blíží se vydání podporující čipy M3. Vývojáře lze podpořit na GitHub Sponsors a Open Collective.
Kancelářský balík LibreOffice byl vydán ve verzi 26.8. Mimo jiné vylepšuje typografii a kompatibilitu s formáty MS Office, více v poznámkách k vydání.
Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu optimalizovaná pro jednodeskové počítače na platformě ARM a RISC-V, ke stažení ale také pro Intel a AMD, byl vydán ve verzi 26.8. Přehled novinek v poznámkách k vydání.
Byla vydána nová verze 23.1.0, tj. první stabilní verze z nové řady 23.1.x, překladačové infrastruktury LLVM (Wikipedie). Přehled novinek v poznámkách k vydání: LLVM, Clang, LLD, Extra Clang Tools, Libc++, Polly a Flang.
Google Chrome 152 byl prohlášen za stabilní. Nejnovější stabilní verze 152.0.7977.64 přináší řadu novinek. Podrobný přehled v poznámkách k vydání. Opraveno bylo 327 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Před 35 lety, 25. srpna 1991, oznámil Linus Benedict Torvalds v diskusní skupině comp.os.minix, že vyvíjí (svobodný) operační systém (jako koníček, nebude tak velký a profesionální jako GNU) pro klony 386 (486), že začal v dubnu a během několika měsíců by mohl mít něco použitelného.
Apple představil čipy M6 a M5 Ultra, Mac mini s M6 nebo M5 Pro a Mac Studio s M5 Max nebo M5 Ultra. Fedora Asahi Remix zatím podporuje jenom M1 a M2.
Firefox 157 přinese zapnutou podporu rastrového grafického formátu JPEG XL. Založena je na v Rustu napsané implementaci jxl-rs používané i v Chrome a Chromiu.
Vanilla OS 3 „Reunion“ byl vydán. Tato na Debianu „Sid“ založená desktopová distribuce s transakčními aktualizacemi „neměnného“ základního systému (ABRoot) nově podporuje architekturu arm64 (vedle x86-64), podporuje reprodukovatelné sestavení většiny balíčků a vylepšuje systémové nástroje. Vlastní meta-správce balíčků APX nyní používá Distrobox v2 a je dostupný i pro jiné distribuce.
Přidáme si tedy repozitáře, pro které chceme balíček sestavit. To můžeme udělat například pomocí osc -e prj home:m4r3k, přičemž se nám opět spustí $EDITOR. Do něj pak napíšeme kód podobný tomu následujícímu:
<project name="home:m4r3k"> <title<m4r3k's Home Project</title> <description>My packages.</description> <person role="maintainer" userid="m4r3k"/> <repository name="openSUSE_10.3"> <path project="openSUSE:10.3" repository="standard"/> <arch>i586</arch> <arch>x86_64</arch> </repository> </project>
Jak vidíte, tento soubor má poměrně složitou syntaxi (alespoň já si ji ne a ne zapamatovat :-)), naštěstí se však repozitáře dají přidat i pomocí webového rozhraní. Přihlásíme se tedy na build.opensuse.org, v našem domovském projektu klikneme na tlačítko Add Repository a vybereme si některý z repozítářů, pro které chceme sestavovat. V našem příkladu se jedná o repozitáře openSUSE 10.3, Fedora 8 a Mandriva 2008.

Po přidání repozitářů se nám začnou sestavovat jednotlivé balíčky. Průběh sestavování si můžeme vypsat pomocí příkazu osc buildlog distribuce architektura, například tedy:
osc buildlog openSUSE_10.3 i586
Po nějaké době by nám měly vzniknout balíčky pro distribuce openSUSE, Fedora a Mandriva. Každá by měla obsahovat jeden textový soubor umístěný v adresáři /etc/ s příslušným jménem. To si můžeme zkontrolovat tak, že si sestavené balíčky stáhneme a pomocí rpm -qlp balíček.rpm necháme vypsat jejich obsah.
for foo in *.rpm; do echo "balíček $foo obsahuje"; rpm -qlp $foo; echo "---"; done balíček fedora-testovaci-balik.rpm obsahuje warning: fedora-testovaci-balik.rpm: Header V3 DSA signature: NOKEY, key ID a575c4b8 /etc/Fedora.txt --- balíček mandriva-testovaci-balik.rpm obsahuje warning: mandriva-testovaci-balik.rpm: Header V3 DSA signature: NOKEY, key ID a575c4b8 /etc/Mandriva.txt --- balíček openSUSE-testovaci-balik.rpm obsahuje warning: openSUSE-testovaci-balik.rpm: Header V3 DSA signature: NOKEY, key ID a575c4b8 /etc/openSUSE.txt ---
Mezi verzemi distribucí se často přejmenovávají, rozdělují a slučují balíčky. Proto je výhodné mít k dispozici i rozlišování podle verze jednotlivých distribucí. Například, pokud chceme, aby se nějaká část kódu provedla jen v případě, že jde o distribuci openSUSE a zároveň se jedná o verzi novější než 10.2, pak použijeme tento kód:
%if 0%{?suse_version} > 1020
%patch0
%endif
| Distribution | Variable |
|---|---|
| openSUSE Factory | %if 0%{?suse_version} == 1031 |
| openSUSE 10.3 | %if 0%{?suse_version} == 1030 |
| openSUSE 10.2 | %if 0%{?suse_version} == 1020 |
| SUSE Linux 10.1 | %if 0%{?suse_version} == 1010 |
| SLE{S,D} 10 | %if 0%{?sles_version} == 10 |
| SUSE Linux 10.0 | %if 0%{?suse_version} == 1000 |
| SUSE Linux 9.3 | %if 0%{?suse_version} == 930 |
| SLES 9 | %if 0%{?sles_version} == 9 |
| CentOS 5 | %if 0%{?centos_version} == 501 |
| RHEL 5 | %if 0%{?rhel_version} == 501 |
| Fedora 8 | %if 0%{?fedora_version} == 8 |
| Fedora 7 | %if 0%{?fedora_version} == 7 |
| Fedora 6 with Extras | %if 0%{?fedora_version} == 6 |
| Fedora 5 with Extras | %if 0%{?fedora_version} == 5 |
| Fedora 4 with Extras | %if 0%{?fedora_version} == 4 |
| Mandriva 2008 | %if 0%{?mandriva_version} == 2008 |
| Mandriva 2007 | %if 0%{?mandriva_version} == 2007 |
| Mandriva 2006 | %if 0%{?mandriva_version} == 2006 |
Tabulka převzata, upravena a aktualizována z en.opensuse.org.
Porovnávací operátory nejsou samozřejmě omezeny jen na operátor ekvivalence (==), ale také jsou k dispozici operátory menší než (<) a větší než (>). Tyto operátory můžeme také skládat a sestavit tak operátor větší nebo rovno (>=), případně menší nebo rovno =<). Stejně tak můžeme také kombinovat jednotlivé podmínky a sestavit například následující konstrukci:
%if 0%{?suse_version} || 0%{?sles_version}
%patch1 -p1
%endif
Která provede makro %patch vždy, když je balíček sestavován v prostředí openSUSE nebo SLES(D). U sestavování balíčků se lze také rozhodovat podle architektury a tyto podmínky lze samozřejmě také kombinovat ve složitější celky. Například takto:
%if 0%{?suse_version} == 1030
%ifarch x86_64
%patch1
%endif
%endif
Makro %patch1 bude provedeno, jen když je balíček sestavován pro openSUSE verze 10.3 a cílová architektura je x86_64.
Často se stane, že si chcete udělat balíček na nový program a z ničeho nic zjistíte, že programů, na kterých tento program závisí, je obrovská spousta. To je ještě v pohodě, jednoduše je napíšete do BuildRequires nebo do Requires. V tom horším případě však zjistíte, že potřebné balíčky nejsou k dispozici v oficiálních stromech balíčků. Pokud máte štěstí, tak balíček který potřebujete, už vytvořil někdo jiný, kdo připravuje balíčky v rámci openSUSE Build Service. Pak máte několik možnosti, jak tyto balíčky zužitkovat. Můžete je zkopírovat do svého projektu pomocí příkazu osc copypac, který má následující syntaxi:
osc copypac home:jiny-balikar cool-balicek home:m4r3k cool-balicek
Což vytvoří identickou kopii balíčku u vás v home:m4r3k. To se hodí v případě, že hodláte balíček nějak významněji upravovat. Má to však tu nevýhodu, že zbytečně plýtváte strojový čas i místo na build serverech. Proto je k dispozici také příkaz osc linkpac, který provede nalinkování balíčku z jednoho projektu do jiného. Tam se balíček sestaví a bude k dispozici i pro váš projekt. Toto řešení také nabízí určitou míru volnosti. Pokud totiž ve svém nalinkovaném projektu vytvoříte soubor se stejným názvem jako je v tom původním, tak se použije ten váš. Můžete si tak třeba poupravit .spec soubor, aniž by se muselo udržovat několik kopií tarové koule se zdrojovými kódy.
osc linkpac home:jiny-balikar cool-balicek home:m4r3k cool-balicek
Vlastní .spec soubor vnutíte projektu tak, že si aktualizujete svou lokální kopii repozitáře pomocí příkazu osc up a přepnete se do adresáře s balíčkem (cd cool-balicek). Pak si vytvoříte třeba soubor cool-balicek.spec a v něm vlastní obsah. Častěji však využijete už hotový .spec soubor a jen si jej upravíte k obrazu svému. Stažení originálního souboru lze provést pomocí:
osc co home:jiny-balikar cool-balicek cool-balicek.spec
Nyní už stačí soubor jen otevřít ve svém oblíbeném editoru a dle libosti upravit. Soubor poté přidáme do projektu pomocí osc add cool-balicek.spec a výsledek pošleme na server pomocí osc commit. Balíček se nyní sestaví i s vašimi změnami. Tento způsob sice už tolik neplýtvá místem na disku, ale na druhou stranu stále plýtvá strojovým časem serverů. Proto je k dispozici i příkaz osc aggregatepac, který je vhodný v případě, že chceme balíček jen používat a nijak upravovat. Syntaxe je obdobná jako u předchozích příkazů.
osc aggregatepac home:jiny-balikar cool-balicek home:m4r3k cool-balicek
Stejně jakou u předchozích dvou příkazů, je i u tohoto příkazu poslední parametr cool-balicek nepovinný a v případě, že jej nepoužijete, tak se použije název stejný jako u zdrojového balíčku.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
(Program běží, ale nic nedělá a plní konzoli chybovýma hláškama).
(Program běží, ale nic nedělá a plní konzoli chybovýma hláškama).Což mi bez těch hlášek vůbec nepomůže. :D
. Všechny ostatní chyby se už jen od toho odvíjí (křik urllib).
michals@smrz:~> yabsc
user 'ilfirin' not found
Traceback (most recent call last):
File "/usr/bin/yabsc", line 597, in run
self.projects = self.bs.getWatchedProjectList()
File "/usr/bin/yabsc", line 101, in getWatchedProjectList
tree = ElementTree.fromstring(''.join(core.get_user_meta(self.apiurl, username)))
TypeError