Rpi-imager: RPi Imager 1.6.1 (und höher) kann nicht auf Ubuntu 18.04 installiert werden

Erstellt am 29. MĂ€rz 2021  Â·  31Kommentare  Â·  Quelle: raspberrypi/rpi-imager

$ sudo apt install /home/andrew/Downloads/rpi-imager_1.6.1_amd64.deb 
[sudo] password for andrew: 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Note, selecting 'rpi-imager' instead of '/home/andrew/Downloads/rpi-imager_1.6.1_amd64.deb'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies.
 rpi-imager : Depends: libgcc-s1 (>= 3.0) but it is not installable
              Depends: libqt5core5a (>= 5.12.2) but 5.9.5+dfsg-0ubuntu2.5 is to be installed
E: Unable to correct problems, you have held broken packages.

Meine vorhandene Installation von RPi Imager 1.6 funktioniert einwandfrei.

BEARBEITEN : Die neueste Version, die auf Ubuntu 18.04 ausgefĂŒhrt werden kann, ist RPi Imager 1.6.1 – Sie finden einen benutzerdefinierten Build in meinem Kommentar unten .
RPi Imager 1.6.2 (oder neuer) wird nicht fĂŒr Ubuntu 18.04 erstellt.

Hilfreichster Kommentar

UnabhĂ€ngig von Problemen mit Snap-Paketen denke ich immer noch, dass das von https://www.raspberrypi.org/software/ herunterladbare imager_1.6.1_amd64.deb auf Ubuntu 18.04 (das noch bis April 2023 unterstĂŒtzt wird) installierbar sein sollte.
:slightly_srunning_face:

EDIT: Blockiert durch #200

EDIT2: FĂŒr alle anderen, die noch Ubuntu 18.04 verwenden, hier ist ein Build von RPi Imager 1.6.1 nach Anwendung des Patches von #200
Nutzung auf eigene Gefahr: rpi-imager_1.6.1_amd64.zip
(FĂŒhlen Sie sich frei, dieses @maxnet zu löschen, wenn Sie es fĂŒr unangemessen halten)

Alle 31 Kommentare

Ich fĂŒrchte, 20.04 LTS ist ein neues Minimum, weil ich darauf aktualisiert habe. :-)
Sollte jedoch immer noch in der Lage sein, "debuild" von git selbst auszufĂŒhren.

Ich bin mir sicher, dass ich nicht die einzige Person sein kann, die noch Ubuntu 18.04 ausfĂŒhrt :wink: Und obwohl ich debuild ausfĂŒhren kann, bin ich mir sicher, dass es viele weniger technisch versierte Benutzer gibt, die das nicht können?
Könnten Sie in einer VM oder so etwas bauen?

Ich betreue einen Schnappschuss von rpi-imager und habe ihn gerade so erweitert, dass er auf Ubuntu 20.04 aufbaut, aber er kann auch auf Ubuntu 18.04 (tatsÀchlich sogar 14.04 und 16.04) und anderen Distributionen installiert werden.

Als interessanter Datenpunkt zum "Wer lÀuft noch 18.04?" Frage, da ist noch eine ordentliche Zahl drauf. Unter den Benutzern von RPI Imager Snap verwenden ~13 % Ubuntu 18.04, ~56 % Ubuntu 20.04 und sogar ~2,7 % Ubuntu 16.04!

Screenshot_20210331_125839

Sofern https://github.com/popey/imager-snap/issues/8 nicht behoben wurde, unterstĂŒtzt der Snap leider nicht alle Imager-Funktionen. IIRC mĂŒssen Sie auch einige zusĂ€tzliche Berechtigungen aktivieren, um andere Fehler zu vermeiden. Es ist nicht offensichtlich, dass Sie das tun mĂŒssen oder wie. Da der Imager die Dinge vereinfachen soll, scheint der Snap HĂŒrden einzufĂŒhren.

Im Idealfall wĂ€re es großartig, es stattdessen in den normalen apt-Repos zu verwenden.

Es sei denn, popey/imager-snap#8 wurde gelöst

Funktioniert es unter 1.6.1 besser?

