[devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Valery Sinelnikov]

Добрый день.

Не получается пройти тесты сборочницы для пакета virtualbox:
http://git.altlinux.org/tasks/264125/

Ранее об этом уже упоминалось:
https://lists.altlinux.org/pipermail/devel/2020-September/211991.html

Начиная с версии 6.1.14 несколько .r0 файлов, ранее являвшихся .o
компилируется, как .so, и в них есть необъявленные символы (они
необходимы для работы, связанной со спецификой программы и ее
внутренней архитектурой).

Попытка переложить эти файлы (VBoxDDR0.r0 и VMMR0.r0) в отдельный
каталог /usr/lib64/virtualbox/private эффекта не даёт - сборочница
проверяет рекурсивно:
[x86_64 i586] ELF symbols check FAILED

Попытка переложить их в %_datadir, тоже эффекта не даёт:
verify-elf: ERROR: ./usr/share/virtualbox/VBoxDDR0.r0: ELF object out
of allowed directory tree

Каким образом можно решить эту проблему?

PS: Обновление virtualbox задерживает обновление драйверов для ядер 5.9 и выше.

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Dmitry V. Levin]

On Mon, Dec 28, 2020 at 04:39:37PM +0400, Valery Sinelnikov wrote:
> Добрый день.
> 
> Не получается пройти тесты сборочницы для пакета virtualbox:
> http://git.altlinux.org/tasks/264125/
> 
> Ранее об этом уже упоминалось:
> https://lists.altlinux.org/pipermail/devel/2020-September/211991.html
> 
> Начиная с версии 6.1.14 несколько .r0 файлов, ранее являвшихся .o
> компилируется, как .so, и в них есть необъявленные символы (они
> необходимы для работы, связанной со спецификой программы и ее
> внутренней архитектурой).
> 
> Попытка переложить эти файлы (VBoxDDR0.r0 и VMMR0.r0) в отдельный
> каталог /usr/lib64/virtualbox/private эффекта не даёт - сборочница
> проверяет рекурсивно:
> [x86_64 i586] ELF symbols check FAILED
> 
> Попытка переложить их в %_datadir, тоже эффекта не даёт:
> verify-elf: ERROR: ./usr/share/virtualbox/VBoxDDR0.r0: ELF object out
> of allowed directory tree
> 
> Каким образом можно решить эту проблему?

Это скорее к вам вопрос.


-- 
ldv

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Anton V. Boyarshinov]

В Mon, 28 Dec 2020 15:57:31 +0300
"Dmitry V. Levin" <ldv@altlinux.org> пишет:

> On Mon, Dec 28, 2020 at 04:39:37PM +0400, Valery Sinelnikov wrote:
> > Добрый день.
> > 
> > Не получается пройти тесты сборочницы для пакета virtualbox:
> > http://git.altlinux.org/tasks/264125/
> > 
> > Ранее об этом уже упоминалось:
> > https://lists.altlinux.org/pipermail/devel/2020-September/211991.html
> > 
> > Начиная с версии 6.1.14 несколько .r0 файлов, ранее являвшихся .o
> > компилируется, как .so, и в них есть необъявленные символы (они
> > необходимы для работы, связанной со спецификой программы и ее
> > внутренней архитектурой).
> > 
> > Попытка переложить эти файлы (VBoxDDR0.r0 и VMMR0.r0) в отдельный
> > каталог /usr/lib64/virtualbox/private эффекта не даёт - сборочница
> > проверяет рекурсивно:
> > [x86_64 i586] ELF symbols check FAILED
> > 
> > Попытка переложить их в %_datadir, тоже эффекта не даёт:
> > verify-elf: ERROR: ./usr/share/virtualbox/VBoxDDR0.r0: ELF object out
> > of allowed directory tree
> > 
> > Каким образом можно решить эту проблему?  
> 
> Это скорее к вам вопрос.

Совет сколь полный, столь и бесполезный. Так как никто не может дать
более осмысленного, у нас в p9 неподдерживаемое древнее ядро un-def.

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Антон Мидюков]

28.12.2020 20:50, Anton V. Boyarshinov пишет:
> В Mon, 28 Dec 2020 15:57:31 +0300
> "Dmitry V. Levin" <ldv@altlinux.org> пишет:
> 
>> On Mon, Dec 28, 2020 at 04:39:37PM +0400, Valery Sinelnikov wrote:
>>> Добрый день.
>>>
>>> Не получается пройти тесты сборочницы для пакета virtualbox:
>>> http://git.altlinux.org/tasks/264125/
>>>
>>> Ранее об этом уже упоминалось:
>>> https://lists.altlinux.org/pipermail/devel/2020-September/211991.html
>>>
>>> Начиная с версии 6.1.14 несколько .r0 файлов, ранее являвшихся .o
>>> компилируется, как .so, и в них есть необъявленные символы (они
>>> необходимы для работы, связанной со спецификой программы и ее
>>> внутренней архитектурой).
>>>
>>> Попытка переложить эти файлы (VBoxDDR0.r0 и VMMR0.r0) в отдельный
>>> каталог /usr/lib64/virtualbox/private эффекта не даёт - сборочница
>>> проверяет рекурсивно:
>>> [x86_64 i586] ELF symbols check FAILED
>>>
>>> Попытка переложить их в %_datadir, тоже эффекта не даёт:
>>> verify-elf: ERROR: ./usr/share/virtualbox/VBoxDDR0.r0: ELF object out
>>> of allowed directory tree
>>>
>>> Каким образом можно решить эту проблему?  
>>
>> Это скорее к вам вопрос.
> 
> Совет сколь полный, столь и бесполезный. Так как никто не может дать
> более осмысленного, у нас в p9 неподдерживаемое древнее ядро un-def.

По поводу un-def в p9. Ядру версии 5.10 от virtualbox нужен только модуль хоста, дополнения не нужны.
Чем иметь совсем неподдерживаемое в p9 ядро, не лучше ли собрать без kernel-modules-virtualbox-un-def пока? 

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Dmitry V. Levin]

On Mon, Dec 28, 2020 at 04:50:32PM +0300, Anton V. Boyarshinov wrote:
> В Mon, 28 Dec 2020 15:57:31 +0300, Dmitry V. Levin пишет:
> > On Mon, Dec 28, 2020 at 04:39:37PM +0400, Valery Sinelnikov wrote:
> > > Добрый день.
> > > 
> > > Не получается пройти тесты сборочницы для пакета virtualbox:
> > > http://git.altlinux.org/tasks/264125/
> > > 
> > > Ранее об этом уже упоминалось:
> > > https://lists.altlinux.org/pipermail/devel/2020-September/211991.html
> > > 
> > > Начиная с версии 6.1.14 несколько .r0 файлов, ранее являвшихся .o
> > > компилируется, как .so, и в них есть необъявленные символы (они
> > > необходимы для работы, связанной со спецификой программы и ее
> > > внутренней архитектурой).
> > > 
> > > Попытка переложить эти файлы (VBoxDDR0.r0 и VMMR0.r0) в отдельный
> > > каталог /usr/lib64/virtualbox/private эффекта не даёт - сборочница
> > > проверяет рекурсивно:
> > > [x86_64 i586] ELF symbols check FAILED
> > > 
> > > Попытка переложить их в %_datadir, тоже эффекта не даёт:
> > > verify-elf: ERROR: ./usr/share/virtualbox/VBoxDDR0.r0: ELF object out
> > > of allowed directory tree
> > > 
> > > Каким образом можно решить эту проблему?  
> > 
> > Это скорее к вам вопрос.
> 
> Совет сколь полный, столь и бесполезный.

