<?xml version="1.0" encoding="utf-8"?> <feed xmlns="http://www.w3.org/2005/Atom"> <id>https://www.archlinux.de/news/feed</id> <title>Aktuelle Arch Linux Neuigkeiten</title> <updated>2024-11-21T08:14:03+00:00</updated> <link rel="alternate" href="https://www.archlinux.de/news"/> <link rel="self" href="https://www.archlinux.de/news/feed"/> <icon>https://www.archlinux.de/img/archicon.svg</icon> <logo>https://www.archlinux.de/img/archlogo.svg</logo> <entry> <id>https://www.archlinux.de/news/35319</id> <title>Aktualisierung von Pacman erfordert unter Umständen einen manuellen Eingriff</title> <updated>2024-09-25T04:43:09+00:00</updated> <link rel="alternate" href="https://www.archlinux.de/news/35319-Aktualisierung-von-Pacman-erfordert-unter-Umstaenden-einen-manuellen-Eingriff"/> <author> <name>Dirk</name> <uri>https://forum.archlinux.de/u/Dirk</uri> </author> <content type="html"><p>Mit der Einführung von <a href="https://gitlab.archlinux.org/pacman/pacman/-/blob/master/NEWS?ref_type&#61;heads" rel="noopener noreferrer nofollow">Pacman 7.0.0</a> wurde die Unterstützung für den Download von Paketen mit Benutzeraccounts mit weniger Berechtigungen hinzugefügt.</p> <p>Für Benutzer die lokale Repos nutzen bedeutet dies, dass der Download-Benutzer auf die infrage kommenden Dateien nicht zugreifen darf. Das kann damit behoben werden, indem man den Dateien und Verzeichnissen die <code>alpm</code>-Gruppe zuweist, und sicherstellt, dass die <a href="https://wiki.archlinux.de/title/Rechteverwaltung" rel="noopener noreferrer nofollow">Gruppe auch Zugriff erhält</a>.</p> <pre><code>chown :alpm -R /pfad/zum/lokalen/repo chmod g&#43;x /pfad/zum/lokalen/repo/</code></pre> <p>Nicht vergessen, nach dem Pacman-Update die <code>.pacnew</code>-Datei mit der <a href="https://wiki.archlinux.de/title/Pacnew-_und_Pacsave-Dateien" rel="noopener noreferrer nofollow">aktuellen Konfiguration zusammenzuführen</a>, um den neuen Standard zu verwenden.</p> <p>Pacman erfuhr ebenfalls eine Änderung, um durch Verwendung der <code>.gitattributes</code>-Dateien die Prüfsummenstabilität von Git-Repos zu verbessern. Dies könnte eine einmalige Prüfsummenänderung in PKGBUILDs benötigen, die ein Git-Repository als Quelle benutzen.</p> </content> </entry> <entry> <id>https://www.archlinux.de/news/35174</id> <title>Backdoor in xz vor Version 5.6.1-2</title> <updated>2024-03-30T09:53:16+00:00</updated> <link rel="alternate" href="https://www.archlinux.de/news/35174-Backdoor-in-xz-vor-Version-5-6-1-2"/> <author> <name>Dirk</name> <uri>https://forum.archlinux.de/u/Dirk</uri> </author> <content type="html"><p><strong>Aufgrund einer kürzlich bekannt gewordenen Backdoor im <a href="https://www.archlinux.de/packages/core/x86_64/xz" rel="noopener noreferrer nofollow">Paket xz</a> (genauer, in der <code>liblzma</code>) wird dringend dazu geraten, Arch Linux auf den aktuellsten Stand zu bringen.</strong></p> <p>Details zur Problematik im initialen <a href="https://www.openwall.com/lists/oss-security/2024/03/29/4" rel="noopener noreferrer nofollow">Secutiry-Report</a>, sowie unter der dazugehörigen <a href="https://nvd.nist.gov/vuln/detail/CVE-2024-3094" rel="noopener noreferrer nofollow">CVE-2024-3094</a> bzw. <a href="https://security.archlinux.org/AVG-2851" rel="noopener noreferrer nofollow">AVG-2851</a>.</p> <h3>Betroffene Systeme</h3> <ul><li>Installationsmedium <code>2024.03.01</code></li> <li>VM-Images <code>0240301.218094</code> und <code>20240315.221711</code></li> <li>Container-Images die zwischen dem 24. Februar und 28. März 2024 erstellt wurden</li></ul> <p>Die betroffenen Artefakte wurden von den Servern und den Mirrors entfernt, und sollten nicht mehr verwendet, bzw. umgehend aktualisiert werden.</p> <h3>Installation aktualisieren</h3> <ul><li>Systemupdate durchführen: <code>pacman -Syu</code></li> <li>xz-Version prüfen: <code>pacman -Qi xz</code></li></ul> <p>Nach der Aktualisierung muss die xz-Version mindestens <code>5.6.1-2</code> sein. Sollte dies nicht der Fall sein, bitte die Aktualität des Mirrors prüfen, und ggf. <a href="https://www.archlinux.de/mirrors" rel="noopener noreferrer nofollow">kurzzeitig auf einen aktuellen Mirror ausweichen</a>.</p> <h3>Container-Images aktualisieren</h3> <p>Containerimage prüfen</p> <ul><li>Podman: <code>podman image history archlinux/archlinux</code></li> <li>Docker: <code>docker image history archlinux/archlinux</code></li></ul> <p>Images älter als 29. März 2024 und neuer als 24. Februar 2024 sind betroffen, hier sollte umgehend ein Update stattfinden.</p> <ul><li>Podman: <code>podman image pull archlinux/archlinux</code></li> <li>Docker: <code>docker image pull archlinux/archlinux</code></li></ul> <p>Danach muss sichergestellt werden, dass der Container aus dem aktualisierten Image neu gebaut wird.</p> <h3>Bezüglich des Bypasses der sshd-Authentifizierung</h3> <p>Arch linkt <code>openssh</code> nicht direkt zur <code>liblzma</code>, daher ist diese Angriffsmethode hier nicht möglich. Mittels folgenden Befehls kann man dies verifizieren.</p> <p><code>ldd &#34;$(command -v sshd)&#34;</code></p> <p>Es wird dennoch dringend dazu geraten, alle betroffenen Systemkomponenten durch ein vollständiges Systemupdate zu aktualisieren, um eventuell noch unentdeckte Probleme mit dieser Backdoor zu verhindern</p> </content> </entry> <entry> <id>https://www.archlinux.de/news/35118</id> <title>Wechsel von dbus-daemon auf dbus-broker</title> <updated>2024-02-05T15:05:17+00:00</updated> <link rel="alternate" href="https://www.archlinux.de/news/35118-Wechsel-von-dbus-daemon-auf-dbus-broker"/> <author> <name>stefanhusmann</name> <uri>https://forum.archlinux.de/u/stefanhusmann</uri> </author> <content type="html"><p>Das Arch Linux Entwicklerteam favorisiert künftig den dbus-broker anstelle des dbus-daemon als Standard-Implentierung des D-Bus, um Performance, Zuverlässigkeit und das Zusammenspiel mit systemd zu verbessern.</p> <p>Für eine absehbare Zukunft wird auch der dbus-daemon - die vorherige Implementation - noch unterstützt. Pacman wird fragen, ob dbus-broker-units or dbus-daemon-units installiert werden sollen. Empfehlung und Standard bei nichtaktiver Auswahl ist ersteres.</p> <p>Mehr dazu in <a href="https://gitlab.archlinux.org/archlinux/rfcs/-/blob/master/rfcs/0025-dbus-broker-default.rst" rel="noopener noreferrer nofollow">https://gitlab.archlinux.org/archlinux/rfcs/-/blob/master/rfcs/0025-dbus-broker-default.rst</a><br /> RFC 25.</p></content> </entry> <entry> <id>https://www.archlinux.de/news/35016</id> <title>Anstehende Änderungen bei JDK/JRE-Paketen erfordern u.U. manuellen Eingriff</title> <updated>2023-11-02T10:30:11+00:00</updated> <link rel="alternate" href="https://www.archlinux.de/news/35016-Anstehende-Aenderungen-bei-JDK-JRE-Paketen-erfordern-u-U-manuellen-Eingriff"/> <author> <name>stefanhusmann</name> <uri>https://forum.archlinux.de/u/stefanhusmann</uri> </author> <content type="html"><p>Die Arch Linux Developer führen mit der anstehenden Einführung der Version 21 eine Änderung ein, die unter Umständen (s.u.) einen manuellen eingriff erfordern. <br /> Anstatt dass die Spielarten JDK (Java Developement Kit) und JRE (Java Runtime Environment) auf demselben System koexistieren können, werden Sie künftig zueinander in Konflikt stehen. Die JDK-Variante wird die Laufzeitumgebung JRE mitenthalten. Wenn man beides braucht, muss man also nur noch das JDK installieren. In diesem Fall würde pacman das jre automatisch deinstallieren.</p> <p>Wenn man andererseits nur eine Laufzeitumgebung braucht, kann man jre oder jre-headless installieren. Der manuelle Eingriff ist dann nötig, wenn man bislang jre <em>und</em> jre-headless installiert hatte. Man muss sich dann eines aussuchen und manuell installieren.</p> <p>Das gilt wie gesagt erst ab Version 21.</p></content> </entry> <entry> <id>https://www.archlinux.de/news/34926</id> <title>Aktualisierung des Budgie-Desktops erfordert manuellen Eingriff</title> <updated>2023-08-06T10:43:24+00:00</updated> <link rel="alternate" href="https://www.archlinux.de/news/34926-Aktualisierung-des-Budgie-Desktops-erfordert-manuellen-Eingriff"/> <author> <name>stefanhusmann</name> <uri>https://forum.archlinux.de/u/stefanhusmann</uri> </author> <content type="html"><p>Bei der Aktualisierung ds Pakets &#34;budgie-desktop&#34; von 10.7.2-5 auf 10.7.2-6 muss das Paket &#34;mutter43&#34; durch &#34;magpie-wm&#34; ersetzt werden, das zur Zeit vom Paket &#34;mutter&#34; abhängt. Da &#34;mutter43&#34; mit &#34;mutter&#34; in Konflikt steht, geht dies nicht ohne manuellen Engriff ab.</p> <ol><li><p>Deinstallation von &#34;mutter43&#34; via &#34;pacman -Rdd mutter43&#34;</p></li> <li><p>Unmittelbar danach, d.h. ohne sich zwischenzeitlich neu einzuloggen oder zu rebooten, eine Systemaktualisierung via &#34;pacman -Syu&#34;</p></li></ol> <p>Dadurch kann man den Konflikt umgehen.</p></content> </entry> <entry> <id>https://www.archlinux.de/news/34889</id> <title>Neuschneidung der TeXLive-Pakete</title> <updated>2023-06-18T14:16:52+00:00</updated> <link rel="alternate" href="https://www.archlinux.de/news/34889-Neuschneidung-der-TeXLive-Pakete"/> <author> <name>stefanhusmann</name> <uri>https://forum.archlinux.de/u/stefanhusmann</uri> </author> <content type="html"><p>Seit 2023.66594-9 sind die Arch-Linux-TeXLive Pakete reorganisiert und neu geschnitten worden, um die <br /> Reorganisation der an der Originaldistribution vorgenommenen Aufteilungen besser wiederzuspiegeln.</p> <ul><li>texlive-basic ersetzt das bisherige texlive-core</li> <li>viele der bislang in texlive-core aufgeteilten Pakete, darunter sprachspezifische Dinge, wurden auf mehrere Pakete aufgeteilt. </li> <li>das bisher zwar mitglieferte Utility tlmgr ist nun nutzbar, zum Beispiel um die Zuordnung eines CTAN-Pakete zu einem Arch-Paket herauszufinden. So bedeutet z.B. <pre><code>$ tlmgr info euler | grep collection collection: collection-latexrecommended</code></pre> dass das euler-Paket in texlive-latexrecommended angesiedelt ist. Für einzelne Dateien ist aber auch pacman -F wie üblich nutzbar.</li></ul> <p>Es gibt ein neues Metapaket texlive-meta, das ähnlich wie das bisherige Metapaket texlive-most zu sehen ist, aber die sprachspezifischen Dateien nicht enthält.</p> <p>Ganz neu ist texlive-doc, um die Dokumentation offline installieren zu können.</p></content> </entry> <entry> <id>https://www.archlinux.de/news/34887</id> <title>Openblas-Aktualisierung erfordert manuellen Eingriff</title> <updated>2023-06-17T06:58:49+00:00</updated> <link rel="alternate" href="https://www.archlinux.de/news/34887-Openblas-Aktualisierung-erfordert-manuellen-Eingriff"/> <author> <name>stefanhusmann</name> <uri>https://forum.archlinux.de/u/stefanhusmann</uri> </author> <content type="html"><p>Das openplas-Paket vor 0.3.23-2 hat die optimierte LAPACK-Routine und CBLAS/LAPACKE Schnittstellen nicht mitgeliefert. TDiese Entscheidung wurde zurückgenommen, um die Möglichkeit, eine alternative Implementierung der BLAS/LAPACK-Familie zu installieren ohne openblas deinstallieren zu müssen, wird nun wieder angeboten</p> <p>Die Standard-BLAS-Implementierung kommt für viele der darauf aufbauenden mathematischen Pakete wie R oder NumPy zum Einsatz. Dazu müssen die Pakete &#34;blas-openblas&#34; und &#34;blas64-openblas&#34; installiert werden.</p> <p>Leider kann das zu Fehlermeldungen der folgenden Art führen:</p> <p><code>error: failed to prepare transaction (could not satisfy dependencies) :: installing openblas (0.3.23-2) breaks dependency &#039;blas&#039; required by cblas :: installing openblas (0.3.23-2) breaks dependency &#039;blas&#039; required by lapack</code></p> <p>Dem entgeht man, wenn man abhängig von der gewünschten Implemetierung den pacman-Aufruf um ein Argument erweitert. Zum Beispiel <code>pacman -Syu blas-openblas</code> oder <code>pacman -Syu blas</code>.</p></content> </entry> <entry> <id>https://www.archlinux.de/news/34866</id> <title>Git-Migration erfolgreich abgeschlossen</title> <updated>2023-05-24T13:44:54+00:00</updated> <link rel="alternate" href="https://www.archlinux.de/news/34866-Git-Migration-erfolgreich-abgeschlossen"/> <author> <name>Pierre</name> <uri>https://forum.archlinux.de/u/Pierre</uri> </author> <content type="html"><p>Die Migration der Paket-Quellen zu <a href="https://gitlab.archlinux.org/archlinux/packaging/packages" rel="noopener noreferrer nofollow">GitLab</a> ist erfolgreich beendet worden. Der Bug-Tracker bleibt vorerst <a href="https://bugs.archlinux.org/" rel="noopener noreferrer nofollow">Flyspray</a> und Merge-Requests über GitLab können aktuell nicht angenommen werden. Künftig ist allerdings geplant den Issue-Tracker von GitLab hierfür zu nutzen.</p> <p>Da in dem Zuge alle Pakete des <code>[community]</code>-Repository nach <a href="https://www.archlinux.de/packages?repository&#61;extra" rel="noopener noreferrer nofollow">[extra]</a> verschoben wurden, kann der entsprechende Eintrag aus <code>/etc/pacman.conf</code> entfernt werden. Für Nutzer der <code>[testing]</code>-Repositories ist zu beachten, dass diese nun durch <a href="https://www.archlinux.de/packages?repository&#61;core-testing" rel="noopener noreferrer nofollow">[core-testing]</a> <em>und</em> <a href="https://www.archlinux.de/packages?repository&#61;extra-testing" rel="noopener noreferrer nofollow">[extra-testing]</a> zu ersetzen sind.</p> <p>Aus</p> <pre><code>[core] Include &#61; /etc/pacman.d/mirrorlist [extra] Include &#61; /etc/pacman.d/mirrorlist [community] Include &#61; /etc/pacman.d/mirrorlist</code></pre> <p>wird also</p> <pre><code>[core] Include &#61; /etc/pacman.d/mirrorlist [extra] Include &#61; /etc/pacman.d/mirrorlist</code></pre> <p>Für Nutzer der <code>[testing}</code>-Repositories wird analog aus</p> <pre><code>[testing] Include &#61; /etc/pacman.d/mirrorlist [core] Include &#61; /etc/pacman.d/mirrorlist [extra] Include &#61; /etc/pacman.d/mirrorlist [community-testing] Include &#61; /etc/pacman.d/mirrorlist [community] Include &#61; /etc/pacman.d/mirrorlist</code></pre> <p>schließlich:</p> <pre><code>[core-testing] Include &#61; /etc/pacman.d/mirrorlist [core] Include &#61; /etc/pacman.d/mirrorlist [extra-testing] Include &#61; /etc/pacman.d/mirrorlist [extra] Include &#61; /etc/pacman.d/mirrorlist</code></pre> <p><em>Wichtig</em>: Stelle sicher, dass Dein Mirror aktuell ist. Dieser sollte nach dem 21.5.2023 aktualisiert worden sein. Diese Daten findest Du im <a href="https://www.archlinux.de/mirrors" rel="noopener noreferrer nofollow">Mirror-Status</a>.</p> <p>Wer bisher <code>asp</code> zum Herunterladen der Paket-Quellen nutzte, kann nun auf das neue Tool <code>pkgctl</code> wechseln, welches von <a href="https://www.archlinux.de/packages/extra/x86_64/devtools" rel="noopener noreferrer nofollow">devtools</a> ab 1:1.0.0-1 bereitgestellt wird.</p></content> </entry> <entry> <id>https://www.archlinux.de/news/34754</id> <title>Einführung des base-devel Meta-Paket benötigt manuellen Eingriff</title> <updated>2023-02-19T11:32:39+00:00</updated> <link rel="alternate" href="https://www.archlinux.de/news/34754-Einfuehrung-des-base-devel-Meta-Paket-benoetigt-manuellen-Eingriff"/> <author> <name>Pierre</name> <uri>https://forum.archlinux.de/u/Pierre</uri> </author> <content type="html"><p>Die Paket-Gruppe <code>base-devel</code> wurde durch ein Meta-Paket mit selben Namen ersetzt. Falls die Gruppe vor dieser Änderung installiert wurde, so kann das neue Paket <a href="https://www.archlinux.de/packages/core/x86_64/base-devel" rel="noopener noreferrer nofollow">base-devel</a> expliziet installiert werden:<br /> <code>pacman -Syu --needed base-devel</code></p></content> </entry> <entry> <id>https://www.archlinux.de/news/34723</id> <title>Aktualisierung auf PHP 8.2 und die Einführung eines Legacy-Zweig</title> <updated>2023-01-13T13:46:53+00:00</updated> <link rel="alternate" href="https://www.archlinux.de/news/34723-Aktualisierung-auf-PHP-8-2-und-die-Einfuehrung-eines-Legacy-Zweig"/> <author> <name>Pierre</name> <uri>https://forum.archlinux.de/u/Pierre</uri> </author> <content type="html"><p>Die <a href="https://www.archlinux.de/packages/extra/x86_64/php" rel="noopener noreferrer nofollow">php</a>-Pakete wurden auf die neueste Version 8.2 aktualisiert. Darüber hinaus wurden neue <a href="https://www.archlinux.de/packages/extra/x86_64/php-legacy" rel="noopener noreferrer nofollow">php-legacy</a>-Pakete eingeführt. Diese folgen dem ältesten <a href="https://www.php.net/supported-versions.php" rel="noopener noreferrer nofollow">aktiv unterstütztem PHP-Entwicklungszweig</a>. Dies ermöglicht Nutzern sowohl die neueste Version zu installieren als auch Dritt-Anbieter-Anwendungen zu nutzen, die noch eine ältere Version benötigen. Beide Varianten werden ständig aktualisiert werden. <code>php</code> und <code>php-legacy</code> können dabei gleichzeitig installiert werden, da letztere den <code>-legacy</code>-Suffix für Programme und Konfiguration nutzt.</p> <p>Zusätzlich wurden die <a href="https://www.archlinux.de/news/33796-PHP-8-0-und-PHP-7-Legacy-Pakete-sind-verfuegbar" rel="noopener noreferrer nofollow">php7</a>-Pakete entfernt, da sie ihr Lebensende erreicht hatten. Die <code>imap</code>-Erweiterung wird nicht mehr bereitgestellt, da es von der <code>c-client</code>-Bibliothek abhängig, dessen Entwicklung vor Jahren eingestellt wurde.</p></content> </entry> <entry> <id>https://www.archlinux.de/news/34608</id> <title>python2 aus den offiziellen Repo entfernt</title> <updated>2022-09-24T08:27:44+00:00</updated> <link rel="alternate" href="https://www.archlinux.de/news/34608-python2-aus-den-offiziellen-Repo-entfernt"/> <author> <name>stefanhusmann</name> <uri>https://forum.archlinux.de/u/stefanhusmann</uri> </author> <content type="html"><p>Da Python in der Version 2 seit Januar 2020 offiziell im Status <a href="https://www.python.org/doc/sunset-python-2" rel="noopener noreferrer nofollow">End of Life</a> war, wurden seitdem nach und nach alle Pakete, die darauf basieren, aus den Repos entfernt.</p> <p>Nun ist der Tag gekommen, dass Python2 entgültig aus den Repositories verschwindet.<br /> Wer es noch braucht, muss es auf eigene Gefahr aus dem AUR oder einem der <a href="https://wiki.archlinux.org/title/Unofficial_user_repositories" rel="noopener noreferrer nofollow">inoffiziellen Repos</a>, die es noch führen, installieren.</p> </content> </entry> <entry> <id>https://www.archlinux.de/news/34519</id> <title>Aktualisierung der wxwidget-Pakete erfordert manuellen Eingriff</title> <updated>2022-07-15T03:54:30+00:00</updated> <link rel="alternate" href="https://www.archlinux.de/news/34519-Aktualisierung-der-wxwidget-Pakete-erfordert-manuellen-Eingriff"/> <author> <name>stefanhusmann</name> <uri>https://forum.archlinux.de/u/stefanhusmann</uri> </author> <content type="html"><p>Mit der Version 3.2 gab es einige Neuerungen bei den Paketen, die nicht alle automatisiert abgefangen werden konnten.<br /> WxWidgets 3.2 kommt mit einem QT-Frontend neben dem bekannten GTK3-Frontend. Um dies zu widerspiegeln, wurden die Pakete von wxgtk* auf wxwidgets* umbenannt. Hingegen wird das GTK2-Frontend nicht mehr unterstützt. Hat man es noch installiert, wird die Aktualisierung fehlschlagen. In diesem Fall muss man wxgtk2 vor der Aktualisierung erst deinstallieren.</p> </content> </entry> <entry> <id>https://www.archlinux.de/news/34460</id> <title>Voreilige Ersetzung des Paketes pipewire-media-session </title> <updated>2022-05-20T12:12:49+00:00</updated> <link rel="alternate" href="https://www.archlinux.de/news/34460-Voreilige-Ersetzung-des-Paketes-pipewire-media-session"/> <author> <name>stefanhusmann</name> <uri>https://forum.archlinux.de/u/stefanhusmann</uri> </author> <content type="html"><p>Vor einigen Tagen wurde das Paket wireplumber mit der Maßgabe, dass es das Paket pipewire-media-session ersetzt, in die Repos gestellt. Dies geschah, da der Session Manager aus dempipewire-media-session als veraltet und nicht länger betreut galt.</p> <p>Leider war dies voreilig und muss zurückgenommen werden. Die Audio-Pakete aus dem Pipewire-Umfeld (pipewire-alsa, pipewire-jack and pipewire-pulse) kommen mit einer Konfiguration, durch die man über media-session gefragt wird, ob man Pipewires-Audo-Eigenschaften aktivieren will. Bejaht man dies, kann man ohne Rückgriff auf ALSA oder PulseAudio allein mit Bordmitteln Bildschirmaufzeichnugen machen.</p> <p>Dieser Mechanismus wird durch Wireplumber nicht beachtet. Dadurch ist es nicht möglich, hier PulseAudio oder ALSA zu benutzen. Bestehende Konfigurationen, die dies tun, gehen kaputt.</p> <p>Bis eine bessere Lösung gefunden wird, wurde der Mechanismus der Paketersetzung wieder deaktiviert. Wer also zur Zeit Pipewire <strong>nicht</strong> für Audio verwenden will, aber wireplumber installiert bekommen hat, sollte pipewire-media-session wieder installieren und das System neu starten.<br /> <code>pacman -Syu pipewire-media-session</code></p> </content> </entry> <entry> <id>https://www.archlinux.de/news/34444</id> <title>Qemu-Pakete neu aufgeteilt</title> <updated>2022-05-11T00:36:07+00:00</updated> <link rel="alternate" href="https://www.archlinux.de/news/34444-Qemu-Pakete-neu-aufgeteilt"/> <author> <name>stefanhusmann</name> <uri>https://forum.archlinux.de/u/stefanhusmann</uri> </author> <content type="html"><p>Mit Erscheinen der Version 7.0.0 wurde eine neue Aufteilung der Paketlandschaft vorgenommen.</p> <ul><li>Das qemu-Paket existiert nicht mehr als solches, sondern wird durch qemu-base, qemu-desktop oder qemu-full geliefert-</li> <li>Die bisherige Funktionalität von qemu geht auf qemu-desktop über.</li> <li>Die bisherige Funktionalität von qemu-headless geht auf qemu-base über.</li> <li>Die bisherige Funktionalität von qemu-arch-extra und qemu-headless-arch-extra geht auf qemu-emulators-full über.</li> <li>Das Meta-Paket qemu-full umfasst alle mit QEMU zusammenhängenden Pakete außer qemu-guest-agent.</li></ul></content> </entry> <entry> <id>https://www.archlinux.de/news/34439</id> <title>Ungültige Signierungsschlüssel beim Systemupdate</title> <updated>2022-05-06T07:42:15+00:00</updated> <link rel="alternate" href="https://www.archlinux.de/news/34439-Ungueltige-Signierungsschluessel-beim-Systemupdate"/> <author> <name>Dirk</name> <uri>https://forum.archlinux.de/u/Dirk</uri> </author> <content type="html"><p>Aktuell gibt es einige Signierungsschlüssel für Arch-Pakete, die beim Update als ungültig (abgelaufen, zurückgezogen, etc.) erkannt werden. Dadurch schlägt das Systemupdate mit Pacman fehl.</p> <pre><code>Fehler: paketname: signature from &#34;Signaturname &lt;mailadresse&#64;example.com&gt;&#34; is marginal trust :: Datei /var/cache/pacman/pkg/paketdateiname ist beschädigt (Ungültiges oder beschädigtes Paket (PGP-Signatur)).</code></pre> <p>Wenn im Zuge des Updates das Paket <code>archlinux-keyring</code> aktualisiert werden soll, so ist dieses Paket zuerst alleine zu aktualisieren, und danach das gesamte System.</p> <pre><code>pacman -Sy archlinux-keyring pacman -Syu</code></pre> <p>Wenn das Paket <code>archlinux-keyring</code> nicht in der Liste der zu aktualisierenden Pakete ist, reicht es, wenn man mittels <a href="https://wiki.archlinux.de/title/Pacman-key" rel="noopener noreferrer nofollow">pacman-key</a> die Signierungsschlüssel für die Pakete aktualisiert bevor man das Systemupdate durchführt.</p> <pre><code>pacman-key --refresh-keys pacman -Syu</code></pre> <p>In beiden Fällen werden also erst die Signierungsschlüssel aktualisiert, und dann das System.</p></content> </entry> <entry> <id>https://www.archlinux.de/news/34404</id> <title>Keycloack 17.0.1-2 Aktualisierung erfordert manuelle Neukonfiguration</title> <updated>2022-04-03T04:37:58+00:00</updated> <link rel="alternate" href="https://www.archlinux.de/news/34404-Keycloack-17-0-1-2-Aktualisierung-erfordert-manuelle-Neukonfiguration"/> <author> <name>stefanhusmann</name> <uri>https://forum.archlinux.de/u/stefanhusmann</uri> </author> <content type="html"><p>Arch Linux folgt der Upstream-Entscheidung des Keycloak-Projektes, vom Wildfly-Server auf die <a href="https://www.keycloak.org/2020/12/first-keycloak-x-release.adoc" rel="noopener noreferrer nofollow">Quartus-Distribution</a> umzusteigen. <br /> Der Umstieg erfordert eine manuell Edition der bisherigen .xml-Datei in ein neues Format und den Stop und Start des kecloak-Services.<br /> Siehe <a href="https://www.keycloak.org/migration/migrating-to-quarkus" rel="noopener noreferrer nofollow">https://www.keycloak.org/migration/migrating-to-quarkus</a> und <a href="https://www.keycloak.org/server/configuration" rel="noopener noreferrer nofollow">https://www.keycloak.org/server/configuration</a></p></content> </entry> <entry> <id>https://www.archlinux.de/news/34320</id> <title>Firmware-Kompression und -Aufteilung</title> <updated>2022-01-29T22:00:44+00:00</updated> <link rel="alternate" href="https://www.archlinux.de/news/34320-Firmware-Kompression-und-Aufteilung"/> <author> <name>stefanhusmann</name> <uri>https://forum.archlinux.de/u/stefanhusmann</uri> </author> <content type="html"><p>Das Paket &#34;linux-firmware&#34; ab Version 20220119.0c6a7b3-2 unterstützt Firmware-Kompression. Dies funktioniert aber nur für Kernel ab Version 5.3 und es muss die Kernel-Option CONFIG_FW_LOADER_COMPRESS aktiviert sein. Bei offiziellen Arch-Linux-Kerneln ist das seit langem der Fall.</p> <p>Darüber hinaus wurden größere und selten benutzte Firmware-Dateien aus dem Paket heraussepariert und in Einzelpakte ausgelagert. Dies betrifft Firmware für Mellanox Spectrum Switche, Marvell-Geräte, Qualcomm SoCs, Cavium LiquidIO Serveradapter, QLogic-Geräte, Broadcom NetXtreme II 10Gb Ethernet-Adapters. Wenn man so etwas hat, sollte man die entsprechenden Pakete installieren.</p></content> </entry> <entry> <id>https://www.archlinux.de/news/34275</id> <title>Aktualisierung von libxml2 auf 2.9.12-6 erfordert manuellen Eingriff</title> <updated>2021-12-27T10:01:41+00:00</updated> <link rel="alternate" href="https://www.archlinux.de/news/34275-Aktualisierung-von-libxml2-auf-2-9-12-6-erfordert-manuellen-Eingriff"/> <author> <name>stefanhusmann</name> <uri>https://forum.archlinux.de/u/stefanhusmann</uri> </author> <content type="html"><p>Die libxml2-Pakete vor 2.9.12-6 enthielten keine Python-Module in Byte-kompilierter Form (Endung .pyc). Dies wurde nun korrigiert, was zur Folge hat, dass Fehlermeldungen über nicht im Paket befindliche Dateien auftreten können.</p> <pre><code>libxml2: /usr/lib/python3.10/site-packages/__pycache__/drv_libxml2.cpython-310.opt-1.pyc exists in filesystem libxml2: /usr/lib/python3.10/site-packages/__pycache__/drv_libxml2.cpython-310.pyc exists in filesystem libxml2: /usr/lib/python3.10/site-packages/__pycache__/libxml2.cpython-310.opt-1.pyc exists in filesystem libxml2: /usr/lib/python3.10/site-packages/__pycache__/libxml2.cpython-310.pyc exists in filesystem</code></pre> <p>(oder auf Deutsch &#34;existiert im Dateisystem&#34;) können mit Hilfe der &#34;overwrite&#34;-Option überschrieben werden</p> <pre><code>pacman -Syu --overwrite /usr/lib/python3.10/site-packages/__pycache__/\*</code></pre> </content> </entry> <entry> <id>https://www.archlinux.de/news/34097</id> <title>Neues Forum für archlinux.de</title> <updated>2021-08-08T08:22:46+00:00</updated> <link rel="alternate" href="https://www.archlinux.de/news/34097-Neues-Forum-fuer-archlinux-de"/> <author> <name>Pierre</name> <uri>https://forum.archlinux.de/u/Pierre</uri> </author> <content type="html"><p>Wir haben unsere Foren-Software von <a href="https://fluxbb.org/" rel="noopener noreferrer nofollow">FluxBB</a> auf <a href="https://flarum.org/" rel="noopener noreferrer nofollow">Flarum</a> umgestellt. Ein Wechsel war mit Blick auf Sicherheit und System-Kompatibilität unausweichlich, da <a href="https://fluxbb.org/" rel="noopener noreferrer nofollow">FluxBB</a> nicht mehr weiterentwickelt wird. Es wurden viele mögliche Alternativen evaluiert. <a href="https://flarum.org/" rel="noopener noreferrer nofollow">Flarum</a> punktet mit einem einfachen und schlankem Setup, ist modular und wir können benötigte Funktionen mittels Erweiterungen hinzufügen.</p> <p>Viele Funktionen sind anders und es gibt einige neue. Naturgemäß werden wir Zeit benötigen um uns auch hier heimisch zu fühlen. Im <a href="https://wiki.archlinux.de/title/Flarum" rel="noopener noreferrer nofollow">Wiki</a> dokumentieren wir erste Wegweiser.</p> <p>Teilt gerne eure ersten Eindrücke und selbstverständlich auch Verbesserungsvorschläge im <a href="https://forum.archlinux.de/d/34097-neues-forum-fur-archlinuxde" rel="noopener noreferrer nofollow">Forum</a>.</p></content> </entry> <entry> <id>https://www.archlinux.de/news/34044</id> <title>libxcrypt und schwache Passwortverschlüsselungen</title> <updated>2021-06-11T16:23:23+00:00</updated> <link rel="alternate" href="https://www.archlinux.de/news/34044-libxcrypt-und-schwache-Passwortverschluesselungen"/> <author> <name>stefanhusmann</name> <uri>https://forum.archlinux.de/u/stefanhusmann</uri> </author> <content type="html">Ab Version 4.4.21 unterstützt libxcrypt keine scwachen Hashalgorithmen zur Passwortverschlüsselung mehr. Das betrifft die Anmeldung am Betriebssystem. Es kann bei Passwörtern, die noch mit alten Hashes verschlüsselt worden sind, dazu führen, dass man einmalig dazu aufgefordert wird, sein Passwort zu ändern. Displaymanager haben damit so ihre Probleme. Falls man also in Schwierigkeiten beim Anmelden kommt, sollte man sich einmal über ein Terminal anmelden und das Passwort ändern.</content> </entry> <entry> <id>https://www.archlinux.de/news/34024</id> <title>Abschied von freenode</title> <updated>2021-05-31T14:18:52+00:00</updated> <link rel="alternate" href="https://www.archlinux.de/news/34024-Abschied-von-freenode"/> <author> <name>stefanhusmann</name> <uri>https://forum.archlinux.de/u/stefanhusmann</uri> </author> <content type="html">In letzter Zeit hat es einen Streit darüber gegeben, wem das <a href="https://freenode.net/" rel="noopener noreferrer nofollow">freenode.net</a>-Netzwerk für IRC gehört. der streit hat unter anderem auch dazu geführt, dass viele der Betreuer des Netzwerks dieses verlassen und ein neues gegründet haben: <a href="https://libera.chat/" rel="noopener noreferrer nofollow">libera.chat</a>.<br /> <br /> Das IRC-Netzwerk wurde von vielen Projekten, darunter auch Arch Linux, als Plattform für Online-Diskussionen und -Support benutzt. Mit dem heutigen Tag wird Arch Linux (und auch befreundete Projekte wie Arch Linux ARM und Arch Linux 32 damit beginnen, die offizielle Infrastruktur für IRC von <a href="https://freenode.net/" rel="noopener noreferrer nofollow">freenode.net</a> nach <a href="https://libera.chat/" rel="noopener noreferrer nofollow">libera.chat</a> zu migrieren. <br /> <br /> Wir bitten bis zum reibungslosen Lauf aller Dienste um etwas Geduld.</content> </entry> <entry> <id>https://www.archlinux.de/news/33941</id> <title>Installationsmedium enthält jetzt ein Installprogramm</title> <updated>2021-04-02T17:48:48+00:00</updated> <link rel="alternate" href="https://www.archlinux.de/news/33941-Installationsmedium-enthaelt-jetzt-ein-Installprogramm"/> <author> <name>stefanhusmann</name> <uri>https://forum.archlinux.de/u/stefanhusmann</uri> </author> <content type="html">Das aktuelle offizielle Installationsmedium weist jetzt ein Installationsprogramm für eine geführte Installation auf. <br /> <br /> Dies zusätzlich zur <a href="https://wiki.archlinux.de/title/Anleitung_f%C3%BCr_Einsteiger" rel="noopener noreferrer nofollow">Standardverfahrensweise</a> angebotene Möglichkeit orientiert sich an den <a href="https://wiki.archlinux.org/index.php/Category:Installation_process" rel="noopener noreferrer nofollow">bestehenden Wiki-Anleitungen</a>.<br /> <br /> Falls man dieses Installationsprogramm bei den Installtion verwendet hat und hier Unterstützung sucht, sollte man zwingend diesen Umstand erwähnen und die Logdatei mitliefern.</content> </entry> <entry> <id>https://www.archlinux.de/news/33913</id> <title>Warnung für Benutzer von signal-desktop: Datenverlust möglich</title> <updated>2021-03-14T19:19:58+00:00</updated> <link rel="alternate" href="https://www.archlinux.de/news/33913-Warnung-fuer-Benutzer-von-signal-desktop-Datenverlust-moeglich"/> <author> <name>stefanhusmann</name> <uri>https://forum.archlinux.de/u/stefanhusmann</uri> </author> <content type="html">Nach einer Aktualisierung von gtk auf gtk3-1:3.24.27-3, die die <a href="https://github.com/archlinux/svntogit-packages/commit/9f1ec21c5fc3d83273d8b38d2065485bdfd3c97e" rel="noopener noreferrer nofollow">Aktivierung von tracker3 </a>mit sich brachte, kann es zu Datenverlusten für Nutzer der Software kommen.<br /> <br /> Fehlermeldung: <pre><code>Database startup error: Error: SQLITE_NOTADB: file is not a database #4513</code></pre> Wenn man diese Meldung arglos und übereilt wegklickt, ist die entsprechende Datenbank weg (die nämlich entgegen der Meldung durchaus eine ist).<br /> <br /> Das grundsätzliche Problem ist in einem <a href="https://github.com/signalapp/Signal-Desktop/issues/4513" rel="noopener noreferrer nofollow">Upstream-Bugreport </a> beschrieben und betrifft auch MAC-OS und Windows. Bei Arch Linux wurde es durch obenstehende gtk-Änderung virulent. <br /> <br /> Ein Workaround besteht darin, bei gtk auf der Version gtk3-1:3.24.27-2 zu bleiben, oder sogar auf 3.34.26 zurück zu gehen.<br /> <br /> Siehe auch <br /> <br /> <a href="https://lists.archlinux.org/pipermail/arch-general/2021-March/048737.html" rel="noopener noreferrer nofollow">Mailing-Liste arch-general</a><br /> <br /> <a href="https://bugs.archlinux.org/task/69980" rel="noopener noreferrer nofollow"> Arch Linux Bugtracker</a></content> </entry> <entry> <id>https://www.archlinux.de/news/33857</id> <title>mkinitcpio: Schwenk auf Zstandard-Images</title> <updated>2021-02-20T10:37:17+00:00</updated> <link rel="alternate" href="https://www.archlinux.de/news/33857-mkinitcpio-Schwenk-auf-Zstandard-Images"/> <author> <name>stefanhusmann</name> <uri>https://forum.archlinux.de/u/stefanhusmann</uri> </author> <content type="html">Seit linutx-lts bei Version 5.10 angelangt ist, unterstützen alle offiziellen Arch-Linux-Kernel das zstd-Format (Zstandard) für die Kompression von Abbildern. Die momentan im [testing]-Repo befindliche Version 30 macht diese Art Kompression zum Standard.<br /> <br /> Spätestens wenn mkinitcpio Vesion 30 die &#34;normalen&#34; Repos erreicht, kommt folgende Problematik zum Tragen:<br /> <br /> Wer als aus irgendwelchen Gründen einen Kernel vor Version 5.10 verwenden will oder muss, muss in der Datei /etc/mkinitcpio.conf unter COMPRESSION eine unterstützte Methode eintragen, z.B. gzip, und mkinitcpio mit der Option -p aufrufen, sonst wird der Kernel nicht hochfahren.<br /> <br /> Welche unterstützten Methoden es gibt, findet man mit &#34;man mkinitcipo.conf&#34; heraus.</content> </entry> <entry> <id>https://www.archlinux.de/news/33814</id> <title>Chromium verliert die Möglichkeit, Google-Dienste zu nutzen</title> <updated>2021-02-05T20:11:51+00:00</updated> <link rel="alternate" href="https://www.archlinux.de/news/33814-Chromium-verliert-die-Moeglichkeit-Google-Dienste-zu-nutzen"/> <author> <name>stefanhusmann</name> <uri>https://forum.archlinux.de/u/stefanhusmann</uri> </author> <content type="html">Der US-Konzern Google hat verlautbart, dass ab dem 15. März bestimmte Webdienste nur noch vermöge des von Google selbst stammenden Browser Chrome nutzbar sein werden. Dies betrifft Arch Linux&#039; chromium-Paket wie auch das entsprechende Paket aller anderen Linux-Distros, die so etwas anbieten. <br /> <br /> Arch Linux wird wie andere Distros auch der Entscheidung der chromium-Betruer folgen, ab der nächsten Version 89 die ohnehin nicht mehr funktionierenden API-Schlüssel aus dem Paket zu entfernen. Danach wird evaluiert, ob das Anbieten eines derart eingeschränkten chromium-Paket längerfristig Sinn ergibt.</content> </entry> </feed>