Rpi-imager: RPi Imager 1.6.1 (dan di atasnya) tidak dapat diinstal di Ubuntu 18.04

Dibuat pada 29 Mar 2021  ·  31Komentar  ·  Sumber: 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.

Instalasi RPi Imager 1.6 saya yang ada berfungsi dengan baik.

EDIT : Versi terbaru yang dapat berjalan di Ubuntu 18.04 adalah RPi Imager 1.6.1 - Anda dapat menemukan custom build di komentar saya di bawah .
RPi Imager 1.6.2 (atau lebih baru) tidak akan dibuat untuk Ubuntu 18.04.

Komentar yang paling membantu

Terlepas dari masalah apa pun dengan paket Snap, saya masih berpikir bahwa imager_1.6.1_amd64.deb yang dapat diunduh dari https://www.raspberrypi.org/software/ seharusnya dapat diinstal di Ubuntu 18.04 (yang masih didukung hingga April 2023).
:slightly_frowning_face:

EDIT: Diblokir oleh #200

EDIT2: Untuk orang lain yang masih menggunakan Ubuntu 18.04, inilah build dari RPi Imager 1.6.1 setelah menerapkan tambalan dari #200
Gunakan dengan risiko Anda sendiri: rpi-imager_1.6.1_amd64.zip
(jangan ragu untuk menghapus @maxnet ini jika Anda merasa tidak pantas)

Semua 31 komentar

Saya takut 20,04 LTS adalah minimum baru, karena saya memutakhirkan ke itu. :-)
Seharusnya masih dapat menjalankan "debuild" dari git sendiri.

Saya yakin saya tidak bisa menjadi satu-satunya orang yang masih menjalankan Ubuntu 18.04 :wink: Dan sementara saya dapat menjalankan debuild, saya yakin ada banyak pengguna yang kurang teknis yang tidak bisa?
Bisakah Anda membangun di dalam VM atau sesuatu?

Saya memelihara snap rpi-imager, dan baru saja menabraknya untuk membangun di Ubuntu 20.04, tetapi dapat diinstal di Ubuntu 18.04 (bahkan 14.04 & 16.04) dan distro lain juga.

Sebagai titik data yang menarik tentang "siapa yang masih menjalankan 18,04?" pertanyaan, masih ada jumlah yang adil di atasnya. Di antara pengguna snap RPI Imager, ~13% ada di Ubuntu 18.04, dengan ~56% di 20.04 dan bahkan ~2.7% di Ubuntu 16.04!

Screenshot_20210331_125839

Kecuali https://github.com/popey/imager-snap/issues/8 telah diselesaikan, sayangnya snap tidak mendukung set lengkap fitur Imager. IIRC, Anda juga perlu mengaktifkan beberapa izin tambahan untuk mencegah kesalahan lain. Tidak jelas bahwa Anda perlu melakukan itu atau bagaimana. Mengingat bahwa imager dimaksudkan untuk menyederhanakan berbagai hal, jepretan tampaknya menimbulkan rintangan.

Idealnya, akan lebih bagus untuk itu di repo apt normal.

Kecuali popey/imager-snap#8 telah diselesaikan

Apakah ini bekerja lebih baik di bawah 1.6.1?

