[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#925602: unblock: ruby-globalid/0.4.2-1



Hey,

On Thu, Mar 28, 2019 at 2:16 AM Paul Gevers <elbrus@debian.org> wrote:
Control: tags -1 moreinfo

Hi Utkarsh,

On 27-03-2019 14:30, Utkarsh Gupta wrote:
> Please unblock package ruby-globalid.
>
> Recently, there was a bug (#925178) reported against the package with
> severity: important.

Did you see my last note in that bug?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925178#21

Apologies. I didn't see it earlier :(
Answering below.

Care to answer it here?
'''
On 24-03-2019 07:21, Debian Bug Tracking System wrote:
>  ruby-globalid (0.4.2-1) unstable; urgency=medium
>  .
>    * Team upload
>    * New upstream version 0.4.2
>    * Add patch to fix regression (Closes: #925178)
>    * Drop patches that are merged in upstream
>    * Bump debhelper compatibility level to 11
>    * Bump Standards-Version to 4.3.0 (no changes needed)
>    * Fix insecure URL

Thanks for the quick fix for this issue. However, due to the new
upstream version and the debhelper compatibility bump this version is
not eligible [1] for an unblock for buster.

Did rails 2:5.2.2.1+dfsg-1 break ruby-globalid or did it only break the
autopkgtest of it? I'm asking because this version of rails is fixing a
CVE's which we want in buster, but the autopkgtest failure (and the
freeze) is blocking it.

It was breaking just the autopkgtest, thus the regression.
Everything else was fine.

Paul

[1] https://release.debian.org/buster/freeze_policy.html
'''

> The package was in testing and the bug was reported on 20th March and
> was resolved in the latest upload, which was on 24th March.
> This also causes regression in the migration of rails' latest update.
>
> Hence, request you to:
>
> unblock ruby-globalid/0.4.2-1

Not likely in the current state.

ruby-activejob from rails is the only reverse dependency of ruby-globalid.
Since the package is in good shape now, perhaps could be given an exception?
And it won't be risky either since ruby-activejob is the only rev-dep :)
Also, it was an RC bug at the last moment (though I understand the scenario here) :(

Paul


Best,
Utkarsh

Reply to: