[Pkg-mozext-maintainers] BoF or Sprint while DebCamp or DebConf?

Carsten Schoenert c.schoenert at t-online.de
Thu Jul 26 02:45:59 BST 2018


Am 26.07.18 um 01:28 schrieb Dmitry Smirnov:
...>> * Where should be the packaged AddOns be collected on Salsa?
>> We have 'pkg-mozext-team' and also 'webext-team' [2]. The latter has now
>> most of the git trees.
> 
> Separation looks clear (enough) to me: "webext-team" is a place for new 
> WebExtensions while the other "pkg-mozext-team" is for legacy XUL-only 
> extensions.

The mainly XUL based AddOns are a matter of time they fade away, I could
happily live with a *one* team for the Maintainer field and one central
place on Salsa preferable. Both teams aren't that big and WebExtension
is the clear future. But I'd like to talk about together so we get a
consent for all involved people.

>> * How to package Mozilla AddOns for Debian in recent days?
>> Out there are mozilla-devscripts but also "manual" packaging for
>> packages named 'webext-$foo'. Could this be consolidated aka make the
>> packaging easier?
> 
> I think I have some answers as I happened to be working on some extensions in 
> the last few days and I think I've figured out how to package them.
> I'll try to write it on wiki somewhere but to cut the long story short, 
> manual method is easier as "dh_webext" is immature and offers little to be 
> useful.
> 
> Basically web extensions can be installed into "/usr/share/webext" and 
> enabled in chromium with "/etc/chromium.d" file as found in Stylus package:
> 
>   https://salsa.debian.org/webext-team/stylus
> 
> This is not ideal and I'd much rather prefer to symlink into chromium's 
> extensions folder but it looks like no such method is available.
> 
> Activating web-extension in Firefox is much more difficult: one _can_ symlink 
> extension directory into "/usr/share/mozilla/extensions/{ec8030f7-
> c20a-464f-9b0e-13a3a9e97384}" with a name as per "applications.gecko.id" 
> value from "manifest.json" but Firefox caches extensions under XDG_CACHE_HOME 
> and not checking for updates so any extension package upgrade is ignored.
> This can be fixed by symlinking zipped extension bundle which appears to be 
> supported method of sideloading but even then it might be necessary to reload 
> extensions page...

We need to collect all these information on the Debian wiki. Even as I
package Thunderbird that all isn't that clear, it was along journey for
me (which was needing a lot of time!) to get Lightning working on TB >= 58.
To me it makes no sense if every body knows "something" and the needed
information to do a packaging right is searched again and again. This is
frustrating and energy consuming. We can make this better.

>> * What about the wiki site for Mozilla extensions? [4]
> 
> Perhaps we need a new page focusing on WebExtensions.

Yes, like always, $someone needs to do it. I guess for a single person
it's to much work, if we can cut this into peaces it easier to get
things done.

>> How can the wiki site made more attractive and a central point for
>> packaging related questions?
> 
> Up-to-date information is crucial... But how to keep it up-to-date that is 
> the question...

Yeah, that's one of the reasons I raced all these questions.

Meanwhile I started some small notes within Gobby, please extend by
things you liked to have talked about or solved.

https://gobby.debian.org/export/debconf18/bof/pkg-webext

I also added a AddHoc session request to Wafer.

https://debconf18.debconf.org/talks/152-debian-pkg-webextension-team-bof/

-- 
Regards
Carsten Schoenert



More information about the Pkg-mozext-maintainers mailing list