Rpi-imager: لا يمكن تثبيت RPi Imager 1.6.1 (وما فوق) على Ubuntu 18.04

أخشى أن 20.04 LTS هو الحد الأدنى الجديد ، لأنني قمت بالترقية إلى ذلك. :-)
يجب أن تظل قادرًا على تشغيل "debuild" من git بنفسك بالرغم من ذلك.

أنا متأكد من أنني لا أستطيع أن أكون الشخص الوحيد الذي ما زال يستخدم Ubuntu 18.04: wink: وبينما يمكنني تشغيل debuild ، أنا متأكد من أن هناك العديد من المستخدمين الأقل تقنية ممن لا يستطيعون ذلك؟
هل يمكنك البناء داخل جهاز افتراضي أو شيء من هذا القبيل؟

أحتفظ بلقطة من rpi-imager ، وقد صدمته للتو للبناء على Ubuntu 20.04 ، لكنه قابل للتثبيت على Ubuntu 18.04 (حتى 14.04 و 16.04) وتوزيعات أخرى أيضًا.

كنقطة بيانات مثيرة للاهتمام حول "من لا يزال يدير 18.04؟" سؤال ، لا يزال هناك رقم لا بأس به. من بين مستخدمي RPI Imager snap ، يوجد 13٪ تقريبًا على Ubuntu 18.04 ، مع 56٪ تقريبًا في 20.04 وحتى ~ 2.7٪ على Ubuntu 16.04!

ما لم يتم حل https://github.com/popey/imager-snap/issues/8 ، لسوء الحظ ، لا يدعم الخاطف المجموعة الكاملة من ميزات Imager. IIRC ، تحتاج أيضًا إلى تمكين بعض الأذونات الإضافية لمنع الأخطاء الأخرى. ليس من الواضح أنك بحاجة إلى القيام بذلك أو كيفية القيام بذلك. بالنظر إلى أن المصور يهدف إلى تبسيط الأشياء ، يبدو أن الخاطف يقدم عقبات.

من الناحية المثالية ، سيكون رائعًا في المستودعات المناسبة العادية بدلاً من ذلك.

ما لم يتم حل popey / imager-snap # 8

هل تعمل بشكل أفضل تحت 1.6.1؟

