On Tue, Mar 08, 2011 at 05:57:05PM +0100, Michael Calmer wrote:
> Hi,
>
> Am Montag, 7. März 2011, 15:49:59 schrieb Miroslav Suchý:
> > On 03/07/2011 02:28 PM, Michael Calmer wrote:
> > > Hello,
>
> [...]
>
> > Regarding patch 0001-implement-updateinfo-Errata-import-5.patch...
> > It seems to me that it is merge of 4 smaller commits and therefore the
> > commit description is quite misleading...
> > I would expectd something like:
> > Decide if package is errata based on updateinfo....
>
> Well, this was the initial patch for this feature. So I think
> "implement updateinfo to Errata import" is a good headline.
> The 2 additional patches merged into this first commit were smaller bugfixes
> for the initial patch.
>
> > and something more how the detection works and which all information you
> > extract from updateinfo.
>
> * fix errata override bug. Create a unique advisory_name
> This was about the <id> element in the updateinfo which is not unique.
> To get it unique we append notice['version'] to it. The next hit was,
By the way, when I've removed some safechecks to actually see some
erratas being created from
http://archives.fedoraproject.org/pub/archive/fedora/linux/updates/7/i386/repodata/updateinfo.xml.gz
I get traceback
No cheksum found for hydrogen-0.9.3-9.fc7.1.src. Skipping Patch
FEDORA-2007-3554-1.4-channel-ia32
Traceback (most recent call last):
File "/usr/bin/spacewalk-repo-sync", line 69, in <module>
sys.exit(abs(main() or 0))
File "/usr/bin/spacewalk-repo-sync", line 63, in main
sync.main()
File
"/usr/lib/python2.6/site-packages/spacewalk/satellite_tools/reposync.py", line
111, in main
self.import_updates(plugin, url)
File
"/usr/lib/python2.6/site-packages/spacewalk/satellite_tools/reposync.py", line
146, in import_updates
self.upload_updates(notices)
File
"/usr/lib/python2.6/site-packages/spacewalk/satellite_tools/reposync.py", line
297, in upload_updates
importer.run()
File
"/usr/lib/python2.6/site-packages/spacewalk/server/importlib/importLib.py",
line 622, in run
self.submit()
File
"/usr/lib/python2.6/site-packages/spacewalk/server/importlib/errataImport.py",
line 196, in submit
dml = self.backend.processErrata(self.batch)
File
"/usr/lib/python2.6/site-packages/spacewalk/server/importlib/backend.py", line
682, in processErrata
transactional=1)
File
"/usr/lib/python2.6/site-packages/spacewalk/server/importlib/backend.py", line
1364, in __processObjectCollection
return self.__processObjectCollection__(objColl, parentTable,
childDict, **kwargs)
File
"/usr/lib/python2.6/site-packages/spacewalk/server/importlib/backend.py", line
1450, in __processObjectCollection__
_buildExternalValue(extObject, object, parentTableObj)
File
"/usr/lib/python2.6/site-packages/spacewalk/server/importlib/backend.py", line
1982, in _buildExternalValue
dict[f] = sanitizeValue(entry[attr], datatype)
File
"/usr/lib/python2.6/site-packages/spacewalk/server/importlib/backendLib.py",
line 494, in sanitizeValue
return int(value)
ValueError: invalid literal for int() with base 10: '1.4'
I assume the 1.4 value is the version you've put to the errata
name as the updateinfo.xml.gz has 1.4 in version -- it starts like
<?xml version="1.0"?>
<updates>
<update from="bodhiadmin-memb...@fedoraproject.org" status="stable"
type="bugfix" version="1.4">
<id>FEDORA-2007-2609</id>
<title>filezilla-3.0.2.1-1.fc7</title>
<release>Fedora 7</release>
<issued date="2007-11-20 17:45:27"/>
<references/>
I further assume that that value somehow gets massaged into epoch
column somewhere, or some other integer field.
It looks like another reason why we really should try to find
alternative approaches to the uniqueness problem, if there indeed
is one. Perhaps some command line option?
--
Jan Pazdziora
Principal Software Engineer, Satellite Engineering, Red Hat
_______________________________________________
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
