هل لديك أي أفكار حول كيفية إصلاحها؟ حاولت البحث عنها في كل مكان لكن لم أجد أي حلول.
تعديل: تم إصلاحها عن طريق تنفيذ chmod -R 777 ~/discourse، لكنني الآن أواجه هذه الرسالة:
gifsicle worker: gifsicle not found; please provide proper binary or disable this worker (--no-gifsicle argument or :gifsicle => false through options)
نجحت في إعداد بيئة تطوير لـ Discourse وأصبحت قادرة على اختبار التصحيح الخاص بي، لكن كيف يمكنني دمج هذا التصحيح في نسختي الإنتاجية؟ لقد حاولت بناء base، ثم تشغيل الأمر ./launcher rebuild app --run-image discourse/base:build، لكن يبدو أن هذا لا يؤدي إلى تشغيل مثيل Discourse.
عادةً ما أواجه خطأً يتعلق بغياب مجموعة syslog، لكنني قمت بتعليق هذا الجزء من الكود، ومع ذلك لم أتمكن من الحصول على موقع يعمل. كما لم ألاحظ أي شيء مهم في سجلات Docker.
لست متأكدًا مما إذا كان هذا هو المكان الأنسب لطرح هذا السؤال، لكنني لم أستطع إكمال تثبيت Discourse باستخدام Docker على جهاز Apple M1.
بعد تشغيل الأمر d/boot_dev --init، يتم تثبيت جميع التبعيات دون أي مشكلة ظاهرة، ولكن بمجرد الوصول إلى خطوة Migrating database، يتوقف الأمر هناك ويستهلك 100% من أحد أنوية المعالج دون أي تقدم ملحوظ.
حاولت تسجيل الدخول إلى حاوية Docker، ووجدت أن مهمة bundle migrate تعمل بنسبة 100%، لكن لا توجد أي نشاط ظاهر على عملية PostgreSQL.
لقد حاولت اليوم لفترة وجيزة، وتوقفت عند نفس الخطوة التي توقفت فيها أنت، ولكن مع ظهور خطأ:
Invalid gemspec in [/usr/local/lib/ruby/gems/2.7.0/specifications/default/zlib-1.1.0.gemspec]: Malformed version number string specification_version
bundler: failed to load command: rake (/usr/local/bin/rake)
نعم، من فضلك افعل ذلك. هناك العديد من أعضاء الفريق يستخدمون Discourse على جهاز M1 (بما في ذلك أنا) يوميًا، لذا فهو يعمل بشكل ممتاز!
لقد جربت ذلك اليوم، وواجهت أيضًا بعض المشكلات. كان الخطأ الذي ظهر بسبب أن محاكاة البنية في Docker لا تدعم inotify (الذي نستخدمه بكثرة في تطوير Discourse). لحسن الحظ، أضفت تحذيرًا إلى d/boot_dev عند اكتشاف بنية غير x86_64:
❯ d/boot_dev
تحذير: بنية Docker ليست x86_64.
من غير المرجح أن يعمل تطوير Discourse باستخدام محاكاة بنية Docker.
يرجى تجربة تثبيت تطوير أصلي.
لقد أضفت الآن أداة مساعدة d/ember-cli، وقمت بتوجيه المنفذ 4200 افتراضيًا. كما تم تحديث المعلومات في أعلى هذا الموضوع. بعد التحديث، قم بتشغيل d/rails s في أحد طرفيات الأوامر، و d/ember-cli في طرفية أخرى. كما قمت بتعيين NO_EMBER_CLI كواحد من المتغيرات التي يتم تمريرها إلى Docker، بحيث تكون متاحة عند الحاجة.
@david ربما لا يهم، ولكن فقط للإعلام: يُظهر سكريبت boot_dev خطأً زائفاً في فحص x86_64 عندما قمت بتشغيله بالخطأ دون Docker على… (لكن جزء “هل يعمل خادم Docker؟” صحيح)…
WARNING: Docker architecture is not x86_64.
Discourse development is unlikely to work using Docker's architecture emulation.
Please try a native development installation.
...(snip)...
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
لقد حصلت على psql: error: FATAL: Peer authentication failed for user "postgres" عند تشغيل d/boot_dev --init.
على الرغم من أن ملف pg_hba.conf في data/postgres/ كان يحتوي على جميع طرق المصادقة مضبوطة على “trust”، إلا أن هناك ملفًا آخر في /etc/postgresql/13/main/ يحتوي على الإعدادات الافتراضية (“peer” / “md5”).
لقد قمت بتعديل /etc/postgresql/13/main/pg_hba.conf، وغيّرت جميع الطرق إلى trust، ثم نفذت d/shell وشغّلت sv restart postgres لتطبيق التغييرات – وتمكنت من المتابعة بتشغيل d/bundle install; d/rake db:migrate RAILS_ENV=development; d/rake admin:create يدويًا.