Ничего с пакетом сделать нельзя, так как в p11 та же версия, что и в Сизифе. Поднимите релиз, если не хотите исправлять очевидную проблему.

(Ответ для Антон Мидюков на комментарий #1)
> Ничего с пакетом сделать нельзя, так как в p11 та же версия, ...

И когда это стало препятствием для сборки нового релиза в бранчи?

(Ответ для Yuri N. Sedunov на комментарий #2)
> (Ответ для Антон Мидюков на комментарий #1)
> > Ничего с пакетом сделать нельзя, так как в p11 та же версия, ...
> 
> И когда это стало препятствием для сборки нового релиза в бранчи?

С момента появления проверки на сборочнице, что EVR пакета в бранче не может быть выше, чем в sisyphus. Полагаю, что эта проверка появилась более 10 лет назад.

Иди учить матчасть про именование релизов в бранчах.

(Ответ для Yuri N. Sedunov на комментарий #4)
> Иди учить матчасть про именование релизов в бранчах.

libical-3.0.20-alt1 скопировали в p11 вы:
https://packages.altlinux.org/ru/tasks/386426/

С тех пор у мейнтейнеров p11 руки связаны.

Ты гонишь пургу и несешь околесицу.

Тебе ничего не мешает делать с пакетом libical, что захочешь в p11 и других бранчах, кто бы его туда не скопировал.

(Ответ для Yuri N. Sedunov на комментарий #4)
> Иди учить матчасть про именование релизов в бранчах.
Юр, а что там учить-то?  Если и в sisyphus, и в p11 одна и та же 3.0.20-alt1 -- со стороны бранча это не решается кроме как понижением релиза (или версии) с выставлением Serial:/Epoch:, а это заявка на вечный форк (ну или обсериаливание сизифного пакета).

Иначе см. girar.git по "not newer":
http://git.altlinux.org/people/glebfm/packages/?p=girar.git&a=blob&f=bin/girar-task-add&h=4f1486fb1d2377be65d556537f6dc05fa630e8c5&hb=HEAD#l198
http://git.altlinux.org/people/glebfm/packages/?p=girar.git&a=blob&f=bin/girar-task-run&h=637517cd0dc01ac632bc8707be52e6ec8885bac7&hb=HEAD#l297

Сделай хотя бы просто release bump в сизифе, а лучше с убиранием устаревшего условия -- Антон же по делу просит.

2 antohami: если конфликтов по другим спекам нет, срочный обход --
выставить на сборочнице в gb-sh-conf-c11f1 следующее:

GB_REPO_RPMARGS="$GB_REPO_RPMARGS --with system_tzdata"

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

(In reply to Yuri N. Sedunov from comment #4)
Юрий, мне очень не нравится тон, в котором вы общаетесь с коллегами.

В техническом плане вы тоже ошибаетесь.  В любом случае, в этом пакете нужно всегда использовать системный tzdata.  Если это значит, что нужно обновить tzdata в конкретном бранче, то именно это и нужно сделать, а не бандлить tzdata в каждый отдельный пакет.

libical-3.0.20-alt2 -> sisyphus:

Mon Aug 10 2026 Gleb F-Malinovskiy <glebfm@altlinux> 3.0.20-alt2
- Enabled system tzdata switch regardless of target repository (ALT#60123).

(Ответ для Антон Мидюков на комментарий #0)
> Необходимо убрать условия сборки для бранчей в libical:
> %if "%altbranch" == "sisyphus" || "%altbranch" == "p11" [...]
Более полный фрагмент:

%ifdef _priority_distbranch
%define altbranch %_priority_distbranch
%else
%define altbranch %(rpm --eval %%_priority_distbranch)
%endif

%if "%altbranch" == "%nil"
%define altbranch sisyphus
%endif

%if "%altbranch" == "sisyphus" || "%altbranch" == "p11"
%def_with system_tzdata
%else
%def_without system_tzdata
%endif

Обстановка на sisyphus_e2k (который сейчас вообще-то запитан из p11):

e16c:~> rpm --eval %_priority_distbranch
sisyphus_e2k

Странно, поскольку в gb-sh-conf-sisyphus_e2k выставлено (тж. rm#225340):

GB_REPO_RPMARGS="$GB_REPO_RPMARGS --define '_priority_distbranch p11'"

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

> В более старые бранчи сборка этой версии не планируется поэтому не нужно.
В p10 сейчас libical 3.0.11 -- т.е. та же ветка, отличие в минорах;
с другой стороны, если кому угораздит, так пусть для p10/c10 бэкпорт с подъёмом версии от того спека и делает, у сизифа p12 уже не за горами.

PS: пока готовил обновку, прошла сборка 3.0.20-alt2 заданием
http://git.altlinux.org/tasks/archive/done/_418/429048/ с
http://git.altlinux.org/srpms/l/libical.git?p=libical.git;a=commitdiff;h=daf16170d779c4423a4c1b09908147764a6a755c

> Подозреваю, что на остальных догоняющих архитектурах тоже могут быть нюансы.

Например:

# uname -m
loongarch64
# rpm --eval %_priority_distbranch
p11_loongarch64

В _priority_distbranch попадает disttag, который по традиции совпадает с именем репозитория. А репозитории у нас традиционно называются <branch>_<arch>, например sisyphus_riscv64, p11_loongarch64. Не думаю, что сейчас это можно передалать.

Надо идти грепать спеки.