Xavier wrote:
Well, I already didn't like this script in the first place, I found
the idea ugly.
I still had a look at it to check if it worked. And I see the
implementation is ugly as well, since it's based on -Qi output.
If you take a few steps back, what's happening is so stupid
From f08d8647274fc2c582005f9f0baebc114b2829cd Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Fri, 2 May 2008 00:32:45 +0200
Subject: [PATCH] One liner _alpm_pkg_find
This patch kills some code duplication.
Signed-off-by: Nagy Gabor [EMAIL PROTECTED]
---
lib/libalpm/package.c
Hi!
This may be a crazy idea, but I bring this on.
I've read some bugs on bug tracker, and I saw that your kernel is too
old sometimes. The problem is, that many users use custom
kernel (like me), that's why we cannot add 'kernel26=...' dependency
to glibc for example. However, some users
On Mon, May 05, 2008 at 04:40:46PM +0200, Nagy Gabor
[EMAIL PROTECTED] wrote:
old sometimes. The problem is, that many users use custom
kernel (like me), that's why we cannot add 'kernel26=...'
dependency to glibc for example.
s/the problem/your own personal problem/. why pacman would
Idézés Xavier [EMAIL PROTECTED]:
On Mon, May 12, 2008 at 4:00 PM, Dan McGee [EMAIL PROTECTED] wrote:
I thought the same thing- I saw a rewinddir call in db_scan, so I
removed what I thought was an extra one here. Either way, I don't plan
on applying the above patch, as we should just
Add SyncFirst option.
This patch offers a way to fix FS#9228.
By putting SyncFirst = pacman in pacman.conf, the version check will
happen before the transaction really starts, and before any replacements
is
made.
Otherwise, no version check is done.
Hi!
This is not a big issue, but memleaks are just ugly.
I mentioned this in the 2. point of my
http://bugs.archlinux.org/task/7884#comment25485 comment.
See pacman/query.c/query_upgrades(): The result of alpm_sync_sysupgrade just
printed but not freed (as I see, the front-end couldn't do it
@@ -861,7 +823,43 @@ int pacman_sync(alpm_list_t *targets)
return(sync_list(sync_dbs, targets));
}
- return(0);
+ if(targets == NULL) {
+ if(config-op_s_sync) {
+ return(0);
I may overlook something, but won't this break -Syu?
From cafa4977a0639ebb30ed20974ad86bf404ca5044 Mon Sep 17 00:00:00 2001
From: Xavier Chantry [EMAIL PROTECTED]
Date: Wed, 28 May 2008 23:25:40 +0200
Subject: [PATCH] Don't display filename on -Qip operation.
Some previous commits apparently broke the get_filename function for
package loaded
2008/6/2 Nagy Gabor [EMAIL PROTECTED]:
@@ -861,7 +823,43 @@ int pacman_sync(alpm_list_t *targets)
return(sync_list(sync_dbs, targets));
}
- return(0);
+ if(targets == NULL) {
+ if(config-op_s_sync) {
+ return(0);
I
Mon, 2 Jun 2008 14:23:49 +0200 -n
Xavier [EMAIL PROTECTED] írta:
On Mon, Jun 2, 2008 at 2:10 PM, Dan McGee [EMAIL PROTECTED] wrote:
On Mon, Jun 2, 2008 at 4:56 AM, Xavier [EMAIL PROTECTED] wrote:
From cafa4977a0639ebb30ed20974ad86bf404ca5044 Mon Sep 17 00:00:00
2001
From: Xavier Chantry
2008/6/20 Xavier [EMAIL PROTECTED]:
2008/6/20 Nagy Gabor [EMAIL PROTECTED]:
You may trust rpm guys, but don't forget that rpm based distros
usually use different versioning scheme, so '1.0b versus 1.0' is
not a real life example there:
alsa-lib-1.0.14-0.4.rc3.fc7.i386.rpm (Fedora
Yes. And in Xavier's link there is a Problems with Dependencies
paragraph. So it is required to minimize force/epoch in order to
calculate 'foo=1.3-1' dependencies correctly. Question: any foo
package with force will satisfy this. Right?
Wrong. alpm_depcmp uses versioncmp instead of
From 0320ac5dabb67813dfe64fddf31a371ec8934126 Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Tue, 1 Jul 2008 21:06:32 +0200
Subject: [PATCH] Don't duplicate packages in requiredby list
This is a fix for FS#10226.
I think that multiple versioned dependencies are quite common now
From cfe1de25873cf7d3d51a33682286f70e53733c4d Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Tue, 1 Jul 2008 22:53:13 +0200
Subject: [PATCH] New _alpm_dep_edge function
The function is introduced to kill some code duplication.
The funcion name uses the 'dependency graph
Now I ran into a problem: The front-end search for _all_ providers
(satisfiers), and will stop if more than one was found. This is not
compatible with resolvedeps behavior... So if we want to keep this, we
cannot share the code (but can re-implement first literal, then
satisfier).
To be more
Maybe you can just drop this behavior for now, because this is indeed
inconsistent with resolvedeps. Then if we want to reintroduce some
kind of handling of multiple satisfiers in the future, it should be
done for both explicit targets (which is currently done in frontend)
and dependency
From cfcaa50b83d6ce09a026e8275f19ce0665365e31 Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Wed, 2 Jul 2008 17:04:29 +0200
Subject: [PATCH] New sync070.py pactest
This pactest tests the cooperation between front-end and back-end in case of
-S provision operation.
Signed-off
From d199269813180d4a034fea54d025280aef3e4853 Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Fri, 4 Jul 2008 15:39:26 +0200
Subject: [PATCH] New _alpm_find_dep_satisfier function
This function finds the first satisfier package in a pkglist.
Using it instead
From 08ea7d37ae38f26d24ba2d3aba5f7272dee2ab73 Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Fri, 4 Jul 2008 20:18:00 +0200
Subject: [PATCH] Resolvedeps rework
I divided resolvedeps into 2 functions. The new _alpm_resolvedep function will
resolve one dependency,
for example
From 2adc17767b1af4e46502f21f5061e19d7a60a4b2 Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Sat, 5 Jul 2008 10:48:26 +0200
Subject: [PATCH] Remove requiredby from pactests
Also remove some meaningless pactests (broken requiredby, requiredby*.py tests)
requiredby001.py
From 6ef3a1f84dca7559506a6ab4b94b92c4ac746df6 Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Sat, 5 Jul 2008 11:08:03 +0200
Subject: [PATCH] Modify sync1003.py pactest
Now it tests a more interesting case.
(The old version failed with the new resolvedeps.)
Signed-off-by: Nagy
+pmpkg_t *alpm_resolvedep(pmdepend_t *dep, alpm_list_t *dbs,
alpm_list_t *excluding, pmpkg_t *tpkg);
Hm. This should be _alpm_resolvedep. Shall I resubmit the whole
patch? ;-)
___
pacman-dev mailing list
pacman-dev@archlinux.org
From 6541daa508b3f4d050db61f7212fcedf45ab0120 Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Sat, 5 Jul 2008 12:53:55 +0200
Subject: [PATCH] sync_addtarget rework
Now '-S provision' handling is done in the back-end.
In case of multiple providers, the first one is selected
From f96b366e8b0e2fb3a74e3647e5e07ecd5b78430e Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Sat, 5 Jul 2008 14:55:18 +0200
Subject: [PATCH] Add some verbosity to -S provision and -S group
sync_addtarget rework removed the warning: foo provides bar message
Hi!
Around this -S reworking, I looked into -R foo code, and I noticed
that we search for foo group, THEN literal... This forces pacman to
read all desc files. Wow. pacman -R group is not a common task...
You may say, that I'm cheating, because we will need to check
dependencies which loads the
From 7490b62443a0bd08a06fa3c97976a27de5b85665 Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Tue, 15 Jul 2008 01:07:22 +0200
Subject: [PATCH] _alpm_db_add_pkgincache rework
Commit 8240da6cb3ff95ad480efe3e1876104024398fae broke some alpm hierarchy
and introduced a new memleak
Idézés Dan McGee [EMAIL PROTECTED]:
On Tue, Jul 15, 2008 at 6:36 AM, Nagy Gabor [EMAIL PROTECTED] wrote:
From b9673a106b1f985cb81f620f394620e6eca88516 Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Tue, 15 Jul 2008 13:30:34 +0200
Subject: [PATCH] Fix some memleaks
On Wed, Jul 16, 2008 at 6:39 AM, Allan McRae [EMAIL PROTECTED]
wrote:
Nagy Gabor wrote:
2. Xav said, that deltas are broken. Couldn't we move this out from
alpm code, and using it XferCommand or whatever (or implement new
external helper, if needed)?
How broken are they? More
From cc336eb3e44038fa1f7416d3dc79fc6dbe9e0004 Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Wed, 16 Jul 2008 14:42:25 +0200
Subject: [PATCH] -Sqg and -Qqg
With --quiet, pacman -Sg grp and pacman -Qg grp don't list group names.
pacman -Qgq and pacman -Sggq (without targets
I've just tested -Qqg with the following command, and I got a
big segfault (debug.log attached):
# LANG=C src/pacman/pacman.static -Rus `src/pacman/pacman.static -Qqg
xorg gnome` --debug debug.log
# src/pacman/pacman.static -Qqg xorg gnome
xf86-input-keyboard
xf86-input-mouse
xorg-fonts-75dpi
From 7aff060a6288b250d398fb47abcb2aa26f05a508 Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Wed, 16 Jul 2008 15:27:37 +0200
Subject: [PATCH] Fix a possible segfault in alpm/remove.c
Before removing a package from target list (in remove_prepare_keep_needed),
we should check
From c44fec0058d8a69d29eeb947698bfaf165a6a080 Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Wed, 16 Jul 2008 15:57:08 +0200
Subject: [PATCH] alpm_list_remove treat NULL needle as nothing
So if you want to remove NULL needle from a list, alpm_list_remove will
return
One last mistake I just noticed is one untranslated message in
libalpm hungarian translation :
#, c-format
msgid removing '%s' from target list because it conflicts with
'%s'\n msgstr
Thx. Fixed.
Bye
hu.tar.gz
Description: GNU Zip compressed data
From 49899f082d6ccd52dc8164a5856353dd2a12ee20 Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Thu, 17 Jul 2008 12:15:29 +0200
Subject: [PATCH] New PM_TRANS_EVT_LDCONFIG events
User will see running ldconfig... message.
Signed-off-by: Nagy Gabor [EMAIL PROTECTED]
---
lib
From 49899f082d6ccd52dc8164a5856353dd2a12ee20 Mon Sep 17 00:00:00
2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Thu, 17 Jul 2008 12:15:29 +0200
Subject: [PATCH] New PM_TRANS_EVT_LDCONFIG events
User will see running ldconfig... message.
Signed-off-by: Nagy Gabor [EMAIL PROTECTED]
I
It indeed looks like we just need to handle the case where it runs out
of segments on one string.
But we have to handle two cases : run out of segments with the
-release number or without it.
So in both cases, I handle it differently if the last remaining
segment starts with a letter or not.
This note inspired me to test '1.0. == 1.0'
You may think that this is useless, but image '1.0 ' versus
'1.0' (extra spacebar, '\n' etc. character). The old code beats the
new one again :-P
I mean 3.1 vercmp code beats 3.2 vercmp code. Xav, your patch is
excellent. (And I just joked here, of
Hi!
I've tried -Su again...
I've just run into a very hard to fix error.
[EMAIL PROTECTED] ~]$ LANG=C sudo pacman -Su --ignore mplayer
...
xulrunner: /usr/include/xulrunner-1.9 exists in filesystem
xulrunner: /usr/lib/xulrunner-1.9 exists in filesystem
xulrunner: /usr/lib/xulrunner-devel-1.9
From 2433ae595f715847c38d6df312a4941d73ea39f2 Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Sat, 19 Jul 2008 16:34:02 +0200
Subject: [PATCH] Rephrase some debug messages in alpm/sync.c
Debug messages were removed from _alpm_sync_find, because it is a general
purpose function
Hm. I wasn't clear again.
Yes, the patch is fine, but I don't like it:
This is too specific. Tomorrow an other user will arrive that his
foo put bar directory to /var/lib/pacman.
Alternative I. (future):
This /var/lib/pacman root-cleanup was introduced because of the old
db format, and
Hi!
I've just discovered that ldconfig runs twice, if the sync transaction
creates a remove transaction too (%REPLACES%, conflict resolving).
IMHO we should move ldconfig call to trans.c to alpm_trans_commit.
Opinions?
Bye
___
pacman-dev mailing list
From c533684914d28407a0a7399e3026c747987d5de3 Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Mon, 21 Jul 2008 13:57:02 +0200
Subject: [PATCH] Re-enable --debug with -Sw and -Sp
Commit 874190827676e3a974e8c5fef6c51b9e9d6b60fa disabled --debug in these
cases. We just clear
On Sat, Jul 19, 2008 at 2:25 PM, Nagy Gabor [EMAIL PROTECTED]
wrote:
Hi!
I've tried -Su again...
I've just run into a very hard to fix error.
[EMAIL PROTECTED] ~]$ LANG=C sudo pacman -Su --ignore mplayer
...
xulrunner: /usr/include/xulrunner-1.9 exists in filesystem
xulrunner
From 92d5c1dbe3b1ecdb4a011a67a4c7719e240d861a Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Tue, 22 Jul 2008 12:48:59 +0200
Subject: [PATCH] New fileconflict004.py pactest
Thread: http://www.archlinux.org/pipermail/pacman-dev/2008-July/012465.html
Signed-off-by: Nagy Gabor
From ad3056757dcc675ee48324cf479b34a1c40dcd0c Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Tue, 22 Jul 2008 13:15:02 +0200
Subject: [PATCH] Update pactest README
Signed-off-by: Nagy Gabor [EMAIL PROTECTED]
---
pactest/README |4 +++-
1 files changed, 3 insertions(+), 1
Signed-off-by: Dan McGee [EMAIL PROTECTED]
:04 04 ea3e9f52732a5412f2e77e2a1060c3247636de7b
a234d7e4ca725edc301f696640d897ce54dfb3b8 Mlib
OMG. That part is totally unrelated here, but it makes our
fileconflict003.py pass (due to its bug);-). Obviously that won't
solve
OMG. That part is totally unrelated here, but it makes our
fileconflict003.py pass (due to its bug);-). Obviously that won't
solve our problem (unfortunately).
typo: fileconflict004.py
For example, this will fail:
self.description = foo
p1 = pmpkg(pkg1, 1.0-1)
Well, I am unable to understand that code, but maybe Nagy did, since
he was able to provide a (fileconflict005 ?) pactest which fails after
this patch :
http://archlinux.org/pipermail/pacman-dev/2008-July/012522.html
That pactest also triggers this %s is a symlink to a dir in previous
I was thinking of adding some kind of self.knownoutcome flag to
pactest, and have that basically suppress the return code incrementing
if it was set to fail or something. (or just
self.knownfailure=true.) Does that make sense to anyone? The problem
is right now we have no way of
-alpm_sync_newversion() function was introduced
___
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
Nagy, are you still interested by improving that list with your
suggestions :
http://archlinux.org/pipermail/pacman-dev/2008-July/012362.html
Yes. I am interested. IMHO 1/B came true in Allan's proposed NEWS file.
After alpm.h diff I have the following suggestions in API change (or
in
-alpm_deptest() function was introduced
___
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
On Wed, Jul 23, 2008 at 8:14 AM, Xavier [EMAIL PROTECTED] wrote:
On Wed, Jul 23, 2008 at 2:53 PM, Dan McGee [EMAIL PROTECTED]
wrote:
I think we should just put some jury-rigged, hopefully passes both
003 and 004 code in here and really attempt to fix this on the
larger scale post-3.2.
I think this is the only outstanding blocker:
http://archlinux.org/pipermail/pacman-dev/2008-July/012465.html
Thanks again for the quick translation updates and the NEWS updates
you guys contributed.
I will send a few patches from my working branch here for review, but
does anyone have
I just inform you that I warmed up my favourite bug-fix:
http://repo.or.cz/w/pacman-ng.git?a=shortlog;h=refs/heads/refresh_pkgcache
Bye
___
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
If you want to restore our old negligent eye-candy behaviour, you
can do the following (pseudo-code):
if(isdir(local_conflicting_stuff)
alpm_list_find_str(oldpkg-files,local_conflicting_stuff) {
continue; /*no conflict*/
}
I would say go ahead with the current code for the
Nagy Gabor wrote:
2.) - fix removing multiple items in dependency chain
I think this refers to 59295081982b33640f4e16589ef281872da540b5. In
this case we can remove this, -Ru is a celebrated new feature of
3.2, so this problem existed in git only (after ~pkgname_pkg_cmp
kill:-P
From 13c0673aa16f71c58ec5665c5832bb44717d08d7 Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Fri, 25 Jul 2008 14:35:54 +0200
Subject: [PATCH] New fileconflict005.py pactest
This makes the fileconflict004.py test complete.
Signed-off-by: Nagy Gabor [EMAIL PROTECTED
From 0605fcacee9da726dabf9e86b68a3bb3d3a44904 Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Sat, 26 Jul 2008 12:28:49 +0200
Subject: [PATCH] Remove UseColor from front-end
This option wasn't used.
Signed-off-by: Nagy Gabor [EMAIL PROTECTED]
---
src/pacman/conf.h |1
From 6f83f47c8545674b7c8e1c3178ac40b2ace44f3a Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Sat, 26 Jul 2008 12:46:22 +0200
Subject: [PATCH] pacman.conf (manual) changes
Document ILoveCandy, and set the default CleanMethod value.
Signed-off-by: Nagy Gabor [EMAIL PROTECTED
On Sat, Jul 26, 2008 at 12:50:06PM +0200, Nagy Gabor
[EMAIL PROTECTED] wrote:
+*ILoveCandy*::
+ Enables pacman game inspired progressbar.
I thought this was undocumented intentionally.
Yes, this is a funny, but musthave option. If this was a cheat code,
please adulterate the ML archive
From e81c8d333178e5180c771a0262dabe9aecb18eb0 Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Sun, 27 Jul 2008 12:27:50 +0200
Subject: [PATCH] Put CleanMethod to pacman.conf (commented out)
Signed-off-by: Nagy Gabor [EMAIL PROTECTED]
---
etc/pacman.conf.in |1 +
1 files
Dan complained several times that the README file was long outdated,
so I tried to improve that.
I hope I did not make it worse :/
As always, help/feedback is appreciated.
Wow. I like it, especially the API changes part ;-).
I can see some formatting issues:
-2 empty line between [REMOVED]
One last problem : the pacman.conf needs to be updated.
Most important points :
1) remove unstable mirror section
2) add SyncFirst
This may be an overkill, but this can be mentioned in .INSTALL file
too, because user may omit pacman.conf.pacnew. Or give a general
message: New options were
On Fri, Jul 25, 2008 at 4:03 AM, Xavier [EMAIL PROTECTED] wrote:
On Fri, Jul 25, 2008 at 10:35 AM, Nagy Gabor
[EMAIL PROTECTED] wrote:
I just inform you that I warmed up my favourite bug-fix:
http://repo.or.cz/w/pacman-ng.git?a=shortlog;h=refs/heads/refresh_pkgcache
I had
On Wed, Jul 30, 2008 at 12:14 PM, Nagy Gabor [EMAIL PROTECTED]
wrote:
One last problem : the pacman.conf needs to be updated.
Most important points :
1) remove unstable mirror section
2) add SyncFirst
This may be an overkill, but this can be mentioned in .INSTALL file
too, because
From 84218a43d0a455a29b9312d43270ddf8bb78600d Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Wed, 30 Jul 2008 23:36:46 +0200
Subject: [PATCH] Pass the old package with PM_TRANS_EVT_UPGRADE_START
This is more rational and coherent with PM_TRANS_EVT_UPGRADE_DONE.
Signed-off
On Thu, Jul 31, 2008 at 5:04 AM, Nagy Gabor [EMAIL PROTECTED]
wrote:
-
commit fabf7ad6c4d9e0a45bf0957d93d810a361db7418 Author: Dan McGee
[EMAIL PROTECTED] Date: Wed Jul 30 19:28:07 2008 -0500
Version bumps
Hi!
Try pacman -Qi audacious-plugins
Each optdepend : feature should be in its own line.
Bye
___
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
On Thu, Jul 31, 2008 at 6:44 AM, Xavier [EMAIL PROTECTED] wrote:
But Nagy also had it reversed. It should be Gabor Nagy.
And we should call him Gabor, like we use Xavier, Roman, Aaron or
Dan. Weird stuff :)
Woah, I didn't know that at all! Sorry about that, Gabor, I thought
Nagy was
From 88ca14b8e7d4c53d886bc7397adbbf6c8a338c5d Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Sun, 17 Aug 2008 18:32:39 +0200
Subject: [PATCH] New public alpm_pkg_get_db function
This function returns with the origin database of a package.
Signed-off-by: Nagy Gabor [EMAIL
/* We don't care about conflicts if we're just printing uris
*/
This commit will be also removed in my git repo.
___
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
From 7e7e2b74ff03dc0656879ed9ae6f171a82194ea4 Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Sun, 17 Aug 2008 21:26:49 +0200
Subject: [PATCH] Remove an usused variable from alpm/util.c/_alpm_lckmk()
Probably a tweakable lockdb-retry option was planned which is not
implemented
A fix on my maint-working branch
http://shining.toofishes.net/gitweb/gitweb.cgi?p=pacman.git;a=commit;h=962a9c7d8e14d0fc20a7793776fd60f8d0619a07
A fix on my working branch
http://shining.toofishes.net/gitweb/gitweb.cgi?p=pacman.git;a=commit;h=0edb8646096b83e20b704f8df47cc117025517ea
Both
On Fri, Aug 22, 2008 at 12:03 PM, Xavier [EMAIL PROTECTED] wrote:
This issue has been known for ages, and it is easy to fix it, so I
would like to do it.
http://archlinux.org/pipermail/pacman-dev/2008-May/011885.html
Example of a bogus output taken from the forums (the thread does not
On Fri, Aug 22, 2008 at 2:56 PM, Nagy Gabor [EMAIL PROTECTED]
wrote:
First, thanks for the feedback!
0. I don't like this _alpm_pkg_compare_versions() function at all,
it has some annoying warning messages (why is the forcing
upgrade... message important?), these reduce its
The Hungarian translation is attached.
Bye
hu.tar.gz
Description: GNU Zip compressed data
___
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
Hi!
Here's a fix for cosmethic bugs I found during translating pacman.
From 3784d9cb45bc96d8d6d0120a89c1f24e58f60ee6 Mon Sep 17 00:00:00 2001
From: Roman Kyrylych [EMAIL PROTECTED]
Date: Mon, 25 Aug 2008 17:20:03 +0300
Subject: [PATCH] Added a couple of missing commas to help messages
The problem seems to be that in the old package
/usr/lib/klibc/include/asm is a symlink to another directory which
contains these files. In the new package, this symlink is replaced by a
directory. pacman thinks that there are file conflicts, while there are
none. I cannot find a viable
Idézet Nagy Gabor [EMAIL PROTECTED]:
The problem seems to be that in the old package
/usr/lib/klibc/include/asm is a symlink to another directory which
contains these files. In the new package, this symlink is replaced by a
directory. pacman thinks that there are file conflicts, while
Hi!
I think you misinterpret something.
This can be a bad thing when the user installs the packages
--asdeps because no package states the dependencies on them, but they
are needed/wanted for some reason. (Often this means the dependent
package misses a dependency and this package should
This seems more like an issue with dependency resolution than anything
else. Assuming this is all based on issues with optdepends, like so:
$ pacman -S foobar
Optional dependencies for foobar:
baz
$ pacman -S --asdep baz
What we have here is 'baz' indicated as an orphan, but what we *want*
On Fri, Oct 24, 2008 at 12:00 PM, Nagy Gabor [EMAIL PROTECTED] wrote:
http://repo.or.cz/w/pacman-ng.git?a=shortlog;h=refs/heads/working
I know you may not like this way (free functions public), but IMHO the
result is not so ugly ;-)
Can we just expose something more like free_conflictlist
On Thu, Oct 30, 2008 at 2:17 AM, Hugo Doria [EMAIL PROTECTED]
wrote:
http://bugs.archlinux.org/task/11846
I have nothing to add to what Nagy said there. He gave the link to a
discussion on the ML about how to implement this differently, in a
better way, which would also fix this bug.
Hey guys,
I would *love* it if someone could take this patch and run with it. I
really just wanted to hash out a possible fix, but unfortunately it
isn't easy for two reasons: our code structure is a bit rough, and we
really don't have a hard-and-fast set of rules for continuing or
failing
Hmm, this isn't quite what I expected either. Can we clean up this
garbage in any way?
$ ./src/pacman/pacman -Qu
warning: alsa-lib: local (1.0.17a-2) is newer than extra (1.0.17a-1)
warning: gvim: local (7.2.25-1) is newer than extra (7.1.330-1)
warning: namcap: local (2.1-2) is newer than
Hi all,
Im trying to add some downgradability magic into pacman .Being quite
new to pacman code, i need your help to identify the possible
pitfalls of my approach before trying something.
What i plan to do is..
In libalpm/remove.c unlink_file() [ I guess remove.c is the only
place where we
: http://horde.org/imp/
From 962ccd09c7afc59a19045e353b4fbd4711414720 Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Sun, 9 Nov 2008 17:34:49 +0100
Subject: [PATCH] New error type: PM_ERR_PKG_IGNORED
This patch fixes FS#12059.
Now sync_addtarget can return with PM_ERR_PKG_IGNORED
Idézet Xavier [EMAIL PROTECTED]:
On Fri, Nov 14, 2008 at 1:02 PM, Nagy Gabor [EMAIL PROTECTED] wrote:
I guess I spoke to soon. I was right concerning xdelta3 using gzip for
handling gzipped files, however it doesn't use the -n flag. This gives
us the same behaviour as xdelta1, with one minor
From 8e11e0c7198f7c7bdeb6ca76d647d4831593b965 Mon Sep 17 00:00:00 2001
From: Nagy Gabor [EMAIL PROTECTED]
Date: Mon, 17 Nov 2008 17:02:43 +0100
Subject: [PATCH] Give an error message on alpm_db_register_sync() error
This patch slightly modifies pacman.c/_parseconfig():
See FS#12148. Now
Omg, you can find my patch here: http://repo.or.cz/w/pacman-ng.git
Bye
___
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
This is an attempt to add a one-file-per-database backend. This leads to
significatly faster loading of the database when the database is not
cached. As you can see from the patch minimal changes to the rest of
ALPM was needed. The only change was to make reading of the changelog
files happen
From 01ba4fce1e7bf2c6058074c583e5db5147d31f02 Mon Sep 17 00:00:00 2001
From: Nagy Gabor ng...@bibl.u-szeged.hu
Date: Fri, 2 Jan 2009 17:43:05 +0100
Subject: [PATCH] Fix for trans001.py (FS#9088)
From now on _alpm_db_find_fileconflicts() works with upgrade and remove
target lists (like checkdeps
Translation is attached.
pacman-hu.tar.gz
Description: GNU Zip compressed data
___
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
From e00884ab554562fa5e6ac601aa99477e0f70cd75 Mon Sep 17 00:00:00 2001
From: Nagy Gabor ng...@bibl.u-szeged.hu
Date: Sat, 10 Jan 2009 16:25:03 +0100
Subject: [PATCH] db-pkgcache_loaded and db-grpcache_loaded
Clearly the old code was more elegant (NULL cache indicated not loaded),
but it had some
No. pkg-depends or alpm_pkg_get_depends(pkg) is used to get the
dependency list of pkg. In the old code it was easy to determine if a
dependency is broken. If we couldn't find a satisfier package in the
target list or in the local database (which won't be upgraded), we
simply detected that this
It sounds good, but isn't it a bit a step backward after this :
http://projects.archlinux.org/?p=pacman.git;a=commit;h=72c0ab5c51d5119b6f81c768b1a0f6ff499df292
However, we were not considering this new behavior in case of
unresolvable dependency back then.
We should decide, whether we want
This discussion is motivated by FS#11737.
A replacement is nothing more than a simple upgrade with package name
change. (This is plausible, but we don't really follow this principle
atm.) So if we moved our find_replacments code to sync_newversion our
code would be more readable [1].
Benefits:
From 2b1a58bda8318b7d0c70a4cfc161a82a156b199b Mon Sep 17 00:00:00 2001
From: Nagy Gabor ng...@bibl.u-szeged.hu
Date: Sun, 18 Jan 2009 20:03:56 +0100
Subject: [PATCH] Use archive_entry_set_perm instead of archive_entry_set_mode
This patch fixes FS#12148 ('unstable' regular file).
I also changed
1 - 100 of 226 matches
Mail list logo
