Changes

If looking good then commit to CVS and push to main buildserver

If looking good then commit to CVS and push to main buildserver

Ian Wells: If only a patch is provided then the spec file needs to be updated, the patch added to CVS, [I find that it is good to do a 'make prep' and see if the patch is OK]then make the package locally, does it build and does it appear to work, then 'make commit tag build'.   

If only a patch is provided then the spec file needs to be updated, the patch added to CVS, [I find that it is good to do a 'make prep' and see if the patch is OK]then make the package locally, does it build and does it appear to work, then 'make commit tag build'.   

You don't need to create a patch as the ones in the bug are correct unified patches, they just need to be save to some relevant name.

You don't need to create a patch as the ones in the bug are correct unified patches, they just need to be save to some relevant name.

Then modify the spec file: update the release number, add a PatchXX line, add a changelog entry, add a %patch line

Then modify the spec file: update the release number, add a PatchXX line, add a changelog entry, add a %patch line

Nothing needs to be committed to CVS - all this happens locally to you at this point

Nothing needs to be committed to CVS - all this happens locally to you at this point

Then make mockbuild

Then :

 

  make mockbuild

Q:then I can build locally and test, correct? No need to make the changes in direstories ect, the patch provided by Dani will do the deed?

Yes if your 'test RPM' from make mockbuild looks OK, then you do cvs add XYZ.patch and then make commit tag build

====Bug 7541====

====Bug 7541====