Menyelinap dalam komit ( https://github.com/raspberrypi/rpi-imager/commit/c8409d741939c0af32180c731a86adcdeaba802d ) yang mungkin mengatasinya, tetapi tidak punya waktu untuk mencari cara membuat snap untuk mengujinya.

Kode sebelumnya mengasumsikan bahwa segera setelah udisks2 (yang kami bicarakan melalui DBus) memberi tahu kami bahwa volume yang dapat dilepas (partisi FAT32) sudah terpasang, kami dapat menulis ke folder pemasangan.
Tapi itu mungkin belum dipasang di dalam snap chroot pada saat itu, yang tampaknya tertinggal.
Jadi, periksa apakah folder mount adalah titik mount, dan tunda hingga 3 detik jika tidak.

Baru saja mencobanya dan tidak, sepertinya lebih buruk. Pada awalnya dikatakan tidak dapat memasang partisi, jadi saya mengaktifkan izin yang relevan. Kesalahan yang sama, jadi saya mengaktifkan semua izin yang dinonaktifkan (walaupun deskripsinya tampaknya tidak relevan) (PEBCAK). Sekarang imager berperilaku seperti semuanya berjalan dengan baik, tetapi kartu SD kosong pada akhirnya.

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

Secara keseluruhan, bukan pengalaman yang Anda inginkan bagi pengguna mana pun.

Tidak dapat membuat 'README.txt'

Apakah /var/lib/snapd/hostfs/media/shift/F28E-8BF1 tidak dapat ditulis oleh snap pengguna menjalankan Imager sebagai?

Haruskah kita memindahkan ini ke https://github.com/popey/imager-snap/issues/8?

Terlepas dari masalah apa pun dengan paket Snap, saya masih berpikir bahwa imager_1.6.1_amd64.deb yang dapat diunduh dari https://www.raspberrypi.org/software/ seharusnya dapat diinstal di Ubuntu 18.04 (yang masih didukung hingga April 2023).
:slightly_frowning_face:

EDIT: Diblokir oleh #200

EDIT2: Untuk orang lain yang masih menggunakan Ubuntu 18.04, inilah build dari RPi Imager 1.6.1 setelah menerapkan tambalan dari #200
Gunakan dengan risiko Anda sendiri: rpi-imager_1.6.1_amd64.zip
(jangan ragu untuk menghapus @maxnet ini jika Anda merasa tidak pantas)

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

Jadi jika RPi Imager pasti tidak akan mendukung Ubuntu 18.04 ke depan, saya kira kita harus memperbarui dokumentasi itu juga? :mengangkat bahu:

Jadi jika RPi Imager pasti tidak akan mendukung Ubuntu 18.04 ke depan

Tidak yakin apa kebijakan dukungan resminya.

Perlu diketahui bahwa kegunaan Ubuntu 18 secara keseluruhan untuk pengembang menurun dengan cepat.

  • Tidak dapat digunakan lagi untuk pengembangan web, karena versi PHP yang disertakan lebih tua dari yang diterima oleh kerangka kerja modern.
  • Tidak dapat digunakan untuk pengembangan level C rendah. Misalnya jika Anda ingin bermain dengan mengatakan Raspberry Pico, Anda akan menemukan bahwa CMake terlalu tua.
  • Versi Qt tidak mendukung banyak metode yang lebih baru. Dan jika Anda menggunakan versi Qt yang lebih baru di platform lain, Anda akan melihatnya melontarkan banyak peringatan metode "usang" jika Anda menggunakan metode lama di sana.

Dan Ubuntu 20 LTS telah keluar selama setahun.

Apa alasan Anda masih menggunakan 18?

Apa alasan Anda masih menggunakan 18?

Saya membeli laptop Dell XPS baru lebih dari setahun yang lalu yang datang dengan Ubuntu 18.04 yang sudah diinstal sebelumnya, dan saya enggan untuk mencoba memutakhirkannya ke versi yang lebih baru, terutama karena ini masih merupakan versi LTS yang didukung secara aktif. Selain itu, menjalankan OS yang lebih lama tetapi masih didukung berguna untuk mengungkap kasus tepi seperti ini :wink:
Untuk hal-hal Pico, saya memperbarui ke versi CMake yang lebih baru menggunakan https://apt.kitware.com/ Dan ketika saya perlu menggunakan versi GCC yang lebih baru, saya hanya menambahkan local-install-dir ke $PATH. Untuk hal lain, ada VirtualBox.

Rilis LTS adalah 'kelas perusahaan' dan berfokus pada stabilitas. Mereka adalah untuk mereka yang _tidak_ menginginkan perangkat lunak versi baru. Pembaruan perangkat lunak yang Anda dapatkan untuk rilis LTS adalah keamanan dan perbaikan bug saja. Mendukung perangkat lunak lama tidak gratis, dibutuhkan kerja keras dan membatasi kemampuan Anda untuk maju. Tidak masuk akal untuk mengharapkan LTS lama tetap menjadi platform yang didukung setahun setelah yang sekarang dirilis.

Mereka adalah untuk mereka yang _tidak_ menginginkan perangkat lunak versi baru.

Ya, itu posisi yang wajar untuk diambil; Saya tidak punya masalah dengan misalnya RPi Imager 1.7.x hanya mendukung Ubuntu 20.04+, dengan Ubuntu 18.04 dibatasi untuk RPi Imager 1.6.x yang lebih lama. Rasanya aneh bagi saya bahwa compatibility-break terjadi dalam perubahan dari 1.6.0 menjadi 1.6.1
Juga, mengingat tingkat pengguna yang dituju situs web Raspberry Pi, saya kira tidak mungkin situs web itu menawarkan opsi unduhan yang berbeda untuk "pengguna Ubuntu 20.04+" dan "pengguna Ubuntu 18.04", itulah sebabnya saya menyarankan itu ketika/jika keputusan untuk menghentikan dukungan untuk 18,04 terjadi, itu perlu disebutkan secara khusus dalam dokumentasi.

:man_mengangkat bahu:

Rasanya aneh bagi saya bahwa compatibility-break terjadi dalam perubahan dari 1.6.0 menjadi 1.6.1

Saya setuju bahwa itu aneh terjadi secara diam-diam pada rilis poin. Itu setidaknya harus ditambahkan ke log perubahan 1.6.1. Tapi tahukah Anda... ada satu tahun masa tenggang! Jika Anda tertarik, XPS (13) saya berjalan 20,04 dengan sempurna :)

