Pacman Contrib merge requestshttps://gitlab.archlinux.org/pacman/pacman-contrib/-/merge_requests2024-03-21T18:11:44Zhttps://gitlab.archlinux.org/pacman/pacman-contrib/-/merge_requests/47Vim syntax: Allow `x86_64_v3` in $arch2024-03-21T18:11:44ZFrederik “Freso” S. OlesenVim syntax: Allow `x86_64_v3` in $arch[Arch Linux RFC 2](https://rfc.archlinux.page/0002-march/) added "x86_64_v3" as a (future) official Arch Linux build architecture, but vim is currently not happy when `PKGBUILD`s have "x86_64_v3" in their `$arch` array.
This adds "x86_6...[Arch Linux RFC 2](https://rfc.archlinux.page/0002-march/) added "x86_64_v3" as a (future) official Arch Linux build architecture, but vim is currently not happy when `PKGBUILD`s have "x86_64_v3" in their `$arch` array.
This adds "x86_64_v3" to the list of allowed `pbArch` keywords as well as the various `{source,depends,…}_$arch` to the list of `srcInfoField`s for `.SRCINFO`.https://gitlab.archlinux.org/pacman/pacman-contrib/-/merge_requests/45GL-125: pacdiff: Be compatible with plocate2024-03-10T19:48:10ZTilman BlumenbachGL-125: pacdiff: Be compatible with plocateAs described in GL-125, `plocate` treats multiple patterns as a conjunction, while `mlocate` treats them as a disjunction.
Since `plocate` doesn't have an option to change its behavior to match `mlocate`, we now simply call `locate` onc...As described in GL-125, `plocate` treats multiple patterns as a conjunction, while `mlocate` treats them as a disjunction.
Since `plocate` doesn't have an option to change its behavior to match `mlocate`, we now simply call `locate` once for each pattern, which works for both `mlocate` and `plocate`.
Closes GL-125.https://gitlab.archlinux.org/pacman/pacman-contrib/-/merge_requests/46Adapt PKGBUILD.vim to the recent switch to SPDX identifiers for the license a...2024-03-10T19:21:54ZRobin Candauantiz@archlinux.orgAdapt PKGBUILD.vim to the recent switch to SPDX identifiers for the license arrayhttps://lists.archlinux.org/hyperkitty/list/arch-dev-public@lists.archlinux.org/thread/NFSB7734U2VVDULPRY65ECXDE3XGNZXM/https://lists.archlinux.org/hyperkitty/list/arch-dev-public@lists.archlinux.org/thread/NFSB7734U2VVDULPRY65ECXDE3XGNZXM/https://gitlab.archlinux.org/pacman/pacman-contrib/-/merge_requests/44Fix: Remove color code from the "updates" array when using the --download option2024-01-29T21:21:53ZRobin Candauantiz@archlinux.orgFix: Remove color code from the "updates" array when using the --download optionWhen using the "Color" option in `pacman.conf`, the "updates" array is now generated with color codes (as introduced in [53c94a04](https://gitlab.archlinux.org/pacman/pacman-contrib/-/commit/53c94a04ba47e3e4d42479b34156c8931dc53a61)).
...When using the "Color" option in `pacman.conf`, the "updates" array is now generated with color codes (as introduced in [53c94a04](https://gitlab.archlinux.org/pacman/pacman-contrib/-/commit/53c94a04ba47e3e4d42479b34156c8931dc53a61)).
This change broke the `--download` option as the heading color code before the name of the packages in the array prevents pacman from finding them.
This commit aims to fix that by removing the heading color code in front of the packages name in the array before trying to download them via pacman, when the "Color" option is set in `pacman.conf`.
Fixes https://gitlab.archlinux.org/pacman/pacman-contrib/-/issues/124https://gitlab.archlinux.org/pacman/pacman-contrib/-/merge_requests/43pacscripts: Fix glob2024-01-27T21:37:32ZGeshpacscripts: Fix globCloses: #123Closes: #123https://gitlab.archlinux.org/pacman/pacman-contrib/-/merge_requests/42Checkupdates: Preserve pacman colors when printing the list of pending updates2024-01-19T02:05:46ZRobin Candauantiz@archlinux.orgCheckupdates: Preserve pacman colors when printing the list of pending updatesThe colors for the listing of pending updates are inherited from the "Color" option in `/etc/pacman.conf` (since it uses `pacman -Qu` to generate the list).
However, since the list is put into an array via a mapfile the colors are not p...The colors for the listing of pending updates are inherited from the "Color" option in `/etc/pacman.conf` (since it uses `pacman -Qu` to generate the list).
However, since the list is put into an array via a mapfile the colors are not preserved. Indeed, the "Color" option in `/etc/pacman.conf` correspond to the `--color auto` pacman flag which prints colors only when outputting onto in a TTY (which a mapfile/array is not :sweat_smile:) and the lack of coloring seems confusing for users (see https://gitlab.archlinux.org/pacman/pacman-contrib/-/issues/117 & https://gitlab.archlinux.org/pacman/pacman-contrib/-/issues/1).
This commit makes `checkupdates` forcing the use of `--color always` during the `pacman -Qu` command in the mapfile to generate the list of pending updates with colors for users that have the "Color" option enabled in the `pacman.conf`.https://gitlab.archlinux.org/pacman/pacman-contrib/-/merge_requests/40Add the -c/--change option to checkupdates which only watch for new available...2023-12-27T01:31:06ZRobin Candauantiz@archlinux.orgAdd the -c/--change option to checkupdates which only watch for new available updates since the last runThis MR adds support for a new `-c/--change` option that makes checkupdates only check for new available updates compared to the last execution ran **with that option**. In other words, the list of available updates is only printed if it...This MR adds support for a new `-c/--change` option that makes checkupdates only check for new available updates compared to the last execution ran **with that option**. In other words, the list of available updates is only printed if it differs from the last time `checkupdates` was run using `--change`.
This is useful to run `checkupdates` in a cronjob or systemd timer for instance, so you're not getting constantly notified of the same exact available updates over and over until you actually apply them.
This feature has been requested in https://gitlab.archlinux.org/pacman/pacman-contrib/-/issues/29 and its implementation was inspired by [this script](https://github.com/cdown/checkupdates-cron/blob/master/checkupdates-cron).
---
Closes https://gitlab.archlinux.org/pacman/pacman-contrib/-/issues/29https://gitlab.archlinux.org/pacman/pacman-contrib/-/merge_requests/39Rename testing repo to core-testing in paclist's examples2023-11-26T04:53:31ZRafael FontenelleRename testing repo to core-testing in paclist's exampleshttps://gitlab.archlinux.org/pacman/pacman-contrib/-/merge_requests/38Revert 'printf' lint for the updpkgsums script2023-09-09T20:10:52ZRobin Candauantiz@archlinux.orgRevert 'printf' lint for the updpkgsums scriptAs reported in #118, the lint change made in commit [17f27b53](https://gitlab.archlinux.org/pacman/pacman-contrib/-/merge_requests/33/diffs?commit_id=17f27b53a21392fabb30c3fef1aba854e3c835a7) for the `updpkgsums` script regarding the `pr...As reported in #118, the lint change made in commit [17f27b53](https://gitlab.archlinux.org/pacman/pacman-contrib/-/merge_requests/33/diffs?commit_id=17f27b53a21392fabb30c3fef1aba854e3c835a7) for the `updpkgsums` script regarding the `printf` statement broke the expected formatting.
Unfortunately, every of my attempts to make this line "shellcheck compliant" resulted in a broken formatting.
I assume the way "$1" is expected to be interpreted here makes it fall to the [exceptions of the related shellcheck rule](https://www.shellcheck.net/wiki/SC2059). I suggest ignoring shellcheck's feedback for that specific line.https://gitlab.archlinux.org/pacman/pacman-contrib/-/merge_requests/37rankmirrors: Add --working-only option to only output working mirrors2023-09-09T20:10:46ZVictor Westerhuisrankmirrors: Add --working-only option to only output working mirrorshttps://gitlab.archlinux.org/pacman/pacman-contrib/-/merge_requests/36Fix word splitting in rankmirrors2023-09-09T19:51:45ZVictor WesterhuisFix word splitting in rankmirrorsThe changes in 17f27b53a21392fabb30c3fef1aba854e3c835a7 prevented some intended word splitting.The changes in 17f27b53a21392fabb30c3fef1aba854e3c835a7 prevented some intended word splitting.https://gitlab.archlinux.org/pacman/pacman-contrib/-/merge_requests/33Linting: Shellcheck2023-08-20T21:57:35ZRobin Candauantiz@archlinux.orgLinting: ShellcheckContinuing the effort started in !32 by adding a pipeline job for `shellcheck` (task listed in #11).
This MR is based on the decisions that have been made in !32 (rules, separate job for `shellcheck`, using `alpine` as image, etc......Continuing the effort started in !32 by adding a pipeline job for `shellcheck` (task listed in #11).
This MR is based on the decisions that have been made in !32 (rules, separate job for `shellcheck`, using `alpine` as image, etc...).
It'll also have to be rebased against !32 once the latter is merged.
Here's a [run of the `shellcheck` job](https://gitlab.archlinux.org/antiz/pacman-contrib/-/jobs/166760).
I'd happily help to fix/treat the "issues" raised by `shellcheck` once this MR is merged! :smile_cat:
I remain available if any changes are needed :slight_smile:https://gitlab.archlinux.org/pacman/pacman-contrib/-/merge_requests/35Linting: Cppcheck2023-08-15T17:33:32ZRobin Candauantiz@archlinux.orgLinting: CppcheckThis MR adds a lint pipeline job for c files with `cppcheck` (related to #11).This MR adds a lint pipeline job for c files with `cppcheck` (related to #11).https://gitlab.archlinux.org/pacman/pacman-contrib/-/merge_requests/34Linting: markdownlint-cli22023-08-08T06:04:50ZRobin Candauantiz@archlinux.orgLinting: markdownlint-cli2Continuing the effort started in !32 and !33 by adding a pipeline job for `mdl` (task listed in #11).
This MR is based on the decisions that have been made in !32 (rules, separate job for `mdl`, using `alpine` as image, etc...).
I...Continuing the effort started in !32 and !33 by adding a pipeline job for `mdl` (task listed in #11).
This MR is based on the decisions that have been made in !32 (rules, separate job for `mdl`, using `alpine` as image, etc...).
It'll also have to be rebased against !32 and !33 once they're merged.
`mdl` isn't packaged for Alpine *(yet?)*, so it is installed via `rubygem` within the pipeline for now.
Here's a [run of the `mdl` job](https://gitlab.archlinux.org/antiz/pacman-contrib/-/jobs/166767).
I'd happily help to fix/treat the "issues" raised by `mdl` once this MR is merged! :smile_cat:
I remain available if any changes are needed :slight_smile:https://gitlab.archlinux.org/pacman/pacman-contrib/-/merge_requests/32Linting: Vint2023-07-27T01:40:53ZMatthew ArmandLinting: Vint### Aim
This MR accomplishes part of #11, namely to lint the Vim files in the package with [`vint`](https://github.com/Vimjas/vint). This is partially an MR of the `vint` pipeline step directly, but should also serve as a vetting of the ...### Aim
This MR accomplishes part of #11, namely to lint the Vim files in the package with [`vint`](https://github.com/Vimjas/vint). This is partially an MR of the `vint` pipeline step directly, but should also serve as a vetting of the standards set by the `vint` job, which will surely be mimicked by other linting jobs that come along next. Vint is a good one to start with because it:
1. Is in the official repos
2. Has very little feedback for existing code, and so is easy to fix. I'd mostly be comfortable addressing the Shellcheck feedback but there's quite a lot of it, and there's minimal CPPCheck feedback but that's not as much my forte.
### Workflow
The `workflow` section of the pipeline saves us from having to specify the same running rules to all the jobs, Gitlab docs here: https://docs.gitlab.com/ee/ci/yaml/workflow.html
### Structure
I added the job without separating them out into stages, which in practice puts the `vint` and `test` jobs together in an implicit stage called `test`, and the jobs can run in parallel. I considered making a separate stage for `lint` but since there isn't actually a run dependency between the stages, that seemed unnecessary.
Another option is in Merge Requests, running the linter only when files governed by it are touched. This has the advantage that if a linter changes styling, someone contributed unrelated code won't be hit by it; the pipeline would just fail after merge to master. I haven't implemented that here but can if that's desired.
This is what the pipeline jobs look like structurally now then:
![image](/uploads/397dff7bf5a7899709928a9ea527b1a6/image.png)
### Vint
I decided to use Arch as the base image because Vint is easily found in the official repos and it mimics the `test` job. This could have the side effect that if Vint (or another linter) changes its styling, pipelines here will start failing as soon as that update hits Arch, and updates will need to be made to appease the linter. This could be avoided by using a different base image, pinning to a specific Vint version, and updating intentionally over time, but honestly that's more likely to fall out of date so I don't prefer it.
~~I ended up using `bash`'s `globstar` `shopt` as that felt like the simplest way to make this happen in just one invocation of Vint, and therefore just have one exit code to decide the failure state of the pipeline. `find`, `xargs`, and other options had these or similar pitfalls.~~
You can see an example of a failed pipeline here: https://gitlab.archlinux.org/matthewarmand/pacman-contrib/-/pipelines/72749
with its failed vint job here: https://gitlab.archlinux.org/matthewarmand/pacman-contrib/-/jobs/165013
And a successful pipeline here, after addressing the linter's feedback: https://gitlab.archlinux.org/matthewarmand/pacman-contrib/-/pipelines/72751
with its successful vint job here: https://gitlab.archlinux.org/matthewarmand/pacman-contrib/-/jobs/165019
Explanation of linter feedback changes here: https://vimhelp.org/autocmd.txt.html#autocmd-groups
Let me know if you have any questions, or feel anything should be different.https://gitlab.archlinux.org/pacman/pacman-contrib/-/merge_requests/31Fix the .bak workflow being broken for /etc/sudoers2023-07-13T08:17:25ZMatthew ArmandFix the .bak workflow being broken for /etc/sudoers### Problem
When /etc/sudoers is the file being pacdiffed here and the -b (.bak) and -s (sudo) flags are enabled, this call temporarily means the system does not have a sudoers file, meaning the next mv call breaks.
```
==> pacnew file...### Problem
When /etc/sudoers is the file being pacdiffed here and the -b (.bak) and -s (sudo) flags are enabled, this call temporarily means the system does not have a sudoers file, meaning the next mv call breaks.
```
==> pacnew file found for /etc/sudoers
:: (V)iew, (M)erge, (S)kip, (R)emove pacnew, (O)verwrite with pacnew, (Q)uit: [v/m/s/r/o/q] v
2 files to edit
sudoedit: /etc/sudoers unchanged
:: (V)iew, (M)erge, (S)kip, (R)emove pacnew, (O)verwrite with pacnew, (Q)uit: [v/m/s/r/o/q] o
renamed '/etc/sudoers' -> '/etc/sudoers.bak'
sudo: unable to open /etc/sudoers: No such file or directory
sudo: no valid sudoers sources found, quitting
sudo: error initializing audit plugin sudoers_audit
```
### Fix
To fix this, make the backup call a copy instead of a move. This will result in the same preservation behavior, while letting the next mv call overwrite the original file with the pacfile as normal.https://gitlab.archlinux.org/pacman/pacman-contrib/-/merge_requests/30Add the missing man pages as well as the missing utils from the README2023-04-03T04:34:25ZRobin Candauantiz@archlinux.orgAdd the missing man pages as well as the missing utils from the READMEHi,
This MR adds the missing man pages for the `paclist`, `paclog-pkglist`, `pacscripts`, `pacsearch` and `rankmirrors` utils (fixes #17) as well a short description for the `pacsort` and the `pactree` utils in the README (which were mi...Hi,
This MR adds the missing man pages for the `paclist`, `paclog-pkglist`, `pacscripts`, `pacsearch` and `rankmirrors` utils (fixes #17) as well a short description for the `pacsort` and the `pactree` utils in the README (which were missing).
I can make changes if needed :)https://gitlab.archlinux.org/pacman/pacman-contrib/-/merge_requests/29Vim highlighting: recognise comments inside array groups2023-04-01T20:45:05Zéclairevoyant cVim highlighting: recognise comments inside array groupsThe motivation for this is to properly highlight comments that are inside PKGBUILD-specific arrays (e.g., `validpgpkeys`, `options`).
There are useful reasons to comment next to individual values of the array (e.g. the email/name associa...The motivation for this is to properly highlight comments that are inside PKGBUILD-specific arrays (e.g., `validpgpkeys`, `options`).
There are useful reasons to comment next to individual values of the array (e.g. the email/name associated with a PGP key, motivation for adding a specific option) and this is also more consistent with how the shell actually parses the file (`#` outside of a string is treated as a comment).
Example:
```
# testing
arr=(a b c) # comment 1
arr2=(
a # comment 2
b # comment 3
c # comment 4
)
depends=(
a # comment 5
)
makedepends=(a) # comment 6
validpgpkeys=(
a # comment 7
)
```
Before this change, comments 5 and 7 aren't highlighted as comments. This change fixes this.https://gitlab.archlinux.org/pacman/pacman-contrib/-/merge_requests/27Fix pacdiff with multiple CacheDirs2023-01-04T09:53:17ZBaltazár RadicsFix pacdiff with multiple CacheDirsCloses #21Closes #21https://gitlab.archlinux.org/pacman/pacman-contrib/-/merge_requests/26checkupdates: fix bolding of --nocolor in doc2022-11-09T20:47:52ZJoakim Petersencheckupdates: fix bolding of --nocolor in docThe `--nocolor` option in the adoc for checkupdates is missing an asterisk at the start of the line, leading to incorrect display across conversions, as can be seen [on archmanweb](https://man.archlinux.org/man/community/pacman-contrib/c...The `--nocolor` option in the adoc for checkupdates is missing an asterisk at the start of the line, leading to incorrect display across conversions, as can be seen [on archmanweb](https://man.archlinux.org/man/community/pacman-contrib/checkupdates.8.en), among other places.