- Pacman-dev - lists.archlinux.org

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

[pacman-dev] BUG and PATCH: 'handle' not null after alpm_release()
by Markus Meissner 21 Jan '10

21 Jan '10

Hi pacman dev list, I am the guy behind pyalpmm and I found a not so small bug in libalpm. As I wrote some unit-tests for pyalpmm I needed to open and close a libalpm-"session" multiple times without restarting the calling application. Something like that: 1. alpm_initialize(); 2. /** do some operation here **/ 3. alpm_release(); 4. alpm_initialize(); 5. alpm_release(); But I couldn't do this, because the alpm_initialize() call in line 4 always threw an error (errno: PM_ERR_HANDLE_NOT_NULL), which translates to: "library already initialized". This is obviously not true, because the alpm_release() function was successfully called. I checked the code and found out that this line threw the error: ASSERT(handle != NULL, RET_ERR(PM_ERR_HANDLE_NULL, -1)); What means that the handle is not correctly reseted to NULL, but the _alpm_free_handle() function, which is called by alpm_release() has a FREE(handle) inside. So here is my explanation why this happens: The handle pointer is passed to _alpm_free_handle() as a value, so the pointer value itself is copied. This works perfect for freeing the contents of the handle struct, BUT setting this handle pointer to NULL just sets the locally copied pointer to NULL, what means the original handle variable remains un-touched. So every alpm_initialize() call after the first one will throw this error, no matter if you called alpm_release() or not. So to get finally end, I fixed it and the patch is (against latest git) attached to this email. Hopefully my explanation is enough to sketch the problem. Solving it, is really easy, just change the _alpm_free_handle() function to take a pointer of a pointer of pmhandle_t as an argument, change the references to handle inside the function and slightly change the _alpm_free_handle() call in alpm_release(). That's how it is done with the attached patch... Finally I also have a question: I saw many changes in the recent git compared to the latest release. Is there an estimated release date? Thanks and Greets Markus

4 6

[pacman-dev] outdated web stuff
by Jeff 21 Jan '10

21 Jan '10

Just a heads up: ftp://ftp.archlinux.org/other/pacman/md5sums doesn't include 3.3.3. http://www.archlinux.org/pacman/ shows 3.3.0 as the latest version HTH! -- Jeff My other computer is an abacus.

2 2

[pacman-dev] [PATCH] Print "there is nothing to do" with NOOP transactions
by Nagy Gabor 21 Jan '10

21 Jan '10

This patch was inspired by FS#17859. (That is not a bug atm due to "target loading"-interface change.) >From now on, with "empty" transactions (e.g. -Ru needed_pkg) pacman prints a " there is nothing to do" message. The " local database is up to date" message is kept for -Su. Signed-off-by: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> --- Reason for resubmit: Xavier and I decided to keep the old -Su message to not confuse scripts (and users). src/pacman/remove.c | 1 + src/pacman/sync.c | 6 +++++- src/pacman/upgrade.c | 1 + 3 files changed, 7 insertions(+), 1 deletions(-) diff --git a/src/pacman/remove.c b/src/pacman/remove.c index 6d44350..61b57c7 100644 --- a/src/pacman/remove.c +++ b/src/pacman/remove.c @@ -118,6 +118,7 @@ int pacman_remove(alpm_list_t *targets) /* Step 3: actually perform the removal */ alpm_list_t *pkglist = alpm_trans_get_remove(); if(pkglist == NULL) { + printf(_(" there is nothing to do\n")); goto cleanup; /* we are done */ } /* print targets and ask user confirmation */ diff --git a/src/pacman/sync.c b/src/pacman/sync.c index a2ef616..3832f03 100644 --- a/src/pacman/sync.c +++ b/src/pacman/sync.c @@ -663,7 +663,11 @@ static int sync_trans(alpm_list_t *targets) packages = alpm_trans_get_add(); if(packages == NULL) { /* nothing to do: just exit without complaining */ - printf(_(" local database is up to date\n")); + if(config->op_s_upgrade) { + printf(_(" local database is up to date\n")); + } else { + printf(_(" there is nothing to do\n")); + } goto cleanup; } diff --git a/src/pacman/upgrade.c b/src/pacman/upgrade.c index 57c7b79..ddb4796 100644 --- a/src/pacman/upgrade.c +++ b/src/pacman/upgrade.c @@ -132,6 +132,7 @@ int pacman_upgrade(alpm_list_t *targets) /* print targets and ask user confirmation */ alpm_list_t *packages = alpm_trans_get_add(); if(packages == NULL) { /* we are done */ + printf(_(" there is nothing to do\n")); trans_release(); return(retval); } -- 1.6.6