تم التسلل في التزام (https://github.com/raspberrypi/rpi-imager/commit/c8409d741939c0af32180c731a86adcdeaba802d) قد يعمل على حلها ، ولكن لم يكن لديك الوقت لمعرفة كيفية إنشاء لقطة لاختبارها.

افترض الكود سابقًا أنه بمجرد أن أخبرنا udisks2 (الذي نتحدث إليه عبر DBus) أن وحدة التخزين القابلة للإزالة (قسم FAT32) ، يمكننا الكتابة إلى مجلد التحميل.
ولكن قد لا يتم تثبيته داخل الجذور المفاجئة حتى الآن عند هذه النقطة ، والتي يبدو أنها متخلفة عن الركب.
لذا تحقق من أن مجلد التحميل هو نقطة تحميل ، ويتأخر لمدة تصل إلى 3 ثوانٍ إذا لم يكن كذلك.

لقد جربته للتو ولا ، يبدو أنه أسوأ. في البداية قال إنه لا يمكنه تثبيت القسم ، لذلك قمت بتمكين الإذن المناسب. نفس الخطأ ، لذلك قمت بتمكين جميع الأذونات التي تم تعطيلها (على الرغم من أن أوصافها لا تبدو ذات صلة) (PEBCAK). الآن يتصرف جهاز التصوير كما لو أن كل شيء سار على ما يرام ، لكن بطاقة SD فارغة في النهاية.

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

بشكل عام ، ليست التجربة التي تريد أن يتمتع بها أي مستخدم.

لا يمكن إنشاء "README.txt"

هل / var / lib / snapd / hostfs / media / shift / F28E-8BF1 غير قابل للكتابة بواسطة المستخدم المفاجئ الذي يقوم بتشغيل Imager كـ؟

هل يجب نقل هذا إلى https://github.com/popey/imager-snap/issues/8؟

بغض النظر عن أي مشاكل مع حزم Snap ، ما زلت أعتقد أن imager_1.6.1_amd64.deb القابل للتنزيل من https://www.raspberrypi.org/software/ يجب أن يكون قابلاً للتثبيت على Ubuntu 18.04 (والذي لا يزال مدعومًا حتى أبريل 2023).
: قليلا_التجعد_الوجه:

تحرير: ممنوع بواسطة # 200

EDIT2: لأي شخص آخر لا يزال يستخدم Ubuntu 18.04 ، إليك بنية RPi Imager 1.6.1 بعد تطبيق التصحيح من # 200
استخدم على مسؤوليتك الخاصة: rpi-imager_1.6.1_amd64.zip
(لا تتردد في حذف @ maxnet إذا كنت تشعر أنه غير مناسب)

https://www.raspberrypi.org/documentation/installation/installing-images/README.md يقول أيضًا "Ubuntu 18.04": wink:

لذا ، إذا كان RPi Imager بالتأكيد لن يدعم Ubuntu 18.04 من الآن فصاعدًا ، أعتقد أنه يجب علينا تحديث هذه الوثائق أيضًا؟ : تتغاضى:

لذلك ، إذا كان RPi Imager بالتأكيد لن يدعم Ubuntu 18.04 للمضي قدمًا

لست متأكدا ما هي سياسة الدعم الرسمية.

فقط كن على دراية بأن الفائدة الإجمالية لـ Ubuntu 18 للمطورين آخذة في التناقص بسرعة.

• لم يعد قابلاً للاستخدام لتطوير الويب بعد الآن ، حيث إن إصدار PHP الذي يأتي معه أقدم مما تقبله أطر العمل الحديثة.
• غير صالحة للاستعمال من أجل التنمية منخفضة المستوى C. على سبيل المثال ، إذا كنت تريد اللعب مع Raspberry Pico ، فستكتشف أن CMake قديم جدًا.
• لا يدعم إصدار Qt مجموعة من الأساليب الأحدث. وإذا كنت تستخدم إصدارًا أحدث من Qt على منصات أخرى ، فسترى أنه يلقي حمولة من تحذيرات الطريقة "المهملة" إذا كنت تستخدم الطرق القديمة هناك.

وقد تم إيقاف تشغيل Ubuntu 20 LTS لمدة عام.

ما هو سبب استمرار استخدامك 18؟

ما هو سبب استمرار استخدامك 18؟

لقد اشتريت جهاز كمبيوتر محمول XPS جديدًا من Dell منذ ما يزيد قليلاً عن عام والذي جاء مع Ubuntu 18.04 مثبتًا مسبقًا ، وأنا متردد في محاولة ترقيته إلى إصدار أحدث ، خاصة أنه لا يزال إصدار LTS مدعومًا بشكل نشط. أيضًا ، يعد تشغيل نظام تشغيل أقدم ولكن لا يزال مدعومًا مفيدًا للكشف عن حالات الحافة مثل هذا: wink:
بالنسبة إلى عناصر Pico ، قمت بالتحديث إلى إصدار أحدث من CMake باستخدام https://apt.kitware.com/ وعندما أحتاج إلى استخدام إصدار أحدث من دول مجلس التعاون الخليجي ، أقوم فقط بإرفاق برنامج local-install-dir بـ $ PATH. لأي شيء آخر ، هناك برنامج VirtualBox.

إصدارات LTS هي "فئة المؤسسات" وتركز على الاستقرار. إنها مخصصة لأولئك الذين لا يريدون إصدارات جديدة من البرامج. تحديثات البرامج التي تحصل عليها لإصدارات LTS هي إصلاحات أمنية وأخطاء فقط. دعم البرامج القديمة لا يأتي مجانًا ، فهو يتطلب عملاً ويحد من قدرتك على المضي قدمًا. ليس من المعقول توقع بقاء LTS القديم كمنصة مدعومة بعد عام من إصدار النظام الحالي.

إنها مخصصة لأولئك الذين لا يريدون إصدارات جديدة من البرامج.

نعم ، هذا موقف معقول يجب اتخاذه ؛ لن أواجه أي مشكلة مع على سبيل المثال RPi Imager 1.7.x الذي يدعم Ubuntu 20.04+ فقط ، حيث يقتصر Ubuntu 18.04 على RPi Imager 1.6.x. لقد شعرت بالغرابة بالنسبة لي أن كسر التوافق حدث في التغيير من 1.6.0 إلى 1.6.1
أيضًا ، نظرًا لمستوى المستخدم الذي يستهدفه موقع Raspberry Pi على الويب ، أعتقد أنه من غير المحتمل أن يقدم موقع الويب خيارات تنزيل مختلفة لكل من "مستخدمي Ubuntu 20.04+" و "مستخدمي Ubuntu 18.04" ، ولهذا السبب كنت أقترح ذلك عندما / إذا حدث قرار إسقاط الدعم لعام 18.04 ، يجب ذكر ذلك على وجه التحديد في الوثائق.

: man_shrugging:

لقد شعرت بالغرابة بالنسبة لي أن كسر التوافق حدث في التغيير من 1.6.0 إلى 1.6.1

أوافق على أنه من الغريب أن يحدث ذلك بصمت عند إصدار نقطة. يجب على الأقل إضافة ذلك إلى سجل التغيير 1.6.1. لكنك تعلم ... كانت هناك فترة سماح لمدة عام! إذا كان لديك أي اهتمام ، فإن XPS (13) الخاص بي يعمل 20.04 بشكل مثالي :)

بغض النظر عن أي مشاكل مع حزم Snap ، ما زلت أعتقد أن imager_1.6.1_amd64.deb القابل للتنزيل من https://www.raspberrypi.org/software/ يجب أن يكون قابلاً للتثبيت على Ubuntu 18.04 (والذي لا يزال مدعومًا حتى أبريل 2023).
قليلا_frowning_face

~ EDIT: ممنوع بواسطة # 200 ~

EDIT2: لأي شخص آخر لا يزال يستخدم Ubuntu 18.04 ، إليك بنية RPi Imager 1.6.1 بعد تطبيق التصحيح من # 200
استخدم على مسؤوليتك الخاصة: rpi-imager_1.6.1_amd64.zip
(لا تتردد في حذف @ maxnet إذا كنت تشعر أنه غير مناسب)

شكرا. عملت على ديبيان باستر بالنسبة لي ، بينما فشل التنزيل الأصلي والإنجذاب

فقط لمعلوماتك أن هذه مشكلة في ChromeOS أيضًا. إذا كان لديك وضع Linux Developer ممكّنًا ، فإن 1.6.1 مشترك بواسطة lurch يعمل بينما التنزيل من https://www.raspberrypi.org/software/ لا يعمل.

لصالح أي شخص يتابع هذه القضية ...

لقد حاولت للتو تجميع علامة v1.6.2 على Ubuntu 18.04 وفشلت في الإنشاء باستخدام:

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

لأنه تمت إضافة هذه الوظيفة في Qt 5.10 ، لكن Ubuntu 18.04 يتضمن Qt 5.9.5 فقط.
لذلك يبدو أن الإصدار الخاص بي من v1.6.1 هو "نهاية السطر" لمستخدمي Ubuntu 18.04: wink:

إنها مخصصة لأولئك الذين لا يريدون إصدارات جديدة من البرامج.

لا ، فأنا أستخدم LTS لأن ترقية أو تثبيت الإصدار الجديد يستهلك الكثير من الوقت. بعد التثبيت ، يجب تعديل / تعديل الكثير ، وتثبيته ، وإعداده وما إلى ذلك. يستغرق الكثير من الوقت. يتيح نظام LTS الفرصة لاستخدام النظام لفترة أطول. اعتبارًا من 18.04 الحالي ، لن أستخدم Ubuntu بعد الآن (ولكن هذه قصة أخرى).

