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

[Gene Czarcinski]

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.

Gene