[virt-tools-list] [PATCH 1/2] update autobuild.sh so it works

[Gene Czarcinski]

On 04/05/2013 10:40 AM, Cole Robinson wrote:
> On 04/05/2013 09:16 AM, Gene Czarcinski wrote:
>> On 04/04/2013 04:48 PM, Daniel P. Berrange wrote:
>>> On Thu, Apr 04, 2013 at 03:15:38PM -0400, Cole Robinson wrote:
>>>> On 04/04/2013 12:49 PM, Daniel P. Berrange wrote:
>>>>> On Thu, Apr 04, 2013 at 12:41:30PM -0400, Gene Czarcinski wrote:
>>>>>> There a some problems with autobuild.sh and this patch addresses
>>>>>> them:
>>>>>>
>>>>>> 1. Some of the tests fail so temporarily comment out
>>>>>> "prython setup.py test" until things are fixed so the tests
>>>>>> run correctly.  At that time, this should be uncommented.
>>>>>>
>>>>>> 2. "python setup.py install" needs to use --root= instead
>>>>>> of --prefix=
>>>>>>
>>>>>> 3. For the rpmbuild, use dist/*tar.gz instead of *.tar.gz
>>>>>>
>>>>>> 4. "python setup.py build" modifies the git tracked/managed
>>>>>> file po/virt-manager.pot so that you end of with uncommitted
>>>>>> changes.  To correct this: use the sdist created tarball,
>>>>>> expand it into a local/unmangerd directory and run build,
>>>>>> test, and install out of this directory.
>>>>> Actually the right fix there is to just remove virt-manager.pot
>>>>> from GIT entirely. GIT shouldn't be used to track any files
>>>>> which are purely auto-generated, as the .pot file is. Only the
>>>>> .po files need to be in GIT
>>>>>
>>>> Transifex requires the pot file to be in tree at least, there's a bit about it
>>>> here:
>>> Ah, well i guess it depends how you use transifex :-) For other projects
>>> I don't ever let Transifex have any repo access. I just use 'tx push' to
>>> send the updated pot file to transifex when required, and 'tx pull' to
>>> bring down the .po's later.
>>>
>>>
>>> Back to the original issue - autobuild.sh causing virt-manager.pot to
>>> change, that's not an issue for autobuild, since it always does a
>>> git reset before running autobuild.sh. It is only an issue with people
>>> running autobuild.sh manually, and  don't think that's worth worrying
>>> about. If the .pot changes, then should ought to be committing the update
>>> to GIT so transifex can pull it.
>>>
>> Please define what you guys want done (besides getting autobuild.sh to work).
>>
>> The only way I have of testing this is to do ./autobuild and the build process
>> changes po/virt-manager.pot.  This file is changed every time build is run if
>> only that the "pot creation" date/time is changed.
>>
>> 1.  Using a subdirectory, expanding the tarball into that directory and then
>> running build, test, install from that directory DOES NOT work because of the
>> hardlinks install does.  I have not looked into see how rpm handles that issue.
>>
>>
>> 2. The po/virtmanger.pot file could be removed from git tracking. Just what is
>> the issue with that?  If a file gets automatically updated/changed then why
>> should git be tracking that file.  If update is needed then then create a new
>> file which will be tracked by get (e.g., po/virt-manager.pot.in) and that file
>> is copied to be po/virt-manager.pot file which can be updated.
>>
>> 3.  At the beginning of the autobuild.sh script I could add a test to make
>> sure there are no uncommitted changes and if changes exists, fail autobuild.sh
>> execution [it may be a good idea to add this anyway].  Then after everything
>> executes, the autobuild.sh could issue a git-reset-hard to clean things up.
>>
>> For myself, I either run things from the git-clone directrory or i use sdist
>> to create a tarball and then use that tarball to create runtime rpms.  I never
>> build rpms directly of out of the git-clone directory-tree.
>>
>> I believe that doing nothing (let these randomly occurring changes exist) is
>> not acceptable.  As I see it, the only viable options are two and three with
>> three continuing to have a git tacked file ... just not the
>> po/virt-manager.pot file.
>>
> My recommendation would be either
>
> 1) Set up an autobuild server and test autobuild.sh that way rather than
> trying to run the script directly. The script has a clear warning that it is
> only expected to be run via autobuild server. If that generates changes to the
> autobuild.sh script I'll be happy to review them.
>
> 2) If you don't want to set up an autobuild server, then just ignore autobuild.sh.
>
> The virt-manager.pot being changed on every build can be avoided by removing
> the pot file from git like Dan suggested. I'll just need to tweak the
> transifex setup and alter my release process, but it should be simple enough.
I do not have a need for the autobuild server so I am going to stay away 
from it.  I have taken another shot at autobuild.sh.  Besides the other 
fixes, I added a check to make sure that there was a git program and 
that this was a git prepository.  I then checked to make sure that there 
are no uncommitted changes and abort if there are. I believe this might 
be a good addition regardless of anything else.  I have added a 
git-reset--hard to the end to get rid of the po/virt-manager.pot changes 
but this could be dropped if the file is going to be removed from git 
tracking.

I really have a set of three patch files that I will be submitting. The 
first is for autobuild.sh.  The second creates a MANIFEST.in (git 
tracked) file to control what is and what is not included in the sdist 
tarball.  This took a bit more tweaking than I anticipated to get a good 
tarball.  The third (and possibly most controversial) is my changes for 
virt-manager versioning.

The versioning updates splits the version into an external-version-id 
for the tarball and rpm. with a related but separate internal-version-id 
which provides more info such as the number of commits since the release 
and the latest commit id.

The external and internal version can optionally use with the fixed 
(cliconfig.__version__) or a version based on the tag portion of what is 
returned by git-describe--tags.

I have also done some effort to support autobuild.sh so that it can use 
its form of naming/versioning.

I will be waiting until tomorrow to submit these patches.

Gene