- Pacman-dev - lists.archlinux.org

[PATCH v2] query: permit filter options with --owns
by Ronan Pigott 02 Jun '23

02 Jun '23

Signed-off-by: Ronan Pigott <ronan(a)rjp.ie> --- Changes from v1: 1. Use forward declarations 2. Drop the unnecessary error message src/pacman/pacman.c | 1 - src/pacman/query.c | 6 ++++++ 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/src/pacman/pacman.c b/src/pacman/pacman.c index e5c6e4200932..320c7654e0a7 100644 --- a/src/pacman/pacman.c +++ b/src/pacman/pacman.c @@ -608,7 +608,6 @@ static void checkargs_query(void) } else if(config->op_q_owns) { invalid_opt(config->group, "--owns", "--groups"); checkargs_query_display_opts("--owns"); - checkargs_query_filter_opts("--owns"); } else if(config->group) { checkargs_query_display_opts("--groups"); } diff --git a/src/pacman/query.c b/src/pacman/query.c index d75c4c801be5..e79b956838a0 100644 --- a/src/pacman/query.c +++ b/src/pacman/query.c @@ -135,6 +135,9 @@ cleanup: return (success ? resolved_path : NULL); } +static int is_unrequired(alpm_pkg_t *pkg, unsigned short level); +static int filter(alpm_pkg_t *pkg); + static int query_fileowner(alpm_list_t *targets) { int ret = 0; @@ -210,6 +213,9 @@ static int query_fileowner(alpm_list_t *targets) } for(i = packages; i && (!found || is_dir); i = alpm_list_next(i)) { + if (!filter(i->data)) { + continue; + } if(alpm_filelist_contains(alpm_pkg_get_files(i->data), rel_path)) { print_query_fileowner(rpath, i->data); found = 1; -- 2.41.0

1 0

[PATCH 0/2] Permit query filter options with --owns
by Ronan Pigott 01 Jun '23

01 Jun '23

Recently I wanted to find foreign packages that own a path and found that pacman -Qmoq /my/path gives an error. I don't see any reason in principle why this should not be allowed, so I'd like to change it. Ronan Pigott (2): query: move declarations of filter related functions query: permit filter options with --owns src/pacman/pacman.c | 1 - src/pacman/query.c | 131 ++++++++++++++++++++++++-------------------- 2 files changed, 71 insertions(+), 61 deletions(-) -- 2.40.1

4 8

[PATCH] doc/submitting-patches: helpfully mention the list address
by Ronan Pigott 29 May '23

29 May '23

--- I think it would be helpful to mention the list address in the documentation. doc/submitting-patches.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/submitting-patches.asciidoc b/doc/submitting-patches.asciidoc index 14b80b61a643..7988b250f539 100644 --- a/doc/submitting-patches.asciidoc +++ b/doc/submitting-patches.asciidoc @@ -57,7 +57,7 @@ Submitting your patch --------------------- -- -* Send the patch to the pacman-dev mailing list +* Send the patch to the pacman-dev mailing list <pacman-dev(a)lists.archlinux.org> The mailing list is the primary queue for review and acceptance. Here you will get feedback, and let the reviewers know the details of your patch. -- 2.40.1

1 0

[Git][pacman/pacman][master] Disable brittle valgrind test in CI
by Allan McRae (＠allan) 22 May '23

22 May '23

Allan McRae pushed to branch master at Pacman / Pacman Commits: 2c45e854 by Allan McRae at 2023-05-22T19:32:47+10:00 Disable brittle valgrind test in CI Signed-off-by: Allan McRae <allan(a)archlinux.org> - - - - - 1 changed file: - .gitlab-ci.yml View it on GitLab: https://gitlab.archlinux.org/pacman/pacman/-/commit/2c45e854ab405101fc13f6b… -- View it on GitLab: https://gitlab.archlinux.org/pacman/pacman/-/commit/2c45e854ab405101fc13f6b… You're receiving this email because of your account on gitlab.archlinux.org.

1 0

[Git][pacman/pacman][master] Update pactest README
by Allan McRae (＠allan) 22 May '23

22 May '23

Allan McRae pushed to branch master at Pacman / Pacman Commits: a81ec016 by Allan McRae at 2023-05-22T19:25:23+10:00 Update pactest README Signed-off-by: Allan McRae <allan(a)archlinux.org> - - - - - 1 changed file: - test/pacman/README View it on GitLab: https://gitlab.archlinux.org/pacman/pacman/-/commit/a81ec016d7d845cc8e14efe… -- View it on GitLab: https://gitlab.archlinux.org/pacman/pacman/-/commit/a81ec016d7d845cc8e14efe… You're receiving this email because of your account on gitlab.archlinux.org.

1 0

[Git][pacman/pacman][master] 2 commits: makepkg.conf.5: correction option name
by Allan McRae (＠allan) 22 May '23

22 May '23

Allan McRae pushed to branch master at Pacman / Pacman Commits: 5e947524 by Allan McRae at 2023-05-22T18:54:01+10:00 makepkg.conf.5: correction option name Also fix typo "librarys" Signed-off-by: Allan McRae <allan(a)archlinux.org> - - - - - 55da1a01 by Allan McRae at 2023-05-22T18:55:23+10:00 makepkg.conf.in: strip leading slash from LIB_DIRS Signed-off-by: Allan McRae <allan(a)archlinux.org> - - - - - 2 changed files: - doc/makepkg.conf.5.asciidoc - etc/makepkg.conf.in View it on GitLab: https://gitlab.archlinux.org/pacman/pacman/-/compare/262aa6c24ee85f96882c37… -- View it on GitLab: https://gitlab.archlinux.org/pacman/pacman/-/compare/262aa6c24ee85f96882c37… You're receiving this email because of your account on gitlab.archlinux.org.

1 0

[RFC] Add post-package test() function to PKGBUILD
by Lamarr Rikskringen 07 Apr '23

07 Apr '23

Hi, PKGBUILDs include the check() function which allows one to run tests on the software after it has been built, but before it has been packaged. This message proposes to add a test() function, which essentially allows to run tests after package(), and in particular after the package has been installed in a chroot (for these testing purposes). This allows the packager to run tests against the final installation (or as final as can be in a chroot). Between package() and test(), the resulting pkg is installed in a chroot like on the regular system (i.e. /usr/bin instead of $pkgdir/usr/bin). Everything but the pkg files and the test files is removed, so only the installation is under test. The idea for this came from the issue that Python packages usually don't need a build or rather, that that build can't be tested without fully installing it. This installation however isn't really possible since /usr/ is inaccessible for obvious reasons. Workarounds usually involve setting the PYTHONPATH, but that's tedious at best and ultimately unnecessary. Because Python has an extensive auto-detection of libraries and dependencies, the tests can be executed easily, if Python can find them. And after installation (in /usr/lib/python*/site-packages/), the package is easily found. This of course is in contrast to most compiled languages, who would require lots of paths and links in order to be able to compile the tests. It shouldn't be this way, but it is. A slight complication arises from the fact that tests can theoretically be anywhere in the python source code. So either makepkg figures out what is a test, or the packager specifies that. In most cases though, all tests are in a single directory, and the edge cases are vast, so the latter case with some boilerplate is probably better. In total, a PKGBUILD might look something like this (names are subject to change): ``` build() { cd ${pkgname}-${pkgver}/ python -m build --wheel --no-isolation } check() { cd ${pkgname}-${pkgver}/ python -m pytest } package() { cd ${pkgname}-${pkgver}/ python -m installer --destdir="$pkgdir" dist/*.whl } collect() { cd ${pkgname}-${pkgver}/ # collects the tests and puts them into $testdir python -m pytest --co | grep -o "[^ ]*\.py" | xargs cp -t $testdir } # inbetween collect() and test(), the package is installed in the chroot and $testdir is copied test() { # we are in $testdir (e.g. /home/builduser) pytest } ``` Notice the line in collect() which is responsible to collect the tests. We basically ask pytest what it wants to run, then filter out the files, and lastly copy them into $testdir, which is ultimately copied over and run. In most cases, this line might just be something like `cp tests/ $testdir/`. ------------ Makepkg ------------ This post is already quite long, so I'll make it quick with some implementation thoughts. Since collect() and test() always run together or don't run together (test() needs collect() and only collect() has no effect), only a single option is necessary to toggle whether to run the post-package tests. The order of package() and collect() conceptually doesn't matter, but collect() should probably run after to guarantee that it does not influence package(). Either case, the packager is responsible. This is a pure addition, so if collect() and test() are missing, then just nothing happens. If only collect() is implemented, that might be ignored too. If only test() exists, then an error is probably most helpful, since no packages are copied. Alternatively, maybe makepkg does some limited test identification (like looking for tests/ folder). Or just nothing happens because the packager made a mistake. Should be obvious enough. In conclusion, two new methods are introduced to allow for better and more precise testing of the final output, as well as easier testing in case of Python. The first function - collect() - collects all the tests in the codebase and copies them into $testdir, while package() creates the pkg in $pkgdir. After that, a chroot with all depends packages is created and the pkg installed therein. $testdir is also copied there. Lastly, the second function - test() - is called and executed to test the installation. Thanks for your attention, if you have further ideas or questions, I'd like to hear them. If something similar has already been discussed, feel free to point out that thread. AFAICT, it hasn't been before. - Lamarrrk

1 0

[Git][pacman/pacman][master] 2 commits: makepkg: do not recurse into LIB_DIRS when looking for library provides
by Allan McRae (＠allan) 13 Feb '23

13 Feb '23

Allan McRae pushed to branch master at Pacman / Pacman Commits: 3323662e by Allan McRae at 2023-02-13T12:09:11+00:00 makepkg: do not recurse into LIB_DIRS when looking for library provides We should only find library provides in the configured directories, and not their subdirectories. Signed-off-by: Allan McRae <allan(a)archlinux.org> - - - - - 262aa6c2 by Allan McRae at 2023-02-13T12:09:11+00:00 Fix comment Signed-off-by: Allan McRae <allan(a)archlinux.org> - - - - - 1 changed file: - scripts/libmakepkg/autodep/library_provides.sh.in View it on GitLab: https://gitlab.archlinux.org/pacman/pacman/-/compare/6c913af95d24fd9bca8c42… -- View it on GitLab: https://gitlab.archlinux.org/pacman/pacman/-/compare/6c913af95d24fd9bca8c42… You're receiving this email because of your account on gitlab.archlinux.org.

1 0

[Git][pacman/pacman][master] Add the -pedantic' compiler flag back to our debug builds
by Allan McRae (＠allan) 13 Feb '23

13 Feb '23

Allan McRae pushed to branch master at Pacman / Pacman Commits: 6c913af9 by Allan McRae at 2023-02-13T22:07:32+10:00 Add the -pedantic' compiler flag back to our debug builds This was lost in the transition from autotools to meson. No additional warnings are given with current gcc and clang. Signed-off-by: Allan McRae <allan(a)archlinux.org> - - - - - 1 changed file: - meson.build View it on GitLab: https://gitlab.archlinux.org/pacman/pacman/-/commit/6c913af95d24fd9bca8c429… -- View it on GitLab: https://gitlab.archlinux.org/pacman/pacman/-/commit/6c913af95d24fd9bca8c429… You're receiving this email because of your account on gitlab.archlinux.org.

1 0

[Git][pacman/pacman][master] 3 commits: libmakepkg: move rust buildenv handling to separate file
by Allan McRae (＠allan) 13 Feb '23

13 Feb '23

Allan McRae pushed to branch master at Pacman / Pacman Commits: 09e82f01 by Allan McRae at 2023-01-13T11:35:35+10:00 libmakepkg: move rust buildenv handling to separate file This serves as a demonstration for how other languages could drop in support into libmakepkg. Signed-off-by: Allan McRae <allan(a)archlinux.org> - - - - - e0bbfb56 by Allan McRae at 2023-01-13T11:35:42+10:00 libmakepkg: ensure clearing of buildflags happens first When 'options=('!buildflags') is used, we want to ensure our buildflags are cleared first. Currently this happens due to luck of alphabetical ordering, but this could change with libmakepkg drop-ins. Signed-off-by: Allan McRae <allan(a)archlinux.org> - - - - - 71764b6d by Allan McRae at 2023-01-17T10:26:07+10:00 makepkg.conf: allow configuration additions via a subdirectory Move rust related buildflags to their own configuration file to provide an example of how other languages could be supported. Signed-off-by: Allan McRae <allan(a)archlinux.org> - - - - - 10 changed files: - + etc/makepkg.conf.d/rust.conf.in - etc/makepkg.conf.in - meson.build - scripts/libmakepkg/buildenv.sh.in - scripts/libmakepkg/buildenv/buildflags.sh.in - scripts/libmakepkg/buildenv/debugflags.sh.in - scripts/libmakepkg/buildenv/meson.build - + scripts/libmakepkg/buildenv/rust.sh.in - scripts/libmakepkg/lint_config/variable.sh.in - scripts/libmakepkg/util/config.sh.in View it on GitLab: https://gitlab.archlinux.org/pacman/pacman/-/compare/d35728f92421eb9e0980fb… -- View it on GitLab: https://gitlab.archlinux.org/pacman/pacman/-/compare/d35728f92421eb9e0980fb… You're receiving this email because of your account on gitlab.archlinux.org.

1 0