launchpad_dogfood=> SELECT spr.version, spr.dsc_binaries FROM sourcepackagename spn, sourcepackagerelease spr WHERE spn.id = spr.sourcepackagename AND spn.name = 'acl';
version | dsc_binaries
------------------------+---------------------------
2.2.39-1ubuntu1 |
2.2.49-4ubuntu2 | acl, libacl1-dev, libacl1
2.2.45-1 | libacl1-dev, libacl1, acl
2.2.39-1ubuntu2 |
2.2.41-1ubuntu1 |
2.2.42-1ubuntu1 | libacl1-dev, libacl1, acl
2.2.49-4 | acl libacl1-dev libacl1
2.2.49-3 | acl, libacl1-dev, libacl1
2.2.49-5 | acl libacl1-dev libacl1
2.2.49-3-1cross1 | acl, libacl1-dev, libacl1
2.2.49-3-1cross2 | acl, libacl1-dev, libacl1
2.2.49-4 | acl, libacl1-dev, libacl1
2.2.49-4ubuntu1 | acl, libacl1-dev, libacl1
2.2.23-1 |
2.2.26-1 |
2.2.29-1 |
2.2.34-1 |
2.2.34-1ubuntu1 |
2.2.48-1 | acl, libacl1-dev, libacl1
2.2.49-5ubuntu1 | acl, libacl1-dev, libacl1
2.2.51-1 | acl, libacl1-dev, libacl1
2.2.51-1 | acl libacl1-dev libacl1
2.2.51-2 | acl libacl1-dev libacl1
2.2.47-3 | acl libacl1-dev libacl1
2.2.47-2 | acl, libacl1-dev, libacl1
2.2.47-2 | acl libacl1-dev libacl1
2.2.47-2-100~ppa1 | acl, libacl1-dev, libacl1
2.2.48-1 | acl libacl1-dev libacl1
2.2.47-2ubuntu1~cross1 | acl, libacl1-dev, libacl1
2.2.49-1 | acl libacl1-dev libacl1
2.2.49-1 | acl, libacl1-dev, libacl1
2.2.49-3 | acl libacl1-dev libacl1
2.2.49-2 | acl libacl1-dev libacl1
2.2.49-2 | acl, libacl1-dev, libacl1
2.2.51-3 | acl libacl1-dev libacl1
(35 rows)
Observe that some of these lines have commas and some don't. The ones that don't are the ones that were imported by gina, which does this:
./lib/lp/soyuz/scripts/gina/handlers.py:657: dsc_binaries=" ".join(src.binaries),
dsc_binaries is taken directly from the Binary field in the .dsc file, which is supposed to be comma-plus-optional-whitespace-separated, not space-separated (reference: http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Binary). This should be ", ".join(src.binaries) instead.
I'm running into this in lp:~cjwatson/launchpad/germinate-from-db where germinate chokes on the invalid Binary field in some source stanzas, but this would also be a blocker to switching to no-more-apt-ftparchive publishing for Ubuntu. I think, then, that as well as fixing gina to import these properly, we need a garbo job to clean up the incorrect data. (Alternatively, IndexStanzaFields.makeOutput could fix it up on the fly, but that would be less efficient.) Does that sound reasonable?
There are currently 55065 affected rows on production (thanks, spm). Would it be better to clean this up with manual SQL or a garbo job?