atools issueshttps://gitlab.alpinelinux.org/Leo/atools/-/issues2019-07-26T01:06:50Zhttps://gitlab.alpinelinux.org/Leo/atools/-/issues/21Check for quoting of variables that are pure integers2019-07-26T01:06:50ZLeoCheck for quoting of variables that are pure integersAccording to the style, variables with literal integers should not be quoted.According to the style, variables with literal integers should not be quoted.18.2https://gitlab.alpinelinux.org/Leo/atools/-/issues/49apkbuild-lint: handle "setcap" option2023-07-02T05:26:46ZDermot Bradleyapkbuild-lint: handle "setcap" optionCurrently apkbuild-lint reports:
```
MC:[AL49]:/home/builder/package/APKBUILD:19:invalid option 'setcap'
```
when "setcap" is present in the options list.Currently apkbuild-lint reports:
```
MC:[AL49]:/home/builder/package/APKBUILD:19:invalid option 'setcap'
```
when "setcap" is present in the options list.https://gitlab.alpinelinux.org/Leo/atools/-/issues/48apkbuild-lint: Check for "options" buggy2023-07-01T20:36:09ZLuca Weissapkbuild-lint: Check for "options" buggyFor example when you have an APKBUILD with the following options
```bash
options="!strip !check !tracedeps
pmb:cross-native
pmb:kconfigcheck-anbox
pmb:kconfigcheck-nftables
"
```
Then apkbuild-lint will not detect the invalid options...For example when you have an APKBUILD with the following options
```bash
options="!strip !check !tracedeps
pmb:cross-native
pmb:kconfigcheck-anbox
pmb:kconfigcheck-nftables
"
```
Then apkbuild-lint will not detect the invalid options (if not declared with `CUSTOM_VALID_OPTIONS`) because apparently the script cannot handle options in multiple lines, or at least not like this. And the check will wrongly succeed.https://gitlab.alpinelinux.org/Leo/atools/-/issues/47AL32 (unnecessary use of brackets) thrown on necessary usage of brackets.2022-03-19T21:01:15Zboomanaiden154AL32 (unnecessary use of brackets) thrown on necessary usage of brackets.In the chromium APKBUILD, there is the following line:
```
"$pkgdir/usr/share/icons/hicolor/"$size"x"$size"/apps/chromium.png"
```
Shellcheck complains about this (SC2027) due to the size variable being unquoted in the middle. The correc...In the chromium APKBUILD, there is the following line:
```
"$pkgdir/usr/share/icons/hicolor/"$size"x"$size"/apps/chromium.png"
```
Shellcheck complains about this (SC2027) due to the size variable being unquoted in the middle. The correct way to fix this would to be to use brackets:
```
"$pkgdir/usr/share/icons/hicolor/${size}x${size}/apps/chromium.png"
```
But using brackets causes `apkbuild-lint` to say that there is an unncessary use of brackets. Probably just some minor logic changes in the regular expressions used to find this error like detecting if there are any characters after the closing bracket that would otherwise be included in the variable name.https://gitlab.alpinelinux.org/Leo/atools/-/issues/45make valid_arches conform to arch_to_hostspec()2022-01-17T13:25:21ZLeomake valid_arches conform to arch_to_hostspec()The `arch_to_hostspec()` function in `/usr/share/abuild/functions.sh` has all the variables `abuild` supports. Lets support all of them in `valid_arches`The `arch_to_hostspec()` function in `/usr/share/abuild/functions.sh` has all the variables `abuild` supports. Lets support all of them in `valid_arches`https://gitlab.alpinelinux.org/Leo/atools/-/issues/44AL29 (pkgname-used-in-source): additional pkgname like variables2021-03-20T08:32:37ZAKorezinAL29 (pkgname-used-in-source): additional pkgname like variablesShould this check also warn about other `pkgname` replacements?
I've done a quick search and found some common replacement variables.
- `_pkgname`
- `_extname`
- `_pkgreal`
- `_realname`
- `_pyname`
- `_name`Should this check also warn about other `pkgname` replacements?
I've done a quick search and found some common replacement variables.
- `_pkgname`
- `_extname`
- `_pkgreal`
- `_realname`
- `_pyname`
- `_name`https://gitlab.alpinelinux.org/Leo/atools/-/issues/42Allow CMAKE_BUILD_TYPE to be set to other than None2021-03-03T16:27:40Zomniomni+alpine@hack.orgAllow CMAKE_BUILD_TYPE to be set to other than NoneThere are occations where you do want to set this, for example `main/llvm*` and `main/clang`. How about a warning instead?There are occations where you do want to set this, for example `main/llvm*` and `main/clang`. How about a warning instead?https://gitlab.alpinelinux.org/Leo/atools/-/issues/40test2023-08-05T21:17:14ZLeotesthttps://gitlab.alpinelinux.org/Leo/atools/-/issues/38AL55 can't handle -DCMAKE_BUILD_TYPE=None on the same line as cmake2020-11-02T19:46:19ZLeoAL55 can't handle -DCMAKE_BUILD_TYPE=None on the same line as cmakeexample:
```sh
cmake -B build . -DCMAKE_BUILD_TYPE=None
```
will fail because it catches the whole lineexample:
```sh
cmake -B build . -DCMAKE_BUILD_TYPE=None
```
will fail because it catches the whole linehttps://gitlab.alpinelinux.org/Leo/atools/-/issues/37Detect the use of github (remote) patches in source2020-09-05T01:31:43ZKevin DaudtDetect the use of github (remote) patches in sourceAt least in the case of github, patches are not stable and cause checksum mismatches. Detect and warn against its use.At least in the case of github, patches are not stable and cause checksum mismatches. Detect and warn against its use.https://gitlab.alpinelinux.org/Leo/atools/-/issues/36AL29 (pkgname-used-in-source): not detecting $pkgname in multiline source2020-09-07T07:51:49ZOliver SmithAL29 (pkgname-used-in-source): not detecting $pkgname in multiline sourceapkbuild-lint did not complain with AL29 about:
```shell
source="$pkgname.initd
https://gitlab.com/postmarketOS/$pkgname/-/archive/$pkgver/$pkgname-$pkgver.tar.bz2
calamares-$_calamaresver.tar.gz::https://github.com/calamares/calamare...apkbuild-lint did not complain with AL29 about:
```shell
source="$pkgname.initd
https://gitlab.com/postmarketOS/$pkgname/-/archive/$pkgver/$pkgname-$pkgver.tar.bz2
calamares-$_calamaresver.tar.gz::https://github.com/calamares/calamares/archive/v$_calamaresver.tar.gz"
```
Besides the second line, I'm wondering if it should also complain about the first line. The intention of AL29 is, to make it easier to rename the package. So it should also complain if the initd file has $pkgname, right?https://gitlab.alpinelinux.org/Leo/atools/-/issues/35AL56 can't deal with patch files that are remote2020-05-24T10:29:20ZLeoAL56 can't deal with patch files that are remotehttps://foo.bar/changes.patch will cause AL56 to return an error message
@nmeumhttps://foo.bar/changes.patch will cause AL56 to return an error message
@nmeumhttps://gitlab.alpinelinux.org/Leo/atools/-/issues/34Proposal: Add linter check for ensuring that patches contain a description2020-05-23T14:16:58ZSören TempelProposal: Add linter check for ensuring that patches contain a descriptionIMHO each patch we add for an aport should contain a short description why this patch is necessary and where it was taken from, et cetera. In the simplest form the linter could just iterate over all `*.patch` files in `$sources` and chec...IMHO each patch we add for an aport should contain a short description why this patch is necessary and where it was taken from, et cetera. In the simplest form the linter could just iterate over all `*.patch` files in `$sources` and check whether the first line is `/^diff .*$/` if so: The patch doesn't contain a description.https://gitlab.alpinelinux.org/Leo/atools/-/issues/33Propsal: Check install_if of shell completion packages in linter2020-05-11T15:26:51ZSören TempelPropsal: Check install_if of shell completion packages in linterBash completions packages should use `bash-completion` in `install_if`.
See: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/7291Bash completions packages should use `bash-completion` in `install_if`.
See: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/7291https://gitlab.alpinelinux.org/Leo/atools/-/issues/32apkbuild-lint thinking setting LUA_CFLAGS would overwrite CFLAGS2020-04-26T20:17:02ZRasmus Thomsenoss@cogitri.devapkbuild-lint thinking setting LUA_CFLAGS would overwrite CFLAGSFrom https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/6806/diffs:
`LUA_CFLAGS="$(pkg-config --cflags lua$_i)"`
apkbuild-lint complains about that: `SP:[AL36]:APKBUILD:35:CFLAGS should not be overwritten, add $CFLAGS to it`...From https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/6806/diffs:
`LUA_CFLAGS="$(pkg-config --cflags lua$_i)"`
apkbuild-lint complains about that: `SP:[AL36]:APKBUILD:35:CFLAGS should not be overwritten, add $CFLAGS to it`.
@kdaudthttps://gitlab.alpinelinux.org/Leo/atools/-/issues/30Add a warning if prepare() is overriden but default_prepare isn't called in it2020-04-27T02:04:28ZRasmus Thomsenoss@cogitri.devAdd a warning if prepare() is overriden but default_prepare isn't called in itThis is rarely what you want, since you have to manually apply patches then.This is rarely what you want, since you have to manually apply patches then.LeoLeohttps://gitlab.alpinelinux.org/Leo/atools/-/issues/29Support TALOS security idenfifier in secfixes-check ?2020-05-24T10:46:06ZLeoSupport TALOS security idenfifier in secfixes-check ?cc: @ncopa TALOS asks for CVEs as part of its [Vendor Vulnerability Reporting and Disclosure Policy](https://tools.cisco.com/security/center/resources/vendor_vulnerability_policy.html).
Should we add support for parsing and validating T...cc: @ncopa TALOS asks for CVEs as part of its [Vendor Vulnerability Reporting and Disclosure Policy](https://tools.cisco.com/security/center/resources/vendor_vulnerability_policy.html).
Should we add support for parsing and validating TALOS security identifiers (most seem to have the TALOS-YYYY-XXXX+1) format.https://gitlab.alpinelinux.org/Leo/atools/-/issues/28linter does not recognize !net option2020-04-03T14:23:41ZAriadne Conillariadne@ariadne.spacelinter does not recognize !net option`!net` option is used with containerized builds (`abuild rootbld`) to designate APKBUILD needs networking.`!net` option is used with containerized builds (`abuild rootbld`) to designate APKBUILD needs networking.https://gitlab.alpinelinux.org/Leo/atools/-/issues/27Support for alternative CVE identifiers2020-04-03T16:14:01ZLeoSupport for alternative CVE identifiersXen has XSA-XXX and other projects might have their own internal numbering.
Should we add support for these ? it will make some checks impossible, like checking if CVE identifiers are missing their CVE- prefix
@kdaudt @clandmeterXen has XSA-XXX and other projects might have their own internal numbering.
Should we add support for these ? it will make some checks impossible, like checking if CVE identifiers are missing their CVE- prefix
@kdaudt @clandmeterhttps://gitlab.alpinelinux.org/Leo/atools/-/issues/26Consider creating pypi-variables like cpan-variables.2020-11-17T15:28:06ZLeoConsider creating pypi-variables like cpan-variables.apkbuild-pypi creates the pydepends and pymakedepend variables when creating/changing an APKBUILD. There is currently cpan-variable [AL35] that deals with apkbuild-cpan and its creation of cpandepends, cpanmakedepends and cpancheckdepends.apkbuild-pypi creates the pydepends and pymakedepend variables when creating/changing an APKBUILD. There is currently cpan-variable [AL35] that deals with apkbuild-cpan and its creation of cpandepends, cpanmakedepends and cpancheckdepends.