Псевдоним: garmr Адрес пересылки: coffe92@gmail.com Имя ментора: Глеб Фотенгауэр-Малиновский Хочу собрать пакет ROOT 6 (root.cern.ch), а так же если возможно, собрать другие пакеты в области физики. Так же хочу устроиться к вам на работу :)
Created attachment 7624 [details] ssh key
Created attachment 7625 [details] gpg key
Прошу прощения, я ошибся в псевдониме, который написал в тексте. gpg ключ я генерировал для псевдонима: arei Только сейчас заметил это.
Было решено вместо ROOT-6 собрать radare2 (http://radare.org/r/). В процессе написания spec файла и попытки сборки rpm пакета были обнаружены и исправлены (написаны патчи) проблемы в radare2-2.6.0. Первая проблема была связана функцией libpath-to-name внутри libr/config.mk.tail - не выполнялась проверка на наличие '/' в аргументе, в следствии чего при копировании имя библиотеки libr.so изменялось в .2.6.0. Для исправления была сделана дополнительная проверка (см. fix_libr_install.patch) Вторая проблема связана с тем, что во время сборки библиотеки libr.so не выполнялась линковка libutil.so. Исправление представлено в патче fix_libr_ldflags.patch spec файл radare2.spec был собран и протестирован с помощью hasher. При проверке sisyphus-check ошибок обнаружено не было.
Created attachment 7632 [details] spec файл к radare2 (old)
Created attachment 7633 [details] патч для libr/config.mk.tail
Created attachment 7634 [details] патч к libr/Makefile
(В ответ на комментарий №4) > Было решено вместо ROOT-6 собрать radare2 (http://radare.org/r/). > В процессе написания spec файла и попытки сборки rpm пакета были обнаружены и > исправлены (написаны патчи) проблемы в radare2-2.6.0. > Первая проблема была связана функцией libpath-to-name внутри > libr/config.mk.tail - не выполнялась проверка на наличие '/' в аргументе, в > следствии чего при копировании имя библиотеки libr.so изменялось в .2.6.0. Для > исправления была сделана дополнительная проверка (см. fix_libr_install.patch) > Вторая проблема связана с тем, что во время сборки библиотеки libr.so не > выполнялась линковка libutil.so. Исправление представлено в патче > fix_libr_ldflags.patch > > spec файл radare2.spec был собран и протестирован с помощью hasher. При > проверке sisyphus-check ошибок обнаружено не было. Для информации. radare2 для сборки использует дизассемблер capstone который берёт из репозитория гит. Поэтому hasher нужен доступ в сеть: $: share_network=1 hsh HASHER_REPO SRPM
(In reply to comment #8) > Для информации. > radare2 для сборки использует дизассемблер capstone который берёт из > репозитория гит. Поэтому hasher нужен доступ в сеть: > $: share_network=1 hsh HASHER_REPO SRPM В Сизиф такое собрать не получится; всё, что во время сборки скачивается по сети, должно быть скачано и доступно для сборки.
Обычно это достигается сборкой требуемого тоже пакетом, прописыванием в BuildRequires: и разбандливанием (штатно или предоставленным заодно апстриму патчем).
В пакете radare2 есть возможность использовать системный capstone при указании --with-syscapstone флага в скрипт configure. Я решил создать отдельный пакет capstone, написал spec файл и выполнил компиляцию rpm пакета при помощи rpmbuild -ba. Однако при компиляции пакета в hasher я столкнулся со следующей проблемой. Для компиляции capstone нужен пакет java-devel, например java-1.7.0-openjdk-devel. При компиляции rpm пакета с помощью rpmbuild в процессе выполнения команды javac никаких ошибок не возникает. Но при использовании hasher возникает ошибка на стадии работы javac: javac: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory При этом эта библиотека есть и лежит (доступна как в hasher так и в хост системе) /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.79-2.5.5.0.x86_64/jre/lib/amd64/jli/libjli.so В самой системе alt javac прекрасно работает: > ldd /usr/bin/javac linux-vdso.so.1 (0x00007fff2e7e7000) libjli.so => /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.79-2.5.5.0.x86_64/jre/lib/amd64/jli/libjli.so (0x00007f8de7f41000) libc.so.6 => /lib64/libc.so.6 (0x00007f8de7b9e000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f8de799a000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8de777d000) libz.so.1 => /lib64/libz.so.1 (0x00007f8de7565000) /lib64/ld-linux-x86-64.so.2 (0x00007f8de814f000) А вот в hasher: + ldd /usr/bin/javac linux-vdso.so.1 (0x00007fffdfb7f000) libjli.so => not found libc.so.6 => /lib64/libc.so.6 (0x00007feeafe7d000) /lib64/ld-linux-x86-64.so.2 (0x00007feeb0220000) Я пытаюсь разобраться в этой проблеме какое-то время, но пока без результатов. Подскажите, если вы знаете, в какую сторону нужно смотреть?
(In reply to comment #11) > + ldd /usr/bin/javac > linux-vdso.so.1 (0x00007fffdfb7f000) > libjli.so => not found > libc.so.6 => /lib64/libc.so.6 (0x00007feeafe7d000) > /lib64/ld-linux-x86-64.so.2 (0x00007feeb0220000) > > Я пытаюсь разобраться в этой проблеме какое-то время, но пока без результатов. > Подскажите, если вы знаете, в какую сторону нужно смотреть? Скорее всего, вы не разрешили hasher'у смонтировать /proc, без которого java не java.
https://www.altlinux.org/Hasher/%D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE#.D0.9C.D0.BE.D0.BD.D1.82.D0.B8.D1.80.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D0.B5_.2Fproc
Created attachment 7637 [details] spec файл к radare2
Created attachment 7638 [details] spec файл к capstone disassembler
Дмитрий, Михаил, большое спасибо за ответы. Действительно дело оказалось в том, что я не монтировал /proc. Я изменил spec файл к radare2, добавил зависимость от capstone-devel и добавил изменение строчки libr/Makefile отвечающей за путь к libcapstone.a, которая была hard-coded на bundled версию capstone. Так же я создал и протестировал на hasher spec файл для сборки capstone (см. приложение) который используется radare2.
ssh ключ на gitery.alt зарегистрирован. ssh ключ на gyle.alt зарегистрирован. Адрес для пересылки создан. T/J/S -> 3.0.
(In reply to comment #14) > Created an attachment (id=7637) [details] > spec файл к radare2 По традиции, тэги пишутся с заглавной буквы (Name, Version, Release, и т.п.). Комментарии пишут к тому, что нуждается в комментарии; тэги, которые есть в каждом спеке, лучше не комментировать. Точка в конце Summary указывать не следует. BuildRequires странный, содержит пакеты, которые всегда присутствуют в сборочной среде, а также пакеты, которые на самом деле не нужны для сборки. У нас нет полиси указывать provides: bundled(). Нужны веские основания использовать носимые с собой zlib, lz4, и magic вместо системных. Вместо %dir %{_datadir}/%{name}/%{version} %{_datadir}/%{name}/%{version}/* можно написать %{_datadir}/%{name}/%{version}/ аналогичную замену можно сделать и в других местах.
Зафиксировал хотя бы в https://www.altlinux.org/Обсуждение:Spec
(В ответ на комментарий №18) > (In reply to comment #14) > Вместо > %dir %{_datadir}/%{name}/%{version} > %{_datadir}/%{name}/%{version}/* > можно написать > %{_datadir}/%{name}/%{version}/ > аналогичную замену можно сделать и в других местах. ...а затем напустить cleanup_spec и получить наконец %_datadir/%name/%version/
Created attachment 7656 [details] radare2 2.7 RPM spec file
Created attachment 7657 [details] capstone disassembler RPM spec file
Спасибо за замечания! Я исправил стилистическую часть spec файлов (см. radare2 2.7 RPM spec file, capstone disassembler RPM spec file). Вчера вышла новая версия radare2-2.7, поэтому я взял теперь её за основу пакета radare2. В ней были исправлены проблемы с libr/Makefile поэтому патчи которые я прикладывал для версии 2.6 больше не нужны. Кроме этого, я исправил build requirements, вроде бы убрал все ненужные зависимости. Убрал Bundled lz4, zlib и magic, в configure скрипте есть возможность использовать их как внешние зависимости. Однако для того, чтобы убрать остальные bundled, необходимо, как я понимаю, существенно менять код самой программы. * sdb - (https://github.com/radare/sdb) разработка команды radare, которая вшита в код radare2 * js0n - (https://github.com/quartzjer/js0n) они используют свою версию этой программы * openbsdregex - они используют свою версию OpenBSD реализации regex * tcc - их "обрезанная" версия tcc * binutils - они используют части кода из binutils * vavrdisasm - они вытащили куски кода из vAVRdisasm написанный Vanya A. Sergeev - <vsergeev@gmail.com>
Пакет alt-gpgkeys обновлён. T/J/S -> 4.0.
Можно завершить приём.
(В ответ на комментарий №25) > Можно завершить приём. Поздравляю! :)
Адрес подписан на devel@. Пользователь добавлен в группу мантейнеров. Желаю удачного мантейнерства!
Всем спасибо! :)
