Re: [Pkg-mozext-maintainers] BoF or Sprint while DebCamp or DebConf?
Dmitry Smirnov: > On Thursday, 26 July 2018 3:38:00 AM AEST Ximin Luo wrote: >> Why not improve it [dh_webext], instead of requiring extra manual packaging > steps to all packages? > > I did land few minor commits to improve "dh_webext" but frankly I'm not sure > what it is intended to do... Perhaps someone else have a strategic vision > regarding what dh_webext should become. > > Due to other priorities and commitments I have no time to work on dh_webext; > my Python skills are mediocre and my first approach to symlink uncompressed > addon was quite easy so I thought that dh_webext just adds complexity to a > straightforward task... Though that was before I've discovered that we need > to compress addons for Firefox or somehow drop its extension caches... I > suppose dh_webext could take care of that but I can't/won't be the one to > work on that... > The "strategic vision" is the same as any other dh addon, to reduce duplication in d/rules across packages within the same ecosystem (here, WebExtensions). I know the code is crap currently, but it doesn't mean we should just drop it and work on another solution that will be worse in the long run. I don't care what language the tool is written in, I picked python2 because that was what other mozilla-devscripts stuff was written in. I think for the long-term sustainability of the team it's better for all of us to work together to improve this one tool, rather than implement similar-but-different logic many times in many different packages. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git ___ Pkg-mozext-maintainers mailing list Pkg-mozext-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mozext-maintainers
Re: [Pkg-mozext-maintainers] BoF or Sprint while DebCamp or DebConf?
On Thursday, 26 July 2018 11:45:59 AM AEST Carsten Schoenert wrote: > 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. I know... It took me days to learn how it works and I've only figured it out yesterday, _hours_ before I've shared my findings on this mail list. Now I need to find time to write a summary for wiki - not sure when but I hope that someone might start a new wiki page for webextensions packaging before I get to it... -- Best wishes, Dmitry Smirnov. --- There is not enough love and goodness in the world to permit giving any of it away to imaginary beings. -- Friedrich Nietzsche signature.asc Description: This is a digitally signed message part. ___ Pkg-mozext-maintainers mailing list Pkg-mozext-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mozext-maintainers
Re: [Pkg-mozext-maintainers] BoF or Sprint while DebCamp or DebConf?
Hi, Le 26/07/2018 à 09:45, Carsten Schoenert a écrit : > 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/ Thank you Carsten for your draft, as well as to Ximin and Dmitry for having already started to work on the webext format. Three of us are already at DebCamp, but I’m not sure Dmitry is coming, can you confirm or not this information? Dmitry, While in person conversation may help – in case you are not in Taiwan – maybe an IRC/live meeting could fit you, especially if you’re in a TZ only two hours away from us. Do you have any specific request about time/date you may prefer? Side note: the Wafer session is not visible until it has been accepted. Regards David signature.asc Description: OpenPGP digital signature ___ Pkg-mozext-maintainers mailing list Pkg-mozext-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mozext-maintainers
Re: [Pkg-mozext-maintainers] tree-style-tab conversion to WebExtensions
On Thursday, 26 July 2018 1:31:00 PM AEST Ximin Luo wrote: > I'm not sure why you think it's "difficult" to create symlinks at build > time. Do you need to verify that the symlinks point to valid targets? Yes, that one of the problems. With systems like dh_link or dh_linktree, staged tree always have broken symlinks on build-time because symlinks are relative to destination while tree is staged in temporary build directory. More over, unless we depend on exact package version, installed dependency with relationship greater-than may install files into different path and that can only be spotted when package is installed. It is trivial to spot problems with symlinks in extracted addon directory - not so easy in zipped archive though. Another interesting challenge is how to zip on build time. Suppose I have all Depends packages in Build-Depends and I want to compress prepared tree with zip. Which target zip command will go to? override_dh_build is too early as resulting directory will be staged only by the time build progress to dh_install stage, right? Except that dh_link runs after dh_install. Running zip from override_dh_link (after dh_link) looks very counter- intuitive... I've found that zipping Firefox extention bundle on build time is needlessly difficult comparing to postinst. Also keep in mind that that zipped bunndle is like statically linked binary. It should be easy enough to introduce APT hook to re-compress bundle on dependency update comparing to bin-NMU process... > In general doing stuff in the postinst is bad because it's arbitrary code > execution as root. In general we'd like to move towards more declarative > packaging that doesn't involve executing Turing-complete logic. It's safer > for users, in case there are bugs, and gives less space for developers to > abuse users' end systems. You are right, I agree. Maybe there is a way to avoid that hassle entirely if we can find out how to drop Firefox addons caches so uncompressed addons can be reloaded... Chromium have no problem detecting changes in uncompressed extensions... -- Regards, Dmitry Smirnov. --- Truth — Something somehow discreditable to someone. -- H. L. Mencken, 1949 signature.asc Description: This is a digitally signed message part. ___ Pkg-mozext-maintainers mailing list Pkg-mozext-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mozext-maintainers
Re: [Pkg-mozext-maintainers] tree-style-tab conversion to WebExtensions
Dmitry Smirnov: > On Thursday, 26 July 2018 3:58:00 AM AEST Ximin Luo wrote: >> to create these zips during build time rather than postinst time? > > There are some good reasons to zip on postinst rather than on build time. > > Unpacked addons is what Chromium needs (for those addons that support both > browsers) and addons directory should be prepared for browser consumption in > DFSG-compliant manner where some files (like source-less pre-minified .js > files) should be replaced with symlinks to files provided by corresponding > packages. Luckily tree-style-tab don't seem to carry non-DFSG files that > needs replacing but that's not a usual case. > > Preparing Firefox's zip bundle on build-time requires same dependencies on > build and install time. Also making zip on build-time is more difficult as > one would have to assemble addon directory with all symlinks on build time. > Requiring same dependencies on build and install time is pretty normal, you generally need to do that if you have any sort of test suite. I'm not sure why you think it's "difficult" to create symlinks at build time. Do you need to verify that the symlinks point to valid targets? At any rate it doesn't seem like you're doing that in the postinst. In general doing stuff in the postinst is bad because it's arbitrary code execution as root. In general we'd like to move towards more declarative packaging that doesn't involve executing Turing-complete logic. It's safer for users, in case there are bugs, and gives less space for developers to abuse users' end systems. X > Compressing from postinst is easier because addon directory is already > prepared as required. > > Besides maybe there is a way to drop Firefox addons cache (how?) and avoid > zip bundle in which case there are less changes to accommodate. > -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git ___ Pkg-mozext-maintainers mailing list Pkg-mozext-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mozext-maintainers
Re: [Pkg-mozext-maintainers] BoF or Sprint while DebCamp or DebConf?
On Thursday, 26 July 2018 6:26:57 AM AEST Michael Meskes wrote:
> Unless something changed in chromium this will not work, that is it
> will not if you install more than one extension because chromium only
> executes one load-extension argument. At least that's the way it was
> when I checked.
>
> The right way imo would be something like
>
> export CHROMIUM_FLAGS="${CHROMIUM_FLAGS} --load-extension=`ls -dm
> /usr/share/chromium/extensions/*|tr -d '\n'`"
>
> It looks awkward to install this with every extension, so #890392
> suggest to do it in chromium instead. Unfortunately this has been
> ignored so far.
Thanks, Michael. I couldn't agree more that it should be implemented on
Chromium side to allow us to activate packaged extensions by symlinking them
into "/usr/share/chromium/extensions/" without polluting "/etc/chromium.d".
Chromium team, please consider implementing Michael's suggestion.
--
Cheers,
Dmitry Smirnov.
---
I am an agnostic; I do not pretend to know what many ignorant men are
sure of.
-- Clarence Darrow
---
'I refuse to prove that I exist,' says God, 'for proof denies faith, and
without faith I am nothing.'
-- Douglas Adams
signature.asc
Description: This is a digitally signed message part.
___
Pkg-mozext-maintainers mailing list
Pkg-mozext-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mozext-maintainers
Re: [Pkg-mozext-maintainers] BoF or Sprint while DebCamp or DebConf?
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
___
Pkg-mozext-maintainers mailing list
Pkg-mozext-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mozext-maintainers
[Pkg-mozext-maintainers] Processed: tagging 823479
Processing commands for cont...@bugs.debian.org: > tags 823479 + wontfix Bug #823479 [xul-ext-stylish] xul-ext-stylish: Please package upstream version 2.0.6 Added tag(s) wontfix. > thanks Stopping processing here. Please contact me if you need assistance. -- 823479: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823479 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-mozext-maintainers mailing list Pkg-mozext-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mozext-maintainers
[Pkg-mozext-maintainers] Bug#904577: ITP: stylus -- stylus manager to customize web sites with themes and skins
Package: wnpp Severity: wishlist Owner: Dmitry Smirnov X-Debbugs-CC: debian-de...@lists.debian.org, pkg-mozext-maintain...@lists.alioth.debian.org Control: tags -1 help Control: affects -1 stylish Package name: Stylus Version: 1.0.0 License: GPL-3+ URL: https://add0n.com/stylus.html Vcs-Browser: https://salsa.debian.org/webext-team/stylus Description: stylus manager to customize web sites with themes and skins User styles are themes for web sites. User styles empower your browsing experience by letting you customize web sites. Take out irrelevant content, change colors, or completely redesign the entire site. You can even use user styles as themes on the interface of Firefox, Thunderbird, and SeaMonkey themselves. . Stylus lets you easily manage user styles. Add, delete, enable, disable, and organize with a few clicks of a mouse, no code to edit, no obscure configuration to find. Stylus's companion website, userstyles.org, hosts tens of thousands of user styles made by other Stylus users that you can try. . For you technical types out there, think of it this way: Stylus and userstyles.org are to CSS as Greasemonkey and userscripts.org are to JavaScript. Stylish changed hands and has been corrupted by new upstream, see #902937, #850452. Stylish is considered dead and will be removed from Debian. Stylus is a compatible Stylish successor, forked from older version of the latter. It has been preliminary packaged as WebExtension but needs more work, mostly regarding DFSG compliance. Due to time constrains I may not be able to finish the job but the hard part is already done. Any help is welcome and appreciated... signature.asc Description: This is a digitally signed message part. ___ Pkg-mozext-maintainers mailing list Pkg-mozext-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mozext-maintainers
[Pkg-mozext-maintainers] BoF or Sprint while DebCamp or DebConf?
Hi there, I think it would make sense to use the opportunity to make a BoF about the future of Mozilla AddOns packaging within Debian. We have currently an ongoing transition of AddOns for Firefox to WebExtension and also some for some AddOns for Thunderbird. Firefox is making a "hard cut" to WebExtension since FF 58 as far I know, for Thunderbird the situation is a bit different. There are still some XUL based extensions usable as long as they have migrated from using 'install.rdf' to 'manifest.json' so they can be recognized by TB as an AddOn. I hope I can get the final Thunderbird 60.0 version from Mozilla within this week (depends on their releasing) and prepare also a final upload to experimental of this version also this week so we can all test this version within some extension in question. But I think there are more things which could be made clearer. * 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. * 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? And even for new contributors. * What about the wiki site for Mozilla extensions? [4] How can the wiki site made more attractive and a central point for packaging related questions? * What is (still) need in the near future to make Firefox 60 and Thunderbird 60 happen in Stretch and Jessie? And there are more things which will come into minds once we talk about I'm sure. So any interests? I can create a entry into the Wafer and also some Gobi notes for scheduling a sprint or BoF if there are more people think it would useful. [1] https://salsa.debian.org/pkg-mozext-team [2] https://salsa.debian.org/webext-team [3] https://tracker.debian.org/pkg/mozilla-devscripts [4] https://wiki.debian.org/Mozilla/ExtensionsPolicy -- Regards Carsten Schoenert ___ Pkg-mozext-maintainers mailing list Pkg-mozext-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mozext-maintainers
[Pkg-mozext-maintainers] tree-style-tab conversion to WebExtensions
Dear Ximin Luo, Thank you for maintaining "tree-style-tab" which is one of the packages I can not live without. I hope you don't mind that I've imported its repository to https://salsa.debian.org/webext-team/tree-style-tab and committed some changes to bring the package up to date, including conversion to WebExtensions. Please have a look when you have a moment. I would love to know what do you think. -- Cheers, Dmitry Smirnov. --- "All government, of course, is against liberty. -- H. L. Mencken signature.asc Description: This is a digitally signed message part. ___ Pkg-mozext-maintainers mailing list Pkg-mozext-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mozext-maintainers
Re: [Pkg-mozext-maintainers] tree-style-tab conversion to WebExtensions
Dmitry Smirnov: > Dear Ximin Luo, > > Thank you for maintaining "tree-style-tab" which is one of the packages I can > not live without. > > I hope you don't mind that I've imported its repository to > > https://salsa.debian.org/webext-team/tree-style-tab > > and committed some changes to bring the package up to date, including > conversion to WebExtensions. > > Please have a look when you have a moment. I would love to know what do you > think. > Hey Dmitry, did you try using "dh $@ --with webext" rather than manually symlinking and unzipping stuff in the postinst? I wrote some emails about it previously in this thread. There are lots of things left to do but it should be able to handle simple WebExtensions like tree-style-tab well. For a quick out-dated example see this: https://salsa.debian.org/webext-team/tree-style-tab/tree/pu/webext Specifically commit 995154a X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git ___ Pkg-mozext-maintainers mailing list Pkg-mozext-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mozext-maintainers
Re: [Pkg-mozext-maintainers] BoF or Sprint while DebCamp or DebConf?
On Wednesday, 25 July 2018 11:15:10 PM AEST Carsten Schoenert wrote:
> I hope I can get the final Thunderbird 60.0 version from Mozilla within
> this week (depends on their releasing) and prepare also a final upload
> to experimental of this version also this week so we can all test this
> version within some extension in question.
Nice. I hope to see it in "unstable" soon.
> * 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.
> * 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...
More examples of Firefox-only extensions can be found in "form-history-
control", "lightbeam" and "tree-style-tab" repositories.
> * What about the wiki site for Mozilla extensions? [4]
Perhaps we need a new page focusing on WebExtensions.
> 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...
--
All the best,
Dmitry Smirnov.
---
Journalism is printing what someone else does not want printed: everything
else is public relations.
-- George Orwell
signature.asc
Description: This is a digitally signed message part.
___
Pkg-mozext-maintainers mailing list
Pkg-mozext-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mozext-maintainers
Re: [Pkg-mozext-maintainers] BoF or Sprint while DebCamp or DebConf?
Dmitry Smirnov: > [..] > > 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. > Why not improve it, instead of requiring extra manual packaging steps to all packages? X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git ___ Pkg-mozext-maintainers mailing list Pkg-mozext-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mozext-maintainers
[Pkg-mozext-maintainers] Processed: tagging 881812
Processing commands for cont...@bugs.debian.org: > tags 881812 + pending Bug #881812 [xul-ext-treestyletab] xul-ext-treestyletab: new version required for Firefox 57 Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 881812: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881812 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-mozext-maintainers mailing list Pkg-mozext-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mozext-maintainers
Re: [Pkg-mozext-maintainers] Processed: tagging 881812
On Thursday, 26 July 2018 3:55:00 AM AEST Ximin Luo wrote: > Can you explain why you tagged this? Merely to indicate work in progress... > As the maintainer of this package I don't like your changes and I don't > think the package should be uploaded in this state. Please do not upload > the package. I apologize for intrusion. I would have never uploaded without your explicit permission. You are the Maintainer and it is your call to decide what to do with the package. Please use my commits only as proof of concept and feel free to revert everything. I'm out, I won't touch your package again. No need to be territorial about it. Though I'm very much surprised that you didn't like my (very careful and technically correct) changes. All of them or some particular ones? Anyway no better way to install Firefox extension has been demonstrated yet... -- All the best, Dmitry Smirnov. --- Honesty is a gift we can give to others. It is also a source of power and an engine of simplicity. Knowing that we will attempt to tell the truth, whatever the circumstances, leaves us with little to prepare for. We can simply be ourselves. -- Sam Harris signature.asc Description: This is a digitally signed message part. ___ Pkg-mozext-maintainers mailing list Pkg-mozext-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mozext-maintainers
Re: [Pkg-mozext-maintainers] tree-style-tab conversion to WebExtensions
Dmitry Smirnov: > On Thursday, 26 July 2018 3:25:00 AM AEST Ximin Luo wrote: >> Hey Dmitry, did you try using "dh $@ --with webext" rather than manually >> symlinking and unzipping stuff in the postinst? >> >> I wrote some emails about it previously in this thread. > > Yes, I did try dh_webext and I thoroughly explored prior attempts to package > web extensions for Firefox. > > I've found dh_webext to be not too helpful as it does very little but the > biggest problem is that Firefox wants _zipped_ extensions (I've explained why > in another email to the list). I'm creating zipped bundle in postinst... > > >> There are lots of things left to do but it should be able to handle simple >> WebExtensions like tree-style-tab well. For a quick out-dated example see >> this: >> >> https://salsa.debian.org/webext-team/tree-style-tab/tree/pu/webext > > I've missed that branch entirely but I already tried similar approach in my > other package (form-history-control) where I've found dh_webext to be > somewhat less effective than direct approach... > If Firefox's requirements have changed since I last used dh_webext, why not improve dh_webext to create these zips during build time rather than postinst time? The whole point of something like dh-XXX is to prevent duplication of logic that might have to change based on something outside of the package. Instead of updating d/rules of every single webext package, whenever Firefox's logic changes, we only have to update dh-webext and run a binary-only rebuild. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git ___ Pkg-mozext-maintainers mailing list Pkg-mozext-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mozext-maintainers
Re: [Pkg-mozext-maintainers] tree-style-tab conversion to WebExtensions
On Thursday, 26 July 2018 3:58:00 AM AEST Ximin Luo wrote: > If Firefox's requirements have changed since I last used dh_webext, why not > improve dh_webext to create these zips during build time rather than > postinst time? > > The whole point of something like dh-XXX is to prevent duplication of logic > that might have to change based on something outside of the package. > Instead of updating d/rules of every single webext package, whenever > Firefox's logic changes, we only have to update dh-webext and run a > binary-only rebuild. I'm not arguing with you. When dh_webext gains the ability to do that it will become quite useful. Until then installing addons can be (easily) done as I've demonstrated. We have to begin somewhere. I've shown a new/better way to handle installation of Firefox extensions. Now let's try it, validate and then hopefully someone will update dh_webext. I doubt it would be right thing to experiment on dh_webext before trying direct approach. Also as I've already said I don't have time or confidence in my Python skills to implement any logic in dh_webext. -- Best wishes, Dmitry Smirnov. --- Truth never damages a cause that is just. -- Mahatma Gandhi signature.asc Description: This is a digitally signed message part. ___ Pkg-mozext-maintainers mailing list Pkg-mozext-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mozext-maintainers
Re: [Pkg-mozext-maintainers] tree-style-tab conversion to WebExtensions
On Thursday, 26 July 2018 3:58:00 AM AEST Ximin Luo wrote: > to create these zips during build time rather than postinst time? There are some good reasons to zip on postinst rather than on build time. Unpacked addons is what Chromium needs (for those addons that support both browsers) and addons directory should be prepared for browser consumption in DFSG-compliant manner where some files (like source-less pre-minified .js files) should be replaced with symlinks to files provided by corresponding packages. Luckily tree-style-tab don't seem to carry non-DFSG files that needs replacing but that's not a usual case. Preparing Firefox's zip bundle on build-time requires same dependencies on build and install time. Also making zip on build-time is more difficult as one would have to assemble addon directory with all symlinks on build time. Compressing from postinst is easier because addon directory is already prepared as required. Besides maybe there is a way to drop Firefox addons cache (how?) and avoid zip bundle in which case there are less changes to accommodate. -- All the best, Dmitry Smirnov. --- You have to start with the truth. The truth is the only way that we can get anywhere. Because any decision-making that is based upon lies or ignorance can't lead to a good conclusion. -- Julian Assange, 2010 signature.asc Description: This is a digitally signed message part. ___ Pkg-mozext-maintainers mailing list Pkg-mozext-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mozext-maintainers
Re: [Pkg-mozext-maintainers] BoF or Sprint while DebCamp or DebConf?
> 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
Unless something changed in chromium this will not work, that is it
will not if you install more than one extension because chromium only
executes one load-extension argument. At least that's the way it was
when I checked.
The right way imo would be something like
export CHROMIUM_FLAGS="${CHROMIUM_FLAGS} --load-extension=`ls -dm
/usr/share/chromium/extensions/*|tr -d '\n'`"
It looks awkward to install this with every extension, so #890392
suggest to do it in chromium instead. Unfortunately this has been
ignored so far.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
signature.asc
Description: This is a digitally signed message part
___
Pkg-mozext-maintainers mailing list
Pkg-mozext-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mozext-maintainers
