Ich habe folgendes in PKGBUILD
prepare() {
patch --forward --strip=1 --input="${startdir}/patchfile.patch"
}
Bei ausführen von makepkg -si && cd /tmp wird angezeigt
==> Starting prepare()...
can't find file to patch at input line 4
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
|diff -upr ffDiaporama.r0/src/ffDiaporama/wgt_QMultimediaBrowser/QCustomFolderTable.cpp ffDiaporama.r1/src/ffDiaporama/wgt_QMultimediaBrowser/QCustomFolderTable.cpp
|--- ffDiaporama.r0/src/ffDiaporama/wgt_QMultimediaBrowser/QCustomFolderTable.cpp 2014-02-09 09:47:04.000000000 +0000
|+++ ffDiaporama.r1/src/ffDiaporama/wgt_QMultimediaBrowser/QCustomFolderTable.cpp 2022-09-03 09:49:31.314912000 +0000
File to patch:
Wie ist die Zeile in prepare() zu ändern damit man nach der Datei die geändert werden soll nicht gefragt wird?

Dir dürfte in prepare() einfach das einleitende
cd "pkgname-$pkgver"
fehlen. (Bzw. ggf nur "$pkgname" je nachdem wie du arbeitest)

Ohne das cd befindest du dich in dort_wo_PKGBUILD_ist/src und da liegen die ausgepackten Quellen i.d.R. nicht¹, sondern darin gibt es noch das $pkgname_Verzeichnis. (Tip: du kannst in die Funktionen auch Dinge wie echo oder pwd für dich zum Debuggen einbauen)

Ob dann die zu patchende Datei gefunden wird hängt vom --strip ab, also von wo aus du das diff erstellt hast.
Hinweis: In den folgenden Pfadbeispielen ist ./ am Anfang das Verzeichnis in dem dein PKGBUILD liegt.
Mit deinem --strip=1 wird momentan für ffDiaporama.r0/src/ffDiaporama/wgt_QMultimediaBrowser/QCustomFolderTable.cpp nur der Teil "ffDiaporama.r0" vom Pfad entfernt, die zu pachende Datei würde also in:
./src/src/ffDiaporama/wgt_QMultimediaBrowser/QCustomFolderTable.cpp
erwartet (was wahrscheinlich auch nicht stimmt IMHO). Da müßtest du mit den --strip= Werten probieren.

--strip=1 sollte eigentlich immer dann passen, wenn man den diff im ./src Verzeichnis zieht und sich darin vom ausgepackten Paket-Folder z.B. ein .org/.new oder wie du ein .r0/.r1 ziehst.

//edit:
¹Natürlich liegen dort die ausgepackten Quellen, aber ein Source-Tarball hat meist ein $pkgname oder pkgname-$pkgver als "Startpunkt". Kann man z.B. mit:
tar --list -f source.tar.gz | head -1
sehen.

Noch ein Hinweis:
Wenn du deine Ausgaben (z.B. von der Ausgabe in deinem 1.Post) in Code-Tags setzt, werden diese wesentlich lesbarer...

Um Änderungen an einziger Datei vorzunehmen funktioniert folgendes
prepare() {
patch ${srcdir}/ffDiaporama/src/ffDiaporama/wgt_QMultimediaBrowser/QCustomFolderTable.cpp ${startdir}/patchfile.patch
}

vmp hat das Thema gelöst hinzugefügt ().

Bei mir hatte die Option in prepare()
cd "pkgname-$pkgver"
nicht funktioniert weil da
cd ffDiaporama
stehen sollte.

Und warum hast du es dann nicht einfach auf:
cd "ffDiaporama" geändert?

Ich vermute ffDiaporama ist ein "Ding" von dir, ggf. temporär, und nicht der Paketname oder als Pfad im Source-Tarball enthalten.
Dann würde ich das eher als Variable im PKGBUILD definieren, z.B.
_pkgdir="ffDiaporama"
und diese dann überall dort nutzen wo du das brauchst, also in prepare() dann
cd "_pkgdir"

