On Thu, Feb 23, 2006 at 11:12:30PM +0100, Aurelien Foret
the sync.c patch contains two hunk: a workaround for the conflict.c problem and a compile fix (would it be a big problem not to mix compile fixes and workarounds?) if you revert the workaround, and apply this patch: http://frugalware.org/~vmiklos/patches/libpacman-proposed/syncfix.diff i hope the test will pass again (this time without the workaround)
Which sync.c patch are you mentioning?
ah, sorry, i run cvs diff -u -r 1.65 sync.c, not cvs diff -u -r 1.65 sync.c so i got a patch that included two revisions Judd: would it be a big task to include pacman-lib in the cvsweb interface? :) (<flame>man, after darcs, using centralized version control systems are so annoying ;) </flame>)
If it's my patch (sync.c 1.65-1.66), there's only one hunk There's no compile fix in it, just a fix to avoid a segmentation fault.
If it's your patch, there are 3 hunks... You're basically switching "j" and "k", and it fixes the issue by chance because you forgot to also switch "j" and "k" at line 159. With your patch applied, at line 159, j->data has become a (pmpkg_t *) that will for sure never make strcmp return 0...
Anyway, I think the issue comes from the _alpm_depmiss_new declarations for CHECK3 that are switching tp->name and info->name. I'm attaching a patch based on yours fixing that point.
Thoughts?
seems ok to me udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org