- Pacman-dev - lists.archlinux.org

[pacman-dev] Bash completion
by Cedric Staniewski 26 Feb '10

26 Feb '10

Hi, I just replaced my bash completion file with the git version and noticed it tries to execute /bin/seq and fails because seq is located at /usr/bin/seq. Since I could not find anything in coreutils' changelog file I guess the path was wrong right from the start and should be corrected. The other thing I wonder about (still the same commit[1]) is why the (slower) external echo command is preferred to bash's internal implementation. Thanks, Cedric [1] http://projects.archlinux.org/pacman.git/commit/?id=8b3f5f0ce6dca98ca14cc48…

4 4

[pacman-dev] [PATCH] makepkg: update required programs
by Allan McRae 25 Feb '10

25 Feb '10

Remove getopt, add xz. Signed-off-by: Allan McRae <allan(a)archlinux.org> --- scripts/makepkg.sh.in | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 5120feb..3d987ac 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -28,7 +28,7 @@ # makepkg uses quite a few external programs during its execution. You # need to have at least the following installed for makepkg to function: # bsdtar (libarchive), bzip2, coreutils, fakeroot, find (findutils), -# getopt (util-linux), gettext, grep, gzip, openssl, sed, tput (ncurses) +# gettext, grep, gzip, openssl, sed, tput (ncurses), xz # gettext initialization export TEXTDOMAIN='pacman' -- 1.7.0

1 0

[pacman-dev] bug: pacman giving up too fast downloading
by Paul Dufresne 17 Feb '10

17 Feb '10

Well, I have lots of errors while downloading packages with pacman, and almost never while downloading files from Shiretoko Firefox. I have tried many mirrors, that's the same for each. Oh... I use a 56k modem (Intel 536EP Data Fax modem). But even while downloading in Firefox, it sometimes give me the feeling it has stopped downloading for about 40 secs... while pacman seems to give up after about 20 secs. I did not tried yet to download with wget or curl (does pacman use one of them?). Is there a constant I could change in the code, and rebuild it?... I did not download the code of pacman yet.

7 8

[pacman-dev] [PATCH] don't use old packages to satisfy dependencies
by Henning Garus 12 Feb '10

12 Feb '10

