Du bist nicht angemeldet.
Ah, prima, ich Danke Dir!
Schönen Rest-Sonntag
Joo
Ich bin haawda. Das gepostete PKGBUILD funktioniert bei mir, allerdings habe ich mich bei den Abhängigkeiten auf namcap verlassen und sie rigoros entfernt. Die eine oder andere mag als optdepend sinnvoll sein.
Sehr cool! Hat geklappt. Scribus meckert zwar, dass ein Plugin fehlen würde, aber damit kann ich wunderbar leben.
Und wenn ich es richtig verstanden habe, soll ich die Lösung hier posten, richtig?
https://aur.archlinux.org/packages/scribus-stable/
Oder hat sich das mit dem Beitrag von haawda am 2021-01-23 21:36 erledigt? Ich muss gestehen, dass ich mit seinem Post wenig anfangen kann.
Vielen, vielen Dank für Eure Hilfe!
Beste Grüße,
Joo
zo7Thohr,
-SET(MANDIR "${CMAKE_INSTALL_DATAROOTDIR}/man/")
+SET(MANDIR "${CMAKE_INSTALL_PREFIX}/man/")Solche Sachen kann man mit -DCMAKE_INSTALL_DATAROOTDIR beim Aufruf von cmake mitgeben. Dann muss man nichts patchen.
Gibt es eigentlich eine Möglichkeit die Aufnahme eines bestimmten Programms als Binary in die Repositorys "in Auftrag" zu geben?
Nein. Inbesondere nicht bei diesem Paket, denn es war in den Repos und wurde aus guten Gründen entfernt. Steht auch in den AUR-Kommentaren zum Paket.
...und so sähe dann der Patch aus:
diff -u a/CMakeLists.txt b/CMakeLists.txt
--- a/CMakeLists.txt 2019-03-05 23:44:45.000000000 +0100
+++ b/CMakeLists.txt 2021-01-23 19:26:37.152160551 +0100
@@ -275,7 +275,7 @@
#Setp all the directories we will use
#MAN
CMAKE_POLICY(SET CMP0005 OLD)
-SET(MANDIR "${CMAKE_INSTALL_DATAROOTDIR}/man/")
+SET(MANDIR "${CMAKE_INSTALL_PREFIX}/man/")
IF(WANT_VERSIONING)
SET(SHAREDIR "${CMAKE_INSTALL_DATAROOTDIR}/${MAIN_DIR_NAME}${TAG_VERSION}/")
ELSE(WANT_VERSIONING)und dann ins build-Verzeichnis als "mandir.patch" speichern und im PKGBUILD mit
prepare() {
cd "$pkgname-$pkgver"
patch -p1 -i ../../mandir.patch
}aufrufen.
Es ist doch etwas anders als ich zunächst dachte... src/scribus-1.4.8/install_manifest.txt befindet sich nicht in den Quellen sondern wird während des build-Prozesse erstellt. Die eigentliche Änderung müsste in src/scribus-1.4.8/CMakeLists.txt vorgenommen werden, und zwar an dieser Stelle:
SET(MANDIR "${CMAKE_INSTALL_PREFIX}/man/")Damit ist das Ziel das übergeordnete Verzeichnis, wie es auch der symbolische Link darstellt.
Dazu muss man aber erst die Quellen mit "makepkg -o" entpacken, die Korrektur vornehmen und dann mit der Option "-e" (damit das Quellarchiv nicht wieder entpackt und die Änderung überschrieben wird) bauen.
Im Paket standen danach die Dateien an der richtigen Stelle, installiert habe ich es aber nicht, weil ich es nicht brauche, aber versuche es mal so.
Wenn es funktioniert, müsste der AUR-Betreuer daraus einen Patch machen und ihn im PKGBUILD und in der prepare-Section aufrufen -> Bugreport!
scribus: /usr/local/share/man existiert im Dateisystem (gehört zu filesystem)
Da hat pacman Recht und der Paketierer Mist gebaut. /usr/local/share/man wird vom Paket "filesystem" angelegt und ist ein symbolischer Link auf /usr/local/man. Deswegen kann das Paketmanagement das Verzeichnis nicht anlegen. Richtigerweise müssten die Dateien bei der Installation in das reale Verzeichnis /usr/local/man kopiert werden.
Das Ziel für die Kopie wird in src/scribus-1.4.8/install_manifest.txt festgelegt. Das sind nur drei Eintragungen:
/usr/local/share/man/man1/scribus.1
/usr/local/share/man/de/man1/scribus.1
/usr/local/share/man/pl/man1/scribus.1Die könnte man bequem über einen Patch auf das richtige Verzeichnis umbiegen (oder vor Kompilation manuell ändern), und dann müsste es passen
Ich habe nun auf einem anderen Rechner noch einmal den Buid durchlaufen lassen (danke für Deinen Hinweis zo7Thohr) und sieh mal einer guck, ein fertiges Paket - allerdings brach die Installation per pacman -U dann mit der folgenden Meldung ab:
Fehler: Konnte den Vorgang nicht durchführen (In Konflikt stehende Dateien)
scribus: /usr/local/share/man existiert im Dateisystem (gehört zu filesystem)
Fehler sind aufgetreten, keine Pakete wurden aktualisiert.Ein Schritt vor - ein Schritt zurück... grmpf
Clean Chroot klingt nicht nach Spaß, aber vermutlich muss man sich da einmal durch quälen, wenn man weiter kommen will. Gucke ich mir morgen einmal an.
Gibt es eigentlich eine Möglichkeit die Aufnahme eines bestimmten Programms als Binary in die Repositorys "in Auftrag" zu geben?
Laut den Kommentaren im AUR geht hier gar nichts ohne ein Clean Chroot.
Der Maintainer bietet aber auch ein fertiges Paket in dem neuesten angehefteten Kommentar an.
Die letzte Alternative könnte die Verwendung eines Flatpaks sein. "Letzte", weil ich Flatpacks, Appimages, Snaps und dergleichen eigentlich für eine Pest halte.
Keine Ahnung, warum das bei dir nicht läuft, hier sieht es so aus:
==> Erstelle Paket: scribus 1.4.8-0 (Sa 23 Jan 2021 14:05:25 CET)
==> WARNUNG: Überspringe Abhängigkeits-Prüfungen.
==> Empfange Quellen...
-> Lade scribus-1.4.8.tar.gz herunter...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 78.8M 100 78.8M 0 0 5642k 0 0:00:14 0:00:14 --:--:-- 5775k
==> Überprüfe source Dateien mit md5sums...
scribus-1.4.8.tar.gz ... Übersprungen
==> Entpacke Quellen...
-> Entpacke scribus-1.4.8.tar.gz mit bsdtar
==> Beginne prepare()...
==> Beginne build()...
CMake Warning (dev) at CMakeLists.txt:662:
Syntax Warning in cmake code at column 25
Argument not separated from preceding token by whitespace.
This warning is for project developers. Use -Wno-dev to suppress it.
CMake Deprecation Warning at CMakeLists.txt:8 (CMAKE_MINIMUM_REQUIRED):
Compatibility with CMake < 2.8.12 will be removed from a future version of
CMake.
Update the VERSION argument <min> value or use a ...<max> suffix to tell
CMake that the project does not need compatibility with older versions.
CMake Warning (dev) at /usr/share/cmake-3.19/Modules/GNUInstallDirs.cmake:223 (message):
Unable to determine default CMAKE_INSTALL_LIBDIR directory because no
target architecture is known. Please enable at least one language before
including GNUInstallDirs.
Call Stack (most recent call first):
CMakeLists.txt:38 (INCLUDE)
This warning is for project developers. Use -Wno-dev to suppress it.
-- The C compiler identification is GNU 10.2.0
-- The CXX compiler identification is GNU 10.2.0...und dann geht es normal weiter mit der Komipaltion und bauen des Pakets.
Ich wüsste auch nicht, was der Maintainer da noch ändern könnte, denn das PKGBUILD funktioniert. Ich bekomme zwar auch Warnungen, die verhindern aber nicht, dass das Paket erstellt wird.
Der PKGDEST-Fehler ist übrigens ein Bug in yay -> https://github.com/Jguer/yay/issues/590
Ja, die Meldung mit dem qt4 habe ich natürlich auch bekommen und dann die gleiche Lösung wie zo7Thohr gewählt und es manuell aud dem AUR instaliert.
Im Anschluss lande ich dann halt bei dem eingangs geposteten Error-Log.
Danke für das Posten des Bugs, ich hab eben einmal nachgesehen, der Maintainer hat sich leider noch nicht gemeldet.
Ich habe es eben noch einmal über yay -S scribus-stable versucht. Das endet aber auch in einer Fehlermeldung:
==> Entpacke Quellen...
-> Entpacke scribus-1.4.8.tar.gz mit bsdtar
==> Beginne prepare()...
==> Quellen sind fertig.
could not find PKGDEST for: scribus-stableDer Build von scribus-stable 1.4.8 aus dem AUR läuft hier auch ohne Abbruch:
==> Erstelle Paket "scribus"...
-> Erstelle .PKGINFO Datei...
-> Erstelle .BUILDINFO Datei...
-> Erstelle .MTREE-Datei...
-> Komprimiere Paket...
==> Verlasse fakeroot Umgebung.
==> Beendete Erstellung: scribus 1.4.8-0 (Fr 22 Jan 2021 23:04:10 CET)Das PKGBUILD für die Version 1.4.7 gibt es hier -> https://projects.archlinux.de/svntogit/ … 089bb98551
Eine Version 1.4.8 gab es lt. History nicht, sondern die nächste Version war direkt 1.5.3, die fehlende Abhängigkeit "qt4" war hier noch installiert, kann man aber auch aus dem AUR beziehen. Danach ließ sich das Paket fehlerfrei erstellen.
Ich kriege das Paket aktuell nicht gebaut ...
Found unsuitable Qt version "5.15.2" from /usr/bin/qmake, this code
requires Qt 4.x
Call Stack (most recent call first):
CMakeLists.txt:587 (FIND_PACKAGE)Ich habe jetzt einen Bug gemeldet. Hoffentlich reagiert der Maintainer zeitnah.
Ansonsten schaue ich mal, ob ich was woanders finde.
VLG
Stephan