pearOS NiceC0re 25.12 is now available for download based on Arch Linux and featuring a highly customized KDE Plasma desktop environment to mimic the macOS look and feel.
The post pearOS Is Back, Now Based on Arch Linux and Featuring the KDE Plasma Desktop appeared first on 9to5Linux - do not reproduce this article without permission. This RSS feed is intended for readers, not scrapers.
Wenn ihr Spotify unter Linux mit GNOME nutzt, habt ihr vielleicht in den letzten Tagen einen unschönen blauen Rahmen um das Anwendungsfenster bemerkt. Ich sehe das Problem hier bei mir unter Arch Linux, es dürfte aber alle Distributionen betreffen.
Schuld daran ist ein Update des offiziellen Linux-Clients auf Electron-Basis, das die GTK-Style-Window-Decoration durcheinandergebracht hat. Die Funktionalität von Spotify bleibt zwar unverändert, optisch sieht es aber alles andere als schick aus.
Es gibt zwei einfache Wege, um das Problem zu beheben. Die bequemste Variante ist, Spotify als Flatpak zu installieren. Die Flatpak-Version zeigt den blauen Rahmen nicht und ihr müsst euch um nichts kümmern. Änderungen an der Konfiguration sind nicht nötig.
Falls ihr Spotify hingegen über den Spotify Launcher (Paket spotify-launcher aus den Extra-Quellen von Arch) oder direkt aus dem AUR (Eintrag spotify) installiert habt, müsst ihr das Start-Flag --ozone-platform=x11 setzen. Damit wird die GTK-Dekoration korrekt angezeigt. Je nach Installationsart fügt ihr das Flag wie folgt ein:
Für AUR-Spotify in der Datei ~/.config/spotify-flags.conf:
--ozone-platform=x11Für Spotify Launcher in ~/.config/spotify-launcher.conf:
[spotify]
extra_arguments = ["--ozone-platform=x11"] Eventuell müsst ihr diese Dateien erst anlegen. Nach einem Neustart von Spotify sollte der blaue Rahmen verschwunden sein und alles wieder normal aussehen.
Korrektur von Fabian auf Mastodon: Das stimmt so nicht. Das ist ganz alleine dem geschulded das Spotify Wayland-nativ läuft und dort, unter GNOME, eine clientseitige Dekoration (CSD) braucht, die es über diese blaue bereit stellt. Das ganze wieder zu X11 zwingen schafft eventuell echte Probleme, wie verschwommene Schriften, schlechtes (kein) scaling und so weiter. Spotify ist auch nicht Elektron, sondern Chromium Embedded Framework (CEF).
Klar, es ist eine Krücke, aber eine die derzeit hilft. Die Änderung lässt sich ja auch schnell wieder rückgängig machen. Die anderen Optionen wären, Gnome unter X11 zu betreiben oder sich mit den blauen Rahmen anzufreunden. Beides in meinen Augen auch nicht gerade optimal. So ist es erstmal ein Workaround, den man natürlich nicht vergessen sollte, falls sich Spotify irgendwann einmal wieder komisch verhält.
Arch Linux 2025.11.01 is now available for download as the November 2025 ISO snapshot, along with the Archinstall 3.0.12 menu-based installer.
The post Arch Linux’s November 2025 ISO and Archinstall 3.0.12 Installer Are Out Now appeared first on 9to5Linux - do not reproduce this article without permission. This RSS feed is intended for readers, not scrapers.
Arch Linux 2025.07.01 is now available for download as Arch Linux’s ISO release for July 2025, powered by Linux kernel 6.15 and featuring an improved installation experience.
The post First Arch Linux ISO Release Powered by Linux 6.15 Is Now Available for Download appeared first on 9to5Linux - do not reproduce this article without permission. This RSS feed is intended for readers, not scrapers.
Archinstall 3.0.2 Arch Linux menu-based installer is now available with support for the Wayfire Wayland compositor, Btrfs improvements, disk partitioning enhancements, and more.
The post Arch Linux Installer Archinstall Gets Support for the Wayfire Wayland Compositor appeared first on 9to5Linux - do not reproduce this article without permission. This RSS feed is intended for readers, not scrapers.
Arch Linux 2022.02.01 is now available for download as the first Arch Linux ISO image powered by the latest and greatest Linux 5.16 kernel series. This release also includes all the updates and security patches released in January 2021.
The post First Arch Linux ISO Powered by Linux Kernel 5.16 Is Now Available for Download appeared first on 9to5Linux - do not reproduce this article without permission. This RSS feed is intended for readers, not scrapers.
Arch Linux-based Garuda Linux kicks off 2022 with a new release featuring the return of the Cinnamon edition, a new Btrfs Assistant tool, performance improvements, and much more.
The post Garuda Linux Kicks Off 2022 with New Cinnamon Edition, Btrfs Assistant Tool appeared first on 9to5Linux - do not reproduce this article without permission. This RSS feed is intended for readers, not scrapers.
Bei einer Rolling-Release-Distribution wie Arch Linux oder Manjaro spült es nicht nur immer wieder neue Programm- oder Kernel-Versionen in das System, sondern auch wichtige Bibliotheken und Systemkomponenten in deren neusten Ausgaben. So wie heute: Wer gerade das Pacman-Upgrade anwirft, dem installiert der Paketmanager zahlreiche Python-Pakete in der Version 3.10, die Anfang Oktober veröffentlicht wurde. Für Arch-Nutzer gibt es dabei im Endeffekt nicht viel zu beachten, vom Upgrade betroffene Pakete werden automatisch aktualisiert, habt ihr allerdings AUR-Pakete auf dem System, dann müsst ihr diese eventuell neu bauen.
Welche Pakete auf eurem System betroffen sind, ermittelt ihr über das Kommando pacman -Qoq /usr/lib/python3.9. Sollte das System hier ein oder mehrere Namen ausspucken, dann müsst ihr diese über euren AUR-Helper neu erstellen, um in Zukunft Fehler beim Ausführen der entsprechenden Anwendungen auszuschließen. Die schnellste und einfachste Methode dafür ist, die Liste an euren AUR-Helper zu übergeben. Beachtet dazu das zweite Kommando aus dem folgenden Listing. Tauscht den Aufruf des AUR-Helpers, hier paru, gegen das von euch genutzte Programm aus. Zur Kontrolle prüft ihr am Ende, ob es nun keine veralteten Programme mehr gibt.
$ pacman -Qoq /usr/lib/python3.9 chrome-gnome-shell [...] python-pympress python-vlc setzer sunflower $ pacman -Qoq /usr/lib/python3.9 | paru -S - --rebuild $ pacman -Qoq /usr/lib/python3.9 Fehler: Kein Paket besitzt /usr/lib/python3.9
Die Aktion ist bei allen Systemen nötig, die auf Arch Linux aufsetzen und das AUR integrieren. Dazu gehören natürlich Arch Linux selbst sowie äußerst beliebte Derivate wie Manjaro, aber auch eher Exoten wie ArcoLinux, Chakra oder KaOS. Eine Liste der zahlreichen Arch-Linux-Derivate pflegt das Arch Wiki. Auch wird es nicht das letzte Mal sein, dass die Python-Anwendungen aus dem AUR neu gebaut werden müssen, da nächste Python-Update kommt bestimmt.
Das Open-Source-Universum rund um freie Software ist schier unüberschaubar geworden. Seit Jahrzehnten angewachsen, gibt es Programme für so gut wie jeden Zweck. Unter Linux lassen sich viele dieser Anwendungen über die Paketverwaltung komfortabel installieren und aktuell halten, doch keine Distribution integriert jede Software in ihre Repositories. Schon alleine die offiziellen Paketquellen unterscheiden zwischen Paketen, die direkt von den Entwicklern der Distribution betreut werden (Arch: Core und Extra, Ubuntu: Main) und Paketen, die von der Community gepflegt werden (Arch: Community, Ubuntu: Universe). In der Praxis macht das für den Nutzer der Distribution in der Regel jedoch kaum einen Unterschied.
Sehr neue Entwicklungen und gerade frisch gestartete Software-Ideen müssen hingegen entweder von Hand oder über aus von den Projekten betrieben Paketquellen integriert werden — wenn es denn überhaupt welche gibt. Nur Arch Linux geht hier wieder einen komplett eigenen Weg, das Arch User Repository oder kurz AUR vereinfacht die Installation fremder Software ganz wesentlich. Wer Arch Linux oder eines seiner Derivate wie etwa Manjaro noch nicht kennt, dem sagt das AUR vielleicht noch nichts: Im Vergleich zu herkömmlichen Paketquellen pflegt das AUR keine Binärpakete, sondern lediglich eine Sammlung von Kochrezepten, die dem System per Skript erklären, wie sich eine Software optimal in das Arch-System integrieren lässt.
Die dafür notwendige PKGBUILD-Datei (hier am Beispiel von Spotify) enthält Informationen, woher die Anwendung herunterzuladen und wie sie zu installieren ist, inklusive einer Reihe von Anpassungen, plus die benötigten Abhängigkeiten aus der Paketverwaltung. So lässt sich so gut wie jedes Programm ohne große Komplikationen installieren, egal ob es die Entwickler nur in Form des Quellcodes, über DEB- oder RPM-Pakete oder statisch gebaute Binaries bereitstellen. Unter Arch lassen sich so sehr einfach proprietäre Anwendungen wie Chrome oder Spotify installieren oder eben auch ganz neue Entwicklungen. Es braucht nur eine Person, die sich mit dem Schreiben einer PKGBUILD-Datei auskennt — und davon gibt es in der Arch-Linux-Community so einige.
Allerdings braucht es wie immer bei Fremdpaketen einen Disclaimer: Die Hürden Änderungen in das AUR einzubringen oder gar AUR-Pakete zu betreuen, sind im Vergleich zu denen in der Karriere eines offiziellen Arch-Entwicklers geringer. Von daher ist es durchaus möglich, dass Menschen mit schlechten Absichten Manipulationen oder gar Malware in das AUR einbringen. 2018 ist das bereits passiert, damals gab es einen Angriff auf den AUR-Eintrag des Acrobat Readers und zweier weiterer PKGBUILDs. Das AUR ist allerdings auch kein wilder Spielplatz für Bastler und Hacker, eine Gruppe von Trusted Users überwacht das Geschehen im AUR, korrigiert Fehler und leitet neue Beitragende an. In der Praxis lässt sich das AUR daher gut nutzen, zur Sicherheit sollte man allerdings immer mal in die PKGBUILD-Dateien sehen und kontrollieren, ob die Software zum Beispiel von den offiziellen Seiten des entsprechenden Projekts geladen wird.
Nun zurück zum Thema: Das AUR ist wie angesprochen kein Selbstläufer. Es enthält selbst keine Software oder fertige Pakete, sondern lediglich Skripte zum Bauen von Arch-Paketen. Der offizielle Installationsweg führt somit über das Auschecken der PKGBUILD-Datei aus dem Github-Repository des AUR, danach kontrolliert ihr die PKGBUILD und baut im letzten Schritt letztlich mit makepkg -si das Paket. Der Schalter -i am Ende installiert das am Ende erstellte Paket, dabei werden automatisch die im PKGBUILD definierten Abhängigkeiten aus der Paketverwaltung nachgezogen. Alle während dieses Prozesses heruntergeladenen und gebauten Daten braucht ihr am Ende nicht mehr, daher führte ich diese Schritte gerne im Ordner /tmp des Systems aus. Es sei denn, ich möchte die Daten auf anderen System wiederverwenden.
$ pacman -S --needed base-devel git $ git clone https://aur.archlinux.org/spotify.git $ cd spotify $ less PKGBUILD ### Mit [Q] beenden $ makepkg -si
Es gibt viele Arch Nutzer, die generell diesen Weg gehen, so behalten sie die volle Kontrolle über den Vorgang. Allerdings gibt es spätestens dann beim Bauen der AUR-Pakete Probleme, wenn diese selbst zusätzliche Pakete aus dem AUR benötigen. Benötigen diese zusätzlichen Pakete wieder andere Pakete aus dem AUR, wird es arg kompliziert. Aus diesem Grund gibt es eine Reihe von Programmen, AUR-Helper genannt, die den Nutzer bei der Installation von AUR-Paketen unterstützen. Sie automatisieren die oben genannten Schritte und lösen Abhängigkeiten automatisch auf, sodass sich die Installation von Paketen aus dem AUR oft nicht anders anfühlt, als die Installation von Software aus den offiziellen Paketquellen. In der Regel übernehmen die AUR-Helper sogar die Syntax des Arch-Linux-Paketmanagers Pacman.
### AUR-Helper wie Yay oder Pacaur erleichtern die Arbeit ### mit Software aus dem Arch User Repository: $ yay -S spotify $ pacaur -S spotify $ paru -S spotify ### Beim Update kann man sich das 'pacman -Syu' sparen. ### Die AUR-Helper übernehmen die Syntax von Pacman und ### rufen neben den eigen Update auch die aus der Paket- ### verwaltung ab. $ yay -Syu $ pacaur -Syu $ paru -Syu
In der Geschichte der AUR-Helper gibt es immer mal wieder ein hin und her. Bis vor ein paar Jahren war Yaourt (Yet another AUR Helper) das Maß aller Dinge: Das Programm war das einzige, das AUR-Abhängigkeiten automatisch auflöste und vor allen Dingen alle Interaktionen mit dem Nutzer vor dem Build-Vorgang klärte, sodass das eigentliche Bauen später ohne Unterbrechungen in einem Rutsch erfolgte. Eine große Erleichterung, da das Bauen manche Pakete durchaus längere Zeit in Anspruch nimmt, besonders wenn diese aus dem Quellcode kompiliert werden. Doch mit der Version 1.9 stellte der Yaourt-Entwickler seine Arbeit ein, wodurch Pacaur zum Liebling der Nutzer wurde. Bis auch hier wieder der Entwickler goodbye sagte und Yay der Quasi-Standard wurde, auch wenn Pacaur inzwischen einen neuen Betreuer gefunden hat. Aktuell liegt Paru in der Gunst der User am höchsten und liegt im AUR-Ranking ganz vorne.
Was ist allerdings immer wieder merke: Kein AUR-Helper ist perfekt. Yay erhält zum Beispiel regelmäßig Updates (zuletzt erschien das Update auf Yay 11.0.2 Mitte Oktober 2021), doch ich stelle immer wieder fest, dass das Programm in bestimmten Situationen scheitert. Aktuell bricht Yay zum Beispiel das Bauen von Spotify ab, da Prüfsummen nicht stimmen würden. Von Hand oder mit Pacaur lässt sich das Spotify-Paket jedoch ohne Probleme erstellen. Zudem wird Yay in Go entwickelt, das auf der Festplatte bald 500 MByte belegt (Tipp: Yay über das Binary yay-bin installieren). Auf einem schlanken System würde ich daher eher zu Paru oder Pacaur greifen. Letzteres hat aber auch wieder den Nachteil, dass die Entwicklung trotz eines neuen Projektbetreuers eher still steht. Die letzte Version ist vor über zwei Jahren freigegeben worden.
$ yay -S spotify
[...]
grep: spotify-1.1.72.439-Release: No such file or directory
sha256sum: spotify-1.1.72.439-x86_64-Packages.sha256: no properly formatted checksum lines found
==> ERROR: A failure occurred in prepare().
Aborting...
-> error making: spotify
Ideal ist es daher in meinen Augen einen Mix an AUR-Helpern auf einem Arch-System bereitzuhalten und bei Fehlern im Build-Prozess erst einmal einen anderen AUR-Helfer zu testen, bevor man sich auf die Fehlersuche begibt oder gar einen Kommentar unter dem AUR-Eintrag im Repository hinterlässt. Bei mir hat schon mehrmals Yay einen Fehler ausgespuckt, während Pacaur ohne Problem das PKGBUILD abarbeitete und anders herum. Ich persönlich empfehle schon alleine aufgrund des schlankeren Unterbaus generell Paru und Pacaur, wobei Paru euer Hauptprogramm sein sollte — nicht ohne Grund ist Paru das am häufigsten installierte Paket aus dem AUR. Pacaur spielt bei mir die zweite Geige, ist aber immer ein gutes Backup. Yay versuche ich inzwischen zu vermeiden, auch wenn das Kommando yay -Syu bei mir im Gedächtnis eingebrannt ist.
### Installation von Paru $ sudo pacman -S --needed base-devel $ git clone https://aur.archlinux.org/paru.git $ cd paru $ makepkg -si
### Installation von Yay: $ pacman -S --needed base-devel git $ git clone https://aur.archlinux.org/yay.git $ cd yay $ makepkg -si ### Alternativ Yay als Binary: $ git clone https://aur.archlinux.org/yay-bin.git $ cd yay-bin $ makepkg -si
### Installation von Pacaur: $ pacman -S --needed base-devel git $ git clone https://aur.archlinux.org/pacaur.git $ cd pacaur $ makepkg -si
Ich sehe gerade, dass in zahlreichen Foren Nutzer mit Arch Linux auf dem Rechner aufschlagen, bei denen das Update vom über das AUR installiertem Spotify klemmt — Vermutlich dürften auch Manjaro und andere Arch-Derivate mit der Thematik kämpfen. Der Hintergrund ist dabei nicht weiter tragisch: Spotify hat einfach nur den GPG-Schlüssel geändert, mit denen die Entwickler ihre Pakete signieren. Dadurch scheitert der Download beziehungsweise die Überprüfung des Downloads und der AUR-Helper bricht das Update des Spotify-Pakets ab.
$ yay -Syu [...] :: PGP keys need importing: -> F9A211976ED662F00E59361E5E3C45D7B312C643, required by: spotify ==> Import? [Y/n] :: Importing keys with gpg... gpg: Keine gültigen OpenPGP-Daten gefunden. gpg: Anzahl insgesamt bearbeiteter Schlüssel: 0 -> problem importing keys
Um das Problem nun möglichst einfach zu lösen, macht ihr einfach ein Terminalfenster auf. Danach löscht ihr den obsoleten Schlüssel aus dem System und importiert den neuen GPG-Key der Entwickler von der Spotify-Webseite. Anschließend leert ihr den Cache des AUR-Helpers Yay (war zumindest bei mir nötig) und spielt dann alle anstehenden Updates ein. Diesmal sollte die Aktion ohne Fehler in einem Rutsch durchlaufen. Generell habe ich schon öfters festgestellt, dass Spotify gerne seine Schlüssel ändert, behaltet die Lösung daher also im Hinterkopf.
$ gpg --delete-key 8FD3D9A8D3800305A9FFF259D1742AD60D811D58 $ curl -sS https://download.spotify.com/debian/pubkey_5E3C45D7B312C643.gpg | gpg --import - $ yay -Sc $ yay -Syu
Überhaupt lohnt sich bei bockigen AUR-Paketen auch immer ein Blick auf die AUR-Seite des entsprechenden Pakets. Im Fall von Spotify wird die Lösung dort bereits ausführlich diskutiert. Schaut bei den Beiträgen auch immer auf das Datum des jeweiligen Kommentars: Oben unter „Pinned Comments“ sind immer wieder angestaubte Beiträge mit deutlich veralteten Informationen fixiert — je nach Engagement des Paketbetreuers. Erst unter den „Latest Comments“ findet ihr die neusten Kommentare mit aktuellen Hinweisen bei Problemen oder Schwierigkeiten.
