[Pkg-privacy-maintainers] New torbrowser-launcher upstream version is out Was: Bug#803171: this only affects one profile in complaint mode

[u]

Hi,

intrigeri:
> Holger Levsen wrote (12 Jul 2016 18:23:04 GMT) :
>> On Mon, Jul 11, 2016 at 04:55:00PM +0000, u wrote:
>>> We did not agree on that, however, if you look at the state of the
>>> pristine-tar branch it's simply a fact that the latest versions did not
>>> use it anymore. Unless I miss something here. This branch is not even
>>> present at
>>> https://anonscm.debian.org/git/pkg-privacy/packages/torbrowser-launcher.git
>>> anymore.
>>>
>>> I *do* have a local copy of the pristine-tar branch from about a year
>>> ago, when I last worked on this package. So, either somebody takes care
>>> of putting the branch back it into shape or we disable it in gbp.conf.
>>> That's what I have done for the time being.
>>>
>>> Do you actually use pristine-tar? If yes, maybe you need to push your
>>> branch with the latest additions, and then I'll happily take care of
>>> updating it. In any case, I guess that one should also document how to
>>> update this package correctly in debian/README.source.
>>  
>> my point is: we agreed on this workflow, because we thought this was the
>> best possible workflow for this. so I would expect a discussion before
>> officially burying it.

We have never agreed on this workflow for this package. As explained
later by intrigeri, it's a fact that we never used pristine-tar for it,
otherwise there would be a branch. The branch I have locally might have
simply be the result of me trying to actually use pristine-tar for this
package.

>> (and no, I havent used pristine-tar here recently, in fact I think I did
>> the last upload ignoring pristine-tar. but this was ment as a temporal
>> thing, to get the upload done.)
> 
>> and as I tried to say in my first/last mail on this: I dont mind the
>> change. I mind the change without discussing it first.
> 
> [Context: I believe this discussion is about
> https://anonscm.debian.org/git/pkg-privacy/packages/torbrowser-launcher.git/commit/?h=debian/sid&id=16bcb4f92e5bd25647cb5696e4af81381eba11a6]

[... snip explanations by intrigeri ...]

> Now down to the actual change that's being discussed — encoding in
> debian/gbp.conf the way we use gbp for that package seems worthwhile
> to me:
> 
>  * it makes it easier, for those of us who do use gbp, to work on this
>    package (one less command-line switch one has to think to manually
>    pass gbp just for this package);
> 
>  * it documents how this package is _practically_ maintained, i.e.
>    the fact it's an exception to our best practices, which is useful
>    regardless of whether we see this exception as a problem: that file
>    is the only place where we can easily share per-package gbp config
>    between team members, and in particular it can be useful for those
>    of us who don't work regularly enough on torbrowser-launcher to
>    remember by heart how exactly it's different from our
>    other packages.

Correct.

> u:
>>> That is not correct. This english language bug is a new feature. It was
>>> not present before. Thus I fail to see how it can break current
>>> behaviour TBH.
> 
> New code can very well break apparently unrelated, and previously
> working, functionality. I'm sure we can agree on that :) I don't
> really understand how we can be stucked there at that point of the
> discussion, given the code and error output we've seen. I _guess_ it
> has to do with how the bug was reported to you, but I'd love to
> understand your reaction better.

Intrigeri reexplained to me what I missed here, that is that this
actually breaks torbrowser-launcher for all people who have an english
system locale. I did not understand that. I had mistakenly thought that
the problem only occurrs for people who use this checkbox.
So yes, obviously, we cannot upload the package in this state.

> I wanted to understand what was happening so I had a look.
> My understanding of the code and error output is that when tbl is
> started in en_US locales, self.force_en_checkbox is never set, so it's
> no surprise that the following statement:
> 
>         self.common.settings['force_en-US'] = self.force_en_checkbox.get_active()
> 
> … raises the exception reported by Jenkins.
> 
> I've tested it locally and I confirm that there's a serious regression:

Thanks.

Looks like a simple Debian patch fixing this could make the package
usable in its new upstream version, for the time being. I might give it
a try, but I'm very busy during the next days.

[.. here were cucumbers and more, miam. ..]

> [1] https://github.com/micahflee/torbrowser-launcher/issues/241

>>> If this is now actually a bullhead contest, I'm out. _Out_ as in "please
>>> remove me from Uploaders".

> I don't know what's a bullhead contest, but if it has something to do
> with insisting on a point despite failing to understand what the other
> party means, then I can see a couple such situations in this thread

It has something to do with not being clear I believe.

I think the bug about the locale being reported by means of a Jenkins
screenshot was not clear - so, sorry, but I thought we were talking
about a corner case and did not check the code which was causing this in
depth. I simply reported the bug upstream.

About the pristine-tar situation - well, I think intrigeri made it clear
what I was trying to say, that I was simply encoding in gbp.conf what
was being done already in practice. I failed to say that clearly too.

> (I'm not inferring that all what's happening is perfectly symmetric;
> it clearly isn't, given the power relationship that are in play).

Correct, it's not symmetric and that's not helping to improve the
situation, because we do not talk here as equals - and I very much had
the impression of not being taken seriously (thus the impression of a
bullhead contest).

> What can we, other team members, do to help fix this situation?

You did already.

Cheers.