- Pacman-dev - lists.archlinux.org

[pacman-dev] Inconsistency of makepkg's activities in devel_check()
by Benjamin Richter 18 Aug '09

18 Aug '09

Hello developers. :-) I noticed that makepkg handles Mercurial repositories differently from CVS/SVN/Bazaar/etc. With the others, $newpkgver is either computed using $(date ...) or retrieved from the online repository and the PKGBUILD is responsible for retrieving the contents as it is demonstrated here: http://wiki.archlinux.org/index.php/Arch_CVS_%6_SVN_PKGBUILD_guidelines. Only with hg the repository is automatically cloned, pulled and updated: - - - - - makepkg, in devel_check(), lines 1211 and following - - - - - if [ -n "${_darcstrunk}" -a -n "${_darcsmod}" ] ; then [ $(type -p darcs) ] || return 0 msg "$(gettext "Determining latest darcs revision...")" newpkgver=$(date +%Y%m%d) elif [ -n "${_cvsroot}" -a -n "${_cvsmod}" ] ; then [ $(type -p cvs) ] || return 0 msg "$(gettext "Determining latest cvs revision...")" newpkgver=$(date +%Y%m%d) elif [ -n "${_gitroot}" -a -n "${_gitname}" ] ; then [ $(type -p git) ] || return 0 msg "$(gettext "Determining latest git revision...")" newpkgver=$(date +%Y%m%d) elif [ -n "${_svntrunk}" -a -n "${_svnmod}" ] ; then [ $(type -p svn) ] || return 0 msg "$(gettext "Determining latest svn revision...")" newpkgver=$(LC_ALL=C svn info $_svntrunk | sed -n 's/^Last Changed Rev: $[0-9]*$$/\1/p') elif [ -n "${_bzrtrunk}" -a -n "${_bzrmod}" ] ; then [ $(type -p bzr) ] || return 0 msg "$(gettext "Determining latest bzr revision...")" newpkgver=$(bzr revno ${_bzrtrunk}) elif [ -n "${_hgroot}" -a -n "${_hgrepo}" ] ; then [ $(type -p hg) ] || return 0 msg "$(gettext "Determining latest hg revision...")" if [ -d ./src/$_hgrepo ] ; then cd ./src/$_hgrepo hg pull hg update else [[ ! -d ./src/ ]] && mkdir ./src/ hg clone $_hgroot/$_hgrepo ./src/$_hgrepo cd ./src/$_hgrepo fi newpkgver=$(hg tip --template "{rev}") cd ../../ fi - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This behaviour seems to be widely unknown, which leads to a lot of PKGBUILDS pulling/updating twice - first automatically and then again in build(): http://aur.archlinux.org/packages/aldrin-hg/aldrin-hg/PKGBUILD http://aur.archlinux.org/packages/audacious-hg/audacious-hg/PKGBUILD ... I just wonder why hg is handled differently and whether it wouldn't be better a) also to clone/update/pull/... svn/bzr/cvs/etc. in devel_check() - cf. http://wiki.archlinux.org/index.php/The_Arch_Way regarding automation or b) to remove devel_check() entirely, but leave devel_update() and let the PKGBUILD handle such changes, eg. like this: - - - complete example PKGBUILD in case anyone wants to try it - - - # Contributor: Artyom Smirnov <smirnoffjr(a)gmail.com> # Contributor: Benjamin Richter <webmaster(a)waldteufel-online.net> pkgname=gajim-hg pkgver=10960 pkgrel=1 pkgdesc="Jabber/XMMP instant messenger client written in PyGTK" arch=('i686' 'x86_64') url="http://gajim.org" license=('GPL') depends=('python>=2.5' 'pygtk>=2.12' 'sqlite3' 'dnsutils') makedepends=('python>=2.5' 'pygtk>=2.12' 'gtk2' 'libxss' 'dbus' 'gtkspell' 'intltool>=0.40.1' 'automake>=1.8' 'autoconf>=2.59' 'libtool' 'pkgconfig>=0.19') optdepends=('pyopenssl: secure SSL/TLS' 'pycrypto: End to end encryption' 'dbus-glib: link-local messaging (install python-avahi!)' 'python-avahi: link-local messaging (install dbus-glib!)' 'dnsutils: SRV support' 'gtkspell: Spell checking (install aspell-LANG!)' 'gnome-python-extras: GNOME integration' 'gnome-python-desktop: Keyring support' 'python-notify: Notification popups' 'dbus-python' 'python-sexy: for clickable URLs' 'python-kerberos>=1.1: GSSAPI authentication') provides=('gajim') conflicts=('gajim' 'gajim-svn') options=(!libtool) source=() md5sums=() scm_hg() { [[ -d "$2" ]] || hg clone "$1" "$2" || return cd "$2" ; hg pull -u || return newpkgver=$(hg tip --template '{rev}') } scm_retrieve() { [[ -z "$REPO_LATEST" ]] || return 0 export REPO_LATEST=1 msg "$(gettext "Determining latest $1 revision...")" cd "${srcdir}" "scm_${1}" "$2" "$3" msg2 "$(gettext 'Version found: %s')" "${newpkgver}" cd "${startdir}" devel_update } scm_retrieve hg http://hg.gajim.org/gajim gajim build() { cp -al gajim gajim-build cd gajim-build ./autogen.sh || return ./configure --prefix=/usr || return make || return make DESTDIR="${pkgdir}" install || return cd .. rm -r gajim-build find "${pkgdir}/usr/share/gajim/" -name "*.pyo" | xargs rm } - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - cf. http://wiki.archlinux.org/index.php/The_Arch_Way regarding freedom (in this case: ... of the PKGBUILDer to choose by which means to retrieve sources under SCM) btw.: This latter approach already works without any change in makepkg. The question is whether it is advisable, especially because there is code outside build() which is run when the PKGBUILD is sourced, which happens twice because of fakeroot. This is why this PKGBUILD needs either the variable $REPO_LATEST or a rather ugly check whether makepkg is running in fakeroot (INFAKEROOT=1), which I'd rather not use because $INFAKEROOT is more like an implementation detail of makepkg. All this could be avoided by introducing another function - eg. update() - into the PKGBUILD which is run only once - that is: after sourcing the PKGBUILD when outside fakeroot - and sets $newpkgver, which would then be read by devel_update, which would be called after update() automatically. Makepkg would detect the existence of a function called update() and display the appropriate messages - eg. "Updating PKGBUILD...". The PKGBUILD would then look like this - provided that update() is called in $srcdir: - - - - - - - - - - - - - - another example - - - - - - - - - - - - - - pkgname=gajim-hg #... variables as before update() { [[ -d gajim ]] || hg clone http://hg.gajim.org/gajim || return 1 hg pull -u -R gajim || return 1 newpkgver=$(hg tip --template '{rev}' -R gajim) } #... build() as before - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - update() could also be called scm_retrieve() or something like that. Any opinions? Kind regards. Benjamin Richter (aka Waldteufel)

