On 21/04/2022 14:12, Pirate Praveen wrote:
2022, ഏപ്രിൽ 21 5:27:25 PM IST, "Éric Valette" <eric.vale...@free.fr>ൽ എഴുതി
The breakage is there for more than 8 months. I tried to install regularly.
Even if I want to, I'm not able to support gitlab in unstable or experimental.
That is the reason why I had to create fasttrack.debian.net
Gitlab changes too fast for unstable or experimental.
I would say the contrary : experimental version are always above what
gitlab expects. experiùmental is way faster than gitlab.
Putting gitlab related packages in experimental or unstable that you
know cannot install is just frustrating. People have someting cretaed
private packages version.
In this specific case multiple upstream gems needs to updated to work with
omniauth 2.0. There are upstream bugs filed already. I can't step in as
upstream maintainers of all those gems. More help is always welcome.
I does not work either if you bstarted from a testing ISO.
Yes, only stable is currently supported. More volunteers to support testing,
unstable or experimental welcome.
Ben then why do yopu publsih pacakages that have no chnace to install
for unstable and experimental.
Even outside gitlab, only stable is officially supported, unstable remains
broken for many days during transitions.
See wiki.debian.org/gitlab
Been ther done that. No way to make it work. FIX your package dependency. Its broken for as long as 1.9.1-1 has been in unstable meaning April 2020 see https://tracker.debian.org/pkg/ruby-omniauth
I meant follow the recommended option, that is bullseye-fasttrack.
Evne with buleyes fastrack, once you installed a testing iso and updated
you are scewed.
Could you please follow the rules and publish in experimental things that works
with a debian unstable system.
I'm not able to do this alone, even if I want to, this is too much work for a
single maintainer. At this point only bullseye-fasttrack I can reasonably
support.
Then avoid publishing package for other debian version.
-- eric