Terlepas dari masalah apa pun dengan paket Snap, saya masih berpikir bahwa imager_1.6.1_amd64.deb yang dapat diunduh dari https://www.raspberrypi.org/software/ seharusnya dapat diinstal di Ubuntu 18.04 (yang masih didukung hingga April 2023).
sedikit_mengernyitkan_wajah

~EDIT: Diblokir oleh #200~

EDIT2: Untuk orang lain yang masih menggunakan Ubuntu 18.04, inilah build dari RPi Imager 1.6.1 setelah menerapkan tambalan dari #200
Gunakan dengan risiko Anda sendiri: rpi-imager_1.6.1_amd64.zip
(jangan ragu untuk menghapus @maxnet ini jika Anda merasa tidak pantas)

Terima kasih. bekerja pada debian buster untuk saya, sementara unduhan dan snap asli gagal

Sekedar informasi bahwa ini juga merupakan masalah di ChromeOS. Jika Anda mengaktifkan mode Pengembang Linux 1.6.1 yang dibagikan oleh @lurch berfungsi sementara unduhan dari https://www.raspberrypi.org/software/ tidak.

Untuk kepentingan siapa pun yang mengikuti masalah ini...

Saya baru saja mencoba mengkompilasi tag v1.6.2 di Ubuntu 18.04 dan gagal membangun dengan:

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

karena fungsi itu ditambahkan di Qt 5.10, tetapi Ubuntu 18.04 hanya menyertakan Qt 5.9.5.
Jadi sepertinya build saya dari v1.6.1 adalah "akhir dari baris" untuk pengguna Ubuntu 18.04 :wink:

Mereka adalah untuk mereka yang _tidak_ menginginkan perangkat lunak versi baru.

Tidak. Saya menggunakan LTS karena memutakhirkan atau menginstal rilis baru adalah waktu yang sangat lama bagi konsumen. Setelah menginstal banyak yang harus dimodifikasi/di-tweak, diinstal, diatur, dll. Butuh banyak waktu. LTS memberikan kesempatan untuk menggunakan sistem untuk waktu yang lebih lama. Pada 18,04 saya saat ini, saya tidak akan menggunakan Ubuntu lagi (tapi itu cerita lain).

Saya menggunakan beberapa PPA + beberapa gambar aplikasi. Untuk hal-hal seperti PHP saya menginstalnya sendiri.

Saya takut 20,04 LTS adalah minimum baru, karena saya memutakhirkan ke itu. :-)

Saya percaya seluruh diskusi "18,04 terlalu tua" ini tidak memiliki masalah besar yang lebih dalam dengan proyek: mengapa proses pembangunan terikat dengan versi khusus Anda? Apakah Anda mengkompilasi dan menerbitkannya _yourself_? Bukankah rpi-imager memiliki tindakan CI, PPA, Github atau alat semacam itu untuk alur kerja pembangunan awan?

Selama alat _that_ mendukung 18,04 (dan sumbernya kompatibel), OS pribadi @maxnet seharusnya tidak relevan. PPA dapat dibuat untuk _semua_ versi Ubuntu saat ini. Travis-CI dan Github dapat membangun untuk banyak platform. Anda bahkan dapat menggunakan Windows untuk pengembangan dan membiarkan cloud membangun untuk Fedora, Mac, BSD, ARM, tidak peduli seberapa kuno atau canggihnya platform tersebut.

Yang mengatakan...

Selama alat itu mendukung 18,04 (dan sumbernya kompatibel)

1) Sumber tidak akan kompatibel di masa mendatang tanpa #ifdef magic.
Metode yang lebih baru tidak ada di versi Qt kuno.
Menggunakan metode yang lebih lama memberikan banyak peringatan usang pada versi Qt 5 yang lebih baru, dan akan hilang di Qt 6

