June 2007 - Pacman-dev - lists.archlinux.org

[pacman-dev] [GIT] pacman branch, master now at v3.0.0-240-gda66bed
by Dan McGee 26 Jun '07

26 Jun '07

Hello, This is an automated email from the git hooks/update script, it was generated because a ref change was pushed to the repository. Updating branch, master, via da66bedf4f98897dfc350195314089028050fa7d (commit) via 2ae043866045bbeef129a4b503ee1f5486545821 (commit) via f401e523981a72664d7f52e5697e3e09de597aeb (commit) from 0de5c97193f16195351957eada94f3e39a2d7d05 (commit) - Log ----------------------------------------------------------------- commit da66bedf4f98897dfc350195314089028050fa7d Author: Nagy Gabor <ngaba(a)petra.hos.u-szeged.hu> Date: Mon Jun 18 10:40:23 2007 -0400 Remove unnecessary trans parameter from _alpm_checkdeps The trans parameter was never used, so remove it. Signed-off-by: Nagy Gabor <ngaba(a)petra.hos.u-szeged.hu> Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 2ae043866045bbeef129a4b503ee1f5486545821 Author: Dan McGee <dan(a)archlinux.org> Date: Sun Jun 17 23:40:21 2007 -0400 Don't extract any top-level files in a package that start with '.' For future possibilities, don't extract any files that start with '.'. This will allow us to add features such as the ChangeLog viewing without having to wait to include these files in packages, because older versions of pacman will be forward compatable with 'hidden' files at the root level of the package. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit f401e523981a72664d7f52e5697e3e09de597aeb Author: Dan McGee <dan(a)archlinux.org> Date: Sun Jun 17 20:34:09 2007 -0400 Mirror update and NEWS updates Signed-off-by: Dan McGee <dan(a)archlinux.org> ----------------------------------------------------------------------- Diffstat: NEWS | 8 ++++++++ etc/pacman.d/mirrorlist.in | 5 +++++ lib/libalpm/add.c | 11 +++++++++-- lib/libalpm/deps.c | 5 ++--- lib/libalpm/deps.h | 2 +- lib/libalpm/remove.c | 4 ++-- lib/libalpm/sync.c | 4 ++-- 7 files changed, 29 insertions(+), 10 deletions(-) hooks/update --- Git Source Code Management System hooks/update refs/heads/master \ 0de5c97193f16195351957eada94f3e39a2d7d05 \ da66bedf4f98897dfc350195314089028050fa7d

1 0

[pacman-dev] [alpm] PM_ERR_PKG_HOLD - what's this?
by Georg Grabler 21 Jun '07

21 Jun '07

Hello guys, With the current ALPM version i get PM_ERR_PKG_HOLD on adding packages. In the current pacman GIT i could just find it in the remove process. Anyway, what does it mean? Has something changed so i need to define holdpkgs in some way? Is there even a need to define them? Hasn't been some weeks ago, so something must have been changed. Yours, Georg (STiAT)

2 4

[pacman-dev] [GIT] pacman branch, master now at v3.0.0-237-g0de5c97
by Dan McGee 21 Jun '07

21 Jun '07

Hello, This is an automated email from the git hooks/update script, it was generated because a ref change was pushed to the repository. Updating branch, master, via 0de5c97193f16195351957eada94f3e39a2d7d05 (commit) from f372a542b9f37b7e36cc3419bf14b5c4e8fbb94c (commit) - Log ----------------------------------------------------------------- commit 0de5c97193f16195351957eada94f3e39a2d7d05 Author: Dan McGee <dan(a)archlinux.org> Date: Wed Jun 20 17:54:42 2007 -0400 libalpm/util.c: remove unnecessary include Signed-off-by: Dan McGee <dan(a)archlinux.org> ----------------------------------------------------------------------- Diffstat: lib/libalpm/util.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) hooks/update --- Git Source Code Management System hooks/update refs/heads/master \ f372a542b9f37b7e36cc3419bf14b5c4e8fbb94c \ 0de5c97193f16195351957eada94f3e39a2d7d05

1 0

[pacman-dev] CVS update of pacman-lib/lib/libalpm (add.c)
by Dan McGee 20 Jun '07

20 Jun '07

Date: Wednesday, June 20, 2007 @ 17:52:24 Author: dan Path: /home/cvs-pacman/pacman-lib/lib/libalpm Modified: add.c (1.132 -> 1.133) Revert erroneous chmod 'fix'. -------+ add.c | 2 -- 1 file changed, 2 deletions(-) Index: pacman-lib/lib/libalpm/add.c diff -u pacman-lib/lib/libalpm/add.c:1.132 pacman-lib/lib/libalpm/add.c:1.133 --- pacman-lib/lib/libalpm/add.c:1.132 Thu May 17 23:26:24 2007 +++ pacman-lib/lib/libalpm/add.c Wed Jun 20 17:52:24 2007 @@ -704,8 +704,6 @@ _alpm_log(PM_LOG_ERROR, _("could not extract %s (%s)"), filename, strerror(errno)); alpm_logaction(_("error: could not extract %s (%s)"), filename, strerror(errno)); errors++; - } else { - chmod(filename, archive_entry_mode(entry)); } /* calculate an hash if this is in newpkg's backup */

1 0

[pacman-dev] [GIT] pacman branch, master now at v3.0.0-236-gf372a54
by Dan McGee 20 Jun '07

