piwo2 Posted June 7, 2023 at 04:23 PM Share Posted June 7, 2023 at 04:23 PM 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 ... Quote Link to comment Share on other sites More sharing options...
piwo2 Posted June 7, 2023 at 04:25 PM Author Share Posted June 7, 2023 at 04:25 PM p.s. voraus geht folgender build (der das .deb liefert anstandslos : python3 build_src.py && python3 build_pkg.py Quote Link to comment Share on other sites More sharing options...
photron Posted June 7, 2023 at 04:40 PM Share Posted June 7, 2023 at 04:40 PM 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/ Quote Link to comment Share on other sites More sharing options...
piwo2 Posted June 8, 2023 at 09:56 AM Author Share Posted June 8, 2023 at 09:56 AM 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. Quote Link to comment Share on other sites More sharing options...
photron Posted June 9, 2023 at 10:12 AM Share Posted June 9, 2023 at 10:12 AM 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. Quote Link to comment Share on other sites More sharing options...
piwo2 Posted June 10, 2023 at 07:16 PM Author Share Posted June 10, 2023 at 07:16 PM (edited) 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 Edited June 10, 2023 at 07:43 PM by piwo2 Quote Link to comment Share on other sites More sharing options...
rtrbt Posted June 12, 2023 at 07:01 AM Share Posted June 12, 2023 at 07:01 AM 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 Quote Link to comment Share on other sites More sharing options...
photron Posted June 12, 2023 at 12:39 PM Share Posted June 12, 2023 at 12:39 PM Warum fürhst du brickv als root aus? Das sollte nicht notwendig sein. Quote Link to comment Share on other sites More sharing options...
piwo2 Posted June 13, 2023 at 11:46 AM Author Share Posted June 13, 2023 at 11:46 AM (edited) ... schon mal versucht einen brick zu flashen OHNE sudo/root ? das serial-device wird dir was pfeifen ... Edited June 13, 2023 at 11:47 AM by piwo2 Quote Link to comment Share on other sites More sharing options...
rtrbt Posted June 13, 2023 at 11:55 AM Share Posted June 13, 2023 at 11:55 AM Füg dich mal der dialout-Gruppe hinzu: https://www.tinkerforge.com/de/doc/Software/Brickv.html#flashen Quote Link to comment Share on other sites More sharing options...
piwo2 Posted June 13, 2023 at 06:27 PM Author Share Posted June 13, 2023 at 06:27 PM (edited) 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 ? Edited June 13, 2023 at 06:31 PM by piwo2 Quote Link to comment Share on other sites More sharing options...
rtrbt Posted June 14, 2023 at 07:32 AM Share Posted June 14, 2023 at 07:32 AM 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. Quote Link to comment Share on other sites More sharing options...
photron Posted June 14, 2023 at 07:45 AM Share Posted June 14, 2023 at 07:45 AM 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.