Re: [Pkg-mozext-maintainers] Packaging WebExtensions

2017-12-28 Thread Sean Whitton
Hello,

On Thu, Dec 28 2017, Ximin Luo wrote:

> Please let me know how this fits with your plans, and if there are no
> objections I'll do an upload to Debian unstable so packages can start
> using it.

Thank you for working on this.

-- 
Sean Whitton


signature.asc
Description: PGP signature
___
Pkg-mozext-maintainers mailing list
Pkg-mozext-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mozext-maintainers

Re: [Pkg-mozext-maintainers] Packaging WebExtensions

2017-12-28 Thread Ximin Luo
Ximin Luo:
> I think it's best to have a debhelper "--with webext --buildsystem webext" to 
> standardise this, just to maintain some consistency across different 
> packages, and to avoid newbies getting confused. I'll have a go at doing this 
> in mozilla-devscripts.
> 
> Perhaps we can have a debian/install-webext file to list the $applications, 
> to install symlinks under /usr/share/$applications/extensions/.
>
Here's my attempt:
https://anonscm.debian.org/cgit/pkg-mozext/mozilla-devscripts.git/commit/?h=pu/webext

It can be used like this (only --with, no --buildsystem is needed):
https://anonscm.debian.org/cgit/pkg-mozext/tree-style-tab.git/commit/?h=pu/webext

Extensions are installed into /usr/share/webext then symlinked into relevant 
application directories.

It reads manifest.json to determine which apps are supported, as described in 
[3][4]. Chromium support is currently detected using "minimum_chrome_version", 
if your extension doesn't have this then you need to echo "chromium" > 
debian/install-webext.

It will write ${webext:Enhances} and ${webext:Provides} but not yet 
Depends/Recommends/Breaks.

More "fancy" stuff like auto-dropping configs in /etc (as what install-xpi 
does) are not yet supported.

[3] https://developer.chrome.com/extensions/manifest
[4] 
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/applications

>> * What is about extensions that support both browsers, but with different
>> builds?

This is not yet supported, one would have to write a custom debian/rules file 
for that.

But the current functionality should already be enough to support [2], keeping 
its existing layout.

>> [1]: https://developer.mozilla.org/en-US/Add-ons/Install_Manifests
>> [2]: https://github.com/snoack/mypass/tree/master/debian
> 
override_dh_webext:
dh_webext extension/

Please let me know how this fits with your plans, and if there are no 
objections I'll do an upload to Debian unstable so packages can start using it.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

___
Pkg-mozext-maintainers mailing list
Pkg-mozext-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mozext-maintainers


Re: [Pkg-mozext-maintainers] Packaging WebExtensions

2017-12-28 Thread Ximin Luo
Sebastian Noack:
> [..] the only thing that install-xpi seems to do is creating symlinks in
> /usr/share/mozilla/extensions/ based on the supported applications listed
> in install.rdf. But WebExtensions should not have an install.rdf, and
> support exactly one Gecko application (i.e. Firefox). So while xpi-pack and
> install-xpi seem useless for WebExtensions, what might still make sense are
> the ${xpi:*} substitutions in the control file, but the minimum/maximum
> Gecko version would have to be extracted from manifest.json instead of
> install.rdf.
> 

Is it really the case that a webext only supports one application? Where is 
this documented, and how is it detected by the application itself (to check 
compatibility)?

>>> However, it is much simpler, and probably not any less appropriate
>>> than relying on deprecated mechanisms, to simple use debian/install
>>> and debian/links files, in order to achieve the same result, as I did
>>> here [2].
>>>

I think it's best to have a debhelper "--with webext --buildsystem webext" to 
standardise this, just to maintain some consistency across different packages, 
and to avoid newbies getting confused. I'll have a go at doing this in 
mozilla-devscripts.

Perhaps we can have a debian/install-webext file to list the $applications, to 
install symlinks under /usr/share/$applications/extensions/.

Did you test your own [2] under Debian's chromium? I thought Chromium does not 
support unpacked system webextensions, and in fact a bug I filed a few years 
ago for this, was recently rejected:

https://bugs.chromium.org/p/chromium/issues/detail?id=420373

>>> But I wonder whether this is the way how Firefox extensions are
>>> supposed to be packaged in the future. Otherwise, mozilla-devscripts
>>> would have to be updated, in order to support WebExtensions properly,
>>> unless I miss something.
>>>
>>> Also I wonder whether it still makes sense to package Firefox and
>>> Chromium extensions separately, if the the only difference is either a
>>> symlink in /usr/share/mozilla/extensions/ or a script with one line in
>>> /etc/chromium.d.
>>
>> Thank you for these suggestions. It would be great if Firefox and
>> Chrome addons could just be under a webextension-* namespace.
> 
> FWIW, I'd rather go for the abbreviation "webext-" as this consistent,
> both, with the old "xul-ext-" prefix, and with the "webext" W3C group which
> standardizes these. But this is just bikeshedding, I suppose.
> 

I also support unifying this under a webext- prefix.

