On Saturday 27 December 2008 19:29:31 Xavier wrote:
In answer to http://bbs.archlinux.org/viewtopic.php?id=61794 :
You were not ignored, it is just that you mentioned this error to us in the past : http://bugs.archlinux.org/task/11355 The conclusion seemed to be that the bug was not in libalpm and that you would find the error yourself. Apparently this was not the case :)
Thanks for the answer. I apologize for such an irruent reaction anyway, realized that just after the post, so sorry once again.
I am completely clueless about what could go wrong there. I had a look several times at your code and never saw anything wrong. Though I never did more than reading the code. Also you said that alpm apparently gives the correct value, so it seems there is not much we can do from our side. But then I have no idea how it could get lost...
What I can try to do is attach gdb and see what happens to that value.
Do you have this problem on both architectures? 686 and x86_64?
Yeah
Also you could maybe try to play with different types on the libalpm level. changing off_t to size_t or things like that.
I'll surely try this now.
One funny thing I noticed is that the call is the following : handle->dlcb(filename, dl_thisfile, ust.size); with dl_thisfile size_t and ust.size off_t and the type of the function is this : typedef void (*alpm_cb_download)(const char *filename, off_t xfered, off_t total);
So we have a type mismatch for the xfered parameter, but not for the total parameter. Yet you only have problems with total :P So it is probably not the problem, but it is still something worth playing with.
I really didn't notice that... it definitely could be. I'll try again and report as soon as I find out something. Cheers Dario
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev