Bug#930795: unblock: ruby-airbrussh/1.3.2-1

2019-08-23 Thread Samuel Henrique
Hello,

Uploaded: ruby-airbrussh_1.3.1-2+deb10u1_source.changes ACCEPTED into
proposed-updates->stable-new

Thanks for your work and help Adam and Paul,


-- 
Samuel Henrique 


Bug#930795: unblock: ruby-airbrussh/1.3.2-1

2019-08-23 Thread Adam D. Barratt
Control: tags -1 + confirmed

On Wed, 2019-08-21 at 00:22 +0100, Samuel Henrique wrote:
> I backported the fix to 1.3.1-2, the version is 1.3.1-2+deb10u1 and I
> will need to wait until 1.3.3-1 hits testing*, which is fine (2
> days), to upload it.
> 
> * because the current version in testing is the same as in stable,
> and the version in testing needs to be higher/bug fixed in there as
> well.
> 

OK, thanks.

Regards,

Adam



Bug#930795: unblock: ruby-airbrussh/1.3.2-1

2019-08-23 Thread Samuel Henrique
Control: tags -1 - moreinfo

Removing moreinfo tag as 1.3.3-1 is on testing and the debdiff for
1.3.1-2+deb10u1 is attached in the previous email,

Thanks,

-- 
Samuel Henrique 


Bug#930795: unblock: ruby-airbrussh/1.3.2-1

2019-08-20 Thread Samuel Henrique
Hello Adam,

Thanks for your patience and explanation, here's the debdiff with the
solution I picked,

I backported the fix to 1.3.1-2, the version is 1.3.1-2+deb10u1 and I will
need to wait until 1.3.3-1 hits testing*, which is fine (2 days), to upload
it.

* because the current version in testing is the same as in stable, and the
version in testing needs to be higher/bug fixed in there as well.

Regards,

-- 
Samuel Henrique 


ruby-airbrussh_1.3.1-2+deb10u1.debdiff
Description: Binary data


Bug#930795: unblock: ruby-airbrussh/1.3.2-1

2019-08-20 Thread Adam D. Barratt
On Tue, 2019-08-20 at 22:22 +0100, Samuel Henrique wrote:
> Hello Adam,
> 
> > It certainly can't be 1.3.2-1+deb10u1, as that version number is
> > higher
> > than the package in unstable. Either one would need to go with
> > 1.3.1-
> > 2+deb10u1 with just the bug fix applied, or 1.3.2-1~deb10u1 with a
> > "backports-style" changelog containing both 1.3.2-1 and then the
> > stable
> > update. In either case we would need a debdiff that reflects the
> > chosen
> > approach.
> > 
> > One thing that will need to be fixed in unstable first either way:
> > 
> > Not built on buildd: arch all binaries uploaded by samueloph
> > 
> > As per the d-d-a announcement, that will need a new source upload
> > to
> > unstable to resolve, as arch:all can't be usefully binNMUed.
> 
> I just uploaded 1.3.3-1 (source-only) to unstable, can I just wait
> until it migrates to testing and then go with "1.3.2-1+deb10u1" ?
> If so, I will remove the "moreinfo" tag when it the package migrates
> to Testing (in 2 days) and we can use the latest debdiff on this
> thread.

That doesn't really make sense as a version here, as it's not a stable
update on top of 1.3.2-1; stable only has 1.3.1-2.

If you really want to go with the complete version rather than just the
specific fix, then either 1.3.2-1~deb10u1 - and therefore with the
original 1.3.2-1 changelog with a "backports style" entry on top - or
1.3.2-0+deb10u1.

Regards,

Adam



Bug#930795: unblock: ruby-airbrussh/1.3.2-1

2019-08-20 Thread Samuel Henrique
Hello Adam,

It certainly can't be 1.3.2-1+deb10u1, as that version number is higher
> than the package in unstable. Either one would need to go with 1.3.1-
> 2+deb10u1 with just the bug fix applied, or 1.3.2-1~deb10u1 with a
> "backports-style" changelog containing both 1.3.2-1 and then the stable
> update. In either case we would need a debdiff that reflects the chosen
> approach.
>
> One thing that will need to be fixed in unstable first either way:
>
> Not built on buildd: arch all binaries uploaded by samueloph
>
> As per the d-d-a announcement, that will need a new source upload to
> unstable to resolve, as arch:all can't be usefully binNMUed.
>

I just uploaded 1.3.3-1 (source-only) to unstable, can I just wait until it
migrates to testing and then go with "1.3.2-1+deb10u1" ?
If so, I will remove the "moreinfo" tag when it the package migrates to
Testing (in 2 days) and we can use the latest debdiff on this thread.

Thanks,

-- 
Samuel Henrique 


Bug#930795: unblock: ruby-airbrussh/1.3.2-1

2019-08-19 Thread Adam D. Barratt
Control: tags -1 + moreinfo

On Tue, 2019-08-20 at 00:33 +0100, Samuel Henrique wrote:
> Thanks for your help Paul :)
> 
> I'm attaching a debdiff for 1.3.2-1+deb10u1, release team please
> advise whether that's acceptable or not (please read discussion on
> the bugreport),

It certainly can't be 1.3.2-1+deb10u1, as that version number is higher
than the package in unstable. Either one would need to go with 1.3.1-
2+deb10u1 with just the bug fix applied, or 1.3.2-1~deb10u1 with a
"backports-style" changelog containing both 1.3.2-1 and then the stable
update. In either case we would need a debdiff that reflects the chosen
approach.

One thing that will need to be fixed in unstable first either way:

Not built on buildd: arch all binaries uploaded by samueloph

As per the d-d-a announcement, that will need a new source upload to
unstable to resolve, as arch:all can't be usefully binNMUed.

Regards,

Adam



Bug#930795: unblock: ruby-airbrussh/1.3.2-1

2019-08-19 Thread Samuel Henrique
Thanks for your help Paul :)

I'm attaching a debdiff for 1.3.2-1+deb10u1, release team please advise
whether that's acceptable or not (please read discussion on the bugreport),

Regards,

-- 
Samuel Henrique 


ruby-airbrussh_1.3.2-1+deb10u1.debdiff
Description: Binary data


Bug#930795: unblock: ruby-airbrussh/1.3.2-1

2019-07-02 Thread Paul Gevers
retitle 930795 buster-pu: package ruby-airbrussh
user release.debian@packages.debian.org
usertags 930795 - unblock
usertags 930795 pu
tags 930795 buster
thanks

On 02-07-2019 01:14, Samuel Henrique wrote:
> I can see you have lots of work to do, so if you feel like this should
> not be fixed for the first Buster release, I will try to address this
> with stable-updates, if you think that's acceptable.
> 
> With my maintainer's hat on I say that it's important to fix this before
> releasing Buster, and the changes are very trivial, but I do acknowledge
> that the best person to make the call here is someone from the release
> team, so whatever you say I'm fine with it.

The time for unblocks for buster has come and gone. The deadline was
last weeks Tuesday, we are now in deep freeze. I propose you prepare a
stable release update targeting buster, such that this can be fixed in
the first point release. I have updated this bugs metadata to reflect
that. Please discuss your proposal with the stable release managers in
this bug.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#930795: unblock: ruby-airbrussh/1.3.2-1

2019-07-01 Thread Samuel Henrique
Control: tags -1 - moreinfo

Hello Paul,

Control: tags -1 moreinfo
>

I removed the moreinfo tag as I assume now you will have enough information
to make a judgement call on this one, feel free to tell me if I should not
have done so.


> > I'm asking for the unblock of ruby-airbrussh
> > because a critical bug was solved in the last upload.
> >
> > The bug is related to the package throwing an exception when dealing
> > with non UTF-8 characters coming from SSH.
>
> Can you elaborate a bit why the severity? (Would have been nice to have
> that description in the bug you didn't file). Looking at the upstream
> bug, it may just be confusing to the user and ugly of course as rsync
> was said to keep on running. Is rsync in Debian broken in the same way?
>

So, the main problem here is that when using capistrano (a deployment
tool), the user will think that the deployment failed because
ruby-airbrussh will have problems with non UTF-8 characters coming from
SSH`ed rsync.
I do not have reasons to think that rsync is broken in the same way, as the
main problem here is misguiding the user into thinking that there is
something wrong with the deployment.
Capistrano is used for production critical pipelines at some companies.

In summary, the deployment will probably occur normally, but the only
guarantee of that would be the user having to manually debug the error and
checking whether it succeeded or not under the hood.


> > I decided to upload the latest release instead of patching the previous
> > release
>
> Which still means review work by us. We do have quite some unblocks
> coming in this last freeze moment.
>

I can see you have lots of work to do, so if you feel like this should not
be fixed for the first Buster release, I will try to address this with
stable-updates, if you think that's acceptable.

With my maintainer's hat on I say that it's important to fix this before
releasing Buster, and the changes are very trivial, but I do acknowledge
that the best person to make the call here is someone from the release
team, so whatever you say I'm fine with it.


-- 
Samuel Henrique 


Bug#930795: unblock: ruby-airbrussh/1.3.2-1

2019-06-21 Thread Paul Gevers
Control: tags -1 moreinfo

Hi Samuel

On 20-06-2019 20:38, Samuel Henrique wrote:
> I'm asking for the unblock of ruby-airbrussh
> because a critical bug was solved in the last upload.
> 
> The bug is related to the package throwing an exception when dealing
> with non UTF-8 characters coming from SSH.

Can you elaborate a bit why the severity? (Would have been nice to have
that description in the bug you didn't file). Looking at the upstream
bug, it may just be confusing to the user and ugly of course as rsync
was said to keep on running. Is rsync in Debian broken in the same way?

> I decided to upload the latest release instead of patching the previous
> release

Which still means review work by us. We do have quite some unblocks
coming in this last freeze moment.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#930795: unblock: ruby-airbrussh/1.3.2-1

2019-06-20 Thread Samuel Henrique
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hello,

I'm asking for the unblock of ruby-airbrussh
because a critical bug was solved in the last upload.

The bug is related to the package throwing an exception when dealing with
non UTF-8 characters coming from SSH.

I decided to upload the latest release instead of patching the previous
release because the only functionality change of the latest release is this
one, all the other changes can't possibly affect the package, and in this
case it's simpler to have the latest release then to patch it and possibly
induce the users to think that this problem is not fixed:

* Files changed that fix this problem:
  - lib/airbrussh/console.rb

* Other files changed, not needed to fix the problem, can't break anything
and makes the package better:
  - test/airbrussh/console_test.rb (it's a new test case for this problem)

* Other files changed, not needed to fix the problem, can't break anything
and does not make any difference on the package:
  - appveyor.yml
  - CHANGELOG.md
  - lib/airbrussh/version.rb
  - LICENSE.txt
  - .travis.yml
As you can see, all of the files in this case are metadata files.

I didn't open a RC bug on BTS because I'm assuming it's not necessary as we
already have the upstream one and the fix is already on Unstable.

This is the bug that was fixed in this new release:
https://github.com/mattbrictson/airbrussh/issues/120
PR + some discussion:
https://github.com/mattbrictson/airbrussh/pull/121

Special attention to the fact that the bug was noticed while using
capistrano, which depends on this package and was the only reason I
packaged it.

Thanks,

-- 
Samuel Henrique 


ruby-airbrussh.debdiff
Description: Binary data