| Age | Commit message (Collapse) | Author |
|---|
|
The recently released gnome-shell version 3.26 is now supported.
|
|
Apart from new translations, this brings gnome-shell 3.24 compatibility.
|
|
Some extensions authors introduce build steps required before
installing. Their execution normally produces a completed variant of the
extension code in a subdirectory, difficult to tell apart from the
original source. The find condition introduced herein proves the process
against such cases to come. It always chooses the files created last,
ensuring that a build which occurred after mere unpacking will always
take precedence.
|
|
|
|
The git-makepkg-templates switched to dynamic adaptation to integrity
checks chosen in makepkg.conf. [1] The default checksums chosen reflect
recommendations from the Arch Linux Wiki and manual pages. [2]
[1]: https://github.com/dffischer/git-makepkg-templates/commit/e84d04b
[2]: https://aur.archlinux.org/cgit/aur.git/commit/?h=git-makepkg-templates-git&id=c2ccaaa
|
|
According to the Arch Packaging Standards [1], lines in a PKGBUILD
should be no longer than 100 characters and package descriptions should
cap at 80.
This does not change the contents of the built package, so the pkgver
stays unchanged.
[1]: https://wiki.archlinux.org/index.php/Arch_packaging_standards
|
|
As an extension consists of both the metadata description and a
JavaScript entry point always named extension.js, searching for both
hardens the locating process against changes to the directory structure.
This does not change the contents of the built package, so the pkgver
stays unchanged.
|
|
Comparing the minor version to a string of minor and major will never
succeed.
Originally, a restriction on the current shell version was omitted for
historical reasons - most packages did so when dependencies were defined
manually. This now turns into a concious decision to
- permit the usage of the extension in instable gnome-shell versions -
the ones with odd minor version numbers - where incompatibilities are
introduced gradually.
- ease the transition from one stable gnome-shell version - the ones
with even minor version numbers - to the next. In an ideal world, all
extensions should have been updates before the update hits the
repositories. But as Arch is quite more on the edge than developers of
some of the extensions, this is not the case more often than not.
|
|
Apart from new translations, this brings gnome-shell 3.20 compatibility.
|
|
Unbelievably, also traditional tools like grep are regularly updated
still today. Version 2.24 forbid the combination of some features with
the -z option. This was exactly what was exploited here to make grep
ignore newlines so they would not interrupt JSON dissection. More
information about the change can be found at the bottom of the
respective release notes. [1]
Fixing it costs an invocation of tr to remove the bothersome newlines.
Because the files are read within "find -exec" where input redirection
is not readily possible, cat has to be invoked to start the pipeline.
The grep script got only a tiny bit simpler by adhering to the new
restriction and leaving newlines to tr.
Thanks to AUR users jmauss, Asher256 and vinadoros for pointing to the
critical line.
[1]: http://savannah.gnu.org/forum/forum.php?forum_id=8477
|
|
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
|
|
Other packages usually depend on the package without any -git suffix.
This makes it possible to als satisfy these dependency requirements when
they target specific versions or version ranges.
|
|
The new version of mksrcinfo released with the recent update to
pkgbuild-introspection adds a header to all .SRCINFO files.
|
|
The package is not maintained by its original author since a few
gnome-shell versions. GitHub user p91paul adapted it for the current
version, so pulling from his repository ensures further compatibility.
|
|
|
|
|
|
|