Это не совет, это вопрос.


-- 
ldv

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Anton V. Boyarshinov]

> По поводу un-def в p9. Ядру версии 5.10 от virtualbox нужен только модуль хоста, дополнения не нужны.
> Чем иметь совсем неподдерживаемое в p9 ядро, не лучше ли собрать без kernel-modules-virtualbox-un-def пока? 

Модуль хоста из имеющегося там virtualbox тоже не собирается с 5.10. А
новый virtualbox не проходит наши проверки.

Если я правильно понимаю, недостающие символы должны браться как раз из
ядрерных модулей (я ещё не завершил знакомство с ситуацией и могу
ошибаться).

Можно, конечно, соорудить hackaround, написав и собрав (в отдельный
подпакет?) библиотеку, которая будет предоставлять необходимые символы,
но хотелось бы найти более прямой способ протащить этот пакет через
сборочницу.

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Anton V. Boyarshinov]

В Mon, 28 Dec 2020 17:11:51 +0300
"Dmitry V. Levin" <ldv@altlinux.org> пишет:

> > > > Каким образом можно решить эту проблему?    
> > > 
> > > Это скорее к вам вопрос.  
> > 
> > Совет сколь полный, столь и бесполезный.  
> 
> Это не совет, это вопрос.

Мне кажется, если человек просит помощи, то он не справляется сам и ему
требуется помощь более опытных членов команды.

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Dmitry V. Levin]

On Mon, Dec 28, 2020 at 05:24:25PM +0300, Anton V. Boyarshinov wrote:
> В Mon, 28 Dec 2020 17:11:51 +0300, Dmitry V. Levin пишет:
> 
> > > > > Каким образом можно решить эту проблему?    
> > > > 
> > > > Это скорее к вам вопрос.  
> > > 
> > > Совет сколь полный, столь и бесполезный.  
> > 
> > Это не совет, это вопрос.
> 
> Мне кажется, если человек просит помощи, то он не справляется сам и ему
> требуется помощь более опытных членов команды.

С сожалению, в этой теме нужна в первую очередь (и во вторую тоже)
экспертиза в virtualbox'е.


-- 
ldv

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Anton V. Boyarshinov]

В Mon, 28 Dec 2020 17:30:50 +0300
"Dmitry V. Levin" <ldv@altlinux.org> пишет:

> > > > > > Каким образом можно решить эту проблему?      
> > > > > 
> > > > > Это скорее к вам вопрос.    
> > > > 
> > > > Совет сколь полный, столь и бесполезный.    
> > > 
> > > Это не совет, это вопрос.  
> > 
> > Мне кажется, если человек просит помощи, то он не справляется сам и ему
> > требуется помощь более опытных членов команды.  
> 
> С сожалению, в этой теме нужна в первую очередь (и во вторую тоже)
> экспертиза в virtualbox'е.

Не факт. Эти символы и раньше были unresolved с точки зрения
нашей сборочницы, просто удачным образом прятоались в  
ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped

И virtualbox их как-то внутри себя загадочным образом находил.

Поскольку это проприретарщина, возможно ему самое место тут:
---------------------
if [ "$rc" = 1 ]; then
        # This list should include only proprietry binary drivers.
        cat >allow-bad-p <<'EOF'
^fglrx_glx(-legacy)?-[[:digit:]][^[:space:]]+[[:space:]]+(/usr/lib(64)?/(X11/(fglrx/lib(dri|glx)|modules/(drivers/fglrx_drv|amdxmm|glesx))|libatiadlxx)\.so|/usr/lib/libAMDXvBA\.so\.1\.0)[[:space:]]
^nvidia_glx_[[:digit:]][^[:space:]]+[[:space:]]+/usr/lib(64)?/nvidia_[[:digit:]][^[:space:]/]+/[^[:space:]/]+\.so[[:space:]]
^xorg-drv-nvidia-[[:digit:]][^[:space:]]+[[:space:]]+/usr/lib(64)?/X11/(libglx-nvidia|modules/drivers/nvidia_drv)\.so[[:space:]]
EOF
--------------------

И мне кажется, тебе было бы быстрее чем мне найти это место и хотя бы
написать что-нибудь вроде "у нас есть список исключений, но я не хочу
добавлять его туда".

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Dmitry V. Levin]

On Mon, Dec 28, 2020 at 05:36:05PM +0300, Anton V. Boyarshinov wrote:
> В Mon, 28 Dec 2020 17:30:50 +0300, Dmitry V. Levin пишет:
> 
> > > > > > > Каким образом можно решить эту проблему?      
> > > > > > 
> > > > > > Это скорее к вам вопрос.    
> > > > > 
> > > > > Совет сколь полный, столь и бесполезный.    
> > > > 
> > > > Это не совет, это вопрос.  
> > > 
> > > Мне кажется, если человек просит помощи, то он не справляется сам и ему
> > > требуется помощь более опытных членов команды.  
> > 
> > С сожалению, в этой теме нужна в первую очередь (и во вторую тоже)
> > экспертиза в virtualbox'е.
> 
> Не факт. Эти символы и раньше были unresolved с точки зрения
> нашей сборочницы, просто удачным образом прятоались в  
> ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
> 
> И virtualbox их как-то внутри себя загадочным образом находил.
> 
> Поскольку это проприретарщина, возможно ему самое место тут:

Это ещё и проприетарная блобятина?


-- 
ldv

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Anton V. Boyarshinov]

В Mon, 28 Dec 2020 17:42:41 +0300
"Dmitry V. Levin" <ldv@altlinux.org> пишет:

> > Не факт. Эти символы и раньше были unresolved с точки зрения
> > нашей сборочницы, просто удачным образом прятоались в  
> > ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
> > 
> > И virtualbox их как-то внутри себя загадочным образом находил.
> > 
> > Поскольку это проприретарщина, возможно ему самое место тут:  
> 
> Это ещё и проприетарная блобятина?

Она не блобятина, она собирается из исходников. Но по способу
разработки -- проприретарная, нам не удастся убедить Оракл обеспечивать
линковку этих файлов более прямым образом, чем это делается сейчас.

И тратить время и силы на то, чтоб переписать кусок virtualbox так,
чтоб наша система видела как эти символы разрешаются, на мой взгляд,
бессмысленно и абсурдно.

