- Pacman-dev - lists.archlinux.org

[pacman-dev] [PATCH] Remove /bin/true from install.proto
by Roman Kyrylych 30 Jan '08

30 Jan '08

This patch removes /bin/true from install.proto to not endorse its bad usage. This was already done in Arch CVS when we discussed cyclic dependencies in Core. -- Roman Kyrylych (Роман Кирилич)

3 2

Re: [pacman-dev] [arch-dev-public] Filename search for Arch
by Dan McGee 28 Jan '08

28 Jan '08

On Jan 25, 2008 5:31 PM, eliott <eliott(a)cactuswax.net> wrote: > > On 1/25/08, Aaron Griffin <aaronmgriffin(a)gmail.com> wrote: > > On Jan 25, 2008 5:02 PM, Thomas Bächler <thomas(a)archlinux.org> wrote: > > > eliott schrieb: > > > > I guess I don't see where this script fits in, and how it is supposed > > > > to be used. > > > > thomas made mention of using zgrep for advanced users, but that seems > > > > just as difficult as opening a web browser and typing into a search > > > > box. > > > > > > The purpose is to provide filelists for download, so they can be > > > searched offline by pacman. > > > My first idea (implementing an online search in pacman) was rejected, > > > thus I thought about a "download the filelist and search it" offline > > > solution. > > > > Oh, I must have misunderstood too. If you're going to implement > > filelist search and all that stuff, we should: > > a) Move this to the pacman-dev mailing list > > b) Add external tools to do this as part of the "pacman source", i.e. > > as a patch to repo-add > > c) Not use this script until pacman actually has this feature. > > > > If the intent is to let users zgrep it, then I agree with cactus that > > that is significantly more complex then actually using the website to > > provide a search interface. > > Yeah. I wasn't apposed to having a file search mechanism on the site. > I was apposed to having pacman query the website. If a user opens up a > browser and searches, no problem. It was tying this to pacman that I > felt was a *really bad idea*. > > Alternatively, if there is a pacman only solution, that involves some > mirrored meta in the repository, that is something else entirely, and > should probably be talked about on the pacman dev list, so as to make > it as distribution neutral as possible. As I've said already, I really don't think this feature belongs in pacman. Obviously you can draw the connection with the -Ql operation, and the fact that we have -Ss, but this is something a bit different than that and I see it as feature creep. -Dan

10 15

[pacman-dev] dbscripts status
by Xavier 28 Jan '08

28 Jan '08

Why are there so many files there : http://projects.archlinux.org/git/?p=dbscripts.git;a=tree pkgdb, pkgdb1, pkgdb2-add.c, pkgdb2-del.c, pkgdb2.c, updatesync-many. These names don't really speak to me. Is updatesync-many the only one developers use directly? And what are all the pkgdb* stuff for? Well, at least the three c programs seem to interact with the mysql database. But that doesn't explain how all the scripts / programs interact together, and how hard it would be to make them use repo-add instead.

2 1

[pacman-dev] Pacman, sqlite and dialectic of competent people
by Manuel "ekerazha" C. 28 Jan '08

28 Jan '08

