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@.
Пользователь добавлен в группу мантейнеров.

Желаю удачного мантейнерства!

Всем спасибо! :)