Hello,
@Matthias, I was travelling around in the wilderness of Canada for some
time. But thanks that you noticed my disappearance :)
Could you please narrow down the error a little bit and how it affects
aptdaemon.
Is the problem that you don't get the ardour-i686 package on a am64
system?
The package data reads Origin: Ubuntu, so it's not a PPA package.
The bug looks identical to the one in PackageKit itself that could not resolve
multiarch packages.
Stephen, could you tell us what exactly LSC is doing there?
--
You received this bug notification because you are a member of
@Sebastian: Indeed, we needed you here ;-) But we knew where you have
been, so nobody tried to rech you. I hope you had a great trip! (But I'm
sure it was great - Canada is awesome!)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
So Matthias wrote the standalone Xapian index generator:
http://blog.tenstral.net/2012/08/gsoc-appstream-final-report.html
Perhaps we should migrate to it instead of building a duplicate DB.
Also he mentions an sql cache for package data... I wonder why would we
need an SQL cache if we can have
Even the original Software Center might switch to the new XDG lib, when it's
stable for performance reasons. (C vs. Python)
The SQL-cache is only an experiment whil allows requesting package-state.data
pretty fast. We don't use it anywhere at time, because it suffers from
synchronisation
Hi!
Aptd can do some things faster by handling the cache smarter and - because it
does not try to be distro-agnostic - can rely on client tools accessing the Apt
db directly, while PackageKit sends everything over a DBus connection.
We're working on making it possible for PackageKit to execute