Ein Commit ( https://github.com/raspberrypi/rpi-imager/commit/c8409d741939c0af32180c731a86adcdeaba802d ) eingeschlichen, das es möglicherweise umgeht, aber keine Zeit hatte, herauszufinden, wie man einen Snap erstellt, um es zu testen.

Der Code ging bisher davon aus, dass sobald udisks2 (mit dem wir ĂŒber DBus sprechen) uns mitteilt, dass der WechseldatentrĂ€ger (FAT32-Partition) gemountet ist, wir in den Mount-Ordner schreiben können.
Aber zu diesem Zeitpunkt ist es möglicherweise noch nicht in der Snap-Chroot gemountet, die hinterherzuhinken scheint.
Haben Sie also eine ÜberprĂŒfung, die ĂŒberprĂŒft, ob der Mount-Ordner ein Mount-Punkt ist, und bis zu 3 Sekunden verzögert, wenn dies nicht der Fall ist.

Gerade ausprobiert und nein, es scheint schlimmer zu sein. Zuerst hieß es, die Partition könne nicht gemountet werden, also habe ich die entsprechende Berechtigung aktiviert. Gleicher Fehler, also habe ich alle Berechtigungen aktiviert, die deaktiviert waren (obwohl ihre Beschreibungen nicht relevant zu sein schienen) (PEBCAK). Jetzt verhĂ€lt sich der Imager so, als wĂ€re alles gut gegangen, aber die SD-Karte ist am Ende leer.

Qt: Session management error: Could not open network socket
QObject::setParent: Cannot set parent, new parent is in a different thread
Drive: "/org/freedesktop/UDisks2/drives/Generic__USB3_2e0_CRW____SD_201506301013_1"
Device: "/org/freedesktop/UDisks2/block_devices/sdc" belongs to same drive
Device: "/org/freedesktop/UDisks2/block_devices/sdc1" belongs to same drive
Unmounted "/org/freedesktop/UDisks2/block_devices/sdc1" successfully
Repartitioning drive
Telemetry done. cURL status code = 0
Adding partition
New partition: "/org/freedesktop/UDisks2/block_devices/sdc1"
Formatting drive as FAT32
Mounting partition
Mounted new file system at: "/media/shift/F28E-8BF1"
Image URL: "https://github.com/raspberrypi/rpi-eeprom/releases/download/v2020.09.03-138a1-imager/rpi-boot-eeprom-recovery-2020-09-03-vl805-000138a1-usb.zip"
Received header: HTTP/2 302 

Received header: server: GitHub.com
...
Can't create 'README.txt'
Can't create 'pieeprom.bin'
Can't create 'pieeprom.sig'
Can't create 'recovery.bin'
Can't create 'vl805.bin'
Can't create 'vl805.sig'
Hash of compressed multi-file zip: "84b73785a93720621136e23ee766e2e56a516902baaccebe3e055106471029ff"
mountutils: Reading /proc/mounts
mountutils: Mount point /dev/sdc1 belongs to drive /dev/sdc
mountutils: Mount point /dev/sdc1 belongs to drive /dev/sdc
mountutils: Closing /proc/mounts
mountutils: Unmounting /media/shift/F28E-8BF1...
mountutils: Unmount MNT_EXPIRE /media/shift/F28E-8BF1: EAGAIN
mountutils: Unmount MNT_EXPIRE /media/shift/F28E-8BF1 failed: Operation not permitted
mountutils: Unmount MNT_DETACH /media/shift/F28E-8BF1 failed: Operation not permitted
mountutils: Unmount MNT_FORCE /media/shift/F28E-8BF1 failed: Operation not permitted
mountutils: Unmounting /var/lib/snapd/hostfs/media/shift/F28E-8BF1...
mountutils: Unmount MNT_EXPIRE /var/lib/snapd/hostfs/media/shift/F28E-8BF1: EAGAIN
mountutils: Unmount MNT_EXPIRE /var/lib/snapd/hostfs/media/shift/F28E-8BF1 failed: Operation not permitted
mountutils: Unmount MNT_DETACH /var/lib/snapd/hostfs/media/shift/F28E-8BF1 failed: Operation not permitted
mountutils: Unmount MNT_FORCE /var/lib/snapd/hostfs/media/shift/F28E-8BF1 failed: Operation not permitted
Download done in 3 seconds

Insgesamt nicht die Erfahrung, die Sie jedem Benutzer wĂŒnschen wĂŒrden.

„README.txt“ kann nicht erstellt werden

Ist /var/lib/snapd/hostfs/media/shift/F28E-8BF1 nicht fĂŒr den Benutzer beschreibbar, den Snap Imager ausfĂŒhrt als?

UnabhĂ€ngig von Problemen mit Snap-Paketen denke ich immer noch, dass das von https://www.raspberrypi.org/software/ herunterladbare imager_1.6.1_amd64.deb auf Ubuntu 18.04 (das noch bis April 2023 unterstĂŒtzt wird) installierbar sein sollte.
:slightly_srunning_face:

EDIT: Blockiert durch #200

EDIT2: FĂŒr alle anderen, die noch Ubuntu 18.04 verwenden, hier ist ein Build von RPi Imager 1.6.1 nach Anwendung des Patches von #200
Nutzung auf eigene Gefahr: rpi-imager_1.6.1_amd64.zip
(FĂŒhlen Sie sich frei, dieses @maxnet zu löschen, wenn Sie es fĂŒr unangemessen halten)

https://www.raspberrypi.org/documentation/installation/installing-images/README.md sagt auch "Ubuntu 18.04" :wink:

Wenn also RPi Imager Ubuntu 18.04 in Zukunft definitiv nicht mehr unterstĂŒtzen wird, sollten wir diese Dokumentation wohl auch aktualisieren? :zucken:

Also, wenn RPi Imager Ubuntu 18.04 definitiv nicht mehr unterstĂŒtzt

Nicht sicher, was die offizielle Support-Richtlinie ist.

Beachten Sie jedoch, dass die allgemeine NĂŒtzlichkeit von Ubuntu 18 fĂŒr Entwickler rapide abnimmt.

  • Nicht mehr fĂŒr die Webentwicklung verwendbar, da die mitgelieferte PHP-Version Ă€lter ist, als moderne Frameworks akzeptieren.
  • Nicht verwendbar fĂŒr Low-Level-C-Entwicklung. Wenn Sie zB mit dem Raspberry Pico spielen wollen, werden Sie feststellen, dass CMake zu alt ist.
  • Die Qt-Version unterstĂŒtzt eine Reihe neuerer Methoden nicht. Und wenn Sie eine neuere Qt-Version auf anderen Plattformen verwenden, werden Sie sehen, dass es eine Menge "veralteter" Methodenwarnungen auswirft, wenn Sie dort die Ă€lteren Methoden verwenden.

Und Ubuntu 20 LTS ist seit einem Jahr draußen.

Was ist der Grund, warum Sie immer noch 18 verwenden?

Was ist der Grund, warum Sie immer noch 18 verwenden?

Ich habe vor etwas mehr als einem Jahr einen neuen Dell XPS-Laptop gekauft, auf dem Ubuntu 18.04 vorinstalliert war, und ich zögere, ihn auf eine neuere Version zu aktualisieren, zumal es sich immer noch um eine aktiv unterstĂŒtzte LTS-Version handelt. Auch das AusfĂŒhren eines Ă€lteren, aber immer noch unterstĂŒtzten Betriebssystems ist nĂŒtzlich, um GrenzfĂ€lle wie diesen aufzudecken :wink:
FĂŒr Pico-Zeug habe ich mit https://apt.kitware.com/ auf eine neuere Version von CMake aktualisiert. Und wenn ich eine neuere GCC-Version verwenden muss, stelle ich einfach mein lokales Installationsverzeichnis $PATH voran. FĂŒr alles andere gibt es VirtualBox.

LTS-Releases sind „Enterprise-Grade“ und auf StabilitĂ€t ausgerichtet. Sie sind fĂŒr diejenigen, die keine neuen Softwareversionen wollen. Die Software-Updates, die Sie fĂŒr LTS-Releases erhalten, sind nur Sicherheits- und Fehlerbehebungen. Die UnterstĂŒtzung alter Software ist nicht kostenlos, es erfordert Arbeit und schrĂ€nkt Ihre Möglichkeiten ein, voranzukommen. Es ist nicht vernĂŒnftig zu erwarten, dass ein altes LTS ein Jahr nach der Veröffentlichung des aktuellen eine unterstĂŒtzte Plattform bleibt.

Sie sind fĂŒr diejenigen, die keine neuen Softwareversionen wollen.

Ja, das ist eine vernĂŒnftige Position; Ich hĂ€tte kein Problem damit, dass zB RPi Imager 1.7.x nur Ubuntu 20.04+ unterstĂŒtzt, wobei Ubuntu 18.04 auf den Ă€lteren RPi Imager 1.6.x beschrĂ€nkt ist. Es kam mir nur komisch vor, dass der KompatibilitĂ€tsbruch beim Wechsel von 1.6.0 auf 1.6.1 passiert ist
Angesichts der Benutzerebene, auf die sich die Raspberry Pi-Website richtet, ist es unwahrscheinlich, dass die Website sowohl fĂŒr „Ubuntu 20.04+-Benutzer“ als auch fĂŒr „Ubuntu 18.04-Benutzer“ unterschiedliche Download-Optionen anbietet, weshalb ich das vorgeschlagen habe Wann/falls die Entscheidung fĂ€llt, die UnterstĂŒtzung fĂŒr 18.04 einzustellen, muss dies ausdrĂŒcklich in der Dokumentation erwĂ€hnt werden.

:mann_achselzuckend:

Es kam mir nur komisch vor, dass der KompatibilitÀtsbruch beim Wechsel von 1.6.0 auf 1.6.1 passiert ist

Ich stimme zu, dass es seltsam ist, dass dies bei einer Punktveröffentlichung stillschweigend geschieht. Das sollte zumindest dem 1.6.1 Changelog hinzugefĂŒgt werden. Aber weißt du ... es gibt eine einjĂ€hrige Gnadenfrist! Wenn es Sie interessiert, mein XPS (13) lĂ€uft perfekt mit 20.04 :)

