Можно, конечно, тупо пересобрать сломавшиеся пакеты (благо их немного).
Но лучше бы понять:
1) Причину такого изменения,
2) Насколько оно желательно (или нет)

Мы выяснили, что это стало следствием https://git.savannah.gnu.org/cgit/config.git/commit/?id=ee9898641088ae9169de0453ce475d371f9d5016

Как видно, в репозитории с этим нет консистентности:
$ grep -F armh-alt-linux-gnueabi Sisyphus/armh/base/contents_index |cut -f2 |sort -u |wc -l
128
$ grep -F armv7l-alt-linux-gnueabi Sisyphus/armh/base/contents_index |cut -f2 |sort -u |wc -l
41

(Ответ для Dmitry V. Levin на комментарий #2)
> Мы выяснили, что это стало следствием
> https://git.savannah.gnu.org/cgit/config.git/commit/
> ?id=ee9898641088ae9169de0453ce475d371f9d5016
> 
> Как видно, в репозитории с этим нет консистентности:
> $ grep -F armh-alt-linux-gnueabi Sisyphus/armh/base/contents_index |cut -f2
> |sort -u |wc -l
> 128

Это то, что собиралось с gnu-config до коммита ee9898641088ae9169de0453ce475d371f9d5016.

> $ grep -F armv7l-alt-linux-gnueabi Sisyphus/armh/base/contents_index |cut
> -f2 |sort -u |wc -l
> 41

А это - то, что успело собраться с gnu-config, в котором уже есть коммит ee9898641088ae9169de0453ce475d371f9d5016.

Даже не знаю, что делать.

1. Если оставить gnu-config как есть, то при следующей пересборке gcc, binutils, у них ВНЕЗАПНО изменится триплет.
2. С другой стороны, условно низкоуровневый код (gmp, например) хорошо знает, что такое armv7l-*-linux-gnueabi, а вот что такое armh-*-linux-gnueabi - как-то не очень.
   Из-за этого configure может решить не использовать ассемблерные реализации, или вообще сказать - а я не знаю, что это за платформа такая.

(In reply to Alexey Sheplyakov from comment #3)
> (Ответ для Dmitry V. Levin на комментарий #2)
> > Мы выяснили, что это стало следствием
> > https://git.savannah.gnu.org/cgit/config.git/commit/
> > ?id=ee9898641088ae9169de0453ce475d371f9d5016
> > 
> > Как видно, в репозитории с этим нет консистентности:
> > $ grep -F armh-alt-linux-gnueabi Sisyphus/armh/base/contents_index |cut -f2
> > |sort -u |wc -l
> > 128
> 
> Это то, что собиралось с gnu-config до коммита
> ee9898641088ae9169de0453ce475d371f9d5016.
> 
> > $ grep -F armv7l-alt-linux-gnueabi Sisyphus/armh/base/contents_index |cut
> > -f2 |sort -u |wc -l
> > 41
> 
> А это - то, что успело собраться с gnu-config, в котором уже есть коммит
> ee9898641088ae9169de0453ce475d371f9d5016.
> 
> Даже не знаю, что делать.
> 
> 1. Если оставить gnu-config как есть, то при следующей пересборке gcc,
> binutils, у них ВНЕЗАПНО изменится триплет.

Этот коммит в Сизифе с конца позапрошлого года, за это время весь тулчейн уже пересобирался.

> 2. С другой стороны, условно низкоуровневый код (gmp, например) хорошо
> знает, что такое armv7l-*-linux-gnueabi, а вот что такое
> armh-*-linux-gnueabi - как-то не очень.
>    Из-за этого configure может решить не использовать ассемблерные
> реализации, или вообще сказать - а я не знаю, что это за платформа такая.

Жалобы на это и послужили причиной того коммита в gnu config.

(Ответ для Dmitry V. Levin на комментарий #4)
> (In reply to Alexey Sheplyakov from comment #3)
> > (Ответ для Dmitry V. Levin на комментарий #2)
> > > Мы выяснили, что это стало следствием
> > > https://git.savannah.gnu.org/cgit/config.git/commit/
> > > ?id=ee9898641088ae9169de0453ce475d371f9d5016
> > > 
> > > Как видно, в репозитории с этим нет консистентности:
> > > $ grep -F armh-alt-linux-gnueabi Sisyphus/armh/base/contents_index |cut -f2
> > > |sort -u |wc -l
> > > 128
> > 
> > Это то, что собиралось с gnu-config до коммита
> > ee9898641088ae9169de0453ce475d371f9d5016.
> > 
> > > $ grep -F armv7l-alt-linux-gnueabi Sisyphus/armh/base/contents_index |cut
> > > -f2 |sort -u |wc -l
> > > 41
> > 
> > А это - то, что успело собраться с gnu-config, в котором уже есть коммит
> > ee9898641088ae9169de0453ce475d371f9d5016.
> > 
> > Даже не знаю, что делать.
> > 
> > 1. Если оставить gnu-config как есть, то при следующей пересборке gcc,
> > binutils, у них ВНЕЗАПНО изменится триплет.
> 
> Этот коммит в Сизифе с конца позапрошлого года, за это время весь тулчейн
> уже пересобирался.

Отлично. Значит последствия не столь страшны, как я себе их представлял.


> > 2. С другой стороны, условно низкоуровневый код (gmp, например) хорошо
> > знает, что такое armv7l-*-linux-gnueabi, а вот что такое
> > armh-*-linux-gnueabi - как-то не очень.
> >    Из-за этого configure может решить не использовать ассемблерные
> > реализации, или вообще сказать - а я не знаю, что это за платформа такая.
> 
> Жалобы на это и послужили причиной того коммита в gnu config.

Значит, просто пересобираю в задании 317766 пострадавшие пакеты (ImageMagick, libfreetype)?

(In reply to Alexey Sheplyakov from comment #5)
> Значит, просто пересобираю в задании 317766 пострадавшие пакеты
> (ImageMagick, libfreetype)?

Да.

(Ответ для Dmitry V. Levin на комментарий #6)
> (In reply to Alexey Sheplyakov from comment #5)
> > Значит, просто пересобираю в задании 317766 пострадавшие пакеты
> > (ImageMagick, libfreetype)?
> 
> Да.

Попробовал. Стало ещё хуже:

https://git.altlinux.org/tasks/317766/logs/events.6.1.log

2023-Apr-01 00:50:58 :: unmets: armh +492 -0 =504
2023-Apr-01 00:50:59 :: dependencies check FAILED
2023-Apr-01 00:50:59 :: task #317766 for sisyphus FAILED

Для сборки libfreetype требуется libharbuzz-devel, см. (https://git.altlinux.org/srpms/l/libfreetype.git?p=libfreetype.git;a=blob;f=libfreetype.spec;h=aede1044d42071043915d690676109114bdf9676;hb=7b26e395ccd157a5cd52721554d3be538cba2d94#l26

А libharfbuzz-devel среди прочего зависит от libfreetype-devel:
$ apt-cache show libharfbuzz-devel | grep -e '^Depends' | tr ',' '\n'
Depends: /usr/lib64/pkgconfig
 glib2-devel
 libfreetype-devel
 libgraphite2-devel
 libicu-devel
 pkgconfig(glib-2.0)
 pkgconfig(gobject-2.0)
 libharfbuzz-icu (= 3.2.0-alt1:p10+310099.70.8.1)
 libharfbuzz-gobject (= 3.2.0-alt1:p10+310099.70.8.1)

Чтобы пересобрать libfreetype-devel, нужно установить libfreetype-devel, а у libfreetype-devel сломана зависимость (от /usr/bin/armh-alt-linux-gnueabi-pkg-config)

Значит, придётся фиксить сборку пакета libfreetype, например, путём добавления
export PKG_CONFIG=pkg-config
перед %configure.

Вообще devel-пакеты совершенно напрасно зашивают путь к pkg-config, да ещё и архитектурно-зависимый.

(Ответ для Dmitry V. Levin на комментарий #8)
> Значит, придётся фиксить сборку пакета libfreetype, например, путём
> добавления
> export PKG_CONFIG=pkg-config
> перед %configure.

Помогло.

> Вообще devel-пакеты совершенно напрасно зашивают путь к pkg-config, да ещё и
> архитектурно-зависимый.

Нет, не напрасно, а для поддержки кросс-компиляции (ПО, использующего данную библиотеку). Другое дело, что скрипт freetype-config сам по себе плохо сочетается с кросс-компиляцией -- кто ж добавляет в PATH $SYSROOT/bin? Но наши devel пакеты для кросс-компиляции (а точнее установки в SYSROOT) всё равно непригодны - в .pc файлах добрые люди удалили ${libdir} из Libs.

(Ответ для Alexey Sheplyakov на комментарий #9)
> (Ответ для Dmitry V. Levin на комментарий #8)
> > Значит, придётся фиксить сборку пакета libfreetype, например, путём
> > добавления
> > export PKG_CONFIG=pkg-config
> > перед %configure.
> 
> Помогло.
> 
> > Вообще devel-пакеты совершенно напрасно зашивают путь к pkg-config, да ещё и
> > архитектурно-зависимый.
> 
> Нет, не напрасно, а для поддержки кросс-компиляции (ПО, использующего данную
> библиотеку). 

Интересно - а почему это происходит только на armh?

Что-то я листал листал вашу переписку и так и не понял - вот этот изменение в ImageMagick оно чем обусловлено?

+export PKG_CONFIG=pkg-config
 %configure \

Я правильно понимаю, что в devel пакет влетает прямой путь к pkg-config ?
Может быть чинить это надо не таким способом, а где-то в autotools ?

(In reply to Anton Farygin from comment #11)
> Что-то я листал листал вашу переписку и так и не понял - вот этот изменение
> в ImageMagick оно чем обусловлено?
> 
> +export PKG_CONFIG=pkg-config
>  %configure \
> 
> Я правильно понимаю, что в devel пакет влетает прямой путь к pkg-config ?

Да, пакет во время сборки сперва спрашивает полный путь к pkg-config (имеет на это право),
а потом зачем-то зашивает этот полный путь в devel-пакет (а это уже лишнее).

> Может быть чинить это надо не таким способом, а где-то в autotools ?

См. комментари45727#c4
Непонятно, что тут чинить в autotools.
Это проявляется только на armh, инвестировать в кото

(In reply to Anton Farygin from comment #11)
> Что-то я листал листал вашу переписку и так и не понял - вот этот изменение
> в ImageMagick оно чем обусловлено?
> 
> +export PKG_CONFIG=pkg-config
>  %configure \
> 
> Я правильно понимаю, что в devel пакет влетает прямой путь к pkg-config ?

Да, пакет во время сборки сперва спрашивает полный путь к pkg-config (имеет на это право),
а потом зачем-то зашивает этот полный путь в devel-пакет (а это уже лишнее).
В Сизифе, видимо, всего 2 пакета, которые так сделали.

> Может быть чинить это надо не таким способом, а где-то в autotools ?

См. комментарий #c4.

Вроде бы autotools всё делает правильно, просто у libfreetype-devel циклические сборочные зависимости, его нельзя просто так взять и пересобрать после пересборки pkg-config.

Поскольку это проявляется только на armh (спасибо за инновационное название архитектуры), инвестировать в которую никто не собирается, скорее наоборот, проще сделать export PKG_CONFIG=pkg-config.

(оказывается, багзилла иногда коммитит комментарии, когда делаешь Preview, зря она это делает)

https://packages.altlinux.org/ru/tasks/317766/

остался один аппрув на freetype