[Pkg-mozext-maintainers] Bug#591579: ITP: https-everywhere -- browser extension to enforce SSL browsing according to rules

[Axel Beckert]

Hi Rogério,

Rogério Brito wrote:
> I really hope that this message gets through. Please let me know if it
> works.

Received it. :-)

> >  * I see that you are using bzip2 compression for the debs. Have you
> >    measured how much gain resulted in doing so?
> 
> Yes, I did: with bzip2, we get, for https-everywhere, a package that is 10%
> smaller than with gzip, which, for compression algorithms, is quite a good
> amount.

Most text data I have seen compresses clearly better with bzip2
anyway, so if I have the choice, I use bzip2 (or xz) anyway, too.

> I would have used xz instead of bzip2, though, as xz-utils is "Priority:
> required", but people would find that to be too aggressive. :-)

IIRC was there also something that we just can use it in unstable only
when dpkg in Stable supports it already. But as xz support is in dpkg
in Squeeze (see http://bugs.debian.org/542160), I'd say that would be
ok, too.

Nevertheless, to get that thing running, I'd stay with bzip2 at least
for this upload.

> Regarding one point that Axel mentioned about using pristine-tar,
> unfortunately, the tor project only seems to release xpi files, which are
> actually zip files, but pristine-tar only supports gzip or bzip2 compressed
> tar files.

That's no problem. xpi-repack works fine. Just check in the tar ball
_you_ generated that way so that we all can use exactly the same tar
ball and don't have hash sums mismatch due to different time stamps.

> I agree that for traceability (if that's even a word) would be better if we
> could have bit-identical tarballs, but that's not an option, unless we:
> 
> * ask upstream to produce tar.{gz,bz2} tarballs
> * grab our tarballs from https://gitweb.torproject.org/https-everywhere.git,
>   but, AFAIK, we loose the automation of checks with uscan and with uupdate

No, the third option applies:

* generated the tar balls with xpi-repack ourselves from the xpi file.

:-)

The main issue is not to trace upstream's tar ball in pristine-tar.
The issue is to have one tar ball in there, so all of us can use
bit-wise identical tar balls.

Hope that explanation was understandable. It took me a while, too, to
realize where the value of pristine-tar lies. And this case (not
having identical tar balls due to the necessarity of repacking) is
definitely one of the cases where I clearly see its value. :-)

> > No other comments. Except for the URLs of the repositories, I would have
> > uploaded it right now! :)

.oO( Looks as if Jérémy and me have to fight about who will sponsor
     it. ;-)

> Great. I hope that what I produced is not to be ashamed of. :-) Please, let
> me know if you would like to have the package as a .dsc combo.

I'd say go ahead and generate a .dsc. :-)

Thanks for your work!

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe at debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5