-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
WARNING! WARNING! WARNING! very long email, bear with me please :) WARNING! WARNING! WARNING!
Here is the updated candlepin.spec file (as of today) :
Here is the diff between what's in master and my tito branch:
I installed the tomcat6 version of the rpm on my development machine and was able to run the python tests against it (after I did the 'init' step from the deploy script).
There is still quite a bit of work to get candlepin packaged 100% as an rpm with all of its dependencies ( see Adam's list: https://fedorahosted.org/candlepin/wiki/Dependencies ) but there are a few more items that need to be addressed before we can merge the tito branch back to master:
1. explode candlepin war for the jboss deployment
2. fix githash code to work or find alternative approach
3. spec file requires rubygem-buildr rpm to build, we could make that BuildRequires: /usr/bin/buildr until the buildr rpms are ready.
4. buildr's buildfile has a version (which hasn't changed, and the spec file has a version which tito bumps automagically).
How hard are the above issues to address?
1. is trivial will be done probably before you read this email.
2. this is a bit more difficult because we need a way to update the candlepin_info.properties on the fly and the build isn't running in a git checkout at the time of the rpm build.
How important is the candlepin_info.properties with a git hash?
3. requiring rubygem-buildr is the proper way to do it, but if the rpm isn't ready for folks to deploy, then the candlepin rpm won't be buildable yet.
Changing it to require /usr/bin/buildr will make it buildable now and *will* require changing once we have a proper rpm of buildr.
An alternative is to BuildRequires: ant, add a build.xml to build the code just for the rpm. (sorry I ain't doing no maven rpm).
I'm leaning towards simply requiring /usr/bin/buildr for now, and merge it into master for now with a new item to finalize the buildr rpm.
4. I think the best way is to *pass* in the version number to the build command from the spec file, and have the buildfile read the version from the spec file during dev builds.
In other words, in the candlepin.spec the %build section will look as follows: buildr clean test=no package version=%{version}
I'm not sure if this is even possible on the buildr side, but since it can do anything ruby and rake can, it's probably doable.
I'll need help with coming to a decision on 2, 3, & 4 so we can merge this into master.
jesus
- -- jesus m. rodriguez | jesusr@redhat.com principal software engineer | irc: zeus red hat systems management | 919.754.4413 (w) rhce # 805008586930012 | 919.623.0080 (c) +---------------------------------------------+ | "Those who cannot remember the past | | are condemned to repeat it." | | -- George Santayana | +---------------------------------------------+
On 04/07/2010 04:46 PM, Jesus M. Rodriguez wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
WARNING! WARNING! WARNING! very long email, bear with me please :) WARNING! WARNING! WARNING!
Here is the updated candlepin.spec file (as of today) :
http://bit.ly/9WAXXK
Here is the diff between what's in master and my tito branch:
http://pastie.org/908199
I installed the tomcat6 version of the rpm on my development machine and was able to run the python tests against it (after I did the 'init' step from the deploy script).
There is still quite a bit of work to get candlepin packaged 100% as an rpm with all of its dependencies ( see Adam's list: https://fedorahosted.org/candlepin/wiki/Dependencies ) but there are a few more items that need to be addressed before we can merge the tito branch back to master:
explode candlepin war for the jboss deployment
fix githash code to work or find alternative approach
spec file requires rubygem-buildr rpm to build, we could make that BuildRequires: /usr/bin/buildr until the buildr rpms are ready.
buildr's buildfile has a version (which hasn't changed, and the spec file has a version which tito bumps automagically).
How hard are the above issues to address?
- is trivial will be done probably before you read this email.
Is this a debug thing? You should be able to deploy the .war file directly to the server/depoly directory in JBoss.
this is a bit more difficult because we need a way to update the candlepin_info.properties on the fly and the build isn't running in a git checkout at the time of the rpm build.
How important is the candlepin_info.properties with a git hash?
requiring rubygem-buildr is the proper way to do it, but if the rpm isn't ready for folks to deploy, then the candlepin rpm won't be buildable yet.
Changing it to require /usr/bin/buildr will make it buildable now and *will* require changing once we have a proper rpm of buildr.
An alternative is to BuildRequires: ant, add a build.xml to build the code just for the rpm. (sorry I ain't doing no maven rpm).
I'm leaning towards simply requiring /usr/bin/buildr for now, and merge it into master for now with a new item to finalize the buildr rpm.
The Buildr RPM works now, so long as we don't need to run the cucumber tests. All RPMS required are in : http://admiyo.fedorapeople.org/buildr/RPMS/
I'll eventually get a Yum repo set up, but wget those and install should work for now, so long as you haven't run "ruby system --update"
I think the best way is to *pass* in the version number to the build command from the spec file, and have the buildfile read the version from the spec file during dev builds.
In other words, in the candlepin.spec the %build section will look as follows: buildr clean test=no package version=%{version}
I'm not sure if this is even possible on the buildr side, but since it can do anything ruby and rake can, it's probably doable.
I'm not sure I understand the issue here.
I'll need help with coming to a decision on 2, 3,& 4 so we can merge this into master.
jesus
jesus m. rodriguez | jesusr@redhat.com principal software engineer | irc: zeus red hat systems management | 919.754.4413 (w) rhce # 805008586930012 | 919.623.0080 (c) +---------------------------------------------+ | "Those who cannot remember the past | | are condemned to repeat it." | | -- George Santayana | +---------------------------------------------+
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAku87zsACgkQvJZ57YntiYMy2gCcCyXbBzRTfoqz+cLc5j9OAwSO Ta8AoKiRSV4bHFoC8nt7jGLqlH1TxlDW =P+W8 -----END PGP SIGNATURE----- _______________________________________________ candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
On Wed, Apr 7, 2010 at 6:21 PM, Adam Young ayoung@redhat.com wrote:
How hard are the above issues to address?
- is trivial will be done probably before you read this email.
Is this a debug thing? You should be able to deploy the .war file directly to the server/depoly directory in JBoss.
No, it's more of an RPM thing. It allows you to own the directory that gets exploded and when you remove the rpm it takes it with it. It also helps in being able to create rpms that depend on the candlepin rpm which can lay down jars in /path/to/deploy/candlepin/WEB-INF/lib/ making it a lot easier to deploy service implementations.
- this is a bit more difficult because we need a way to update
the candlepin_info.properties on the fly and the build isn't running in a git checkout at the time of the rpm build.
How important is the candlepin_info.properties with a git hash?
- requiring rubygem-buildr is the proper way to do it, but if the
rpm isn't ready for folks to deploy, then the candlepin rpm won't be buildable yet.
Changing it to require /usr/bin/buildr will make it buildable now and *will* require changing once we have a proper rpm of buildr.
An alternative is to BuildRequires: ant, add a build.xml to build the code just for the rpm. (sorry I ain't doing no maven rpm).
I'm leaning towards simply requiring /usr/bin/buildr for now, and merge it into master for now with a new item to finalize the buildr rpm.
The Buildr RPM works now, so long as we don't need to run the cucumber tests. All RPMS required are in : http://admiyo.fedorapeople.org/buildr/RPMS/
I'll eventually get a Yum repo set up, but wget those and install should work for now, so long as you haven't run "ruby system --update"
Ok I'll update my rpms. If you want to you could just run createrepo -d on the directory you have those RPMS in and then rsync the repo metadata files to your people account. Unless you don't want a repo right now for some reason.
- I think the best way is to *pass* in the version number to the
build command from the spec file, and have the buildfile read the version from the spec file during dev builds.
In other words, in the candlepin.spec the %build section will look as follows: buildr clean test=no package version=%{version}
I'm not sure if this is even possible on the buildr side, but since it can do anything ruby and rake can, it's probably doable.
I'm not sure I understand the issue here.
the buildfile has a VERSION=1.0.0 which NEVER changes. And the candlepin.spec file has a Version=1.0.1 (which is incremented by tito during the tagging process. It would be best if we kept them consistent. To me the buildfile should use the one passed in from the rpm during build, and for development purposes i.e. buildr package from your git tree it should use the git hash as the version number.
jesus
On 04/07/2010 11:14 PM, Jesus M. Rodriguez wrote:
On Wed, Apr 7, 2010 at 6:21 PM, Adam Youngayoung@redhat.com wrote:
How hard are the above issues to address?
- is trivial will be done probably before you read this email.
Is this a debug thing? You should be able to deploy the .war file directly to the server/depoly directory in JBoss.
No, it's more of an RPM thing. It allows you to own the directory that gets exploded and when you remove the rpm it takes it with it. It also helps in being able to create rpms that depend on the candlepin rpm which can lay down jars in /path/to/deploy/candlepin/WEB-INF/lib/ making it a lot easier to deploy service implementations.
this is a bit more difficult because we need a way to update the candlepin_info.properties on the fly and the build isn't running in a git checkout at the time of the rpm build.
How important is the candlepin_info.properties with a git hash?
requiring rubygem-buildr is the proper way to do it, but if the rpm isn't ready for folks to deploy, then the candlepin rpm won't be buildable yet.
Changing it to require /usr/bin/buildr will make it buildable now and *will* require changing once we have a proper rpm of buildr.
An alternative is to BuildRequires: ant, add a build.xml to build the code just for the rpm. (sorry I ain't doing no maven rpm).
I'm leaning towards simply requiring /usr/bin/buildr for now, and merge it into master for now with a new item to finalize the buildr rpm.
The Buildr RPM works now, so long as we don't need to run the cucumber tests. All RPMS required are in : http://admiyo.fedorapeople.org/buildr/RPMS/
I'll eventually get a Yum repo set up, but wget those and install should work for now, so long as you haven't run "ruby system --update"
Ok I'll update my rpms. If you want to you could just run createrepo -d on the directory you have those RPMS in and then rsync the repo metadata files to your people account. Unless you don't want a repo right now for some reason.
Yeah, I did that on my local machine. No createrepo on the remote, so I'll rsync over from local.
I think the best way is to *pass* in the version number to the build command from the spec file, and have the buildfile read the version from the spec file during dev builds.
In other words, in the candlepin.spec the %build section will look as follows: buildr clean test=no package version=%{version}
I'm not sure if this is even possible on the buildr side, but since it can do anything ruby and rake can, it's probably doable.
I'm not sure I understand the issue here.
the buildfile has a VERSION=1.0.0 which NEVER changes. And the candlepin.spec file has a Version=1.0.1 (which is incremented by tito during the tagging process. It would be best if we kept them consistent. To me the buildfile should use the one passed in from the rpm during build, and for development purposes i.e. buildr package from your git tree it should use the git hash as the version number.
jesus _______________________________________________ candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
On 04/08/2010 08:50 AM, Adam Young wrote:
On 04/07/2010 11:14 PM, Jesus M. Rodriguez wrote:
On Wed, Apr 7, 2010 at 6:21 PM, Adam Youngayoung@redhat.com wrote:
How hard are the above issues to address?
- is trivial will be done probably before you read this email.
Is this a debug thing? You should be able to deploy the .war file directly to the server/depoly directory in JBoss.
No, it's more of an RPM thing. It allows you to own the directory that gets exploded and when you remove the rpm it takes it with it. It also helps in being able to create rpms that depend on the candlepin rpm which can lay down jars in /path/to/deploy/candlepin/WEB-INF/lib/ making it a lot easier to deploy service implementations.
this is a bit more difficult because we need a way to update the candlepin_info.properties on the fly and the build isn't running in a git checkout at the time of the rpm build.
How important is the candlepin_info.properties with a git hash?
requiring rubygem-buildr is the proper way to do it, but if the rpm isn't ready for folks to deploy, then the candlepin rpm won't be buildable yet.
Changing it to require /usr/bin/buildr will make it buildable now and *will* require changing once we have a proper rpm of buildr.
An alternative is to BuildRequires: ant, add a build.xml to build the code just for the rpm. (sorry I ain't doing no maven rpm).
I'm leaning towards simply requiring /usr/bin/buildr for now, and merge it into master for now with a new item to finalize the buildr rpm.
The Buildr RPM works now, so long as we don't need to run the cucumber tests. All RPMS required are in : http://admiyo.fedorapeople.org/buildr/RPMS/
I'll eventually get a Yum repo set up, but wget those and install should work for now, so long as you haven't run "ruby system --update"
Ok I'll update my rpms. If you want to you could just run createrepo -d on the directory you have those RPMS in and then rsync the repo metadata files to your people account. Unless you don't want a repo right now for some reason.
Yeah, I did that on my local machine. No createrepo on the remote, so I'll rsync over from local.
http://admiyo.fedorapeople.org/buildr-repo/
I think the best way is to *pass* in the version number to the build command from the spec file, and have the buildfile read the version from the spec file during dev builds.
In other words, in the candlepin.spec the %build section will look as follows: buildr clean test=no package version=%{version}
I'm not sure if this is even possible on the buildr side, but since it can do anything ruby and rake can, it's probably doable.
I'm not sure I understand the issue here.
the buildfile has a VERSION=1.0.0 which NEVER changes. And the candlepin.spec file has a Version=1.0.1 (which is incremented by tito during the tagging process. It would be best if we kept them consistent. To me the buildfile should use the one passed in from the rpm during build, and for development purposes i.e. buildr package from your git tree it should use the git hash as the version number.
jesus _______________________________________________ candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
On 04/08/2010 08:54 AM, Adam Young wrote:
On 04/08/2010 08:50 AM, Adam Young wrote:
On 04/07/2010 11:14 PM, Jesus M. Rodriguez wrote:
On Wed, Apr 7, 2010 at 6:21 PM, Adam Youngayoung@redhat.com wrote:
How hard are the above issues to address?
- is trivial will be done probably before you read this email.
Is this a debug thing? You should be able to deploy the .war file directly to the server/depoly directory in JBoss.
No, it's more of an RPM thing. It allows you to own the directory that gets exploded and when you remove the rpm it takes it with it. It also helps in being able to create rpms that depend on the candlepin rpm which can lay down jars in /path/to/deploy/candlepin/WEB-INF/lib/ making it a lot easier to deploy service implementations.
I'd be prone to install into a different directory, like something under /usr/share, and then copy the deploy directory as a deliberate decision on the part of the sys admin. THis allows you to separate out the copying of the code to the machine and the upgrade. JBoss hot deploy is a pretty nice feature, and, so long as there is not a DB upgrade involved, goes pretty cleanly. One caveat is that the deploy dir should be on the same volume as the jar. It it is, deploy is just a rename, which is atomic, otherwise it is a full copy, and JBoss will start deploying as soon as it knows that the the deploy dir has a new dentry.
THus, I'd suggest the folowing:
/usr/share/candlepin/candelin.war /usr/share/candlepin/upgrade.sh
And then, as part of deploy:
Check for DB upgrades. IF there are any, undeploy candlepin from JBoss, upgrade the DB
For deploy, create a dir jbossas/server/deploy-stage right next to jbossas/server/deploy cp candlepin.war to jbossas/server/deploy-stage mv jbossas/server/deploy-stage jbossas/server/deploy
this is a bit more difficult because we need a way to update the candlepin_info.properties on the fly and the build isn't running in a git checkout at the time of the rpm build.
How important is the candlepin_info.properties with a git hash?
requiring rubygem-buildr is the proper way to do it, but if the rpm isn't ready for folks to deploy, then the candlepin rpm won't be buildable yet.
Changing it to require /usr/bin/buildr will make it buildable now and *will* require changing once we have a proper rpm of buildr. An alternative is to BuildRequires: ant, add a build.xml to build the code just for the rpm. (sorry I ain't doing no maven rpm). I'm leaning towards simply requiring /usr/bin/buildr for now, and merge it into master for now with a new item to finalize the buildr rpm.
The Buildr RPM works now, so long as we don't need to run the cucumber tests. All RPMS required are in : http://admiyo.fedorapeople.org/buildr/RPMS/
I'll eventually get a Yum repo set up, but wget those and install should work for now, so long as you haven't run "ruby system --update"
Ok I'll update my rpms. If you want to you could just run createrepo -d on the directory you have those RPMS in and then rsync the repo metadata files to your people account. Unless you don't want a repo right now for some reason.
Yeah, I did that on my local machine. No createrepo on the remote, so I'll rsync over from local.
http://admiyo.fedorapeople.org/buildr-repo/
I think the best way is to *pass* in the version number to the build command from the spec file, and have the buildfile read the version from the spec file during dev builds.
In other words, in the candlepin.spec the %build section will look as follows: buildr clean test=no package version=%{version} I'm not sure if this is even possible on the buildr side, but since it can do anything ruby and rake can, it's probably doable.
I'm not sure I understand the issue here.
the buildfile has a VERSION=1.0.0 which NEVER changes. And the candlepin.spec file has a Version=1.0.1 (which is incremented by tito during the tagging process. It would be best if we kept them consistent. To me the buildfile should use the one passed in from the rpm during build, and for development purposes i.e. buildr package from your git tree it should use the git hash as the version number.
jesus _______________________________________________ candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
On 04/07/2010 04:46 PM, Jesus M. Rodriguez wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
WARNING! WARNING! WARNING! very long email, bear with me please :) WARNING! WARNING! WARNING!
Here is the updated candlepin.spec file (as of today) :
http://bit.ly/9WAXXK
Here is the diff between what's in master and my tito branch:
http://pastie.org/908199
I installed the tomcat6 version of the rpm on my development machine and was able to run the python tests against it (after I did the 'init' step from the deploy script).
There is still quite a bit of work to get candlepin packaged 100% as an rpm with all of its dependencies ( see Adam's list: https://fedorahosted.org/candlepin/wiki/Dependencies ) but there are a few more items that need to be addressed before we can merge the tito branch back to master:
explode candlepin war for the jboss deployment
fix githash code to work or find alternative approach
spec file requires rubygem-buildr rpm to build, we could make that BuildRequires: /usr/bin/buildr until the buildr rpms are ready.
buildr's buildfile has a version (which hasn't changed, and the spec file has a version which tito bumps automagically).
How hard are the above issues to address?
is trivial will be done probably before you read this email.
this is a bit more difficult because we need a way to update the candlepin_info.properties on the fly and the build isn't running in a git checkout at the time of the rpm build.
How important is the candlepin_info.properties with a git hash?
Not as important. If we loose the hash, we will need to get better with small releases for QE. What if we packaged the git repo with it in the srpm?? Or... if builder made the srpm and copied the resources over as part of that?
-- bk
candlepin@lists.fedorahosted.org