dpk build fedora error ***DRINGEND***

[piwo2]

bisher habe ich den brickv ohne probleme bauen können

jezt :

# dpkg-deb -x ${k}_all.deb deb

building Debian package
dpkg-buildpackage: info: source package tinkerforge-brickv
dpkg-buildpackage: info: source version 2.4.25
dpkg-buildpackage: info: source distribution stable
dpkg-buildpackage: info: source changed by Matthias Bolte <matthias@tinkerforge.com>
dpkg-buildpackage: info: host architecture amd64
 dpkg-source --before-build .
dpkg-checkbuilddeps: error: Unmet build dependencies: debhelper-compat (= 10)
dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
dpkg-buildpackage: warning: (Use -d flag to override.)
Traceback (most recent call last):
  File "/home/rotten/TRPM/brickv-2.4.25/src/build_pkg.py", line 264, in <module>
    exit_code = main()
                ^^^^^^
  File "/home/rotten/TRPM/brickv-2.4.25/src/build_pkg.py", line 252, in main
    build_linux_pkg()
  File "/home/rotten/TRPM/brickv-2.4.25/src/build_pkg.py", line 141, in build_linux_pkg
    utils.build_debian_pkg()
  File "/home/rotten/TRPM/brickv-2.4.25/src/build_pkg_utils.py", line 206, in build_debian_pkg
    system(['dpkg-buildpackage', '-us', '-uc'], cwd=self.build_data_dest_path)
  File "/home/rotten/TRPM/brickv-2.4.25/src/build_pkg_utils.py", line 33, in system
    subprocess.check_call(command, **kwargs)
  File "/usr/lib64/python3.11/subprocess.py", line 413, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['dpkg-buildpackage', '-us', '-uc']' returned non-zero exit status 3.

-------------------

FEDORA 37 scheint keine dbhelper-compat zu haben

mein bisheriger trick, eure deb mittels debian-tools zu kompilieren und dann anschliessend die binaries "rauszuziehen"

instf=( lib/udev/rules.d/99-tinkerforge-brickv.rules usr/bin/brickv usr/share/applications/brickv.desktop usr/share/pixmaps/brickv-icon.png )
        instd=( usr/share/brickv )
        for i in "${instf[@]}" ; do [ -f "deb/$i" ] || continue ; ii="$(dirname "$i")" ; [ -d "/$ii" ] || continue ; done
        for i in "${instd[@]}" ; do [ -d "deb/$i" ] || continue ; ii="$(dirname "$i")" ; [ -d "/$ii" ] || continue ; done
        for i in "${instf[@]}" ; do ii="$(dirname "$i")"
          echo cp "deb/$i" "/$ii" ; sudo cp "deb/$i" "/$ii" ; done
        for i in "${instd[@]}" ; do ii="$(dirname "$i")"
          if [ -d "/$i" ] ; then echo rm "/$i" ; sudo rm -rf "/$i" ; fi
          echo cp "deb/$i" "/$ii" ; sudo cp -r "deb/$i" "/$ii" ; done

schlägt fehl ....

entweder bitte diese expliziten dependencies mit -d irgendwie managbar machen, oder bitte für fedora / redhat mal eine gute anleitung zum build from source - nicht über dpkg -

ICH MÖCHTE NICHT BETONEN, WIE SEHR ICH DEN BRICKV BRAUCHE, NACHDEM ICH DIE AKTUELLE (ALTE) VERSION NICHT MEHR HABE ...

[piwo2]

p.s.