UnabhĂ€ngig von Problemen mit Snap-Paketen denke ich immer noch, dass das von https://www.raspberrypi.org/software/ herunterladbare imager_1.6.1_amd64.deb auf Ubuntu 18.04 (das noch bis April 2023 unterstĂŒtzt wird) installierbar sein sollte.
leicht_stirnrunzelndes_gesicht

~EDIT: Blockiert durch #200~

EDIT2: FĂŒr alle anderen, die noch Ubuntu 18.04 verwenden, hier ist ein Build von RPi Imager 1.6.1 nach Anwendung des Patches von #200
Nutzung auf eigene Gefahr: rpi-imager_1.6.1_amd64.zip
(FĂŒhlen Sie sich frei, dieses @maxnet zu löschen, wenn Sie es fĂŒr unangemessen halten)

Vielen Dank. hat fĂŒr mich an Debian Buster gearbeitet, wĂ€hrend der ursprĂŒngliche Download und Snap fehlgeschlagen sind

Nur zur Info, dass dies auch unter ChromeOS ein Problem ist. Wenn Sie den Linux-Entwicklermodus aktiviert haben, funktioniert 1.6.1 von @lurch freigegeben , wÀhrend der Download von https://www.raspberrypi.org/software/ nicht funktioniert.

Zum Nutzen aller, die dieses Problem verfolgen ...

