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
_______________________________________________
virt-tools-list mailing list
virt-tools-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/virt-tools-list
