Comment 13 for bug 1025381

The code pointed to by the trace is the get_vendor method in canonical/certify/model/device.py. It has this:

if vendor_id is not None:
            vendor = store.get(DeviceVendor, (self.id, vendor_id,))
            if not vendor:
                if vendor_name:
                    vendor = DeviceVendor(self, vendor_name, vendor_id)
                    vendor = store.add(vendor)
                    store.flush()
                else:
                    vendor = None
elif vendor_name:
            vendor = store.find(DeviceVendor,
                DeviceVendor.bus == self,
                DeviceVendor.vendor_id > DEVICE_MAX_ID,
                DeviceVendor.name == vendor_name).one() #This is where the bug hits
            if not vendor:
                vendor = DeviceVendor(self, vendor_name)
                vendor = store.add(vendor)
                store.flush()

The reason why Marc was unable to reproduce is that, on my attempts with Juergen's submission, I managed to make c3 create the vendor in question (apparently a new, never-seen-before one: "USB 2.0" - lame vendor if you ask me). So when he ran it, he hit instead the "if" clause which works correctly, rather than the elif one that fails.

To test this theory, I edited the submission.xml file to invent a new vendor with the same "faily" characteristics as the one Juergen had. I modified line 7451 to change:

E: ID_VENDOR_ENC=USB\x202.0

for:

E: ID_VENDOR_ENC=TESTUSB\x202.0

I then ran checkbox-certification-submit and got the failure again.

I then changed it to:

E: ID_VENDOR_ENC=TESTUSB\\x202.0

This worked correctly and created the TESTUSB\x202.0 vendor. I then moved the ID_VENDOR_ENC back to the failing version:

E: ID_VENDOR_ENC=TESTUSB\x202.0

And *now* I was able to re-submit the result because the vendor exists and is found by id rather than by name.

Anyway, convoluted, but this seems to be what happens and to reproduce it, you can change that particular ID_VENDOR_ENC to something that's not already in the database.