- Pacman-dev - lists.archlinux.org

[pacman-dev] [GIT] The official pacman repository branch, maint, updated. v3.1.1-8-gc028014
by Dan McGee 02 Feb '08

02 Feb '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 c028014f96911930bf3b7dce08c0fe997cedfc69 (commit) from 0775c38e72c06b9ad428c4e6dbfd0b6f0cda2818 (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 c028014f96911930bf3b7dce08c0fe997cedfc69 Author: Dan McGee <dan(a)archlinux.org> Date: Sun Jan 27 21:06:28 2008 -0600 makepkg: ensure binaries in /opt/* are stripped The path selection for stripping binaries was slightly off, so any binaries in subdirectories of opt/ were missed. Fixes FS#9342. Signed-off-by: Dan McGee <dan(a)archlinux.org> ----------------------------------------------------------------------- Summary of changes: scripts/makepkg.sh.in | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] is newer than messages
by Karolina Lindqvist 02 Feb '08

02 Feb '08

What is the purpose of the messages "is newer then", from pacman -Su? Can't they please be removed in the normal case? Is there anyone who need them? They look like debug messages to me. $ sudo pacman -Su :: Starting full system upgrade... warning: attr: local (2.4.39-2.1) is newer than core (2.4.39-2) warning: kdebase: local (3.5.8.20080105-1) is newer than extra (3.5.8-3) warning: kdelibs: local (3.5.8.20080105-2) is newer than extra (3.5.8-4) warning: kernel26: ignoring package upgrade (2.6.23.14-1 => 2.6.24-2) warning: lirc: local (0.8.3-0.20080113) is newer than testing (0.8.2-10) warning: lirc-utils: local (0.8.3-0.20080113.1) is newer than extra (0.8.2-1) warning: tellico: local (1.3-1) is newer than community (1.2.14-1)

2 1

[pacman-dev] pamcan don't show the size of invididual package in remove list and 'Total remove size:' in operation -R
by Vojtěch Gondžala 31 Jan '08

31 Jan '08

Hi all, I think something like this: --------- # pacman -Rc amarok-engine-xine loading package data... done. checking dependencies... Targets: amarok-base [28.60 MB] amarok-engine-xine [0.21 MB] Total Removed Size: 28.81 MB Do you want to remove these packages? [Y/n] ---------- and ---------- # pacman -S qca2 resolving dependencies... looking for inter-conflicts... :: qca2 conflicts with qca. Remove qca? [Y/n] Remove: qca [2.94 MB] Total Removed Size: 2.94 MB Targets: qca2-2.0.0-1 [0.66 MB] Total Download Size: 0.00 MB Total Installed Size: 1.92 MB Proceed with installation? [Y/n] ---------- in attachment is patch for this --vogo

3 2

Re: [pacman-dev] pamcan don't show the size of invididual package in remove list and 'Total remove size:' in operation -R
by Vojtěch Gondžala 31 Jan '08

31 Jan '08

> This is already implemented for -S and -Q (see > http://bugs.archlinux.org/task/6667) > Add ShowSize option to pacman.conf. > So this should be just extended to support -R. > > -- > Roman Kyrylych (Роман Кирилич) no wholly in -S, see this line without patch: :: qca2 conflicts with qca. Remove qca? [Y/n] Remove: qca <<<<< Total Removed Size: 2.94 MB with patch: :: qca2 conflicts with qca. Remove qca? [Y/n] Remove: qca [2.94 MB] <<<<< Total Removed Size: 2.94 MB --vogo

2 1

[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