[pacman-dev] Aqpm, and some help needed

[Xavier]

On Thu, Nov 20, 2008 at 12:43 AM, Dario Freddi <drf54321 at 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.