[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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

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
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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]