Hi,

Am Freitag, 11. März 2011, 09:58:39 schrieb Jan Pazdziora:
> On Fri, Mar 11, 2011 at 09:40:25AM +0100, Jan Pazdziora wrote:
> > 
[...]
> >         _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 turns out, the
> 
>       e['advisory_rel'] = notice['version']
> 
> is at fault -- at least in that Fedora 7 updateinfo, the version
> is not integer. When I've changed the line to
> 
>       e['advisory_rel'] = 1
> 
> things went much better.

Yes, this is the version appended to advisory_name. Here is an example from 
openSUSE which shows the unique problem

<updates>
<!--PATCHINFO id="898568de8313f62fc290e303946cfe11"!-->
<update status="stable" from="maint-co...@suse.de" type="recommended" 
version="1596">
  <id>flash-player</id>
  <issued date="1256155647"/>
[...]
<update status="stable" from="maint-co...@suse.de" type="security" 
version="1707">
  <id>flash-player</id>
  <issued date="1260492724"/>

Same id used but with a different version. I think we need to find a way to 
deal with all these differences in how updateinfo is used.

About the channel label added to the advisory_name.

I think the correct way would be to search in DB if the errata already exist.
If so, create the errata object from the DB and add the new packages and 
channels to it.
Than update the errata in the database.

Doing this, we do not need to append the channel label to advisory_name.

Is there already a method to create an Erratum object from the database?


-- 
Regards,

        Michael Calmer

--------------------------------------------------------------------------
Michael Calmer
SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg
T: +49 (0) 911 74053 0
F: +49 (0) 911 74053575  - e-mail: michael.cal...@suse.com
--------------------------------------------------------------------------
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Reply via email to