> Anyway, this generally seems to be a good idea, though there are some more
> things to think about:
> 
> * Where should cross-browser extensions be installed in the filesystem?
> * What is about extensions that will remain only compatible with either
> Chromium or Firefox?
> * What is about extensions that support both browsers, but with different
> builds?
> 

I took a look at your [2] and the paths seem OK IMO. I'll submit a proposal for 
updating mozilla-devscripts soon. (Eventually we could rename this to 
webext-devscripts.)

X

Sebastian Noack:
> [1]: https://developer.mozilla.org/en-US/Add-ons/Install_Manifests
> [2]: https://github.com/snoack/mypass/tree/master/debian

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

___
Pkg-mozext-maintainers mailing list
Pkg-mozext-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mozext-maintainers


Re: [Pkg-mozext-maintainers] Packaging WebExtensions compatible with multiple browsers

2017-08-21 Thread Sean Whitton
Hello Yao Wei,

Thank you for working on this.

On Mon, Aug 21 2017, Yao Wei wrote:

> 1. Should we use different prefix for the WebExtensions packages that
> support different browsers?
>
> I think webext- prefix can be good for this kind of packages.
>
> 2. Should we split the package for different browsers?
>
> There's current efforts packaging ublock-origin for both chromium and
> xul-ext.  However shifting to WebExtensions implies that the codebase
> will be the same.  To save disk space and lower the security risk not
> to split the main package could be good.  Some of the
> browser-dependent files can be splitted to their dedicated packages.

David Prévot and I looked into this during DebCamp.  You can find our
attempt on the webext branch of ublock-origin's alioth repository.

We thought it would be better just to have all packages use the prefix
webext-, installing to something like /usr/share/webext/foo, and then
create a symlink into /usr/share/firefox if the extension works in
Firefox, and into /usr/share/chromium if the extension works with
Chromium.

Do you think this would work?

-- 
Sean Whitton


signature.asc
Description: PGP signature
___
Pkg-mozext-maintainers mailing list
Pkg-mozext-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mozext-maintainers

Re: [Pkg-mozext-maintainers] Packaging WebExtensions compatible with multiple browsers

2017-08-21 Thread Ximin Luo
Yao Wei:
> Hi,
> 
> There are some problems for us to package Debian packages for
> WebExtensions that can support Firefox and Chromium using the same
> codebase.  I do come up with my idea, but I still need a conclusion to
> prepare a package:
> 
> 1. Should we use different prefix for the WebExtensions packages that
> support different browsers?
> 
> I think webext- prefix can be good for this kind of packages.
> 
> 2. Should we split the package for different browsers?
> 
> There's current efforts packaging ublock-origin for both chromium and
> xul-ext.  However shifting to WebExtensions implies that the codebase
> will be the same.  To save disk space and lower the security risk not to
> split the main package could be good.  Some of the browser-dependent
> files can be splitted to their dedicated packages.
> 
> Inputs are welcome!
> 

Hi Yao Wei, thanks for taking this forward! I have not been following the 
discussions very closely but this all seems sensible to me.

Best,
Ximin

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

___
Pkg-mozext-maintainers mailing list
Pkg-mozext-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mozext-maintainers


[Pkg-mozext-maintainers] Packaging WebExtensions compatible with multiple browsers

2017-08-21 Thread Yao Wei
Hi,

There are some problems for us to package Debian packages for
WebExtensions that can support Firefox and Chromium using the same
codebase.  I do come up with my idea, but I still need a conclusion to
prepare a package:

1. Should we use different prefix for the WebExtensions packages that
support different browsers?

I think webext- prefix can be good for this kind of packages.

2. Should we split the package for different browsers?

There's current efforts packaging ublock-origin for both chromium and
xul-ext.  However shifting to WebExtensions implies that the codebase
will be the same.  To save disk space and lower the security risk not to
split the main package could be good.  Some of the browser-dependent
files can be splitted to their dedicated packages.

Inputs are welcome!

Best regards,
Yao Wei


signature.asc
Description: PGP signature
___
Pkg-mozext-maintainers mailing list
Pkg-mozext-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mozext-maintainers

Re: [Pkg-mozext-maintainers] Packaging WebExtensions

2017-05-12 Thread Sebastian Noack
Hi Sean

On Fri, May 12, 2017 at 10:33 PM, Sean Whitton 
wrote:
>
> Dear Sebastian,
>
> On Thu, May 11, 2017 at 02:29:35PM +0200, Sebastian Noack wrote:
> > as you might know, Firefox is moving away from traditional Gecko
> > extensions, towards WebExtensions which are essentially the same as
> > Chrome extensions.
>
> Right. We need to update our tools, but the work hasn't started yet.[1]

As far as I understand, the only thing that xpi-pack does, besides creating
an XPI file (which essentially is just a standard ZIP file), is some magic
for unpacked JAR files within, which is no longer relevant for
WebExtensions. Moreover, creating an XPI/ZIP file, just to have it unpacked
by install-xpi seems redundant in the first place. Besides that, the only
thing that install-xpi seems to do is creating symlinks in
/usr/share/mozilla/extensions/ based on the supported applications listed
in install.rdf. But WebExtensions should not have an install.rdf, and
support exactly one Gecko application (i.e. Firefox). So while xpi-pack and
install-xpi seem useless for WebExtensions, what might still make sense are
the ${xpi:*} substitutions in the control file, but the minimum/maximum
Gecko version would have to be extracted from manifest.json instead of
install.rdf.

> > WebExtensions don't need an install.rdf manifest. In fact the
> > documentation indicates that is has been deprecated as part of legacy
> > extensions [1]. Still, I would have to create an install.rdf, just so
> > that I can use install-xpi.
> >
> > However, it is much simpler, and probably not any less appropriate
> > than relying on deprecated mechanisms, to simple use debian/install
> > and debian/links files, in order to achieve the same result, as I did
> > here [2].
> >
> > But I wonder whether this is the way how Firefox extensions are
> > supposed to be packaged in the future. Otherwise, mozilla-devscripts
> > would have to be updated, in order to support WebExtensions properly,
> > unless I miss something.
> >
> > Also I wonder whether it still makes sense to package Firefox and
> > Chromium extensions separately, if the the only difference is either a
> > symlink in /usr/share/mozilla/extensions/ or a script with one line in
> > /etc/chromium.d.
>
> Thank you for these suggestions. It would be great if Firefox and
> Chrome addons could just be under a webextension-* namespace.

FWIW, I'd rather go for the abbreviation "webext-" as this consistent,
both, with the old "xul-ext-" prefix, and with the "webext" W3C group which
standardizes these. But this is just bikeshedding, I suppose.

Anyway, this generally seems to be a good idea, though there are some more
things to think about:

* Where should cross-browser extensions be installed in the filesystem?
* What is about extensions that will remain only compatible with either
Chromium or Firefox?
* What is about extensions that support both browsers, but with different
builds?

> I think the best thing might be to have a meeting about this with any
> pkg-mozext people at Deb[Camp|Conf], to figure out a transition plan.

That sounds like a good idea and/or perhaps we could loop somebody of them
in on the discussion here.

Sebastian
___
Pkg-mozext-maintainers mailing list
Pkg-mozext-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mozext-maintainers

Re: [Pkg-mozext-maintainers] Packaging WebExtensions

2017-05-12 Thread Sean Whitton
Dear Sebastian,

On Thu, May 11, 2017 at 02:29:35PM +0200, Sebastian Noack wrote:
> as you might know, Firefox is moving away from traditional Gecko
> extensions, towards WebExtensions which are essentially the same as
> Chrome extensions.

Right.  We need to update our tools, but the work hasn't started yet.[1]

> WebExtensions don't need an install.rdf manifest. In fact the
> documentation indicates that is has been deprecated as part of legacy
> extensions [1]. Still, I would have to create an install.rdf, just so
> that I can use install-xpi.
> 
> However, it is much simpler, and probably not any less appropriate
> than relying on deprecated mechanisms, to simple use debian/install
> and debian/links files, in order to achieve the same result, as I did
> here [2].
> 
> But I wonder whether this is the way how Firefox extensions are
> supposed to be packaged in the future. Otherwise, mozilla-devscripts
> would have to be updated, in order to support WebExtensions properly,
> unless I miss something.
> 
> Also I wonder whether it still makes sense to package Firefox and
> Chromium extensions separately, if the the only difference is either a
> symlink in /usr/share/mozilla/extensions/ or a script with one line in
> /etc/chromium.d.

Thank you for these suggestions.  It would be great if Firefox and
Chrome addons could just be under a webextension-* namespace.

I think the best thing might be to have a meeting about this with any
pkg-mozext people at Deb[Camp|Conf], to figure out a transition plan.

-- 
Sean Whitton


signature.asc
Description: PGP signature
___
Pkg-mozext-maintainers mailing list
Pkg-mozext-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mozext-maintainers

[Pkg-mozext-maintainers] Packaging WebExtensions

2017-05-11 Thread Sebastian Noack
Hi everyone,

as you might know, Firefox is moving away from traditional Gecko
extensions, towards WebExtensions which are essentially the same as
Chrome extensions.

WebExtensions don't need an install.rdf manifest. In fact the
documentation indicates that is has been deprecated as part of legacy
extensions [1]. Still, I would have to create an install.rdf, just so
that I can use install-xpi.

However, it is much simpler, and probably not any less appropriate
than relying on deprecated mechanisms, to simple use debian/install
and debian/links files, in order to achieve the same result, as I did
here [2].

But I wonder whether this is the way how Firefox extensions are
supposed to be packaged in the future. Otherwise, mozilla-devscripts
would have to be updated, in order to support WebExtensions properly,
unless I miss something.

Also I wonder whether it still makes sense to package Firefox and
Chromium extensions separately, if the the only difference is either a
symlink in /usr/share/mozilla/extensions/ or a script with one line in
/etc/chromium.d.

[1]: https://developer.mozilla.org/en-US/Add-ons/Install_Manifests
[2]: https://github.com/snoack/mypass/tree/master/debian

___
Pkg-mozext-maintainers mailing list
Pkg-mozext-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mozext-maintainers