أنا أستخدم عدة PPAs + بعض التطبيقات. لأشياء مثل PHP أقوم بتثبيتها بنفسي.

أخشى أن 20.04 LTS هو الحد الأدنى الجديد ، لأنني قمت بالترقية إلى ذلك. :-)

أعتقد أن مناقشة "18.04 قديمة جدًا" تفتقد إلى مشكلة ضخمة وأعمق في المشروع: لماذا ترتبط عملية الإنشاء بإصدارك الخاص؟ هل تقوم بتجميعها ونشرها بنفسك؟ ألا يحتوي rpi-imager على CI أو PPA أو إجراء Github أو أي أداة من هذا القبيل لسير عمل إنشاء السحابة؟

طالما أن الأداة _that_ تدعم 18.04 (والمصادر متوافقة) ، يجب أن يكون نظام التشغيل الشخصي الخاص بـmaxnet غير ذي صلة. يمكن لـ PPA إنشاء _جميع_ إصدارات Ubuntu الحالية. يمكن لـ Travis-CI و Github البناء للعديد من المنصات. يمكنك حتى استخدام Windows للتطوير والسماح بإنشاء السحابة لـ Fedora ، و Mac ، و BSD ، و ARM ، بغض النظر عن مدى تقدم النظام الأساسي أو تطوره.

هكذا قال...

طالما أن هذه الأداة تدعم 18.04 (والمصادر متوافقة)

1) لن تكون المصادر متوافقة في المستقبل بدون سحر #ifdef.
لا توجد طرق أحدث في إصدارات Qt القديمة.
باستخدام الطرق القديمة ، أعط مجموعة من التحذيرات المهملة في إصدارات Qt 5 الأحدث ، وستختفي في Qt 6

2) هذا تطبيق يحتاج إلى أن يكون رمزًا موقّعًا على نظامي التشغيل Windows و Mac OS X على الأقل ولست معجبًا كبيرًا بمشاركة مفاتيح توقيع التعليمات البرمجية مع موفري الخدمات السحابية.

3) هل ستظل بحاجة إلى تثبيت كل نظام تشغيل لتتمكن من اختبار ما إذا كانت النتيجة تعمل بشكل صحيح.
هذا النوع من البرامج (مع التفاعل مع خدمات النظام والأجهزة المادية مثل قارئات بطاقة SD) ليس مناسبًا جدًا لأطر الاختبار الآلية ...

وقد تم إيقاف تشغيل Ubuntu 20 LTS لمدة عام.

ولا يزال Ubuntu 18 مدعومًا لمدة عامين كاملين . وجهة نظرك؟

فقط كن على دراية بأن الفائدة الإجمالية لـ Ubuntu 18 للمطورين آخذة في التناقص بسرعة.
...
ما هو سبب استمرار استخدامك 18؟

هذا ... ليس كيفية التعامل مع هذه المشكلة. يجب ألا تهم الأسباب الخاصة باستخدام lurch لاستخدام 18. هناك العديد. نظرًا لأنه كان لديك للتبديل إلى 20.04 ، بينما قفز البعض بالفعل في 21.10.

ليس من المعقول توقع بقاء LTS القديم كمنصة مدعومة بعد عام من إصدار النظام الحالي.

أنه. يطلق عليه LTS لسبب ما! _دعم طويل الأمد .

كانت هناك فترة سماح لمدة عام!

خطأ شنيع. ستبدأ "فترة السماح للسنة" فقط في أبريل 2022 ، حيث سيكون لدينا بعد ذلك عام كامل حتى _2023_ للانتقال إلى Ubuntu 22.04 ، متخطيًا تمامًا 20.04 ، مع الاستمرار في استخدام نظام مدعوم بالكامل. أنا _ حقًا لا أريد متاعب ترقية نظام التشغيل بالكامل كل عامين