2) Ini adalah aplikasi yang perlu ditandatangani kode setidaknya di Windows dan Mac OS X dan saya bukan penggemar berat berbagi kunci penandatanganan kode dengan penyedia cloud.

3) Masih memerlukan instalasi setiap sistem operasi untuk dapat menguji apakah hasilnya berfungsi dengan benar.
Jenis perangkat lunak ini (dengan interaksi dengan layanan sistem dan perangkat keras fisik seperti pembaca kartu SD) tidak begitu cocok untuk kerangka pengujian otomatis...

Dan Ubuntu 20 LTS telah keluar selama setahun.

Dan Ubuntu 18 masih didukung selama dua tahun penuh. Poin Anda?

Perlu diketahui bahwa kegunaan Ubuntu 18 secara keseluruhan untuk pengembang menurun dengan cepat.
...
Apa alasan Anda masih menggunakan 18?

Itu ... bukan bagaimana menangani masalah ini. Alasan khusus @lurch untuk menggunakan 18 seharusnya tidak menjadi masalah. Ada banyak. Seperti yang Anda miliki untuk beralih ke 20,04, sementara beberapa sudah melompat pada 21,10.

Tidak masuk akal untuk mengharapkan LTS lama tetap menjadi platform yang didukung setahun setelah yang sekarang dirilis.

Dia. Ini disebut LTS karena suatu alasan! _Dukungan Jangka Panjang_ .

sudah ada masa tenggang tahun!

Palsu. "Masa tenggang tahun" hanya akan _dimulai_ pada April 2022 , di mana kita akan _kemudian_ memiliki waktu satu tahun penuh hingga _2023_ untuk bermigrasi ke Ubuntu 22.04, sepenuhnya melewati 20.04, sementara masih menggunakan sistem yang didukung penuh. Saya _sangat_ tidak ingin repot memutakhirkan seluruh OS setiap 2 tahun

Ayo guys... Ubuntu baru saja sepenuhnya merangkul Raspberry, merilis tidak hanya edisi Server tetapi juga Desktop, Core, seluruh keluarga. Mereka menambahkan semua paket khusus Raspberry ke repositori mereka, tidak ada lagi PPA yang diperlukan untuk rpi-eeprom atau vcgencmd .

Tolong dukung sepenuhnya juga untuk pernikahan yang panjang dan bahagia :1st_place_medal:

Dan Ubuntu 18 masih didukung selama dua tahun penuh. Poin Anda?

"Didukung" tidak berarti Anda dapat memiliki versi perangkat lunak yang lebih baru.
Semua yang ada di sistem Ubuntu 18 adalah perangkat lunak versi 2018, dengan hanya perbaikan stabilitas dan keamanan yang ditambahkan sebagai backport nanti.
Anda masih dapat menjalankan Imager versi lama di atasnya, agar sesuai dengan sistem lainnya.

  1. Ini adalah aplikasi yang perlu ditandatangani kode setidaknya pada Windows dan Mac OS X dan saya bukan penggemar berat berbagi kunci penandatanganan kode dengan penyedia cloud.

Bukankah Raspberry (perusahaan / organisasi) memberi Anda _setiap_ infrastruktur atau panduan tentang ini? Maksud saya... IMHO rpi_imager adalah komponen kunci dalam ekosistem Raspi. Ini adalah _entry point_ dari menggunakannya. Ini dipamerkan di situs web resmi _both_ Raspberry dan Ubuntu sebagai imager yang didukung.

Tidak yakin apa kebijakan dukungan resminya.

Mengingat profil tinggi dari proyek ini, saya benar-benar terkejut bahwa tidak ada kebijakan resmi tentang itu.

"Didukung" tidak berarti Anda dapat memiliki versi perangkat lunak yang lebih baru. Semua yang ada di sistem Ubuntu 18 adalah perangkat lunak versi 2018, dengan hanya perbaikan stabilitas dan keamanan yang ditambahkan sebagai backport nanti.

Poin yang adil, dan saya setuju. Saya tidak keberatan menggunakan versi lama, selama versi _current_ saya tetap berfungsi. Dan bukan itu yang terjadi di sini.

rpi-imager , diinstal dari snap , baru saja _broke_ tiba-tiba, kemarin. Itu berhenti bekerja, dengan kesalahan dmesg AppArmor dan drive kosong seperti yang dilaporkan @lurch , yang membawa saya ke sini. Mengapa versi yang tidak kompatibel diunggah ke saluran 18,04?

Poin yang adil, dan saya setuju. Saya tidak keberatan menggunakan versi lama

