- Pacman-dev - lists.archlinux.org

[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

Working on SandboxUser patch
by Allan McRae 12 Feb '23

12 Feb '23

Just to avoid any potential overlap - I am working on the SandboxUser patch that Remi submitted a long while ago... https://lists.archlinux.org/archives/list/pacman-dev@lists.archlinux.org/th… The patch is far too big for me to confidently review in one go, so I am splitting it into smaller sections as I go. Progress can be seen here: https://gitlab.archlinux.org/pacman/pacman/-/commits/allan/privsep Allan

7 21

[PATCH] repo-add: do not recreate the database if nothing was changed
by Ivan Shapovalov 08 Feb '23

08 Feb '23

Signed-off-by: Ivan Shapovalov <intelfx(a)intelfx.name> --- When `repo-add` is used to add a package that already exists in the database, it will recompress the database unconditionally, even if `--new` is passed. Avoid doing that. scripts/repo-add.sh.in | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/scripts/repo-add.sh.in b/scripts/repo-add.sh.in index 221abdc0..78195de1 100644 --- a/scripts/repo-add.sh.in +++ b/scripts/repo-add.sh.in @@ -44,6 +44,8 @@ USE_COLOR='y' PREVENT_DOWNGRADE=0 INCLUDE_SIGS=0 +ENTRIES_CHANGED=0 + # Import libmakepkg source "$LIBRARY"/util/compress.sh source "$LIBRARY"/util/message.sh @@ -343,6 +345,8 @@ db_write_entry() { rm -f ${oldfile} ${oldfile}.sig fi + (( ++ENTRIES_CHANGED )) + return 0 } # end db_write_entry @@ -365,6 +369,9 @@ db_remove_entry() { pkgentry=$(find_pkgentry "$pkgname") done + if [[ $notfound == 0 ]]; then + (( ++ENTRIES_CHANGED )) + fi return $notfound } # end db_remove_entry @@ -684,13 +691,13 @@ for arg in "${args[@]:1}"; do done # if the whole operation was a success, re-zip and rotate databases -if (( !fail )); then +if (( !fail )) && (( ENTRIES_CHANGED > 0 )); then msg "$(gettext "Creating updated database file '%s'")" "$REPO_DB_FILE" create_db rotate_db else msg "$(gettext "No packages modified, nothing to do.")" - exit 1 + exit $(( fail != 0 )) fi exit 0 -- 2.38.0

3 6

RFC: Automatically fallback to Arch Linux Archive if all mirrors returned 404
by Yuuta Liang 05 Feb '23

05 Feb '23

Hi, I am using Arch Linux on lots of my personal servers, and most of them are not updated regularly. This causes trouble when I need to install a package on these servers because the requested package versions are already gone from mirrors. Upgrading these machines requires some effort because I need to wait and also manually fix pacnews, so it is not very ad-hoc. This is also an annoying issue on old (well, not the latest I'd say) Arch ISOs. I sometimes use Arch ISO to debug offline Linux systems, and I need to quickly install some debug tools, but my old Arch ISOs usually need to get a full update to install these packages, which is really annoying. Although Arch Linux is currently providing an archive service, it still requires manually typing the URL, which is not very convenient. I would like to work on a patch that automatically falls back to downloading `https://archive.archlinux.org/packages/.all/package_name-version-arch.pkg.tar.xxx` if all mirrors returned 404. The administrator may configure the archive URL prefix in pacman.conf(5). How does that sound? This is only a handy helper for users and will not likely to break any Arch systems except those very old ones, which need to be upgraded to get things working. If it sounds good, I would like to submit the patch as soon as possible, or are there any suggestions? Thank you very much. Best regards, Yuuta Liang

2 1

[Important] Gitlab migation plan for Pacman
by Morten Linderud 03 Jan '23

03 Jan '23

Hi, Some time ago it was decided to migrate the pacman development from the Mailing List to the Gitlab instance hosted by Arch Linux. The pacman source has been hosted there for a while but the development has strictly been conducted on the Mailing List and this is about to change. https://gitlab.archlinux.org/pacman/pacman/ The plan is as follows: 1. Open the patch submission via Gitlab and close the mailing list submission 2. Open the Gitlab issue tracker and close down the flyspry issue tracker 3. Manually migrate bugs from flyspry to Gitlab and close the others. Currently the issue tracker is open on Gitlab, and merge requests have also been enabled for some time. No EOL dates has been set on on patch submission nor flyspry, but I'd encourage any new development to using gitlab instead of the mailing list and flyspry from this point on. I propose we close down Flyspry and patch submission 1st of January 2023. This change also implies decommisioning the Patchwork instance. For this to be done we need to keep track of any unmerged/unreviewed patches from the mailing list. This list has been made and if anything is missing please do reach out. https://gitlab.archlinux.org/pacman/pacman/-/issues/1 There is also some documentation work that needs to be done to direct users from the Mailing List to Gitlab. Any help updating this documentation is very much appreciated. Cheers, Morten Linderud

3 6

[Git][pacman/pacman][master] pacman-key: Fix shell syntax
by Allan McRae (＠allan) 02 Jan '23

02 Jan '23

Allan McRae pushed to branch master at Pacman / Pacman Commits: d35728f9 by Stefan Weil at 2023-01-01T15:54:48+01:00 pacman-key: Fix shell syntax Fixes: 3f8029af92752c04 ("pacman-key: Use ngettext for plurals") Signed-off-by: Stefan Weil <sw(a)weilnetz.de> - - - - - 1 changed file: - scripts/pacman-key.sh.in View it on GitLab: https://gitlab.archlinux.org/pacman/pacman/-/commit/d35728f92421eb9e0980fb7… -- View it on GitLab: https://gitlab.archlinux.org/pacman/pacman/-/commit/d35728f92421eb9e0980fb7… You're receiving this email because of your account on gitlab.archlinux.org.

1 0