python-aptdaemon.pkcompat cannot resolve some packages

[Michael Rawson]

sudo ./dbbuild -d /var/cache/lsc-vala.db
Collecting app-install data...
Querying PackageKit...

** (dbbuild:28222): ERROR **: dbbuild.vala:207: Error: Package name ardour-i686 could not be resolved.

Does not happen with packagekit-backend-aptcc but happens with python-aptdaemon.pkcompat

[Stephen Smally (stephen-smally)]

can you please post "apt-cache show ardour-i686"?

[Michael Rawson (michael.rawson)]

michael@laptop:~$ apt-cache show ardour-i686
Package: ardour-i686
Priority: optional
Section: universe/sound
Installed-Size: 13211
Maintainer: Ubuntu Developers <email address hidden>
Original-Maintainer: Debian Multimedia Maintainers <email address hidden>
Architecture: i386
Source: ardour
Version: 1:2.8.12+svn12923-1
Replaces: ardour, ardour-gtk-i686
Provides: ardour
Depends: libart-2.0-2 (>= 2.3.19), libasound2 (>= 1.0.16), libatkmm-1.6-1 (>= 2.22.1), libaubio2, libc6 (>= 2.15), libcairo2 (>= 1.2.4), libcurl3-gnutls (>= 7.16.2), libfftw3-3, libgcc1 (>= 1:4.1.1), libglib2.0-0 (>= 2.12.0), libglibmm-2.4-1c2a (>= 2.32.0), libgnomecanvas2-0 (>= 2.11.1), libgnomecanvasmm-2.6-1c2a (>= 2.23.1), libgtk2.0-0 (>= 2.18.0), libgtkmm-2.4-1c2a (>= 1:2.24.0), libjack-jackd2-0 (>= 1.9.5~dfsg-14) | libjack-0.116, liblilv-0-0 (>= 0.14.2~dfsg0), liblo7 (>= 0.26~repack), liblrdf0, libpango1.0-0 (>= 1.14.0), libpangomm-1.4-1 (>= 2.27.1), libsamplerate0 (>= 0.1.7), libsigc++-2.0-0c2a (>= 2.0.2), libsndfile1 (>= 1.0.20), libstdc++6 (>= 4.6), libusb-0.1-4 (>= 2:0.1.12), libvamp-hostsdk3, libvamp-sdk2, libxml2 (>= 2.7.4), python, python-twisted, python-gtk2, jackd
Recommends: firefox | www-browser
Conflicts: ardour, ardour-gtk-i686
Filename: pool/universe/a/ardour/ardour-i686_2.8.12+svn12923-1_i386.deb
Size: 4801696
MD5sum: 22ef87803195599df8c712a598c72a6a
SHA1: 9c59fbf67268b05f80f6f93a4b72cc834db3e5ad
SHA256: e4e65af68667e01598e9aa2e01217b156aca46396c2dcc32231012924bec8297
Description-en: digital audio workstation (graphical gtk2 interface) [i686]
 Ardour is a multichannel hard disk recorder (HDR) and digital audio
 workstation (DAW). It can be used to control, record, edit and run
 complex audio setups. For more information see the description
 of the ardour package or <http://ardour.org/>.
 .
 This package is optimized for i686 and will not run on
 subarchitectures that don't support features enabled in i686.
 It might fail with weird error SIGILLs and other non-obvious failures.
 Please refrain from filling bugs to the upstream author about this package
 that are not reproducible in the non-optimized package.
Homepage: http://www.ardour.org/
Description-md5: 56ca7588e4deecaa1aa61faf29504de8
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu

michael@laptop:~$

[Stephen Smally (stephen-smally)]

It's a strange error, by the way should be fixed in trunk

[Michael Rawson (michael.rawson)]

Thanks, I'll pull and try again.

[Michael Rawson (michael.rawson)]