voraus geht folgender build (der das .deb liefert anstandslos :

python3 build_src.py && python3 build_pkg.py

[photron]

Fedora 37 scheint debhelper 13 zu haben. 

Teste bitte mal diese Änderung, die die Anforderung für debhelper abschwächt als schnelle Lösung:

diff --git a/src/build_data/linux/brickv/debian/control b/src/build_data/linux/brickv/debian/control
index bff8b534..f57ed506 100644
--- a/src/build_data/linux/brickv/debian/control
+++ b/src/build_data/linux/brickv/debian/control
@@ -2,7 +2,7 @@ Source: tinkerforge-brickv
 Section: electronics
 Priority: optional
 Maintainer: Matthias Bolte <matthias@tinkerforge.com>
-Build-Depends: debhelper-compat (= 10)
+Build-Depends: debhelper (>= 10)
 Standards-Version: 4.1.3
 Homepage: https://www.tinkerforge.com/

 

[piwo2]

 

no deal - meckert jetzt anders ...

 

building Debian package
dpkg-buildpackage: info: source package tinkerforge-brickv
dpkg-buildpackage: info: source version 2.4.25
dpkg-buildpackage: info: source distribution stable
dpkg-buildpackage: info: source changed by Matthias Bolte <matthias@tinkerforge.com>
dpkg-buildpackage: info: host architecture amd64
 dpkg-source --before-build .
dpkg-checkbuilddeps: error: Unmet build dependencies: debhelper (>= 10)
dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
dpkg-buildpackage: warning: (Use -d flag to override.)
Traceback (most recent call last):
  File "/home/rotten/TRPM/brickv-2.4.25/src/build_pkg.py", line 264, in <module>
    exit_code = main()
                ^^^^^^
  File "/home/rotten/TRPM/brickv-2.4.25/src/build_pkg.py", line 252, in main
    build_linux_pkg()
  File "/home/rotten/TRPM/brickv-2.4.25/src/build_pkg.py", line 141, in build_linux_pkg
    utils.build_debian_pkg()
  File "/home/rotten/TRPM/brickv-2.4.25/src/build_pkg_utils.py", line 206, in build_debian_pkg
    system(['dpkg-buildpackage', '-us', '-uc'], cwd=self.build_data_dest_path)
  File "/home/rotten/TRPM/brickv-2.4.25/src/build_pkg_utils.py", line 33, in system
    subprocess.check_call(command, **kwargs)
  File "/usr/lib64/python3.11/subprocess.py", line 413, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['dpkg-buildpackage', '-us', '-uc']' returned non-zero exit status 3.

====================

       patch build_pkg_utils.py <<EOFEOF
206c206
<         system(['dpkg-buildpackage', '-us', '-uc'], cwd=self.build_data_dest_path)
---
>         system(['dpkg-buildpackage', '-d', '-us', '-uc'], cwd=self.build_data_dest_path)
EOFEOF

d.h. build ohne dependencies : ergebnis :

building Debian package
dpkg-buildpackage: info: source package tinkerforge-brickv
dpkg-buildpackage: info: source version 2.4.25
dpkg-buildpackage: info: source distribution stable
dpkg-buildpackage: info: source changed by Matthias Bolte <matthias@tinkerforge.com>
dpkg-buildpackage: info: host architecture amd64
 dpkg-source --before-build .
 fakeroot debian/rules clean
dh clean
dh: error: Please specify the compatibility level in debian/compat or via Build-Depends: debhelper-compat (= X)
make: *** [debian/rules:4: clean] Fehler 255
dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned exit status 2
Traceback (most recent call last):
  File "/home/rotten/TRPM/brickv-2.4.25/src/build_pkg.py", line 264, in <module>
    exit_code = main()
                ^^^^^^
  File "/home/rotten/TRPM/brickv-2.4.25/src/build_pkg.py", line 252, in main
    build_linux_pkg()
  File "/home/rotten/TRPM/brickv-2.4.25/src/build_pkg.py", line 141, in build_linux_pkg
    utils.build_debian_pkg()
  File "/home/rotten/TRPM/brickv-2.4.25/src/build_pkg_utils.py", line 206, in build_debian_pkg
    system(['dpkg-buildpackage', '-d', '-us', '-uc'], cwd=self.build_data_dest_path)
  File "/home/rotten/TRPM/brickv-2.4.25/src/build_pkg_utils.py", line 33, in system
    subprocess.check_call(command, **kwargs)
  File "/usr/lib64/python3.11/subprocess.py", line 413, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['dpkg-buildpackage', '-d', '-us', '-uc']' returned non-zero exit status 2.

 

[photron]

Ich habe das jetzt in Fedora 37 ausprobiert. Das debhelper Package hat Probleme, dpkg findet es nicht, auch wenn es installiert ist. Zusätzlich ist es dann auch noch kaputt, es fehlt das dh_strip_nondeterminism Skript.

Damit es überhaupt geht hab ich dh_strip_nondeterminism einfach durch einen Symlink erzeugt:

ln -s /usr/bin/true /usr/bin/dh_strip_nondeterminism

Neu im git ist jetzt die --dpkg-no-check-builddeps Option, damit dpkg die Probleme mit dem debhelper Package ignoriert. So kann ich jetzt auf Fedora 37 wieder das Debian Package bauen:

./build_pkg.py --dpkg-no-check-builddeps

Nimm bitte die Änderung zurück, die ich die vorher genannt hatte, update auf den aktuellen git Stand und probier es nochmal aus.

[piwo2]

ok. funkt.

kleine frage noch :

ich sehe schon länger, dass ein "sudo brickv" offensichtlich eine andere gui erzeugt als "brickv".
die fehlende XDG_RUNTIME_DIR mittels "sudo XDG_RUNTIME_DIR=/run/user/0 brickv" zu spezifizieren ändert nichts ....

darüber hinaus wirft "brickv" bei mir folgenden fehler :

"qt.qpa.qgnomeplatform.theme: The desktop style for QtQuick Controls 2 applications is not available on the system (qqc2-desktop-style). The application may look broken."
..... und so sieht es auch aus : vollkommen unleserlich ....

würde mich nur grundsätzlich interessieren, wie beides zustande kommt, bzw. ob da mit fedora-37 (cinnamon desktop) was zu tun ist.

lg wolfgang

bearbeitet June 10, 2023 at 19:43 von piwo2

[rtrbt]

Eigentlich sollte

On 6/10/2023 at 9:16 PM, piwo2 said:

"qt.qpa.qgnomeplatform.theme: The desktop style for QtQuick Controls 2 applications is not available on the system (qqc2-desktop-style). The application may look broken."

kein Problem sein, da der Brick Viewer nicht QtQuick sondern QtWidgets benutzt. Du kannst z.B. mal versuchen, die Verwendung des Fusion-Styles (oder jedes beliebigen anderen) zu verwenden mit

sudo QT_STYLE_OVERRIDE=fusion brickv

 

Eventuell hilft das hier?: https://wiki.archlinux.org/title/qt#Theme_not_applied_to_root_applications

 

[photron]

Warum fürhst du brickv als root aus? Das sollte nicht notwendig sein.

[piwo2]

... schon mal versucht einen brick zu flashen OHNE sudo/root ?
das serial-device wird dir was pfeifen ...

bearbeitet June 13, 2023 at 11:47 von piwo2

[rtrbt]

Füg dich mal der dialout-Gruppe hinzu: https://www.tinkerforge.com/de/doc/Software/Brickv.html#flashen

[piwo2]

dies wird beim installationsprozess automatisch gemacht, wenn man den "normalen" user als admin deklariert ...

mag heissen, member von dialout ist der fall ...

[rotten@vlap-wp ~]$ grep dialout /etc/group
dialout:x:18:rotten

der /dev/ACM1 (oder wie er auch immer heisst, nagel mich nicht fest) der das flash-device unter fedora ist, spielt offensichtlich beim dialout nicht mit
tty* schon ...

genügt das ?

bearbeitet June 13, 2023 at 18:31 von piwo2

[rtrbt]

Letzte Idee die ich noch habe: Je nach Distribution kann die Gruppe anders heißen. Unter Arch z.B. uucp statt dialout. Du kannst mit ls -l /dev/ttyACM1 (o.Ä.) nachsehen welcher Gruppe die Datei gehört.

[photron]

Ich habe das unter Fedora 37 (Live System) getestet und es verhält sich genau so wie unter Debian. Der Brick im Bootloader taucht als /dev/ttyACM0 auf und gehört root und der Gruppe dialout. Wenn ich den liveuser der Gruppe dialout hinzufüge klappt der Zugriff als User wie erwartet.