Я не хочу, чтобы это было по умолчанию.
Кому надо, тот добавит.

В сборочнице sisyphus x86_32 подключены? Если да, то меня устроит.

Т.е. для x86_64 с -m32 собирать на git.alt не получиться. Так?

За конфигурацию apt в сборочнице git.alt отвечает girar-builder.
Пакет apt-conf-sisyphus к этому никакого отношения не имеет.

(In reply to comment #2)
> В сборочнице sisyphus x86_32 подключены? Если да, то меня устроит.

Нет, не подключены.

(In reply to comment #3)
> Т.е. для x86_64 с -m32 собирать на git.alt не получиться. Так?

Нет, не получится.
По крайней мере, до тех пор, пока girar-builder не научится генерить пакеты для x86-32 автоматически при обработке каждого задания.

(В ответ на комментарий №4)
> За конфигурацию apt в сборочнице git.alt отвечает girar-builder.
Да какая разница! Или перевесь на более подходящий пакет.

> пока girar-builder не научится генерить пакеты для x86-32
Отдельную багу повесить?

*** Bug 25162 has been marked as a duplicate of this bug. ***

2cas@ не спешите с distro-blocker, так как не вполне понятно является ли именно эта бага ключом к решению проблемы

(In reply to comment #7)
> 2cas@ не спешите с distro-blocker, так как не вполне понятно является ли именно
> эта бага ключом к решению проблемы

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

(В ответ на комментарий №8)
> Не distro-blocker, поскольку не блокирует выпуск дистрибутивов.
> Для дистрибутивов, база пакетов для которых по определению зафиксирована,
Зато блокирует выпуск бранча 6.0, поскольку сейчас x86_32 разломан напрочь.

(In reply to comment #9)
> (В ответ на комментарий №8)
> > Не distro-blocker, поскольку не блокирует выпуск дистрибутивов.
> > Для дистрибутивов, база пакетов для которых по определению зафиксирована,
> Зато блокирует выпуск бранча 6.0, поскольку сейчас x86_32 разломан напрочь.

Ну, поскольку gcc -m32 работает, утверждать, что сейчас x86_32 разломан напрочь, как минимум некорректно.  Если каких-то пакетов не хватает, то надо просто дописывать их arepo.conf.  Когда в Сизифе наступит относительная стабилизация по библиотекам, то поддерживать arepo.conf в актуальном состоянии будет несложно. Последний раз x86_32 сломался после исчезновения из Сизифа пакета libgtk+2-common.

(В ответ на комментарий №10)
> Ну, поскольку gcc -m32 работает, утверждать, что сейчас x86_32 разломан
> напрочь, как минимум некорректно.
Да, некорректно здесь. Я имел ввиду репозиторий x86_32 (bug#25187) сейчас разломан наглухо.

(В ответ на комментарий №10)
> Последний раз x86_32 сломался после исчезновения из Сизифа
> пакета libgtk+2-common.
И это до сих пор не починили.

(In reply to comment #12)
> (В ответ на комментарий №10)
> > Последний раз x86_32 сломался после исчезновения из Сизифа
> > пакета libgtk+2-common.
> И это до сих пор не починили.

Наверное, за этим плохо следят.

(В ответ на комментарий №13)
> Наверное, за этим плохо следят.
Да. Подпинывание в bug#24578 редко помогает

(В ответ на комментарий №10)
> Ну, поскольку gcc -m32 работает
Противоречие (см. коментерий #4).

(В ответ на комментарий №10)
> Когда в Сизифе наступит относительная стабилизация по библиотекам,
> то поддерживать arepo.conf в актуальном состоянии будет несложно.
Там, похоже, более серьезная проблема с новыми появившимися зависимостями.

(В ответ на комментарий №16)
> похоже, более серьезная проблема с новыми появившимися зависимостями.
Не, моя локальная проблема. Тогда непонятно, почему разломан x86_32 ...
Видимо, не плохо, а очень плохо следят.

Во избежание коллизий с настоящей архитектурой x86_32 от intel
имя arepo-архитектуры будет i586-x86_64 ($ARCH_donor-$ARCH_acceptor).

(In reply to comment #18)
> Во избежание коллизий с настоящей архитектурой x86_32 от intel
> имя arepo-архитектуры будет i586-x86_64 ($ARCH_donor-$ARCH_acceptor).

Или, наоборот, x86_64-i586, чтобы подчеркнуть, что пакеты там для x86_64.

x86_48 -- компромисс и гуглиться будет хорошо. :]

x86_2^5 :)

(В ответ на комментарий №19)
> Или, наоборот, x86_64-i586
+1

Встречайте x86_64-i586.