Binary distributions

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

لاحظ أنه بينما يكون كود جوليا هو MIT-licensed, with a few exceptions، فإن التوزيعة التي تم إنشاؤها بواسطة التقنيات الموضحة هنا ستكون مرخصة بموجب GPL، حيث أن المكتبات المعتمدة المختلفة مثل SuiteSparse مرخصة بموجب GPL. نأمل أن يكون لدينا توزيع غير GPL لجوليا في المستقبل.

Versioning and Git

يستخدم ملف Makefile كل من ملف VERSION وهاشات الالتزام والتسميات من مستودع git لإنشاء base/version_git.jl بمعلومات نستخدمها لملء شاشة البداية ونتيجة versioninfo(). إذا كنت لأسباب ما لا ترغب في توفر مستودع git أثناء البناء، يجب عليك توليد ملف base/version_git.jl مسبقًا باستخدام:

make -C base version_git.jl.phony

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

make full-source-dist

الذي ينشئ أرشيف julia-version-commit.tar.gz مع جميع التبعيات المطلوبة.

عند تجميع إصدار موسوم في مستودع git، لا نقوم بعرض معلومات الفرع/هاش الالتزام في شاشة البداية. يمكنك استخدام هذا السطر لعرض وصف الإصدار يصل إلى 45 حرفًا. لتعيين هذا السطر، يجب عليك إنشاء ملف Make.user يحتوي على:

override TAGGED_RELEASE_BANNER = "my-package-repository build"

Target Architectures

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

لذلك نوصي بأن تقوم بتمرير المتغير MARCH عند استدعاء make، مع تعيينه إلى الهدف الأساسي الذي تنوي دعمه. سيحدد هذا وحدة المعالجة المركزية المستهدفة لكل من التنفيذية جوليا والمكتبات، وصورة النظام (يمكن أيضًا تعيين الأخيرة باستخدام JULIA_CPU_TARGET). القيم المفيدة عادة لوحدات المعالجة المركزية x86 هي x86-64 و core2 (للبنيات 64 بت) و pentium4 (للبنيات 32 بت). للأسف، وحدات المعالجة المركزية الأقدم من Pentium 4 غير مدعومة حاليًا (انظر this issue).

يمكن الحصول على القائمة الكاملة لأهداف وحدة المعالجة المركزية المدعومة من قبل LLVM عن طريق تشغيل llc -mattr=help.

Linux

على نظام Linux، يقوم الأمر make binary-dist بإنشاء ملف tarball يحتوي على تثبيت كامل لوحدة Julia. إذا كنت ترغب في إنشاء حزمة توزيع مثل .deb أو .rpm، فستحتاج إلى بعض الجهد الإضافي. راجع مستودع julia-debian للحصول على مثال حول البيانات الوصفية المطلوبة لإنشاء حزم .deb لأنظمة Debian وUbuntu. راجع Fedora package للتوزيعات المعتمدة على RPM. على الرغم من أننا لم نجرب ذلك بعد، يمكن استخدام Alien لإنشاء حزم Julia لمختلف توزيعات Linux.

تدعم جوليا تجاوز أدلة التثبيت القياسية عبر prefix وغيرها من متغيرات البيئة التي يمكنك تمريرها عند استدعاء make و make install. راجع Make.inc للحصول على قائمة بها. يمكن أيضًا استخدام DESTDIR لفرض التثبيت في دليل مؤقت.

بشكل افتراضي، يقوم جوليا بتحميل $prefix/etc/julia/startup.jl كملف تهيئة على مستوى التثبيت. يمكن استخدام هذا الملف من قبل مديري التوزيع لإعداد مسارات مخصصة أو كود تهيئة. بالنسبة لحزم توزيعات لينكس، إذا تم تعيين $prefix إلى /usr، فلا يوجد /usr/etc للبحث فيه. يتطلب ذلك تغيير مسار دليل etc الخاص بجوليا. يمكن القيام بذلك عبر متغير sysconfdir عند البناء. ببساطة، مرر sysconfdir=/etc إلى make عند البناء وسيتحقق جوليا أولاً من /etc/julia/startup.jl قبل محاولة $prefix/etc/julia/startup.jl.

