Your message dated Sun, 19 Feb 2023 01:03:08 +0000
with message-id <e1pty6e-00aph6...@fasolo.debian.org>
and subject line Bug#1031519: Removed package(s) from unstable
has caused the Debian Bug report #988108,
regarding gitlab: Repeated issues resolving dependencies on upgrade
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
988108: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988108
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: gitlab
Version: 13.9.6+ds1-1~fto10+1
Severity: important

Dear Maintainer,

unfortunately, I have repeatedly issues when upgrading gitlab to a new
version. My system is basically as recommended in the Debian Wiki with
Buster as basis plus Backports and Fasttrack. However, I am often
running in a situation that packages are actually *too new* and Gitlab
fails configuring because it expects a certain version of a package in
its Gemfile.

E.g., to upgrade to Gitlab version 13.9.6+ds1-1~fto10+1 today, I
iteratively *downgraded* ruby packages, re-run the Gitlab
installation, which then failed because another package was too new,
and so on. Finally, for 13.9.6+ds1-1~fto10+1, I needed to downgrade
these packages:

* ruby-autoprefixer-rails=10.2.4.0+dfsg1+~cs14.2.17-1
* ruby-devise-two-factor=3.1.0-2~bpo10+1
* ruby-fog-google=1.12.1-1~fto10+1
* ruby-discordrb-webhooks=3.3.0-1
* ruby-ruby-magic-static=0.3.5-1
* ruby-gitlab-labkit=0.15.0-1~fto10+2
* ruby-batch-loader=1.4.1+dfsg.1-3
* ruby-gitlab-experiment=0.4.9-1~fto10+1
* ruby-lockbox=0.3.5-2~bpo10+1
* ruby-rotp=2.1.1+dfsg-1

Of course, I need to hold them all, since they'd be upgraded
automatically otherwise.

One solution I could think of would be to provide a dependency-package
with hard version requirements. So, in contrast to
gitlab-apt-pin-preferences, such a package would directly depend on
all Gitlab-dependencies in their correct version for a particular
version of Gitlab. That way, I'd only need to pin a single package and
get a reproducible working installation. What do you think about that?

Best,
Maximilian

--- End Message ---
--- Begin Message ---
Version: 13.4.7-2+rm

Dear submitter,

as the package gitlab has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/1031519

The version of this package that was in Debian prior to this removal
can still be found using https://snapshot.debian.org/.

Please note that the changes have been done on the master archive and
will not propagate to any mirrors until the next dinstall run at the
earliest.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmas...@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Scott Kitterman (the ftpmaster behind the curtain)

--- End Message ---

Reply via email to