Don't use packages which are updated during the current transaction as dependency providers, when computing needed dependencies in resolvedeps. This could lead to new dependencies not being pulled in, in situations like: foo-1 provides bar baz depends on bar foo-2 does not provide bar anymore baz still depends on bar bar is not pulled in because foo-1 is used to satisfy the dependency Signed-off-by: Henning Garus <henning.garus(a)gmail.com> --- This should fix the "phonon bug". I am not entirely happy with this, because I more or less copy the local db (once more) on every call to resolvedeps. Alternatively one could create a joined list from remove and trans->add and give it to checkdeps as remove parameter. This would do what we want (exclude packages which will be upgraded from the list used to compute already satisfied dependencies in checkdeps), but it feels wrong. lib/libalpm/deps.c | 12 +++++++++++- 1 files changed, 11 insertions(+), 1 deletions(-) diff --git a/lib/libalpm/deps.c b/lib/libalpm/deps.c index 46699ac..85d7e24 100644 --- a/lib/libalpm/deps.c +++ b/lib/libalpm/deps.c @@ -600,6 +600,7 @@ int _alpm_resolvedeps(pmdb_t *local, alpm_list_t *dbs_sync, pmpkg_t *pkg, { alpm_list_t *i, *j; alpm_list_t *targ; + alpm_list_t *untouched = NULL; alpm_list_t *deps = NULL; alpm_list_t *packages_copy; @@ -620,11 +621,19 @@ int _alpm_resolvedeps(pmdb_t *local, alpm_list_t *dbs_sync, pmpkg_t *pkg, on that list */ *packages = alpm_list_add(*packages, pkg); + /* Create a list of local packages which can be used to satisfy deps. + * Don't use packages which are updated in the current transaction */ + for(i = _alpm_db_get_pkgcache(local); i; i = i->next) { + if(!alpm_list_find(handle->trans->add, i->data, _alpm_pkg_cmp)) { + untouched = alpm_list_add(untouched, i->data); + } + } + _alpm_log(PM_LOG_DEBUG, "started resolving dependencies\n"); for(i = alpm_list_last(*packages); i; i = i->next) { pmpkg_t *tpkg = i->data; targ = alpm_list_add(NULL, tpkg); - deps = alpm_checkdeps(_alpm_db_get_pkgcache(local), 0, remove, targ); + deps = alpm_checkdeps(untouched, 0, remove, targ); alpm_list_free(targ); for(j = deps; j; j = j->next) { pmdepmissing_t *miss = j->data; @@ -666,6 +675,7 @@ int _alpm_resolvedeps(pmdb_t *local, alpm_list_t *dbs_sync, pmpkg_t *pkg, alpm_list_free_inner(deps, (alpm_list_fn_free)_alpm_depmiss_free); alpm_list_free(deps); } + alpm_list_free(untouched); alpm_list_free(packages_copy); _alpm_log(PM_LOG_DEBUG, "finished resolving dependencies\n"); return(0); -- 1.6.6.1

2 1

Re: [pacman-dev] [arch-general] Error message on mkinitcpio
by Xavier Chantry 12 Feb '10

12 Feb '10

On Thu, Feb 11, 2010 at 10:27 PM, Dan McGee <dpmcgee(a)gmail.com> wrote: > > I think we may have this fixed in pacman-git, but Nagy or Xavier would > know for sure... > That documentation from man PKGBUILD still applies, I don't think we ever considered it as a bug/problem : replaces (array) An array of packages that this package should replace, and can be used to handle renamed/combined packages. For example, if the j2re package is renamed to jre, this directive allows future upgrades to continue as expected even though the package has moved. Sysupgrade is currently the only pacman operation that utilizes this field, a normal sync will not use its value. But now I am wondering if replaces could imply conflicts/provides. Implicit fields means less control and power to the user/packager though.

2 1

Re: [pacman-dev] [arch-dev-public] Warning 2/2: removing kde-unstable; KDE 4.4 in testing
by Xavier Chantry 10 Feb '10

10 Feb '10

On Mon, Feb 1, 2010 at 1:04 PM, Pierre Schmitz <pierre(a)archlinux.de> wrote: > Hi DEVs and TUs, > > I am about to move the first wave of KDE 4.4 RC3 packages into testing. These > will be x86_64 at first; i686 packages might follow later this evening. There > won't be any l10n packages. (they are not needed for testing and rebuild and > we'll save disk space and bandwidth this way) > > The same Information about kde-unstable now apply to testing: > http://wiki.archlinux.org/index.php/DeveloperWiki:KDE#Users Note that the kde- > unstable repository will be removed soon. > > If you update you have to use the following commands as pacman is not able to > resolve the dependencies otherwise: > > % pacman -Sy --asdeps qt > % pacman -Su > Please report this kind of issues to pacman-dev ML or pacman bugtracker in the future :) This limitation was actually not even known to us (at least Nagy and I), and it doesn't seem that we have a pactest for it. This issue might be fixable (at least that specific case), and it might be a pactest that we want to add to the testsuite, to avoid future regressions.

4 6

Re: [pacman-dev] [arch-general] A suggestion for the devs regarding rebuilds
by Xavier Chantry 08 Feb '10

08 Feb '10

On Mon, Jan 11, 2010 at 12:53 AM, Aaron Griffin <aaronmgriffin(a)gmail.com> wrote: > On Sun, Jan 10, 2010 at 12:08 PM, Jeff Horelick <jdhore1(a)gmail.com> wrote: >> Hey all, >> >> I have a suggestion to possibly make rebuilds a bit less painful (or >> non-existant). I think this is a good idea because it seems like right now, >> even before there was a new rebuild (ffmpeg/x264) in testing, there's >> already another on the horizon (linjpeg/libpng, and it's a big one) and when >> this isn't the case, there's usually a rebuild, when it leaves testing, >> another rebuild comes in within days and so on. >> >> My suggestion would be to do what Debian does and when there's a library >> release with a new soname, bump the old package and "rename" it (or for new >> packages just do it from the start) and make the package name include the >> soname version (like libjpeg7, libpng12, libtorrent-rasterbar4 and so on) >> and when the soname is bumped upstream, just make libjpeg8 or libpng13 or >> libtorrent-rasterbar5. This does clutter the repos a bit, but it pretty much >> negates the need for rebuilds since (i believe) when the new GNOME for >> example is released, it'll automagically build against libjpeg8 and libpng13 >> instead of the old ones and eventually, almost no packages will be using the >> old ones. Once the package list for a large rebuild like the libpng/libjpeg >> one is down to 3 or 4 items after like 3 months, you can probably rebuild >> them and pull libjpeg7/libpng12 from the repos. > > This is one of the single biggest things I hate about apt based > distros. The libfoo2/libfoo3/libfoo4 cruft. It's needless. > > This doesn't do anything with regards to helping the devs do rebuilds, > because packages still need to be rebuilt. It just allows us to take > our time - something you DON'T want if you're expecting packages to be > up to date. > With every big rebuilds we get new breakage stories. It seems like it's the norm nowadays rather than the exception. I am wondering if it's really only the users that are to blame.. or if Arch is also to blame. Or if Arch was supposed to be an elitist distribution and is victim of its success. More importantly, I am wondering if the sodepends/soprovides proposal would not actually be a more complex solution than the libfoo2/libfoo3/libfoo4 way.

