Re: [devel] [#263468] EPERM (try 14) llvm-common.git=11.0.0-alt2 srpm=llvm11.0-11.0.0-alt2.src.rpm

[Arseny Maslennikov <arseny@altlinux.org>]

[-- Attachment #1: Type: text/plain, Size: 10746 bytes --]

On Mon, Jan 11, 2021 at 10:41:00PM +0100, Konstantin Lepikhov wrote:
> Hi Arseny!
> 
> On 01/11/2021, at 07:38:51 PM you wrote:
> 
> <skip>
> > > а так ли нужны все эти приседания с версиями и rc? У нас же не daily
> > > builds собираются.
> > 
> > До поры до времени.
> > Начинать готовить адаптацию спека лучше с каких-то достаточно поздних
> > rc, особенно в случае, когда после выхода времени у мейнтейнера мало, а
> > чуть раньше — много.
> а мы куда то спешим?

Самая важная причина, по которой я начал миграцию llvm в собственный
префикс — в том, что разным пакетам, в т. ч. пакетам-тулчейнам, требуются
llvm разной мажорной версии в одном репозитории, потому что они написаны
с расчётом на конкретную мажорную версию, и в том, что пользователи
не-мейнтейнеры хотели бы иметь в репозитории свежий clang и иногда
старый clang. Я не планирую сборку rc в репозиторий, но вот test-only
задания — почему нет, если так будет удобно.

> 
> > 
> > > 
> > > > +%global llvm_name llvm%v_majmin
> > > > +%global clang_name clang%v_majmin
> > > > +%global clangd_name clangd%v_majmin
> > > > +%global lld_name lld%v_majmin
> > > т.е. планируется собирать раздельные версии clang/llvm/lld?

на всякий случай уточню: я понял эти слова так, что в репозитории могут
сосуществовать clang-11, clang-12 и clang-10, lld-11, lld-12 и lld-10, и
да, разные мажорные версии собираются не из одного исходного пакета.

> > 
> > не в рамках одного исходного пакета.
> Я знаю, что в Fedora/Arch так делают, поэтому и спросил. Еще у нас есть
> lav@ который собирает все что находит - 
> 
> https://bugzilla.altlinux.org/show_bug.cgi?id=33411
> https://bugzilla.altlinux.org/show_bug.cgi?id=34672
> 
> Тут все еще есть нерешенная проблема - чего мы хотим достигнуть с llvm в
> сизифе? Конкурентный toolchain или еще одну библиотеку для сборки пакета
> xyz.

И то, и другое.
И не только тулчейн, там ещё много всего интересного.

> 
> > 
> > <...>
> > 
> > > >  %def_disable tests
> > > >  %ifarch x86_64 aarch64
> > > >  %def_without clang
> > > почему? without_clang используется только если у нас bootstrap. Иначе
> > > будет сборка без LTO.
> > 
> > Внимательно посмотрите changelog и архив.
> > 
> > Одна из возможных причин:
> > http://git.altlinux.org/people/arseny/packages/?p=llvm11.0.git;a=commit;h=4b3c6c13e4d70fd201691c636d57b5b020e00709
> > Надо думать, что с этим делать.
> Наверное, уведомить апстрим?
> 
> Еще неплохо прояснить вот этот баг
> https://bugzilla.altlinux.org/show_bug.cgi?id=34672

_Лично мне_ libcxx не слишком интересна до тех пор, пока с ней не будет
иметь смысл собирать (асимптотически) всё, что ныне может быть собрано с
libstdc++, и держать такие пакеты в рамках одной инсталляции ОС.
Когда-то clang вообще не конкурировал с gcc на том, что ещё пока принято
называть гнулинуксами; сейчас, в общем, монокультуры уже нет. О
подробностях и прогнозах тут не буду.
(Вскользь припомню только недавний порыв пассионарных googlers добавить
под зонтик llvm ещё и собственную libc, от чего их отговорило сообщество
musl. А где libc, там и elfutils, и dynamic linker.)

Собирать её в рамках llvm-экосистемы в репозитории и брать
ответственность за её работоспособность _лично я_ точно не в силах и не
хочу; если только договориться с теми, кому она нужна.

> 
> > разве тут что-то неверно?
> > старый description был слишком неточным и подходил к нескольким бинарным
> > пакетам.
> по мне масло маслянное ну да ладно.
> 
> <skip>
> > > Почему нам нужны все TARGETS?
> > 
> > Я скоро буду собирать пакеты, которые этим будут пользоваться.
> > 
> > Ну, и для "clang -target aarch64-unknown-linux-gnu" какого-нибудь.
> все таргеты это время сборки, потенциально сваленные тесты и т.д. Более
> того, предлагается все эти таргеты поддерживать?

В рамках того, что умеет их апстрим.

В случае необходимости бутстрапа можно решить собирать только host, а
потом им собирать all.

> 
> > Вот тут написано, почему man1dir не лишний:
> > 
> > > > +# Symlink man pages to the man dirs.
> > > > +for mand in %buildroot%llvm_datadir/man/man*; do
> > > > +	mand_index="${mand##*/man}"
> > > > +	for m in "$mand"/*.[1-9]*; do
> > > > +		# Let's force compress the man page, then symlink it.
> > > > +		# /usr/lib/llvm-11.0/share/man/manD/utilX.D.xz -> /usr/share/man/manD/utilX-11.D.xz
> > > > +		# Otherwise, brp-alt(compress) keeps fucking us up.
> > > > +		# It remakes the symlinks first, then compresses their targets,
> > > > +		# severing the symlinks.
> > > > +		/usr/lib/rpm/compress_files "$m"
> > > > +
> > > > +		mb="$(basename "$m")" # e. g. llvm-ar.1.xz
> > > > +		new_mb="${mb%%.[1-9]*}-%v_major.$mand_index" # e. g. llvm-ar-11.1.xz
> > > > +
> > > > +		mkdir -p "%buildroot%_mandir/man$mand_index"
> > > > +		ln -srv "$m" "%buildroot%_mandir/man$mand_index/$new_mb"
> > > > +	done
> > > > +done
> Ну так костыль жеж. У нас тут есть мантейнеры rpm, почему они не помогают?
> :)

Помогут — уберём. :)

А пока — надо было достичь готового пакета с
удовлетворительным (а лучше — хорошим) результатом; это лучше, чем
полгода искать время подготовить исправление и проталкивать его ещё 9
месяцев.

Со слов автора /usr/lib/rpm/compress_files, этот старый код надо
как-нибудь познакомить с xz и zstd, а то и переосмыслить.

> 
> <skip>
> > man не смотрит в llvm_man1dir.
> > Заморочиться и научить — вариант хуже, чем текущий, потому что программе
> > man надо ещё ман от правильной версии достать.
> я понимаю ваше желание сделать все красиво, но этот пакет могут
> поддерживать другие люди и хотелось бы, чтобы эта поддержка была вот без

(Note to self: мне надо бы подробно расписать в каком-то публичном
месте, что делает пакет llvm-common, как и зачем, как раз для других людей и
приравненного к ним будущего себя.)

У себя в packages я подробно веду git-историю всего, что происходит со
спеком, с пояснением, почему. Правда, её не видно в
git.altlinux.org/srpms...
В самом спеке около каждого дредноута я кратко пишу, зачем он.

Надо бы собирать из gear, но с использованием апстримных тарболлов, без
мучительной перепаковки.
В инструментарии gear у нас есть gear-import, а вот, например, такого
нет:
    tar.xz clang name=clang-@version@.src origin=https://github.com/llvm/llvm-project/releases/download/llvmorg-@version@/clang-@version@.src.tar.xz

Тогда gear мог бы взять локально закешированный тарболл, выкачанный
оттуда, и при составлении исходного пакета его использовать.
При этом тарболл распакован в git-репозиторий, с каталогом можно
работать средствами git.

> таких объездов, особенно, если тут есть те, кто могут помочь и исправить
> rpm/gear/whatever.
> 
> PS До сих пор собираю новую версию postfix вот именно из-за таких
> прекрасных патчей и .spec которые, конечно, собирают в результате
> космический дрендноут, но уж очень неподдерживаемые.

Я где-то краем уха слышал, что мейнтейнеры сами недовольны сложившейся
ситуацией, но забрасывать дрындноут не готовы, и ребейзить его тоже
некогда.

> 
> PPS Огромное спасибо вам, что не бросаете работу и таки собрали пакет!
:)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]