On Thu, Nov 20, 2008 at 12:43 AM, Dario Freddi drf54321@gmail.com wrote:

Hello guys,

I'm introducing you Aqpm, a QT/C++ wrapper to libalpm. I did this since Shaman backend was starting to get too much bloated, and since I needed to use Alpm in some other apps (and in Shaman 2 too).

What's cool about it: I aim at a strong binary compatibility. This way, even when alpm introduces some binary-incompatible changes, modifying Aqpm internals will be enough to get all applications relying on Aqpm work again without a rebuild. This way we'll also avoid bad situation like Shaman crack this summer.

It also wraps around the callback system and implements an easier Queue. It has solid internal threading where needed, and I'm planning to make it support PolicyKit, so that I'll also get rid of the problem of running Shaman with suid and other apps using Alpm running as root (even though Policykit could be directly added to alpm itself, I don't know).

Enough talking, it's here: http://github.com/drf/aqpm/tree/master. If you want to test it, I moved Shaman to github and I have a branch there working with aqpm: http://github.com/drf/shaman1/tree/aqpm-work . Sure, it has some regressions, but really small stuff. Please note that Aqpm at the current status supports latest git revision of alpm, so it is not compilable with current stable pacman.

I am writing you also to ask you for some help. I have one problem since libalpm 3, namely the download progress callback streaming always 0 in the "total" parameter. I got almost crazy over it, and I still can't find a reason why it does not work. I verified that when Alpm streams the callback, the value is correct, though when it gets received it becomes 0.

So I kindly ask you a small review of my code, since I really don't know where to crash my head. It is the last missing bit to aqpm to work 100%, so I'd really appreciate if you could give some help. The relevant code is at:

http://github.com/drf/aqpm/tree/master/trunk/libaqpm/Backend.cpp line 797-1010 (Transaction thread, but in that file you'll find every action aqpm does)

http://github.com/drf/aqpm/tree/master/trunk/libaqpm/callbacks.cpp Callbacks are here.

Also some feedbacks/suggestions would be highly appreciated

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 :)

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...

Do you have this problem on both architectures? 686 and x86_64? Also you could maybe try to play with different types on the libalpm level. changing off_t to size_t or things like that.

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.