OS X

لإنشاء توزيع ثنائي على نظام OSX، قم أولاً ببناء Julia، ثم انتقل إلى contrib/mac/app، وشغل make بنفس متغيرات makevars التي تم استخدامها مع make عند بناء Julia بشكل صحيح. سيؤدي ذلك إلى إنشاء ملف .dmg في دليل contrib/mac/app يحتوي على تطبيق Julia.app مكتفي ذاتياً تمامًا.

بدلاً من ذلك، يمكن بناء جوليا كإطار عمل عن طريق استدعاء make مع الهدف darwinframework وضبط DARWIN_FRAMEWORK=1. على سبيل المثال، make DARWIN_FRAMEWORK=1 darwinframework.

Windows

تعليمات لإنشاء توزيع جوليا على نظام ويندوز موصوفة في build devdocs for Windows.

Notes on BLAS and LAPACK

تبني جوليا OpenBLAS بشكل افتراضي، والذي يتضمن مكتبات BLAS و LAPACK. على المعماريات ذات 32 بت، تبني جوليا OpenBLAS لاستخدام أعداد صحيحة بحجم 32 بت، بينما على المعماريات ذات 64 بت، تبني جوليا OpenBLAS لاستخدام أعداد صحيحة بحجم 64 بت (ILP64). من الضروري أن تستخدم جميع دوال جوليا التي تستدعي واجهات برمجة التطبيقات BLAS و LAPACK أعدادًا صحيحة بالحجم الصحيح.

تقدم معظم توزيعات BLAS و LAPACK المتاحة على توزيعات لينكس، وحتى التطبيقات التجارية، مكتبات تستخدم واجهات برمجة التطبيقات 32 بت. في العديد من الحالات، يتم توفير واجهة برمجة التطبيقات 64 بت كمكتبة منفصلة.

عند استخدام المكتبات المقدمة من البائع أو المكتبات المقدمة من نظام التشغيل، تتوفر خيار make يسمى USE_BLAS64 كجزء من بناء جوليا. عند تنفيذ make USE_BLAS64=0، ستقوم جوليا باستدعاء BLAS و LAPACK على افتراض واجهة برمجة تطبيقات 32 بت، حيث تكون جميع الأعداد الصحيحة بعرض 32 بت، حتى على بنية 64 بت.

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

يرجى ملاحظة أن توزيعات لينكس أحيانًا توفر عدة إصدارات من OpenBLAS، بعضها يتيح تعدد الخيوط، والبعض الآخر يعمل فقط بطريقة تسلسلية. على سبيل المثال، في فيدورا، libopenblasp.so تدعم التعدد، لكن libopenblas.so لا تدعم ذلك. نوصي باستخدام الأولى لتحقيق أداء مثالي. لاختيار مكتبة OpenBLAS التي تحمل اسمًا مختلفًا عن libopenblas.so الافتراضية، مرر LIBBLAS=-l$(YOURBLAS) و LIBBLASNAME=lib$(YOURBLAS) إلى make، مع استبدال $(YOURBLAS) باسم مكتبتك. يمكنك أيضًا إضافة .so.0 إلى اسم المكتبة إذا كنت تريد أن تعمل حزمةك دون الحاجة إلى الرابط الرمزي غير المرقم .so.

أخيرًا، يتضمن OpenBLAS نسخته المحسّنة من LAPACK. إذا قمت بتعيين USE_SYSTEM_BLAS=1 و USE_SYSTEM_LAPACK=1، يجب عليك أيضًا تعيين LIBLAPACK=-l$(YOURBLAS) و LIBLAPACKNAME=lib$(YOURBLAS). خلاف ذلك، سيتم استخدام LAPACK المرجعي وعادةً ما ستكون الأداء أقل بكثير.

بدءًا من Julia 1.7، تستخدم Julia libblastrampoline لاختيار BLAS مختلف في وقت التشغيل.