Повторяю, это не регрессия, эти символы и раньше разрешались каким-то
загадочным способом, просто  наша проверка этого раньше не видела.

Я вижу несколько хакообразных способов протащить этот virtualbox через
сборочницу (собрать mock библиотеку, упаковать этот файл компрессором и
разжимать при установке на место %ghost), я могу ещё придумать, но
добавление в список исключений кажется мне наиболее прямым способом.

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Dmitry V. Levin]

On Mon, Dec 28, 2020 at 05:42:41PM +0300, Dmitry V. Levin wrote:
> On Mon, Dec 28, 2020 at 05:36:05PM +0300, Anton V. Boyarshinov wrote:
> > В Mon, 28 Dec 2020 17:30:50 +0300, Dmitry V. Levin пишет:
> > 
> > > > > > > > Каким образом можно решить эту проблему?      
> > > > > > > 
> > > > > > > Это скорее к вам вопрос.    
> > > > > > 
> > > > > > Совет сколь полный, столь и бесполезный.    
> > > > > 
> > > > > Это не совет, это вопрос.  
> > > > 
> > > > Мне кажется, если человек просит помощи, то он не справляется сам и ему
> > > > требуется помощь более опытных членов команды.  
> > > 
> > > С сожалению, в этой теме нужна в первую очередь (и во вторую тоже)
> > > экспертиза в virtualbox'е.
> > 
> > Не факт. Эти символы и раньше были unresolved с точки зрения
> > нашей сборочницы, просто удачным образом прятоались в  
> > ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
> > 
> > И virtualbox их как-то внутри себя загадочным образом находил.
> > 
> > Поскольку это проприретарщина, возможно ему самое место тут:
> 
> Это ещё и проприетарная блобятина?

Ещё у нас есть такой коммит:
http://git.altlinux.org/gears/p/...git?p=perl-qa-rpmelfsym.git;a=commitdiff;h=2d6d7a5

Может быть, virtualbox настолько потусторонний, что его нужно исключить
из рассмотрения навсегда?

Нужно хорошо понимать в virtualbox, чтобы сделать правильный выбор.


-- 
ldv

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Dmitry V. Levin]

On Mon, Dec 28, 2020 at 04:56:06PM +0300, Aleksey Novodvorsky wrote:
[...]
> Да, это блокер перехода на 5.10 LTS. И в Сизифе в качестве std-def тоже,
> конечно.

Этот подход глубоко порочный.
Если какая-то проприетарщина блокирует обновление ядра, то проще собрать
себе ядро, которое никогда не заблокирует какая-то там проприетарщина.


-- 
ldv

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Anton V. Boyarshinov]

В Mon, 28 Dec 2020 17:52:41 +0300
"Dmitry V. Levin" <ldv@altlinux.org> пишет:

> Может быть, virtualbox настолько потусторонний, что его нужно исключить
> из рассмотрения навсегда?

На мой взгляд он... достаточно потусторонний. В том смысле что, если я
правильно понимаю, он именно что устанавливает связь с потусторонним
миром, то есть между гостем и хостом. А в хостовом vboxdrv.ko эти
символы есть, но с префиксом VBHost_

Хотя, возможно, он как-то иначе их разрешает.

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Anton V. Boyarshinov]

В Mon, 28 Dec 2020 17:57:24 +0300
"Dmitry V. Levin" <ldv@altlinux.org> пишет:

> On Mon, Dec 28, 2020 at 04:56:06PM +0300, Aleksey Novodvorsky wrote:
> [...]
> > Да, это блокер перехода на 5.10 LTS. И в Сизифе в качестве std-def тоже,
> > конечно.  
> 
> Этот подход глубоко порочный.
> Если какая-то проприетарщина блокирует обновление ядра, то проще собрать
> себе ядро, которое никогда не заблокирует какая-то там проприетарщина.

У нас есть такое ядро в Сизифе. А в p9 хорошо бы всё-таки не допускать
регрессий, даже если регрессия состоит в том, что проприретарное
(nvidia) или полупроприретарное (vbox) не шмогла.

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Dmitry V. Levin]

On Mon, Dec 28, 2020 at 05:51:51PM +0300, Anton V. Boyarshinov wrote:
> В Mon, 28 Dec 2020 17:42:41 +0300, Dmitry V. Levin пишет:
> 
> > > Не факт. Эти символы и раньше были unresolved с точки зрения
> > > нашей сборочницы, просто удачным образом прятоались в  
> > > ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
> > > 
> > > И virtualbox их как-то внутри себя загадочным образом находил.
> > > 
> > > Поскольку это проприретарщина, возможно ему самое место тут:  
> > 
> > Это ещё и проприетарная блобятина?
> 
> Она не блобятина, она собирается из исходников. Но по способу
> разработки -- проприретарная, нам не удастся убедить Оракл обеспечивать
> линковку этих файлов более прямым образом, чем это делается сейчас.
> 
> И тратить время и силы на то, чтоб переписать кусок virtualbox так,
> чтоб наша система видела как эти символы разрешаются, на мой взгляд,
> бессмысленно и абсурдно.
> 
> Повторяю, это не регрессия, эти символы и раньше разрешались каким-то
> загадочным способом, просто  наша проверка этого раньше не видела.

Из этого описания мне не стало понятно, из какого именно рассмотрения
и что именно нужно исключать.  Есть ли вероятность, что эти файлы
могут запровайдить какие-то символы и тем самым исказить проверку
для других пакетов?


-- 
ldv

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Anton V. Boyarshinov]

В Mon, 28 Dec 2020 17:59:26 +0300
"Anton V. Boyarshinov" <boyarsh@altlinux.org> пишет:

> В Mon, 28 Dec 2020 17:52:41 +0300
> "Dmitry V. Levin" <ldv@altlinux.org> пишет:
> 
> > Может быть, virtualbox настолько потусторонний, что его нужно исключить
> > из рассмотрения навсегда?  
> 
> На мой взгляд он... достаточно потусторонний. В том смысле что, если я
> правильно понимаю, он именно что устанавливает связь с потусторонним
> миром, то есть между гостем и хостом. А в хостовом vboxdrv.ko эти
> символы есть, но с префиксом VBHost_
> 
> Хотя, возможно, он как-то иначе их разрешает.

То есть, на мой взгляд, он достаточно потусторонний, чтоб приравнять его
к nvidia, но, на мой взгляд, недостаточно для того, чтоб заблокировать
нашим пользователям возможность им пользоваться.

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Dmitry V. Levin]

On Mon, Dec 28, 2020 at 06:00:00PM +0300, Aleksey Novodvorsky wrote:
> пн, 28 дек. 2020 г., 17:52 Dmitry V. Levin:
[...]
> > Ещё у нас есть такой коммит:
> >
> > http://git.altlinux.org/gears/p/...git?p=perl-qa-rpmelfsym.git;a=commitdiff;h=2d6d7a5
> >
> > Может быть, virtualbox настолько потусторонний, что его нужно исключить
> > из рассмотрения навсегда?
> 
> Не надо, пожалуйста.