4 7

Re: [pacman-dev] [PATCH] add support for .so dependencies
by Christoph Schied 15 Aug '09

15 Aug '09

On Sun, Aug 16, 2009 at 01:38:51AM +1000, Allan McRae wrote: > The "magically" adding depends is my concern. If the libraries provided > by a package are to be in a depends array, then there is no need for > that package to be in the depends array (but should be in makedepends). > Otherwise this makes pacman have to do redundant checks and slows down > dependency resolution. Yes, like you already said, putting package dependencies into makedepends would solve that issue. The so-dependency is a lot nicer because it exactly specifies on what the package depends, and not on a "virtual" package version. You cannot produce inconsitent linking without breaking dependencies, and you get this almost for free, as there is no extra maintaining effort needed. > What I would like is a description of the problem this is trying to > solve that could not be already handled by versioned deps? It ensures consitent linking without providing manual versioned dependencies. This will solve problems like pacman -S y <package> because the full linking dependencies will have to be considered. This is especially nice if you consider packages that aren't built upstream, as linking-breakage will be detected by pacman, so it will make the handling with AUR packages a lot easier. My Motivation to this is that I broke my system quite often because I wasn't aware of how simple pacman handles the dependencies, and i think a packagemanagers purpose is to not break the system and keep everything consistent. greetings, Christoph