Point releasing 101

إنشاء إصدار نقطة/تصحيح يتكون من عدة خطوات مميزة.

Backporting commits

بعض طلبات السحب مُعلمة بـ "backport pending x.y"، على سبيل المثال "backport pending 0.6". هذا يشير إلى أن الإصدار التالي الذي يتم وضع علامة عليه من فرع release-x.y يجب أن يتضمن الالتزام (الالتزامات) في طلب السحب ذلك. بمجرد دمج طلب السحب في الفرع الرئيسي، يجب أن يتم cherry picked إلى فرع مخصص سيتم دمجه في النهاية في release-x.y.

Creating a backports branch

أولاً، أنشئ فرعًا جديدًا بناءً على release-x.y. القاعدة المعتادة لفروع جوليا هي إضافة بادئة باسم الفرع بأحرفك الأولى إذا كان من المقرر أن يكون فرعًا شخصيًا. على سبيل المثال، سنقول إن مؤلف الفرع هو جين سميث.

git fetch origin
git checkout release-x.y
git rebase origin/release-x.y
git checkout -b js/backport-x.y

هذا يضمن أن النسخة المحلية الخاصة بك من release-x.y محدثة مع الأصل قبل أن تقوم بإنشاء فرع جديد منها.

Cherry picking commits

الآن نقوم بعملية النقل الفعلية. ابحث عن جميع طلبات السحب المدمجة التي تحمل علامة "backport pending x.y" في واجهة ويب GitHub. لكل من هذه الطلبات، قم بالتمرير إلى الأسفل حيث يقول "someperson merged commit 123abc into master قبل XX دقيقة". لاحظ أن اسم الالتزام هو رابط؛ إذا نقرت عليه، ستظهر لك محتويات الالتزام. إذا كانت هذه الصفحة تظهر أن 123abc هو التزام دمج، عد إلى صفحة PR - لا نريد التزامات دمج، نريد الالتزامات الفعلية. ومع ذلك، إذا لم تظهر هذه الصفحة التزام دمج، فهذا يعني أن PR تم دمجه باستخدام السحق. في هذه الحالة، استخدم SHA git للالتزام، المدرج بجانب الالتزام في هذه الصفحة.

بمجرد أن تحصل على SHA من الالتزام، قم بعمل cherry-pick له على فرع النسخ الاحتياطي:

git cherry-pick -x -e <sha>

قد تكون هناك تعارضات تحتاج إلى حل يدوي. بمجرد حل التعارضات (إذا كانت قابلة للتطبيق)، أضف مرجعًا إلى طلب السحب في GitHub الذي قدم الالتزام في نص رسالة الالتزام.

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

Checking for performance regressions

يجب ألا تؤدي الإصدارات الفرعية إلى إدخال تدهور في الأداء. لحسن الحظ، يمكن لروبوت قياس الأداء في جوليا، نانوسولدير، تشغيل القياسات ضد أي فرع، وليس فقط الفرع الرئيسي. في هذه الحالة، نريد التحقق من نتائج القياس لـ js/backport-x.y مقابل release-x.y. للقيام بذلك، قم بإيقاظ نانوسولدير من سباته الروبوتي باستخدام تعليق على طلب السحب الخاص بك:

@nanosoldier `runbenchmarks(ALL, vs=":release-x.y")`

سيقوم هذا بتشغيل جميع المعايير المسجلة على release-x.y و js/backport-x.y وإنتاج ملخص للنتائج، مع وضع علامة على جميع التحسينات والانحدارات.

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

Building test binaries

بعد دمج طلب السحب الخاص بالنسخة القديمة في فرع release-x.y، قم بتحديث النسخة المحلية من جوليا، ثم احصل على SHA للفرع باستخدام

git rev-parse origin/release-x.y

احتفظ بذلك في متناول اليد، حيث ستقوم بإدخاله في حقل "المراجعة" في واجهة مستخدم buildbot.