Maybe this is a better place where discuss this ( http://bbs.archlinux.org/viewtopic.php?id=42374 ) or at least I've have to clarify some things. 1)** toofishes says: ------------------------------------------------------------------------ Yes its faster. But does it matter all that much? $ time pacman -Qg gnome > /dev/null real 0m0.105s user 0m0.047s sys 0m0.037s $ time pacman -Sg gnome > /dev/null real 0m0.388s user 0m0.160s sys 0m0.203s ------------------------------------------------------------------------ Well... these are my results with Pacman 3.1.0 (Pentium III 933 Mhz, PC133 512 MB, 120 GB 7200rpm with XFS filesystem, "pacman-optimize" regularly done): [root@PC-ekerazha ekerazha]# time pacman -Qg gnome > /dev/null real 0m8.083s user 0m0.107s sys 0m0.233s [root@PC-ekerazha ekerazha]# time pacman -Sg gnome > /dev/null real 0m44.482s user 0m0.510s sys 0m0.963s So 8 and 44 seconds (44 seconds!). Apparently it really matters... toofishes says: ------------------------------------------------------------------------ Here are the things to "do" since you don't seem to understand we are "busy" developing "software" that works and doesn't "break" people's systems in the "name" of speed. ------------------------------------------------------------------------ Why should the sqlite approach "break people's systems in the name of speed"? You clearly don't know what are you talking about... I really hope there are also competent pacman devs there (as you say). 2) phrakture, people like "toofishes" is the living example of why "show you the code" (already partially done but incomplete) is useless. As I've already said, <People will "do" when the things to "do" will be *understood and accepted*, people won't waste their time vainly> and it seems obvious that people like "toofishes" isn't understanding anything about this. However... keep up the good work because Arch is a great Linux distro (the best out there) and well... pacman is a "decent" package manager (although poorly engineered and very slow). P.S. Excuse me for my bad English but it isn't my native language.

10 21

[pacman-dev] [GIT] The official pacman repository branch, maint, updated. v3.1.1-7-g0775c38
by Dan McGee 27 Jan '08

27 Jan '08

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 0775c38e72c06b9ad428c4e6dbfd0b6f0cda2818 (commit) via f950c2630798e03bbee314c4a3f2749d1293a2b3 (commit) via 11692e0eef79e016859bb182917e56a12a14f734 (commit) from bba62655fe06989e89576e66a97607da88aa9916 (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 ----------------------------------------------------------------- ----------------------------------------------------------------------- Summary of changes: doc/makepkg.8.txt | 2 +- scripts/makepkg.sh.in | 2 +- src/pacman/sync.c | 9 +++------ 3 files changed, 5 insertions(+), 8 deletions(-) hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] [GIT] The official pacman repository branch, master, updated. v3.1.1-35-g1fc83f4
by Dan McGee 27 Jan '08

27 Jan '08

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 1fc83f4af6d827bf2e69c7a10e3d2010c9211974 (commit) via 9fbb77c91ba411fa46b1f2955893e7a39291f46a (commit) via 9bfbd739176ebc41e4ec93dcd21264b87640aa5b (commit) via ea828b5693d389d24c744841385b16cb37a32fce (commit) via f432ce41e0892b17d062d8d64ac221e7bc4d718c (commit) via 0775c38e72c06b9ad428c4e6dbfd0b6f0cda2818 (commit) via f950c2630798e03bbee314c4a3f2749d1293a2b3 (commit) via 11692e0eef79e016859bb182917e56a12a14f734 (commit) from 88cbee3c24768470cc0d4abe050e98b989807a67 (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 1fc83f4af6d827bf2e69c7a10e3d2010c9211974 Author: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Date: Sun Jan 27 12:24:50 2008 +0100 pmsyncpkg_t cleanup Fix for sync044.py and reason001.py. Rename sync->data to sync->removes (alpm_list_t *) Replace pmsynctype_t sync->type by pmpkgreason_t sync->newreason The type field was set to UPGRADE or DEPEND or REPLACE. Instead of using type = UPGRADE or DEPEND, we now rather use a "pmpkgreason_t newreason" field directly (= explicit or depend) which allows a better handling of the install reason. And the REPLACE type is now deduced implicitly when the sync->removes list is not empty. Signed-off-by: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 9fbb77c91ba411fa46b1f2955893e7a39291f46a Merge: 9bfbd739176ebc41e4ec93dcd21264b87640aa5b 0775c38e72c06b9ad428c4e6dbfd0b6f0cda2818 Author: Dan McGee <dan(a)archlinux.org> Date: Sun Jan 27 11:54:52 2008 -0600 Merge branch 'maint' commit 9bfbd739176ebc41e4ec93dcd21264b87640aa5b Author: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Date: Fri Jan 25 21:52:35 2008 +0100 Fix PM_ERR_CONFLICTING_DEPS handling in sync.c * eliminate asymmetry (innerconflict vs. outerconflict) * fix a memleak (in case of PM_ERR_MEMORY deps wasn't freed) * fix wrong pmconflict_t duplication (*retconflict = *conflict) Note: the new code introduces some code duplication which shall disappear by fixing FS#7524. Signed-off-by: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> Signed-off-by: Dan McGee <dan(a)archlinux.org> commit ea828b5693d389d24c744841385b16cb37a32fce Author: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Date: Fri Jan 25 21:31:20 2008 +0100 New _alpm_conflict_dup function Added function to cleanly duplicate a conflict. Signed-off-by: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> commit f432ce41e0892b17d062d8d64ac221e7bc4d718c Author: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Date: Mon Jan 14 14:29:41 2008 +0100 small sync.c code clean-up Remove unnecessary synclist_free function, and use our standard way (alpm_list_free_inner + alpm_list_free) instead. This slightly reduces code duplication. Signed-off-by: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> Signed-off-by: Dan McGee <dan(a)archlinux.org> ----------------------------------------------------------------------- Summary of changes: doc/makepkg.8.txt | 2 +- lib/libalpm/alpm.h | 11 +--- lib/libalpm/conflict.c | 11 ++++ lib/libalpm/conflict.h | 1 + lib/libalpm/sync.c | 147 +++++++++++++++++++---------------------------- lib/libalpm/sync.h | 6 +- scripts/makepkg.sh.in | 2 +- src/pacman/sync.c | 9 +-- src/pacman/util.c | 25 ++++----- 9 files changed, 93 insertions(+), 121 deletions(-) hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] [PATCH] conflict error return fix in sync.c
by Nagy Gabor 24 Jan '08

24 Jan '08

From 1225b562d9ce5eb96cc3a391d7a6eb5553ff7450 Mon Sep 17 00:00:00 2001 From: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Date: Thu, 24 Jan 2008 22:52:58 +0100 Subject: [PATCH] conflict error return fix in sync.c *some memleak fixes *unify return lists (inner vs outer conflict) Note: this patch introduces some code duplication, which should be fixed, when fixing FS#7524 Signed-off-by: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> --- lib/libalpm/sync.c | 29 +++++++++++++---------------- 1 files changed, 13 insertions(+), 16 deletions(-) diff --git a/lib/libalpm/sync.c b/lib/libalpm/sync.c index 3e99795..603214d 100644 --- a/lib/libalpm/sync.c +++ b/lib/libalpm/sync.c @@ -485,9 +485,15 @@ int _alpm_sync_prepare(pmtrans_t *trans, pmdb_t *db_local, alpm_list_t *dbs_sync rsync = sync1; sync = sync2; } else { + _alpm_log(PM_LOG_ERROR, _("unresolvable package conflicts detected\n")); pm_errno = PM_ERR_CONFLICTING_DEPS; ret = -1; - *data = deps; + if(data) { + *data = deps; + } else { + alpm_list_free_inner(deps, (alpm_list_fn_free)_alpm_conflict_free); + alpm_list_free(deps); + } goto cleanup; } @@ -552,23 +558,14 @@ int _alpm_sync_prepare(pmtrans_t *trans, pmdb_t *db_local, alpm_list_t *dbs_sync sync->data = alpm_list_add(sync->data, local); } else { /* abort */ _alpm_log(PM_LOG_ERROR, _("unresolvable package conflicts detected\n")); - if(data) { - pmconflict_t *retconflict; - MALLOC(retconflict, sizeof(pmconflict_t), 0); - if(!retconflict) { - pm_errno = PM_ERR_MEMORY; - alpm_list_free_inner(*data, (alpm_list_fn_free)_alpm_conflict_free); - alpm_list_free(*data); - ret = -1; - goto cleanup; - } - *retconflict = *conflict; - *data = alpm_list_add(*data, retconflict); - } pm_errno = PM_ERR_CONFLICTING_DEPS; ret = -1; - alpm_list_free_inner(deps, (alpm_list_fn_free)_alpm_conflict_free); - alpm_list_free(deps); + if(data) { + *data = deps; + } else { + alpm_list_free_inner(deps, (alpm_list_fn_free)_alpm_conflict_free); + alpm_list_free(deps); + } goto cleanup; } } -- 1.5.3.7

1 0

[pacman-dev] Fwd: [arch-general] makepkg not stripping bin/libs
by Travis Willard 24 Jan '08

24 Jan '08

This feels more like pacman-dev material - forwarded there. ---------- Forwarded message ---------- From: Mark Constable <markc(a)renta.net> Date: Jan 24, 2008 6:58 AM Subject: [arch-general] makepkg not stripping bin/libs To: General Discusson about Arch Linux <arch-general(a)archlinux.org> makegpkg 3.1.1 line ~752 has this... find {,usr/{,local/},opt/}{bin,lib,sbin} -type f and I can't see how that will ever work, and it doesn't for me, however this does work (for me)... find -regex ".+/bin/.+" -o -regex ".+/lib/.+" -o -regex ".+/sbin/.+" -type f I recently rebuilt kdemod4 and it ended up being 1.9Gb whereas it should have been around >400Mb. --markc

3 3

[pacman-dev] Some small issues with backup relocation: upgrade044.py; needless .pacorig
by Nagy Gabor 24 Jan '08

24 Jan '08

Look at the following pactest file: ---upgrade044.py--- self.description = "Backup file relocation (package split)" lp = pmpkg("foo") lp.files = ["etc/foo.cfg*"] lp.backup = ["etc/foo.cfg"] self.addpkg2db("local", lp) p1 = pmpkg("foo", "1.0-2") self.addpkg(p1) p2 = pmpkg("libfoo", "1.0-2") p2.files = ["etc/foo.cfg**"] p2.backup = ["etc/foo.cfg"] self.addpkg(p2) self.filesystem = ["etc/foo.cfg"] self.args = "-U %s" % " ".join([p.filename() for p in p1, p2]) self.addrule("PKG_VERSION=foo|1.0-2") self.addrule("PKG_VERSION=libfoo|1.0-2") self.addrule("!FILE_PACSAVE=etc/foo.cfg") self.addrule("FILE_PACNEW=etc/foo.cfg") self.addrule("FILE_EXIST=etc/foo.cfg") ---------- This pactest fails, which means that we get different behaviour, if we had libfoo installed (see upgrade042.py and upgrade043.py). The difference is the immediate corollary of line 501 in add.c (libalpm). It's important to see, that if --force wasn't set we reach that line iff the file was backed up by the transaction, so .pacorig has no meaning in this case. So this .pacorig stuff has meaning with --force, but as I see backup handling with --force is not well defined :-P Bye, ngaba PS: and this .pacorig extension is quite misleading, it suggests "original config file" to me; using .pacsave is more suggestive here imho. ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/

1 1

[pacman-dev] [pacman-git] New release
by Dan McGee 24 Jan '08

24 Jan '08

I pushed a new release tonight. It is the current (88cbee) cut of the master branch. Stable enough for me to trust it here. :) Vastly reduced memory usage compared to v3.1.1 now- I posted a little writeup on my blog about how massif helped us examine this memory issue, as it wasn't a memleak problem at all. That entry is here: http://toofishes.net/blog/valgrind-330-and-new-massif/ As usual, if you encounter problems, reply here or open a bug report. I did enable a debug compile for this so you should be able to use gdb and have full symbols on a segfault backtrace or something. -Dan

1 0