Ich habe gerade versucht, das v1.6.2-Tag auf Ubuntu 18.04 zu kompilieren, und es kann nicht erstellt werden mit:

rpi-imager/main.cpp:250:19: error: ‘class QApplication’ has no member named ‘screenAt’; did you mean ‘screens’?
         if ( !app.screenAt(QPoint(x,y)) || !app.screenAt(QPoint(x+w,y+h)) )
                   ^~~~~~~~
                   screens
rpi-imager/main.cpp:250:49: error: ‘class QApplication’ has no member named ‘screenAt’; did you mean ‘screens’?
         if ( !app.screenAt(QPoint(x,y)) || !app.screenAt(QPoint(x+w,y+h)) )
                                                 ^~~~~~~~
                                                 screens

weil diese Funktion in Qt 5.10 hinzugefĂŒgt wurde, aber Ubuntu 18.04 nur Qt 5.9.5 enthĂ€lt.
Es sieht also so aus, als wĂ€re mein Build von v1.6.1 fĂŒr Benutzer von Ubuntu 18.04 "end of the line" :wink:

Sie sind fĂŒr diejenigen, die keine neuen Softwareversionen wollen.

Nein. Ich verwende LTS, weil ein Upgrade oder die Installation einer neuen Version sehr viel Zeit in Anspruch nimmt. Nach der Installation muss viel modifiziert/optimiert, installiert, eingerichtet usw. werden. Das kostet viel Zeit. Das LTS bietet die Möglichkeit, ein System ĂŒber einen viel lĂ€ngeren Zeitraum zu nutzen. Ab meinem aktuellen 18.04 werde ich Ubuntu nicht mehr verwenden (aber das ist eine andere Geschichte).