//Edit: _srcdir wäre "logischer"....<g>

$startdir sollte man gar nicht mehr verwenden, stattdessen $srcdir.
Ich verwende meist patch -Np1 < "$srcdir"/_patchfile_
also mit Dateiumleitung.

Wie definiert man eine Variable in PKGBUILD?
Hier die Lösung
_pkgname="ffDiaporama"
cd "$_pkgname"

$pkgdesc ist für Packetbeschreibung
_pkgname="ffDiaporama" wäre besser als _pkgdir="ffDiaporama" zu definieren.
Wenn man das Program entpackt dann wird das Verzeichnis ffDiaporama erzeugt (mit großem D) der Programname bei pacman lautet aber ffdiaporama (klein d).

Wenn ihr schon dabei seid, das PKGBUILD zu verbessern, hätte ich auch etwas einzubringen.
@vmp, wenn du was am PKGBUILD änderst, ohne dass es eine Versionsänderung des Programmes gibt, solltest du pkgrel um eins erhöhen. Dann bekommen das zumindest diejenigen mit, welche das AUR-Paket mit einem Package Manager installiert haben oder auf andere Weise die Paketversion auf Updates überprüfen.

Und nochmal ein paar Anmerkungen:

a) Im aktuellen PKGBUILD von ffdiaporama solltest du deinen Patch ins source-Array aufnehmen. IMHO ist das für alle Quellen/patches/Zusatzfiles so üblich. Diese können/sollten dann auch mit aktuellen Checksummen drinstehen (Integrität der Dateien die von deinem AUR-Paket kommen). Auch bei der Namenswahl des Patches könntest du etwas genauer sein(plus ggf. Kommentar warum der nötig ist).
Wenn du das machst, dann ist deine Patchquelle im PKGBUILD dann nicht:
--input="${startdir}
sondern --input="${srcdir}
Weiterhin ist im Tarball noch eine Datei ffmpeg3.0.patch enthalten. Warum? Wird die für irgendwas gebraucht? Die würde ich rausnehmen aus dem ganzen Archiv wenn das geht.

b) Die Abhängigkeiten. Die hatte ich im anderen Thread ja angemeckert.
Für ffmpeg21 hast du dessen PKGBUILD ja angepaßt. Danke!
Für x264_152 installierst du aber weiterhin noch nach /usr/local ! No Go! Das solltest du auch noch anpassen (Und ggf. andere Pakete im AUR bei denen du Maintainer bist)

Den ganzen Komplex "ffDiaporama"+Abhängigkeiten solltest du halt nochmal genau abarbeiten, und dann wie @krisz schrieb für alle abschließend die pkgrel erhöhen damit die Strukturänderungen auch bei deinen Usern ankommen.