Kemudian Anda dapat mencoba 1.6.0 yang lebih lama: https://downloads.raspberrypi.org/imager/imager_1.6_amd64.deb

rpi-imager, diinstal dari snap, tiba-tiba muncul

Masalah jepret dapat dilaporkan di sini: https://github.com/popey/imager-snap/issues
Kami tidak terlibat dengan versi itu.

Beberapa klarifikasi yang mungkin relevan:

rpi-imager , diinstal dari snap , baru saja _broke_ tiba-tiba, kemarin.

Mungkin itu rusak lebih awal. Saya telah menggunakannya secara teratur untuk ngengat, tetapi selalu menggunakan gambar (cache) yang sama. Kemarin saya mencoba beberapa yang baru, jadi mungkin itu sebabnya baru sekarang masalahnya terwujud. Versi terinstal adalah 1.6.2, dan IIRC sudah demikian setidaknya selama beberapa minggu.

Saya tidak keberatan menggunakan versi lama

Bukannya aku tidak peduli. Saya bersedia. Tapi saya sadar saya tidak _berhak_ untuk apa pun. Saya hanya berharap beberapa proyek mengambil pendekatan yang lebih konservatif dalam hal mengadopsi API baru yang mungkin merusak rilis yang lebih lama (tetapi masih tidak EOL).

Saya, misalnya, melakukan banyak pengembangan Python, dan sering menghadapi dilema yang sama: jika ada fitur baru yang bagus di Python 3.9, saya menahan diri untuk tidak menggunakannya meskipun saya sudah menggunakan Python 3.11, karena distro lama suka CentoOS masih dikirimkan dengan 3.6 kuno. Setidaknya mereka memiliki 3,8 _available_, jadi saya dapat menambahkan versi sumber minimum saya ke sana. Bisakah pendekatan serupa diambil di sini?

Menggali lebih dalam ke dalam log, saya yakin kita sedang berhadapan dengan 2 masalah independen yang berbeda di sini:

  • Entah bagaimana saya (dan selalu) dapat menginstal dan meluncurkan tidak hanya 1.6.1 tetapi 1.6.2 dari snap. Jadi apa pun yang dilakukan @popey untuk mengompilasinya agar 18,04 berhasil, selamat! Ini menunjukkan kesalahan saya tentang AppArmor saat menulis gambar tidak ada hubungannya dengan dependensi paket atau masalah kompilasi QT saat membangun .deb (masalah _this_ tampaknya tentang), meskipun keduanya bermanifestasi dalam 18.04

  • Masalah saya, dan sepertinya @XECDesign juga, adalah tentang _permissions_, dan sepertinya ini adalah masalah snap-only . Jadi saya akan pindah ke sana seperti yang diinstruksikan.

Untuk siapa pun yang datang ke sini dengan masalah seperti _"Kebijakan AppArmor mencegah pengirim ini mengirim pesan ini ..."_, _"Tidak dapat membuka soket jaringan"_, atau _"operasi tidak diizinkan"_, buka masalah ini , tidak disini. Hanya saja ada banyak masalah dengan 18,04 dalam judulnya :-)

dapat menginstal dan meluncurkan tidak hanya 1.6.1 tetapi 1.6.2 dari snap. Jadi apa pun yang dilakukan @popey untuk mengompilasinya agar 18,04 berhasil, selamat!

Saya pikir snap adalah format pengemasan "mandiri"? Jadi mungkin dapat menyertakan versi perpustakaan Qt yang lebih baru daripada yang disertakan dengan Ubuntu 18.04? (yang perlu digunakan versi .deb dari RPi Imager)

Masalah jepret dapat dilaporkan di sini: https://github.com/popey/imager-snap/issues
Kami tidak terlibat dengan versi itu.

@maxnet Kami tampaknya mendapatkan beberapa laporan masalah tentang versi snap RPi Imager (mungkin karena itu adalah versi yang diinstal oleh "toko perangkat lunak" Ubuntu), yang jelas tidak dapat kami lakukan apa-apa. Mungkin ada baiknya memanfaatkan fitur template masalah GitHub, untuk mengarahkan orang yang memiliki masalah dengan versi snap RPi Imager langsung ke repo popey ? :mengangkat bahu:

Versi 1.6.0 yang lebih lama (direferensikan oleh @maxnet) diinstal dengan baik di Linux Mint 19.3 (repo bionik). Terima kasih

Apakah halaman ini membantu?
0 / 5 - 0 peringkat