Ich verwende mehrere PPAs + einige Appimages. Dinge wie PHP installiere ich selbst.

Ich fĂŒrchte, 20.04 LTS ist ein neues Minimum, weil ich darauf aktualisiert habe. :-)

Ich glaube, dass dieser ganzen „18.04 zu alt“-Diskussion ein riesiges, tieferes Problem mit dem Projekt fehlt: Warum ist der Build-Prozess an Ihre spezielle Version gebunden? Kompilieren und veröffentlichen Sie es _selbst_? VerfĂŒgt rpi-imager nicht ĂŒber eine CI-, PPA-, Github-Aktion oder ein Ă€hnliches Tool fĂŒr einen Cloud-Build-Workflow?

Solange _dass_ Tool 18.04 unterstĂŒtzt (und die Quellen kompatibel sind), sollte das persönliche Betriebssystem von @maxnet irrelevant sein. Ein PPA kann fĂŒr _alle_ aktuellen Ubuntu-Versionen erstellt werden. Travis-CI und Github können fĂŒr viele Plattformen bauen. Sie können sogar Windows fĂŒr die Entwicklung verwenden und die Cloud fĂŒr Fedora, Mac, BSD, ARM erstellen lassen, egal wie alt oder modern die Plattform ist.

Das gesagt...

Solange dieses Tool 18.04 unterstĂŒtzt (und die Quellen kompatibel sind)

1) Quellen werden in Zukunft ohne #ifdef-Magie nicht kompatibel sein.
Neuere Methoden gibt es in alten Qt-Versionen nicht.
Die Verwendung der Àlteren Methoden gibt bei neueren Qt 5-Versionen eine Reihe veralteter Warnungen aus und verschwindet in Qt 6

2) Dies ist eine Anwendung, die zumindest unter Windows und Mac OS X Code-signiert werden muss, und ich bin kein großer Fan davon, Code-SignaturschlĂŒssel mit Cloud-Anbietern zu teilen.

3) WĂŒrde immer noch eine Installation jedes Betriebssystems benötigen, um testen zu können, ob das Ergebnis korrekt funktioniert.
Diese Art von Software (mit Interaktion mit Systemdiensten und physischer Hardware wie SD-Kartenlesern) ist nicht so gut fĂŒr automatisierte Testframeworks geeignet ...

Und Ubuntu 20 LTS ist seit einem Jahr draußen.

Und Ubuntu 18 wird noch zwei ganze Jahre lang unterstĂŒtzt. Dein Punkt?

Beachten Sie jedoch, dass die allgemeine NĂŒtzlichkeit von Ubuntu 18 fĂŒr Entwickler rapide abnimmt.
...
Was ist der Grund, warum Sie immer noch 18 verwenden?

Das ist ... nicht , wie man mit diesem Problem umgeht. Die besonderen GrĂŒnde von @lurch fĂŒr die Verwendung von 18 sollten keine Rolle spielen. Es gibt viele. Da musste man bei Ihnen auf den 20.04 wechseln, wĂ€hrend manche schon auf den 21.10 sprangen.

Es ist nicht vernĂŒnftig zu erwarten, dass ein altes LTS ein Jahr nach der Veröffentlichung des aktuellen eine unterstĂŒtzte Plattform bleibt.

Es ist. Es heißt nicht umsonst LTS ! _Langfristige_ UnterstĂŒtzung .

Es gibt ein Jahr Gnadenfrist!

