On 04/03/2013 08:42 PM, Cole Robinson wrote:
On 04/03/2013 06:19 PM, Gene Czarcinski wrote:
On 04/03/2013 05:09 PM, Gene Czarcinski wrote:
On 04/03/2013 04:21 PM, Daniel P. Berrange wrote:
On Wed, Apr 03, 2013 at 04:07:34PM -0400, Gene Czarcinski wrote:
On 04/03/2013 03:01 PM, Daniel P. Berrange wrote:
On Wed, Apr 03, 2013 at 02:12:32PM -0400, Gene Czarcinski wrote:
There may still be an autobuild server and it may be
necessary for vir--manager rpms to be built by it, but
this script depends on autotools and will not work
with the current distutils approach.
Signed-off-by: Gene Czarcinski <gene@xxxxxxxxx>
NACK, fix the script to work with distutils, don't delete it.
OK, I am not familiar with this server. Could you provide me with
more info or point me to where I can see the environment this script
must run in?
The intent is that you merely need do
export AUTOBUILD_INSTALL_ROOT=$HOME/tmp/autobuld
./autobuild.sh
and it will do a configure, build, install putting all the files into
$HOME/tmp/autobuild as the install prefix. Then create a release dist
and run the RPM buld.
Also, should this be a shell script or python?
Shell, as now. Just need to replace the calls to 'configure' and
'make' etc with corresponding distutils shell commands. eg
replace "make install" with "python setup.py install"
That was easy ... got the dist and rpms done, will do the install in a bit.
The problem (there always is one) is another of the patches I submitted ...
the one changing the way virt-manager version is done. You have a choice of
using a "fixed" version or one based on the move recent tag (the first part
of git-describe). Regardless, if the tag of the git-describe is not pointing
to the current commit or if the base version has version-<something>, then
".gityyyymmdd" is appended to the external-version-id which is used in the
tarball and rpm names. Thus, the result of autobuild.sh are some rpm files
with filenames of more than sixty bytes long.
Any suggestions? I would like to retain the "snapshot" id part of my
version patch but when mixed with "extra release", it is way too long.
BTW, one solution is to add some "special" commands to setup.py to just
handle the needs of autobuild. What would you like the "unique name" to
look like?
Got it all basically working although I had to do a little extra for the
install because setup.py install modifies at least one file that git tracks
and thus git get upset with uncommitted changes.
I need to think about how do do the version and yet make something unique for
autobuild. Maybe I should use ".git$NOW" for my version and then use
".autobuild" for the autobuild.sh extra_release.
Suggestions appreciated. I want to have autobuild be reasonable but I want to
be able to get a snapshot which has a tarball/rpm version-id which indicates
it is definitely a snapshot.
In the process of finishing off the virtinst merge, I reworked autobuild.sh:
http://git.fedorahosted.org/cgit/virt-manager.git/commit/?id=69d2aa49e4d1ffc5299e98851528f3628edaff31
But please submit patches for any further improvements you've listed.
HACKING and INSTALL also have been updated incase you are still wondering
about some of the setup.py details.
A problem and suggested solution.
Unfortunately, "python setup.py build" modifies po/virt-manager.pot
which is a git tracked/managed file. The result is that you wind up
with uncommitted changes after running "autobuild.sh'.
My solution: ... it hurts ... don't do that:
1. do the "python setup.py" first
2. Then create directory "builddir" and expand the tarball into it.
3. Change the current directory to be the tarball's directory under builddir
4. run python setup build
5. run python setup test
6. run python setup install -O1 --root=...
7. cd ../../ and do rm -rf builddir
8. do the rpm stuff
That is it.
I will submit a patch to implement the above.
Gene
_______________________________________________
virt-tools-list mailing list
virt-tools-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/virt-tools-list
