- Pacman-dev - lists.archlinux.org

[pacman-dev] [PATCH] makepkg: run tidy_install with no package() function
by Allan McRae 30 Mar '09

30 Mar '09

After the splitpkg implementation, the tidy_install function was not being called in PKGBUILDs with only the build() function. Signed-off-by: Allan McRae <allan(a)archlinux.org> --- scripts/makepkg.sh.in | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 716c5a9..349d0e0 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1635,6 +1635,7 @@ if [ "$INFAKEROOT" -eq 1 ]; then if [ "$PKGFUNC" -eq 0 ]; then if [ "$REPKG" -eq 0 ]; then run_build + tidy_install fi else run_package -- 1.6.2.1

1 0

[pacman-dev] [PATCH] makepkg: do not bail on failure to install built package
by Allan McRae 29 Mar '09

29 Mar '09

Fixes FS#13417. Do no exit makepkg on a failure to install the built package(s). This allows clean-up to still occur. Signed-off-by: Allan McRae <allan(a)archlinux.org> --- scripts/makepkg.sh.in | 10 ++++++++-- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index ff2663b..716c5a9 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1071,10 +1071,16 @@ install_package() { pkglist="${pkglist} $PKGDEST/${pkg}-${pkgver}-${pkgrel}-${CARCH}${PKGEXT}" done + local ret=0 if [ "$ASROOT" -eq 0 ]; then - sudo pacman $PACMAN_OPTS -U ${pkglist} || exit $? + sudo pacman $PACMAN_OPTS -U ${pkglist} || ret=$? else - pacman $PACMAN_OPTS -U ${pkglist} || exit $? + pacman $PACMAN_OPTS -U ${pkglist} || ret=$? + fi + + if [ $ret -ne 0 ]; then + warning "$(gettext "Failed to install built package(s).")" + return 0 fi } -- 1.6.2.1

1 0

[pacman-dev] makepkg repackage option text
by Allan McRae 26 Mar '09

26 Mar '09

Hi, Currently makepkg has a line like this: echo "$(gettext " -R, --repackage Repackage contents of pkg/ without building")" which is now true, but only to an extent... If a PKGBUILD has a package() function or split packages, then the packaging functions are run, not just a simple repacking of pkg/. So, alternative text is needed, and I need help generating it. How about: "Rerun the packaging stage only"? or does this need more description? For the man page: Rerun the packaging stage without rebuilding the package. This is useful if you forgot a depend or install file in your PKGBUILD and the build itself will not change. Comments? Allan

3 3

[pacman-dev] [PATCH] makepkg: adjust log clean-up for new filenames
by Allan McRae 25 Mar '09

25 Mar '09

