подтверждаю,  аналогично сломался courier-imap:
https://git.altlinux.org/beehive/logs/Sisyphus/i586/archive/2024/1109/error/courier-imap-5.2.10-alt1

но, к сожалению,  всем заинтересованным и ответственным на этот пакет глубоко наплевать (могу предоставить переписку :)

Говорят, [1] исправляет это. Приложено в debian, gentoo, fedora, openembedded,... Вошло в 3.23 и 3.24.

Вообще этот пакет хорошо бы обновить. В федору, с которой он традиционно синхронизируется, 3.24 уже завезли, и в rawhide и 41-ю.

> всем заинтересованным и ответственным на этот пакет глубоко наплевать

Надеюсь, что раз ACL всё ещё закрыт, значит не так уж и глубоко.

[1] https://sourceware.org/git/?p=valgrind.git;a=commit;h=d35005cef8ad8207542738812705ceabf137d7e0

(In reply to Ivan A. Melnikov from comment #2)
> Говорят, [1] исправляет это. Приложено в debian, gentoo, fedora,
> openembedded,... Вошло в 3.23 и 3.24.
> 
> Вообще этот пакет хорошо бы обновить. В федору, с которой он традиционно
> синхронизируется, 3.24 уже завезли, и в rawhide и 41-ю.
> 
> > всем заинтересованным и ответственным на этот пакет глубоко наплевать
> 
> Надеюсь, что раз ACL всё ещё закрыт, значит не так уж и глубоко.
> 
> [1]
> https://sourceware.org/git/?p=valgrind.git;a=commit;
> h=d35005cef8ad8207542738812705ceabf137d7e0

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

(In reply to Konstantin A Lepikhov (L.A. Kostis) from comment #3)
> Вы выразили интерес и даже собрали пакет.

Я заинтересован в живом valgrind'е. И планировал потыкать в текущее состояние патчей для loongarch64, в которых я тоже заинтересован.

Я попробую собрать новую версию, а там посмотрим.

> Я попробую собрать новую версию, а там посмотрим.

Попробовал, https://git.altlinux.org/tasks/362452.

На x86_64 при установленном glibc-core-debuginfo не проходит один тест из запускаемых:

--- use_after_close.stderr.exp  2024-11-13 19:00:26.000000000 +0400
+++ use_after_close.stderr.out  2024-11-13 19:10:43.813348303 +0400
@@ -6,13 +6,13 @@
  Originally opened
    at 0x........: dup (in /...libc...)
    by 0x........: main
-   at 0x........: write (in /...libc...)
+   at 0x........: write (write.c:26)
    by 0x........: main
 File descriptor 7 was never created
-   at 0x........: write (in /...libc...)
+   at 0x........: write (write.c:26)
    by 0x........: main
 File descriptor -7 Invalid file descriptor
-   at 0x........: write (in /...libc...)
+   at 0x........: write (write.c:26)
    by 0x........: main
 File descriptor ...: ... is already closed
    at 0x........: close (in /...libc...)

Выглядит не страшно.

На gyle их не проходит больше, так как там нет возможности запихнуть в hasher glibc-core-debuginfo, а без неё helgrind отказывается как-то разумно работать.

Это намного лучше, того, что было: в тех же условиях при сборке текущего 3.17.0-alt3 падает примерно в 10 раз больше тестов.

Я сейчас попробую посмотреть, как ведут себя тесты на aarch64 в присутствии glibc-core-debuginfo.

Если тесты можно запускать независимо от сборки, то получить debuginfo пакеты можно в install check. Примеры тут

  c/crash/crash.spec:44:%package -n kernel-ci-crash-debuginfo
  d/drgn/drgn.spec:52:%package -n kernel-ci-drgn-debuginfo

Пример чуть сложнее чем возможно нужно для valgrind, так как там надо было еще kernel. Так что достаточно сделать -debuginfo подпакет с %post с тестами.

Created attachment 17181 [details]
Тесты на aarch64 в присутствии glibc-core-debuginfo

(In reply to Ivan A. Melnikov from comment #5)
> Я сейчас попробую посмотреть, как ведут себя тесты на aarch64 в присутствии
> glibc-core-debuginfo.

Упало немного больше, но тоже не выглядит критично.

(In reply to Vitaly Chikunov from comment #6)
> Если тесты можно запускать независимо от сборки, то получить debuginfo
> пакеты можно в install check.

Не уверен, что эти тесты легко оторвать от сборочного окружения. Это надо или очень постораться, или сделать что-то совсем суровое.

> Так что достаточно сделать -debuginfo подпакет с %post с тестами.

Извините, но немного оффтопика. У меня есть ощущение, что компоненту checkinstall должны быть доступны при установке все компоненты, включая debuginfo и gostcrypto, так как без этого смысл checkinstall немного размывается а область его применения сужается. Если я правильно понимаю, проблемы здесь может вызвать gb-task-repo-unmets и собственно install check'и. В install check'ах всё уже должно быть хорошо, там один apt.conf/list на всех; а gb-task-repo-unmets несложно поправить. Надо попробовать.

(In reply to Ivan A. Melnikov from comment #5)
> > Я попробую собрать новую версию, а там посмотрим.
> 
> Попробовал, https://git.altlinux.org/tasks/362452.

Потыкал memcheck руками на x86_64. В дополнение ко всяким тестам -- кажется, valgrind получился работоспособным.

Задача 362452 в EPERM. Прошу аппрува или конструктивной критики.

(In reply to Ivan A. Melnikov from comment #8)
> У меня есть ощущение, что компоненту checkinstall должны быть доступны при
> установке все компоненты, включая debuginfo и gostcrypto,

Да, было бы удобнее.

valgrind-3.24.0-alt1 -> sisyphus:

 Wed Nov 13 2024 Ivan A. Melnikov <iv@altlinux> 3.24.0-alt1
 - 3.17.0 -> 3.24.0 (ALT#51941).
 - Synced RH patches with valgrind-3.24.0-1 from Fedora.

@iv Спасибо за обновление!

@iv спасибо, что взяли пакет на себя и обновили наконец-то его!