Алексей, если я дал ссылку, то не надо отвечать на моё письмо,
не пройдя по этой ссылке.  Иначе вы отвечаете на другое письмо.

> Это самая популярная среда виртуализации, как ни крути.

На чём основано это утверждение?


-- 
ldv

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Dmitry V. Levin]

On Mon, Dec 28, 2020 at 06:02:55PM +0300, Anton V. Boyarshinov wrote:
[...]
> То есть, на мой взгляд, он достаточно потусторонний, чтоб приравнять его
> к nvidia, но, на мой взгляд, недостаточно для того, чтоб заблокировать
> нашим пользователям возможность им пользоваться.

Он ближе к nvidia или к /boot?


-- 
ldv

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Andrey Savchenko]

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

On Mon, 28 Dec 2020 17:57:24 +0300 Dmitry V. Levin wrote:
> On Mon, Dec 28, 2020 at 04:56:06PM +0300, Aleksey Novodvorsky wrote:
> [...]
> > Да, это блокер перехода на 5.10 LTS. И в Сизифе в качестве std-def тоже,
> > конечно.
> 
> Этот подход глубоко порочный.
> Если какая-то проприетарщина блокирует обновление ядра, то проще собрать
> себе ядро, которое никогда не заблокирует какая-то там проприетарщина.

GPLv2 — это проприетарщина? Вот RMS удивится.
Не нужно называть софт проприетарщиной только потому, что апстрим
не захотел принимать пользовательские изменения, GPL к этому не
обязывает.

Best regards,
Andrew Savchenko

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

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Dmitry V. Levin]

On Mon, Dec 28, 2020 at 06:38:49PM +0300, Andrey Savchenko wrote:
> On Mon, 28 Dec 2020 17:57:24 +0300 Dmitry V. Levin wrote:
> > On Mon, Dec 28, 2020 at 04:56:06PM +0300, Aleksey Novodvorsky wrote:
> > [...]
> > > Да, это блокер перехода на 5.10 LTS. И в Сизифе в качестве std-def тоже,
> > > конечно.
> > 
> > Этот подход глубоко порочный.
> > Если какая-то проприетарщина блокирует обновление ядра, то проще собрать
> > себе ядро, которое никогда не заблокирует какая-то там проприетарщина.
> 
> GPLv2 — это проприетарщина? Вот RMS удивится.

Когда virtualbox стал GPLv2, интересно?


-- 
ldv

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Evgeny Sinelnikov]

пн, 28 дек. 2020 г. в 21:20, Aleksey Novodvorsky <aen@basealt.ru>:
>
>
>
> пн, 28 дек. 2020 г., 20:13 Dmitry V. Levin <ldv@altlinux.org>:
>>
>> On Mon, Dec 28, 2020 at 06:38:49PM +0300, Andrey Savchenko wrote:
>> > On Mon, 28 Dec 2020 17:57:24 +0300 Dmitry V. Levin wrote:
>> > > On Mon, Dec 28, 2020 at 04:56:06PM +0300, Aleksey Novodvorsky wrote:
>> > > [...]
>> > > > Да, это блокер перехода на 5.10 LTS. И в Сизифе в качестве std-def тоже,
>> > > > конечно.
>> > >
>> > > Этот подход глубоко порочный.
>> > > Если какая-то проприетарщина блокирует обновление ядра, то проще собрать
>> > > себе ядро, которое никогда не заблокирует какая-то там проприетарщина.
>> >
>> > GPLv2 — это проприетарщина? Вот RMS удивится.
>>
>> Когда virtualbox стал GPLv2, интересно?
>
>
> Когда -- не скажу, но сейчас:
>
> https://www.virtualbox.org/manual/ch01.html#intro-installing

Он таким был всегда. При этом базовый функционал вполне достаточен для
многих задач, а проприетарная часть расширений не обязательна и
постепенно перетекает в базовую.

Мы собираем базовый функционал и он вполне свободный. И это,
действительно, самый популярный инструмент для виртуализации для очень
многих пользователей. Например, в правительстве, куда я приходил
посмотреть что у них и как, его тоже используют на всю катушку без
всякий проприетарных расширений а кое-где и с ними.

Теперь о проблеме. Мы с Валерой много вариантов попробовали в плане
решения. Сделать заглушку в виде ответной библиотеки я отвергал, как
дикую. Но что-то мне уже подсказывает, что она не так уж и далека от
реальности, которая дана в виде сборочницы. Это можно даже
автоматизировать.

Я бы предложил исключить из проверки файлы с расширением *.r0, даже
если это ELF. Или дать возможность исключать из проверки файлы в
спекфайле. Ещё один вариант - это как-то откатить код апстрима до
предыдущего, но там, ой как, всё непросто.

Если не найдётся решения сделать исключение на сборочнице, то я пока
вижу только одно "хорошее" программное решение - разобрать код
загрузки этих модулей и пропатчить virtualbox обратно. Но это куча
работы. И мне тогда придётся ей занятся во внерабочее время.

В чём суть обратного исправления? И откуда взялся этот ELF? дело в
том, что разработчики ведут этот проект на одной кодовой базе под
разные операционные системы. И возникшая перед нами проблема - это
результат обобщения их кодовой базы. Вот и вся суть. Мне надо теперь
очень глубоко вчитаться в код virtualbox'а, чтобы всё это вернуть
обратно. Я очень надеялся, что меня минует это чаша.



-- 
Sin (Sinelnikov Evgeny)

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Dmitry V. Levin]

On Mon, Dec 28, 2020 at 10:09:47PM +0400, Evgeny Sinelnikov wrote:
[...]
> Я бы предложил исключить из проверки файлы с расширением *.r0, даже
> если это ELF. Или дать возможность исключать из проверки файлы в
> спекфайле. Ещё один вариант - это как-то откатить код апстрима до
> предыдущего, но там, ой как, всё непросто.

