3:44 p.m.
Greetings,
GIT: [PATCH] Include githash when building pre-release packages
The attached patch follows the packaging process similar to aeolus-conductor by
including a datestamp and githash in any pre-release RPM builds. A pre-release
is any oz release where %{release} starts with '0'. Any pre-release rpm builds
(make rpm) will include a datestamp and githash in the %{release} field. Any
non pre-release builds will appear as normal.
Comments welcome.
Thanks,
James
3:44 p.m.
New subject: [PATCH] Include githash when building pre-release packages
A pre-release is any release where %{release} starts with 0. When
building RPMs of pre-releases, a datestamp and githash are included in
the RPM %{release} string. This allows to easily determine when and
what is included in the built packages.
---
oz.spec.in | 2 +-
setup.py | 18 +++++++++++++++---
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/oz.spec.in b/oz.spec.in
index ece60ec..ca7583e 100644
--- a/oz.spec.in
+++ b/oz.spec.in
@@ -1,7 +1,7 @@
Summary: Library and utilities for automated guest OS installs
Name: oz
Version: @VERSION@
-Release: 1%{?dist}
+Release: 0%{?dist}
License: LGPLv2
Group: Development/Libraries
URL: http://aeolusproject.org/oz.html
diff --git a/setup.py b/setup.py
index ff2b318..9ed0615 100644
--- a/setup.py
+++ b/setup.py
@@ -1,8 +1,15 @@
from distutils.core import setup, Extension, Command
from distutils.command.sdist import sdist as _sdist
-import os
+import os, sys
+import subprocess
+
+def call(*args):
+ p = subprocess.Popen(*args, shell=True, \
+ stdout=subprocess.PIPE)
+ return p.communicate()[0]
VERSION = '0.7.0'
+RELEASE = call("grep '^\s*Release:' oz.spec.in | gawk '{print
$2}'")
datafiles = [('share/man/man1', ['man/oz-install.1',
'man/oz-customize.1',
'man/oz-generate-icicle.1',
@@ -13,8 +20,13 @@ class sdist(_sdist):
""" custom sdist command, to prep oz.spec file for inclusion
"""
def run(self):
- cmd = (""" sed -e "s/@VERSION@/%s/g" < oz.spec.in
""" %
- VERSION) + " > oz.spec"
+ cmd = 'sed -e "s|@VERSION@|%s|g"' % VERSION
+ if RELEASE.startswith('0'):
+ git_head = call("git log -1 --pretty=format:%h").strip()
+ date = call("date --utc +%Y%m%d%H%M%S").strip()
+ git_release = "%sgit%s" % (date, git_head)
+ cmd += ''' -e
"s|^\(Release:[^%%]*\)|\\1.%s|"''' % git_release
+ cmd += ' < oz.spec.in > oz.spec'
os.system(cmd)
_sdist.run(self)
--
1.7.6.4
9:13 a.m.
New subject: [PATCH] Include githash when building pre-release packages
On 10/03/11 - 04:44:16PM, James Laska wrote:
A pre-release is any release where %{release} starts with 0. When
building RPMs of pre-releases, a datestamp and githash are included in
the RPM %{release} string. This allows to easily determine when and
what is included in the built packages.
---
oz.spec.in | 2 +-
setup.py | 18 +++++++++++++++---
2 files changed, 16 insertions(+), 4 deletions(-)
I feel like we can be a bit more pythonic about this. I've taken your patch
and modified it a bit; the result is attached. Please take a look and tell
me what you think.
There is one bit about this I still don't like. Right now when I go to do a
release, I only have to the VERSION field in setup.py, and things will work
properly. By moving to this new scheme, I have to change VERSION in setup.py
and Release in oz.spec.in. I think I might rather move the Release field into
setup.py, and then at least I would only have a single file to change (even if
I do have to change 2 fields).
--
Chris Lalancette
9:57 a.m.
New subject: [PATCH] Include githash when building pre-release packages
On Tue, 2011-10-04 at 10:13 -0400, Chris Lalancette wrote:
On 10/03/11 - 04:44:16PM, James Laska wrote:
> A pre-release is any release where %{release} starts with 0. When
> building RPMs of pre-releases, a datestamp and githash are included in
> the RPM %{release} string. This allows to easily determine when and
> what is included in the built packages.
> ---
> oz.spec.in | 2 +-
> setup.py | 18 +++++++++++++++---
> 2 files changed, 16 insertions(+), 4 deletions(-)
I feel like we can be a bit more pythonic about this. I've taken your patch
and modified it a bit; the result is attached. Please take a look and tell
me what you think.
Much better! I debated removing the 'sed' in favor of a iterating
through the file in python. I like you're approach better.
There is one bit about this I still don't like. Right now when I
go to do a
release, I only have to the VERSION field in setup.py, and things will work
properly. By moving to this new scheme, I have to change VERSION in setup.py
and Release in oz.spec.in. I think I might rather move the Release field into
setup.py, and then at least I would only have a single file to change (even if
I do have to change 2 fields).
Good thinking. Let's make life easier for you come release time.
Perhaps just go with @VERSION@ and @RELEASE@%{?dist} in oz.spec.in? The
following attached patch seems to handle that for me, feel free to
adjust as needed.
Thanks,
James
12:47 p.m.
New subject: [PATCH] Include githash when building pre-release packages
On 10/04/11 - 10:57:37AM, James Laska wrote:
On Tue, 2011-10-04 at 10:13 -0400, Chris Lalancette wrote:
> On 10/03/11 - 04:44:16PM, James Laska wrote:
> > A pre-release is any release where %{release} starts with 0. When
> > building RPMs of pre-releases, a datestamp and githash are included in
> > the RPM %{release} string. This allows to easily determine when and
> > what is included in the built packages.
> > ---
> > oz.spec.in | 2 +-
> > setup.py | 18 +++++++++++++++---
> > 2 files changed, 16 insertions(+), 4 deletions(-)
>
> I feel like we can be a bit more pythonic about this. I've taken your patch
> and modified it a bit; the result is attached. Please take a look and tell
> me what you think.
Much better! I debated removing the 'sed' in favor of a iterating
through the file in python. I like you're approach better.
> There is one bit about this I still don't like. Right now when I go to do a
> release, I only have to the VERSION field in setup.py, and things will work
> properly. By moving to this new scheme, I have to change VERSION in setup.py
> and Release in oz.spec.in. I think I might rather move the Release field into
> setup.py, and then at least I would only have a single file to change (even if
> I do have to change 2 fields).
Good thinking. Let's make life easier for you come release time.
Perhaps just go with @VERSION@ and @RELEASE@%{?dist} in oz.spec.in? The
following attached patch seems to handle that for me, feel free to
adjust as needed.
Yep, this looks a lot better than mine, even. I modified it ever so slightly
to remove the (now unnecessary) import re, and then pushed it.
Thanks!
--
Chris Lalancette
4596
days inactive
4597
days old
aeolus-devel@lists.fedorahosted.org
4 comments
2 participants
participants (2)
-
Chris Lalancette -
James Laska