- Pacman-dev - lists.archlinux.org

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

18 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 92f0775e76c75ebe9e30355cc99bb40cf365abcb (commit) via 7dae79e7b95c517df136003728363dc9ad346a7e (commit) via bdd8e92ff601aab44941e7572f6c48d7e32a3f24 (commit) via 6f97842ab22eb50fdc689e8aa2e95688d015fa74 (commit) via 8a55b793631f37dbe7f906cd55d0997f920d36e8 (commit) via bba234a92ed9560bab1f1846870faa8303f98064 (commit) via 600782853ad5317ee51423a03487abcf34efd166 (commit) via 14a93b2e436ed19c814653c3b2b61605fd5ca156 (commit) from 7bb9c4098b29d7bcc82ff9e9a823d2adc44cc881 (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 92f0775e76c75ebe9e30355cc99bb40cf365abcb Merge: 7dae79e7b95c517df136003728363dc9ad346a7e bdd8e92ff601aab44941e7572f6c48d7e32a3f24 Author: Dan McGee <dan(a)archlinux.org> Date: Tue Aug 18 20:49:25 2009 -0500 Merge branch 'maint' Conflicts: lib/libalpm/dload.c commit 7dae79e7b95c517df136003728363dc9ad346a7e Author: Xavier Chantry <shiningxc(a)gmail.com> Date: Sat Aug 8 19:59:02 2009 +0200 dload.c : various fixes - fix one memleak if get_filename failed - cleanup according to Joerg's feedback: "url_for_string: If fetchParseURL returned successful, you should always have a scheme set. The logic for anonftp should only be needed for very broken server -- do you know of any such? download_internal: Specifying 'p' is now a nop -- it is tried by default first with fall-back to active FTP." Signed-off-by: Xavier Chantry <shiningxc(a)gmail.com> [Dan: remove from pacman.conf and pacman.conf.5] Signed-off-by: Dan McGee <dan(a)archlinux.org> ----------------------------------------------------------------------- Summary of changes: README | 1 - configure.ac | 2 +- doc/pacman.conf.5.txt | 3 --- etc/pacman.conf.in | 1 - lib/libalpm/alpm.h | 2 -- lib/libalpm/dload.c | 43 +++++++++++-------------------------------- lib/libalpm/handle.c | 14 -------------- lib/libalpm/handle.h | 1 - src/pacman/pacman.c | 5 +---- src/pacman/query.c | 12 +++++++++++- src/pacman/sync.c | 2 +- src/util/testdb.c | 6 ++---- 12 files changed, 27 insertions(+), 65 deletions(-) hooks/post-receive -- The official pacman repository

1 0

[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 13 Aug '09

13 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