Falsch. Die „Jahresschonfrist“ wird erst im April 2022 _beginnen_, wo wir _dann_ ein ganzes Jahr bis _2023_ Zeit haben, um auf Ubuntu 22.04 zu migrieren, wobei 20.04 vollstĂ€ndig ĂŒbersprungen wird, wĂ€hrend wir immer noch ein vollstĂ€ndig unterstĂŒtztes System verwenden. Ich möchte _wirklich_ nicht den Aufwand haben, alle 2 Jahre das gesamte Betriebssystem zu aktualisieren

Kommt schon Leute... Ubuntu hat gerade Raspberry vollstĂ€ndig angenommen und veröffentlicht nicht nur eine Server-Edition, sondern auch Desktop, Core, die ganze Familie. Sie haben alle Raspberry-spezifischen Pakete zu ihren Repositories hinzugefĂŒgt, es werden keine PPAs mehr fĂŒr rpi-eeprom oder vcgencmd benötigt.

Bitte unterstĂŒtzen Sie es auch voll und ganz fĂŒr eine lange und glĂŒckliche Ehe :1st_place_medal:

Und Ubuntu 18 wird noch zwei ganze Jahre lang unterstĂŒtzt. Dein Punkt?

„UnterstĂŒtzt“ bedeutet nicht, dass Sie neuere Softwareversionen erhalten.
Alles auf einem Ubuntu 18-System ist die Softwareversion 2018, wobei nur StabilitĂ€ts- und Sicherheitsfixes spĂ€ter als Backports hinzugefĂŒgt werden.
Sie können immer noch Ă€ltere Versionen von Imager darauf ausfĂŒhren, um sie an den Rest des Systems anzupassen.

  1. Dies ist eine Anwendung, die zumindest unter Windows und Mac OS X Code-signiert werden muss, und ich bin kein großer Fan davon, Code-SignaturschlĂŒssel mit Cloud-Anbietern zu teilen.

Bietet Ihnen Raspberry (das Unternehmen / die Organisation) keine _irgendeine_ Infrastruktur oder Anleitung dazu? Ich meine ... IMHO ist rpi_imager eine SchlĂŒsselkomponente im Ökosystem von Raspi. Es ist der _Einstiegspunkt_, es zu benutzen. Es wird auf den offiziellen Websites von _sowohl_ Raspberry als auch Ubuntu als empfohlener Imager prĂ€sentiert.

Nicht sicher, was die offizielle Support-Richtlinie ist.

Angesichts des hohen Bekanntheitsgrades dieses Projekts bin ich wirklich ĂŒberrascht, dass es keine offizielle Richtlinie dazu gibt.

„UnterstĂŒtzt“ bedeutet nicht, dass Sie neuere Softwareversionen erhalten. Alles auf einem Ubuntu 18-System ist die Softwareversion 2018, wobei nur StabilitĂ€ts- und Sicherheitsfixes spĂ€ter als Backports hinzugefĂŒgt werden.

Fairer Punkt, und ich stimme zu. Es macht mir nichts aus, eine veraltete Version zu verwenden, solange meine _aktuelle_ Version weiterhin funktioniert. Und das ist hier nicht passiert.

rpi-imager , installiert von snap , ist gestern aus heiterem Himmel _pleite_ geworden. Es funktionierte nicht mehr, mit den gleichen dmesg Fehlern zu AppArmor Profilen und ausgeblendeten Laufwerken wie @lurch berichtete, was mich hierher fĂŒhrte. Warum wurde eine inkompatible Version auf die 18.04-KanĂ€le hochgeladen?

Fairer Punkt, und ich stimme zu. Ich habe nichts dagegen, eine veraltete Version zu verwenden

Dann können Sie die Àltere 1.6.0 ausprobieren: https://downloads.raspberrypi.org/imager/imager_1.6_amd64.deb

rpi-imager, installiert von snap, brach gerade aus heiterem Himmel aus

Snap-Probleme können hier gemeldet werden: https://github.com/popey/imager-snap/issues
An dieser Version sind wir nicht beteiligt.

Einige möglicherweise relevante Klarstellungen:

rpi-imager , installiert von snap , ist gestern aus heiterem Himmel _pleite_ geworden.