ffmpeg063 läst sich nicht nach /opt verschieben, weil dort schon ffmpeg21 ihren Platz hat.
Ich würde die Datei ffmpeg3.0.patch noch behalten falls man es später für irgend etwas noch braucht, speichert man sie auf dem eigenen Rechner und die Festplatte geht kaputt dann ist sie weg.
Zu den übrigen zwei Programmen versucht man das Übersetzungsprogramm nach /opt zu verschieben dann erscheint es nicht mehr bei Applications und das Video Programm dürfte an /usr gebunden sein.
Da ffDiaporama in pkgrel=1 sich anfangs nicht bauen ließ würde ich pkgrel auf 2 nicht ändern.

  • Dirk hat auf diesen Beitrag geantwortet.

    vmp ffmpeg063 läst sich nicht nach /opt verschieben, weil dort schon ffmpeg21 ihren Platz hat.

    Was spricht dagegen, /opt/ffmpeg063 und /opt/ffmpeg21 zu verwenden?

      Wenn man ffmpeg in einem nicht Standardverzeichnis installiert (z.B. ffmpeg21) gibt es für die include Dateien für die Konsole dafür eine Variable (wie LD_LIBRARY_PATH) um dem zu kompielierenden Program diese mitzuteilen.
      Es geht darum versuche ich das Program zu Fuß zu kompilieren (für meine Belange) mit
      qmake-qt5 'QMAKE_CFLAGS_ISYSTEM=-I' 'INCLUDEPATH += /opt/ffmpeg21/include' 'LIBPATH += /opt/ffmpeg21/lib' ffDiaporama.pro PREFIX=/usr
      dann make ergibt
      In file included from ./engine/cApplicationConfig.h:42,
      from ./engine/_Transition.h:80,
      from ./engine/_Diaporama.h:26,
      from MainWindow/cCustomSlideTable.h:26,
      from MainWindow/mainwindow.cpp:21:
      ./engine/cDeviceModelDef.h:56:10: fatal error: libavutil/audioconvert.h: No such file or directory
      56 | #include <libavutil/audioconvert.h>
      er findet die ganzen haeder Dateien in dem Verzeichnis ffmpeg21 nicht

      • GerBra hat auf diesen Beitrag geantwortet.

        vmp gibt es für die include Dateien für die Konsole dafür eine Variable (wie LD_LIBRARY_PATH) um dem zu kompielierenden Program diese mitzuteilen

        Kurze Antwort: Das brauchst du nicht.

        Ich bin zwar kein Programmierer, kenne mich aber etwas mit den Tools aus.

        Vorweg: Du mißverstehst den Sinn von LD_LIBRARY_PATH. Diese Anweisung hat nichts mit "Compilieren" oder "Paketbauen" zu tun.
        Sie dient nur dem Zweck ein dynamisch gelinktes Programm anzuweisen in einem anderen/zusätzlichen Pfad nach notwendigen SharedLibraries (Unix: *.so, Windows: *.dll) zu suchen bzw. diese zu verwenden. Kurz: der ld.so lädt dynamisch Libraries entweder aus dem im Programm fest verankerten Pfad und/oder aus dem Standard-Pfad(//lib->/usr/lib). Durch das setzen dieser Variablen vor Programmstart wird das Programm nun angewiesen ggf. ganz andere oder zusätzliche Pfade zu verwenden.
        Die Notwendigkeit so etwas tun zu müssen zeigt im "normalen" Gebrauch von Programmen eher das "etwas faul" ist.
        Wie gesagt: Das hat aber nichts mit den Schritten zu tun die in einem PKGBUILD vorkommen.
        Ein IMHO guter Artikel (englisch) über Zweck,Sinn,Probleme durch LD_LIBRARY_PATH

        Build-Systeme, Compiler, Linker erlauben eigentlich immer zusätzliche Pfade für Include-Dateien bzw. SharedLibs direkt beim Aufruf, also als Option mitzugeben.
        Du nutzt das z.B. in deinem PKGBUILD für ffDiaporama:
        qmake-qt5 'QMAKE_CFLAGS_ISYSTEM=-I' 'INCLUDEPATH += /opt/ffmpeg21/include' 'LIBPATH += /opt/ffmpeg21/lib' ffDiaporama.pro
        Hier setzt du direkt andere Pfade als z.B. im qmake-Project(*.pro) angegeben sind.
        Das du ein paar Zeilen darüber LD_LIBRARY_PATH setzt und auch noch exportierst ist IMHO nicht notwendig und der export auch "unschön" in einem PKGBUILD.

        Also für alle gcc, ld, make, cmake qmake Programme im build() vom PKGBUILD am besten immer die jeweiligen direkten Programm-Optionsparameter für z.B. Include und Libraries verwenden.
        Das Setzen/Nutzen von Umgebungsvariablen aus/in das Environment des (AUR)Users sollte man nicht tun bzw. ist immer irgendwann ein Problem.

        Hier noch ein Leitfaden für diverse Build-Systeme und die Nutzung für/im PKGBUILD:
        https://wiki.archlinux.org/title/Arch_package_guidelines
        https://wiki.archlinux.org/title/Arch_package_guidelines#Additional_guidelines