Re: [Spacewalk-devel] Spacewalk 0.4 update
Mike McCune wrote: I'd advocate we instead release a QA build to the public on 12/15 and do QA build aka nightly builds are released every day at: http://miroslav.suchy.cz/spacewalk/nightly-candidate/ Just make sure you tag the package when you commit some fix/feature. BTW: It seems that there is a lot of packages with some commits and which are not tagged: [EMAIL PROTECTED]/~/rhn/spacewalk.pub/rel-eng]$ ./git-untagged-commits.pl |grep HEAD SatConfig-bootstrap-server-1.13.1-1..HEAD: jabberpy-0.5-0.15..HEAD: nocpulse-common-2.0.13-1..HEAD: oracle-instantclient-selinux-10.2-2..HEAD: oracle-xe-selinux-10.2-5..HEAD: osad-0.3.2-1..HEAD: perl-Crypt-OpenPGP-1.03-15..HEAD: perl-Crypt-RIPEMD160-0.04-15..HEAD: perl-DBD-Oracle-1.21-4..HEAD: perl-NOCpulse-PersistentConnection-1.5.2-1..HEAD: rhn-custom-info-0.2.2-1..HEAD: rhn-virtualization-0.3.2-1..HEAD: rhncfg-0.3.1-1..HEAD: rhnpush-0.3.1-1..HEAD: spacewalk-0.4.2-1..HEAD: spacewalk-admin-0.4.2-1..HEAD: spacewalk-backend-0.4.5-1..HEAD: spacewalk-branding-0.1.6-1..HEAD: spacewalk-certs-tools-0.3.1-1..HEAD: spacewalk-config-0.3.3-1..HEAD: spacewalk-java-0.4.2-1..HEAD: fatal: bad revision 'spacewalk-koan-0.3.2-1..HEAD' spacewalk-proxy-0.3.3-1..HEAD: spacewalk-proxy-monitoring-0.3.2-1..HEAD: spacewalk-repo-0.3-1..HEAD: spacewalk-schema-0.4.3-1..HEAD: spacewalk-search-0.3.4-1..HEAD: spacewalk-web-0.4.2-1..HEAD: stringtree-json-2.0.9-3..HEAD: tsdb-1.27.16-1..HEAD: -- 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] Spacewalk 0.4 update
On Tue, Nov 25, 2008 at 09:20:01AM +0100, Miroslav Suchý wrote: > Mike McCune wrote: >> I'd advocate we instead release a QA build to the public on 12/15 and >> do > > QA build aka nightly builds are released every day at: > http://miroslav.suchy.cz/spacewalk/nightly-candidate/ > Just make sure you tag the package when you commit some fix/feature. > > BTW: It seems that there is a lot of packages with some commits and > which are not tagged: > [EMAIL PROTECTED]/~/rhn/spacewalk.pub/rel-eng]$ ./git-untagged-commits.pl > |grep HEAD [...] > perl-Crypt-OpenPGP-1.03-15..HEAD: > perl-Crypt-RIPEMD160-0.04-15..HEAD: Shouldn't these be gone by now? If yes, removing rel-eng/packages/perl-Crypt-OpenPGP rel-eng/packages/perl-Crypt-RIPEMD160 will pretend the packages never existed. -- 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
Re: [Spacewalk-devel] Spacewalk 0.4 update
On Tue, Nov 25, 2008 at 09:20:01AM +0100, Miroslav Suchý wrote: > Mike McCune wrote: >> I'd advocate we instead release a QA build to the public on 12/15 and >> do > > QA build aka nightly builds are released every day at: > http://miroslav.suchy.cz/spacewalk/nightly-candidate/ > Just make sure you tag the package when you commit some fix/feature. > > BTW: It seems that there is a lot of packages with some commits and > which are not tagged: > [EMAIL PROTECTED]/~/rhn/spacewalk.pub/rel-eng]$ ./git-untagged-commits.pl > |grep HEAD [...] > fatal: bad revision 'spacewalk-koan-0.3.2-1..HEAD' Mike, I can see $ git whatchanged rel-eng/packages/spacewalk-koan commit 973b88e59e5d40b6880c9e3fb3ae823400b311c2 Author: Mike McCune <[EMAIL PROTECTED]> Date: Wed Nov 5 20:46:50 2008 -0800 need a version file :00 100644 000... 3c5d699... A rel-eng/packages/spacewalk-koan So it looks like you've just created that file without running make tag-(minor-)release That did not create the git tag, which is something the other tools expect. Could you please make the tag-release (you can use KEEP_VERSION=0.3.2-1 option if you do not want the version changed)? Thanks, -- 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
Re: [Spacewalk-devel] Spacewalk 0.4 update
Jan Pazdziora wrote: perl-Crypt-OpenPGP-1.03-15..HEAD: perl-Crypt-RIPEMD160-0.04-15..HEAD: Shouldn't these be gone by now? If yes, removing Indeed. rel-eng/packages/perl-Crypt-OpenPGP rel-eng/packages/perl-Crypt-RIPEMD160 will pretend the packages never existed. Removed. What did you say, that did not existed? :) -- Miroslav Suchy RHN Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Reason why we should use dist-5E-sw-0.4
Right now we build into tag dist-5E-sw-0.4-candidate. When I have been working on that nightly repo I find one good reason why we should use tag dist-5E-sw-0.4 and only successful builds tagged there from dist-5E-sw-0.4-candidate. The reason are nightly builds. Now the package get into nightly repo only if you tagged that package in git. If you do not tagged it there we have two possibility how to build the package. 1) Automatically tag the package in git and current script will then automatically pick it up for rebuild. Honestly - I do not like such option. 2) Create tag dist-5E-sw-0.4. Normally build into dist-5E-sw-0.4-candidate as now and unsuccessful builds tag into dist-5E-sw-0.4. Final Spacewalk create from dist-5E-sw-0.4 tag. For nightly builds, let call "make test-srpm" on untagged packages and build in koji the packages with .git.longsha1 dist tag. This way you make sure when somebody finally tag the package (which bump up the version automatically) such package will be upgraded to last version. I prefer this option. 3) OK. There is third option. To build .git.longsha1 packages in dist-5E-sw-0.4-candidate and not creating dist-5E-sw-0.4. But it will create only mess. I'm scratching such option. How do you like it? Or do you have another idea how to implement nightly builds? -- 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] multiarch - SSM remove packages issue
Jason Dobies wrote: I ran into a wall while adding multiarch support to the SSM remove packages flow. Currently, we store the packages the user selects into an rhnSet. When determining on which servers the selected packages exist, the query uses the rhnSet of packages and the set of systems to let the DB do all the heavy lifting. The problem is in the two element approach in rhnSet; there's no room for arch (it's currently holding the name ID and evr ID in the two slots). This keeps me from using rhnSet to hold the packages for that query (I can easily hang on to them in memory with SessionSet). Likewise, an IN clause is probably out for all of the reasons I'm sure we've hit a number of other places. So I'm kinda stuck. Any ideas are appreciated. Ehm... Why do you need to store arch in db in first place? I though that the process should be: 1. choose in SSM packages to remove 2. store them name and evr in rhnset. 3. foreach machine in SSM do select name_id, evd_id, package_arch_id from RHNSERVERPACKAGE where server_id=machine delete on machine the package(name_id, evd_id, package_arch_id) -- 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] Spacewalk 0.4 update
Mike McCune wrote: Jesus M. Rodriguez wrote: Hey Spacewalk hackers, I'd like to wrap up feature and bug fixing by 12/5 so that we can start the package building process on Monday 12/8 for a release on 12/15. Let me know if this will be a problem. Feature freeze: 12/5 Packages: 12/9 QA freeze: 12/12 Release: 12/15 I'm thinking since the scope of features in 0.4 is much much larger than the previous releases we are going to need to spend more time in testing (multiorg and cobbler-koan come to mind) I'd advocate we instead release a QA build to the public on 12/15 and do the final release on say ... 12/22? Or after the break? I realize I'm calling for us to be late but it seems rational to me. Anyone else agree/disagree? Also don't forget that we have a feature called "multiarch enhancements" for 0.4 which needs extensive testing as its a revamp of existing functionality to use arch info in a bunch of areas. This IMHO is highly regression prone and needs rigorous testing as well. Also we have stored profile devel work still in progress for 0.4 so I think 12/15 would be pretty tight to get this feature wrapped up and tested enough within the next two weeks into 0.4. Thanks, ~ Prad ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk 0.4 update
Partha Aji wrote: Mike McCune wrote: Jesus M. Rodriguez wrote: Hey Spacewalk hackers, I'd like to wrap up feature and bug fixing by 12/5 so that we can start the package building process on Monday 12/8 for a release on 12/15. Let me know if this will be a problem. Feature freeze: 12/5 Packages: 12/9 QA freeze: 12/12 Release: 12/15 I'm thinking since the scope of features in 0.4 is much much larger than the previous releases we are going to need to spend more time in testing (multiorg and cobbler-koan come to mind) I'd advocate we instead release a QA build to the public on 12/15 and do the final release on say ... 12/22? Or after the break? I realize I'm calling for us to be late but it seems rational to me. Anyone else agree/disagree? +1. The cobbler koan feature will require significant testing w.r.t provisioning especially. 12/15 release at this point seems a bit too optimistic IMHO. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel We do still have quite a bit of work in progress and to be done for the multiarch enhancements. At current this includes SSM remove/verify/upgrade packages as well as Stored System Profile creation/comparisons/syncing...etc. As part of many of these enhancements we are porting perl pages to java. This work is currently being done in a remote branch (origin/multiarch) and our goal is to complete by 12/5; however, there is a risk that we won't complete by then given the amount of work remaining. That said, we would be in better shape if went out on 12/15 as mentioned above or waited to merge in multiarch as part of a SW 0.5. ___ 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
[Spacewalk-devel] Re: Updating koan for SSL, and other port things..
Michael DeHaan wrote: > Justin Sherrill wrote: > >> Hi All, >> >> Currently when you specify a port for koan it: >> >> 1. Tries port 80, if that fails: >> >> > > Yes, specifically it tries http://$server:80/cobbler_api_rw first, which > is the Apache proxied endpoint. > > If that fails, the usage of port is for a direct connection, not using > Apache proxying. > > (Also, if --server=DISCOVER is set it will try looking through Avahi > before doing either) > > > >> 2. Tries the port you specified. >> >> > > > > >> I'm changing it such that it will: >> >> 1. Try the port you specify, if that fails: >> 2. Tries port 80. >> >> >> Also, I'm adding support for SSL. Would koan users prefer: >> >> a. A '--ssl' option that tries on SSL if specified >> >> > > I am not sure there is a good reason at all to let koan use SSL. All of > the data koan retrieves is available over non-secured protocols (TFTP > for starters, and HTTP) so there is nothing to hide. I think trying the > specified port first makes sense. > For spacewalk integration this is a requirement IMHO. Spacewalk/satellite as it is today allows provisioning over pure SSL which is a requirement for many of our customers. I've heard many hair-brained network security schemes from customers that require this (not provisioning specifically, but just their traffic in general). If you look at what just koan is doing, i agree there isn't any reason for it to be encrypted. If you look what koan could be a part of then there is benefit of having the entire process be encrypted. -Justin > >> b. if 443 is passed in try on 443 with SSL, if that fails try on port >> 80 w/o SSL >> >> >> > How about if the XMLRPC port connection fails because the port is > encrypted (with an appropriate exception which I suspect the XMLRPC > module should raise), trying to treat the port as an SSL connection? > > --Michael > > >> -Justin >> ___ >> cobbler mailing list >> [EMAIL PROTECTED] >> https://fedorahosted.org/mailman/listinfo/cobbler >> >> > > ___ > cobbler mailing list > [EMAIL PROTECTED] > https://fedorahosted.org/mailman/listinfo/cobbler > ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Re: Updating koan for SSL, and other port things..
Justin Sherrill wrote: > Michael DeHaan wrote: > >> Justin Sherrill wrote: >> >> >>> Hi All, >>> >>> Currently when you specify a port for koan it: >>> >>> 1. Tries port 80, if that fails: >>> >>> >>> >> Yes, specifically it tries http://$server:80/cobbler_api_rw first, which >> is the Apache proxied endpoint. >> >> If that fails, the usage of port is for a direct connection, not using >> Apache proxying. >> >> (Also, if --server=DISCOVER is set it will try looking through Avahi >> before doing either) >> >> >> >> >>> 2. Tries the port you specified. >>> >>> >>> >> >> >> >>> I'm changing it such that it will: >>> >>> 1. Try the port you specify, if that fails: >>> 2. Tries port 80. >>> >>> >>> Also, I'm adding support for SSL. Would koan users prefer: >>> >>> a. A '--ssl' option that tries on SSL if specified >>> >>> >>> >> I am not sure there is a good reason at all to let koan use SSL. All of >> the data koan retrieves is available over non-secured protocols (TFTP >> for starters, and HTTP) so there is nothing to hide. I think trying the >> specified port first makes sense. >> >> > For spacewalk integration this is a requirement IMHO. > Spacewalk/satellite as it is today allows provisioning over pure SSL > which is a requirement for many of our customers. I've heard many > hair-brained network security schemes from customers that require this > (not provisioning specifically, but just their traffic in general). > > If you look at what just koan is doing, i agree there isn't any reason > for it to be encrypted. If you look what koan could be a part of then > there is benefit of having the entire process be encrypted. > > -Justin > > >> >> >>> b. if 443 is passed in try on 443 with SSL, if that fails try on port >>> 80 w/o SSL >>> >>> >>> >>> >> How about if the XMLRPC port connection fails because the port is >> encrypted (with an appropriate exception which I suspect the XMLRPC >> module should raise), trying to treat the port as an SSL connection? >> The exception that gets thrown is an ExpatError (error parsing the xml). Not sure if this is a great indication or not... -Justin >> --Michael >> >> >> >>> -Justin >>> ___ >>> cobbler mailing list >>> [EMAIL PROTECTED] >>> https://fedorahosted.org/mailman/listinfo/cobbler >>> >>> >>> >> ___ >> cobbler mailing list >> [EMAIL PROTECTED] >> https://fedorahosted.org/mailman/listinfo/cobbler >> >> > > ___ > Spacewalk-devel mailing list > Spacewalk-devel@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-devel > ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] schema upgrade required
I added a few new schema upgrades to master: spacewalk/schema/spacewalk/upgrade/spacewalk-0.3-spacewalk-0.4 132-rhnActionKickstartGuest-add-kshost.sql 133-rhnKickstartVirtualizationType-update.sql 134-rhnKickstartDefaults-virt-fields.sql you will need these ran against your schema if you want kickstarts to function. A rebuild of the schema works too. Mike -- Mike McCune mmccune AT redhat.com Engineering | Portland, OR RHN Satellite | 650.567.9039x79248 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk 0.4 update
Jan Pazdziora wrote: On Tue, Nov 25, 2008 at 09:20:01AM +0100, Miroslav Suchý wrote: Mike McCune wrote: I'd advocate we instead release a QA build to the public on 12/15 and do QA build aka nightly builds are released every day at: http://miroslav.suchy.cz/spacewalk/nightly-candidate/ Just make sure you tag the package when you commit some fix/feature. BTW: It seems that there is a lot of packages with some commits and which are not tagged: [EMAIL PROTECTED]/~/rhn/spacewalk.pub/rel-eng]$ ./git-untagged-commits.pl |grep HEAD [...] fatal: bad revision 'spacewalk-koan-0.3.2-1..HEAD' Mike, I can see $ git whatchanged rel-eng/packages/spacewalk-koan commit 973b88e59e5d40b6880c9e3fb3ae823400b311c2 Author: Mike McCune <[EMAIL PROTECTED]> Date: Wed Nov 5 20:46:50 2008 -0800 need a version file :00 100644 000... 3c5d699... A rel-eng/packages/spacewalk-koan So it looks like you've just created that file without running make tag-(minor-)release That did not create the git tag, which is something the other tools expect. Could you please make the tag-release (you can use KEEP_VERSION=0.3.2-1 option if you do not want the version changed)? Thanks, done and pushed! -- Mike McCune mmccune AT redhat.com Engineering | Portland, OR RHN Satellite | 650.567.9039x79248 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] git repo reorg
Ok now that I have your attention :) a few questions: 1) is there a reason gzipstream is its own directory? can we move it under projects? 2) there are a number of 'scripts' that are in the scripts directory which came from 108. Is ok if we move those to the contrib directory? That way we can keep all contributions in a single place. If no one objects, I'll move these on Monday. -- 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
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
Re: [Spacewalk-devel] git repo reorg
Jesus M. Rodriguez wrote: Ok now that I have your attention :) a few questions: 1) is there a reason gzipstream is its own directory? can we move it under projects? unknown to me 2) there are a number of 'scripts' that are in the scripts directory which came from 108. Is ok if we move those to the contrib directory? That way we can keep all contributions in a single place. #2 - please do! :) Check that nothing on wiki points directly to old locations, if possible :) google search it.. Cliff If no one objects, I'll move these on Monday. -- Clifford Perry Manager, Satellite Engineering Red Hat, Inc. http://www.redhat.com/ +1 919 754 4403 RHCA / RHCE# 805007680128201 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] schema upgrade required
On Tue, Nov 25, 2008 at 2:12 PM, Mike McCune <[EMAIL PROTECTED]> wrote: > I added a few new schema upgrades to master: > > spacewalk/schema/spacewalk/upgrade/spacewalk-0.3-spacewalk-0.4 > > 132-rhnActionKickstartGuest-add-kshost.sql > 133-rhnKickstartVirtualizationType-update.sql > 134-rhnKickstartDefaults-virt-fields.sql Is this just a sqlplus spacewalk/spacewalk @132-rhnActionKic? I remember some 'updater' script, how do we use that? Also, is the above script, if it exists, documented on the wiki? thanks jesus ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Reason why we should use dist-5E-sw-0.4
On Tuesday 25 November 2008 04:56:36 am Miroslav Suchý wrote: > Right now we build into tag dist-5E-sw-0.4-candidate. When I have been > working on that nightly repo I find one good reason why we should use > tag dist-5E-sw-0.4 and only successful builds tagged there from > dist-5E-sw-0.4-candidate. The reason are nightly builds. > > Now the package get into nightly repo only if you tagged that package in > git. If you do not tagged it there we have two possibility how to build > the package. I think we can assume if its not tagged that means that the work is not complete and not ready to be built or tested. > 1) Automatically tag the package in git and current script will then > automatically pick it up for rebuild. > Honestly - I do not like such option. I do not like that either > 2) Create tag dist-5E-sw-0.4. Normally build into > dist-5E-sw-0.4-candidate as now and unsuccessful builds tag into > dist-5E-sw-0.4. Final Spacewalk create from dist-5E-sw-0.4 tag. > For nightly builds, let call "make test-srpm" on untagged packages and > build in koji the packages with .git.longsha1 dist tag. > This way you make sure when somebody finally tag the package (which bump > up the version automatically) such package will be upgraded to last > version. I prefer this option. Im assuming that you mean moving successful builds into dist-5E-sw-0.4 I honestly do not like how when you tag something it bumps the release. I fell that when we do a release all tarballs should be that release so for 0.4 we should have spacewalk-java-0.4.0.tar.gz or spacewalk-java-0.4.0.tar.bz2 and bug fixes in the 0.4 series get 0.4.1 etc every other open source project ive worked with (mysql does something simmiliar to how spacewalk is working) uses RCS snapshots for prerelease testingor in the case of gnome and KDE for 0.4 they would use 0.3.85 etc, I can live with how it currently is though. > 3) OK. There is third option. To build .git.longsha1 packages in > dist-5E-sw-0.4-candidate and not creating dist-5E-sw-0.4. But it will > create only mess. I'm scratching such option. > > How do you like it? Or do you have another idea how to implement nightly > builds? tag dist-5E-sw-0.4 already exists once we get closer to release and start doing QA on the release, i envisioned running koji move-tag on everything in candidate at that time to dist-5E-sw-0.4. we would then sign the packages and do the composes on dist-5E-sw-0.4 which would be what gets pushed out as 0.4. the composes from the candidate tags are testing repos. I expect that the repos from the candidate tags can be used to prove that your build fixes the bugs or adds the features that they are supposed to. and once proven we will move to dist-5E-sw-0.4, sign the package and push it out. I do not thing we are that far away from teh same goals. I just think that doing builds needs to be the deliberate action of an engineer. We can and should make "make tag" do the build also. Dennis ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