1 0

Re: [pacman-dev] [PATCH] add support for .so dependencies
by Christoph Schied 15 Aug '09

15 Aug '09

On Sun, Aug 16, 2009 at 12:45:50AM +1000, Allan McRae wrote: > "arch" is a reserved variable name in PKGBUILDs. This will break split > package support for packages that have both binary and arch=any packages > (which will be supported in the future). Okay, this one should be easy to fix. > As far as I can tell, IFS does absolutely nothing here. IFS is set to newline. > Well, the patch being broken and so I assume untested was my main > issue. I will not review a patch the submitter has not even tested. Bluewind tested it yesterday, and it worked for him. > Well, then... what is the point? Versioned dependencies already cover > soname values if the package is listed as a dep in addition to is > library. The point is that the dependencies are magically generated and this greatly reduces the work for the maintainer to specify the explicit versioned dependencies (which doesn't happen right now). Also the .so dependencies are not about the library version, but about the content of the package. greetings, Christoph Schied

2 1

[pacman-dev] [translation] Russian translation for pacman 3.3
by partizan 14 Aug '09

14 Aug '09

last version was good, but this is even better :)

1 0

[pacman-dev] [GIT] The official pacman repository branch, maint, updated. v3.3.0-7-g14a93b2
by dan＠archlinux.org 14 Aug '09

14 Aug '09

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The official pacman repository". The branch, maint has been updated via 14a93b2e436ed19c814653c3b2b61605fd5ca156 (commit) from 6d00025c18e837f57a4f78ee232fe3d8f244f143 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 14a93b2e436ed19c814653c3b2b61605fd5ca156 Author: Dan McGee <dan(a)archlinux.org> Date: Thu Aug 13 21:01:40 2009 -0500 Make fetch timeout actually 10 seconds We had 10000 as our timeout value, assuming it was expressed in ms. This is false after looking at the current code, so reset it back to 10 seconds. Addresses FS#15369. Signed-off-by: Dan McGee <dan(a)archlinux.org> ----------------------------------------------------------------------- Summary of changes: lib/libalpm/dload.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] [translation] Russian translation for pacman 3.3 (upd 2)
by partizan 12 Aug '09

12 Aug '09

sorry, once more update :)

1 0

[pacman-dev] [translation] Russian translation for pacman 3.3(upd)
by partizan 12 Aug '09

12 Aug '09

hello, i have fixed some bugs in translation.

1 0

[pacman-dev] Pacman 3.3.0 released
by Dan McGee 09 Aug '09

09 Aug '09

