| Age | Commit message (Collapse) | Author |
|---|
|
To improve readability, related functionality should be kept together,
while different section are separated by multiple newlines.
|
|
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.
|
|
In the absence of a dedicated web page, the description page for the
Add-On follows a similar naming scheme as the download link and can
be automatically composed, too. Conditionally doing so when no explicit
$url is set, eases transition should the extension be forked, switch
maintainers or otherwise change in a way that the description page on
addons.mozilla.org is more accurate than the current page.
|
|
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.
|
|
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.
|
|
Compatibility to the current Firefox version 45 was introduced.
|
|
This reverts "add mksrcinfo header".
The .SRCINFO is now generated by "makepkg --printsrcinfo" which does no
longer include any header since commit f63854f [1], released with pacman
version 5.0.1.
[1]: https://projects.archlinux.org/pacman.git/commit/?id=f63854fa96f658ca5bdf2c21a1cd33cf4e3fbdbd
|
|
|
|
|
|
The new version of mksrcinfo released with the recent update to
pkgbuild-introspection adds a header to all .SRCINFO files.
|
|
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.
|
|
|