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

u u at 451f.org
Mon Jul 11 16:55:00 UTC 2016


Hi,

Holger Levsen:
> Hi u,
> 
> On Sun, Jul 10, 2016 at 08:59:00PM +0000, u wrote:
>> Packaging is ready and tested! I'll push a bit later.
> 
> I'm a bit surprised about not using pristine-tar anymore. Did we agree
> on that on the list?

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.

> Then, as a minor nitpick, I wouldn't have done f8b9b90a1 as a revert,
> but rather as a simple file removal and normal commit. And then, I
> would have mentioned this in debian/changelog: "removed
> $description/$path patch as it has been merged upstream". (And that's
> actually a less minor comment…)

I agree that it's not very beautiful.

However that patch was my own addition before I merged the current tag,
and was not present in the previous version of tbl.

>>> Just be warned:
>>> https://jenkins.debian.net/view/torbrowser/job/torbrowser-launcher_test_on_unstable_amd64_from_git_branch_upstream_master/317/console
>>> looks like it is broken:
>>>
>>> Traceback (most recent call last):
>>>   File "/usr/lib/python2.7/dist-packages/torbrowser_launcher/settings.py", line 219, in install
>>>     self.save()
>>>   File "/usr/lib/python2.7/dist-packages/torbrowser_launcher/settings.py", line 240, in save
>>>     self.common.settings['force_en-US'] = self.force_en_checkbox.get_active()
>>> AttributeError: Settings instance has no attribute 'force_en_checkbox'
>>>
>>> That build is based on f79d4c42fc3fbf492ba9b602195bf7ca7c8909d9
>>> which is Micah's latest commit, verifyable as signed tag v0.2.5,
>>> in which the current debian/sid branch has been merged into and
>>> build on current sid.
>>
>> Thanks for pointing this out.
>>
>> I do see the correct "en" checkbox in the package which i just built.
>> However, I found another little bug
>> https://github.com/micahflee/torbrowser-launcher/issues/240 but i don't
>> think it's a blocker for a new upstream release, as fixing the apparmor
>> issue seems much more important to me than this.
> 
> I'm not sure I want to upload with this bug present, as this will break
> torbrowser for people for whom it's not broken at the moment (with a
> quite standard usecase).

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.

> I also think the tests on https://jenkins.debian.net/view/torbrowser/
> mimic "normal (yet simple) behaviour" and as such, shouldn't be broken.
> 
> Finally fixing apparmor is really nice, but not like this I'd say. Those
> who are using apparmor have been able to workaround the bugs for the
> last half year, I'm sure they can continue to do that for some little
> more time.
> 
> Knowingly breaking new stuff is bad.

I don't think there is knowingly breaking stuff and the new version does
improve many other things which do outweigh this *new* feature.

Furthermore, this can be simply workarounded by exporting $LANG when
running @torbrowser-launcher --settings at . Sorry, but I find this much
easier than workarounding the current AppArmor bugs. (Which actually
does involve manually downloading 3 different aa-profiles, and
installing them to the correct location manually - *and* that's possible
only since intrigeri actually fixed them upstream some *weeks* and not
half a year ago.).

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

Cheers,
u.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-privacy-maintainers/attachments/20160711/4971422d/attachment.sig>


More information about the Pkg-privacy-maintainers mailing list