Вопрос, предоставляют ли эти /usr/lib64/virtualbox/*.r0 какие-нибудь
символы для других файлов, зависимости которых видит сборочница?


-- 
ldv

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Evgeny Sinelnikov]

пн, 28 дек. 2020 г. в 22:15, Dmitry V. Levin <ldv@altlinux.org>:
>
> On Mon, Dec 28, 2020 at 10:09:47PM +0400, Evgeny Sinelnikov wrote:
> [...]
> > Я бы предложил исключить из проверки файлы с расширением *.r0, даже
> > если это ELF. Или дать возможность исключать из проверки файлы в
> > спекфайле. Ещё один вариант - это как-то откатить код апстрима до
> > предыдущего, но там, ой как, всё непросто.
>
> Вопрос, предоставляют ли эти /usr/lib64/virtualbox/*.r0 какие-нибудь
> символы для других файлов, зависимости которых видит сборочница?

Ну, вот так это выглядит.
http://git.altlinux.org/tasks/264125/logs/events.2.1.log

$ file VMMR0.r0 VBoxDDR0.r0
VMMR0.r0:    ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
dynamically linked, stripped
VBoxDDR0.r0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
dynamically linked, stripped

$ ldd VMMR0.r0 VBoxDDR0.r0
VMMR0.r0:
        statically linked
VBoxDDR0.r0:
        statically linked

sin@xpi tmp $ nm -D VMMR0.r0 | grep -v ' U ' | wc
   1287    3861   53297
sin@xpi tmp $ nm -D VMMR0.r0 | grep -v ' U ' | head
0000000000082fa0 T APICGetTpr
0000000000082f50 T APICSetTpr
0000000000084550 T APICUpdatePendingInterrupts
0000000000159fe0 T ASMCpuIdExSlow
0000000000159ef0 T ASMGetXcr0
0000000000159f1d T ASMMemFirstMismatchingU8
0000000000159f10 T ASMMemFirstNonZero
0000000000159ed0 T ASMXRstor
0000000000085e20 T CPUMDeactivateGuestDebugState
0000000000085ea0 T CPUMGetGuestCodeBits
sin@xpi tmp $ nm -D VMMR0.r0 | grep -v ' U ' | tail
0000000000121010 T _Z17pgmR0GstRealEnterP6GVMCPUy
0000000000123790 T _Z18pgmR0Gst32BitEnterP6GVMCPUy
00000000001237c0 T _Z18pgmR0GstAMD64EnterP6GVMCPUy
0000000000158f60 T _Z19IntNetR0IfAbortWaitjP13SUPDRVSESSIONb
0000000000055810 T _Z20GMMR0QueryStatisticsP8GMMSTATSP13SUPDRVSESSIONP3GVM
0000000000055b30 T _Z20GMMR0ResetStatisticsPK8GMMSTATSP13SUPDRVSESSIONP3GVM
000000000012f1d0 T
_Z37pgmR0BthPAEPAETrap0eHandlerGuestFaultP6GVMCPUP15PGMPTWALKGSTPAEy
000000000012f180 T
_Z39pgmR0BthPAE32BitTrap0eHandlerGuestFaultP6GVMCPUP17PGMPTWALKGST32BITy
000000000012f130 T
_Z41pgmR0Bth32Bit32BitTrap0eHandlerGuestFaultP6GVMCPUP17PGMPTWALKGST32BITy
000000000012f550 T
_Z41pgmR0BthAMD64AMD64Trap0eHandlerGuestFaultP6GVMCPUP17PGMPTWALKGSTAMD64y

sin@xpi tmp $ nm -D VBoxDDR0.r0| grep -v ' U ' | wc
     24      72     931
sin@xpi tmp $ nm -D VBoxDDR0.r0| grep -v ' U ' | head
000000000001d360 T drvIntNetUp_AllocBuf
000000000001d2f0 T drvIntNetUp_BeginXmit
000000000001d890 T drvIntNetUp_EndXmit
000000000001d710 T drvIntNetUp_FreeBuf
000000000001d770 T drvIntNetUp_SendBuf
000000000001d8a0 T drvIntNetUp_SetPromiscuousMode
0000000000024a40 T drvNetShaperUp_AllocBuf
0000000000024a00 T drvNetShaperUp_BeginXmit
0000000000024b50 T drvNetShaperUp_EndXmit
0000000000024b10 T drvNetShaperUp_FreeBuf
sin@xpi tmp $ nm -D VBoxDDR0.r0| grep -v ' U ' | tail
000000000000c950 T flashMMIOWrite
000000000000a1c0 T ModuleInit
000000000000a1d0 T ModuleTerm
0000000000025ca0 T ohciMmioWrite
000000000001bb60 T ox958IrqReq
0000000000013a10 T rtcIOPortRead
0000000000013cb0 T rtcIOPortWrite
000000000001b560 T serialIrqReq
000000000000fe70 T vgaLbfAccessPfHandler
000000000000fe90 T vgaLFBAccessHandler

Это символы для модулей в виртуальном пространстве ядра. Связующий клей такой.


-- 
Sin (Sinelnikov Evgeny)

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Dmitry V. Levin]

On Mon, Dec 28, 2020 at 10:40:53PM +0400, Evgeny Sinelnikov wrote:
> пн, 28 дек. 2020 г. в 22:15, Dmitry V. Levin wrote:
> >
> > On Mon, Dec 28, 2020 at 10:09:47PM +0400, Evgeny Sinelnikov wrote:
> > [...]
> > > Я бы предложил исключить из проверки файлы с расширением *.r0, даже
> > > если это ELF. Или дать возможность исключать из проверки файлы в
> > > спекфайле. Ещё один вариант - это как-то откатить код апстрима до
> > > предыдущего, но там, ой как, всё непросто.
> >
> > Вопрос, предоставляют ли эти /usr/lib64/virtualbox/*.r0 какие-нибудь
> > символы для других файлов, зависимости которых видит сборочница?
> 
> Ну, вот так это выглядит.
> http://git.altlinux.org/tasks/264125/logs/events.2.1.log

Там мы видим то, что этим /usr/lib64/virtualbox/*.r0 нужно, а не то,
что нужно от них другим файлам.

> sin@xpi tmp $ nm -D VMMR0.r0 | grep -v ' U ' | wc
>    1287    3861   53297

Что-нибудь из этого нужно каким-нибудь другим файлам, зависимости которых
видит сборочница?


-- 
ldv

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Alexey V. Vissarionov]

On 2020-12-28 22:09:47 +0400, Evgeny Sinelnikov wrote:

 > Я бы предложил исключить из проверки файлы с расширением *.r0,
 > даже если это ELF. Или дать возможность исключать из проверки
 > файлы в спекфайле. Ещё один вариант - это как-то откатить код
 > апстрима до предыдущего, но там, ой как, всё непросто.

Нужно именно отключать проверку для отдельных файлов. Более того,
было бы разумно по умолчанию воспринимать ELF для non-Linux как
бинарные данные - в том числе разрешать паковать их в noarch.

В случае ELF для Linux сложнее, но даже это можно отдать на откуп
мейнтейнеру (максимум выдавать предупреждение в лог, чтобы совсем
уж незаметно это не проходило).


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Alexey V. Vissarionov]

On 2020-12-28 18:01:26 +0300, Dmitry V. Levin wrote:

 > Из этого описания мне не стало понятно, из какого именно
 > рассмотрения и что именно нужно исключать. Есть ли вероятность,
 > что эти файлы могут запровайдить какие-то символы и тем самым
 > исказить проверку для других пакетов?

Сделай проверку только для Linux ELF - не ошибешься. Остальную
блобятину можно считать данными.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Alexey V. Vissarionov]

On 2020-12-28 18:07:21 +0300, Dmitry V. Levin wrote:

 >> То есть, на мой взгляд, он достаточно потусторонний, чтоб
 >> приравнять его к nvidia, но, на мой взгляд, недостаточно
 >> для того, чтоб заблокировать нашим пользователям возможность
 >> им пользоваться.
 > Он ближе к nvidia или к /boot?

Если "/boot" означает модули загрузчика, то да - именно к ним.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Dmitry V. Levin]

On Mon, Dec 28, 2020 at 10:30:06PM +0300, Dmitry V. Levin wrote:
> On Mon, Dec 28, 2020 at 10:40:53PM +0400, Evgeny Sinelnikov wrote:
[...]
> > sin@xpi tmp $ nm -D VMMR0.r0 | grep -v ' U ' | wc
> >    1287    3861   53297
> 
> Что-нибудь из этого нужно каким-нибудь другим файлам, зависимости которых
> видит сборочница?

Насколько я понимаю, ответ на этот вопрос - нет, из этих файлов не нужно
и никогда не понадобится, нормальные эльфы с этими дела не имеют.

В таком случае предлагаю следующий вариант объезда в rpmelfsym.pm:

# virtualbox ELF shared objects with unclear linkage semantics
next if $filename =~ m#^/usr/lib(64)?/virtualbox/[^/.]+\.r0\z#;


-- 
ldv

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Alexey V. Vissarionov]

On 2020-12-29 01:23:21 +0300, Dmitry V. Levin wrote:

 >> Что-нибудь из этого нужно каким-нибудь другим файлам,
 >> зависимости которых видит сборочница?
 > Насколько я понимаю, ответ на этот вопрос - нет, из этих файлов
 > не нужно и никогда не понадобится, нормальные эльфы с этими
 > дела не имеют.

Имеют, но очень опосредованнное.

 > В таком случае предлагаю следующий вариант объезда в rpmelfsym.pm:
 > # virtualbox ELF shared objects with unclear linkage semantics
 > next if $filename =~ m#^/usr/lib(64)?/virtualbox/[^/.]+\.r0\z#;

Костыль. Если делать по уму - надо смотреть на породу эльфа, а не
на место его обитания. И если оно non-Linux - сборочнице до него
не должно быть никакого дела.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Anton Farygin]

On 29.12.2020 07:23, Alexey V. Vissarionov wrote:
> On 2020-12-29 01:23:21 +0300, Dmitry V. Levin wrote:
>
>   >> Что-нибудь из этого нужно каким-нибудь другим файлам,
>   >> зависимости которых видит сборочница?
>   > Насколько я понимаю, ответ на этот вопрос - нет, из этих файлов
>   > не нужно и никогда не понадобится, нормальные эльфы с этими
>   > дела не имеют.
>
> Имеют, но очень опосредованнное.
>
>   > В таком случае предлагаю следующий вариант объезда в rpmelfsym.pm:
>   > # virtualbox ELF shared objects with unclear linkage semantics
>   > next if $filename =~ m#^/usr/lib(64)?/virtualbox/[^/.]+\.r0\z#;
>
> Костыль. Если делать по уму - надо смотреть на породу эльфа, а не
> на место его обитания. И если оно non-Linux - сборочнице до него
> не должно быть никакого дела.
>
>
Кстати да, было бы неплохо.

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Anton V. Boyarshinov]

В Mon, 28 Dec 2020 18:02:44 +0300
Aleksey Novodvorsky <aen@basealt.ru> пишет:

> Возможно, мы его напрасно включали раньше, не предвидев новые проверки
> сборочницы.

Проверки старые. И unresolved символы старые. Просто раньше они были в
объектном файле, который не проверялся, а теперь в библиотеке, которая
проверяется.

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Anton V. Boyarshinov]

В Mon, 28 Dec 2020 23:30:57 +0300
"Alexey V. Vissarionov" <gremlin@altlinux.org> пишет:

> Нужно именно отключать проверку для отдельных файлов. Более того,
> было бы разумно по умолчанию воспринимать ELF для non-Linux как
> бинарные данные - в том числе разрешать паковать их в noarch.

Насколько я понимаю, это всё-таки ELF для Linux, просто он загружается
чрезвычайно небанальным образом.
 
> В случае ELF для Linux сложнее, но даже это можно отдать на откуп
> мейнтейнеру (максимум выдавать предупреждение в лог, чтобы совсем
> уж незаметно это не проходило).

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Anton V. Boyarshinov]

В Mon, 28 Dec 2020 18:01:26 +0300
"Dmitry V. Levin" <ldv@altlinux.org> пишет:

> Из этого описания мне не стало понятно, из какого именно рассмотрения
> и что именно нужно исключать.  Есть ли вероятность, что эти файлы
> могут запровайдить какие-то символы и тем самым исказить проверку
> для других пакетов?

Для других пакетов, я полагаю, исключено.

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Anton V. Boyarshinov]

В Mon, 28 Dec 2020 18:05:45 +0300
"Dmitry V. Levin" <ldv@altlinux.org> пишет:

> > Это самая популярная среда виртуализации, как ни крути.  
> 
> На чём основано это утверждение?

Если сформулировать "самая популярная среда НАСТОЛЬНОЙ виртуализации",
то это утверждение с учётом кроссплатформенности выглядит очень
правдоподобно.

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Alexey V. Vissarionov]

On 2020-12-29 11:18:58 +0300, Anton V. Boyarshinov wrote:

 >> Нужно именно отключать проверку для отдельных файлов.
 >> Более того, было бы разумно по умолчанию воспринимать
 >> ELF для non-Linux как бинарные данные - в том числе
 >> разрешать паковать их в noarch.
 > Насколько я понимаю, это всё-таки ELF для Linux, просто
 > он загружается чрезвычайно небанальным образом.

Лень отматывать тред, но вроде бы я видел там абстрактное
SYSV вместо GNU/Linux.

Вот, например, `file /lib64/libc-*.so` вполне предсказуемо
выдает "ELF 64-bit LSB shared object, x86-64, version 1
(GNU/Linux".

А `file /usr/share/syslinux/efi64/syslinux.c32` - не менее
предсказуемо выдает "ELF 64-bit LSB shared object, x86-64,
version 1 (SYSV)".

По-моему, разница очевидна.

 >> В случае ELF для Linux сложнее, но даже это можно отдать
 >> на откуп мейнтейнеру (максимум выдавать предупреждение в
 >> лог, чтобы совсем уж незаметно это не проходило).

Но самое главное - здесь. Ибо огораживание еще никому никогда
на пользу не шло.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Dmitry V. Levin]

On Tue, Dec 29, 2020 at 07:23:10AM +0300, Alexey V. Vissarionov wrote:
> On 2020-12-29 01:23:21 +0300, Dmitry V. Levin wrote:
> 
>  >> Что-нибудь из этого нужно каким-нибудь другим файлам,
>  >> зависимости которых видит сборочница?
>  > Насколько я понимаю, ответ на этот вопрос - нет, из этих файлов
>  > не нужно и никогда не понадобится, нормальные эльфы с этими
>  > дела не имеют.
> 
> Имеют, но очень опосредованнное.
> 
>  > В таком случае предлагаю следующий вариант объезда в rpmelfsym.pm:
>  > # virtualbox ELF shared objects with unclear linkage semantics
>  > next if $filename =~ m#^/usr/lib(64)?/virtualbox/[^/.]+\.r0\z#;
> 
> Костыль. Если делать по уму - надо смотреть на породу эльфа, а не
> на место его обитания. И если оно non-Linux - сборочнице до него
> не должно быть никакого дела.

Тут уже было, повторяю:
$ rpmpeek /tasks/264125/build/200/x86_64/rpms/virtualbox-6.1.16-alt1.x86_64.rpm file ./usr/lib64/virtualbox/VMMR0.r0
./usr/lib64/virtualbox/VMMR0.r0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped

Для сравнения:
$ file -L /usr/lib64/libelf.so.1 
/usr/lib64/libelf.so.1: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped


-- 
ldv

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Alexey V. Vissarionov]

On 2020-12-29 11:51:11 +0300, Dmitry V. Levin wrote:

 >>> В таком случае предлагаю следующий вариант объезда в rpmelfsym.pm:
 >>> # virtualbox ELF shared objects with unclear linkage semantics
 >>> next if $filename =~ m#^/usr/lib(64)?/virtualbox/[^/.]+\.r0\z#;
 >> Костыль. Если делать по уму - надо смотреть на породу эльфа, а не
 >> на место его обитания. И если оно non-Linux - сборочнице до него
 >> не должно быть никакого дела.
 > Тут уже было, повторяю:
 > $ rpmpeek
 > /tasks/264125/build/200/x86_64/rpms/virtualbox-6.1.16-alt1.x86_64.rpm
 > file ./usr/lib64/virtualbox/VMMR0.r0
 > ./usr/lib64/virtualbox/VMMR0.r0: ELF 64-bit LSB shared object,
 > x86-64, version 1 (SYSV), dynamically linked, stripped
 > Для сравнения:
 > $ file -L /usr/lib64/libelf.so.1
 > /usr/lib64/libelf.so.1: ELF 64-bit LSB shared object, x86-64,
 > version 1 (SYSV), dynamically linked, stripped

Ну, libelf такой libelf... тут, скорее, именно его надо в исключения
внести - в общем случае non-Linux блобятине в %_libdir не место.

Ну, или явно их указывать для каждого пакета макросом наподобие
%alienelf %_libdir/%name/*.r0 - это хотя бы будет означать, что
мейнтейнер знает, что это за файлы.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Anton Farygin]

On 29.12.2020 11:51, Dmitry V. Levin wrote:
> On Tue, Dec 29, 2020 at 07:23:10AM +0300, Alexey V. Vissarionov wrote:
>> On 2020-12-29 01:23:21 +0300, Dmitry V. Levin wrote:
>>
>>   >> Что-нибудь из этого нужно каким-нибудь другим файлам,
>>   >> зависимости которых видит сборочница?
>>   > Насколько я понимаю, ответ на этот вопрос - нет, из этих файлов
>>   > не нужно и никогда не понадобится, нормальные эльфы с этими
>>   > дела не имеют.
>>
>> Имеют, но очень опосредованнное.
>>
>>   > В таком случае предлагаю следующий вариант объезда в rpmelfsym.pm:
>>   > # virtualbox ELF shared objects with unclear linkage semantics
>>   > next if $filename =~ m#^/usr/lib(64)?/virtualbox/[^/.]+\.r0\z#;
>>
>> Костыль. Если делать по уму - надо смотреть на породу эльфа, а не
>> на место его обитания. И если оно non-Linux - сборочнице до него
>> не должно быть никакого дела.
> Тут уже было, повторяю:
> $ rpmpeek /tasks/264125/build/200/x86_64/rpms/virtualbox-6.1.16-alt1.x86_64.rpm file ./usr/lib64/virtualbox/VMMR0.r0
> ./usr/lib64/virtualbox/VMMR0.r0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
>
> Для сравнения:
> $ file -L /usr/lib64/libelf.so.1
> /usr/lib64/libelf.so.1: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
>
>
Тоже такие себе эльфы, я бы их исключал из проверок:

$ file /usr/lib64/ocaml/biniou/biniou.cmxs
/usr/lib64/ocaml/biniou/biniou.cmxs: ELF 64-bit LSB shared object, 
x86-64, version 1 (SYSV), dynamically linked, stripped

Build a plugin (usually .cmxs) that can be dynamically loaded with the 
Dynlink module. The name of the plugin must be set with the -o option. A 
plugin can include a number of OCaml modules and libraries, and extra 
native objects (.o, .obj, .a, .lib files)

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Andrey Savchenko]

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

On Tue, 29 Dec 2020 11:31:16 +0300 Alexey V. Vissarionov wrote:
> On 2020-12-29 11:18:58 +0300, Anton V. Boyarshinov wrote:
> 
>  >> Нужно именно отключать проверку для отдельных файлов.
>  >> Более того, было бы разумно по умолчанию воспринимать
>  >> ELF для non-Linux как бинарные данные - в том числе
>  >> разрешать паковать их в noarch.
>  > Насколько я понимаю, это всё-таки ELF для Linux, просто
>  > он загружается чрезвычайно небанальным образом.
> 
> Лень отматывать тред, но вроде бы я видел там абстрактное
> SYSV вместо GNU/Linux.
> 
> Вот, например, `file /lib64/libc-*.so` вполне предсказуемо
> выдает "ELF 64-bit LSB shared object, x86-64, version 1
> (GNU/Linux".
> 
> А `file /usr/share/syslinux/efi64/syslinux.c32` - не менее
> предсказуемо выдает "ELF 64-bit LSB shared object, x86-64,
> version 1 (SYSV)".
> 
> По-моему, разница очевидна.

Ну-ну:
$ file -L /usr/lib64/libncurses.so.3
/usr/lib64/libncurses.so.3: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped

И таких в /usr/lib64 очень много.
 
>  >> В случае ELF для Linux сложнее, но даже это можно отдать
>  >> на откуп мейнтейнеру (максимум выдавать предупреждение в
>  >> лог, чтобы совсем уж незаметно это не проходило).
> 
> Но самое главное - здесь. Ибо огораживание еще никому никогда
> на пользу не шло.
> 
> 


Best regards,
Andrew Savchenko

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

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Dmitry V. Levin]

On Tue, Dec 29, 2020 at 12:25:50PM +0300, Alexey V. Vissarionov wrote:
> On 2020-12-29 11:51:11 +0300, Dmitry V. Levin wrote:
> 
>  >>> В таком случае предлагаю следующий вариант объезда в rpmelfsym.pm:
>  >>> # virtualbox ELF shared objects with unclear linkage semantics
>  >>> next if $filename =~ m#^/usr/lib(64)?/virtualbox/[^/.]+\.r0\z#;
>  >> Костыль. Если делать по уму - надо смотреть на породу эльфа, а не
>  >> на место его обитания. И если оно non-Linux - сборочнице до него
>  >> не должно быть никакого дела.
>  > Тут уже было, повторяю:
>  > $ rpmpeek
>  > /tasks/264125/build/200/x86_64/rpms/virtualbox-6.1.16-alt1.x86_64.rpm
>  > file ./usr/lib64/virtualbox/VMMR0.r0
>  > ./usr/lib64/virtualbox/VMMR0.r0: ELF 64-bit LSB shared object,
>  > x86-64, version 1 (SYSV), dynamically linked, stripped
>  > Для сравнения:
>  > $ file -L /usr/lib64/libelf.so.1
>  > /usr/lib64/libelf.so.1: ELF 64-bit LSB shared object, x86-64,
>  > version 1 (SYSV), dynamically linked, stripped
> 
> Ну, libelf такой libelf...

Это типичный представитель, почти все библиотеки такие.


-- 
ldv

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Ivan A. Melnikov]

On Mon, Dec 28, 2020 at 11:39:03PM +0300, Alexey V. Vissarionov wrote:
> On 2020-12-28 18:01:26 +0300, Dmitry V. Levin wrote:
> 
>  > Из этого описания мне не стало понятно, из какого именно
>  > рассмотрения и что именно нужно исключать. Есть ли вероятность,
>  > что эти файлы могут запровайдить какие-то символы и тем самым
>  > исказить проверку для других пакетов?
> 
> Сделай проверку только для Linux ELF - не ошибешься. Остальную
> блобятину можно считать данными.

Было бы здорово, если бы Linux ELF можно было бы как-то формально
отличить от не-Linux ELF. Опираться для этого на поле EI_OSABI
(на которое и смотрит команда file, когда выдаёт своё SYSV или
Linux), к сожалению, ошибочно.

Загрузчик ELF'ов в Linux'е традиционно принимает ELF'ы
с двумя типами этих самых OSABI: ELFOSABI_NONE (SYSV это
alias на него) и ELFOSABI_GNU (ELFOSABI_LINUX это алиас
на него); похоже, загрузчик не делает различий между ними.

Компоновщик же (который GNU ld, из состава binutils) ELF'ам,
которые он собирает, по умолчанию выставляет OS ABI
в ELFOSABI_NONE, и использует ELFOSABI_GNU только если в полученом
ELF'е используются какие-то особенные GNU-тые расширения,
а точнее "STT_GNU_IFUNC symbol type or STB_GNU_UNIQUE binding".
Таких меньшинство, и это технически правильно. Вот прямо
сейчас у меня:

$ file /usr/lib64/*.so.* | grep ELF | grep SYSV | wc -l
1258
$ file /usr/lib64/*.so.* | grep ELF | grep GNU/Linux | wc -l
210

То есть, эти буквы в скобках -- не предназначение, а особенности
формата. Причём, что интересно, GNU binutils и glibc в коде
используют ELFOSABI_NONE и ELFOSABI_GNU и похоже так к ним
и относятся, а все readelf, file и сотоварищи в human-readable
выводе пишут SysV или Linux. Не дайте себя запутать)

-- 
  wbr,
    iv m.

Re: [devel] Ограничения сборочницы для virtualbox-6.1.14 и выше

[Alexey V. Vissarionov]

On 2020-12-29 15:07:47 +0400, Ivan A. Melnikov wrote:

 >> Сделай проверку только для Linux ELF - не ошибешься.
 >> Остальную блобятину можно считать данными.
 > Было бы здорово, если бы Linux ELF можно было бы как-то
 > формально отличить от не-Linux ELF. Опираться для этого
 > на поле EI_OSABI (на которое и смотрит команда file, когда
 > выдаёт своё SYSV или Linux), к сожалению, ошибочно.

Печалька.

 > Загрузчик ELF'ов в Linux'е традиционно принимает ELF'ы с двумя
 > типами этих самых OSABI: ELFOSABI_NONE (SYSV это alias на него)
 > и ELFOSABI_GNU (ELFOSABI_LINUX это алиас на него); похоже,
 > загрузчик не делает различий между ними.
 > Компоновщик же (который GNU ld, из состава binutils) ELF'ам,
 > которые он собирает, по умолчанию выставляет OS ABI в
 > ELFOSABI_NONE, и использует ELFOSABI_GNU только если в
 > полученом ELF'е используются какие-то особенные GNU-тые
 > расширения, а точнее "STT_GNU_IFUNC symbol type or
 > STB_GNU_UNIQUE binding". Таких меньшинство, и это технически
 > правильно.

Значит, надо спихнуть это разделение на мейнтейнеров.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] exception for ocaml .cmxs files

[Dmitry V. Levin]

On Tue, Dec 29, 2020 at 12:55:03PM +0300, Anton Farygin wrote:
[...]
> Тоже такие себе эльфы, я бы их исключал из проверок:
> 
> $ file /usr/lib64/ocaml/biniou/biniou.cmxs
> /usr/lib64/ocaml/biniou/biniou.cmxs: ELF 64-bit LSB shared object, 
> x86-64, version 1 (SYSV), dynamically linked, stripped
> 
> Build a plugin (usually .cmxs) that can be dynamically loaded with the 
> Dynlink module. The name of the plugin must be set with the -o option. A 
> plugin can include a number of OCaml modules and libraries, and extra 
> native objects (.o, .obj, .a, .lib files)

Они тоже никогда не предоставляют символы для обычных эльфов?


-- 
ldv

Re: [devel] exception for ocaml .cmxs files

[Anton Farygin]

On 29.12.2020 17:55, Dmitry V. Levin wrote:
> On Tue, Dec 29, 2020 at 12:55:03PM +0300, Anton Farygin wrote:
> [...]
>> Тоже такие себе эльфы, я бы их исключал из проверок:
>>
>> $ file /usr/lib64/ocaml/biniou/biniou.cmxs
>> /usr/lib64/ocaml/biniou/biniou.cmxs: ELF 64-bit LSB shared object,
>> x86-64, version 1 (SYSV), dynamically linked, stripped
>>
>> Build a plugin (usually .cmxs) that can be dynamically loaded with the
>> Dynlink module. The name of the plugin must be set with the -o option. A
>> plugin can include a number of OCaml modules and libraries, and extra
>> native objects (.o, .obj, .a, .lib files)
> Они тоже никогда не предоставляют символы для обычных эльфов?
>
>
Ну из описания же понятно что они предоставляют символы для программ 
ocaml, использующих модуль dynlink. Это уже конечно. бывают,  обычные 
elf'ы, но я не уверен что механизм работы с символами похож на то, для 
чего делался обсуждаемый инструмент проверки замыкаемости по символам.


а  у тебя же есть данные по символам, которые требуются и провайдятся ? 
Можешь проверить моё предположение  - нужны ли кому-то символы из cmxs 
файлов ?