2 1

[pacman-dev] [PATCH] makepkg: only strip files that are writable
by Allan McRae 03 Feb '10

03 Feb '10

Signed-off-by: Allan McRae <allan(a)archlinux.org> --- scripts/makepkg.sh.in | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 5120feb..0ca5e36 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -869,7 +869,7 @@ tidy_install() { if [[ $(check_option strip) = y && -n ${STRIP_DIRS[*]} ]]; then msg2 "$(gettext "Stripping unneeded symbols from binaries and libraries...")" local binary - find ${STRIP_DIRS[@]} -type f 2>/dev/null | while read binary ; do + find ${STRIP_DIRS[@]} -type f -writable 2>/dev/null | while read binary ; do case "$(file -biz "$binary")" in *compressed-encoding*) # Skip compressed binaries ;; -- 1.6.6.1

4 6

[pacman-dev] [PATCH] makepkg: Add documentation for the new SRCPKGDEST variable
by Nezmer 22 Jan '10

22 Jan '10

Add SRCPKGDEST documentation to the makepkg.conf man page Signed-off-by: Nezmer <git(a)nezmer.info> --- doc/makepkg.conf.5.txt | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/doc/makepkg.conf.5.txt b/doc/makepkg.conf.5.txt index 704dccc..d8ee86b 100644 --- a/doc/makepkg.conf.5.txt +++ b/doc/makepkg.conf.5.txt @@ -171,6 +171,11 @@ Options in the current directory. Many people like to keep all source files in a central location for easy cleanup, so this path can be set here. +**SRCPKGDEST=**"/path/to/folder":: + If this value is not set, source package files will be stored in + PKGDEST. Many people like to keep all source package files in + a central location for easy cleanup, so this path can be set here. + **PACKAGER=**"John Doe <john(a)example.com>":: This value is used when querying a package to see who was the builder. It is recommended you change this to your name and email address. -- 1.6.6

4 3

[pacman-dev] Matching split packages to PKGBUILDs
by Xyne 21 Jan '10

21 Jan '10

I was under the impression that the naming convention for split packages was $pkgbase-$pkgname. I've used this scheme in bauerbill to determine the corresponding PKGBUILD of split packages in $repo.abs.tar.gz. This works for all packages in the kernel26 PKGBUILD, for example, but someone has discovered that this does not work with dhclient. Is there simply no official rule for this or should dhclient actually be names "dhcp-client"? I'm hoping for that latter with the expectation that the name was not changed because the package was named "dhclient" before the advent of split packages. Should I file a bug report and request that the package be renamed "dhcp-client" and provide "dhclient"? If not, how can I sanely determine the corresponding PKGBUILD for packages such as dhclient which do not follow any naming convention that would identify the matching PKGBUILD? Would it be possible to include symlinks or duplicate PKGBUILDs in $repo.abs.tar.gz to enable applications to determine this? I know that some of you feel that the sole purpose of makepkg is to build packages and consequently have no regard for anything else one might want to do with PKGBUILDs, but this is very unfortunate as it severely limits the development of complementary tools. While I see the superficial simplicity of using bash for PKGBUILDs and the convenience of split PKGBUILDs, I really think this is going in the wrong direction. There is a difference between simplicity and laziness, and the trade-off of versatility and elegance is a considerable disadvantage of this direction, as previous discussions here have shown. Regards, Your friendly yet frustrated contributor.

4 6