VMiklos wrote:
i would say if the problem is with the patch that improves conflict.c, then why not fixing conflict.c and adding a workaround to sync.c if possible?
Sure.
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? 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?
something partially unrelated: would it be difficult to add an option to pactest to run "fakeroot libtool gdb --args" instead of "fakeroot" and in that case not to redirect the output? for now i've hardwired that here, but that's not a sollution :)
Added to the TODO. Thanks -- Aurelien