هيا يا رفاق ... لقد احتضنت Ubuntu للتو Raspberry بالكامل ، حيث أصدرت ليس فقط إصدار Server ولكن أيضًا Desktop و Core وجميع أفراد العائلة. لقد أضافوا جميع الحزم الخاصة بـ Raspberry إلى مستودعاتهم ، ولم تعد هناك حاجة إلى مزيد من PPA مقابل rpi-eeprom أو vcgencmd .

يرجى دعمه بالكامل أيضًا من أجل زواج طويل وسعيد: 1st_place_medal:

ولا يزال Ubuntu 18 مدعومًا لمدة عامين كاملين. وجهة نظرك؟

لا تعني كلمة "مدعوم" أنك تحصل على إصدارات أحدث من البرامج.
كل شيء على نظام Ubuntu 18 هو إصدار 2018 من البرنامج ، مع إضافة إصلاحات الاستقرار والأمان فقط كنافذة خلفية لاحقًا.
لا يزال بإمكانك تشغيل إصدارات أقدم من Imager عليه ، لتتناسب مع بقية النظام.

1. هذا تطبيق يحتاج إلى أن يكون رمزًا موقّعًا على نظامي التشغيل Windows و Mac OS X على الأقل ولست معجبًا كبيرًا بمشاركة مفاتيح توقيع التعليمات البرمجية مع موفري الخدمات السحابية.

ألا تزودك شركة Raspberry (الشركة / المنظمة) بأي بنية تحتية أو إرشادات في هذا الشأن؟ أعني ... IMHO rpi_imager هو عنصر أساسي في نظام Raspi البيئي. إنها نقطة الدخول ذاتها لاستخدامها. يتم عرضه في المواقع الرسمية لكل من Raspberry و Ubuntu باعتباره المصور المعتمد.

لست متأكدا ما هي سياسة الدعم الرسمية.

نظرًا للمكانة العالية لهذا المشروع ، فأنا مندهش حقًا من عدم وجود سياسة رسمية بشأن ذلك.

لا تعني كلمة "مدعوم" أنك تحصل على إصدارات أحدث من البرامج. كل شيء على نظام Ubuntu 18 هو إصدار 2018 من البرنامج ، مع إضافة إصلاحات الاستقرار والأمان فقط كنافذة خلفية لاحقًا.

نقطة عادلة ، وأنا أوافق. لا أمانع في استخدام إصدار قديم ، طالما أن الإصدار الحالي الخاص بي يستمر في العمل. وهذا ليس ما حدث هنا.

rpi-imager ، مثبت من snap ، فقط _broke_ من اللون الأزرق ، أمس. توقف عن العمل ، مع نفس أخطاء dmesg حول ملفات تعريف AppArmor ومحركات أقراص فارغة كما ذكرت lurch ، مما قادني إلى هنا. لماذا تم تحميل نسخة غير متوافقة على 18.04 قناة؟

نقطة عادلة ، وأنا أوافق. لا أمانع في استخدام نسخة قديمة

ثم يمكنك تجربة الإصدار 1.6.0 الأقدم: https://downloads.raspberrypi.org/imager/imager_1.6_amd64.deb

rpi-imager ، المثبت من snap ، اندلع للتو من اللون الأزرق

يمكن الإبلاغ عن مشكلات Snap هنا: https://github.com/popey/imager-snap/issues
نحن لا نشارك في هذا الإصدار.

بعض التوضيحات التي قد تكون ذات صلة:

rpi-imager ، مثبت من snap ، فقط _broke_ من اللون الأزرق ، أمس.

ربما كسر في وقت سابق. كنت أستخدمه بانتظام للعث ، ولكن دائمًا ما أستخدم نفس الصورة (المخزنة مؤقتًا). بالأمس جربت بعضًا جديدًا ، لذلك ربما لهذا السبب فقط ظهرت المشكلة الآن. الإصدار المثبت هو 1.6.2 ، و IIRC كان كذلك لبضعة أسابيع على الأقل.

