[devel] Q: jpp FTBFS packages in Sisyphus

[Mikhail Novosyolov]

05.04.2021 16:33, Dmitry V. Levin пишет:
> On Mon, Apr 05, 2021 at 03:21:29PM +0300, Mikhail Novosyolov wrote:
>> 05.04.2021 15:06, Alexey Gladkov пишет:
>>> On Mon, Apr 05, 2021 at 02:43:58PM +0300, Mikhail Novosyolov wrote:
>>>> 05.04.2021 01:06, Alexey Gladkov пишет:
>>>>>>> запаковали то, на чём мантейнер Х не справился. Во-первых,
>>>>>>> справляются с этой работой не копирующие роботы, а мантейнеры
>>>>>>> из другого дистра. Во-вторых, как показывает данная ситуация,
>>>>>>> мантейнер в сизифе в итоге всё равно нужен, чтобы разгребать
>>>>>>> проблемы мантейнеров в других дистрах помноженные на усердие
>>>>>>> роботов.
>>>>>> Так viy@ тихонько и разбирается, пока его поливают всем подряд
>>>>>> ничего тяжелее стокилограммовой штанги не пробовавшие.
>>>>> Да, я не ничего тяжёлого не поднимал. Отчасти потому, что считаю, что не
>>>>> нужно этого делать. Ну а viy@ я желаю удачи в подтирании пола за роботами.
>>>> У viy@ подтерто за роботами хорошо, судя по состоянию java в сизифе по
>>>> сравнению с Fedora, где опустились до просто копирования бинарных
>>>> пакетов без пересборки из релиза в релиз несколько релизов (т.к. 1+ лет)
>>>> подряд.
>>> Если бы с jpp всё было хорошо, то их бы не было в этом списке. Напомню,
>>> что у этих пакетов проблемы 25+ weeks.
>> А у них ХОРОШО, я считаю, не ОТЛИЧНО, но именно ХОРОШО. Глобальных проблем нет, а могли бы быть очень легко.
> OK, поскольку на вопрос, который я задал Игорю, отреагировали вы, а не
> он, интересно услышать вашу точку зрения, что делать с этим наследием
> без мантейнера, которое FTBFS 25+ weeks и должно быть удалено даже по
> нашим старым правилам, породив пачку новых FTBFS, удаление которых породит
> ещё большую пачку FTBFS, и так далее, пока наследия совсем не останется.

Мне кажется, в текущем стеке jpp нет каких-либо критичных проблем, которые могли бы быть поводом для паники (кроме, может быть, отсутствия активного мейнтейнера). Проблемы единичные.

В sbt проблема не в самом пакете sbt.

Попробовал запустить его сборку с помощью etersoft-build-utils в systemd-nspawn на сизифе от не-root и получил ошибку:

> + ./climbing-nemesis.py org.jsoup jsoup ivy-local --version 1.7.1
> Traceback (most recent call last):
>   File "/home/user/RPM/BUILD/sbt-0.13.1/./climbing-nemesis.py", line 232, in <module>
>     main()
>   File "/home/user/RPM/BUILD/sbt-0.13.1/./climbing-nemesis.py", line 217, in main
>     pom = resolveArtifact(args.group, args.artifact, args.pomfile, ignored_deps=(args.ignore or []), override=((not args.override_dir_only) and override or None), extra_deps=extra_deps)
>   File "/home/user/RPM/BUILD/sbt-0.13.1/./climbing-nemesis.py", line 127, in resolveArtifact
>     result = XMvnResolve.process_raw_request([ResolutionRequest(group, artifact, extension="pom")])[0]
>   File "/usr/lib/python3/site-packages/javapackages/xmvn/xmvn_resolve.py", line 67, in process_raw_request
>     raise XMvnResolveException("xmvn-resolve failed:\n" + stderr)
> javapackages.xmvn.xmvn_resolve.XMvnResolveException: xmvn-resolve failed:
>
> ошибка: Неверный код возврата из /tmp/.private/user/rpm-tmp.87022 (%prep)
Попробовал запустить просто xmvn-resolve, получил ошибку:

> [user на alt sbt]$ xmvn-resolve
> Error occurred during initialization of VM
> java.lang.OutOfMemoryError: unable to create new native thread
>     at java.lang.Thread.start0(Native Method)
>     at java.lang.Thread.start(Thread.java:717)
>     at java.lang.ref.Reference.<clinit>(Reference.java:232)
Пробую запустить от root в этом же контейнере:

> [root на alt sbt]# xmvn-resolve
> [root на alt sbt]# echo $?
> 0
Запустил пересборку sbt в сборочнице, ошибка опять другая:

> 2021-Apr-06 08:27:39 :: [x86_64] sbt-0.13.1-alt5_9.1jpp8.src.rpm: remote: build failed
> 2021-Apr-06 08:27:39 :: [x86_64] #100 sbt-0.13.1-alt5_9.1jpp8.src.rpm: build FAILED
> [ppc64le] Unhandled exception
> [ppc64le] java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext
> [ppc64le]     at org.fedoraproject.xmvn.tools.resolve.ResolverCli.parseRequests(ResolverCli.java:60)
Но в свой контейнер я ставил java с нуля, до установки BuildRequires sbt java вообще не стояла, поэтому на нехватку зависимостей не похоже.

Запустил rpmbb (etersoft-build-utils) у себя в контейнере от root. Такой ошибки не возникло, "+ ./climbing-nemesis.py org.jsoup jsoup ivy-local --version 1.7.1", на чем падало и у меня, и в сборочнице, прошло успешно, сборка пошла дальше.

Таким образом, проблема не в jpp пакетах.

> Может быть, вы готовы помантейнить это наследие?
Не готов, но готов по возможности и по силам как-то помочь тому, чтобы в Федоре и Альте java-стек был в хорошем и пригодном для частичного заимствования состоянии.