On Mon, 2008-12-22 at 23:57 +0200, Axel Thimm wrote: > On Mon, Dec 22, 2008 at 10:34:55PM +0100, Dag Wieers wrote: > > Can you be a little bit more specific ? Is there a thread describing the > > issue ? Is there going to be a real fix for it ? > > > > I really don't feel good with this patch. The error does not indicate > > to a user that a "yum clean metadata" resolves their problem. > > > > If we are going to have all our users that use atrpms go through this by > > default, then I think we should avoid it at all cost. The BZ I can easily find is RH 465898: [https://bugzilla.redhat.com/show_bug.cgi?id=465898 TypeError: 'NoneType' object is unsubscriptable error in sqlitesack.py:94:_read_db_obj (pkgId can't be found)] ...although I'm sure we discussed something with You or Axel at one point about multiple pkgId's in one repo. The yum-metadata-parser "fix" is: http://yum.baseurl.org/gitweb?p=yum-metadata-parser.git;a=commitdiff;h=c5033bfe5484ec3ecd49f1bf8801c6a8163df482 ...which seems to have cured it (just disables the "optimized" code path, which doesn't like multiple pkgId's). > I also don't understand the patch mentioned above. What at ATrpms > upsets the new yum that way? The yum patch is to stop the backtraces, and give a warning to the user that the repo. is currently broken. AFAIK it should break equally on all versions of yum¹, but given how it breaks the yum .sqlite files it's not really possible to see it in action. Maybe older versions of yum wouldn't use pkgKey in the same way ... so if multiple pkgId's broke the pkgKey's then it'd still work. Not sure. > If it's something I can fix on my end, > I'd gladly do so, but I'm just using plain createrepo (and this seems > to work with the yum version in question with other distros). Pass -d to create repo. and it'll work (and be faster). ¹ Hence my interest in any information from the reporter here to disprove that. -- James Antill <james at fedoraproject.org> Fedora