لا أمانع في استخدام نسخة قديمة

ليس الأمر أنني لا أهتم. أفعل. لكني أعلم أنني لست بعنوان أي شيء. لقد تمنيت للتو أن تتخذ بعض المشاريع نهجًا أكثر تحفظًا عندما يتعلق الأمر بتبني واجهة برمجة تطبيقات جديدة قد تتسبب في كسر الإصدارات الأقدم (ولكن لا تزال غير موسوعة الحياة).

أنا ، على سبيل المثال ، أقوم بالكثير من تطوير Python ، وأواجه نفس المعضلة كثيرًا: إذا كانت هناك ميزة جديدة ورائعة في Python 3.9 ، فأنا أحجم عن استخدامها حتى لو كنت بالفعل في Python 3.11 ، لأن التوزيعات القديمة مثل لا يزال CentoOS يشحن مع الإصدار القديم 3.6 . على الأقل لديهم 3.8 _available_ ، لذا يمكنني أن أضع الحد الأدنى من إصدار المصدر الخاص بي على هذا الحد. هل يمكن اتباع نهج مماثل هنا؟

بالتعمق أكثر في السجلات ، أعتقد أننا نتعامل مع مسألتين متميزتين ومستقلتين هنا:

• بطريقة ما أنا (وكنت دائمًا) قادرًا على التثبيت والتشغيل ليس فقط 1.6.1 ولكن 1.6.2 من snap. لذا فإن كل ما فعله popey لتجميعه لـ 18.04 نجح ، تهانينا! يشير هذا إلى أخطائي حول AppArmor عند كتابة الصور لا علاقة لها بتبعيات الحزمة أو مشاكل تجميع QT عند إنشاء .deb (يبدو أن هذه المشكلة تدور حول) ، على الرغم من أن كلاهما يظهر في 18.04

• مشكلتي ، ويبدو أنها مشكلةXECDesign أيضًا ، تتعلق بـ _permissions_ ، ويبدو أن هذه مشكلة سريعة فقط . لذلك سأنتقل إلى هناك حسب التعليمات.

لأي شخص قادم إلى هنا يعاني من مشاكل مثل _ "تمنع سياسة AppArmor هذا المرسل من إرسال هذه الرسالة ..." _ ، _ "تعذر فتح مقبس الشبكة" _ ، أو _ "العملية غير مسموح بها" _ ، انتقل إلى هذه المشكلة ، ليس هنا. هناك الكثير من المشكلات مع 18.04 في عنوانها :-)

قادر على التثبيت والتشغيل ليس فقط 1.6.1 ولكن 1.6.2 من سناب. لذا فإن كل ما فعله popey لتجميعه لـ 18.04 نجح ، تهانينا!

أعتقد أن snap هو تنسيق تغليف "قائم بذاته"؟ لذا من المحتمل أن يكون بإمكانه تضمين إصدار أحدث من مكتبات Qt مما تم تضمينه في Ubuntu 18.04؟ (وهو الإصدار .deb من RPi Imager الذي سيحتاج إلى استخدامه)

يمكن الإبلاغ عن مشكلات Snap هنا: https://github.com/popey/imager-snap/issues
نحن لا نشارك في هذا الإصدار.

maxnet يبدو أننا تلقينا عددًا لا بأس به من تقارير المشكلات حول الإصدار المفاجئ من RPi Imager (ربما لأن هذا هو الإصدار الذي يثبته "متجر البرامج" في Ubuntu) ، والذي من الواضح أننا لا نستطيع فعل أي شيء حياله. ربما يجدر استخدام ميزة قالب المشكلات في GitHub ، لتوجيه الأشخاص الذين يواجهون مشكلة في الإصدار المفاجئ من RPi Imager مباشرةً إلى مستودع Popey ؟ : تتغاضى:

تم تثبيت الإصدار الأقدم 1.6.0 (المشار إليه بواسطة @ maxnet) جيدًا على Linux Mint 19.3 (الريبو الآلي). شكرا