Now it doesn't crash (still shows error, but continues), but it doesn't build the database (no disk write, and the software centre shows no elements.

[Stephen Smally (stephen-smally)]

Are you sure you are building the database in the right location? what architecture are you on?

[Michael Rawson (michael.rawson)]

Freshly pulled this morning, still the same problems.

michael@laptop:~/code/light-software-center/db-build$ sudo ./dbbuild -d /var/cache/lsc-vala.db
Collecting app-install data...
Querying PackageKit...

(dbbuild:8350): Error: %s
-WARNING **: dbbuild.vala:207: Package name ardour-i686 could not be resolved.
Done, no error reported

And no packages in the software centre. That is the right location, right?

[Michael Rawson (michael.rawson)]

Oops, forgot. I'm on 64-bit Ubuntu Quantal. This doesn't happen on 32-bit Lubuntu Precise.

[Michael Rawson (michael.rawson)]

Okay, I removed the app-install entry for ardour-i686, it then moved on to various other packages. I stopped after a few. I could theoretically install all of them.

[Stephen Smally (stephen-smally)]

It seems an aptcc (backend for packagekit) bug that they shoudl have solved ( https://launchpad.net/ubuntu/quantal/+source/packagekit/+changelog ):

- aptcc: Fix a multiarch bug that failed to resolve packages
        (Daniel Nicoletti)

since you are on 64bit and ardour is for i386, it seems related to this. try to rebuild all when you have packagekit 0.7.4-2 or later.

[Michael Rawson (michael.rawson)]

michael@laptop:~$ apt-cache policy packagekit
packagekit:
  Installed: (none)
  Candidate: 0.7.4-4ubuntu2
  Version table:
     0.7.4-4ubuntu2 0
        500 http://ubuntu.retrosnub.co.uk/ubuntu/ quantal/universe amd64 Packages
michael@laptop:~$

..regression?

[Stephen Smally (stephen-smally)]

make sure you are using packagekit-backend-aptcc.

[Michael Rawson (michael.rawson)]

Okay, that tried to remove something to do with ubuntu-drivers...I'll stick to testing on precise for now. XD

[Sergey "Shnatsel" Davidoff (shnatsel)]

Ubuntu uses python-aptdaemon.pkcompat by default instead; it bridges PackageKit interfaces into much more modern AptDaemon. See https://launchpad.net/aptdaemon for advantages over packagekit-backend-aptcc

So it seems that that's a bug in python-aptdaemon.pkcompat now.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Sergey "Shnatsel" Davidoff (shnatsel)]

By the way I've got the same error for package "qtodo", see bug 1023808
So maybe this bug is not exclusive to multiarch.

[Matthias Klumpp (ximion)]

Hi!
That is not the fault of PackageKit, the compat layer is wrong and Ubuntu does some extremely crappy things, e.g. forcing the PyApt-backend in Ubuntu-Drivers, which is totally broken and has been removed (again) from distribution. (We weren't able to ship it in Debian with RC bugs)
Btw, Aptdaemon is *not* much more modern than PK ;-) There's only one advantage of Aptd at time, and we're working on PK to solve this issue. (However, Aptd can expose some advanced Apt features on DBus, which PK can't, but that is irrelevant for Software Centers) - Of course, read this as an opinion of a PackageKit developer. ;-)
I'll send message to ubuntu-drivers, so they can fix their dependencies and probably add possible missing features to Aptcc.
If you have further questions, please ask (I'm subscribed here now)
Cheers,
   Matthias

[Matthias Klumpp (ximion)]

Oh, btw: It appears that you're creating a completely new SQL db from raw data... It would probably make more sense and be a little bit faster to use the original Xapian database, as discussed in our AppStream[1] meeting. Unfortunately, the generator code to build the DB from AppStream XML or Apt package data is closely integrated with the Ubuntu Software center. I'm doing lots of work on PackageKit at time to make cross-distro software centers possible, and I also work on the cross-distro fork of the USC. (required because of Canonicals CLA to make contributions from Red Hat, SuSE and others possible) As the next step I will probably create an independent Xapian generator, written in C++. (I'd love to use Vala, but there are no C bindings for it...) If work starts on that, I can notify you. Using Xapian from Vala should also work by creating some glue code. Positive effect: Software center becomes distro-agnostic, at least if you use PackageKit bindings and not Aptd specifics.
Bye!
---
[1]: http://distributions.freedesktop.org/wiki/AppStream

[Stephen Smally (stephen-smally)]

I never used Xapian, so i don't know how to implement a database with
it, also there are no bindings...

[Sergey "Shnatsel" Davidoff (shnatsel)]

Mattias, thanks a lot for clearing that up! I've erroneously tracked down python-aptdaemon.pkcompat to packagekit ubuntu package and thus marked it affected. Reassigned to aptdaemon package now :)

I've hit up the aptcc changelog linked above and it seems it did improve greatly since last time I checked it, so I take that back. I wonder if any PackageKit APT backend now supports installing packages that require downgrading/removal of other packages and what the one remaining advantage of AptDaemon is.

[Matthias Klumpp (ximion)]

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 multiple actions at the same time (e.g. run GetDetails() while a InstallPackages() transaction is running), this resulted in rewriting large parts of the backend API.
For packages which require removal of other packages, Aptcc has mechanisms and that works really well at time. (introduced a loong time ago with the Simulate* methods) Downgrading packages is not yet possible, but planned. (we just haven't had a user who asked for this yet, so it has a lower priority ^^)
Aptcc is excellent at time, and it is one of the best-maintained backends PK has. Kudos to Daniel! Btw, I wonder where Sebastian Heinlein (glatzor) is to comment on this issue.... Nobody seems to have seen him for weeks...
Anyway, I filed the PK breakage as bug #1023953 , so PK installations should work fine again soon.
Regarding Xapian, let's see what we'll have soon. Writing the generator is on my todo-list, and if there are no other more important changes to do on the Software Center, I'll work on that soon. (And probably in Vala, not sure about the language yet) - right now, SQL is a viable solution too. (It's a pity AppStream progressed so slowly...)
If Ubuntu Quantal gets PackageKit 0.8.x (one PK from the 0.8 series), we'll have lots of great new features for everyone to test. But this step will need coordination with people at Ubuntu, otherwise it will break your compat-layer. (need to find someone responsible for making these decisions later, when 0.8.x is ready)

[Sergey "Shnatsel" Davidoff (shnatsel)]

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 the whole database in SQLite?

[Matthias Klumpp (ximion)]

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 problems every cache has, and it slows down PackageKit refresh sctions.
Cheers,
   Matthias

[Sebastian Heinlein (glatzor)]

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? Which PPA did you use?

Cheers,

Sebastian

[Sergey "Shnatsel" Davidoff (shnatsel)]

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?

[Matthias Klumpp (ximion)]

@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!)