لحد الآن، كل ما تحتاجه هو الثنائيات لنظام Linux x86-64، حيث إن هذا هو ما يُستخدم لتشغيل PackageEvaluator. انتقل إلى https://buildog.julialang.org، قدّم طلبًا لـ nuke_linux64، ثم قم بجدولة طلب لـ package_linux64، مع توفير SHA كالإصدار. عندما يكتمل طلب التعبئة، سيتم رفع الثنائي إلى دلو julialang2 على AWS. استرجع الرابط، حيث سيتم استخدامه لـ PackageEvaluator.

Checking for package breakages

يجب ألا تؤدي إصدارات النقاط إلى كسر الحزم، مع الاستثناء المحتمل للحزم التي تقوم ببعض الحيل المشكوك فيها باستخدام العناصر الداخلية لـ Base التي لا يُقصد بها أن تكون موجهة للمستخدم. (في تلك الحالات، ربما يجب التحدث مع مؤلف الحزمة.)

التحقق مما إذا كانت التغييرات التي تم إجراؤها في الإصدار الجديد القادم ستكسر الحزم يمكن أن يتم باستخدام PackageEvaluator، والذي يُطلق عليه غالبًا "PkgEval" باختصار. PkgEval هو ما يملأ شارات الحالة على مستودعات GitHub وعلى pkg.julialang.org. عادةً ما يعمل على أحد العقد غير المخصصة للاختبار في Nanosoldier ويستخدم Vagrant لأداء مهامه في آلات افتراضية منفصلة ومتوازية باستخدام VirtualBox.

Setting up PackageEvaluator

استنساخ PackageEvaluator وإنشاء فرع يسمى backport-x.y.z، ثم قم بتسجيل الخروج منه. لاحظ أن التغييرات المطلوبة قد تكون معقدة بعض الشيء ومربكة، ونأمل أن يتم معالجة ذلك في إصدار مستقبلي من PackageEvaluator. ستتم نمذجة التغييرات التي يجب إجراؤها على أساس this commit.

تأخذ سكريبت الإعداد أول وسيط كإصدار جوليا للتشغيل والثاني كنطاق أسماء الحزم (AK للحزم المسماة A-K، LZ للحزم المسماة L-Z). الفكرة الأساسية هي أننا سنقوم بتعديل ذلك قليلاً لتشغيل إصدارين فقط من جوليا، الإصدار الحالي x.y وإصدار النسخة الاحتياطية لدينا، كل منهما مع ثلاثة نطاقات من الحزم.

في الفرق المرتبط، نقول إنه إذا كانت الحجة الثانية هي LZ، استخدم الثنائيات المبنية من فرع التحديث الخاص بنا، وإلا (AK) استخدم الثنائيات المصدرة. ثم نستخدم الحجة الأولى لتشغيل قسم من قائمة الحزم: A-F للإدخال 0.4، G-N لـ 0.5، و O-Z لـ 0.6.

Running PackageEvaluator

لتشغيل PkgEval، ابحث عن جهاز قوي بما فيه الكفاية (مثل العقدة Nanosoldier 1)، ثم قم بتشغيل

git clone https://github.com/JuliaCI/PackageEvaluator.jl.git
cd PackageEvaluator.jl/scripts
git checkout backport-x.y.z
./runvagrant.sh

هذا ينتج بعض المجلدات في دليل scripts/. أسماء المجلدات ومحتوياتها موضحة أدناه:

Folder name	Julia version	Package range
0.4AK	Release	A-F
0.4LZ	Backport	A-F
0.5AK	Release	G-N
0.5LZ	Backport	G-N
0.6AK	Release	O-Z
0.6LZ	Backport	O-Z

Investigating results

بمجرد الانتهاء من ذلك، يمكنك استخدام ./summary.sh من نفس الدليل لإنتاج تقرير ملخص عن النتائج. سنقوم بذلك لكل من المجلدات لتجميع النتائج الإجمالية حسب الإصدار.

