Re: [Spacewalk-devel] New Makefile.git(2) committed
Jan Pazdziora wrote: However, if build.py is what you guys want and what you guys will develop and maintain, so be it. Just put the info to the wiki and I'll switch to using that. Until that happens, I'm ready to maintain and improve Makefile.git. Err. Am I missing something? Neither you nor Devan should do it. According Cliff notes: In general Satellite Release Engineer maintains Release Engineering tools and processes needed to get built packages into a consumable format. Such as: * Top level/master Makefiles used globally -- Miroslav Suchy RHN Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] New Makefile.git(2) committed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 26 Nov 2008 18:54:12 +0100 Jan Pazdziora [EMAIL PROTECTED] wrote: On Tue, Nov 25, 2008 at 04:14:32PM -0500, Jesus M. Rodriguez wrote: I'll appreciate if you try the new code and if you tell me your thoughts. How does this compare to the build.py stuff we added? While I prefer the build.py (as I can work more easily with python than make), I don't care which one ultimately we choose. If I'm not mistaken, Makefile.git is still the code we use. At least that's what the wiki suggests to do if you want to (for example) get .src.rpm from the repository. The changes I've committed this week were long in my oven, and the primary drive was to do even old builds right, by observing (for example) the NO_TAR_GZ at the correct time. Yes still the solution we use but as you know I've been tasked with adding some substantial functionality for Satellite builds. I had a very hard time deciphering the original Makefile.git, the new version has improved quite a bit but still quite daunting to dive into particularly if you're not skilled with shell/awk/perl syntax. Meanwhile pybuild is rapidly approaching the same level of functionality so I'm planning to proceed with that solution. Aside from solving my own need to get something I can work with quickly, I'm hopeful that Python scripts will serve to be easier for the team at large to read/digest/modify going forward, and we won't end up in a situation where only one or two people are capable of maintaining them. Scripting language should give us a healthy array of tools for organizing the code. I'm not happy to advocate that we drop Makefile.git, we needed a solution for build tools and you stepped up and gave us one solving a lot of the hard problems in the process. (note that I'm re-using much of your solutions just with different glue) I just want to solve the problem with the best technical solution we can for the long term. The Makefile.git was modelled after Makefile.svn, which was a thing which allowed me to do 5.2.0, and which was inspired by dist-cvs. I've picked make and Makefile primarily because dist-cvs uses that, to be as compatible as possible with what you have in brew and koji. (Otherwise I'd just hack it in Perl. :-P ) Will we be headed for some issues if we were to someday be building in Fedora Koji and are using Python build scripts? My understanding is you generally import srpms or tarballs into Fedora CVS which we would have previously built with our own build tools so I wasn't aware of any areas where we'd get into trouble there previously. Please let me know if there are. I consider rewriting Makefile.git into build.py a bad idea -- it just brings another language into the mix, it puts code to packages' directories where the Makefile generally only has variable definitions, plus it will take some time to stabilize. The main concern that Devan had with Makefile.git, the readability of the code, has hopefully been addressed with the last versions of Makefile.git. build.py should not plant any significant amount of code in the project directories, it will be using code defined in rel-eng just as the project Makefiles do today. While it is executable I would argue it really is just configuration as well, defining a class to be used to build the package. You could plug more code there if needed (if perhaps a package required massive hackery to build, but this situation hasn't arisen yet) but you could do the same with the Makefiles. It really is no different. Complicated Makefile: NAME := perl-DateTime-Locale NO_TAR_GZ = 1 SPECFILE = $(NAME).spec include ../../../rel-eng/Makefile.git Complicated build.py: import sys sys.path.append(../../../rel-eng/pybuilder/) from pybuilder import main, TarGzBuilder if __name__ == __main__: main(builder_class=TarGzBuilder) However, if build.py is what you guys want and what you guys will develop and maintain, so be it. Just put the info to the wiki and I'll switch to using that. Until that happens, I'm ready to maintain and improve Makefile.git. Will do. II will update wiki and drop build.py's in appropriate places as soon as I feel it's ready. Cheers, Devan - -- Devan Goodwin [EMAIL PROTECTED] Software Engineer - Spacewalk / RHN Satellite Halifax, Canada650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkuq+8ACgkQAyHWaPV9my6dpACgghgy3jFKSlaQ7dU7B0SHnOha vf0AnjPwdHFbjWw73LcrQjPRw985OTE0 =n+al -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] New Makefile.git(2) committed
On Wed, Nov 26, 2008 at 5:11 AM, Miroslav Suchý [EMAIL PROTECTED] wrote: Jesus M. Rodriguez wrote: How does this compare to the build.py stuff we added? The formula for comparability is: Makefile.git build.py :) Then let's pick one or the other. Having two is confusing. While I prefer python over anything Makefile :) I don't see the need to reinvent the wheel now. Python would make it easier for other folks to contribute but not sure how far along it is compared to the Makefile approach. jesus ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] New Makefile.git(2) committed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 26 Nov 2008 10:36:04 -0500 Jesus M. Rodriguez [EMAIL PROTECTED] wrote: On Wed, Nov 26, 2008 at 5:11 AM, Miroslav Suchý [EMAIL PROTECTED] wrote: Jesus M. Rodriguez wrote: How does this compare to the build.py stuff we added? The formula for comparability is: Makefile.git build.py :) Then let's pick one or the other. Having two is confusing. While I prefer python over anything Makefile :) I don't see the need to reinvent the wheel now. Python would make it easier for other folks to contribute but not sure how far along it is compared to the Makefile approach. jesus build.py was on hold while we sorted out the plan for some build issues and who was going to be working on them. That's been assigned to me and I'm in agreement in terms of doing it in Python so I've picked it back up as of yesterday. This implies I'll have to replicate the new behaviour Jan has added in the last weeks. A lot of it gets re-used as much of it boils down to git commands etc, it's just the glue that changes. Build.py currently supports: ([EMAIL PROTECTED])[~/src/spacewalk/java] % ./build.py --help Usage: build.py [options] arg Options: -h, --help show this help message and exit --tgz build .tar.gz --srpm build srpm --rpm build rpm --dist=DISTdist tag to apply to srpm and/or rpm (i.e. .el5) --test Use current branch HEAD instead of latest package tag. --no-cleanup Do not clean up temporary build directories/files. --tag=TAG Build a specific tag instead of the latest version. (i.e. spacewalk-java-0.4.0-1) --debugPrint debug messages. I still need to finish adding: - - Building of packages we store a .tar.gz for in git. - - Package tagging. - - Keep version. (not sure how important this one is) - - Other irritating oddities Jan probably found but I haven't hit yet. Also build.py's aren't placed everywhere we have Makefiles now, I plan to do this once I have that building of .tar.gz's working. So going forward we probably should hold off on any major Makefile.git work, or at least coordinate with me so we can put it into the best place. My hope is that we can replace Makefile.git before too long. Cheers, Devan - -- Devan Goodwin [EMAIL PROTECTED] Software Engineer - Spacewalk / RHN Satellite Halifax, Canada650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkktczgACgkQAyHWaPV9my6I0QCcDrXJSh84xMy9rG/9FWm8rmSn G6gAoOgwU0/bKgllcJbiwCLdKla5OqtO =CqN5 -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] New Makefile.git(2) committed
On Tue, Nov 25, 2008 at 04:27:23PM +0100, Jan Pazdziora wrote: I've pushed new Makefile.git code to the repository. Well, I have pushed it as Makefile.git2, so if you want to try it (and I'd appreciate if you did), please do ln -sf Makefile.git2 rel-eng/Makefile.git ln -s rel-eng/Makefile After using the thing for a day and having fixed a couple more glitches, I've now replaced the original Makefile.git with the new one, so the changes are now live. It now also runs rpmlint on the resulting .rpms due to popular demand. Enjoy, -- Jan Pazdziora Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] New Makefile.git(2) committed
On Tue, Nov 25, 2008 at 04:14:32PM -0500, Jesus M. Rodriguez wrote: I'll appreciate if you try the new code and if you tell me your thoughts. How does this compare to the build.py stuff we added? While I prefer the build.py (as I can work more easily with python than make), I don't care which one ultimately we choose. If I'm not mistaken, Makefile.git is still the code we use. At least that's what the wiki suggests to do if you want to (for example) get .src.rpm from the repository. The changes I've committed this week were long in my oven, and the primary drive was to do even old builds right, by observing (for example) the NO_TAR_GZ at the correct time. The Makefile.git was modelled after Makefile.svn, which was a thing which allowed me to do 5.2.0, and which was inspired by dist-cvs. I've picked make and Makefile primarily because dist-cvs uses that, to be as compatible as possible with what you have in brew and koji. (Otherwise I'd just hack it in Perl. :-P ) By now, I consider Makefile.git pretty mature, with pieces missing mainly in the more automatic build invocation area. The reason why I did not add this (yet) was that doing the builds manually during 5.2.0 gave us more control over what is going on where and it also hinted the developer to actually check the build results. For Spacewalk, the build systems we use were (are) transforming so I really didn't know on which environment to focus. Currently, with Mirek's build-o-setup, maybe even this need is no longer of any urgence -- you just tag your package and it will get built for you automatically. I consider rewriting Makefile.git into build.py a bad idea -- it just brings another language into the mix, it puts code to packages' directories where the Makefile generally only has variable definitions, plus it will take some time to stabilize. The main concern that Devan had with Makefile.git, the readability of the code, has hopefully been addressed with the last versions of Makefile.git. However, if build.py is what you guys want and what you guys will develop and maintain, so be it. Just put the info to the wiki and I'll switch to using that. Until that happens, I'm ready to maintain and improve Makefile.git. -- Jan Pazdziora | adelton at #satellite*, #brno Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] New Makefile.git(2) committed
Hello, I've pushed new Makefile.git code to the repository. Well, I have pushed it as Makefile.git2, so if you want to try it (and I'd appreciate if you did), please do ln -sf Makefile.git2 rel-eng/Makefile.git ln -s rel-eng/Makefile Everything which worked before should be working still: make test-srpm make srpm make tgz But you can also do make spacewalk-backend-0.4.3-1.src.rpm or make spacewalk-backend-0.4.3-1.el5.src.rpm or make spacewalk-backend-0.4.2-1.tar.gz in the top level (or any) directory of the checkout and it will give you correct .src.rpm or .tar.gz from previous tags. And you can do make srpm NAME=spacewalk-backend COMMIT=12c7e6ad48b0d4693eef90cd96c694da3c2bef07 and get the .src.rpm of spacewalk-backend as it was in that commit. I'll appreciate if you try the new code and if you tell me your thoughts. -- Jan Pazdziora Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] New Makefile.git(2) committed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 25 Nov 2008 16:27:23 +0100 Jan Pazdziora [EMAIL PROTECTED] wrote: Hello, I've pushed new Makefile.git code to the repository. Well, I have pushed it as Makefile.git2, so if you want to try it (and I'd appreciate if you did), please do ln -sf Makefile.git2 rel-eng/Makefile.git ln -s rel-eng/Makefile Everything which worked before should be working still: make test-srpm make srpm make tgz But you can also do make spacewalk-backend-0.4.3-1.src.rpm or make spacewalk-backend-0.4.3-1.el5.src.rpm or make spacewalk-backend-0.4.2-1.tar.gz in the top level (or any) directory of the checkout and it will give you correct .src.rpm or .tar.gz from previous tags. And you can do make srpm NAME=spacewalk-backend COMMIT=12c7e6ad48b0d4693eef90cd96c694da3c2bef07 and get the .src.rpm of spacewalk-backend as it was in that commit. I'll appreciate if you try the new code and if you tell me your thoughts. Found a very tiny problem only with echo's, USER_NAME doesn't seem to be defined in any of the new scripts so the echos for missing changelog entries are just slightly off from what they should be. New functionality is very cool. Should prove useful for Satellite builds as well. It got a little more complex now that there's yet another entry point for building packages but I see that it does all boil down to the same places most of the time. The variable assignments remain quite hard to track but the separation into individual files helps as do the additional comments. Thanks, Devan - -- Devan Goodwin [EMAIL PROTECTED] Software Engineer - Spacewalk / RHN Satellite Halifax, Canada650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkksK2MACgkQAyHWaPV9my5MHwCgymWb6WneFAcYBSKVAF8xJdER VJ0An1sE+D4H1Me8dxu5jwNzkUIjUrsK =3AMU -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] New Makefile.git(2) committed
On Tue, Nov 25, 2008 at 12:44:15PM -0400, Devan Goodwin wrote: I'll appreciate if you try the new code and if you tell me your thoughts. Found a very tiny problem only with echo's, USER_NAME doesn't seem to be defined in any of the new scripts so the echos for missing changelog entries are just slightly off from what they should be. Fixed. -- Jan Pazdziora Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] New Makefile.git(2) committed
Jan Pazdziora wrote: Hello, I've pushed new Makefile.git code to the repository. Well, I have pushed it as Makefile.git2, so if you want to try it (and I'd appreciate if you did), please do ln -sf Makefile.git2 rel-eng/Makefile.git ln -s rel-eng/Makefile Everything which worked before should be working still: make test-srpm make srpm make tgz But you can also do make spacewalk-backend-0.4.3-1.src.rpm or make spacewalk-backend-0.4.3-1.el5.src.rpm or make spacewalk-backend-0.4.2-1.tar.gz in the top level (or any) directory of the checkout and it will give you correct .src.rpm or .tar.gz from previous tags. And you can do make srpm NAME=spacewalk-backend COMMIT=12c7e6ad48b0d4693eef90cd96c694da3c2bef07 and get the .src.rpm of spacewalk-backend as it was in that commit. I'll appreciate if you try the new code and if you tell me your thoughts. How does this compare to the build.py stuff we added? While I prefer the build.py (as I can work more easily with python than make), I don't care which one ultimately we choose. -- jesus m. rodriguez| [EMAIL PROTECTED] sr. software engineer | irc: zeus rhn satellite spacewalk | 919.754.4413 (w) rhce # 805008586930012| 919.623.0080 (c) +---+ | Those who cannot learn from history | | are doomed to repeat it. | | -- George Santayana | +---+ ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