Woo! Thanks everyone, the source should be hitting your favorite mirror or here (ftp://ftp.archlinux.org/other/pacman/) soon. -Dan

4 6

[pacman-dev] Bash port of rankmirrors
by matthew bruenig 08 Aug '09

08 Aug '09

bruenig here, wrote a bash port of rankmirrors posted it in the forums because I don't know how you guys do things http://bbs.archlinux.org/viewtopic.php?pid=597235#p597235 I've tested it and am convinced it works. Perhaps you could do the same and then include it in pacman eventually to get rid of the awful python optdepend and replace it with a curl optdepend.

3 2

[pacman-dev] [GIT] The official pacman repository branch, master, updated. v3.3.0-12-g7bb9c40
by dan＠archlinux.org 08 Aug '09

08 Aug '09

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The official pacman repository". The branch, master has been updated via 7bb9c4098b29d7bcc82ff9e9a823d2adc44cc881 (commit) via e8806748ec6efdf62fd1210873dc2fd38cccdf2a (commit) via 619d1fcf7f6a834d6bf5eda846ce39cc2ca5a8f3 (commit) via 6d00025c18e837f57a4f78ee232fe3d8f244f143 (commit) via 3cf0ee98c02e1f40954f0c2c508e16d33ca299ca (commit) via 68200676d2828f159d5dbdf184c3ad7de42c66d6 (commit) via d7675e393ff3cecb5408c243898ebaae80c5988d (commit) via ee43e75ed2e8b852f1ae140d8a619a39a90d8481 (commit) via 839bb562693d83aa61e996b492b731ff452a2bcd (commit) via f16c7a4343c2e82d7ead0423c70495de5441b1ef (commit) via 4fa6f262a66336240b6e792955dcd38f04753bf2 (commit) via 8152077f6d923f5ff432175a3f86f232fd75919f (commit) from aba58e95abbeef2a9145ec702338def1e4912898 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 7bb9c4098b29d7bcc82ff9e9a823d2adc44cc881 Merge: e8806748ec6efdf62fd1210873dc2fd38cccdf2a 6d00025c18e837f57a4f78ee232fe3d8f244f143 Author: Dan McGee <dan(a)archlinux.org> Date: Sat Aug 8 11:23:38 2009 -0500 Merge branch 'maint' commit e8806748ec6efdf62fd1210873dc2fd38cccdf2a Author: Dan McGee <dan(a)archlinux.org> Date: Sat Aug 8 11:23:21 2009 -0500 Fix nonsensical replace Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 619d1fcf7f6a834d6bf5eda846ce39cc2ca5a8f3 Author: Dan McGee <dan(a)archlinux.org> Date: Sat Aug 8 11:22:52 2009 -0500 Pass all xsltproc-opts in one argument Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 3cf0ee98c02e1f40954f0c2c508e16d33ca299ca Author: Xavier Chantry <shiningxc(a)gmail.com> Date: Sat Aug 8 15:20:24 2009 +0200 dload.c : only call fwrite once I assume the loop was never iterated more than once, because the write location was not updated at each loop iteration (buffer instead of buffer + nwritten), yet we never had reports of corrupted download. Signed-off-by: Xavier Chantry <shiningxc(a)gmail.com> Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 68200676d2828f159d5dbdf184c3ad7de42c66d6 Author: Allan McRae <allan(a)archlinux.org> Date: Fri Aug 7 16:40:04 2009 +1000 Be consistent with naming of handle_deps function All other "dep" functions (check_deps, resolve_deps, remove_deps) have underscores separating words. Being consistent, convert handledeps to handle_deps. Signed-off-by: Allan McRae <allan(a)archlinux.org> Signed-off-by: Dan McGee <dan(a)archlinux.org> commit d7675e393ff3cecb5408c243898ebaae80c5988d Author: Xavier Chantry <shiningxc(a)gmail.com> Date: Fri Aug 7 16:58:01 2009 +0200 dload.c : change the way to check for mtimes libfetch supports checking mtime so we do not need to do it manually. when the databases are already up-to-date, initiating a connection with fetchXGet and closing it right after with fetchIO_close took a very long time (up to 10min!) on some network. Signed-off-by: Xavier Chantry <shiningxc(a)gmail.com> Signed-off-by: Dan McGee <dan(a)archlinux.org> ----------------------------------------------------------------------- Summary of changes: doc/Makefile.am | 4 ++-- etc/makepkg.conf.in | 2 +- lib/libalpm/dload.c | 32 +++++++++++++++++--------------- lib/libalpm/util.c | 4 ++-- scripts/makepkg.sh.in | 14 +++++++------- scripts/repo-add.sh.in | 2 +- src/pacman/sync.c | 26 +++++++++++++++++--------- 7 files changed, 47 insertions(+), 37 deletions(-) hooks/post-receive -- The official pacman repository

1 0