./summary.sh 0.4AK/*.json > summary_release.txt
./summary.sh 0.5AK/*.json >> summary_release.txt
./summary.sh 0.6AK/*.json >> summary_release.txt
./summary.sh 0.4LZ/*.json > summary_backport.txt
./summary.sh 0.5LZ/*.json >> summary_backport.txt
./summary.sh 0.6LZ/*.json >> summary_backport.txt

الآن لدينا ملفان، summary_release.txt و summary_backport.txt، يحتويان على نتائج اختبار PackageEvaluator (نجاح/فشل) لكل حزمة للإصدارين.

لجعل هذه الملفات أسهل في الاستخدام في جوليا، سنقوم بتحويلها إلى ملفات CSV ثم استخدام حزمة DataFrames لمعالجة النتائج. لتحويلها إلى CSV، انسخ كل ملف .txt إلى ملف .csv المقابل، ثم ادخل إلى Vim ونفذ ggVGI"<esc> ثم :%s/\.json /",/g. (ليس من الضروري استخدام Vim؛ هذه مجرد طريقة واحدة للقيام بذلك.) الآن قم بمعالجة النتائج باستخدام كود جوليا مشابه لما يلي.

using DataFrames

release = readtable("summary_release.csv", header=false, names=[:package, :release])
backport = readtable("summary_backport.csv", header=false, names=[:package, :backport])

results = join(release, backport, on=:package, kind=:outer)

for result in eachrow(results)
    a = result[:release]
    b = result[:backport]
    if (isna(a) && !isna(b)) || (isna(b) && !isna(a))
        color = :yellow
    elseif a != b && occursin("pass", b)
        color = :green
    elseif a != b
        color = :red
    else
        continue
    end
    printstyled(result[:package], ": Release ", a, " -> Backport ", b, "\n", color=color)
end

سيكتب هذا خطوطًا ملونة إلى stdout. يجب التحقيق في جميع الخطوط باللون الأحمر لأنها تشير إلى احتمالية حدوث أعطال ناجمة عن إصدار النسخة الخلفية. يجب النظر في الخطوط باللون الأصفر لأنها تعني أن حزمة ما تعمل على إصدار واحد ولكن ليس على الآخر لسبب ما. إذا وجدت أن فرع النسخة الخلفية الخاص بك يسبب أعطالًا، استخدم git bisect لتحديد الالتزامات المشكلة، وgit revert لتلك الالتزامات، وكرر العملية.

Merging backports into the release branch

بعد أن تأكدت من أن

تنجح الالتزامات المعادة في اجتياز جميع اختبارات الوحدة الخاصة بـ Julia،
لا توجد تدهورات في الأداء تم تقديمها من خلال الالتزامات المعادة كما هو الحال مقارنة بفرع الإصدار، و
التغييرات المعادة لا تكسر أي حزم مسجلة،

ثم يصبح فرع النسخ الاحتياطي جاهزًا ليتم دمجه في release-x.y. بمجرد دمجه، قم بالمرور وإزالة علامة "نسخ احتياطي معلق x.y" من جميع طلبات السحب التي تحتوي على الالتزامات التي تم نسخها احتياطيًا. لا تقم بإزالة العلامة من طلبات السحب التي لم يتم نسخها احتياطيًا.

يجب أن تحتوي فرع release-x.y الآن على جميع الالتزامات الجديدة. آخر شيء نريد القيام به في الفرع هو تعديل رقم الإصدار. للقيام بذلك، قدم طلب سحب ضد release-x.y الذي يعدل ملف VERSION لإزالة -pre من رقم الإصدار. بمجرد دمجه، نكون مستعدين لوضع العلامة.

Tagging the release

حان الوقت! تحقق من فرع release-x.y وتأكد من أن النسخة المحلية لديك من الفرع محدثة مع الفرع البعيد. في سطر الأوامر، قم بتشغيل

git tag v$(cat VERSION)
git push --tags

هذا ينشئ العلامة محليًا ويدفعها إلى GitHub.

بعد وضع علامة على الإصدار، قدم طلب سحب آخر إلى release-x.y لزيادة رقم التصحيح وإضافة -pre مرة أخرى إلى النهاية. هذا يدل على أن حالة الفرع تعكس إصدارًا مسبقًا من الإصدار التالي في سلسلة x.y.

اتبع التعليمات المتبقية في ملف Makefile.

Signing binaries

بعض هذه الخطوات ستتطلب كلمات مرور آمنة. للحصول على كلمات المرور المناسبة، اتصل بـ Elliot Saba (staticfloat) أو Alex Arslan (ararslan). لاحظ أن توقيع الشيفرة لكل منصة يجب أن يتم على تلك المنصة (على سبيل المثال، يجب أن يتم توقيع Windows على Windows، إلخ).

Linux

يجب أن يتم توقيع الشيفرة يدويًا على نظام Linux، لكنه بسيط جدًا. أولاً، احصل على الملف julia.key من مجلد CodeSigning في دلو juliasecure على AWS. أضف هذا إلى حلقة مفاتيح GnuPG باستخدام

gpg --import julia.key

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

gpg --edit-key julia

عند المطالبة، اكتب trust، ثم عندما يُطلب منك مستوى الثقة، قدم أعلى مستوى متاح (من المحتمل 5). اخرج من GnuPG.

الآن، لكل من ملفات tarballs الخاصة بـ Linux التي تم بناؤها على أجهزة البناء، أدخل

gpg -u julia --armor --detach-sig julia-x.y.z-linux-<arch>.tar.gz

سيؤدي هذا إلى إنتاج ملف .asc مطابق لكل أرشيف tarball. وهذا كل شيء!

macOS

يجب أن يحدث توقيع الشيفرة تلقائيًا على آلات البناء الخاصة بنظام macOS. ومع ذلك، من المهم التحقق من أنه كان ناجحًا. على نظام أو آلة افتراضية تعمل بنظام macOS، قم بتنزيل ملف .dmg الذي تم بناؤه على آلات البناء. على سبيل المثال، لنفترض أن ملف .dmg يسمى julia-x.y.z-osx.dmg. قم بتشغيل

mkdir ./jlmnt
hdiutil mount -readonly -mountpoint ./jlmnt julia-x.y.z-osx.dmg
codesign -v jlmnt/Julia-x.y.app

تأكد من ملاحظة اسم القرص المثبت المذكور عند التركيب! لأغراض المثال، سنفترض أن هذا هو disk3. إذا كانت عملية التحقق من توقيع الشيفرة قد انتهت بنجاح، فلن يكون هناك أي مخرجات من خطوة codesign. إذا كانت ناجحة بالفعل، يمكنك فصل .dmg الآن:

hdiutil eject /dev/disk3
rm -rf ./jlmnt

إذا تلقيت رسالة مثل

جوليا-x.y.app: كائن الشيفرة غير موقع على الإطلاق

ثم ستحتاج إلى التوقيع يدويًا.

لتوقيع يدويًا، أولاً استرجع شهادات OS X من مجلد CodeSigning في دلو juliasecure على AWS. أضف ملف .p12 إلى سلسلة المفاتيح الخاصة بك باستخدام Keychain.app. اطلب من إليوت سابا (staticfloat) أو أليكس أرسلان (ararslan) كلمة المرور للمفتاح. الآن قم بتشغيل

hdiutil convert julia-x.y.z-osx.dmg -format UDRW -o julia-x.y.z-osx_writable.dmg
mkdir ./jlmnt
hdiutil mount -mountpoint julia-x.y.z-osx_writable.dmg
codesign -s "AFB379C0B4CBD9DB9A762797FC2AB5460A2B0DBE" --deep jlmnt/Julia-x.y.app

قد يفشل هذا مع رسالة مثل

جوليا-x.y.app: لا يُسمح بوجود فرع الموارد، معلومات Finder، أو أي بقايا مشابهة

إذا كان هذا هو الحال، فستحتاج إلى إزالة السمات الزائدة:

xattr -cr jlmnt/Julia-x.y.app

ثم أعد محاولة توقيع الشيفرة. إذا لم ينتج عن ذلك أي أخطاء، أعد محاولة التحقق. إذا كان كل شيء على ما يرام الآن، قم بفصل .dmg القابل للكتابة وتحويله مرة أخرى إلى وضع القراءة فقط:

hdiutil eject /dev/disk3
rm -rf ./jlmnt
hdiutil convert julia-x.y.z-osx_writable.dmg -format UDZO -o julia-x.y.z-osx_fixed.dmg

تحقق من أن ملف .dmg الناتج قد تم إصلاحه بالفعل من خلال النقر المزدوج عليه. إذا كان كل شيء يبدو جيدًا، قم بإخراجه ثم احذف اللاحقة _fixed من الاسم. وهذا كل شيء!

Windows

يجب أن يتم التوقيع يدويًا على نظام Windows. أولاً، احصل على Windows 10 SDK، الذي يحتوي على الأدوات اللازمة للتوقيع، من موقع Microsoft. نحتاج إلى أداة SignTool التي يجب أن تكون قد تم تثبيتها في مكان ما مثل C:\Program Files (x86)\Windows Kits\10\App Certification Kit. احصل على ملفات الشهادة الخاصة بـ Windows من CodeSigning على juliasecure وضعها في نفس الدليل الذي توجد فيه الملفات التنفيذية. افتح نافذة CMD في Windows، وانتقل إلى حيث توجد جميع الملفات، ثم قم بتشغيل

set PATH=%PATH%;C:\Program Files (x86)\Windows Kits\10\App Certification Kit;
signtool sign /f julia-windows-code-sign_2017.p12 /p "PASSWORD" ^
   /t http://timestamp.verisign.com/scripts/timstamp.dll ^
   /v julia-x.y.z-win32.exe

لاحظ أن ^ هو حرف متابعة السطر في Windows CMD و PASSWORD هو عنصر نائب لكلمة المرور لهذه الشهادة. كما هو معتاد، اتصل بإيليوت أو أليكس للحصول على كلمات المرور. إذا لم تكن هناك أخطاء، فنحن بخير!

Uploading binaries

الآن بعد أن تم التوقيع على كل شيء، نحتاج إلى رفع الملفات الثنائية إلى AWS. يمكنك استخدام برنامج مثل Cyberduck أو أداة سطر الأوامر aws. يجب أن تذهب الملفات الثنائية إلى دلو julialang2 في المجلدات المناسبة. على سبيل المثال، يتم وضع Linux x86-64 في julialang2/bin/linux/x.y. تأكد من حذف ملف julia-x.y-latest-linux-<arch>.tar.gz الحالي واستبداله بنسخة من julia-x.y.z-linux-<arch>.tar.gz.

نحتاج أيضًا إلى رفع الشيكات لكل ما قمنا ببنائه، بما في ذلك ملفات المصدر المضغوطة وجميع ثنائيات الإصدار. هذا بسيط:

shasum -a 256 julia-x.y.z* | grep -v -e sha256 -e md5 -e asc > julia-x.y.z.sha256
md5sum julia-x.y.z* | grep -v -e sha256 -e md5 -e asc > julia-x.y.z.md5

لاحظ أنه إذا كنت تقوم بتشغيل تلك الأوامر على macOS، فستحصل على مخرجات مختلفة قليلاً، والتي يمكن إعادة تنسيقها من خلال النظر إلى ملف موجود. سيحتاج مستخدمو Mac أيضًا إلى استخدام md5 -r بدلاً من md5sum. قم بتحميل ملفات .md5 و .sha256 إلى julialang2/bin/checksums على AWS.

تأكد من أن الأذونات على AWS لجميع الملفات المرفوعة مضبوطة على "الجميع: قراءة."

لكل ملف قمنا بتحميله، نحتاج إلى مسح ذاكرة التخزين المؤقت لـ Fastly حتى تشير الروابط على الموقع إلى الملفات المحدثة. كمثال:

curl -X PURGE https://julialang-s3.julialang.org/bin/checksums/julia-x.y.z.sha256

أحيانًا لا يكون هذا ضروريًا ولكن من الجيد القيام به على أي حال.