Vielleicht ist es frĂŒher kaputt gegangen. Ich habe es regelmĂ€ĂŸig fĂŒr Motten verwendet, aber immer das gleiche (gecachte) Bild. Gestern habe ich ein paar neue ausprobiert, vielleicht ist das Problem deshalb erst jetzt aufgetreten. Installierte Version ist 1.6.2, und IIRC ist es seit mindestens ein paar Wochen.

Ich habe nichts dagegen, eine veraltete Version zu verwenden

Es ist nicht so, dass es mir egal wĂ€re. Ich mache. Aber ich bin mir bewusst, dass ich zu nichts _berechtigt_ bin. Ich wĂŒnschte nur, einige Projekte wĂŒrden einen konservativeren Ansatz verfolgen, wenn es darum geht, neue APIs zu ĂŒbernehmen, die Ă€ltere (aber immer noch nicht EOL-)Versionen beschĂ€digen könnten.

Ich zum Beispiel mache viel Python-Entwicklung und stehe oft vor dem gleichen Dilemma: Wenn es in Python 3.9 ein neues, großartiges Feature gibt, verwende ich es nicht, selbst wenn ich bereits bei Python 3.11 bin, weil Ă€ltere Distributionen es mögen CentoOS wird immer noch mit dem alten 3.6 ausgeliefert. Zumindest haben sie 3.8 _verfĂŒgbar_, also kann ich meine minimale Quellversion darauf erhöhen. Kann man hier Ă€hnlich vorgehen?

Wenn ich tiefer in die Protokolle eintauche, glaube ich, dass wir es hier mit zwei verschiedenen, unabhÀngigen Problemen zu tun haben:

  • Irgendwie bin ich (und war es immer) in der Lage, nicht nur 1.6.1, sondern 1.6.2 von Snap aus zu installieren und zu starten. Was auch immer @popey getan hat, um es fĂŒr 18.04 zu kompilieren, hat funktioniert, GlĂŒckwunsch! Dies deutet darauf hin, dass meine Fehler bezĂŒglich AppArmor beim Schreiben von Bildern nichts mit PaketabhĂ€ngigkeiten oder QT-Kompilierungsproblemen beim Erstellen von .deb zu tun haben (um die es bei _diesem_ Problem anscheinend geht), obwohl sich beide in 18.04 manifestieren

  • Bei meinem Problem, und anscheinend auch bei @XECDesign , geht es um _permissions_, und es sieht so aus, als wĂ€re dies ein reines Snap-Problem . Also werde ich mich wie angewiesen dorthin bewegen.

FĂŒr alle, die hierher kommen und Probleme wie _„Eine AppArmor-Richtlinie hindert diesen Absender daran, diese Nachricht zu senden 
“_, _„Netzwerk-Socket konnte nicht geöffnet werden“_ oder _„Vorgang nicht zulĂ€ssig“_ haben, gehen Sie zu dieser Ausgabe , nicht hier. Es gibt nur viele Probleme mit 18.04 im Titel :-)

in der Lage, nicht nur 1.6.1, sondern 1.6.2 von Snap aus zu installieren und zu starten. Was auch immer @popey getan hat, um es fĂŒr 18.04 zu kompilieren, hat funktioniert, GlĂŒckwunsch!

Ich denke, Snap ist ein "in sich geschlossenes" Verpackungsformat? Es ist also wahrscheinlich möglich, eine neuere Version der Qt-Bibliotheken einzuschließen, als sie in Ubuntu 18.04 enthalten sind? (was die .deb Version von RPi Imager verwenden mĂŒsste)

Snap-Probleme können hier gemeldet werden: https://github.com/popey/imager-snap/issues
An dieser Version sind wir nicht beteiligt.

@maxnet Wir scheinen einige Problemmeldungen ĂŒber die Snap-Version von RPi Imager zu erhalten (wahrscheinlich, weil das die Version ist, die Ubuntus "Software Store" installiert), gegen die wir offensichtlich nichts unternehmen können. Vielleicht lohnt es sich, die Issue-Template-Funktion von GitHub zu nutzen, um Leute, die Probleme mit der Snap-Version von RPi Imager haben, direkt zu Popeys Repo zu leiten? :zucken:

Die Àltere Version 1.6.0 (referenziert von @maxnet) installierte sich gut auf Linux Mint 19.3 (bionic repo). Vielen Dank

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen