| Age | Commit message (Collapse) | Author |
|---|
|
Besides a small fixup, the compatible version range was adjusted.
|
|
The appearance of a few elements was fixed.
|
|
The appearance of icons added by extensions were fixed.
|
|
Some fixes concern the current Firefox beta 51.
|
|
Some fixed concern mainly HI-DPI.
|
|
Some icons were fixed.
|
|
Some new buttons were fixed.
|
|
To improve readability, related functionality should be kept together,
while different section are separated by multiple newlines.
|
|
Some visual glitches were fixed.
|
|
This adapts for changes in Firefox and brings version 50 compatibility.
|
|
Despite the information given out via the API, Firefox actually permits
installation of some extensions reported incompatible, which then work
fine. This is because Firefox' internal mechanism determines that these
extensions should be compatible by itself and subsequently refrains from
even querying the API to begin with.
The version range in the depends array should reflect this. The new
condition set models how Firefox and Thunderbird decide compatibility to
smoothen future updates.
|
|
This adapts for changes in Firefox.
|
|
Some bugs, not ready for the last release, were fixed.
|
|
This ships out compatibility to Firefox 48 and 49 beta and fixes some
built in pages.
|
|
Some sidebar and panel issues were fixed.
|
|
This ships out compatibility to Firefox beta 48 and fixes some icons.
|
|
The description page for the Add-On follows a similar naming scheme as
the download link, so it can be automatically composed, too.
Only doing so when the $url is not yet set takes into account that the
Add-Ons may get a dedicated web page in the future. The conditional
would not be necessary as long as the $url would then be overwritten
afterwards. Nonetheless, it allows ordering the PKGBUILD in an usual
fashion: Automatic composition of values is semantically more suited to
be placed amongst the part of the PKGBUILD where prepare, build, package
and related functions are collected while the simple value assignment
belongs into the earlier block defining variables.
|
|
The advertised title of some extensions differs from the name used in
the URL of their page on addons.mozilla.org. Overwriting it allows usage
of the template nonetheless.
|
|
|
|
It contains some minor fixes.
|
|
This ships out compatibility to the newest Firefox version 46.
|
|
The file is just used to set up package information and relations. It is
not needed in the package contents.
When included nonetheless, it can cause Firefox to consider the Add-On
as signed because of the additional file lacking any checksum or
verification.
Hiding it effectively excludes it from the installation.
|
|
Because of a bug in libarchive, extracting the XPI archive through
makepkg's automated process leaves the contents of the META-INF
directory scrambled. This causes Firefox to reject the activation of the
Add-On as long as "xpinstall.signatures.required" is not set to to
"false" in "about:config". Unzip preserves the content flawlessly.
The underlying bug in libarchive [1] is already fixed, but the changes
are not yet shipped out through a release. An Arch Linux bug [2] also
tracks the case. This commit shall be reverted as soon as the latter is
marked as resolved.
[1]: https://github.com/libarchive/libarchive/commit/5422a51ff294c58173338073ea400e71935350bb
[2]: https://bugs.archlinux.org/task/41071
|
|
Despite the wild card * not coping hidden files, this does not exclude
such in subdirectories. A reliable method to exclude files by a pattern
like "starting with a dot" would be rsync. But to not pull it in as an
additional dependency, copy and find are preferred.
|
|
Hidden files are normally only used to manage the source code of the
extension. They are not needed in and have no direct relation to the
compiled package and can thus be left out safely.
At this moment, there are no hidden files in this extension. So this
change happens just in anticipation to future additions and not raising
the need to increment the pkgrel.
|
|
|
|
|
|
|
|
The addons.mozilla.org API provides updated information about Add-On
compatibility more recent than the install.rdf file included in the
extension. Restricting package relations according to it yields a wider
version range, especially with newer versions.
|
|
|
|
|
|
|
|
|