dealing with i686 builds

[Tim Flink]

One of the things that I haven't dealt with yet for email reduction is
i686 packages.

At the moment, I assume that there are 2 or 3 tests that will be run
depending on the koji tag:
 - depcheck i386
 - depcheck x86_64
 - upgradepath noarch (not run for updates-testing)

These 2 or 3 tests are used to determine the state of an update's tests
and that state is used as part of the decision process to send an email
or not.

I'm trying to figure out the best way to deal with i686 packages and the
things that I have come up with so far are:

 - Ignore them and accept that emails will not be sent for those updates
 - Interface with bodhi/koji to determine whether an update has i686
   builds and adjust the state determination as needed

I remember Kamil found a list of i686 packages (but can't seem to find
the email at the moment) but I'll find the list of updates that would be
affected by not handling i686 builds.

Any other thoughts on how to go about doing this or preferences on one
over the other?

Tim

[John Dulaney]

I'm trying to figure out the best way to deal with i686 packages and the
things that I have come up with so far are:
 
 - Ignore them and accept that emails will not be sent for those updates
 - Interface with bodhi/koji to determine whether an update has i686
   builds and adjust the state determination as needed
 
I remember Kamil found a list of i686 packages (but can't seem to find
the email at the moment) but I'll find the list of updates that would be
affected by not handling i686 builds.
 
Any other thoughts on how to go about doing this or preferences on one
over the other?
 
Tim
 

Tim, I'm thinking the latter is ultimately the better way.

As far as implementation, can you not grep for 686 in the description
page thingy after where it says RPMs but prior to changelog?  Just a
thought.

John Dulaney

[Tim Flink]

On 06/02/2011 01:38 PM, John Dulaney wrote:
>  
>  
>  I'm trying to figure out the best way to deal with i686 packages and the
>  things that I have come up with so far are:
>   
>   - Ignore them and accept that emails will not be sent for those updates
>   - Interface with bodhi/koji to determine whether an update has i686
>     builds and adjust the state determination as needed
>   
>  I remember Kamil found a list of i686 packages (but can't seem to find
>  the email at the moment) but I'll find the list of updates that would be
>  affected by not handling i686 builds.
>   
>  Any other thoughts on how to go about doing this or preferences on one
>  over the other?
>   
>  Tim
>   
>  
>  Tim, I'm thinking the latter is ultimately the better way.
>  
>  As far as implementation, can you not grep for 686 in the description
>  page thingy after where it says RPMs but prior to changelog?  Just a
>  thought. 
I assume that you mean the user-facing page for koji builds? If so, it
would be easier just to grab the information from the data we get from
koji's XML-RPC interface.

Sorry, I should have sent this out earlier but I talked with Kamil on
IRC and he reminded me of a better solution which I didn't think to
include in the first email.

I changed the code to just look for 32 and 64 bit builds so that i686
and i386 both count against the same part of an update's status. While
not a perfect solution, it does cover a majority of our use cases and
this is only meant to be a temporary solution, anyways. ResultsDB will
be the end solution that we end up using for determining an update's
test status.

Tim