Re: [Spacewalk-devel] Re: Package: spacewalk-backend-0.2.5-1.el5.sw Tag: spacewalk-5E-0.2-candidate Status: complete Built by: jesusr
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 10 Sep 2008 16:07:51 +0200 Jan Pazdziora <[EMAIL PROTECTED]> wrote: > On Wed, Sep 10, 2008 at 08:50:54AM -0400, Jesus M. Rodriguez wrote: > > > > Sigh. I just did a git push. Is there an easy way to determine > > if I've pushed something or not? i.e. "show me pending commits" > > I use > > gitk --all & > > If the green does not point to the same as the grey-green > remotes/origin/, then the branch was not pushed. > Courtesy of jbowes: git log --pretty=oneline origin/master..master 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) iEYEARECAAYFAkjH2jEACgkQAyHWaPV9my7CygCeKkEfQYp/bW1G1Y/xwE+MCIkJ MesAnikPMXJzGchWX4UQUePmlH9PTsRO =L9Dt -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] #spacewalk-devel on Freenode Open for Business
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Some discussion today leading us to believe we might have use for a more development centric chat room with less user noise. As such we've registered and opened up #spacewalk-devel and invite all interested in spacewalk development to join and take part. 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) iEYEARECAAYFAkjc/bEACgkQAyHWaPV9my4RmACgpSbvrKUWmOa5DRBIgbkLdpB6 DMUAoJevWK6D+22K0/KFejRcVDfTbN5C =d04Q -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] API call 'system.config.lookupFileInfo'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 9 Oct 2008 11:43:31 +0800 "Coe, Colin C. (Unix Engineer)" <[EMAIL PROTECTED]> wrote: > > I know that this email has gone on for a while but we're nearly done > now. So the problem is with the call to > 'server.getLocalOverride().getId()' returning some value other than > the value of the config channel ID (could be the config file's ID). > > Could one of the Satellite/Spacewalk dev's have a look at this and > fill in the blanks? I'm really not sure what should be called > instead of 'server.getLocalOverride().getId()' but I really need this > API call working in Satellite. > > Thanks > > CC > > PS: On a related note, the API call configchannel.lookupFileInfo > doesn't return the file contents even though the docs state that it > should. The attached patch fixes this. > Patch applied and pushed to git master. Apparently file contents was never being returned, and even the reference to it in the XMLRPC docs was lost between 5.1.1 and spacewalk. Are you ok with the channel ID now? Based on IRC conversation it looked like you discovered it was a configuration channel ID, not a software channel ID. Let us know if there are any further issues with this. 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) iEYEARECAAYFAkjuJ0QACgkQAyHWaPV9my5fpgCeJc8on5pO7bCUcC0ZRzGLLjqo kHoAnRcM23AbmVi/jiEGloJefUZkGAru =3hE+ -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Git help needed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gotta be careful same as you would with svn before. Review your changes and don't do a blanket "git commit -a" if there are config files involved. Instead you can do: git commit file1 file2 file3 or git add file1 git add file2 git commit (no -a) I don't know of anything to do it automatically. If it boils down to looking for a way to have git never commit changes to a file we've told it to track changes on, I'd be kind of surprised if there is such a thing. Not thrilled with live config files coming from git repos, maybe we could rename the files in git to "file.conf.default" or something like that, and explicitly copy it for live use. Then of course we'd have to manually keep them in sync. :( Afaik there's not much you can do aside from review your commit changes carefully. Cheers, Devan On Tue, 14 Oct 2008 10:04:53 -0400 Partha Aji <[EMAIL PROTECTED]> wrote: > I have run into this issue too.. I have accidentally committed > config files in the past that I changed custo to my machine.. Does > any one know whats a good way to ask git to commit every thing but > this config file?.. My problem is I use branches and then merge to > the main branch, so generally the commit I make tend to be very big, > copy pasting 20 lines 1 at a time is too much work. Whats a good way > to say ignore my rhn.conf, log4j.properties, config.py in > git?... .gitignore doesnot work becasue the file is tracked in git.. > I can make up a script to ignore but I am sure there's a git way to > ignore config files.. > > Partha > > Jesus M. Rodriguez wrote: > > John, > > > > Looks good, one minor nit. Don't check in the log4j.properties with > > DEBUG turned on :) this is the file we ship in the rpm. > > http://git.fedorahosted.org/git/?p=spacewalk.git;a=commitdiff;h=b682c19120f2cf6bc5aa4f1c717cc9a67606a5d9 > > > > jesus > > > > ___ > > 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 - -- Devan Goodwin <[EMAIL PROTECTED]> Software Engineer - Spacewalk / RHN Satellite Halifax, Canada650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj0tzgACgkQAyHWaPV9my5CwACgjqDjfDFObE7/ZkLFW6s2X1+W o/wAn1nRMiyUhBsoTp//F751u7Ww8L0/ =rDzn -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] tar.gz files and nightly builds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 17 Oct 2008 09:43:32 +0200 Miroslav Suchý <[EMAIL PROTECTED]> wrote: > It seems that we should provide tar.gz (see Original Message on > bottom for Dennis reasoning). I disagree, but I'm not the one who do > the review. > > Dennis, can you provide us some tool for building tar.gz from our > revision control? I suggest you to start with "make > git-archive-to-tar-gz" target, which do the tar, but name it with > current revision. Almost did exactly this a couple days ago, added a target for "make tgz" but it behaves like make srpm and names the tgz with the current package version. (as opposed to the current git revision) IIRC git-archive-to-tar-gz already does do that with the current revision, just needs some slight modifications to copy the resulting file somewhere sane. > > Additionaly - can we have some web space where we can put the tar.gz > files? And if we can have nightly build somewhere too, it would be > cool. > > Mirek > > > Original Message > Subject: [Bug 453109] Review Request: nocpulse-common - Add NOCpulse > users and includes common files for NOCpulse. > Date: Fri, 17 Oct 2008 02:32:01 -0400 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > References: <[EMAIL PROTECTED]> > > Please do not reply directly to this email. All additional > comments should be made in the comments box of this bug. > > > https://bugzilla.redhat.com/show_bug.cgi?id=453109 > > > > > > --- Comment #13 from Dennis Gilmore <[EMAIL PROTECTED]> 2008-10-17 > 02:32:00 EDT --- > http://fedoraproject.org/wiki/Packaging/SourceURL#We_are_Upstream > says "There > is no public revision control system or publically released tarball > for these > programs so there is no tarball to list" there is a public revision > control system, and im saying there should be public tarballs. this > is something that > could be useful and useable by more than spacewalk. spacewalk could > also end > up in other distros. a traball should be provided. > > otherwise it looks good. > - -- Devan Goodwin <[EMAIL PROTECTED]> Software Engineer - Spacewalk / RHN Satellite Halifax, Canada650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj4gu8ACgkQAyHWaPV9my5WkQCg0Knxl4MV24S8nazjB6yDdpRB lVgAn22l4DdvnghIGTVzLu6p1HRm2+ZB =+Xpx -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Re: First draft of a new build system for Spacewalk.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 29 Oct 2008 12:11:38 +0100 Miroslav Suchý <[EMAIL PROTECTED]> wrote: > > <http://git.fedorahosted.org/git/?p=spacewalk.git;a=commitdiff;h=938ca0f0c10f18af4784aa6aed1c38e26feb5a33> > > > > > > First draft of a new build system for Spacewalk. > > > > Created out of the need to build Satellite packages based on > > Spacewalk, this code may replace the Makefile.git we use today > > depending on how things go. > > > > Code currently only working with ./build.py --tgz in the java > > project. Other options coming soon as well as build.py's for the > > various sub-projects to replace Makefiles. > > > > * [DH] java/build.py > > * [DH] rel-eng/pybuilder/pybuilder.py > > What is wrong on current Makefile? > Why we need to have rewritten to Python? > Basically because we need some work done to it (Satellite tooling), there's nobody else to do it, and I can't get things done with it in Makefiles. The syntax is like greek to me and the more I tried to learn it the less I felt it was suitable for the task at hand. I don't mind it for compilation so much but when you start getting up near a third path of execution through it (all controlled by variables), auto-editing spec files and committing the result, and interacting heavily with git tags, I felt a more powerful scripting language was a better fit. I'm also hoping the end result will be something more of the team can look at and understand how to work with. (not sure) I saw that it was only 250 lines and most of the commands could be re-used and decided to go for it. Devan - -- Devan Goodwin <[EMAIL PROTECTED]> Software Engineer - Spacewalk / RHN Satellite Halifax, Canada650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkIT1AACgkQAyHWaPV9my767gCgjIyOMAII5TYS4ALDcpUqMqy5 2dQAmgJg/5Z3iqJ+xhkzNPp04sFds5qX =ooUr -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Nightly builds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 30 Oct 2008 14:31:11 +0100 Miroslav Suchý <[EMAIL PROTECTED]> wrote: > I prepared nighlty builds: > http://miroslav.suchy.cz/spacewalk/rawhide/ > http://miroslav.suchy.cz/spacewalk/rawhide-candidate/ > > It is created from packages in spacewalk-5E-[lastversion] resp. > spacewalk-5E-[lastversion]-candidate tags in Brew. > It does not automatically build the needed packages (yet). You have > to build yourself for now. > > Repos are updated at 8.30 and 12.30 CET (which is 2.30 and 6.30 EDT). > Nice! This could be great for dev machines. d - -- Devan Goodwin <[EMAIL PROTECTED]> Software Engineer - Spacewalk / RHN Satellite Halifax, Canada650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkJwTUACgkQAyHWaPV9my5xzgCg0WCf+B4uYKnnCbOMjERVy2kv 0qEAoKBZf8VYRJtNfEG19HuTCG6J6CVL =8sdS -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] rhnSQL errors in master
a cursor and calling execute on that, I must have grepped bad. (or possibly recklessly) Push away! (although if you get a conflict I've fixed it and pushed as well in attempting to resolve that earlier issue) :) > > yea I think we need that for stuff for sql queries to work. Anyhu I > think these were changes from postgres pre clean up work dgoodwin > was working on. So I'll let him say the word. But jus wanna say, we > should not be committing this into master yet. Probably working in a > branch until its stable would be easier so we can avoid these > regressions. This work was done in a branch originally and brought back when I *thought* it was stable and as soon as 0.3 was released. My apologies if it's causing major problems. I was nervous to leave it in a long term branch due to massive refactors that were going to cause big conflict troubles if the code got touched in master. Considering all the postgresql stuff just sits by the wayside I figured it would be best to merge sooner rather than later and expose anything I missed. (as that bullet has to be bitten at some point regardless, post-0.3 seemed like as good a time as any) This make sense? Let me know if others disagree and I can prevent this in the future. I think the real mistake here is I should have rebuilt my own test rpms and plugged them into a live spacewalk server before merging in. I've just been testing with scripts that talk straight to rhnSQL, which in hindsight was unwise. :) Devan - -- Devan Goodwin <[EMAIL PROTECTED]> Software Engineer - Spacewalk / RHN Satellite Halifax, Canada650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkhd+EACgkQAyHWaPV9my6p7gCffYiHyKaO+YzPWIC6GFVMpxRg qx8An3+Q9XTl4k2RqfggS28nUbPyF4Nt =mwSD -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Dep Issues Installing From 0.4 Devel Repos
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Running into the following problems which are preventing from installing spacewalk from the devel repo at http://miroslav.suchy.cz/spacewalk/nightly-candidate/. - --> Finished Dependency Resolution Error: Missing Dependency: perl(DBD::Oracle) is needed by package spacewalk-base Error: Missing Dependency: perl(NOCpulse::DBRecord) is needed by package SatConfig-generator Error: Missing Dependency: perl(NOCpulse::NPRecords) is needed by package SatConfig-installer Error: Missing Dependency: rhnpush is needed by package spacewalk Error: Missing Dependency: perl(NOCpulse::Database) is needed by package tsdb Error: Missing Dependency: perl(NOCpulse::NPRecords) is needed by package perl-NOCpulse-Scheduler Error: Missing Dependency: perl(DBD::Oracle) is needed by package NPalert Error: Missing Dependency: perl(NOCpulse::CF_DB) is needed by package eventReceivers Error: Missing Dependency: perl(NOCpulse::CF_DB) is needed by package SputLite-server Error: Missing Dependency: perl(NOCpulse::Database) is needed by package scdb E rror: Missing Dependency: perl(NOCpulse::NPRecords) is needed by package NOCpulsePlugins Error: Missing Dependency: python(:DBAPI:oracle) is needed by package spacewalk-backend-sql Error: Missing Dependency: perl-NOCpulse-OracleDB is needed by package spacewalk Error: Missing Dependency: perl(NOCpulse::NPRecords) is needed by package SatConfig-bootstrap-server Error: Missing Dependency: nocpulse-db-perl is needed by package spacewalk Error: Missing Dependency: perl(NOCpulse::NPRecords) is needed by package SNMPAlerts Error: Missing Dependency: perl(NOCpulse::NPRecords) is needed by package MessageQueue Error: Missing Dependency: perl(NOCpulse::NPRecords) is needed by package SatConfig-generator Error: Missing Dependency: perl(DBD::Oracle) is needed by package perl-NOCpulse-Probe Any thoughts? 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) iEYEARECAAYFAkkjB3wACgkQAyHWaPV9my7K/ACfYzqw3iYYuZ+wlaF1OI+eYdXh XaoAoK0TslkHgSF4JA6HrWgI54VChoNl =HGNO -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] API version
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 20 Nov 2008 09:43:39 -0500 Brad Buckingham <[EMAIL PROTECTED]> wrote: > I am, however, a little unclear on the proposed bumping of the API > version. Is it necessary to bump it for each API that added during > the course of a development cycle? Or is it sufficient just to bump > it once for each Spacewalk release? If we bump it for new APIs, do > we also have to bump it for every API modification? > > The reason that I ask is that we don't bump the Spacewalk version for > every change that is submitted to it. I also suspect that over time > many folks will forget to bump the API version as they submit changes > to the APIs, so the might become less reliable/useful. Agreed, during a devel cycle I can't imagine anyone who's relying on the API version for unreleased spacewalk code and needs to know (progrematically) when a new API call is added or a signature changes. IMO we should up the API version once and only once per spacewalk release. (either right before it goes out the door, or right after the last release is made, actually the latter sounds better) Even if there are API bugfixes post-release they won't be changing the signature for calls and thus no need for a minor version increase. (if I understand the purpose of API version anyhow) Devan Devan - -- Devan Goodwin <[EMAIL PROTECTED]> Software Engineer - Spacewalk / RHN Satellite Halifax, Canada650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkklhEkACgkQAyHWaPV9my57AQCgmtUO0+xDKgYJasIYFW7x7rqd 2xsAn2VqBq7h1lcUVwFFHoAmyC82doUf =52mC -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Git Book
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Saw this come across an RSS feed somewhere last night, looks very good and easy to read. Thought it might be of interest to some of our devs: http://book.git-scm.com/ Lots of good stuff on git usage and it's internals in relatively straightforward language. 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) iEYEARECAAYFAkklmtMACgkQAyHWaPV9my7AEACguusd3Dcj1zrR9+KoT0E+9H8y nWcAoLIHY6p3EPLx0uGlR2CaG02Gnoyu =4oS4 -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
-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] Reason why we should use dist-5E-sw-0.4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 26 Nov 2008 14:23:15 +0100 Jan Pazdziora <[EMAIL PROTECTED]> wrote: > > To summarize: from my point of view building test-srpm (the > .git.longsha1) packages to dist-5E-sw-0.4-candidate is > counterinuitive. It has that longsha1 in its name for a reason, to > warn everybody that it was built from some random commit, not signed > off by the developer (via make tag-release). If you start feeding > them to dist-5E-sw-0.4-candidate, before long they will make their > way to dist-5E-sw-0.4 and you will see things like > SatConfig-general-1.215.38-7.git.4c57d3b9f251dd5dc7113ecf37c30cecbb6d88c1.i386.rpm > > in our yum repo. > > Other guys might have different opinion. > Just to chime in with my preference, I think I'd prefer to have it remain largely as we do today. - - Require manual package rebuilds. (assign people to keep a loose eye on certain packages if there's a genuine problem with no re-builds taking place) - - Keep the version going up for each internal rebuild. Yes we release spacewalk-package-0.4.159 but I like that each new version signifies a new tarball inside and we don't have to do any fancy patching. Even if we decided on a way to bump versions during devel cycle but then go to 0.4.0 at release would be nice. - - I'm not really keen on test-rpms appearing anywhere. I'd rather just keep using these as a developer tool and anything appearing in repos be versioned normally. Having the devel repo contain only packages that *somebody* decided to manually tag seems good to me. Devan - -- Devan Goodwin <[EMAIL PROTECTED]> Software Engineer - Spacewalk / RHN Satellite Halifax, Canada650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkktbTYACgkQAyHWaPV9my7WggCfQW/ehHlEXdwtW5YeH19jOtrC 1rEAn2WowCGyPVcoPqFq5+LYWyJz55W9 =Kl2h -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
-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
-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
[Spacewalk-devel] PostgreSQL Git Branch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 PostgreSQL git branch is now up and named "pgsql": git branch --track pgsql origin/pgsql && git checkout pgsql The old branch (named "postgresql") has been removed, it contained too much experimental code that has since been deemed unnecessary so we decided to just port over the small diff of changes against master as most of the non-intrusive work has been merged back already. Branch has been renamed to prevent any git problems for people tracking the old branch name. I hope to soon have a small package repo built and hosted which can be used in addition to the nightly devel repo for testing the PostgreSQL work in a live install. Cheers, Devan - -- Devan Goodwin Software Engineer - Spacewalk / RHN Satellite Halifax, Canada650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklHyzkACgkQAyHWaPV9my7WnACgmHv91r+rFLLBj+okVINBRtRG uNUAn3be7+PJyw93tItnuS92r2LedPof =Ee4q -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Re: PostgreSQL Git Branch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 16 Dec 2008 11:04:02 -0500 (EST) Bruce Momjian wrote: > Would you please supply a URL that I can reference for the checkout, > like: > > git clone git://git.fedorahosted.org/spacewalk.git/ > You've got it right there. :) Well almost, that would be for those not planning to commit, if you have commit access you'd use: git clone ssh://yourfedorausern...@git.fedorahosted.org/git/spacewalk.git/ When you clone a git repo you're setup for all the remote branches so clone as you do above, then run the commands in original email and you'll be looking at the PostgreSQL branch. Cheers, Devan - -- Devan Goodwin Software Engineer - Spacewalk / RHN Satellite Halifax, Canada650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklH0rcACgkQAyHWaPV9my7eowCeN1CtOQHIdnIBOUHSHRNFyuZc ogkAoLzt3hV3sbmktSYzED5v4CIrue5v =/8nO -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Building RPMs w/ build.py
I think the build.py script for building spacewalk packages is ready for some wider testing. At this point the functionality should be roughly equivalent to the Makefile.git. If you're looking to build spacewalk packages the script is located in rel-eng/bin/build.py. To use it just cd to the project you want to build and call the script via full path, or add it to your PATH variable and make your life easier. cd java/ build.py --srpm Also if you'd prefer to have your packages built somewhere *other* than the current working directory (which is very useful) Jan's setup for configuring this still works: (dgood...@elaine)[~/src/spacewalk] % cat ~/.spacewalk-build-rc RPMBUILD_BASEDIR = /tmp/spacewalk-build Usage is: (dgood...@elaine)[~/src/spacewalk] % 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=DIST dist tag to apply to srpm and/or rpm (i.e. .el5) --test Use current branch HEAD instead of latest package tag. --no-cleanupDo 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) --debug Print debug messages. --tag-release Tag a new release of the package. (i.e. x.y.z-R+1 --keep-version Use spec file version/release to tag package. Combine --test with --rpm or --srpm to replicate the functionality of make test-rpm. Please note that anyone can build tgz, srpm, or rpm, but the tagging of packages should really only be done by those with commit access. (you can still do it, the tags will just be meaningless and cause conflicts when someone tags the same version you have locally) Please let me know if you see any problems, or if there's anything else you'd like to be added. Thanks, Devan ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Building RPMs w/ build.py
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 16 Dec 2008 19:15:22 +0100 Michael Mraka wrote: > Devan Goodwin wrote: > ... > % (dgood...@elaine)[~/src/spacewalk] % 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=DIST dist tag to apply to srpm and/or rpm (i.e. .el5) > % --test Use current branch HEAD instead of latest package > tag. % --no-cleanupDo 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) > % --debug Print debug messages. > % --tag-release Tag a new release of the package. (i.e. x.y.z-R+1 > > So this is equivalent of 'make tag-minor-release'. Is there a way how > to achieve 'make tag-release' behaviour (i.e. x.y.(z+1)-1)? > I'd suggest renaming to --tag-minor-release to be compatible with > make. > > % --keep-version Use spec file version/release to tag package. > % > % Combine --test with --rpm or --srpm to replicate the functionality > of % make test-rpm. > > > -- > Michael Mráka > Satellite Engineering, Red Hat > > ___ > Spacewalk-devel mailing list > Spacewalk-devel@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-devel build.py --tag-release should just figure out whether or not you want a minor or major release. It became apparent that for any given sub-project we only really allow one type (major or minor) so the code now will figure out which to do based on some metadata in build.py.props. (if it's required, if not specified we assume make tag-release) Just noticed my help msg for --tag-release is out of date, will update this. Thanks, Devan - -- Devan Goodwin Software Engineer - Spacewalk / RHN Satellite Halifax, Canada650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklH9pYACgkQAyHWaPV9my4rywCfbgHmSPZJzFcu7v6Jen90Uyk+ lM4Anj88rN0Zp5OK8nKHR8Cmwm1kyskO =mrfc -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Building RPMs w/ build.py
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 17 Dec 2008 13:50:04 +0100 Jan Pazdziora wrote: > On Tue, Dec 16, 2008 at 12:27:04PM -0400, Devan Goodwin wrote: > > I think the build.py script for building spacewalk packages is ready > > for some wider testing. At this point the functionality should be > > roughly equivalent to the Makefile.git. If you're looking to build > > spacewalk packages the script is located in rel-eng/bin/build.py. > > > > To use it just cd to the project you want to build and call the > > script via full path, or add it to your PATH variable and make your > > life easier. > > > > cd java/ > > build.py --srpm > > > > Also if you'd prefer to have your packages built somewhere *other* > > than the current working directory (which is very useful) Jan's > > setup for configuring this still works: > > > > (dgood...@elaine)[~/src/spacewalk] % cat ~/.spacewalk-build-rc > > RPMBUILD_BASEDIR = /tmp/spacewalk-build > > > > Usage is: > > > > (dgood...@elaine)[~/src/spacewalk] % 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=DIST dist tag to apply to srpm and/or rpm (i.e. .el5) > > --test Use current branch HEAD instead of latest package > > tag. --no-cleanupDo 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) > > --debug Print debug messages. > > --tag-release Tag a new release of the package. (i.e. x.y.z-R+1 > > --keep-version Use spec file version/release to tag package. > > > > Combine --test with --rpm or --srpm to replicate the functionality > > of make test-rpm. > > > > Please note that anyone can build tgz, srpm, or rpm, but the > > tagging of packages should really only be done by those with commit > > access. (you can still do it, the tags will just be meaningless and > > cause conflicts when someone tags the same version you have locally) > > > > Please let me know if you see any problems, or if there's anything > > else you'd like to be added. > > Devan, > > if I need srpm from particular tag, I can do > > spacewalk$ make srpm TAG=tsdb-1.27.17-1 > > in the top level of the spacewalk repo and get .src.rpm created. > > If I try > > spacewalk$ rel-eng/bin/build.py --tag=tsdb-1.27.17-1 --srpm > > I get > > ERROR: Unable to locate a spec file > in /mnt/data/project/spacewalk > > What is the correct way of building a package from a particular tag, > without chdirring to package's directory (which might not even exist > by now)? > This was on my TODO but hasn't been done yet, I'll try to get it in there today. Will also fix the problem parsing empty lines in ~/.spacewalk-build-rc. Thanks, Devan - -- Devan Goodwin Software Engineer - Spacewalk / RHN Satellite Halifax, Canada650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklJHMYACgkQAyHWaPV9my6uggCfdX6umA5kNrTlepRlagxIKuGs N60AoIilJHc2PiCmMsQrkucAPVF6lLdr =Xyli -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Building RPMs w/ build.py
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 17 Dec 2008 17:38:08 +0100 Miroslav Suchý wrote: > Devan Goodwin wrote: > > This was on my TODO but hasn't been done yet, I'll try to get it in > > there today. > > Is is just me or > I had the impression that you start working on build.py so that it > will be easier to read/maintain. Yes this is one of the reasons, and because I believe it was a better fit for the task at hand. (particularly in reference to the functionality to be added for building satellite pkgs) > > But if I compare: > $ wc -l Makefile.* > 85 Makefile.git >189 Makefile.srpm >113 Makefile.tag-release >387 total > > $ wc -l bin/build.py lib/spacewalk/__init__.py lib/spacewalk/releng/* > 26 bin/build.py > 0 lib/spacewalk/__init__.py >383 lib/spacewalk/releng/builder.py >155 lib/spacewalk/releng/cli.py >178 lib/spacewalk/releng/common.py > 19 lib/spacewalk/releng/__init__.py >251 lib/spacewalk/releng/tagger.py > 1012 total Ease of maintenance and readability do not correlate to a low line count. For starters the python scripts are heavily commented, try to stick to 80 characters per line, and in general do not jam complicated multi-step procedures into single (or few) lines. At no point was it stated that build.py would result in less lines. > > And I do not see build.py much readable then Makefile > I know you have a stronger shell background than myself and thus may not find it much different. I however find it substantially more readable and and easy to work with for the tasks I have to complete, I'm hopeful future developers who work on it will as well, and thus I chose to move forward with it. If on the other you're stating you actually find it *less* readable, then please feel free to point out where and I will try to remedy the problem. > And build.py still do not have the functionality of Makefile. > Tack on another 50 lines to complete the small pieces of missing functionality if it makes you feel better. :) Honestly the remaining pieces will not require much additional work or lines of code. Devan - -- Devan Goodwin Software Engineer - Spacewalk / RHN Satellite Halifax, Canada650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklJOmcACgkQAyHWaPV9my5Q/QCffLC4aibu/wNl2x2JopljCO0c mOoAoLio68ifW1a7xCTyUyQCg1oCBcQf =KOFI -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Building RPMs w/ build.py
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 17 Dec 2008 14:04:45 +0100 Jan Pazdziora wrote: > On Tue, Dec 16, 2008 at 12:27:04PM -0400, Devan Goodwin wrote: > > I think the build.py script for building spacewalk packages is ready > > for some wider testing. At this point the functionality should be > > roughly equivalent to the Makefile.git. If you're looking to build > > spacewalk packages the script is located in rel-eng/bin/build.py. > > > > To use it just cd to the project you want to build and call the > > script via full path, or add it to your PATH variable and make your > > life easier. > > > > cd java/ > > build.py --srpm > > > > Also if you'd prefer to have your packages built somewhere *other* > > than the current working directory (which is very useful) Jan's > > setup for configuring this still works: > > > > (dgood...@elaine)[~/src/spacewalk] % cat ~/.spacewalk-build-rc > > RPMBUILD_BASEDIR = /tmp/spacewalk-build > > > > Usage is: > > > > (dgood...@elaine)[~/src/spacewalk] % build.py --help > > Usage: build.py [options] arg > > > > Options: > > -h, --help show this help message and exit > > --tgz build .tar.gz > > The build.py generates .tar.gz with different content than make does: > > $ make tgz > Removing previous > [/tmp/spacewalk-build/rpmbuild-spacewalk-java-0.4.7-1/] Creating > [/tmp/spacewalk-build/rpmbuild-spacewalk-java-0.4.7-1/] > Wrote: > /tmp/spacewalk-build/rpmbuild-spacewalk-java-0.4.7-1/spacewalk-java-0.4.7.tar.gz > $ > md5sum > /tmp/spacewalk-build/rpmbuild-spacewalk-java-0.4.7-1/spacewalk-java-0.4.7.tar.gz > 8340e0ce02f8fb5677373b66257d3d8f > /tmp/spacewalk-build/rpmbuild-spacewalk-java-0.4.7-1/spacewalk-java-0.4.7.tar.gz > $ > > $ ../rel-eng/bin/build.py --tgz > Building version: 0.4.7 > Creating spacewalk-java-0.4.7.tar.gz from git tag: > e31a535781ec4b1d2790e2f07a58a3e74ad57e29... > Wrote: /tmp/spacewalk-build/spacewalk-java-0.4.7.tar.gz $ > md5sum /tmp/spacewalk-build/spacewalk-java-0.4.7.tar.gz > 11851f3be168a7252eaef9abf459d50f > /tmp/spacewalk-build/spacewalk-java-0.4.7.tar.gz > $ > Not good, will look into this asap. Devan - -- Devan Goodwin Software Engineer - Spacewalk / RHN Satellite Halifax, Canada650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklJHQcACgkQAyHWaPV9my4mFwCeO5kyQF17cnhlIkcBhu/hj6eK fScAoJqWJTOMsyePhF8KOdbh7W7Av/c5 =6bMb -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Building RPMs w/ build.py
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 17 Dec 2008 13:50:04 +0100 Jan Pazdziora wrote: > > Devan, > > if I need srpm from particular tag, I can do > > spacewalk$ make srpm TAG=tsdb-1.27.17-1 > > in the top level of the spacewalk repo and get .src.rpm created. > > If I try > > spacewalk$ rel-eng/bin/build.py --tag=tsdb-1.27.17-1 --srpm > > I get > > ERROR: Unable to locate a spec file > in /mnt/data/project/spacewalk > > What is the correct way of building a package from a particular tag, > without chdirring to package's directory (which might not even exist > by now)? > This should be working now. % build.py --tag=spacewalk-setup-0.4.2-1 --srpm Building version: 0.4.2 Creating spacewalk-setup-0.4.2.tar.gz from git tag: 1faab1f475408ddf07a94accf029e2a212995d23... Wrote: /tmp/spacewalk-build/spacewalk-setup-0.4.2.tar.gz Wrote: /tmp/spacewalk-build/spacewalk-setup-0.4.2-1.fc9.src.rpm I ran into an issue with packages that need build.py.props (basically those that use NO_TAR_GZ previously) particularly when building a tag that was created prior to build.py.props. If anyone needs to build such a package version (and creating a new tag is out of the question) then I can add a - --properties-file option to build.py to force it, or we can just use make. (could use git-checkout some-past-revision if Makefiles were deleted at that point in time) Cheers, Devan - -- Devan Goodwin Software Engineer - Spacewalk / RHN Satellite Halifax, Canada650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklJiroACgkQAyHWaPV9my62fQCfYGAVWECnMoBcfVI08BKl23Tv DOwAn21TV5ew7JaK3Epq9DkYtCUxPJLb =eXjp -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Building RPMs w/ build.py
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 18 Dec 2008 09:11:00 +0100
Jan Pazdziora wrote:
> On Wed, Dec 17, 2008 at 07:26:46PM -0400, Devan Goodwin wrote:
> > > I get
> > >
> > > ERROR: Unable to locate a spec file
> > > in /mnt/data/project/spacewalk
> > >
> > > What is the correct way of building a package from a particular
> > > tag, without chdirring to package's directory (which might not
> > > even exist by now)?
> > >
> >
> > This should be working now.
> >
> > % build.py --tag=spacewalk-setup-0.4.2-1 --srpm
> > Building version: 0.4.2
> > Creating spacewalk-setup-0.4.2.tar.gz from git tag:
> > 1faab1f475408ddf07a94accf029e2a212995d23...
> > Wrote: /tmp/spacewalk-build/spacewalk-setup-0.4.2.tar.gz
> > Wrote: /tmp/spacewalk-build/spacewalk-setup-0.4.2-1.fc9.src.rpm
> >
> > I ran into an issue with packages that need
> > build.py.props (basically those that use NO_TAR_GZ previously)
> > particularly when building a tag that was created prior to
> > build.py.props. If anyone needs to build such a package version (and
> > creating a new tag is out of the question) then I can add a
> > - --properties-file option to build.py to force it, or we can just
> > use make. (could use git-checkout some-past-revision if Makefiles
> > were deleted at that point in time)
> >
> > Cheers,
>
> We seem to have a problem with (for example)
>
> $ rel-eng/bin/build.py --tag=perl-Crypt-RIPEMD160-0.04-15 --srpm
> Building version: 0.04
> Creating perl-Crypt-RIPEMD160-0.04.tar.gz from git tag:
> 8a7ceb5c1fe383d6cd2a4a96bdfcbdb99cecb390...
> Wrote: /tmp/spacewalk-build/perl-Crypt-RIPEMD160-0.04.tar.gz
>
> ## ERROR
> Error running command: rpmbuild --define
> "_sourcedir
> /tmp/spacewalk-build/rpmbuild-perl-Crypt-RIPEMD160-8a7ceb5c1fe383d6cd2a4a96bdfcbdb99cecb390/SOURCES"
> --define
> "_builddir
> /tmp/spacewalk-build/rpmbuild-perl-Crypt-RIPEMD160-8a7ceb5c1fe383d6cd2a4a96bdfcbdb99cecb390/BUILD"
> --define "_srcrpmdir /tmp/spacewalk-build" --define
> "_rpmdir /tmp/spacewalk-build" --nodeps
> -bs
> /tmp/spacewalk-build/rpmbuild-perl-Crypt-RIPEMD160-8a7ceb5c1fe383d6cd2a4a96bdfcbdb99cecb390/SOURCES/perl-Crypt-RIPEMD160-0.04/perl-Crypt-RIPEMD160.spec
> Status code: 256 Command output: error:
> File
> /tmp/spacewalk-build/rpmbuild-perl-Crypt-RIPEMD160-8a7ceb5c1fe383d6cd2a4a96bdfcbdb99cecb390/SOURCES/Crypt-RIPEMD160-0.04.tar.gz:
> No such file or directory Traceback (most recent call last): File
> "rel-eng/bin/build.py", line 26, in CLI().main() File
> "rel-eng/bin/../lib/spacewalk/releng/cli.py", line 165, in main
> builder.run(options) File
> "rel-eng/bin/../lib/spacewalk/releng/builder.py", line 102, in run
> self._srpm() File "rel-eng/bin/../lib/spacewalk/releng/builder.py",
> line 139, in _srpm output = run_command(cmd) File
> "rel-eng/bin/../lib/spacewalk/releng/common.py", line 68, in
> run_command raise Exception("Error running command") Exception: Error
> running command $
>
Had an idea this morning for dealing with these old packages tagged
prior to the existence of build.py.props, should build ok now.
Cheers,
Devan
- --
Devan Goodwin
Software Engineer - Spacewalk / RHN Satellite
Halifax, Canada650.567.9039x79267
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAklKbDMACgkQAyHWaPV9my7XmQCgs0ltIGnZYWvcyekg7kcam2sy
Wo4AoNkFeFZ7at8fB+cBHnDxiM2CPQkE
=9d3H
-END PGP SIGNATURE-
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Building RPMs w/ build.py
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 17 Dec 2008 14:04:45 +0100 Jan Pazdziora wrote: > The build.py generates .tar.gz with different content than make does: > > $ make tgz > Removing previous > [/tmp/spacewalk-build/rpmbuild-spacewalk-java-0.4.7-1/] Creating > [/tmp/spacewalk-build/rpmbuild-spacewalk-java-0.4.7-1/] > Wrote: > /tmp/spacewalk-build/rpmbuild-spacewalk-java-0.4.7-1/spacewalk-java-0.4.7.tar.gz > $ > md5sum > /tmp/spacewalk-build/rpmbuild-spacewalk-java-0.4.7-1/spacewalk-java-0.4.7.tar.gz > 8340e0ce02f8fb5677373b66257d3d8f > /tmp/spacewalk-build/rpmbuild-spacewalk-java-0.4.7-1/spacewalk-java-0.4.7.tar.gz > $ > > $ ../rel-eng/bin/build.py --tgz > Building version: 0.4.7 > Creating spacewalk-java-0.4.7.tar.gz from git tag: > e31a535781ec4b1d2790e2f07a58a3e74ad57e29... > Wrote: /tmp/spacewalk-build/spacewalk-java-0.4.7.tar.gz $ > md5sum /tmp/spacewalk-build/spacewalk-java-0.4.7.tar.gz > 11851f3be168a7252eaef9abf459d50f > /tmp/spacewalk-build/spacewalk-java-0.4.7.tar.gz > $ > Should be fixed now. Devan - -- Devan Goodwin Software Engineer - Spacewalk / RHN Satellite Halifax, Canada650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklKl2UACgkQAyHWaPV9my7SnQCfZaMSCIoVst2fJE+664GGq5Rv 62MAoJtc3vx95V/JyyHh+1vQPutHVcc9 =3VXi -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Dev environment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 5 Jan 2009 15:03:19 -0500 "Travis Camechis" wrote: > Hi, > > I am slowly getting my development environment completely setup. I am > currently in the process of setting up some VMs running CentOS for > actually running the server / clients. Does anyone have any > recommendations on the VM setup such as the amount of HD space that > should be allocated? > > Thanks, > > Travis Camechis > Software Engineer For the Spacewalk guest, it depends on how much content you intend to serve. I think Fedora i386 is somewhere around 9 gigs, if I was setting up a Spacewalk repo just for that I'd probably allow at least 15 gigs. Cheers, Devan - -- Devan Goodwin Software Engineer - Spacewalk / RHN Satellite Halifax, Canada650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklib7EACgkQAyHWaPV9my5F2wCgmWfwdMF3aKZPOZYtvakArzNw wIMAoMfFvVsv74JlqcvRo8a2UaUfhImI =DUdj -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Email not showing in http://www.mail-archive.com/spacewalk-devel@redhat.com/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 7 Jan 2009 20:40:07 +0900 "Coe, Colin C. (Unix Engineer)" wrote: > Hi all > > Yesterday morning I sent an email containing two patches. I can see > the email in my sent items but its not showing up in the archive. > The subject was 'Patches'. > > Did anyone see this? Just trying to work out where the hold up is. > > Thanks > > CC > > NOTICE: This email and any attachments are confidential. > They may contain legally privileged information or > copyright material. You must not read, copy, use or > disclose them without authorisation. If you are not an > intended recipient, please contact us at once by return > email and then delete both messages and all attachments. > > > ___ > Spacewalk-devel mailing list > Spacewalk-devel@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-devel Yep they made it through, not sure if the archives have a delay or how long it is. Cheers, Devan - -- Devan Goodwin Software Engineer - Spacewalk / RHN Satellite Halifax, Canada650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklkrjwACgkQAyHWaPV9my73bACeIwp/MwSs9GXWMPqz4p0tu+as JVMAn2KPB/geVJ7B2PqPmqSppivRcUw3 =mIll -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Avoiding Large Binary Files In Git
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We've hit this a couple times so it's probably worth making sure everyone's aware this is a bad idea and why. (don't think we've actually communicated this at any time) In general git and svn both aren't so fond of binary data, they can't do diffs and thus any change to the file chews up a lot of storage. The situation with git is even worse because a git clone is a clone of the entire repository, all branches and history. Thus when we commit a huge binary file in git, even if we remove it later on, it's still included in all git checkouts and any future clones as well. (which is brutal for distant remotees or people with slow connections) So if you need to share a large binary file, we can keep our scm drastically more efficient if we find another way to host and share the file. Anyone have suggestions? Thanks, Devan - -- Devan Goodwin Software Engineer - Spacewalk / RHN Satellite Halifax, Canada650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklmPTkACgkQAyHWaPV9my7pOwCfVhKQ+JVkH8QFl0SgiCMWLY/N MPIAn1d8tj1G9IXfkni3pDNeJdVgq6LW =qIRf -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Nightly repos
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 09 Jan 2009 09:19:52 -0800 Mike McCune wrote: > Jan Pazdziora wrote: > > On Fri, Jan 09, 2009 at 08:50:48AM -0800, Mike McCune wrote: > >> excellent. good to know. will use that next time. > >> > >> So I saw a few changelogs in some specfiles: > >> > >> ==spacewalk-setup.spec:== > >> > >> * Thu Jan 8 2009 Jan Pazdziora 0.4.20-1 > >> - support symlinked and NFS-mounted /var/satellite during setup > >> - run chkconfig for "stock" httpd > >> > >> ==spacewalk-backend.spec== > >> * Thu Jan 8 2009 Jan Pazdziora 0.4.10-1 > >> - more changes for nvrea error handling > >> - changed all references of none to auto w.r.t > >> rhnKickstartVirtualizationType > >> - 467115 - adding a switch so users can turn off same nvrea > >> different vendor package uploads > >> - eliminate satellite-httpd daemon, migrate to 'stock' apache > >> - 461162 - adding support to push the cobbler profile name down to > >> koan > >> - 461162 - adding some virt options and spiffifying the virt > >> provisioning page > >> - 461162 - moving cobbler requirement down to the RPMs that > >> actually use it > >> - changes are by multiple authors > >> > >> where these hand-entered by you? > > > > Yes. > > > >>Or did you have some tool that > >> grabbed git comments and added the changelog for you? > > > > I generally do > > > > git whatchanged . > > > > in the package directory and put the commit messages up until the > > previous "Automatic commit ..." message there, after shortening > > them. > > > > cool, good 2 know! > > Mike Adding this to build.py is on my TODO list, something like if no changelog entry found, open up a text buffer with an autogenerated one from git history, let the user edit it, then write it out when they close. Dev - -- Devan Goodwin Software Engineer - Spacewalk / RHN Satellite Halifax, Canada650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklnrawACgkQAyHWaPV9my6kRQCgsAskHv6NJbiYld8aNUsBRylS XIAAoMLrNxFAGLe1B9N59T7bTY7PTo52 =C5Th -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Postgres status report
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 12 Jan 2009 08:53:54 -0500 (EST) Bruce Momjian wrote: > I just had another conference call with the EnterpriseDB staff. They > have studied the output of ora2pg stored in GIT and now think they > need to manually convert the schemas. The will write up some > guidelines and post them on a wiki for everyone to review. They are > also looking at the stored procedures. > > Also, EnterpriseDB Fedora logins will soon need the ability to modify > the Postgres branch in the GIT repository. > I think to do this they just need to log in to the FAS and request membership in the gitspacewalk group. https://admin.fedoraproject.org/accounts/group/view/gitspacewalk After that we approve the requests and they should be good to go. Do we have a list yet of the login names whose requests we can know to approve? Thanks, Devan - -- Devan Goodwin Software Engineer - Spacewalk / RHN Satellite Halifax, Canada650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklrUcgACgkQAyHWaPV9my5TuwCfXXn589D/1XmPtQhsAMWABItK IVYAnilyA4qZ7gpuQiS3FvqLScZeVn0v =C3FD -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PGPORT Introducing EnterpriseDB team
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 13 Jan 2009 17:11:25 +0530 "Gurjeet Singh" wrote: > Hi All, > > I am a bit late in doing this, but I think it is necessary, so > here it goes. > > The migration of the Spacewalk project to support Postgres has > started, and EnterpriseDB is collaborating with Redhat and Spacewalk > developers on this. For now, the people involved from EnterpriseDB > are as follows: > > Bruce Momjian: Architect, br...@momjian.us > > George Williams: Manager, george.willi...@enterprisedb.com > > Gurjeet Singh: Developer, gurjeet.si...@enterprisedb.com > > Vikram Rai: DBA, vikram.si...@enterprisedb.com > > Tushar Ahuja: QA + DBA, tushar.ah...@enterprisedb.com Welcome! > > I propose that all the mails exchanged for this effort be tagged > with PGPORT in the subject, as above; or with aything else that you > all might see suitable. +1 Devan - -- Devan Goodwin Software Engineer - Spacewalk / RHN Satellite Halifax, Canada650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklshUAACgkQAyHWaPV9my6mBwCeLX3nv49UGK6/muUAAIQnxQJF Hq4AmwbJI6KWta9FwhNNRjzVam0J1Jht =mTh+ -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Snapshots from actions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 09 Jan 2009 16:22:13 -0500
Jason Dobies wrote:
> I'm looking for some help on:
> https://bugzilla.redhat.com/show_bug.cgi?id=444519
>
> I am looking at the backend python code for handling an action
> (server/handlers/xmlrpc/queue.py:411):
>
> elif status == 2 and trigger_snapshot and self.__should_snapshot():
> # if action status is 'Completed', snapshot if allowed and if
> needed self.server.take_snapshot("Scheduled action completion: %s" %
> row['name'])
>
> - I'm assuming status is set to 2, based on the fact that the action
> shows it was successful.
> - I followed trigger_snapshot around and ended up in the DB; the
> action type for config file deployment is set to trigger a snapshot
> - I believe __should_snapshot should be returning 1. That method just
> checks for the provisioning entitlement, which I verified the server
> I'm using has.
>
> I took a quick look at take_snapshot and it looks ok (I didn't look
> too closely at the rhnServer.snapshot_server stored proc yet. Part of
> me is also assuming that if there was a bug in taking the snapshot
> we'd notice a lot more snapshot bugs than we have open (I could be
> wrong on that assumption).
>
> So I can't figure out why a snapshot wouldn't be triggered for a
> configuration file deployment. And I don't have enough python
> experience yet to have a solid idea of what to do next to debug it.
>
> Any advice? I'm looking to "learn to fish" so to speak here, so even
> if you come across what the bug is please let me know how you got
> there.
>
> Thanks!
> - J
>
Hey Jason,
First thing I would try would be to add print statements right above
that if/elif block to display what all those boolean clauses are
evaluating too.
With Python it's kind of handy that you *can* do this by just editing
the queue.py that gets installed on a dev machine, should be
in /usr/share/rhn. Mind you this probably isn't the best habit to get
into but it makes for a handy quick hack when you're debugging and want
to see what's going on.
So I would add print("status = %s" % status) etc and get a real clear
idea what's going on. Once you do that I don't think you even need to
restart services.
Those prints should show up in /var/log/rhn/rhn_server_xmlrpc.log (I
think, if not it should be somewhere around there) There's also
debugging you can crank up and get more info here by modifying levels
in /etc/rhn/rhn.conf and /etc/rhn/defaults/.
Hope that's of some use, gl!
Devan
- --
Devan Goodwin
Software Engineer - Spacewalk / RHN Satellite
Halifax, Canada650.567.9039x79267
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAklsiK0ACgkQAyHWaPV9my70qgCePMgctWN/ihR5i0Zmy+knunTg
jk8AoNkF7XbEnxUnG6TTPjS7GHkhjy24
=wiWb
-END PGP SIGNATURE-
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] #!/usr/bin/env python to #!/usr/bin/python
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 14 Jan 2009 12:13:20 +0100
Jan Pazdziora wrote:
> On Wed, Jan 14, 2009 at 10:36:37AM +0100, Jan Pazdziora wrote:
> >
> > I propose to phase out
> >
> > #!/usr/bin/env python
> >
> > in favour of
> >
> > #!/usr/bin/python
> >
> > in our python scripts.
> >
> > Speak now or forever hold your peace.
> >
> > Note that we already use the second form 182 times in non-test
> > scripts, while we use env 63 times.
> >
> > The current problem that I'm solving is that osa-dispatcher, when
> > started via /usr/bin/env, will search directories for python, which
> > generates SELinux AVC denials like
> >
> > type=AVC msg=audit(1231924839.798:5971): avc: denied { search }
> > for pid=15336 comm="python" name="root" dev=dm-0 ino=784129
> > scontext=root:system_r:osa_dispatcher_t:s0
> > tcontext=root:object_r:user_home_dir_t:s0 tclass=dir
> >
>
> Actually, this AVC denial is about different problem. So it was not
> a good example.
>
> But nevertheless: shouldn't we decide for env or direct path in the
> shebang line and be consistent about it?
>
+1. I'd go the other direction though and stick with "/usr/bin/env
python", iirc that's considered best practice to accommodate people
with Python installed in a weird location or using multiple versions.
Devan
- --
Devan Goodwin
Software Engineer Spacewalk / RHN
Satellite Halifax, Canada
650.567.9039x79267 "Coming back to Java after a few months off is like
a slap in the face."
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAklt4UYACgkQAyHWaPV9my4/qACbBZ1YE/c9Vl0Xt4lxTR293Oth
cJgAnR3duyp7zEM02m64byk9vEfB6Uiq
=8N1T
-END PGP SIGNATURE-
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PGPORT Initial porting guidelines.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 15 Jan 2009 15:36:55 +0530 "Gurjeet Singh" wrote: > Hi All, > > Just finished Wikifying the initial guidelines on how to go about > porting to Postgres. You can find it here: > > https://fedorahosted.org/spacewalk/wiki/PostgresPortingGuidelines > > These are my opinions on the issues I could see directly (in > schema/ or through grepping). There are many places where some debate > is needed, and then there are some places where core developers can > help out making decisions based on their knowledge. > > I am attaching the text file here. Lets discuss the issues here, > and finalize them, before going ahead with the actual modifications. > > Best regards, Great guidelines Gurjeet, We'll have to get Orafce packages into Fedora/EPEL, will we need some work done to the code itself to run on PostgreSQL 8.1? I think we discussed that it may require 8.2 currently in some past meetings but I can't see this clearly indicated in the Orafce webpage. I'm not really the best qualified to comment on some of the changes you propose to the existing Oracle schema, but in general I like the idea of making adjustments if it aids in portability provided they're not too invasive and wide-sweeping. The rest looks good to me, nice guidelines. Hopefully others on the team with more schema background will be able to chime in with some more feedback. Thanks, Devan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklvNWQACgkQAyHWaPV9my5C0QCdGAJoD7lJ5C1U/9yF2kSjtZ6k AfgAoMnAHg413FtTUi3lE3psMposCx2U =clUu -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk and ODBC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 15 Jan 2009 14:50:26 +0100 "Christoffer Strömblad" wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > This probably all boils down to my lack of understanding how > communication from spacewalk is carried out towards the database. > When I hear talk about creating a port from Oracle to PGSQL I > assumed that this meant that the current development of Spacewalk > was done in a way that was directly communicating with Oracle. > > Also my understanding of ODBC was that it is a sort of API that one > uses to communicate towards DBs, avoiding DB-specific APIs. All > this mounts up to lack of understanding how DB-interaction is > carried out from various languages. > > I guess that JDBC is the abstraction layer that I'm thinking ODBC > is supposed to be. Still not entirely confident I understand what > .sql things is changed to move it from Oracle to PGSQL, but I won't > trouble the list with these newbie questions, I'll just go educate > myself on wikipedia instead. > > Thanks for taking your time to reply! > > Regards, > Christoffer We've got three languages on the go and sometimes multiple solutions for talking to the db in all of them. Despite some of these solutions being very well chosen for portability, there's always problems when you try to switch to a new db. In our case we have schema defined in .sql files that all needs to be ported and tuned, stored procedures that all must be ported, and then we get to all the application code. Any raw SQL queries are a risk and there will be many instances where these queries need to be adjusted or a new version for the new database. The port is more about schema/procedures/queries than what methods we use to actually connect to the db. This is an issue as well but it's microscopic in relation to the size of these. As for what we use, Python uses the Python DB API and an Oracle driver to connect (although this driver deviates from the standard in some ways that we use) but executes raw SQL queries and thus needs some attention. Perl uses DBI and again executes raw SQL queries (I think) and also needs attention. Java has two big solutions in play, one an older datasource library we wrote in house to call SQL queries, again needing significant attention, and more recently Hibernate for ORM which helps in a lot of ways but still allows you to resort to raw SQL queries and we use that on occasion. Both of these boil down JDBC and the ojdbc driver we use. Hopefully that's an accurate high level overview. :) Cheers, Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklvQ14ACgkQAyHWaPV9my50bwCfTysJQCXlHtVxyKDOyvWWAdUc 1YQAnjsb3bPKyjz71hAS7hsmiRNdQwQf =8cTw -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PGPORT (installation issue using make)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 15 Jan 2009 19:57:02 +0530 "tushar ahuja" wrote: > Hi Jeff, > > Thanks for the link .We have started the installation for creating a > devel environment on Red-Hat5. > > These are the Steps which we have used :- > > 1)We have installed spacewalk using rmp (yum install spacewalk) Was this spacewalk 0.3 you installed? > 2)at the time of configuration (spacewalk-setup --disconnected), we > found tomcat failed to start just before the installation ,but > somehow we found the solution and fix it. > 3)we opened GUI interface (https://localhost.localdomain) and > created a administrator user and password wow :-) > 4) we installed/configured git(using rpm) and also clone the spacewalk > repository successfully > 5)Now at the time of installation "WEB APPLICATION" ,we performed all > the Steps mentioned in the wiki successfully. > > But whenever i am trying to open browser for spacewalk server( > https://localhost.localdomain) > i am getting this error message > > Forbidden > > You don't have permission to access / on this server. > > Additionally, a 403 Forbidden error was encountered while trying to > use an ErrorDocument to handle the request. > -- > Apache/2.2.3 (Red Hat) Server at 127.0.0.1 Port 80 > > it look like a Apache issue but i am not able to solve it. > > Any idea how to solve this ? Could you try hitting from a non-localhost IP, this historically does not work in spacewalk and I don't recall that changing anytime recently. Cheers, Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklvTU8ACgkQAyHWaPV9my4iIACgu67Z0J/j2Kwsz01tudzMSEUo iIMAoKjQ1wCjUX/P3U4Ucz7+65m8fOw8 =wtIl -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Re: Spacewalk 0.4 BRANCHED
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 16 Jan 2009 11:07:46 +0100 Michael Mraka wrote: > Jesus M. Rodriguez wrote: > % master = spacewalk 0.5 > % SPACEWALK-0.4 = spacewalk 0.4 > > Why 0.4 branch is called SPACEWALK-0.4 while we have RELEASE-0.2 and > RELEASE-0.3 branches? I asked Jesus to change the naming for clarity with the Satellite git repo. (SPACEWALK-0.4 and SATELLITE-5.3 instead of RELASE-X.Y for both) We could quite easily push those old RELEASE-0.2 to RELEASE-0.3 branches with a new name to make them conform if you'd like. Cheers, Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklwjVwACgkQAyHWaPV9my42YgCfQz+DV/hEdBmezgzB1HosKowp LXIAoI5h7ohY0tAhqjIqE4yEeHhGyjWR =d42C -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PGPORT (installation issue using make)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 17 Jan 2009 13:13:46 +0530 tushar ahuja wrote: > thanks Jan. > > Sure I will try to upgrade 0.3 to 0.4 .and let you know the result. i > am just wondering is this a known issue ,has someone already > encountered with this problem ? or i am doing something wrong ? as i > am not able to find any thread against this issue at spacewalk-devel > list. > Not a known issue that I'm aware of. Hopefully a fresh 0.4 attempt will avoid it. Cheers, Devan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklx5fgACgkQAyHWaPV9my7GvACfRdeIyprQsm4aMn9WpGORnG98 VmYAoLJ1FFcLbMKaYBliWvJCU2GIk40G =oOm/ -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PATCH: tagger.py: make email in changelog optional
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 19 Jan 2009 11:03:28 +0100 Jan Pazdziora wrote: > > Hello Devan, > > I tried build.py --tag-release and it complained that there is no > email address in the changelog entry line. I do not want to put my > email address there. This patch makes that part optional. > > Pleasse apply. Applied, thanks. Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkl0eE4ACgkQAyHWaPV9my5RJQCgoKjx6jOo/DbxKC0xRLau/sJs 1EIAnRxmhFz+4n+SkMNXmI86iraxA8T4 =6qtQ -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] building packages in remote branch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 21 Jan 2009 10:47:45 +0100 Miroslav Suchý wrote: > Mike McCune wrote: > > If I tag a release in the SPACEWALK-0.4 release branch: > > > > http://git.fedorahosted.org/git/spacewalk.git?p=spacewalk.git;a=commit;h=1ac7a83c472b8b6bf45bb54b6477c3c825254401 > > > > > > > > Do I need to push any of that into master? If not, won't the > > versions get out of date in master (behind the release branch)? > > If you tag package in SPACEWALK-0.4 you will get another 0.4 version > - 0.4.17-1 in your case. > When you make some changes in master after branching you should bump > up version number - to 0.5.0 in this case. Then after you tag the > package you will get 0.5.1-1 version. > That is everything perfect. > > The scenario when you hit some problem is when you tag release in > SPACEWALK-0.4 branch (and you will get 0.4.17-1) and then you forgot > to bump up version in master you tag there release as well and you > will get 0.4.17-1 as well. But either git pull or git push --tags > will stop you since you can not have one tag for two different > commits. Therefore it is nearly impossible to do things wrong. > I actually tried to tag java 0.4.17 in master this morning and forgot to bump up to 0.5. I had already git pulled so it quickly died because that tag already existed. I'll add a remote repo check in build.py to run before doing anything as well. Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkl3KKwACgkQAyHWaPV9my7bkgCfS6D0B48WrVz0wBPO2qTar8ip Gq4An2VO6y/WGnuIjyShP8R+jNvFWpY0 =qxkf -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Deleting Unused Java Datasource Queries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just deleted a bunch of unused data source queries from the Java stack. I think the script logic I used to identify them is sound, and I've tested that the XML still parses and the tomcat will come to life, but you never can tell. If you run into a missing data source query in the next little while you know who to yell at. :) Cheers, Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkl3ipkACgkQAyHWaPV9my4A2QCgzeSygqBSu9sEJ/ovxplIMhfz rHQAn3iifjv63qLMFn6hqdIkObWtQ1Iv =PWw1 -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Informal Devel Environment Survey
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Noticing a lot of newcomers really struggling with our devel setup lately and got to wondering how many others out there aren't actually even using it. Anyone feel like sharing what, if anything, they're doing differently from the standard devel environment setup defined here (and why): https://fedorahosted.org/spacewalk/wiki/DevelopmentWorkstationSetup I have a gut feeling we should recommend something drastically different to lower the barrier to entry. Thanks, Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkl4tg4ACgkQAyHWaPV9my4fagCgxk0kpwBihkzTyqi3gHtT7nnT gfgAn1ZXXS83qkq1nGQB+qrjTbEBim9M =ZRP5 -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] beginning spacewalk development
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 20 Jan 2009 16:31:34 -0500 Travis Camechis wrote: > I have finally got my Dev environment all setup. My question now is, > where would be a good place to start for beginners on the project? > Right now I have no preference. Thought of some other ideas, 1. Getting packages into Fedora: https://fedorahosted.org/spacewalk/wiki/GettingPackagesIntoFedora This entails getting approved as a Fedora packager and learning the ins and outs of rpm's and spec files but it's really not that hard once you do it a couple times, and it can prove to be very valuable knowledge to have as well. The end goal is a great one as well, spacewalk installable straight out of Fedora/EPEL yum repos. 2. Migrate Perl pages to Java: https://fedorahosted.org/spacewalk/wiki/RemainingPxtPages We've had this partially completed migration away from Perl to Java underway for years. Still many small pages remain and there's likely some easy pickings in here. Great way to get a feel for the application too. Cheers, Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkl41/0ACgkQAyHWaPV9my5AAACffbSo/VpBgTARTbnOuv5vUYgL 8aYAnR5VANuog/WprLrZTO3fZNDpVyTh =hluy -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Informal Devel Environment Survey
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 23 Jan 2009 11:45:48 +0530 tushar wrote: > > when:-at the time of Installing Web application :- these are the > last few steps which are mentioned in > wiki(https://fedorahosted.org/spacewalk/wiki/DevelopmentWorkstationSetup) > > * cd $GITDIR/spacewalk/search-server > * make test-srpm; rpmbuild --rebuild > spacewalk-search-*.git.*.src.rpm; rpm -Uvh > /usr/src/redhat/RPMS/noarch/spacewalk-search-0.4.1-1.git.*.noarch.rpm > * it's a good idea to wipe out the search indexes, "sudo > /sbin/service rhn-search cleanindex" > * sudo /sbin/rhn-satellite start > > > At the time of performing rpmbuild --rebuild > spacewalk-search-*.git.*.src.rpm; , this command fails. as it is > trying to search in search-server folder but if we fire this command > under saerch-server > /rpmbuild-spacewalk-search-git-f51c6110bc1c7296b3478c3110a30c9dca331e9b > it works > > > At the time of performing rpm -Uvh > /usr/src/redhat/RPMS/noarch/spacewalk-search-0.4.1-1.git.*.noarch.rpm , > this also fails ,if we go to /usr/src/redhat/RPMS/noarch/ folder it > is showing > spacewalk-search-0.4.10-1.git.f51c6110bc1c7296b3478c3110a30c9dca331e9b.noarch.rpm > > present,we have 0.4.10 not 0.4.1 Just updated the section for spacewalk-search to: ../rel-eng/bin/build.py --test --rpm && /tmp/spacewalk-build/noarch/spacewalk-search-*.git.*.noarch.rpm Cheers, Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkl6JxcACgkQAyHWaPV9my67pwCglNwOaQiOBHjFghBNbLevDNcF lhIAoLyvZSb9Zu717HtX++hBkHYhMHpO =te9x -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] bugzilla
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 24 Jan 2009 23:16:06 -0500 "Jesus M. Rodriguez" wrote: > On Sat, Jan 24, 2009 at 4:00 PM, Travis Camechis > wrote: > > Is there a way for me to get emails when bugs are entered/updated? > > I haven't used bugzilla before and Im not sure if that is even > > possible without being a core developer. > > You can add yourself to the CC list of the bugzilla. > > jesus > > ___ > Spacewalk-devel mailing list > Spacewalk-devel@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-devel If you CC yourself on the space05 tracker bug you'll see what's getting added too. Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkl9x5oACgkQAyHWaPV9my5O2ACfQNXrHn0pkpwTKkRtk89r8qFG OZsAn0/friJOwY0v23T+5O+OJBZ79unJ =zmlk -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] PGPORT: Worklog Up, Master Merged, Scp Sync Script Coming Soon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We've added a "worklog" to the wiki meant to identify the problems we've hit in pgsql branch and the porting effort and details on how we've solved them. We're hoping others can review this and spot any problems or situations we may not have thought of. https://fedorahosted.org/spacewalk/wiki/PostgresWorklog Currently there's just my work from before Christmas here but to all working on the project please feel free to add to these sections or create your own. This morning I merged in several hundred commits from master (i.e. Spacewalk 0.5) and pushed them out to the pgsql branch, we are now up to date. Next up I'm going to setup a pgsql-update.sh script in scripts/ that will scp code from your working directory over to a live spacewalk install. It's not pretty but hopefully it will suffice for awhile as the traditional devel setup does not catch a number of modifications required for testing the pgsql code base. (particularly spacewalk-setup and rhnSQL Python code) Cheers, Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkl98lcACgkQAyHWaPV9my7BmQCglys5gwXa9hnUurFO0191ShhV /RQAn0yrGdypc71t2kPa9ME8kiYd0LIY =A8KX -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PGPORT: Orafce on Postgres 8.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 27 Jan 2009 22:55:03 +0530 Gurjeet Singh wrote: > Thats good news. We will need more QA for the features provided by > orafce. > > Can we have an optional pseudo package (something like > spacewalk_postgres ) that spacewalk package would depend on, so that > we make postgres and orafce part of those and 'yum install > spacewalk_postgres' will automatically install the contained packages > for us? > > If possible, can we add this dependency only in pgsql branch? > > Best regards, > I'd like to set up some customized package builds off pgsql branch and find some way to distribute them but it's a little tricky to do so, and I'm hoping we can survive with a devel setup at least for awhile. (though if we find it necessary then we'll figure something out) Building and tagging packages in a branch off master, while work moves on in master and we merge that in occasionally, is a bit tricky to coordinate. As for packaging I'm hopeful that when we finish this effort, things will look something like: - - yum install spacewalk requires no database packages (as your db could be on another host) - - spacewalk will install schema for one or both databases somewhere on your system. if we choose one or the other, postgresql should be the default. - - spacewalk-setup will prompt if you'd like an "embedded" installation where we assume the admin doesn't know anything about databases, then just yum install postgresql and configure a database for them during the setup automatically. - - otherwise, spacewalk-setup will ask for connection parameters to your pre-existing oracle or postgresql db and install the appropriate schema. I'm going to try to get a script in the pgsql branch soon to copy all pgsql modified files into a live location on the system soon. Hopefully this will hold us over for awhile but we'll see how it goes. Cheers, Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFJf1U4AyHWaPV9my4RAt3WAKDBbrqZ4Sbebam4plcYOixsPjh7XgCeOXAd g/n+HVz/KtvXCJ2OH2RjteE= =d9ht -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] PGPORT: How to Use What's In the "pgsql" Branch
Posted some notes on how you can actually use the pg modified code in the "pgsql" git branch. This isn't particularly useful yet as the setup process breaks midway (EnterpriseDB guys you probably want to avoid this for now as it will muck with the stability of your Spacewalk servers), but if you're interested in seeing how work is progressing on getting the actual Spacewalk application ready to *talk* to PostgreSQL, this is the place for you: https://fedorahosted.org/spacewalk/wiki/PostgresDevelopmentNotes The deploy script isn't pretty but building customized rpms off a branch is even less pretty, and hopefully we can avoid it at least for awhile. Devan -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PGPORT: Orafce on Postgres 8.1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 28 Jan 2009 09:48:42 -0500
"Jesus M. Rodriguez" wrote:
> >
> > - - spacewalk-setup will prompt if you'd like an "embedded"
> > installation where we assume the admin doesn't know anything about
> > databases, then just yum install postgresql and configure a
> > database for them during the setup automatically.
>
> -1 (see other email from me and Jan)
I'd just as soon we expect admins to have created their databases
beforehand and know how to connect to them, but I've been given a
requirement for that "embedded" type installation for users who don't
know or care about db administration. Setup was my first thought but
maybe it could be solved somewhere else, and perhaps it should be
Satellite specific.
>
> >
> > - - otherwise, spacewalk-setup will ask for connection parameters
> > to your pre-existing oracle or postgresql db and install the
> > appropriate schema.
>
> always ask for db information. For example,
>
> Database [PostgreSQL]? # valid values would be PostgreSQL & Oracle
>
> The prompts for the database information can change depending on what
> the value of Database was chosen, that is if PostgreSQL needs more or
> less information than Oracle, etc.
Mostly doing this today in spacewalk-setup in pgsql branch, although
the PostgreSQL params are kind of shoehorned into what Oracle was
asking for before, there's a new db-backend parameter ("oracle" or
"postgresql"), then SID is used as a database name for postgresql,
and the default port is still Oracle's default port. I'll get this a
little prettier at some point.
>
> jesus
>
> ___
> Spacewalk-devel mailing list
> Spacewalk-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-devel
- --
Devan Goodwin
Software Engineer Spacewalk / RHN Satellite
Halifax, Canada 650.567.9039x79267
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkmAdiAACgkQAyHWaPV9my4e8ACfZQS8L/wfxb01eSmlcktxDZcU
+JEAniKfdXGLCrQtzFpHlOIQ+9kqOq/f
=YVbk
-END PGP SIGNATURE-
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Anyone Have PostgreSQL + python-pgsql experience?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Looking for anyone who has experience with these particularly in the realm of calling procedures, would love to bounce a few questions off you. It's looking like the Python DBAPI (http://www.python.org/dev/peps/pep-0249/) method of calling stored procedures (Cursor.callproc()) is not implemented for PostgreSQL. It looks like this is because PostgreSQL does procedures quite differently. All the examples I've seen so far of using stored procedures has them embedded within regular queries like: spacewalk=# select return_int(5) as qty; qty - - 5 (1 row) If I'm on the right track it might be possible to hack something up in our rhnSQL code where if you tried to call a procedure, the same way as we do for Oracle, it would translate it into a "SELECT blah(arg1, arg2) as blah" statement behind the scenes but will see how it goes. Otherwise we've got a problem with the backend code where we'll need to fork calls to procedures, though fortunately there aren't a huge number. Have to make sure I'm on the right track first. Thanks, Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmAgf0ACgkQAyHWaPV9my7HNgCfeMz0Cm672BodMLc3S9+b5r5A gLsAoOpv8xDf0PWbV8XPzZrfEch5iJjn =4ZG7 -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Changes needed in wiki for CentOS development environment setup
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 29 Jan 2009 16:04:34 +0530
Vikram Rai wrote:
> Hi,
>
> We have put together a document for deploying the Spacewalk dev
> environment on CentOS 5.
> There were a couple of steps that we had to do in order to make it
> working on our local machines.
>
> Please go through the attached document and let us know if the
> document seems ok.
> We had a suggestion to put this document as a separate link on the
> wiki for install instructions for CentOS.
>
> Regards,
>
> Vikram Rai
> Enterprise DB
My personal preference would be to keep this in the same document if
it's at all possible. If somewhere the steps are deviating massively
then maybe it's worth it but between Cent OS 5 and RHEL 5 I can't see
the need for another entire dev guide. (which is just all the more
likely to get out of date as the last one did)
What did you guys need RPMForge repos for? I haven't needed these at
any point to run Spacewalk.
"rpmlint" package should be available in the EPEL repository for EL5.
Looks like a lot of good additions and fixes for the current guide but
I would greatly prefer they get added to the appropriate section rather
than a new page.
Thanks for your efforts!
Devan
>
> On Wed, Jan 28, 2009 at 4:12 AM, Gurjeet Singh <
> gurjeet.si...@enterprisedb.com> wrote:
>
> > Hi All,
> >
> > I followed the guide at
> > https://fedorahosted.org/spacewalk/wiki/DevelopmentWorkstationSetup
> > and tried to setup a dev env on CentOS 5.2.
> >
> > Here's what I started with:
> > Clean install of CentOS, with a few packeges that make sense for
> > Spacewalk like webserver, etc.
> > Disable SELinux policy in /etc/selinux/config (SELINUX=disabled)
> >
> > And then while following the instructions, I had to perform the
> > following 4 additional steps to get the env up and running:
> >
> > 1) During Spacewalk installation, before the following step:
> >
> > rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-former
> >
> > Do this as root:
> >
> > wget -O /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-former
> > http://www.redhat.com/security/db42a60e.txt
> >
> > 2) Instead of
> >
> > ../rel-eng/bin/build.py --test --rpm &&
> > /tmp/spacewalk-build/noarch/spacewalk-search-*.git.*.noarch.rpm
> >
> > do this:
> >
> > ../rel-eng/bin/build.py --test --rpm && sudo rpm -Uvh
> > /tmp/spacewalk-build/noarch/spacewalk-search-*.git.*.noarch.rpm
> >
> > 3) After 'Web Application Installation' section, I had to replace
> > two symlinks with their targets, and then restart the spacewalk
> > service. (as root)
> > cd /var/www
> > ls -l html
> > html -> /home/dev/spacewalk/web/html
> > mv html html.orig; cp -r -L /home/dev/spacewalk/web/html html
> >
> > cd /usr/share/tomcat5/webapps/
> > ls -l rhn
> > rhn -> /home/dev/spacewalk/java/rhnwebapp
> > mv rhn rhn.orig; cp -r -L /home/dev/spacewalk/java/rhnwebapp rhn
> >
> > /usr/sbin/rhn-satellite restart
> >
> > 4) Under section 'Deploying development schema' the usage of
> > /etc/init.d/rhn-satellite should be changed
> > to /usr/sbin/rhn-satellite.
> >
> > 5) The GITDIR environment variable is used in three places, but is
> > never asked to be initialized anywhere. In my case, when doing 'Web
> > Application Installation' section, GITDIR was supposed to
> > be /home/dev/ and when in section 'Deploying development schema' it
> > is supposed to point to /home/dev/spacewalk (otherwise cd
> > $GITDIR/schema/spacewalk wouldn't work).
> >
> > So, IMHO, it should point to /home/dev/spacewalk so that ls
> > $GITDIR shows schema/ contrib/ playpen/ etc.
> >
> > Also, since this variable can be easily confused with Git's own
> > GIT_DIR (which is seldom used, but points to .git/ in a repo), lets
> > change this variable to SRCDIR or something similar.
> >
> > Best regards,
> > --
> > gurjeet[.sin...@enterprisedb.com
> > EnterpriseDB http://www.enterprisedb.com
> >
> > singh.gurj...@{ gmail | hotmail | indiatimes | yahoo }.com
> >
> >
> > ___
> > Spacewalk-devel mailing list
> > Spacewalk-devel@redhat.com
> > https://www.redhat.com/mailman/listinfo/spacewalk-devel
> >
- --
Devan Goodwin
Software Engineer Spacewalk / RHN Satellite
Halifax, Canada 650.567.9039x79267
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkmBq6cACgkQAyHWaPV9my7shQCgqQuxvx/J3niFz5RbZSbJMYP5
sXAAnAls7PbzlJhrLW4s19FroAxk2lYL
=saYh
-END PGP SIGNATURE-
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Fedora Status
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 29 Jan 2009 12:19:26 +0100 Miroslav Suchý wrote: > Dennis Gilmore wrote: > > All but 2 packages in git are built for fedora. > Good. Thx. > > > Please when you build build for F-10 also. instructions are > > https://fedorahosted.org/spacewalk/wiki/ReleaseProcess > > It wil be nice to have some target in Makefile.git (and/or build.py) > to build in both tags at once. Something like: > make release > like we have for sat520. > > Will you do it or should I do it? This was actually done via dist-cvs in 5.2 and while adding similar support is on my todo list (though some way down in priority :() this isn't really an option for Spacewalk koji. So to do it we'd probably have to mock up similar behavior without dist-cvs, so in case someone does have the drive to go ahead to give it a shot here's an idea how it might be done with build.py: - - Add support for parsing multiple --brew or --koji options. - - Add section to rel-eng/global.build.py.properties like [disttaglookup] with entries like: kojitag1=.el5 kojitag2=.fc10 etc. - - Then it's just a matter of creating multiple srpms with the right dist tag and shipping them off to brew. I hope to look at this someday but too many other things of higher priority for now. Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmBrRAACgkQAyHWaPV9my5cLgCbBOz6m01WVAPDeurnZt2fXFXh 6MYAn0Mna+CA4kSkubO5dRAnOR/c2Fzl =M9hB -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Changes needed in wiki for CentOS development environment setup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 29 Jan 2009 08:59:58 -0500 "Jesus M. Rodriguez" wrote: > > Let's be careful how we add to that document. We want the document to > be accurate but as simple as possible. I don't like it when we have a > bunch of conditionals in a howto, makes it more difficult to follow. > For example, I do *NOT* care for something like this: > > = Importing GPG keys = > > For Red Hat Enterprise Linux, > > rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-former > rpm -e specspo > yum install gpg > yum install spacewalk > > If you are using CentOS, > wget http://www.redhat.com/security/db42a60e.txt > mv > db42a60e.txt /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-former rpm > --import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-former > > If you are using Fedora, > > .--- > > If the document will have a bunch of those types of changes, I'd much > rather have a separate page for each. > > jesus > My only concern is the one document we have today is already falling painfully out of date. Adding another two to the mix is just going to get worse. If the differences start getting drastic then I guess we'll probably need it but between RHEL 5 and CentOS 5 I don't think we're seeing anything that a "CentOS step" flag wouldn't fix. (or even better assume CentOS and flag things that don't need to be done in RHEL) Once we're throwing Fedora in the mix (hopefully soon) it may be another story. Cheers, Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmBv/MACgkQAyHWaPV9my5x7QCfeiMxvzI0e+28JBHA+1v8zRal YykAnRXPiAETBRU97Ybwr9eDk0s0+7+2 =8nSj -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] PGPORT: Early Schema Requests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As mentioned in phone call this morning, a couple early requests for PostgreSQL schema + procs to be ported, I ran into a need for these in spacewalk-setup: Stored procedure: create_first_org.sql It delves out into a few tables, hopefully not far and if it goes too far then surely it's not possible to get it up and running quickly but I thought I'd make the request just in case. :) Cheers, Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmBxEUACgkQAyHWaPV9my4YxwCfQ3NcmFtGvGdhHzxKRo8Rg9kF FG0Anja/hFbY2ymjYJuuzI25attcgwUR =jtyf -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PGPORT: Early Schema Requests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 29 Jan 2009 21:00:06 +0530 Gurjeet Singh wrote: > Can you post the exact error message you got? Not really an error so much as my code tries to call the procedure but I have no PostgreSQL schema or procedures yet. :) The ora2pg generated schema currently checked into git is *totally* broken. :) It errors out in a magnificent fashion when trying to load it, and psql was returning success code 0. :) I'm going to get rid of that schema today and make a proper directory layout for Makefile and order.sql as per emails earlier this week. > > >From the looks of it, I think following are the issues with it: > > 1) In Postgres we have to CREATE FUNCTION RETURNS VOID. > > 2) rhn_user_group_id_seq.nextval is being used, so we need to port > that Sequence too. > > Will be doing this in about an hour from now.. let me know if you need > anything more. Many thanks! Devan > > Best regards, > > On Thu, Jan 29, 2009 at 8:29 PM, Devan Goodwin > wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > As mentioned in phone call this morning, a couple early requests for > > PostgreSQL schema + procs to be ported, I ran into a need for these > > in spacewalk-setup: > > > > Stored procedure: create_first_org.sql > > > > It delves out into a few tables, hopefully not far and if it goes > > too far then surely it's not possible to get it up and running > > quickly but I thought I'd make the request just in case. :) > > > > Cheers, > > > > Devan > > > > - -- > > Devan Goodwin > > Software Engineer Spacewalk / RHN Satellite > > Halifax, Canada 650.567.9039x79267 > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v2.0.9 (GNU/Linux) > > > > iEYEARECAAYFAkmBxEUACgkQAyHWaPV9my4YxwCfQ3NcmFtGvGdhHzxKRo8Rg9kF > > FG0Anja/hFbY2ymjYJuuzI25attcgwUR > > =jtyf > > -END PGP SIGNATURE- > > > > ___ > > Spacewalk-devel mailing list > > Spacewalk-devel@redhat.com > > https://www.redhat.com/mailman/listinfo/spacewalk-devel > > > > > - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmBzRUACgkQAyHWaPV9my4pDwCeL26msQdXVWNTQkrkvPe7GkDC QN8An3z9S/qj9uGYFrX2PHcgCHL9/sGo =oJo9 -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] PGPORT: PostgreSQL Schema Directory Layout Checked In
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Added a start on the PostgreSQL schema layout in the pgsql branch and some dummy tables/procedures. (will remove these as soon as there's *any* real schema in play) cd schema/spacewalk/postgresql/ psql -f main.sql -d spacewalk For the record I've been using the following to destroy and re-create my "spacewalk" database, in case it's useful to anyone: $ dropdb spacewalk && createdb spacewalk && createlang plpgsql spacewalk Onward and upward, Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmB3DoACgkQAyHWaPV9my5TWwCfbwtBKZfJ/lG/+aPTRtrZtSHe BfIAnjcl3zj2rEgCuUsGE1Vs9189QQ6c =hOaZ -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] PGPORT: Checking psql Success From Shell Script
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Working on the population of PostgreSQL schema in spacewalk-setup I landed in rhn-populate-database.pl, got the script ready to populate pgsql schema as well but even if the schema population fails miserably, the psql executable returns a 0 success code. Anyone have ideas for a good way to progrematically check if the population was successful? For the record the population code looks like: my $psql_cmd = "PGPASSWORD=" . $password . " psql -U " . $user . " -h " . $host . " " . $database . " < " . $schema_deploy_file; $pid = open3(gensym, ">&LOGFILE", ">&LOGFILE", $psql_cmd); Thanks, Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmCCycACgkQAyHWaPV9my7m+wCgsBixKLS4PIhCEJtLiK7P0yHq TlYAn3ofYMCEA5Jms6HwK1GPuG9YkEM9 =JkFW -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PGPORT: Checking psql Success From Shell Script
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 29 Jan 2009 21:57:10 +0100 Jan Pazdziora wrote: > On Thu, Jan 29, 2009 at 04:01:40PM -0400, Devan Goodwin wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Working on the population of PostgreSQL schema in > > spacewalk-setup I landed in rhn-populate-database.pl, got the > > script ready to populate pgsql schema as well but even if the > > schema population fails miserably, the psql executable returns a > > 0 success code. > > > > Anyone have ideas for a good way to progrematically check if the > > population was successful? > > Can't you check back (with select) that whatever is the last > command in $schema_deploy_file got executed properly? For example, > that the version of the schema got actually set? Probably will have to do something like this soon anyhow to check if pre-existing schema exists. > > > For the record the population code looks like: > > > > my $psql_cmd = "PGPASSWORD=" . $password . " psql -U " . > > $user . " -h " . $host . " " . $database . " < " . > > $schema_deploy_file; $pid = open3(gensym, ">&LOGFILE", ">&LOGFILE", > > $psql_cmd); > > If you use open3, please, please, please, do not join. Two months > from now we'll be again having a bugzilla when someone has ', or ", > or & in their password. > Sure thing. Thanks. Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmCGlsACgkQAyHWaPV9my6/SgCgr2OBez+4bJTrRf28pkGH/Q57 uEEAoILnu5Oqw0KUgRI/ZGDwVuftN4r6 =UtZT -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PGPORT: Checking psql Success From Shell Script
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 30 Jan 2009 02:18:51 +0530 Gurjeet Singh wrote: > Reading up on 'Exit Status' section in > http://www.postgresql.org/docs/8.3/static/app-psql.html shows that it > will return 3 if ON_ERROR_STOP was set, and it was run using a script. > > So I guess you need to do it as: > > my $psql_cmd = "PGPASSWORD=" . $password . " psql -U " . > $user . " -h " . $host . " " . $database . " -v ON_ERROR_STOP= -f " . > $schema_deploy_file; > > HTH, Just what the doctor ordered. Thanks! Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmCVSAACgkQAyHWaPV9my7WbQCgiPkxH6WVYE2dq0r+VYYYZHPs hrkAoIUp3dfuxVyM8TlK/J0HTLJzuD9q =osah -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Re: PGPORT: Orafce
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 30 Jan 2009 15:26:36 +0100 Jan Pazdziora wrote: > On Fri, Jan 30, 2009 at 09:17:39AM -0500, Jeff Ortel wrote: > > > > Whether this is done via 1) compatibility layer or 2) migrating > > the queries to ANSI SQL or both is another question. The advantage > > of doing it in the compatibility layer is (maybe) lower risk when > > running on Oracle. But, since we know there are many queries that > > must be rewritten (for example: queries with the oracle (+) syntax > > for outer joins) anyway, why not just do the right thing now and > > get it over with while we're committed to spending the $$ and time > > to do this? If satellite is going to become a multi-database > > application, shouldn't the application code be as database agnostic > > as possible? > > Agreed with the intention. But why is this part of the PostgreSQL > effort. Shouldn't this be completely independent goal, with its own > requirements and plan and test plan? I don't see why it should be separated in the first place but if it were, it should probably be done before the PostgreSQL effort (otherwise there'd be some wasted effort involved) implying that we (a) need to put that on hold and (b) find people to do it. We've already got people with a strong background in both databases and are already prepping for a big test/QA impact, I say hit it while we're in there. Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmDE70ACgkQAyHWaPV9my4PfgCfWuasLd86THFxPiakQleGiWNr gUYAoMLO18gxJQHrOgKEvVLl6pbjUw0a =q/aK -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Constructor problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 2 Feb 2009 13:54:49 +0900 "Coe, Colin C. (Unix Engineer)" wrote: > ctx.getRequiredParam(RequestContext.NAME) Hey Colin, Looks like this is getting populated with a Long not a String. (a println would confirm) Are you setting "name" in the context somewhere in your diff that wasn't included? Cheers, Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmG46IACgkQAyHWaPV9my7ThACguBFNITiCuAwCMQ6sWOpeS7X1 vywAoL5rCwB9vIzbX2s43YDRk0N38Bbo =3c3o -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] PGPORT: Another porting request.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hey guys, blocked on another spot in the installer and wanted to queue
these items up for porting:
Out of backend/satellite_tools/satCerts.py:
_query_latest_version = rhnSQL.Statement("""
SELECT nvl(version, 0) version, version orig_version, cert,
TO_CHAR(issued, '-MM-DD HH24:MI:SS') issued,
TO_CHAR(expires, '-MM-DD HH24:MI:SS') expires
FROM rhnSatelliteCert
WHERE label = :label
ORDER BY version DESC NULLS LAST
""")
So rhnSatelliteCert needs some mappings, I think the TO_CHAR looks
usable in PostgreSQL, is it just the nvl that needs to change here?
You can see quite a few other queries in the file, I don't know how
many of them are going to end up getting called but this is the first
one I hit.
Thoughts?
Thanks,
Devan
- --
Devan Goodwin
Software Engineer Spacewalk / RHN Satellite
Halifax, Canada 650.567.9039x79267
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkmHni0ACgkQAyHWaPV9my6UAACeJQlpd/p5CPHCN0oq/31DX/TI
JPUAnRuHFy6c0Gr8xSUNcOF+SHf2uMVc
=82ZA
-END PGP SIGNATURE-
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PGPORT: Another porting request.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 3 Feb 2009 19:11:39 +0530
Gurjeet Singh wrote:
> On Tue, Feb 3, 2009 at 6:34 PM, Jan Pazdziora
> wrote:
>
> > On Tue, Feb 03, 2009 at 06:26:19PM +0530, Gurjeet Singh wrote:
> > > >
> > > > How about
> > > >
> > > >order by decode(version, null, 1, 0), version
> > >
> > > Yup... that'll work, but will mess up the ordering if more than
> > > one of version's values is non-null.
> > >
> > > SQL> select * from t order by decode( a, null, 1, 0 );
> > >
> > > A
> > > --
> > > 1
> > > 2
> > > 4
> > > 3
> > >
> > >
> > >
> > > 6 rows selected.
> >
> > That's why my proposed solution was
> >
> >order by decode(version, null, 1, 0), version
> >
> > not just
> >
> >order by decode(version, null, 1, 0)
> >
> >
> Right.. I missed that last reference to version!
>
Couldn't get decode to work initially but the case seemed ok and I
ended up with:
diff --git a/backend/satellite_tools/satCerts.py
b/backend/satellite_tools/satCerts.py index 290b987..692a39c 100644
- --- a/backend/satellite_tools/satCerts.py
+++ b/backend/satellite_tools/satCerts.py
@@ -311,12 +311,17 @@ _query_update_dates = rhnSQL.Statement("""
""")
_query_latest_version = rhnSQL.Statement("""
- -SELECT nvl(version, 0) version, version orig_version, cert,
- - TO_CHAR(issued, '-MM-DD HH24:MI:SS') issued,
- - TO_CHAR(expires, '-MM-DD HH24:MI:SS') expires
+SELECT COALESCE(version, 0) as version, version as orig_version,
cert,
+ TO_CHAR(issued, '-MM-DD HH24:MI:SS') as issued,
+ TO_CHAR(expires, '-MM-DD HH24:MI:SS') as expires
FROM rhnSatelliteCert
WHERE label = :label
- - ORDER BY version DESC NULLS LAST
+ ORDER BY
+ CASE WHEN version IS NULL
+THEN -1
+ELSE version
+ END
+DESC
Holler if you spot any problems.
Cheers,
Devan
- --
Devan Goodwin
Software Engineer Spacewalk / RHN Satellite
Halifax, Canada 650.567.9039x79267
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkmIkXQACgkQAyHWaPV9my7dEACfS10NMN0d8VtNyufpVUD1dkfZ
E5MAnRvl1+R7d1Cve65TyQbS4R4+15As
=o65X
-END PGP SIGNATURE-
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PGPORT: Another porting request.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 3 Feb 2009 20:24:06 +0100 Jan Pazdziora wrote: > On Tue, Feb 03, 2009 at 02:48:15PM -0400, Devan Goodwin wrote: > >FROM rhnSatelliteCert > > WHERE label = :label > > - - ORDER BY version DESC NULLS LAST > > + ORDER BY > > + CASE WHEN version IS NULL > > +THEN -1 > > +ELSE version > > + END > > +DESC > > > > Holler if you spot any problems. > > Can't we just use those two fields, in the ORDER BY query? What two fields? > > I do not like that use of -1, which I assume is in the domain of > the type of version. > It might work in this case now but it might > confuse people reading the code five years from now, and it might > confuse people who will be porting the NULLS LAST construct in > situation when the value of choice will actually be a possible > value of the column used. > Could you rephrase the last part of this? Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmIoWUACgkQAyHWaPV9my4/FACgpwcZoWV5lxwXZi28irjB8GzP 6CcAoMA3f3rIz/fFKRey8QUgn8o6mwF3 =C4Ti -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PGPORT: Another porting request.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 4 Feb 2009 11:01:45 +0100 Michael Mraka wrote: > % > Can't we just use those two fields, in the ORDER BY query? > % > % What two fields? > > order by decode(version, null, 1, 0), version Tried this before I went to the case but it didn't work, I think decode in PostgreSQL looks like it has a different meaning and signature, seems to be used for binary data. > or > order by CASE WHEN version IS NULL > THEN 1 > ELSE 0 >END, version Changed to this. Thanks, Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmJkRgACgkQAyHWaPV9my64kwCfaAFAdhjj8hOnWRsWQ2sFdKOm wB4AoIhNiW/RfNfp19ROb18DqGtEYKnX =0HA/ -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Re: PGPORT: Porting tables; contributions needed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Working on web_user_personal_info.sql and web_contact*.sql. Cheers, Devan On Tue, 3 Feb 2009 16:48:55 +0530 Gurjeet Singh wrote: > I am starting to work on the following set of tables: > > schema/spacewalk/rhnsat/tables/rhnAction*.sql > > Best regards, > - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmJuzYACgkQAyHWaPV9my5x/gCgo3ahckwI/lZ2Kdtzr7uZ8Yw2 8TEAn3BW7D3264tkZDGAR70VzppbDmi/ =1oQJ -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Do I report this as a bug?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 5 Feb 2009 15:33:58 -0500 (EST) wrote: > I've tried to install both the 64-bit version and the 32-bit version, > both on CentOS 5.2 (Final). I've been trying this for a week (29/30 > Jan). Fresh install of o/s (running under VMware ESX as a "guest" > system). What I've installed is what's pulled down with yum for > spacewalk .4 > > I've followed all the directions, including the oracle post-install > additional config, and put selinux in permissive mode. I've also > made /etc/rhn/rhn.conf readable by apache. And run cobbler-setup. And > fixed some issues that cobbler check wanted. This right here sets off alarm bells, whatever is causing you to have to do these above steps (chmod rhn.conf, cobbler-setup, etc) is very likely to be the root of your problems. I think you need to hit the brakes here and figure out what's causing this before proceeding. We have established that Spacewalk installs do not normally hit these problems you're experiencing, so to me your situation screams of two possible causes. The least likely is there's a problem with Spacewalk within Vmware, the more likely is that you're doing something unorthodox or unexpected during the install and not even realizing it. No offense but your emails are littered with rogue commands to hack around problems that make it extremely difficult to tell what you may have done to the system during the install, so we need to know precisely what you've done to rule this out. If you really want to get this fixed I think you need to start with a fresh Cent OS install and note each and every command you run and task you perform as you install spacewalk right up until the point that you realize you need to chmod rhn.conf. (for starters) Send that off to the list and we'll see what happens from there. Cheers, Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmLV8sACgkQAyHWaPV9my5hdwCbBJ51USom5sflLVlagHA9xZeI YuAAnRsrWQKts+t6SnEh3cIURk0CqofV =FoLb -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PGPORT: CONNECT BY queries
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 6 Feb 2009 18:22:49 +0530
Gurjeet Singh wrote:
> Hi All,
>
> As I mentioned in the last conference call, I could not implement
> a workaround for CONNECT BY in plpgsql; that was because of a
> limitation in the way plpgsql handles the pseudo datatype RECORD.
>
> So, I turned to implementing it as an add-on in C. But I wanted to
> actually see how much the reward would be if I did that, so I
> performed a better grepping of the sources than before and this is
> what I saw:
>
>
> $ find ./ -type f | grep -v \' | grep -v \.git | xargs -r grep -i
> "[[:space:]*]connect[[:space:]+]by"
> ./backend/server/rhnAction.py: connect by prior id =
> prerequisite
> ./java/scripts/explain_plan.pl:connect by prior id=parent_id;
> ./java/code/scripts/src/com/redhat/rhn/scripts/ExplainPlanGenerator.java:
> "connect by prior id = parent_id " +
> ./monitoring/PerlModules/NP/NOT-USED/ReleaseDB/ReleaseDB.pm:
> CONNECT BY prior component_class = macro_class
> ./schema/util/explain.sql:connect by prior id = parent_id and
> statement_id = :stmt_id
> ./schema/util/explain_plan_for_queries.py:connect by prior id
> = parent_id and statement_id = 'query_explain'
> ./schema/spacewalk/rhnsat/packages/rhn_server.pkb:
> connect by prior id = prerequisite
> ./schema/spacewalk/test-universe.satellite.sql: connect by
> prior id = prerequisite
> ./schema/spacewalk/universe.satellite.sql: connect by
> prior id = prerequisite
>
>
> (In previous "crude" grep I had encountered 125 instances!)
>
> Of these, only two were the real candidates:
> ./backend/server/rhnAction.py: connect by prior id =
> prerequisite
> ./schema/spacewalk/rhnsat/packages/rhn_server.pkb:
> connect by prior id = prerequisite
>
> and both these instances SELECT the same data: given an action_id,
> give me all the pre-requisites in order.
>
> So I have written two plpgsql functions to accomplish what these two
> instances need. Please find the code and a few examples attached.
>
> Using these functions, the queries can now be written as:
>
> ./backend/server/rhnAction.py:
>
> _query_lookup_action = rhnSQL.Statement("""
> select sa.action_id, sa.status
> from rhnServerAction sa,
> (
> select id
> from rhn_get_action_prerequisites( :action_id )
> as f( id numeric, prerequisite numeric, level
> int) / start with id = :action_id
> connect by prior id = prerequisite ****/
> ) a
> where sa.server_id = :server_id
>and sa.action_id = a.id
> """)
>
> Best regards,
If we modify the queries to use these functions I assume we need Oracle
implementations as well?
Cheers,
Devan
- --
Devan Goodwin
Software Engineer Spacewalk / RHN Satellite
Halifax, Canada 650.567.9039x79267
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkmMQpIACgkQAyHWaPV9my6HEACfaYg5KPAjsI6f0cd+y+QrkdpB
Ho4An0m5liOFAGdJkmpXROUOiwZk7Xb8
=WpQX
-END PGP SIGNATURE-
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] commit messages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 6 Feb 2009 10:41:21 + Rob James wrote: > Looking at the commit logs recently a lot of the linked Bugzilla > reports seem to have restricted access - is this just that they are > coming from the Satellite QA or is it that they have customer info in? > Where possible it would be nice for the community for bug reports to > be open access. > > -R This was likely an oversight, we try to make a public Spacewalk bug for anything reported against Satellite and use that in the Spacewalk commit messages. Cheers, Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmMQ6UACgkQAyHWaPV9my4RBACgpwn7h7rkmaXB/ftjZIX3IV25 OCQAnA+YuV1OXGgLRmfdEUgudlnxWMcu =Lg3Z -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PGPORT: CONNECT BY queries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 6 Feb 2009 19:37:28 +0530 Gurjeet Singh wrote: > > > Hmm.. Although that is doable, I haven't thought about that. The way > I saw it was that we'd have a IF(ORACLE) CONNECT BY ELSE IF(POSTGRES) > CALL FUNCTION END kinda code... > > Thinking a bit, I don't see a point in porting this to Oracle! The > calling syntax will be different for both the databases anyway: > Oracle: > select x,y from TABLE( function() ); > Postres: > select x, y from function() as f( x int, y int). > > So I guess we will _have_ to keep two versions of the query at least > in the python code. The other usage in PL/SQL package is anyway going > to be ported over. > > Best regards, Ok this is something we'll need to be very careful with. We kinda knew this was coming (having to fork queries for each database) but we'll need to plan ahead for this on our end. The python queries are all just variables in the source so it's probably in our best interest to setup a quick framework for using one set of queries by default, and allowing them to be overridden depending on your database backend. I will add this to my TODO list. However if anything occurs to you for a way we can keep the query static for both databases that would be great! Cheers, Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmMRzwACgkQAyHWaPV9my4WIACfcIsfWWUo9XVnQC00E4ILgQyK cxYAoINtsaE6bM+5YXJatbIynLCV/X7r =rC9y -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] commit messages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 6 Feb 2009 16:53:29 + Rob James wrote: > In the last 24 hours of commits at least these seem to be restricted: > > Justin Sherrill [Fri, 6 Feb 2009 16:31:49 +] > 458943 - fixed issue where having 500 items on a page and clicking > confirm would result in page not found > > Brad Buckingham [Fri, 6 Feb 2009 16:16:42 +] > 483824 - fix apidoc error on errata.listKeywords > > Pradeep Kilambi [Thu, 5 Feb 2009 22:08:17 +] > bug#480028 adding debug options to migration script > > Mike McCune [Thu, 5 Feb 2009 19:53:18 +] > 481767 - be more forgiving of busted kickstart distros during a sync > and also report errors in an email. > > Justin Sherrill [Thu, 5 Feb 2009 17:56:29 +] > 443718 - fixing a view mistage and having a query just use the view > Yikes that's a lot for 24 hours. :) We'll try to do better with this. Thanks for the heads up. Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmMdV8ACgkQAyHWaPV9my4i7ACgiJ3O1xkMdyADNvVf3LFZU4KP nOkAoL0Oq0idKSw4SG9D4EB66Jsp1WSt =brLP -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Note On Recording Git Commit IDs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just some clarification on comments in meeting this morning, when recording a git commit ID in bugzilla you want to do your fix, push your changes, THEN lookup the SHA1 for your commit in the history. Note that a rebase is basically taking your local commits and re-applying them on top of the current state of the upstream branch. (which often has changed since you started working) Because these diffs are getting reapplied, the commit SHA1s (which are specific to the state of the source tree as a whole) will change. Cheers, Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmQS7QACgkQAyHWaPV9my7EbwCfRX6OfmcH9kN/Hc115DvKAKqw ufwAoLZ+/oLpP6EElPfTYS2skjXKigFl =w7OB -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] build.py: CLI Changes Coming Soon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Working on cvs build integration for build.py and seeing some cleanup that needs to happen before things start getting out of hand. I'm proposing the following changes: 1. Make it installable via setup.py: - - install on your system with "sudo python setup.py install" - - re-run when you need to get the latest code. - - Doing this because tracking the code in specific branches is going to bite someone sooner or later. (something's fixed in master that you need when building in another branch or repo) - - Will leave thin rel-eng/bin/build.py script in place to run directly from source if you really don't want to install it. 2. Rename the main executable: - - Really don't want to put something into /usr/bin named build.py. - - Was thinking 'tito', our magical rel-eng helper. - - Other suggestions? 3. Restructure the CLI into modules like yum or cobbler: - - Options now are getting convoluted in a flat list. - - Doing several high level tasks that shouldn't be combined. - - New interface will look like: tito build --tgz --rpm --srpm --test tito tag-release --keep-version tito report --untagged-diffs tito cvs-release [options TBD] With options like --debug available in all modules. Hoping to be able to implement some of these as I go this week, so they won't be landing for a little bit, but let me know if you see any issues or have suggestions. Thanks, Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmQmFYACgkQAyHWaPV9my7etQCfUaFy1x8lLM6ZHEjxtHqAESQ7 cBQAoKho3a4SAx/hlFRf1xzw3MRQROTZ =z8Cc -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] build.py: CLI Changes Coming Soon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 10 Feb 2009 11:22:05 +0100 Miroslav Suchý wrote: > Devan Goodwin wrote: > > 1. Make it installable via setup.py: > Why would I want it to install? So you can use latest code on any branch or git repo. > How I manage the updates if I install > it? Should I then manualy track the changes in rel-eng/bin and when > file change, then reinstall it? > > > - - re-run when you need to get the latest code. > How would I know when to re-run it? When something breaks. :) When an email comes out for an urgent change. When you want something new. Or just keep using the build.py to run from source. :) > > > - - Doing this because tracking the code in specific branches is > > going to bite someone sooner or later. (something's fixed in > > master that you need when building in another branch or repo) > Jan had ionce idea for Makefile, that the Makefile will do as first > think checkout of rel-eng/ from master and then will call the > Makefile from this checkout. This way you will have always fresh code > even if you are building from some old branch. > But this idea never been implemented. This is an interesting idea, build.py could be a thin script that checked out the latest code from master in /tmp and ran it from there. Will give this some thought. > > > - - Was thinking 'tito', our magical rel-eng helper. > +1 > > > 3. Restructure the CLI into modules like yum or cobbler: > Instead of refactoring cli can you instead change the behavior to be > more friendly? You'll have to be more specific. The problem is the command options relevant to each of the high level tasks in original email are doing very different things. Logic checking what options can and cannot be combined is starting to spiral and should be addressed as soon as possible. > > My dislikes with build.py: > Have to specify path for each run (sometimes it can be dot hell): >$ ../rel-eng/bin/build.py --srpm > compared to >$ make srpm > And - no, I do not want to modify PATH since I have more then one > checkout and I want to use the script from that checkout I'm > currently using. Why would you want the script from current checkout and not spacewalk master? Avoiding this is the whole reason behind installing it on the system or checking out latest code. Honestly I added it to my path and I've been using it in as many branches and repos as anybody, it works fine, I actually highly recommend this over using the one in satellite repo which could be lagging behind. If you're in old branches it's even worse. > > $ cat build.py.props > [buildconfig] > builder = spacewalk.releng.builder.Builder > tagger = spacewalk.releng.tagger.VersionTagger > > Compare to: > $ cat Makefile > include ../../rel-eng/Makefile > > Why should I care about some classes? Why can not I use some simple > switch like: > KEEP_VERSION=1 > I really do not want to study code of build.py when I create > build.py.props It contains class names to accommodate the possibility of a future project needing customized build/tag classes, the use case hasn't surfaced yet but I wanted to plan for it. I don't want a situation where we have NO_TAR_GZ=1 now, then someday we need a BUILD_LIKE_THIS=1 and the two conflict with each other, and the logic checking expands from there. More recently we're wondering if the existence of these projects being built from .tar.gz checked into git is even something we should be doing. We might be moving them out to cvs but will see how this goes while adding cvs functionality. If this is somehow affecting your daily use then we can look at it but given that it's only relevant when creating a brand new project in git and all you have to do then is cp an existing one and forget about it, I'm assuming it's just a passing annoyance. Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmRfXgACgkQAyHWaPV9my5sLgCeLqhU/J4hx5w8EL3x9Cy1sfUN /uYAn3a9MiNj88U1pe8SRtDThZ04kqrP =KWQa -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] build.py: CLI Changes Coming Soon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 10 Feb 2009 10:57:42 +0100 Jan Pazdziora wrote: > On Mon, Feb 09, 2009 at 04:55:47PM -0400, Devan Goodwin wrote: > > > > Working on cvs build integration for build.py and seeing some > > cleanup that needs to happen before things start getting out of > > hand. I'm proposing the following changes: > > > > 1. Make it installable via setup.py: > > Make ^ what *it* installable? build.py? > > > - - install on your system with "sudo python setup.py install" > > - - re-run when you need to get the latest code. > > Why is this? Shouldn't programs be installed via rpm, always? Because packaging up rpms for all operating systems developers use, setting up yum repositories, getting everyone subscribed, and pushing out packages is overkill for what we're trying to accomplish. (at least at this point, if a yum repo becomes required then we set one up) > > > - - Doing this because tracking the code in specific branches is > > going to bite someone sooner or later. (something's fixed in > > master that you need when building in another branch or repo) > > - - Will leave thin rel-eng/bin/build.py script in place to run > > directly from source if you really don't want to install it. > > Could you maybe explain what you try to achieve and how the > behaviour will change from what Makefile.svn used to do? Not at this point in time, I'm just starting to decipher what Makefile.svn does and come up with a plan, need to have some long chats with Dennis as well but essentially it will do roughly what make release did back in svn for 5.2. > > > 2. Rename the main executable: > > - - Really don't want to put something into /usr/bin named > > build.py. > > - - Was thinking 'tito', our magical rel-eng helper. > > - - Other suggestions? > > > > 3. Restructure the CLI into modules like yum or cobbler: > > - - Options now are getting convoluted in a flat list. > > - - Doing several high level tasks that shouldn't be combined. > > - - New interface will look like: > > > > tito build > > --tgz > > --rpm > > --srpm > > --test > > tito tag-release > > --keep-version > > tito report > > --untagged-diffs > > tito cvs-release > > [options TBD] > > > > With options like --debug available in all modules. > > > > Hoping to be able to implement some of these as I go this week, so > > they won't be landing for a little bit, but let me know if you see > > any issues or have suggestions. > > I'd much rather see us having *some* way of building via dist-cvs than > starting another refactoring of the code again. > As stated, cvs support is what I am working on. Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmRh5AACgkQAyHWaPV9my7ELQCfUEgPlqAGE/eEYcmtFRzn22l7 ba0An0p+A2SZXTyB5mSlFbuVmUOzOu+P =tN48 -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PATCH: remove duplicate 'isRhel2' check from code/src/com/redhat/rhn/domain/kickstart/KickstartInstallType.java
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 11 Feb 2009 21:20:45 +0900 "Coe, Colin C. (Unix Engineer)" wrote: > Hi all > > Real simple patch to remove a duplicate check. > > CC > > NOTICE: This email and any attachments are confidential. > They may contain legally privileged information or > copyright material. You must not read, copy, use or > disclose them without authorisation. If you are not an > intended recipient, please contact us at once by return > email and then delete both messages and all attachments. LOL, nice find. :) Applying now. Thanks, Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmSxnwACgkQAyHWaPV9my4d3wCg5ZO2PWs1dSDpSEuGWulZQ325 0rAAn3vo0o1u2c+IIejaLmqL/jwn+M4G =/V6o -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] BaseSubscribeAction
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 11 Feb 2009 11:20:31 -0500 Jason Dobies wrote: > Looks like this class hasn't really been changed since it was moved to > git, so I figured I'd fire out the question here to see if someone can > give me a hand. > > I'm looking at https://bugzilla.redhat.com/show_bug.cgi?id=485085 . In > short, I'm seeing an error changing a base channel through the SSM > when you're changing from the default channel to the default channel > (I know, it's a weird case). > > In particular BaseSubscribeAction line 166 is what's confusing me. > > If I'm reading this right, we get here if you're changing to the > default base channel (it will be ID -1, which gets us into the > condition at 164). > > What I don't get is why we're loading a DistChannelMap for the old > channel. When my old channel is the default base, that map is coming > back as non-null. That's causing me to get to line 169, but ends up > with a null pointer exception at 172. Starting to remember a bit about this. So rhnDistChannelMap is used to map to the main RHEL channel for a given version arch and product. The first dist channel map lookup is because we don't have access to some of these parameters in this context for that system (can't remember which). I recall fighting with this and being unable to query that information any other way. As per IRC discussion I think the problem is the use of ChannelManager.RHEL_PRODUCT_NAME in line 169 (the second lookup). That table stores "Red Hat Linux" as the product name, but RHEL_PRODUCT_NAME = "rhel" and even has some notes above where it's defined stating how product name changes from table to table. Not real sure why this hasn't broken before now... Still investigating, will hit you up on irc. Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmTA6oACgkQAyHWaPV9my7/zwCggnbJRTEf4af+md6VV7tAZEql JRoAninlKQ5sOEp1/uBWIqMPfgsGPbec =/GzY -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PGPORT: Instructions for porting procedures/functions
.raise_exception('arch_type_not_found');
>
>
>
> exception
> when no_data_found then
> PERFORM
> rhn_exception.raise_exception('arch_type_not_found');
>
>
> .) SHOW ERROR and /
> In Postgres the ERRORs encountered in creating a plpgsql using
> are shown immediately; so we don't need to port SHOW ERROR. Just get
> rid of it. Also, psql (postgres CLI client) automatically detects end
> of function code, so the / (slash) after each function/procedure is
> not needed either.
>
> .) AUTONOMOUS TRANSACTIONS
> Remove the COMMIT staments; Oracle requires that an
> AUTONOMOUS_TRANSACTION be explicitly COMMITted, else it will be
> rolled back. This does not apply to Postgres.
>
> And example of porting fllows:
> Oracle version:
> ===
> create or replace function del( a int, b char, c varchar ) return int
> as pragma autonomous_transaction;
> begin
> return 10;
> commit;
> end;
> /
>
> Postgres version:
> =
>
> /* the actual function should be renamed */
> create or replace function
> del_autonomous( a int, b char, c varchar)
> returns int as $$
> begin
> return 10;
> end;
> $$ language plpgsql;
>
> /* now create a wrapper for the autonomous version */
> create or replace function
> del( a int, b char, c varchar )
> returns int as $$
> declare
> ret int;
> begin
> select retcode
> into ret
> from dblink( 'dbname='||current_database(),
> 'select del_autonomous( '
> || coalesce( a::varchar, 'null' ) || ', '
> || coalesce( quote_literal( b ), 'null' ) || ', '
> || coalesce( quote_literal( c ), 'null' ) ||
> ' )' )
> as f( retcode int );
>
> return ret;
> end;
> $$ language plpgsql;
>
>
> .) OUT parameters
>
> (no concrete/clear implementation details yet; am in consultation
> with PG community)
>
>
- --
Devan Goodwin
Software Engineer Spacewalk / RHN Satellite
Halifax, Canada 650.567.9039x79267
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkmUHTkACgkQAyHWaPV9my4iXACfWTpMXWxrt6ShyA6lObPX1iJR
MrMAoLaek6nc2atdhfteozcFXjXriCtS
=kBnX
-END PGP SIGNATURE-
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] MySQL support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 10 Feb 2009 16:48:16 +0100 Matej Hasul wrote: > Hello everyone, > I will try to port spacewalk DB to mysql as part of my master's > thesis. > > I installed spacewalk server and 2 clients and tried some basic > operations (installing/removing packages, configuration channel, etc). > > In following days I will browse DB schema and try to identify what > functionality is mysql missing and how to replace it. > > Any help, suggestions or tips are appreciated. > > Matej Hasul My tips, - - Track progress of the pgsql branch carefully to see what issues we're hitting and how they're being dealt with. - - Find help if you can. I honestly don't know if one person could do this. With pgsql we're looking at about 6-8 full time developers working for about 6 months. If we were to extrapolate that to mysql and one person, you could easily be looking at 3 or more years of full-time work. (granted some of the pgsql changes will help accommodate new databases, but MySQL will also bring some added effort in porting procedures as I understand it, but the task is HUGE in any case) - - Manage your forked source carefully. Obviously with a task this size it will need to have spacewalk's changes merged in frequently for the duration of the project. (suggest starting with the pgsql branch until it's merged back into master) - - Stay in constant communication with the development lists and find a way to publish your changes. This project will have some serious impact for our development team and QA, so constant communication will be vital to being able to integrate your work. Perhaps you could send patches regularly which could be reviewed and then applied in a git branch for the mysql effort? (giving others a place to track the work and contribute as well) Best of luck, and kudos for undertaking what's sure to be a very challenging task. :) Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmUISYACgkQAyHWaPV9my6s4wCg3e8G+UHXCIOeYep6Xfk0NqSr pl4AnidujNvbUyNoGbkMlILLgjxIjcfm =+lUi -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] MySQL support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 10 Feb 2009 16:48:16 +0100 Matej Hasul wrote: > Hello everyone, > I will try to port spacewalk DB to mysql as part of my master's > thesis. > > I installed spacewalk server and 2 clients and tried some basic > operations (installing/removing packages, configuration channel, etc). > > In following days I will browse DB schema and try to identify what > functionality is mysql missing and how to replace it. > > Any help, suggestions or tips are appreciated. > > Matej Hasul With a PostgreSQL effort underway, could you outline why you're driven to add the MySQL support? What advantages does it offers over PostgreSQL? Would you have interest in participating in the PostgreSQL porting effort first? Cheers, Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmUIwIACgkQAyHWaPV9my6fHgCgjr+qh0K0bxGUaAi9xAV6r9Zd 2hYAoM+WOK/1NHrfC1XWn8Q4tUF7SDLQ =kpP4 -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] MySQL support
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 12 Feb 2009 15:58:21 +0100
Miroslav Suchý wrote:
> Devan Goodwin wrote:
> > - - Find help if you can. I honestly don't know if one person could
> > do this. With pgsql we're looking at about 6-8 full time developers
> > working for about 6 months. If we were to extrapolate that to
> > mysql and one person, you could easily be looking at 3 or more
> > years of full-time work. (granted some of the pgsql changes will
> > help accommodate new databases, but MySQL will also bring some added
> > effort in porting procedures as I understand it, but the task is
> > HUGE in any case)
>
> It is no problem. His thesis can have negative conclusion ("Not
> possible with MySQL") or partial ("Not possible till MySQL implement
> this feature" or "It was huge for one man, I done this and that and
> others can continue and build upon my work"). And of course he can
> always surpris and done completely despite your presumption :)
>
I'm not really worried about what happens if the thesis fails, I'm
worried about what happens if it succeeds. My concern is that we don't
end up in a situation where someone spends 1.5+ years working on an
open source project, succeeds (in that the code works), submits that
work to the project and we're left scrambling to determine if the code
passes review, we can accept the added burden of maintaining and
testing a third schema, etc.
If all parties are agreed that this is purely a research project that
will likely never see the light of day, then that's fine, go to it. If
however the ultimate plan is to see this work included in Spacewalk
(which seems like the logical desire if one is to spend so much effort
working on an open source project), then there are things that should be
discussed right now to help mitigate the risk. (how do we communicate
and review work incrementally, do all parties know what will be
involved if it's successful and we accept these patches, anything
else we can do to help the task succeed)
Basically it boils down to: do we know whether or not we can accept
this work (if it is successful or partially successful) and if the
answer is no, is this communicated clearly up front. If those
questions are answered, or Matej is content to spend years working
on code that may never be used even if it's successful, then my
concerns are satisfied.
Devan
- --
Devan Goodwin
Software Engineer Spacewalk / RHN Satellite
Halifax, Canada 650.567.9039x79267
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkmUbx4ACgkQAyHWaPV9my5mJQCcClr4z2M6QNyeNrmd0jnFv70E
lgEAoNDWSEX7ivojNKs6eh4lK21wp4IP
=aeqY
-END PGP SIGNATURE-
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] first_names Fix: 233c64b8e502fe85ed1a77730559078d32adcdb8
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hey Jason, not sure if this is an issue but am I correct that you
changed the incoming key the API expects from first_names to first_name?
If so that might need a follow up, in general we try not to change the
API signatures so as not to break any pre-existing user/customer
scripts.
If we get in a situation where we really want to, we mark the old
way deprecated in the XMLRPC and then return both. (or in your case
accept both) Then after some period of time we can remove
deprecated things. (I can't remember what was agreed upon, maybe 2
Satellite releases? anybody recall?)
So if I'm reading this right you probably want to change the XML RPC
doc to:
#prop_desc("string", "first_names", "(deprecated)")
#prop("string", "first_name")
And then I guess try for first_name, if not found try first_names, and
if neither found error out. (hopefully it does this already)
Similarly for the getDetails call you'll probably want to mark
deprecated and return a key in the hash for both.
Cheers,
Devan
- --
Devan Goodwin
Software Engineer Spacewalk / RHN Satellite
Halifax, Canada 650.567.9039x79267
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkmV7wYACgkQAyHWaPV9my61swCfQjhaijjOBlk0qWG56A+Trw9P
DM0AoILpXPtzPp3m2DZyTTVSYG2wwOA4
=Z69T
-END PGP SIGNATURE-
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] broken links in rss feed?
Noticing this lately as well also from Google Reader. On Sun, Feb 15, 2009 at 10:25 AM, Jesus M. Rodriguez wrote: > Anyone else having busted links in the rss feed? The titles have a url > of : http://git.fedoraproject.org/git/?p=spacewalk.git%3Ba > I'm using google reader which might be my problem. Just curious if > others noticed it. > > jesus > > ___ > Spacewalk-devel mailing list > Spacewalk-devel@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-devel > -- Devan Goodwin http://dgoodwin.dangerouslyinc.com ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Spacewalk on Fedora 10 Notes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've done a little hacking on this system before so not sure if there's
any deps still missing that I'd previously installed manually, but
today it was only missing perl-Apache-Admin-Config, manually installing
it got spacewalk deps to resolve and install:
http://ftp.belnet.be/packages/dries.ulyssis.org/fedora/fc8/i386/RPMS.dries/perl-Apache-Admin-Config-0.94-1.fc8.rf.noarch.rpm
Note this is using the Fedora 10 nightly devel repo at:
http://miroslav.suchy.cz/spacewalk/nightly-candidate-f10/i386/os/
Dennis any luck establishing what the deal is with this package and how
we plan to tackle it?
Once packages are installed the real fun begins, during spacewalk-setup
I get a problem:
** Loading Spacewalk Certificate.
** Verifying certificate locally.
** Activating Spacewalk.
There was a problem activating the satellite: Local activation failure.
ERROR: RHN Entitlement Certificate failed to validate:
Exception reported from elaine.dangerouslyinc.com
Time: Sun Feb 15 13:24:11 2009
Exception type
Exception Handler Information
Traceback (most recent call last):
File "/usr/share/rhn/satellite_tools/rhn_satellite_activate.py", line
203, in activateSatellite_lo
cal
satCerts.storeRhnCert(cert, check_generation=1,
check_version=not(options.ignore_version_mismatc
h))
File "/usr/share/rhn/satellite_tools/satCerts.py", line 294, in
storeRhnCert
set_slots_from_cert(sc)
File "/usr/share/rhn/satellite_tools/satCerts.py", line 125, in
set_slots_from_cert
monSupportedYN = not not getInstalledHeader("NPalert")
File "/usr/share/rhn/common/rhn_rpm.py", line 159, in __getattr__
return getattr(self.hdr, name)
KeyError: 'unknown header tag'
Ran a couple prints for this getattr calls:
self.hdr =
name = __nonzero__
Still debugging why this is failing in Fedora but the code is checking
if NPAlert is installed and if so, assuming we want to enable
monitoring. In my case I don't so, granted this is getting very hacky
now, you can edit /usr/share/rhn/satellite_tools/satCerts.py and remove
the references to monSupportedYN. (one was actually completely unused,
took this out in git commit e474fbb995501481f9f28b6603d1c0a053527023)
Will investigate this further.
After this hack, spacewalk-setup completes, but it looks like services
don't come up and I see a NPE in tomcat5's catalina.out:
java.lang.NoClassDefFoundError:
org/apache/commons/collections/SequencedHashMap
That's as far as I've gotten so far.
Getting there...
Devan
- --
Devan Goodwin
Software Engineer Spacewalk / RHN Satellite
Halifax, Canada 650.567.9039x79267
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkmYVuwACgkQAyHWaPV9my7fcACfaofLETAsY+cNBD80TK26c9L0
Xp8AoMYaUZwFdpX72spChhZpKbhsSnC+
=gytT
-END PGP SIGNATURE-
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Spacewalk Cgit Web Interface
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Noticed in Fedora Weekly News there's some talk of replacing gitweb with cgit for the Fedora infrastructure git web interface. They've got it up and running at what's probably not a permanent URL but it looks very nice, overview of all branches too, not just master. http://hosted2.fedoraproject.org/cgit/spacewalk.git/ Cheers, Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmZowAACgkQAyHWaPV9my7K6wCeJ19h4+6tLlMQxPHP1Ut1Fdms OrEAoJZv3rST3tG/YZOwcgKB/GOVcDX4 =dz4U -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PGPORT: CONNECT BY queries
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Just an refresher, before proceeding with a solution for forked queries
inside Python, with what we know now is the below still a problem
requiring forking them?
Perl and Java are relatively well setup to support forked queries but
Python will require a from scratch solution, so if it's not necessary
(yet) we can avoid it for the time being.
If we go ahead I'm thinking something like a dead simple query store
object storing hashes to query names.
Queries now are defined right just as strings right in the Python code.
I'm thinking we introduce the simplest object possible, lets call it
QueryStore.
- - query = query_store.get_query("my_query_key")
- - query_store stores a hash of query keys to the queries they
represent, or a version like my_query_key_ORACLE and _POSTGRESQL if
we had to fork it.
- - Lookup version specific to the current backend and return it if found,
otherwise lookup the key directly and return it.
- - Error out if nothing is found.
- - Less work than re-implementing DataSource in a third language.
- - Could probably just leave most queries in place as they are today if
a fork is not required to minimize impact on the codebase.
Thoughts?
Devan
On Fri, 6 Feb 2009 21:19:03 +0530
Gurjeet Singh wrote:
> On Fri, Feb 6, 2009 at 7:50 PM, Devan Goodwin
> wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On Fri, 6 Feb 2009 19:37:28 +0530
> > Gurjeet Singh wrote:
> >
> >
> > > >
> > > Hmm.. Although that is doable, I haven't thought about that. The
> > > way I saw it was that we'd have a IF(ORACLE) CONNECT BY ELSE
> > > IF(POSTGRES) CALL FUNCTION END kinda code...
> > >
> > > Thinking a bit, I don't see a point in porting this to Oracle! The
> > > calling syntax will be different for both the databases anyway:
> > > Oracle:
> > > select x,y from TABLE( function() );
> > > Postres:
> > > select x, y from function() as f( x int, y int).
> > >
> > > So I guess we will _have_ to keep two versions of the query at
> > > least in the python code. The other usage in PL/SQL package is
> > > anyway going to be ported over.
> > >
> > > Best regards,
> >
> > Ok this is something we'll need to be very careful with. We kinda
> > knew this was coming (having to fork queries for each database) but
> > we'll need to plan ahead for this on our end. The python queries
> > are all just variables in the source so it's probably in our best
> > interest to setup a quick framework for using one set of queries by
> > default, and allowing them to be overridden depending on your
> > database backend. I will add this to my TODO list.
> >
> > However if anything occurs to you for a way we can keep the query
> > static for both databases that would be great!
>
>
> [?] We can create a view on both DBs with different definitions and
> get away with it.. ;)
>
>
- --
Devan Goodwin
Software Engineer Spacewalk / RHN Satellite
Halifax, Canada 650.567.9039x79267
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkma0KsACgkQAyHWaPV9my7cQACgttCPsysqgpSIcp2lF8L0K+8R
c+QAoKfXfaGCWEaLCmqznNACt18m0qvC
=hIKw
-END PGP SIGNATURE-
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] 481766: Added the example text as require dint he bug .. Forgot abt it...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 17 Feb 2009 10:15:48 -0500 Partha Aji wrote: > Nice > s/Added the example text as require dint he bug/ Added the example > text as required in the bug > > Damn typoisms. How do I change an old commit message in GIT ? > > Partha You don't. :) Once pushed it is basically permanent. Before pushing you have options. Cheers, Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkma1wUACgkQAyHWaPV9my4ikgCcCPchZ305Y3/5By/KuGebFzCB 4cUAoJS7pl6seDUzIfI86uq5r0xFagZa =vfZh -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Automating Oracle-xe Setup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Has anyone figured out a way to automate the steps in the install guide for: /etc/init.d/oracle-xe configure And the creation of the spacewalk user / permissions? Have a cobbler setup here to create guests for testing but it'd save me a lot of hassle if I could script these and have the box nearly ready to go with spacewalk after kickstart. Cheers, Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmcMoUACgkQAyHWaPV9my5ZBQCg7b7NYv0aWSSXjGR54Gu/qc7O NgMAn3kC4I2gQKBamRv8aRzucZjAUtPA =xtla -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] PGPORT: master to pgsql merge: schema changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just did a master to pgsql merge this morning and about to push the results. Here's a diff of what's changed in the schema since the last merge. (only on the rhnsat/ subdir, left the rest out as it includes upgrades and such which we're not interested in) Generated with this command run before I pushed the merge, here pgsql is my tracking branch that tracks the remote pgsql branch, and HEAD is my current branch where I actually did the merge. git diff pgsql..HEAD -- schema/spacewalk/rhnsat/ Cheers, Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmcNxIACgkQAyHWaPV9my6l+wCgxCMOkU+cRA9D3Rr+grk+ws7h W1UAn1kXX/5tdSYBPQSoh4fXFU442V9M =X+kw -END PGP SIGNATURE- diff --git a/schema/spacewalk/rhnsat/packages/rhn_org.pkb b/schema/spacewalk/rhnsat/packages/rhn_org.pkb index 6ae229e..88fdaf9 100644 --- a/schema/spacewalk/rhnsat/packages/rhn_org.pkb +++ b/schema/spacewalk/rhnsat/packages/rhn_org.pkb @@ -57,6 +57,11 @@ IS from rhnChannel where org_id = org_id_in; + cursor errata is +select id +from rhnErrata +where org_id = org_id_in; + begin if org_id_in = 1 then @@ -87,6 +92,11 @@ IS delete from rhnServerProfile where base_channel = cc.id; end loop; +-- Delete all errata packages +for e in errata loop +delete from rhnErrataPackage where errata_id = e.id; +end loop; + -- Give the org's entitlements back to the main org. rhn_entitlements.remove_org_entitlements(org_id_in); diff --git a/schema/spacewalk/rhnsat/procs/delete_errata.sql b/schema/spacewalk/rhnsat/procs/delete_errata.sql index 9817761..77b9fd0 100644 --- a/schema/spacewalk/rhnsat/procs/delete_errata.sql +++ b/schema/spacewalk/rhnsat/procs/delete_errata.sql @@ -21,7 +21,7 @@ delete_errata ( errata_id_in in number ) is begin - delete from rhnServerNeededPackageCache where errata_id = errata_id_in; + delete from rhnServerNeededCache where errata_id = errata_id_in; delete from rhnPaidErrataTempCache where errata_id = errata_id_in; delete from rhnErrataFile where errata_id = errata_id_in; delete from rhnErrataPackage where errata_id = errata_id_in; diff --git a/schema/spacewalk/rhnsat/procs/delete_server.sql b/schema/spacewalk/rhnsat/procs/delete_server.sql index 2f86807..d63f3e0 100644 --- a/schema/spacewalk/rhnsat/procs/delete_server.sql +++ b/schema/spacewalk/rhnsat/procs/delete_server.sql @@ -181,8 +181,7 @@ begin delete from rhnServerInstallInfo where server_id = server_id_in; delete from rhnServerLocation where server_id = server_id_in; delete from rhnServerLock where server_id = server_id_in; - delete from rhnServerNeededPackageCache where server_id = server_id_in; - delete from rhnServerNeededErrataCache where server_id = server_id_in; + delete from rhnServerNeededCache where server_id = server_id_in; delete from rhnServerNetwork where server_id = server_id_in; delete from rhnServerNotes where server_id = server_id_in; -- I'm not removing the foreign key from rhnServerPackage; that'll diff --git a/schema/spacewalk/rhnsat/procs/queue_server.sql b/schema/spacewalk/rhnsat/procs/queue_server.sql index 0462ede..7bf0703 100644 --- a/schema/spacewalk/rhnsat/procs/queue_server.sql +++ b/schema/spacewalk/rhnsat/procs/queue_server.sql @@ -27,18 +27,12 @@ IS BEGIN IF immediate_in > 0 THEN -DELETE FROM rhnServerNeededPackageCache WHERE server_id = server_id_in; -INSERT INTO rhnServerNeededPackageCache - (SELECT org_id, server_id, errata_id, package_id - FROM rhnServerNeededPackageView +DELETE FROM rhnServerNeededCache WHERE server_id = server_id_in; +INSERT INTO rhnServerNeededCache + (SELECT server_id, errata_id, package_id + FROM rhnServerNeededView WHERE server_id = server_id_in); - DELETE FROM rhnServerNeededErrataCache snec WHERE server_id = server_id_in; - insert into rhnServerNeededErrataCache - (select distinct org_id, server_id, errata_id - from rhnServerNeededPackageCache - where server_id = server_id_in - and errata_id is not null); ELSE SELECT org_id INTO org_id_tmp FROM rhnServer WHERE id = server_id_in; diff --git a/schema/spacewalk/rhnsat/tables/Makefile.deps b/schema/spacewalk/rhnsat/tables/Makefile.deps index 688f1e6..a740286 100644 --- a/schema/spacewalk/rhnsat/tables/Makefile.deps +++ b/schema/spacewalk/rhnsat/tables/Makefile.deps @@ -191,6 +191,7 @@ rhnRegTokenConfigChannels:: rhnRegToken rhnConfigChannel rhnRegTokenEntitlement :: rhnRegToken rhnServerGroupType rhnRegTokenGroups :: rhnRegToken rhnServerGroup rhnRegTokenPackages :: rhnRegToken rhnPackageName +rhnRepoRegenQueue :: rhnSatelliteCert rhnSatell
Re: [Spacewalk-devel] Automating Oracle-xe Setup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Consider my day made. :) Thanks Michael. Devan On Wed, 18 Feb 2009 17:13:13 +0100 Michael Mraka wrote: > Devan Goodwin wrote: > % -BEGIN PGP SIGNED MESSAGE- > % Hash: SHA1 > % > % Has anyone figured out a way to automate the steps in the install > guide % for: > % > % /etc/init.d/oracle-xe configure > > /etc/init.d/oracle-xe configure < 9000 > 1521 > spacewalk > spacewalk > y > ORA > > % And the creation of the spacewalk user / permissions? > > su - oracle -c 'sqlplus / as sysdba' < create user spacewalk identified by spacewalk default tablespace > users; grant dba to spacewalk; > alter system set processes = 400 scope=spfile; > alter system set "_optimizer_filter_pred_pullup"=false scope=spfile; > alter system set "_optimizer_cost_based_transformation"=off > scope=spfile; EOS > > % Have a cobbler setup here to create guests for testing but it'd > save me % a lot of hassle if I could script these and have the box > nearly ready % to go with spacewalk after kickstart. > % > % Cheers, > % > % Devan > > -- > Michael Mráka > Satellite Engineering, Red Hat > > _______ > Spacewalk-devel mailing list > Spacewalk-devel@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-devel - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmcOMAACgkQAyHWaPV9my4fowCfco8xZ34UX+EkJ249aMsh9jMg 0PwAn2jmGyydZwmfFVVMkczSoCBMNTtG =Geab -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Important Git Guide Updates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Made some updates this morning to the Git Guide in a number of areas, most importantly I've changed the example workflow to (a) avoid the "goto master, pull, goto branch, rebase, goto master, merge, push" dance and (b) discuss just working in master for those who do not like or understand the use of local branches, while still avoiding those cursed "merge" commits that pollute our history. All of this is made possible by git pull --rebase which I wasn't even aware of when I wrote the first draft of the guidelines. I've been using it myself lately and find it much simpler. Sections also added for understanding branches, resolving conflicts, and the difference between merge and rebase. PLEASE read these carefully if you are having problems with git, and I cannot recommend these resources enough: http://book.git-scm.com/ http://www.kernel.org/pub/software/scm/git/docs/user-manual.html The first is the happy magical sugar git introduction, the second is much more in depth and suitable for drilling into specific topics. Hoping to get a git lunch and learn or something like that set up for next Wednesday. Cheers, Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmdfLUACgkQAyHWaPV9my5zJQCggXuum2drh7C62mmSHcLZBH6p 8q4Ani+bx26ADzdBGBjafNevk/MbXIHh =ddta -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] PGPORT: empty_blob() Commit For Review
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ran into an issue in satCerts.py with the use of empty_blob(), being used to insert into a table with a blob column which has a not null constraint. In PostgreSQL this column becomes a "bytea". First tried changing it to just '' but this breaks for Oracle as it evaluates to NULL. Thought briefly about changing it to nonsense like "nothingyet" but then decided to try a postgresql compatibility function. http://git.fedorahosted.org/git/?p=spacewalk.git;a=blob;f=schema/spacewalk/postgresql/procs/empty_blob.sql;h=4af10bf12c8d483bdc0606395c8e346ef2423d88;hb=ad648496420396db183fa6433628ab17f8d9fd0b Look ok? Thanks, Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmdts0ACgkQAyHWaPV9my4LtwCgzh5bvmMkZJg/VthSJ9uPm/X0 CtUAn2iAj+zPZWkilVB4lgZN8/pgopkw =ig80 -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Re: build.py + dist-cvs update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 thirdparty.git available at: git clone git+ssh://yourlo...@git.rhndev.redhat.com/scm/git/thirdparty.git oracle-instantclient is the only package there now. I brought the spec over from svn, removed the reverences to "sources" and "version" files, and fixed any issues with build.py. I see that we don't bother tracking sources for this project in source control (and rightly so given their size), is this something we should apply to all our third party libraries? Or do we wish to continue doing so if the .tar.gz is small enough? (how small?) It's probably still a little rough around the edges but if anyone wants to test feel free to clone and try: build.py --tag-release build.py --cvs-release Should look something like: Checking for tag [oracle-instantclient-10.2.0-36] in git repo [git+ssh://dgood...@git.rhndev.redhat.com/scm/git/thirdparty.git] Building release from CVS... Checking out cvs module [oracle-instantclient] Creating oracle-instantclient-10.2.0.tar.gz from git tag: fbd8da9d1c28045ea5e9f3a542c8acfa1baeaa55... Preparing to commit [/tmp/spacewalk-build/cvswork/oracle-instantclient] Switch terminals and run cvs diff in this directory to examine the changes. Do you wish to proceed with commit? [y/n] y Proceeding with commit. Creating CVS tags... (cd ../common && cvs update) cvs update: Updating . cvs update: Updating devel cvs tag -c oracle-instantclient-10_2_0-36_el4sat cvs tag: Tagging . T .cvsignore T Makefile T branch T oracle-instantclient.spec T sources T version Tagged with: oracle-instantclient-10_2_0-36_el4sat (cd ../common && cvs update) cvs update: Updating . cvs update: Updating devel cvs tag -c oracle-instantclient-10_2_0-36_el5sat cvs tag: Tagging . T .cvsignore T Makefile T branch T oracle-instantclient.spec T sources T version Tagged with: oracle-instantclient-10_2_0-36_el5sat Submitting CVS builds... (cd ../common && cvs update) cvs update: Updating . cvs update: Updating devel Created task: 1700283 Task info: http://brewweb.devel.redhat.com/brew/taskinfo?taskID=1700283 (cd ../common && cvs update) cvs update: Updating . cvs update: Updating devel Created task: 1700285 Task info: http://brewweb.devel.redhat.com/brew/taskinfo?taskID=1700285 If run on something that's already been tagged, it will have nothing to commit for the spec file and die trying to run make tag. (this behavior seems ok to me) Next stage will be moving the existing projects left in svn, as well as those under spec-tree/ in git into thirdparty. This will have implications in that the build-missing* scripts will not catch them anymore, but this seems to be only a marginal concern considering the projects will be built from binary packed source. (and rarely at that) Hopefully we can keep thirdparty as just a master branch, but if necessary we can create branches to track spacewalk and satellite releases. Cheers, Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmeLFUACgkQAyHWaPV9my6NaQCcCsB42Pnq/VZtt3O7j08eohfK zjwAnRAHR7TjMIi6FNZ96ezMkhRgdT1W =/cKX -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] F10 Spacewalk Progress
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 First bug that breaks the activation during spacewalk-setup has been fixed, was a change in Python relating to trying to use objects as booleans with __nonzero__. Easy to workaround in a more reliable way. After this restarting services hangs. If you kill it and rhn-satellite restart you can see a couple failures more clearly. Issue with errors in tomcat5 boiling down to missing the apache commons SequencedHashMap collection. In el5 /var/lib/tomcat/common/lib will have a symlink to the installed collections jar in /usr/share/java. On F10 this symlink doesn't exist. Workaround is easy, just copy or symlink the jar into the common lib directory. I'm not sure how to address this properly in the long run, probably drop a symlink into /var/lib/tomcat5/webapps/rhn/WEB-INF/lib/ like we do for many other libraries. Next up is httpd refusing to start due to: Syntax error on line 209 of /etc/httpd/conf/httpd.conf: Syntax error on line 36 of /etc/httpd/conf.d/zz-spacewalk-www.conf: Cannot load /etc/httpd/modules/mod_jk.so into server: /etc/httpd/modules/mod_jk.so: cannot open shared object file: No such file or directory It looks to me like this shouldn't even be triggering: = 2.1> LoadModule proxy_ajp_module modules/mod_proxy_ajp.so LoadModule jk_module modules/mod_jk.so httpd-2.2.10-2.i386 is installed. Turns out in EL5 httpd.conf has: LoadModule version_module modules/mod_version.so In F10 this module is not loaded, adding the LoadModule allows httpd to start up fine. So there's two packaging issues to address, will file bugs. After this I tried to hit the webapp and got: java.lang.ClassNotFoundException: javax.transaction.Synchronization, probably just another missing symlink. Will pick up here next go around. Cheers, Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmgP2YACgkQAyHWaPV9my4e5wCg3Pd1gIcF3ErhFnWRAM7tJ31S EuAAn0CLekjnd932DkN800x40qExAXWz =EAw3 -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] F10 Spacewalk Progress
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Staring at Spacewalk UI running on F10 right now! Blocked out of the box by two very minor bugs, both with workarounds noted in https://bugzilla.redhat.com/show_bug.cgi?id=486749 - - Two missing jar symlinks in Tomcat lib directories. https://bugzilla.redhat.com/show_bug.cgi?id=486749 - - mod_version needs to be loaded in httpd.conf. Note that this implies you install from the Spacewalk 0.5 devel repo for F10, available at: http://miroslav.suchy.cz/spacewalk/nightly-candidate-f10/i386/os/ After this the webapp should run. Tested a custom channel creation, system registration, hell even the perl pages are displaying fine. Looks like rhnpush will need some love however, it bonks out after three tries uploading the first package. No obvious errors in any file in /var/log/rhn/ so this'll need a little more attention. Cheers, Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmiGT0ACgkQAyHWaPV9my4umQCg4ZGEKWDIU2vE2e+uB3oYRb27 BLIAoIBJIFMlJhz6fencFPG1Ef/0F6NN =n9oZ -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PGPORT (regarding queries)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 24 Feb 2009 19:35:44 +0530 Vikram Rai wrote: > Hi, > > We have started looking at the queries that need to be tagged. > In the initial stages of going through these queries we found a > couple of things and some ways we can tag them. > > Keeping in mind the diversity and complexity of the some of the > queries we have divided them into four categories: > >1. Queries that need to have minor changes to make them work in > postgres. > > For eg: It could be like adding an "as" clause for alias names > etc. We had a suggestion to tag them with the following comment where > ever the changes are necessary: > > pgsql_c:xxx --> which is postgresql_comment:line number. > > 2. Queries that need to be rewritten. We had gone through a > couple of them as we went along the list and found some queries > that had to be rewritten to give an exact result. For eg: queries > on system catalogs in oracle do not work in postgres. > > we would be tagging such queries with the following comment: > > pgsql_q:xxx --> which is postgresql_query:line number. > > 3. Incase there are any db changes to accommodate a query using > Orafce, such queries would be tagged as: > > pgsql_orafce:xxx --> which is postgresql_database_change:line > number. > > 4. No changes required to the existing query. Works both on > postgres and oracle. > > pgsql_ora:xxx --> which is works on both postgres and oracle:line > number. > > These are just some initial thoughts and I am sure we will have > some additions to it down the road as we unfold some more of them. > Do let me know what you think. > > Regards, > > Vikram Rai > EnterpriseDB Looks pretty good, though could we sustitute pgsql_ with PGPORT_. I see almost no hits for pgsql_ but there may be some popping up in the future, PGPORT_ might be a little less grep hits down the road. Cheers, Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmkBMsACgkQAyHWaPV9my5UQwCggzIHFY9vFyfyVrQcFDKYWH9k z8EAoJKh7O3yN+KTEtzXpchB3ZIlJY8O =mE9m -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] spacewalk and CentOS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 24 Feb 2009 16:17:36 + Karanbir Singh wrote: > hi Guys, > > Over the next few days were going to have CentOS-5.3 ready for > release and I was just wondering if there is anything that might be > desirable to get into the distro from the Spacewalk side of things. > iirc, there was interest in bringing back the *rhn* support packages > which we dropped from 5.X ( since they really have no use in CentOS > and we dont want to have $people hitting rhn services ). > > Is there anything else beyond that, I might be able to do this end to > make life for Spacewalk/CentOS users easier at this stage ? > > -- > Karanbir Singh > http://www.karan.org/ > z00dax#centos-de...@irc.freenode.net Hi Karanbir, I think there are definitely some packages we would love to get into CentOS 5.3. In a perfect world all of these would be nice to see: http://stahnma.fedorapeople.org/spacewalk-tools/5Server/i386/ But of those there are a few that are more helpful than others, rhnlib, rhn-check, and rhn-setup. (anybody know of others?) I think rhnlib is the one that would need patching to prevent it from doing any querying of RHN hosted. Also big thanks for checking in with us on this, very proactive. :) Cheers, Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmkVvIACgkQAyHWaPV9my4eBgCfUQBmuBigwg2TaeGhseNvxNhg gngAnAq6hRSIGczHjA1V7WAgT4yvmPjQ =ObHJ -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] F10 Spacewalk Progress
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 25 Feb 2009 11:26:28 +0100 Jan Pazdziora wrote: > > I'd like to stare at Spacewalk UI as well. Instead, I stare at > > # yum install spacewalk > [...] > Error: Missing Dependency: quartz is needed by package > spacewalk-search-0.5.8-1.fc10.noarch (spacewalk) Error: Missing > Dependency: cglib is needed by package > spacewalk-taskomatic-0.5.22-1.fc10.noarch (spacewalk) Error: Missing > Dependency: quartz is needed by package > spacewalk-taskomatic-0.5.22-1.fc10.noarch (spacewalk) Error: Missing > Dependency: hibernate3 >= 3.2.4 is needed by package > spacewalk-taskomatic-0.5.22-1.fc10.noarch (spacewalk) Error: Missing > Dependency: hibernate3 >= 3.2.4 is needed by package > spacewalk-java-0.5.22-1.fc10.noarch (spacewalk) > > So I'm doing something wrong because I'm not even able to *install* > the thing. I'm using > > # cat /etc/yum.repos.d/spacewalk.repo > [spacewalk] > name=Spacewalk > > baseurl=http://miroslav.suchy.cz/spacewalk/nightly-candidate-f10/i386/os/ > gpgkey=http://spacewalk.redhat.com/yum/RPM-GPG-KEY-spacewalk > enabled=1 > gpgcheck=0 > > How did you install Spacewalk on F10? > I forgot to mention: [r...@fedorasw ~]# cat /etc/yum.repos.d/jpackage.repo [jpackage] name=jpackage-f10 baseurl=http://mirrors.dotsrc.org/jpackage/6.0/fedora-10/free/ gpgcheck=0 [r...@fedorasw ~]# Cheers, Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmlRu0ACgkQAyHWaPV9my41OACfSKL0UBuDaZu37DNQxng2OhIa UkMAoKd6eu3KNGKPj6VfhFH1azVBnL2+ =ZT72 -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] PGPORT: git merge problems, rhnsat schema diff
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Muhammad: I think you may have accidentally done a master to pgsql
merge for me. :)
http://hosted2.fedoraproject.org/cgit/spacewalk.git/commit/?h=pgsql&id=20a473edd51cf26e19220b8a048b2e250606b047
It appears the merge was clean, no conflicts, thus why it was probably
somewhat easy to not realize this was happening.
I think I've pieced together a way to check the diff of what's changed
in the existing Oracle rhnsat schema, attaching the diff, much smaller
this time around.
Gurjeet: I think you mentioned the last diff was addressed in the
PostgreSQL schema (sent on Feb 18) but just wanted to confirm.
Remember that 'git merge SOMETHING' means you're merging 'SOMETHING'
into whatever branch you're currently working on. In this case it was
probably 'git merge master' when it was intended to be 'git merge my
workbranch'. Fortunately we intend to merge in master frequently so no
harm no foul. :)
Muhammad could you check and make sure the work you were
trying to merge in actually made it?
Thanks,
Devan
- --
Devan Goodwin
Software Engineer Spacewalk / RHN Satellite
Halifax, Canada 650.567.9039x79267
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkmr7fEACgkQAyHWaPV9my4OuQCg3m3rdpsuSG6zUU8Ke5KW8eD6
RTAAn0EtlYJ084xZx1NmrgvFJiz6x8Qk
=tPg1
-END PGP SIGNATURE-
diff --git a/schema/spacewalk/rhnsat/class/evr_t.sql b/schema/spacewalk/rhnsat/class/evr_t.sql
index 0d03097..a9debe5 100644
--- a/schema/spacewalk/rhnsat/class/evr_t.sql
+++ b/schema/spacewalk/rhnsat/class/evr_t.sql
@@ -61,3 +61,26 @@ end;
/
show errors
+create or replace function evr_t_as_vre( a evr_t )
+ return varchar2
+is
+begin
+return a.version || '-' || a.release || ':' || a.epoch;
+end;
+
+create or replace function evr_t_as_vre_simple( a evr_t )
+ return VARCHAR2
+is
+vre_out VARCHAR2(256);
+begin
+vre_out := a.version || '-' || a.release;
+
+if a.epoch is not null
+then
+vre_out := vre_out || ':' || a.epoch;
+end if;
+
+return vre_out;
+end;
+
+
diff --git a/schema/spacewalk/rhnsat/procs/lookup_client_capability.sql b/schema/spacewalk/rhnsat/procs/lookup_client_capability.sql
index 366b4db..0d2ed85 100644
--- a/schema/spacewalk/rhnsat/procs/lookup_client_capability.sql
+++ b/schema/spacewalk/rhnsat/procs/lookup_client_capability.sql
@@ -15,33 +15,20 @@
--
--
--
-
CREATE OR REPLACE FUNCTION
-LOOKUP_CLIENT_CAPABILITY(name_in IN VARCHAR2)
-RETURN NUMBER
-IS
- PRAGMA AUTONOMOUS_TRANSACTION;
- cap_name_id NUMBER;
+LOOKUP_CLIENT_CAPABILITY(name_in IN VARCHAR)
+RETURNS NUMERIC
+AS $$
+DECLARE
+ret_val NUMERIC;
BEGIN
- SELECT id
- INTO cap_name_id
- FROM rhnClientCapabilityName
- WHERE name = name_in;
+SELECT retcode into ret_val from dblink('dbname='||current_database(),
+'select lookup_client_capabality_autonomous('
+||coalesce(name_in::varchar,'null')||')')
+as f(retcode int);
- RETURN cap_name_id;
-EXCEPTION
-WHEN NO_DATA_FOUND THEN
-INSERT INTO rhnClientCapabilityName (id, name)
-VALUES (rhn_client_capname_id_seq.nextval, name_in)
-RETURNING id INTO cap_name_id;
-COMMIT;
- RETURN cap_name_id;
-END;
-/
-SHOW ERRORS
---
--- Revision 1.1 2003/07/21 22:30:04 misa
--- bugzilla: none Lookup function for capabilities
---
---
+RETURN ret_val;
+END; $$
+LANGUAGE plpgsql;
+
diff --git a/schema/spacewalk/rhnsat/tables/rhnRepoRegenQueue.sql b/schema/spacewalk/rhnsat/tables/rhnRepoRegenQueue.sql
index 51fde2a..8b9f13d 100644
--- a/schema/spacewalk/rhnsat/tables/rhnRepoRegenQueue.sql
+++ b/schema/spacewalk/rhnsat/tables/rhnRepoRegenQueue.sql
@@ -44,3 +44,6 @@ for each row
begin
:new.modified := sysdate;
end;
+/
+show errors
+
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] PGPORT: PostgreSQL 8.3 Problem?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Suspect we might have something in our schema that doesn't work on 8.3, doing some testing on fedora and hit this: psql:tables/rhn_contact_groups.sql:45: ERROR: operator does not exist: character = integer HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. This is with: postgresql-server-8.3.6-1.fc10.i386 Whereas the sql loads fine on postgresql-server-8.1.11-1.el5_1.1. Probably not a huge deal but it'll probably surface at some point. :) I can't even tell what it's complaining about... anybody know? Devan - -- Devan Goodwin Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmtlAEACgkQAyHWaPV9my42QACfVpn8zev+SOS8rSBNG2l2g3IS w4YAn0j5XcHyVplqzKdxHFb5WQ1vmmNo =JEaQ -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
