Namcap merge requestshttps://gitlab.archlinux.org/pacman/namcap/-/merge_requests2024-03-13T20:49:47Zhttps://gitlab.archlinux.org/pacman/namcap/-/merge_requests/69fix(util): handle an invalid env shebang2024-03-13T20:49:47ZJelle van der Waafix(util): handle an invalid env shebangexploitdb in the Arch Linux repositories has a bare `#!/usr/bin/env`
shebang which crashes Namcap.
Fixes https://gitlab.archlinux.org/pacman/namcap/-/issues/80exploitdb in the Arch Linux repositories has a bare `#!/usr/bin/env`
shebang which crashes Namcap.
Fixes https://gitlab.archlinux.org/pacman/namcap/-/issues/80https://gitlab.archlinux.org/pacman/namcap/-/merge_requests/63licensepkg: support `+` in license expressions2024-03-13T21:52:02ZPekka Ristolalicensepkg: support `+` in license expressionsFixes https://gitlab.archlinux.org/pacman/namcap/-/issues/71
With this change, `+` SPDX operator is allowed for all license identifiers
except those that end with `-only` or `-or-later`. Syntactically the SPDX
specification allows using...Fixes https://gitlab.archlinux.org/pacman/namcap/-/issues/71
With this change, `+` SPDX operator is allowed for all license identifiers
except those that end with `-only` or `-or-later`. Syntactically the SPDX
specification allows using the operator for any license identifier, but
semantically it doesn't make sense to use it for licenses like `GPL-2.0-only+`.
Such uses will be reported as unknown license identifiers.
While there are other licenses that could probably be disallowed like `MIT+`,
it's hard to draw the line on which identifers should support the `+` operator.
The SPDX specification doesn't provide that information, see
https://github.com/spdx/spdx-spec/issues/689
The functionality is implemented by removing trailing `+` from the license
symbols, since the python `license_expression` module doesn't support parsing it
directly. See https://github.com/nexB/license-expression/issues/9https://gitlab.archlinux.org/pacman/namcap/-/merge_requests/59Namcap: enable ruff's isort rule2024-02-10T11:07:21ZJelle van der WaaNamcap: enable ruff's isort ruleStart with enabling ruff linting rules, the isort rule is an autofix.Start with enabling ruff linting rules, the isort rule is an autofix.https://gitlab.archlinux.org/pacman/namcap/-/merge_requests/41Add basic support for typechecking2024-03-17T19:22:16ZClaudia PellegrinoAdd basic support for typecheckingStatic typechecking can help make IDEs and editors smarter, uncover hidden bugs, and may help people read and understand the code better.
This merge request:
1. enables static typechecking via [`mypy`](https://www.mypy-lang.org/) (see ...Static typechecking can help make IDEs and editors smarter, uncover hidden bugs, and may help people read and understand the code better.
This merge request:
1. enables static typechecking via [`mypy`](https://www.mypy-lang.org/) (see also [extra/mypy](https://archlinux.org/packages/extra/any/mypy/));
2. fixes a couple of typing issues, which would interfere with type checking;
3. adds a CI step that will fail when a commit introduces typing errors.
The basic MyPy configuration this MR introduces is pretty lenient: it deliberately leaves two helpful typing rules switched off (`disallow_untyped_calls` and `disallow_untyped_defs`). That allows any piece of code to opt into typing annotations (instead of making them a hard requirement). Should the project team decide to go the stricter route, I’ll be there and willing to do follow-up MRs to add type declarations to the rest of the code.
This MR requires Python 3.10 or newer (compared to current `master`, which requires 3.9 or newer).
Shouldn’t be an issue though, given that namcap runs on system Python anyway, which is at 3.11.https://gitlab.archlinux.org/pacman/namcap/-/merge_requests/24improvements for metapackages2023-02-23T12:13:48ZChristian Heuselimprovements for metapackagesI had a look at [`base-devel`'s `PKGBUILD`](https://github.com/archlinux/svntogit-packages/blob/packages/base-devel/trunk/PKGBUILD) today and wondered why it has a `license=()` array even if there is no content to license.
Someone on I...I had a look at [`base-devel`'s `PKGBUILD`](https://github.com/archlinux/svntogit-packages/blob/packages/base-devel/trunk/PKGBUILD) today and wondered why it has a `license=()` array even if there is no content to license.
Someone on IRC said that it could be because the author wanted to suppress namcap warnings.
So I tried to fix that and created a check whether a given package is a metapackage and exclude missing licenses and unneeded deps from there.
I think there could be two main ToDos:
- [ ] testing to avoid regressions
- [ ] Coding style (will do in the end)
Looking forward to your feedback! :tada:https://gitlab.archlinux.org/pacman/namcap/-/merge_requests/4Add support for i686, aarch64 and riscv64 to SharedLibsRule2022-02-22T20:44:18ZHaochen TongAdd support for i686, aarch64 and riscv64 to SharedLibsRuleAdd support for some non-x86 architectures.
It tries to guess `e_machine` and `EI_CLASS` based on the current machine type and `ldconfig -p` output, and matches shared libraries based on "arch identifiers" (which are basically tuples of...Add support for some non-x86 architectures.
It tries to guess `e_machine` and `EI_CLASS` based on the current machine type and `ldconfig -p` output, and matches shared libraries based on "arch identifiers" (which are basically tuples of `e_machine` and `EI_CLASS`).