20 Jun '07

Hello, This is an automated email from the git hooks/update script, it was generated because a ref change was pushed to the repository. Updating branch, master, via f372a542b9f37b7e36cc3419bf14b5c4e8fbb94c (commit) from cacf968970bbc63e8eb519e40194e6c083ba6a06 (commit) - Log ----------------------------------------------------------------- commit f372a542b9f37b7e36cc3419bf14b5c4e8fbb94c Author: Dan McGee <dan(a)archlinux.org> Date: Wed Jun 20 17:38:56 2007 -0400 Revert "Fix libarchive permission extraction" This was a bad way to fix a problem upstream. Doing this resulted in symlink permissions being applied to files installed on the system, leaving some binaries with 77 permission, etc. This reverts commit 4e6b7c1cde4c0ac1d035b51f9af19510a7c9135e. ----------------------------------------------------------------------- Diffstat: lib/libalpm/add.c | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) hooks/update --- Git Source Code Management System hooks/update refs/heads/master \ cacf968970bbc63e8eb519e40194e6c083ba6a06 \ f372a542b9f37b7e36cc3419bf14b5c4e8fbb94c

1 0

[pacman-dev] pacman screws up permissions
by Thomas Bächler 20 Jun '07

20 Jun '07

I just installed the ntfs-3g package with pacman 3.0.5-1: $ /bin/ls -lhF /bin/ntfs-3g /usr/man/man8/ntfs-3g.8.gz -rwxrwxrwx 1 root root 36K 20. Jun 01:45 /bin/ntfs-3g* -rwxrwxrwx 1 root root 3,0K 20. Jun 01:44 /usr/man/man8/ntfs-3g.8.gz* The permissions in the tarfile are 755 for /bin/ntfs-3g (and I suppose they are 644 for the manpage, didn't check that). This behaviour can cause critical bugs and in this case is security-relevant, as a user could change the ntfs-3g binary, which is executed at boot time on many systems. This has to be fixed FAST.

2 2

[pacman-dev] libarchive, pacman, and libtool-slaying
by Dan McGee 19 Jun '07

19 Jun '07

I'm sending this to two lists to see who can offer some insight, as I tried and failed earlier to get pacman to correctly build with a newer version of libarchive. I think it may deal with having la files in the package, but I am not sure so I'll outline what I've tried and know so far. Libarchive website: http://people.freebsd.org/~kientzle/libarchive/ Current version: 2.2.3 Current Arch Linux version: 1.3.1-2 As you can see, we are a ways behind. I up-ed the PKGBUILD for libarchive, rebuilt it without problems (as far as I can tell), and then pacman -U <new libarchive> and tried to compile pacman. The ldd output showed that it correctly linked against the new libarchive.so.2, but it had somehow also linked against libarchive.so.1. I tried rebuilding libarchive using options=(!libtool), but that didn't seem to fix anything- it actually just spit some more errors saying libarchive was missing la files and such. OK, long explanation, but it comes down to this: 1. How can we get pacman to compile with libarchive without needing the la files? libdownload seems to work fine without them, etc. 2. Where is this mysterious link to libarchive.so.1 coming from when it isn't even present on my system anymore? This applies to both the most recent CVS release and our GIT tree at projects.al.org. -Dan

2 1

[pacman-dev] [patch] alpm_removedeps bug+fix && alpm_depcmp-discussion
by ngaba＠petra.hos.u-szeged.hu 19 Jun '07

19 Jun '07

Hi! I attached the pactest file and my patch. I also made some modifications in alpm_removedeps' args, because the old one was a bit messy for me. And I think that my version is faster. can_remove_package is a bit stupid (compared to alpm_checkdeps), but I leave it untouched, because speed is more important here than "perfection". As you see, this patch contains my usual "for (pkg in pkgcache) if(alpm_depcmp(pkg, depend))..." stuff. We should discuss something now: This method has a drawback sometimes in speed: This method implicitly reads the pkgcache with full pkginfo, because alpm_depcmp needs provisions. If we've already done this (or we need to do this later) or we must collect ALL dependency satisfier in pkgcache this is not a problem. However, for example if we just want to know if there is ANY package in pkgcache which satisfies a dependency (something similar to can_remove_package without using requiredby fields), then FIRST check for package names THEN for providers is probably faster, if the pkgcache is loaded with pkgname-pkgver info only: because we have great chance to find a satisfier pkgname-pkgver pair and we can stop, we can answer the question without reading the ugly PKGINFO files for providers. Bye, ngaba ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

3 10

[pacman-dev] FS7461: Pacman permission problems
by Andrew Fyfe 19 Jun '07

19 Jun '07

There's still some problems (FS7461) with pacman/libarchive and setuid files, the permissions are getting screwed up when extracting the file. The best fix I can see is to upgrade to libarchive-2.2.3 and remove the chmod hack Aaron added to lib/libalpm/add.c

1 0

[pacman-dev] installing two packages conflicting with each other
by Xavier 19 Jun '07

19 Jun '07

http://bugs.archlinux.org/task/7415#comment17206 I think this bug is not so obvious, there are two package in the same group, one conflicts / replaces / provides the other. There are at least 3 cases to consider here for the state before the installation : none of the packages are installed, old package is installed, new package is installed. Should pacman always choose the package replacing the other ? And what should happen without the replace flag, if the package only provides and conflicts with the other ?

1 2