Pacman Contrib merge requestshttps://gitlab.archlinux.org/pacman/pacman-contrib/-/merge_requests2022-01-14T20:29:08Zhttps://gitlab.archlinux.org/pacman/pacman-contrib/-/merge_requests/4Display output in columns.2022-01-14T20:29:08ZGhost UserDisplay output in columns.There's probably a nicer way to do it but this worksThere's probably a nicer way to do it but this workshttps://gitlab.archlinux.org/pacman/pacman-contrib/-/merge_requests/21Allow parallel time check2022-09-07T07:43:43ZDmitry KuzmenkoAllow parallel time checkAdds an optional ability to run each mirror test in parallel. This
could possibly produce inaccurate results but speeds up the process for
a number of mirrors.
This uses GNU parallel for parallel checks.
Signed-off-by: Dmitry Kuzmenko <...Adds an optional ability to run each mirror test in parallel. This
could possibly produce inaccurate results but speeds up the process for
a number of mirrors.
This uses GNU parallel for parallel checks.
Signed-off-by: Dmitry Kuzmenko <dmitry.kuzmenko@dsr-corporation.com>https://gitlab.archlinux.org/pacman/pacman-contrib/-/merge_requests/28Draft: Add doas support2023-07-13T08:25:34ZMarek VospelDraft: Add doas supportThis commit adds the option to elevate privileges with doas instead of sudo if sudo is not found.
## TODO
I have changed paccache, checkupdates and pacscripts, pacdiff still needs to be updatedThis commit adds the option to elevate privileges with doas instead of sudo if sudo is not found.
## TODO
I have changed paccache, checkupdates and pacscripts, pacdiff still needs to be updatedhttps://gitlab.archlinux.org/pacman/pacman-contrib/-/merge_requests/41Add option to display `checkupdates `results in a neatly organized table2024-02-07T16:41:01Zcedric cvlAdd option to display `checkupdates `results in a neatly organized table```
$ checkupdates -t/--table
archlinux-keyring 20231113-1 -> 20231130-1
c-ares 1.22.1-1 -> 1.23.0-1
evolution 3.50.1-1 -> 3.50.2-1
evoluti...```
$ checkupdates -t/--table
archlinux-keyring 20231113-1 -> 20231130-1
c-ares 1.22.1-1 -> 1.23.0-1
evolution 3.50.1-1 -> 3.50.2-1
evolution-data-server 3.50.1-2 -> 3.50.2-1
evolution-ews 3.50.1-1 -> 3.50.2-1
firefox 120.0-1 -> 120.0.1-1
firefox-i18n-fr 120.0-1 -> 120.0.1-1
firewalld 2.0.1-1 -> 2.0.2-1
gnome-disk-utility 45.0-1 -> 45.1-1
gnome-software 45.1-2 -> 45.2-1
```https://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/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/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/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/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/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/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.