[pacman-dev] [GIT] The official pacman repository branch, master, updated. v3.4.1-88-g46ffd34
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 46ffd342a4255916a9599692b5969ae4cd85a156 (commit) via fa933df65b9e024ec3291fcc1f995be3dc000e0c (commit) via 67068b64b9da96a0122591ede25c50ab307a1612 (commit) via 73442a7e035a7b7f8ed80261226989ae87edd3a9 (commit) via 1e0e5b2a0241d1f3e298991c0d583afb9c80baef (commit) via dff73a2a69de1c55a0ba9fe75a9f7a900e5ed15b (commit) from bef19a266bf5d80b68cab02f6a3ccc3fcedbec6d (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 46ffd342a4255916a9599692b5969ae4cd85a156 Author: Jakob Gruber <jakob.gruber@gmail.com> Date: Sat Oct 9 09:20:57 2010 +0200 CLI args: add pactest with an invalid combination Pacman should catch cases in which the passed arguments don't apply to the current operation (sync/query/...). Also see FS#20950. Signed-off-by: Dan McGee <dan@archlinux.org> commit fa933df65b9e024ec3291fcc1f995be3dc000e0c Author: Xavier Chantry <chantry.xavier@gmail.com> Date: Mon Oct 11 01:05:04 2010 +0200 pactest: fix gensync gensync generated a sync.db file with PKGINFO syntax, this is not quite what pacman expects. Also the file was only added to the Server path: root/var/pub/sync/sync.db but it was not available in the normal sync db path: root/var/lib/pacman/sync/sync.db Change gensync() to generate var/lib/pacman/sync/sync.db and then copy it to var/pub/sync/sync.db (this is used by sync200 -Sy test). Signed-off-by: Dan McGee <dan@archlinux.org> commit 67068b64b9da96a0122591ede25c50ab307a1612 Author: Xavier Chantry <chantry.xavier@gmail.com> Date: Mon Oct 11 01:05:03 2010 +0200 pactest: use simpler method to create tar Just like in 24fc623e1a8bf905cf0367f9bd40bc5bd6034378, apply to pmdb gensync as well. Signed-off-by: Dan McGee <dan@archlinux.org> commit 73442a7e035a7b7f8ed80261226989ae87edd3a9 Author: Dan McGee <dan@archlinux.org> Date: Thu Oct 7 17:53:11 2010 -0500 Only check for function if we are using libfetch We did this check unconditionally, rather than only doing it if we were actually going to build and run with libfetch. This is safe because we would have already bailed if libfetch was explicitly requested but not found. Signed-off-by: Dan McGee <dan@archlinux.org> commit 1e0e5b2a0241d1f3e298991c0d583afb9c80baef Author: Dan McGee <dan@archlinux.org> Date: Thu Oct 7 15:50:29 2010 -0500 Remove use of `seq` in pactree This is not a bash builtin, so can potentially cause portability issues. Additionally, the use of it is completely unnecessary as it can all be done within bash (and done faster). $ time pactree xfwm4 >/dev/null (old version) real 0m3.245s $ time ./contrib/pactree xfwm4 >/dev/null (new version) real 0m3.042s Signed-off-by: Dan McGee <dan@archlinux.org> commit dff73a2a69de1c55a0ba9fe75a9f7a900e5ed15b Author: Dan McGee <dan@archlinux.org> Date: Tue Oct 5 11:44:32 2010 -0500 Avoid stat call to determine is_directory if possible On Linux and OS X, we can determine if an entry obtained through a readdir() call is a directory without also having to stat it. This can save a significant number of syscalls. The performance increase isn't dramatic, but it could be on some platforms (e.g. Cygwin) so it shouldn't hurt to use this unconditionally where supported. Signed-off-by: Dan McGee <dan@archlinux.org> ----------------------------------------------------------------------- Summary of changes: configure.ac | 4 +++- contrib/pactree | 3 ++- lib/libalpm/be_files.c | 29 +++++++++++++++++++---------- test/pacman/pmdb.py | 37 +++++++++++++++---------------------- test/pacman/pmtest.py | 12 +++++++----- test/pacman/tests/pacman005.py | 11 +++++++++++ test/pacman/util.py | 1 + 7 files changed, 58 insertions(+), 39 deletions(-) create mode 100644 test/pacman/tests/pacman005.py hooks/post-receive -- The official pacman repository
On 12/10/10 01:33, Dan McGee wrote:
commit dff73a2a69de1c55a0ba9fe75a9f7a900e5ed15b Author: Dan McGee<dan@archlinux.org> Date: Tue Oct 5 11:44:32 2010 -0500
Avoid stat call to determine is_directory if possible
On Linux and OS X, we can determine if an entry obtained through a readdir() call is a directory without also having to stat it. This can save a significant number of syscalls. The performance increase isn't dramatic, but it could be on some platforms (e.g. Cygwin) so it shouldn't hurt to use this unconditionally where supported.
Signed-off-by: Dan McGee<dan@archlinux.org>
I thought we were dropping that one as it actually made things slowed? Allan
On Mon, Oct 11, 2010 at 5:27 PM, Allan McRae <allan@archlinux.org> wrote:
On 12/10/10 01:33, Dan McGee wrote:
commit dff73a2a69de1c55a0ba9fe75a9f7a900e5ed15b Author: Dan McGee<dan@archlinux.org> Date: Tue Oct 5 11:44:32 2010 -0500
Avoid stat call to determine is_directory if possible
On Linux and OS X, we can determine if an entry obtained through a readdir() call is a directory without also having to stat it. This can save a significant number of syscalls. The performance increase isn't dramatic, but it could be on some platforms (e.g. Cygwin) so it shouldn't hurt to use this unconditionally where supported.
Signed-off-by: Dan McGee<dan@archlinux.org>
I thought we were dropping that one as it actually made things slowed?
Xavier and I talked about it, and my numbers were a bit flawed due to having a debug-compiled pacman and comparing it against the system pacman. We also figured it would help a lot on patches with a slow stat (Cygwin, etc.). -Dan
On Tue, Oct 12, 2010 at 12:38 AM, Dan McGee <dpmcgee@gmail.com> wrote:
Xavier and I talked about it, and my numbers were a bit flawed due to having a debug-compiled pacman and comparing it against the system pacman. We also figured it would help a lot on patches with a slow stat (Cygwin, etc.).
-Dan
Allan already killed it with hatred in the backend branch :) Maybe we want to keep this in be_local.c : _alpm_local_db_populate ? I still don't believe that avoiding thousands of stats can hurt, but probably no big deal.
On Wed, Oct 13, 2010 at 5:36 PM, Xavier Chantry <chantry.xavier@gmail.com> wrote:
On Tue, Oct 12, 2010 at 12:38 AM, Dan McGee <dpmcgee@gmail.com> wrote:
Xavier and I talked about it, and my numbers were a bit flawed due to having a debug-compiled pacman and comparing it against the system pacman. We also figured it would help a lot on patches with a slow stat (Cygwin, etc.).
-Dan
Allan already killed it with hatred in the backend branch :) Maybe we want to keep this in be_local.c : _alpm_local_db_populate ? I still don't believe that avoiding thousands of stats can hurt, but probably no big deal.
Yes, we will probably want to port it into that set of patches, I agree. -Dan
On 14/10/10 08:53, Dan McGee wrote:
On Wed, Oct 13, 2010 at 5:36 PM, Xavier Chantry <chantry.xavier@gmail.com> wrote:
On Tue, Oct 12, 2010 at 12:38 AM, Dan McGee<dpmcgee@gmail.com> wrote:
Xavier and I talked about it, and my numbers were a bit flawed due to having a debug-compiled pacman and comparing it against the system pacman. We also figured it would help a lot on patches with a slow stat (Cygwin, etc.).
-Dan
Allan already killed it with hatred in the backend branch :) Maybe we want to keep this in be_local.c : _alpm_local_db_populate ? I still don't believe that avoiding thousands of stats can hurt, but probably no big deal.
Yes, we will probably want to port it into that set of patches, I agree.
Whoops! Poor rebasing on my part. I was intending to keep this iin be_local and has assumed it was... I will fix that. Allan
On 14/10/10 10:54, Allan McRae wrote:
On 14/10/10 08:53, Dan McGee wrote:
On Wed, Oct 13, 2010 at 5:36 PM, Xavier Chantry <chantry.xavier@gmail.com> wrote:
On Tue, Oct 12, 2010 at 12:38 AM, Dan McGee<dpmcgee@gmail.com> wrote:
Xavier and I talked about it, and my numbers were a bit flawed due to having a debug-compiled pacman and comparing it against the system pacman. We also figured it would help a lot on patches with a slow stat (Cygwin, etc.).
-Dan
Allan already killed it with hatred in the backend branch :) Maybe we want to keep this in be_local.c : _alpm_local_db_populate ? I still don't believe that avoiding thousands of stats can hurt, but probably no big deal.
Yes, we will probably want to port it into that set of patches, I agree.
Whoops! Poor rebasing on my part. I was intending to keep this iin be_local and has assumed it was... I will fix that.
And it has been restored. Although the majority of it use has been removed due to not reading in the sync database via a directory list on the file system. Allan
participants (4)
-
Allan McRae
-
Dan McGee
-
dan＠archlinux.org
-
Xavier Chantry