1 0

[pacman-dev] [PATCH] makepkg: [Idea] Introduce $SRCPKGDEST
by Nezmer 20 Jan '10

20 Jan '10

Introduce $SRCPKGDEST to define a destination dir for source packages instead of saving them in $PKGDEST with binary packages. The simple patch doesn't break old behavior. Signed-off-by: Nezmer <git(a)nezmer.info> --- etc/makepkg.conf.in | 2 ++ scripts/makepkg.sh.in | 7 +++++-- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/etc/makepkg.conf.in b/etc/makepkg.conf.in index 3a3a415..b92a697 100644 --- a/etc/makepkg.conf.in +++ b/etc/makepkg.conf.in @@ -91,6 +91,8 @@ PURGE_TARGETS=(usr/{,share}/info/dir .packlist *.pod) #PKGDEST=/home/packages #-- Source cache: specify a fixed directory where source files will be cached #SRCDEST=/home/sources +#-- Source packages: specify a fixed directory where all src packages will be placed +#SRCPKGDEST=/home/srcpackages #-- Packager: name/email of the person or organization building packages #PACKAGER="John Doe <john(a)doe.com>" diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 5bbd880..5bd294c 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1108,7 +1108,7 @@ create_srcpackage() { "$SRCEXT" ;; esac - local pkg_file="$PKGDEST/${pkgbase}-${pkgver}-${pkgrel}${SRCEXT}" + local pkg_file="$SRCPKGDEST/${pkgbase}-${pkgver}-${pkgrel}${SRCEXT}" # tar it up msg2 "$(gettext "Compressing source package...")" @@ -1575,6 +1575,7 @@ done #preserve environment variables _PKGDEST=${PKGDEST} _SRCDEST=${SRCDEST} +_SRCPKGDEST=${SRCPKGDEST} # default config is makepkg.conf MAKEPKG_CONF=${MAKEPKG_CONF:-$confdir/makepkg.conf} @@ -1613,6 +1614,8 @@ PKGDEST=${_PKGDEST:-$PKGDEST} PKGDEST=${PKGDEST:-$startdir} #default to $startdir if undefined SRCDEST=${_SRCDEST:-$SRCDEST} SRCDEST=${SRCDEST:-$startdir} #default to $startdir if undefined +SRCPKGDEST=${_SRCPKGDEST:-$SRCPKGDEST} +SRCPKGDEST=${SRCPKGDEST:-$PKGDEST} #default to $PKGDEST if undefined if (( HOLDVER )) && [[ -n $FORCE_VER ]]; then @@ -1838,7 +1841,7 @@ msg "$(gettext "Making package: %s")" "$pkgbase $pkgver-$pkgrel ($(date))" # if we are creating a source-only package, go no further if (( SOURCEONLY )); then - if [[ -f $PKGDEST/${pkgbase}-${pkgver}-${pkgrel}${SRCEXT} ]] \ + if [[ -f $SRCPKGDEST/${pkgbase}-${pkgver}-${pkgrel}${SRCEXT} ]] \ && (( ! FORCE )); then error "$(gettext "A source package has already been built. (use -f to overwrite)")" exit 1 -- 1.6.6

6 5