ich bin noch neu bei Linux allgemein & Manjaro speziell.
Bei meinem Umstieg von Win zu Linux habe mich nicht zuletzt für Manjaro entschieden, weil es als Arch-basiertes System auch das AUR unterstützt, da hier angenehm viel an SW angeboten wird, was bei z.B. Debian-basierten Systemen einfach so nicht angeboten wird.
Entsprechend habe ich das AUR auch in Pamac (GUI-Einstellungen) aktiviert und ein paar für mich interessante Pakete/Apps installiert.
Seit einige Zeit gibt mir die GUI von Pamac allerdings bei "Datenbanken aktualisieren eine Fehlermeldung “Fehler beim Synchronisieren der AUR-Datenbank” zurück; bei “Aktualisierungen → aktualisieren” kommt am Ende die etwas allgemeiner gehaltene Fehlermeldung “Fehler beim Synchronisieren der Datenbanken”.
Updates aus den vier “normalen” Repos werden erkannt und können installliert werden, aus dem AUR klappt das entsprechend nicht.
Über die Kommandozeile in der Konsole (CLI) kann ich allerdings via “sudo pamac update/upgrade -a” auch ein fehlerfreies Update der aus dem AUR stammenden Apps bewerkstelligen - die entsprechenden Programm-Updates werden brav gebaut.
Suche ich mittels Pamac-GUI nach einem Programm und versuche, dieses dann zu installieren, schlägt dieser Versuch mit der Dialogbox “Vorgang konnte nicht erfolgreich vorbereitet werden - Konnte Abhängigkeiten von [App-Name] nicht prüfen” ebenso fehl.
Weiß jemand Hilfe, wie man dieses Problem beheben kann?
Wäre es evtl. eine Lösung, Pamac einmal (z.B. mittels Pacman) komplett zu de- und anschließend wieder neu zu installieren (evtl. bis auf das Paket “pamac-cli”), oder handele ich mir damit voraussichtlich neue / andere / schwerwiegendere Probleme ein?
Tut mir leid, aber die AUR wird weder von ArchLinux noch von Manjaro unterstützt. Mit pamac wird lediglich die Möglichkeit angeboten, es zu benutzen. AUR ist in erster Linie für ArchLinux gemacht, Manjaro hält neue Pakete länger zurück, was dann auch zu Problemen führen kann.
Also AUR, nur wenn es wirklich nötig ist.
Die AUR-Datenbank wird von einem CDN von Manjaro heruntergeladen. Je nachdem wann du herunterlädst (z. B. wenn ein Update des Caches auf dem Server erfolgt), kann es zu dem Problem führen. Einfach später noch mal probieren.
Der Fehler hier ist, dass du es mit sudo ausführst. Pamac fragt selbst nach Root Rechten, wenn nötig. Also wenn du ein Update mit sudo ausführst, dann schreibt pamac die aur datenbank auch mit root. Wenn du nun die Pamac GUI nimmst, dann wird das als aktueller Benutzer geschrieben, ergo: ein normaler Benutzer kann keine Datei, die als root geschrieben wurde, überschreiben. Das führt dann zu deinem Fehler.
Ich korrigiere mich. Die Datei wird für alle mit Lese/Schreib-Rechten geschrieben (666), also sollte es heute kein Problem darstellen, war früher so. Hab es gerade gesehen.
Erst einmal vielen Dank für die prompten Antworten!
Tut mir leid, aber die AUR wird weder von ArchLinux noch von Manjaro unterstützt.
Sorry, ich habe mich vielleicht missverständlich ausgedrückt, daher formuliere ich einmal um: Weil es als auf pkg-Paketen basiert und daher die Möglichkeit bietet, auch SW aus dem AUR zu installieren.
Also AUR, nur wenn es wirklich nötig ist.
Ja, danke. Tatsächlich schaue ich erst einmal, ob ein Paket nicht offiziell unterstützt wird und greife nur zum AUR, wenn das nicht der Fall ist.
Die AUR-Datenbank wird von einem CDN von Manjaro heruntergeladen. Je nachdem wann du herunterlädst (z. B. wenn ein Update des Caches auf dem Server erfolgt), kann es zu dem Problem führen. Einfach später noch mal probieren.
Der Fehler ist in letzter Zeit ab und an mal. Einfach nach einer Weile nochmal probieren.
Das Problem besteht inzwischen bereits ein paar Wochen.
Ich hatte erst einmal mit einem Freund drauf geschaut, der sehr firm in Linux ist, allerdings eher in Debian-basierten Systemen. Der hat im Moment aber leider auch keine Idee mehr.
Da ich erst noch ein paar andere Probleme zu lösen hatte bzw. mich natürlich in viele Themen einarbeiten muss und auch jobmäßig derzeit sehr eingebunden bin, hatte ich das Problem noch etwas vor mir her geschoben.
Ich korrigiere mich. Die Datei wird für alle mit Lese/Schreib-Rechten geschrieben (666), also sollte es heute kein Problem darstellen, war früher so. Hab es gerade gesehen.
Danke für den Hinweis, werde ich mal probieren.
Kann es denn beim Aufruf von pamac (CLI) mit sudo zu Problemen kommen, und wenn ja welcher Art?
Nebenbei gibt es ja beim CLI in der Konsole ja halt gerade kein Problem.
Für mich stellt sich da die Frage, ob pamac_gtk (also die GUI-Variante) und pamac_cli überhaupt auf der gleichen lokalen Datenbasis arbeiten (wovon ich anfangs naiv ausgegangen bin) oder komplett unabhängig voneinander agieren.
Gibt es zwischen diesen beiden Varianten gegenseitige Abhängigkeiten?
“pamac-manager” ist nur die grafische oberfläche für pamac, die sind identisch. pamac und pacman sind aber nicht immer freunde.
empfehlenswert ist es den cache vor dem update mit pacman zu löschen, die Spiegelserver zu aktualisieren, dann das update von pacman ausführen und erst danach mit pamac das update des aur auszuführen.
sudo pacman -Scc
sudo pacman-mirrors -c Germany
# für uns in D häufig schneller als z.bsp. die 5 schnellsten international "sudo pacman-mirrors -f 5"
sudo pacman -Syyu
dann erst
sudo pamac update -a
aktuell solltest du auch die python-abhängigkeiten aktualisieren wie es im thread für das aktuelle stable update beschrieben ist
Print a list of of packages that have files in /usr/lib/python3.10/ :
pacman -Qoq /usr/lib/python3.10/
Rebuild them all at once:*
pamac build $(pacman -Qoq /usr/lib/python3.10)
Note that if any fail to build, you’ll have to rebuild what’s remaining one or a few at a time.
Use rebuild-detector to see if anything else needs to be rebuilt:
“pamac-manager” ist nur die grafische oberfläche für pamac, die sind identisch.
Umso mehr wundert es mich dass die GUI nicht mit dem AUR will, das CLI aber keine Probleme macht.
Wenn beide lokal auf den selben Daten aufsetzen, müssten die doch eigentlich auch gleich gut (oder ggf. halt auch schlecht) bzgl. der Datenbanksynchronisierung funktionieren.
pamac und pacman sind aber nicht immer freunde.
Mit pacman habe ich glaube ich - wenn ich mich recht erinnere - noch gar nicht gearbeitet. Habe mit der Pamac GUI angefangen (in der Standard-KDE-Installation werden einem Updates ja auch gleich in der Statusleiste angezeigt), dann habe ich das CLI getestet, als die GUI nicht mehr zusammen mit dem AUR wollte.
Ich werde Deine Tipps vorsichtshalber trotzdem einmal ausprobieren, vielleicht ändert es ja was (zum Positiven ).
Ich kann dir zumindest sagen, dass bei mir keine Probleme vorliegen. Ob nun GUI oder CLI beides lädt die AUR-Datenbank herunter ohne Zicken.
Anfangs hat die GUI bei mir auch noch funktioniert (vermutlich auch das CLI), ab einem gewissen Punkt nicht mehr.
CLI funktioniert im Gegensatz zur GUI auch jetzt noch.
Klar arbeiten die auf derselben “Datenbasis”
Naja, so klar ist das keineswegs, denn GUI und CLI könnten ja sich jeweils eigene gespiegelte Daten lokal vorhalten - auch wenn die gemeinsame Nutzung natürlich ressourcenschonender ist.
oder verwechselst du die pamac mit pacman? Da ist es eben ein wenig anders.
Nein, soweit hatte ich mich bereits vor der Manjaro-Installation eingelesen, dass mir die Unterschiede (aus Anwendersicht) bewusst sind.
ich hab’ mir schon gedacht, dass ich nicht der Einzige mit dem Problem bin.
Ja, das ist bei mir ähnlich.
(Ich gehe davon aus, dass wir hier über die Pamac GUI - also die grafische Oberfläche - sprechen.)
Meine Erfahrung ist, dass die Pamac-GUI alle Pakete aus den “Standard”-Repos (core, extra, community, multilib) aktualisiert, aber keine Programme, die ich aus dem AUR installiert habe. Entsprechend bleibt auch die Fehlermeldung, dass er beim Synchronisieren des AUR Probleme hat.
Daher meine Fragen:
Hast Du Programme aus dem AUR installiert?
Wenn ja: Werden diese Programme ebenfalls aktualisiert?
Bleibt die Fehlermeldung “Fehler beim Synchronisieren der AUR-Datenbank” bei Dir ebenfalls bestehen, wird also nach einem neuen Synchronisations- bzw. Aktualisierungsversuch wieder ausgegeben?
“Entfallen” die Fehlermeldungen komplett, wenn Du die AUR-Unterstützung in den Einstellungen der Pamac-GUI deaktivierst?
Einen Hinweis hat in die anscheinend richtige Richtung hat aber @megavolt gegeben, auch wenn’s ihm wahrscheinlich nicht bewusst war:
Ich habe daher nun einmal probiert, pamac-cli ohne root-Rechte (also ohne sudo) auszuführen, was folgendes zur Folge hatte:
pamac upgrade --force-refresh ✔
Vorbereitung...
==== AUTHENTICATING FOR org.manjaro.pamac.commit ====
Eine Authentifizierung ist erforderlich, um Pakete zu installieren, aktualisieren oder zu entfernen
Multiple identities can be used for authentication:
1. user1 (usr)
2. user2 (Admin-Konto) (usradmin)
Choose identity to authenticate as (1-2): 1
Password:
==== AUTHENTICATION COMPLETE ====
Synchronisiere Paketdatenbanken...
Aktualisierung von core.db...
Aktualisierung von extra.db...
Aktualisierung von community.db...
Aktualisierung von multilib.db...
Aktualisierung von core.files...
Aktualisierung von extra.files...
Aktualisierung von community.files...
Aktualisierung von multilib.files...
https://aur.manjaro.org/packages-meta-ext-v1.json.gz: Fehler beim Öffnen der Datei »/var/tmp/pamac-build-nob/packages-meta-ext-v1.json.gz.part«: Keine Berechtigung
Fehler beim Synchronisieren der AUR-Datenbank
[...]
Starte ich das Update jedoch mit root-Rechten, kann er auch das AUR aktualisieren und aktualisiert mir auch die Pakete aus dem AUR problemlos:
sudo pamac upgrade --force-refresh ✔ 28s
[sudo] Passwort für user1:
Warnung: Pakete als dynamischer Benutzer bauen
Warnung: Konfiguriere Build-Verzeichnis /var/cache/pamac
Vorbereitung...
Synchronisiere Paketdatenbanken...
Aktualisierung von core.db...
Aktualisierung von extra.db...
Aktualisierung von community.db...
Aktualisierung von multilib.db...
Aktualisierung von core.files...
Aktualisierung von extra.files...
Aktualisierung von community.files...
Aktualisierung von multilib.files...
Aktualisierung von AUR...
Klone drawio-desktop-bin Build-Dateien...
Running as unit: run-u135.service
Schwerwiegend: Kein Git-Repository (oder irgendein Elternverzeichnis bis zum Einhängepunkt /var/cache/private)
Stoppe bei Dateisystemgrenze (GIT_DISCOVERY_ACROSS_FILESYSTEM nicht gesetzt).
Finished with result: exit-code
Main processes terminated with: code=exited/status=128
Service runtime: 109ms
CPU time consumed: 14ms
Running as unit: run-u136.service
Finished with result: success
Main processes terminated with: code=exited/status=0
Service runtime: 104ms
CPU time consumed: 11ms
Running as unit: run-u137.service
Finished with result: success
Main processes terminated with: code=exited/status=0
Service runtime: 402ms
CPU time consumed: 98ms
Generiere drawio-desktop-bin Informationen...
Running as unit: run-u138.service
Finished with result: success
Main processes terminated with: code=exited/status=0
Service runtime: 1.403s
CPU time consumed: 1.504s
Überprüfe drawio-desktop-bin Abhängigkeiten...
Klone keepass-de Build-Dateien...
Running as unit: run-u139.service
Schwerwiegend: Kein Git-Repository (oder irgendein Elternverzeichnis bis zum Einhängepunkt /var/cache/private)
Stoppe bei Dateisystemgrenze (GIT_DISCOVERY_ACROSS_FILESYSTEM nicht gesetzt).
Finished with result: exit-code
Main processes terminated with: code=exited/status=128
Service runtime: 96ms
CPU time consumed: 11ms
Running as unit: run-u140.service
Finished with result: success
Main processes terminated with: code=exited/status=0
Service runtime: 103ms
CPU time consumed: 11ms
Running as unit: run-u141.service
Finished with result: success
Main processes terminated with: code=exited/status=0
Service runtime: 348ms
CPU time consumed: 93ms
Generiere keepass-de Informationen...
Running as unit: run-u142.service
Finished with result: success
Main processes terminated with: code=exited/status=0
Service runtime: 1.200s
CPU time consumed: 1.250s
Überprüfe keepass-de Abhängigkeiten...
Abhängigkeiten werden aufgelöst...
Interne Konflikte werden überprüft...
Zu erstellen (2):
drawio-desktop-bin 21.3.7-1 (21.2.8-1) AUR
keepass-de 2.54-1 (2.53-1) AUR
Build-Dateien bearbeiten : [e]
Transaktion anwenden ? [e/j/N] j
Erstelle drawio-desktop-bin...
Running as unit: run-u143.service
Press ^] three times within 1s to disconnect TTY.
==> Erstelle Paket: drawio-desktop-bin 21.3.7-1 (Sa 10 Jun 2023 14:01:11 CEST)
==> Prüfe Laufzeit-Abhängigkeiten...
==> Prüfe Buildtime-Abhängigkeiten...
==> Empfange Quellen...
-> Lade drawio-desktop-bin-21.3.7.deb herunter...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 102M 100 102M 0 0 4529k 0 0:00:23 0:00:23 --:--:-- 4498k
==> Überprüfe source Dateien mit sha256sums...
drawio-desktop-bin-21.3.7.deb ... Erfolg
==> Entferne existierendes $srcdir/ Verzeichnis...
==> Entpacke Quellen...
-> Entpacke drawio-desktop-bin-21.3.7.deb mit bsdtar
==> Beginne prepare()...
==> Betrete fakeroot Umgebung...
==> Beginne package()...
==> Säubere Installation...
-> Entferne libtool Dateien...
-> Bereinige ungewollte Dateien...
-> Entferne statische Bibliotheken...
-> Entferne unnötige Symbole aus Binär-Dateien und Bibliotheken...
-> Komprimiere Man-Pages und Info-Seiten...
==> Prüfe auf Paketierungsprobleme...
==> Erstelle Paket "drawio-desktop-bin"...
-> Erstelle .PKGINFO Datei...
-> Erstelle .BUILDINFO Datei...
-> Erstelle .MTREE-Datei...
-> Komprimiere Paket...
==> Verlasse fakeroot Umgebung.
==> Beendete Erstellung: drawio-desktop-bin 21.3.7-1 (Sa 10 Jun 2023 14:01:55 CEST)
==> Räume auf...
Finished with result: success
Main processes terminated with: code=exited/status=0
Service runtime: 45.627s
CPU time consumed: 23.754s
Running as unit: run-u144.service
Finished with result: success
Main processes terminated with: code=exited/status=0
Service runtime: 1.214s
CPU time consumed: 1.281s
Erstelle keepass-de...
Running as unit: run-u145.service
Press ^] three times within 1s to disconnect TTY.
==> Erstelle Paket: keepass-de 2.54-1 (Sa 10 Jun 2023 14:01:58 CEST)
==> Prüfe Laufzeit-Abhängigkeiten...
==> Prüfe Buildtime-Abhängigkeiten...
==> Empfange Quellen...
-> Lade KeePass-2.54-German.zip herunter...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 406 100 406 0 0 611 0 --:--:-- --:--:-- --:--:-- 611
100 381 100 381 0 0 142 0 0:00:02 0:00:02 --:--:-- 376
100 45200 100 45200 0 0 16069 0 0:00:02 0:00:02 --:--:-- 12.0M
==> Überprüfe source Dateien mit md5sums...
KeePass-2.54-German.zip ... Erfolg
==> Überprüfe source Dateien mit sha1sums...
KeePass-2.54-German.zip ... Erfolg
==> Entferne existierendes $srcdir/ Verzeichnis...
==> Entpacke Quellen...
-> Entpacke KeePass-2.54-German.zip mit bsdtar
==> Betrete fakeroot Umgebung...
==> Beginne package()...
==> Säubere Installation...
-> Entferne libtool Dateien...
-> Bereinige ungewollte Dateien...
-> Entferne statische Bibliotheken...
-> Entferne unnötige Symbole aus Binär-Dateien und Bibliotheken...
-> Komprimiere Man-Pages und Info-Seiten...
==> Prüfe auf Paketierungsprobleme...
==> Erstelle Paket "keepass-de"...
-> Erstelle .PKGINFO Datei...
-> Erstelle .BUILDINFO Datei...
-> Erstelle .MTREE-Datei...
-> Komprimiere Paket...
==> Verlasse fakeroot Umgebung.
==> Beendete Erstellung: keepass-de 2.54-1 (Sa 10 Jun 2023 14:02:04 CEST)
==> Räume auf...
Finished with result: success
Main processes terminated with: code=exited/status=0
Service runtime: 7.182s
CPU time consumed: 4.656s
Running as unit: run-u158.service
Finished with result: success
Main processes terminated with: code=exited/status=0
Service runtime: 1.700s
CPU time consumed: 1.749s
Überprüfe Schlüsselring... [2/2]
Integrität wird überprüft... [2/2]
Paketdateien werden geladen... [2/2]
Dateikonflikte werden überprüft... [2/2]
Überprüfe verfügbaren Speicherplatz... [2/2]
Starte Pre-Transaction-Hooks...
Creating Timeshift snapshot before upgrade... [1/1]
First run mode (config file not found)
Selected default snapshot type: BTRFS
Using system disk as snapshot device for creating snapshots in BTRFS mode
Mounted '/dev/sda2' at '/run/timeshift/11289/backup'
btrfs: Quotas are not enabled
Creating new backup...(BTRFS)
Saving to device: /dev/sda2, mounted at path: /run/timeshift/11289/backup
Created directory: /run/timeshift/11289/backup/timeshift-btrfs/snapshots/2023-06-10_14-02-07
Created subvolume snapshot: /run/timeshift/11289/backup/timeshift-btrfs/snapshots/2023-06-10_14-02-07/@
Created control file: /run/timeshift/11289/backup/timeshift-btrfs/snapshots/2023-06-10_14-02-07/info.json
BTRFS Snapshot saved successfully (0s)
Tagged snapshot '2023-06-10_14-02-07': ondemand
------------------------------------------------------------------------------
First run mode (config file not found)
Selected default snapshot type: BTRFS
Mounted '/dev/sda2' at '/run/timeshift/11445/backup'
btrfs: Quotas are not enabled
Selected default snapshot device: /dev/sda2
------------------------------------------------------------------------------
Removing snapshot: 2023-06-05_19-31-11
Deleting subvolume: @ (Id:291)
Deleted subvolume: @ (Id:291)
Deleted directory: /run/timeshift/11445/backup/timeshift-btrfs/snapshots/2023-06-05_19-31-11
Removed snapshot: 2023-06-05_19-31-11
------------------------------------------------------------------------------
GRUB-Konfigurationsdatei wird erstellt …
Thema gefunden: /usr/share/grub/themes/manjaro/theme.txt
Linux-Abbild gefunden: /boot/vmlinuz-6.2-rt-x86_64
initrd-Abbild gefunden: /boot/intel-ucode.img /boot/initramfs-6.2-rt-x86_64.img
Found initrd fallback image: /boot/initramfs-6.2-rt-x86_64-fallback.img
Linux-Abbild gefunden: /boot/vmlinuz-6.1-x86_64
initrd-Abbild gefunden: /boot/intel-ucode.img /boot/initramfs-6.1-x86_64.img
Found initrd fallback image: /boot/initramfs-6.1-x86_64-fallback.img
Warnung: Zur Erkennung anderer bootfähiger Partitionen wird os-prober ausgeführt.
Dessen Ausgabe wird zur Erkennung bootfähiger Programmdateien und Erzeugen neuer Boot-Einträge verwendet.
Windows Boot Manager auf /dev/sda1@/EFI/Microsoft/Boot/bootmgfw.efi gefunden
Bootmenü-Eintrag für UEFI-Firmware-Einstellungen wird hinzugefügt …
Detecting snapshots ...
Found snapshot: 2023-06-10 14:02:07 | timeshift-btrfs/snapshots/2023-06-10_14-02-07/@ | ondemand | {timeshift-autosnap} {created before upgrade} |
Found snapshot: 2023-06-10 13:59:23 | timeshift-btrfs/snapshots/2023-06-10_13-59-23/@ | ondemand | {timeshift-autosnap} {created before upgrade} |
Found snapshot: 2023-06-05 22:43:09 | timeshift-btrfs/snapshots/2023-06-05_22-43-09/@ | ondemand | {timeshift-autosnap} {created before upgrade} |
Found 3 snapshot(s)
Unmount /tmp/grub-btrfs.AQQ2tIEY3A .. Success
Found memtest86+ image: /boot/memtest86+/memtest.bin
Found memtest86+ EFI image: /boot/memtest86+/memtest.efi
abgeschlossen
Erneuere keepass-de (2.53-1 -> 2.54-1)... [1/2]
Erneuere drawio-desktop-bin (21.2.8-1 -> 21.3.7-1)... [2/2]
Starte Post-Transaction-Hooks...
Arming ConditionNeedsUpdate... [1/5]
Updating the MIME type database... [2/5]
Refreshing PackageKit... [3/5]
Updating icon theme caches... [4/5]
Updating the desktop file MIME type cache... [5/5]
Vorgang erfolgreich abgeschlossen.
Es sieht also tatsächlich danach aus, dass es ein Rechteproblem ist.
Das werde ich mir die Tage also mal etwas genauer anschauen, auch wenn ich noch nicht ganz genau weiß, welche Dateien ich mir hier genau anschauen muss und wie ich die Rechte dann sinnvoll setzen muss.
Zudem gibt es - wenn man sich die Angaben anschaut - offenbar noch eine zweite Schwierigkeit, die ich mir anschauen sollte, die aber anscheinend die Builds nicht zu verhindern scheint, nämlich:
Schwerwiegend: Kein Git-Repository (oder irgendein Elternverzeichnis bis zum Einhängepunkt /var/cache/private)
Stoppe bei Dateisystemgrenze (GIT_DISCOVERY_ACROSS_FILESYSTEM nicht gesetzt).
Finished with result: exit-code
Aber eines nach dem anderen.
Für Hinweise, für welche Dateien ich die Rechte wie ändern sollte, um das AUR-Problem zu beheben, wäre ich dankbar.
Es handelt sich eindeutig um ein Problem der Zugriffsrechte:
Wenn ich versuche, über das CLI ein Programm aus dem AUR ohne sudo (also ohne root-Rechte) zu installieren, schlägt dies ebenfalls mit einer Meldung über unzureichende Zugriffsrechte fehl.
Gebe ich hingegen
sudo pamac install <AUR_paketname>
ein, läuft die Installation problemlos durch.
Interessant ist dabei, dass ich beim Suchen die Option “-a” für das Einbeziehen des AUR in die Suchte nicht eingeben muss, d.h. der Befehl
pamac search <suchstring>
findet auch Pakete aus dem AUR.
Meine Vermutung wäre hier, dass die’s nicht notwendig ist, weil ich in der pamac-GUI die AUR-Unterstützung eingeschaltet habe.
Warum pamac jetzt für das AUR nur noch mit root-Rechten funktioniert, ist mit derzeit leider noch nicht ganz klar.
Die Rechte der Datei “packages-meta-ext-v1.json.gz” (auf die nicht zugegriffen werden kann, wenn ich pamac-CLI ohne root-Rechte aufrufe und AUR-bezogene Aktionen starte) sehen wir folgt aus:
Es gab seit ein paar Tagen wieder Probleme, beim Aktualisieren einer AUR Software (FreeFileSync). Dann habe ich im Pamac “Datenbank aktualisieren” gemacht, danach haben die Updates wieder geklappt und jetzt ist alles ok.
So, das Problem scheint gelöst (hatte nur in den letzten Tagen/Wochen zu wenig Zeit).
Ich hab’ mir das Problem nach dem Hinweis von @weingeist noch einmal zusammen mit einem (mit Linux vertrautem) Freund näher angeschaut, woraufhin dieser meinte, das Verzeichnis /var/tmp/pamac-build-nob
wohl von einem User angelegt worden sei, der mit dieser UID nicht mehr existiert oder dessen UID geändert wurde.
Da fiel mir ein, dass ich zu Beginn einmal meine (aus Netzwerkfreigabe-Gründen) UID an die UID im NAS angepasst hatte. Das war zwar fast zu Beginn der Manjaro-Einrichtung, aber eben nur fast - ich hatte zuvor wohl in der Pamac-GUI bereits die AUR-Unterstützung angeschaltet, um ein wenig im AUR zu stöbern, wodurch offenbar besagtes Verzeichnis angelegt wurde - aber halt mit der alten User-ID.
Der Ordner gehört nun wieder mir, das Verhalten ist wieder normal / erwartungsgemäß:
Die Fehlermeldungen sind seitdem verschwunden.
SW aus dem AUR lässt sich wieder problemlos installieren.
Updates aus dem AUR gab es bislang noch nicht - ich nehme aber an, dass auch diese nun wieder funktionieren.
pamac-cli funktioniert nun auch wieder ohne sudo/root-Rechte, auch die “Aktualisierung von AUR...” (z.B. durch: pamac upgrade --force-refresh) erfolgt ohne Murren.
Mein besonderer Dank für die zielführenden und wissenserweiternden gehen in diesem Thread an @megavolt für den Hinweis, dass pamac-cli keine root-Rechte (mehr) benötigt, sowie an @weingeist für den Hinweis auf User & Gruppe - und last not least @Michi , der mir das Gefühl gab, mit dem Fehler nicht ganz alleine dazustehen.