The log files now have -build or -package at the end and there are separate log files for each *_package() function. Alter clean_up() to deal with this. Also, move glob outside quotes so this actually works. Signed-off-by: Allan McRae <allan(a)archlinux.org> --- scripts/makepkg.sh.in | 9 ++++++++- 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 95ee520..ff2663b 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -155,7 +155,14 @@ clean_up() { rm -rf "$pkgdir" "$srcdir" if [ -n "$pkgname" ]; then # Can't do this unless the BUILDSCRIPT has been sourced. - rm -f "${pkgname}-${pkgver}-${pkgrel}-${CARCH}.log*" + rm -f "${pkgbase}-${pkgver}-${pkgrel}-${CARCH}-build.log"* + if [ "$PKGFUNC" -eq 1 ]; then + rm -f "${pkgbase}-${pkgver}-${pkgrel}-${CARCH}-package.log"* + elif [ "$SPLITPKG" -eq 1 ]; then + for pkg in ${pkgname[@]}; do + rm -f "${pkg}-${pkgver}-${pkgrel}-${CARCH}-package.log"* + done + fi fi fi -- 1.6.2.1

1 0

[pacman-dev] [PATCH] makepkg: adjust install_package for split packages
by Allan McRae 25 Mar '09

25 Mar '09

Install all created packages when using the install option with package splitting. Signed-off-by: Allan McRae <allan(a)archlinux.org> --- scripts/makepkg.sh.in | 17 ++++++++++++++--- 1 files changed, 14 insertions(+), 3 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index a804489..95ee520 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1052,11 +1052,22 @@ create_srcpackage() { install_package() { [ "$INSTALL" -eq 0 ] && return - msg "$(gettext "Installing package ${pkgname} with pacman -U...")" + + if [ "$SPLITPKG" -eq 0 ]; then + msg "$(gettext "Installing package ${pkgname} with pacman -U...")" + else + msg "$(gettext "Installing ${pkgbase} package group with pacman -U...")" + fi + + local pkglist + for pkg in ${pkgname[@]}; do + pkglist="${pkglist} $PKGDEST/${pkg}-${pkgver}-${pkgrel}-${CARCH}${PKGEXT}" + done + if [ "$ASROOT" -eq 0 ]; then - sudo pacman $PACMAN_OPTS -U $PKGDEST/${pkgname}-${pkgver}-${pkgrel}-${CARCH}${PKGEXT} || exit $? + sudo pacman $PACMAN_OPTS -U ${pkglist} || exit $? else - pacman $PACMAN_OPTS -U $PKGDEST/${pkgname}-${pkgver}-${pkgrel}-${CARCH}${PKGEXT} || exit $? + pacman $PACMAN_OPTS -U ${pkglist} || exit $? fi } -- 1.6.2.1

1 0

[pacman-dev] Doing more stuff with optdepends
by Allan McRae 25 Mar '09

25 Mar '09

Hi, I have been thinking about optdepends and if we can improve the handling of them. So, given I am better at making wiki pages than patches... http://wiki.archlinux.org/index.php/User:Allan/Pacman_OptDepends What do people think about this idea? Are there other sensible additions to that proposal? I know that optdepends were originally for getting rid of informational messages but I have some packages on my system that are installed "explicitly" when they are really (opt)deps for other packages. Allan

6 8

[pacman-dev] fix for Turkish translation (patch)
by Samed Beyribey 23 Mar '09

23 Mar '09

Hello, I've created a patch for some typos in Turkish translation, and there was an alignment problem in pacman -Sh output, so i've fixed them. Could you check and apply my patch, please? Regards, Samed.

2 3

[pacman-dev] [PATCH] Document --debug
by Nagy Gabor 22 Mar '09

22 Mar '09

>From c121fa3c9ad702f4daa0f1156869573673d749c7 Mon Sep 17 00:00:00 2001 From: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Date: Sun, 22 Mar 2009 17:13:29 +0100 Subject: [PATCH] Document --debug After some irc/forum experiences, I decided to document this option. However, I left the debug-level undocumented (--debug=2). Signed-off-by: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> --- doc/pacman.8.txt | 6 +++++- src/pacman/pacman.c | 1 + 2 files changed, 6 insertions(+), 1 deletions(-) diff --git a/doc/pacman.8.txt b/doc/pacman.8.txt index c574872..95880a2 100644 --- a/doc/pacman.8.txt +++ b/doc/pacman.8.txt @@ -124,9 +124,13 @@ Options command line or in linkman:pacman.conf[5], their default location will be inside this root path. -*-v, --verbose*:: +*-v, \--verbose*:: Output paths such as as the Root, Conf File, DB Path, Cache Dirs, etc. +*\--debug*:: + Display debug messages. When reporting bugs, this option is recommended + to be used. + *\--cachedir* <'dir'>:: Specify an alternative package cache location (a typical default is ``/var/cache/pacman/pkg''). Multiple cache directories can be specified, diff --git a/src/pacman/pacman.c b/src/pacman/pacman.c index 59916d6..14cfdfa 100644 --- a/src/pacman/pacman.c +++ b/src/pacman/pacman.c @@ -143,6 +143,7 @@ static void usage(int op, const char * const myname) printf(_(" --noprogressbar do not show a progress bar when downloading files\n")); printf(_(" --noscriptlet do not execute the install scriptlet if one exists\n")); printf(_(" -v, --verbose be verbose\n")); + printf(_(" --debug display debug messages\n")); printf(_(" -r, --root <path> set an alternate installation root\n")); printf(_(" -b, --dbpath <path> set an alternate database location\n")); printf(_(" --cachedir <dir> set an alternate package cache location\n")); -- 1.6.0.3

1 0

[pacman-dev] patch submission help
by Jeff 18 Mar '09

18 Mar '09

In the last month I have created and tested [1] a patch for pacman-3.2.2 that allows for 3 different PKGBUILD functions: build() check() inst(). This allows for a new option in makepkg.conf called check which is expected to default to !check (and overridden for toolchain packages). build() and check() are never run in fakeroot, only inst() (with exception for !fakeroot or --asroot, of course) which conforms to the fakeroot recommendation. My attempt was to make the patch backwards compatible so that if any of the functions weren't present, it was not an error. However, I realized while writing this email that this means that a PKGBUILD with just build() would run completely in a non-fakeroot environment which needs re-thinking. Anyway, it's a rather small patch as seen below: $ grep ^- makepkg.patch | grep -v ^--- |wc -l 16 $ grep ^+ makepkg.patch | grep -v ^+++ |wc -l 33 The reason for this email, though, is that I subbed to this list to watch how things are done, learn protocol, etc. So I grabbed the git repo and started looking at how I was going to apply this patch since enough has changed to cause all but 1 hunk to fail. I am not familiar with git, preferring svn, but can read docs. Where I'm tripped up is realizing that head doesn't reflect what private branches might hold. One person (sorry, I forget who) mentioned having a branch with many makepkg changes in it which would cause me to have to hand apply these changes again. I have no interest in doing that, so I'm asking: does this feature seem like it would be worthwhile (read; would the patch be accepted)? If so, how do I access private branches so my branch doesn't conflict with them? [1] I am building a base system with the new PKGBUILD format and am about 3/4 of the way done with no known makepkg errors (running makepkg with sh -x for extra detail) -- Jeff My other computer is an abacus.

7 8

Re: [pacman-dev] patch submission help
by Jeff 18 Mar '09

18 Mar '09

On Wed, Mar 18, 2009 at 10:03:26AM +1000, Allan McRae wrote: > > What exactly is dangerous about this? There are two options > 1) build() and package() functions - here only package() is run in fakeroot > 2) build() function only - build() is run in fakeroot. I apologize. I misread it as build() is never run in fakeroot. > All my changes are now on the pacman master branch so you can just check > that out. See here for further info: > http://www.archlinux.org/pacman/#_development Sweet. > The check() function should serve as a major hint that it should be > run. Perhaps, if it is present and not invoked using --check then a > warning could be printed. A warning does sound nice, but I was referring to a hint that a testsuite *should* be run. Obviously the toolchain would be in that category whereas some would argue things like sed's testsuite is minor and generally not worth the time or trouble to run. Personally this wouldn't affect me as I run every testsuite. -- Jeff My other computer is an abacus.

1 0