[Spacewalk-devel] When changing schema, keep PostgreSQL in sync
Hello, when you change the Oracle-specific SQL schema sources (schema/spacewalk/oracle), please make sure from now on to also commit the equivalent change to the PostgreSQL side (schema/spacewalk/postgres). After you do so, please mark the Oracle version on which the PostgreSQL is based by putting the SHA1 of the Oracle source file to the first line of the PostgreSQL source. If you don't do this, the spacewalk-schema rpm will not build, so please keep in mind to do it from now on. Of course, you also need to add Oracle schem upgrade script -- that stays the same. For example, the file schema/spacewalk/postgres/procs/lookup_package_arch.sql now starts with -- oracle equivalent source sha1 ff037ec343dd654b470e32c119fbf596c669364e When you change schema/spacewalk/oracle/procs/lookup_package_arch.sql and commit the change to the PostgreSQL file, put the new SHA1 (use the sha1sum command) to the PostgreSQL source instead of that ff037... string. Well, the file schema/spacewalk/postgres/procs/lookup_package_arch.sql actually starts with -- oracle equivalent source sha1 ff037ec343dd654b470e32c119fbf596c669364e -- retrieved from ./1235730481/28a92ec2f6056ccc56e0bc4b0da3630def22548f/schema/spacewalk/rhnsat/procs/lookup_package_arch.sql because I've just spent some time to find the old matching Oracle versions and I've retrofitted the SHA1 to our PostgreSQL code, so please remove the second line at the same time because it will no longer be true. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] PostgreSQL schema update needed
Hello, when you do git grep '^-- -- oracle equivalent source' you will find seven PostgreSQL schema source files where the Oracle sources have changed since their PostgreSQL equivalent was committed to our git repo. The quest for brave SQL hackers is to find what changes happened to the Oracle sources since the PostgreSQL ones were committed, and apply the same (semantically equivalent) changes to the PostgreSQL sources. Then change the double comment (-- --) to a single comment (--), put in correct SHA1 of the Oracle source, and remove the second line line from the file. You can run cd schema/spacewalk perl schema-source-sanity-check.pl to check that you did not break anything. Thank you ... and go start coding. ;-) -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Development environment build
On Fri, Sep 24, 2010 at 03:25:38PM -0600, Shelby, James wrote: I did see some tito references but nothing that shows exactly how to build them or at least the document doesn't match the current sources. I've made some updates to https://fedorahosted.org/spacewalk/wiki/ReleaseProcess now. For local test builds, you chdir to the directory where the package you're interested in lives (java/ for spacewalk-java, for example), and you do tito build --srpm --test which will give you .src.rpm of that package based on your current HEAD. You can then build the rpm on your Spacewalk installation. You can also do tito build --rpm --test which will do it in one step (.src.rpm + the target .rpm) on your local machine. This is of course only useful if you run Spacewalk directly on the machine where you have the Spacewalk repo checked out or if they are the same OS and arch. Please don't hesitate to ask if you hit some issue. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] On changelogs
Noticed this on Fedora devel: - Forwarded message from Tom spot Callaway tcall...@redhat.com - Date: Fri, 24 Sep 2010 14:55:34 -0400 Subject: Re: F-14 Branched report: 20100923 changes On 09/24/2010 01:32 PM, Toshio Kuratomi wrote: The rpm changelog should be more like NEWS than a changelog; and usually a summary of NEWS, at that. (imho, no packaging guidelines currently mandate this, etc.) I could swear I had written don't copy the upstream changelog into the rpm changelog, summarize in a line or two if you must., but apparently, I never did. :/ ~spot - End forwarded message - I wonder if we should change the way changelog is currently generated for our packages ... -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Development environment build
On Wed, Sep 22, 2010 at 12:43:26PM -0600, Shelby, James wrote: I'm having a problem building the test rpms from the base git and receive the following error. Can someone point me in the right direction? I have done a complete remove of the rpmbuild directory and keep getting an error on the x-setup-specfile. [u...@spacewalk-development spacewalk]# make test-rpm Nowadays, you probably want to use tito instead to build the rpms. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] possible breakage of spacewalk-backend
On Fri, Aug 13, 2010 at 07:51:37PM +0200, Miroslav Suchý wrote:
My approach is not optimal as we populate it with those generic
names. But one step in time.
It's not one step in time. There won't be other steps to fix it
properly in the future. And if there will be, it will just be
twice as much change, twice as much potential breakage and
twice as much work.
We can even conflict with some others packages on really generic names like:
common/apache.py
Which is good. Becouse you will get at least error during
installation.
No you won't, unless you will be testing Spacewalk with the full
OS (including EPEL) installations. And it will not prevent conflicts
in the future because people adding packages to EPEL will know
nothing about these filenames used by Spacewalk packages.
instead and change all the relevant imports to have the rhn.
prefix? Alternatively we could have /usr/share/rhn to be a symlink
to %{python_sitelib}/rhn or something similar.
That's ugly. Since we have there other data which should not be
stored in %{python_sitelib}
E.g. RHN-GPG-KEY, RHNS-CA-CERT
You can always do the symlinks for the subdirectories, can't you?
--
Jan Pazdziora
Principal Software Engineer, Satellite Engineering, Red Hat
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] possible breakage of spacewalk-backend
On Fri, Aug 13, 2010 at 07:21:36PM +0200, Miroslav Suchý wrote:
Well with this mine commit, I admit something can break. I tested it
on my own Spacewalk and it works, but I'm not sure what it make to
developer setup...
So if something breaks, you know why :)
I hope nobody is against this change. But if somebody do not like
it, I'm ready to open discussion.
I don't like the fact that we will pollute /usr/lib/python2.6 with
multiple directories with very generic names -- common, actions,
classes, etc. Shouldn't we make it
distutils.sysconfig import get_python_lib; print get_python_lib())}
%endif
+%global rhnroot %{python_sitelib}
%global rhnroot %{python_sitelib}/rhn
instead and change all the relevant imports to have the rhn.
prefix? Alternatively we could have /usr/share/rhn to be a symlink
to %{python_sitelib}/rhn or something similar.
--
Jan Pazdziora
Principal Software Engineer, Satellite Engineering, Red Hat
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PostgreSQL status
On Thu, Jul 22, 2010 at 10:05:30AM +0200, Maxim Burgerhout wrote: Most Python applications that interface with PostgreSQL (Django for one, and I think Turbogears too) use python-psycopg2 these days. Python-psycopg2 at least has had some commits in its python2 branch in the last couple of months. The version available in F-13 is 2.0.14, which is a tiny bit old, but basically seems to be the standard way to interface with PostgreSQL in Python at the moment. Its use by both Django and Turbogears guarantees at least some amount of activity upstream. But I don't know how much work migrating from python-pgsql to python-psycopg2 would be... [...] On Tue, Jul 27, 2010 at 11:50:35AM -0400, Tom Lane wrote: The PG Python client with the brightest future seems to be psycopg2 http://initd.org/psycopg/ but I'm not much of a Python guy and can't gauge how much trouble it'd be to convert to that. Maxim, Tom, thank you for the suggestion. I have changed the Requires in .spec to require python-psycopg2 and I've changed the placeholder handling in driver_postgresql.py. The thing now installs and activates the certificate just like it did with python-pgsql, but please point out any regressions that this change might have brought. This also means that Spacewalk on PostgreSQL now installs on Fedora 13 as well, for you guys who accept no old releases. You want the nightly repo, which now has 1.2 in the path -- please follow https://fedorahosted.org/spacewalk/wiki/PostgreSQL -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Changes for Spacewalk 1.2
On Tue, Aug 10, 2010 at 04:28:01PM +0200, Milan Zazrivec wrote: With respect to upcoming release of Spacewalk 1.1, following changes (affecting Spacewalk 1.2) have been made: * Bumped up versions of packages in current spacewalk.git master [1] * New koji tags: dist-5E-sw-1.2-candidate dist-f12-sw-1.2-candidate dist-f13-sw-1.2-candidate * Nightly repos [2] are going to be mashed out of the tags above * rel-eng/build-missing-builds-in-koji.sh and rel-eng/tito.props have been changed appropriately * 1.2 version has been added to the Spacewalk product in bugzilla [3] We have a problem. If you run ./rel-eng/koji-missing-builds.py dist-5E-sw-1.2-candidate you will see a *lot* of missing builds. If you run it for f12, there's not so many of them, but there are some, like spacewalk-web-1.1.8-1.fc12. So build-missing-builds-in-koji.sh will schedule a lot of tasks which will fail eventually, because the builds are in fact there. The problem is that we only have 27 builds explicitly tagged to dist-5E-sw-1.1. And dist-5E-sw-1.2-candidate inherits from dist-5E-sw-1.2 and that inherits from dist-5E-sw-1.1. The spacewalk-web-1.1.8-1.fc12 is not tagged either. Could you please finish the tagging of 1.1 packages? -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Postgres dev environment
On Tue, Aug 03, 2010 at 07:55:05PM +0800, Colin Coe wrote: Hi all Just setting this up ATM. When I run 'spacewalk-setup --disconnected' I got heaps of errors in /var/log/rhn/populate_db.log, reportedly from /etc/sysconfig/rhn/postgres/main.sql. To get spacewalk-setup to complete, I made the following changes: --- 902 CREATE TABLE rhnConfigInfo 903 ( 904 --id NUMBER NOT NULL 905 id NUMERIC NOT NULL 906 CONSTRAINT rhn_confinfo_id_pk PRIMARY KEY, 907 -- USING INDEX TABLESPACE [[2m_tbs]], 908 --username VARCHAR2(32) NULL, 909 --groupnameVARCHAR2(32) NULL, 910 username VARCHAR(32) NOT NULL, 911 groupnameVARCHAR(32) NOT NULL, 912 --filemode NUMBER NULL, 913 filemode NUMERIC NOT NULL, 914 --symlink_target_filename_id NUMBER 915 symlink_target_filename_id NUMERIC 916 CONSTRAINT rhn_confinfo_symlink_fk 917 REFERENCES rhnConfigFileName (id), 918 created DATE 919 -- DEFAULT (sysdate) NOT NULL, 920 DEFAULT (current_timestamp) NOT NULL, 921 modified DATE 922 -- DEFAULT (sysdate) NOT NULL, 923 DEFAULT (current_timestamp) NOT NULL, 924 --selinux_ctx VARCHAR2(64) 925 selinux_ctx VARCHAR(64) 926 ) 927 -- ENABLE ROW MOVEMENT 928 ; 929 930 CREATE UNIQUE INDEX rhn_confinfo_ugf_uq 931 ON rhnConfigInfo (username, groupname, filemode, selinux_ctx, symlink_target_filename_id) 932 --TABLESPACE [[4m_tbs]]; 933 ; 934 935 CREATE SEQUENCE rhn_confinfo_id_seq; --- Could someone comment on the correctness of these? The problem is caused by the NULL clauses that chameleon does not understand and thus the source file is just copied over. Can you please try the rpm from https://koji.spacewalkproject.org/koji/taskinfo?taskID=43419 and confirm that it fixes the issue for you? -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Postgres dev environment
On Tue, Aug 03, 2010 at 09:19:53PM +0800, Colin Coe wrote: I've gone back to RHEL as I kept having problems under Fedora (the simple-core and friends) so I downloaded the src.rpm and rebuild against RHEL5. It built cleanly and I've upgraded the RPM. Looks like it worked OK as it came back OK and the services all started. Fine. I've pushed the change, tagged and scheduled spacewalk-schema-1.1.26-1 build. Thanks, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] remove rpms from koji
On Wed, Jul 28, 2010 at 10:36:07AM -0400, Shannon Hughes wrote: Jan, we need to remove both javaassist and maven2-common-poms from our spacewalk koji tags for 1.1 release. I wrote a spec for slf4j I've now untagged javassist and maven2-common-poms. We might or might not want to remove the package from tag listings -- the reverse of add-pkg which I don't see in koji help (we do not want block-pkg, we want the pkg to be completely gone). -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] What do I do with all those potential bugzillas ?
On Wed, Jul 21, 2010 at 11:17:57PM +0200, Jerome Fenal wrote: still ongoing on my Perl OO API for Spacewalk/Satellite, I have collected quite a few glitches during development (unit test helps here). As the number is growing, I'm getting a bit concerned of not taking care of those... :) You can find those here : http://github.com/jfenal/RHNC/blob/master/Bugzillas.txt Do you want me to open a bugzilla for each of those, or may I Yes, one bugzilla per issue, please. It is easier for people to pick one small thing and create and submit patch than to work with mega-bugzilla that lists multiple issues. Thank you, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Suggestions for sysdate, for PostgreSQL?
On Wed, Jul 21, 2010 at 06:21:04PM -0400, Tom Lane wrote: Jan Pazdziora jpazdzi...@redhat.com writes: what are our possibilities for handling sysdate in PostgreSQL. Isn't s/sysdate/current_timestamp/g a good solution? That's standards compliant, unlike sysdate. I wouldn't dare to do that en masse. It's a different type -- timestamp instead of date, so it has different precision, and I'm not sure if the arithmetic is exactly the same. But you are right, we could just change that one-by-one, verifying any side effect of the change, as we keep hitting the sysdate errors. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PostgreSQL status
On Fri, Jul 09, 2010 at 07:37:48PM -0400, Tom Lane wrote: That page mentions that you can't install on RHEL5 because RHEL5's version of postgresql is too old (8.1). While that's true, as of now we are shipping postgresql84 for RHEL5, which provides 8.4.x. So if anyone cares about testing on RHEL5, it should be sufficient to change the dependencies to reference postgresql84 instead of Thanks for the pointer. I've now changed the documentation to yum install -y 'postgresql-server 8.4' which seems to do the right thing both on Fedora 12 and RHEL 5. So the setup is usable on RHEL 5 / CentOS 5 as well. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PostgreSQL status
On Tue, Jul 20, 2010 at 06:25:06PM -0400, Justin Sherrill wrote: I've finished those changes and have built packages. If you could give them a try, that'd be awesome :} The newest spacewalk-java within koji are the ones you want. I believe they now pass all the unit tests on oracle, so oracle should be good. Thanks. This seems to be solving the issue on PostgreSQL as well. I'm not saying it selects the blobs correctly, we are not there yet, but I no longer get the errors I used to be getting upon tomcat startup. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PostgreSQL status
On Fri, Jul 09, 2010 at 04:40:12PM +0200, Jan Pazdziora wrote: Hello, in the past couple of weeks, I've been looking at the status of PostgreSQL database backend for Spacewalk, trying to get it install and at least start. I've summarized my findings at https://fedorahosted.org/spacewalk/wiki/PostgreSQL and I've also linked this page from HowToInstall, so please consider this to be the primary resource for the PostgreSQL port. All the other pages are describing the situation back for Spacewalk 0.6. The overview is: - You should be able to install Spacewalk with PostgreSQL backend and get to /rhn/YourRhn.do web page. - You should not expect anything beyond that; even this page will give you error popups for those panes. - It only works on Fedora 12. - You need to patch spacewalk-java to remove reference to blob columns to start tomcat6 -- link to 1.1.21 packages with this patch is provided. - Better solution is needed. Hello, Justin built new spacewalk-java so if you want to try to install Spacewalk nightly with PostgreSQL on Fedora 12 to hack, you can just use the nightly repo from http://koji.spacewalkproject.org/spacewalk/split/spacewalk-f12/server/spacewalk-f12-1.1/ -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PostgreSQL status
On Fri, Jul 09, 2010 at 07:37:48PM -0400, Tom Lane wrote: Personally though I'm more interested in an F-13 build. Tom, the nightly F-13 repo seems installable now for spacewalk-oracle, but for spacewalk-postgresql we are missing the python-pgsql dependency. The package seems to have been orphaned, based on http://www.redhat.com/archives/rhl-devel-list/2009-September/msg00655.html Do you know what our options for Fedora 13 are? Do we want to bring python-pgsql back, or use some other package/module? -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Suggestions for sysdate, for PostgreSQL?
On Fri, Jul 09, 2010 at 04:40:12PM +0200, Jan Pazdziora wrote: - ... and then it's just business as usual -- fix bugs that you see in catalina.out and other logs. - For example, we will need to do something about sysdate. ;-) Hello, what are our possibilities for handling sysdate in PostgreSQL. The word sysdate appears on more than 200 lines in our code base, not counting the schema definition itself where it's already been converted to current_timestamp. On these remaining lines, it is send as part of the SQL queries to the server. Are we able to create an object in PostgreSQL schema which would behave as current_timestamp but which would be called sysdate? Function seems to require parentheses upon invocation so that probably cannot be used. Another possibility is to modify the SQL on the fly, while it's being sent to the server, similar to what I did for the Python stack and the anonymous PL/SQL codes. Would it be reasonable to do a regexp replace on every command sent to the PostgreSQL server? Any performance implications? How would we do that for Java connections? Another option is to modify the sources not to use sysdate but (say) xsysdate(), or maybe now(), and define that xsysdate function both in Oracle and PostgreSQL to do the right thing. The problem with this approach is that it might have potential performance impact on the Oracle side, as having function where it had plain sysdate might prevent it to do optimizations that it was able to do before, thus slowing the operations down. Any other options? What do people think? -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PostgreSQL status
On Fri, Jul 09, 2010 at 06:15:22PM -0400, Justin Sherrill wrote: - You need to patch spacewalk-java to remove reference to blob columns to start tomcat6 -- link to 1.1.21 packages with this patch is provided. - Better solution is needed. So we think we've got a fix for the blob issue. We simply need to change it to use a binary data type within hibernate instead of a blob (and then refactor the code to handle it).I'm going to see about making this change and doing some more testing within oracle to make sure it is ok. Have you got a spacewalk-java* package I could try, for Oracle and PostgreSQL? -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PostgreSQL status
On Fri, Jul 09, 2010 at 07:37:48PM -0400, Tom Lane wrote: Personally though I'm more interested in an F-13 build. Sure. Folks are working on getting the missing dependencies of Spacewalk packages built for F13 so I hope you will see it within a week or so. Then the PostgreSQL port should work on F13 just fine (famous last words). -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] PostgreSQL status
Hello, in the past couple of weeks, I've been looking at the status of PostgreSQL database backend for Spacewalk, trying to get it install and at least start. I've summarized my findings at https://fedorahosted.org/spacewalk/wiki/PostgreSQL and I've also linked this page from HowToInstall, so please consider this to be the primary resource for the PostgreSQL port. All the other pages are describing the situation back for Spacewalk 0.6. The overview is: - You should be able to install Spacewalk with PostgreSQL backend and get to /rhn/YourRhn.do web page. - You should not expect anything beyond that; even this page will give you error popups for those panes. - It only works on Fedora 12. - You need to patch spacewalk-java to remove reference to blob columns to start tomcat6 -- link to 1.1.21 packages with this patch is provided. - Better solution is needed. - You should get the WebUI ... - ... and then it's just business as usual -- fix bugs that you see in catalina.out and other logs. - For example, we will need to do something about sysdate. ;-) - I've listed TODOs in the page. Please send patches addressing those items. - I feel that we should focus on the sanity and sustainability first, or we will end up with uninstallable port in a while again. I hope that we are (again) in the state when we are ready to accept contributions to the PostgreSQL port. Let the comments and patches flow! PS: If I'm not responding right away, it's because I'm taking rest, not because I'm ignoring you. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] spacecmd 0.4 - a viable alternative to the Satellite web UI
On Tue, Jul 06, 2010 at 11:49:35AM -0400, Aron Parsons wrote: I created an entry for spacecmd on the Spacewalk wiki. https://fedorahosted.org/spacewalk/wiki/spacecmd Great. I've linked it from https://fedorahosted.org/spacewalk/wiki/UserDocs -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] org.postgresql.util.PSQLException: Bad value for type long while SatelliteCertificate.lookupNewestCertificate
On Wed, Jun 30, 2010 at 11:50:15AM +0200, Jan Pazdziora wrote: On Wed, Jun 30, 2010 at 11:11:16AM +0200, Jan Pazdziora wrote: FYI, setting the certBlob to lazy [...] did not help. But dropping it completely diff --git a/java/code/src/com/redhat/rhn/domain/satellite/SatelliteCertificate.hbm.xml b/java/code/src/com/redhat/rhn/domain/satellite/SatelliteCertificate.hbm. index 1989496..83b09cf 100644 --- a/java/code/src/com/redhat/rhn/domain/satellite/SatelliteCertificate.hbm.xml +++ b/java/code/src/com/redhat/rhn/domain/satellite/SatelliteCertificate.hbm.xml @@ -9,7 +9,6 @@ PUBLIC -//Hibernate/Hibernate Mapping DTD 3.0//EN meta attribute=scope-setprotected/meta /id property name=label column=LABEL not-null=true type=string length=64 / -property name=certBlob column=CERT not-null=true type=blob lazy=true / property name=issued column=ISSUED type=timestamp insert=false update=false/ property name=expires column=EXPIRES type=timestamp insert=false update=false/ property name=created column=CREATED not-null=true type=timestamp insert=false update=false/ got me over to the Create Spacewalk Administrator page. Of course, we need some better solution for blob handling. Hello team, this this is currently the biggest blocker of having installable Spacewalk on PostgreSQL, so if anybody can look into it and suggest some working config for dealing with blobs in PsotgreSQL (while also keeping them working in Oracle), it would be appreciated. Thank you, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] spacecmd 0.4 - a viable alternative to the Satellite web UI
On Thu, Jul 01, 2010 at 03:18:19PM -0400, Aron Parsons wrote: I just wanted to update everyone on the status of spacecmd, a command-line interface to Satellite. I've put a bit of work into it since its first release[1] and it now can manage nearly every aspect of Satellite. I consider it a viable alternative to the web UI at this point and have been using it extensively. Below is an example of how it can simplify a process that requires far too many clicks in the web interface: spacecmd errata_apply search:CVE-2009-3726 search:CVE-2010-2063 Aron, would you maybe like to put a wiki page somewhere under https://fedorahosted.org/spacewalk/wiki/ with more info about spacecmd, so that we can reference it from other pages? Thank you, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PXT pages
On Thu, Jul 01, 2010 at 12:33:12PM +0800, Colin Coe wrote: I was looking at adding a tab under Systems for migrating between orgs but it looks like these are still PXT pages. Is this correct? Which these? Under Systems menu, everything directly there except System Set Manager seems to be .do. Of course, under that things may be .pxt still -- System Groups are a good example. If you are writing new application, you probably should do it in Java. If you just plan to add an existing .pxt application to better place in the menu structure, just do it. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] org.postgresql.util.PSQLException: Bad value for type long while SatelliteCertificate.lookupNewestCertificate
On Tue, Jun 29, 2010 at 02:47:07PM +0200, Jan Pazdziora wrote: Hello, when I try to access the /rhn/Login.do page of my PostgreSQL-backended Spacewalk, I get the following traceback: 2010-06-29 11:16:41,052 [TP-Processor3] ERROR org.hibernate.util.JDBCExceptionReporter - Bad value for type long : ?xml version=1.0 encoding=UTF-8?\012 ... /rhn-cert 2010-06-29 11:16:41,056 [TP-Processor3] WARN org.apache.struts.action.RequestProcessor - Unhandled Exception thrown: class com.redhat.rhn.common.hibernate.HibernateRuntimeException 2010-06-29 11:16:41,074 [TP-Processor3] ERROR com.redhat.rhn.frontend.servlets.SessionFilter - Error during transaction. Rolling back javax.servlet.ServletException: com.redhat.rhn.common.hibernate.HibernateRuntimeException: Executing query SatelliteCertificate.lookupNewestCertificate with params null failed at org.apache.struts.action.RequestProcessor.processException(RequestProcessor.java:535) [...] Caused by: org.postgresql.util.PSQLException: Bad value for type long : ?xml version=1.0 encoding=UTF-8?\012 ... /rhn-cert at org.postgresql.jdbc2.AbstractJdbc2ResultSet.toLong(AbstractJdbc2ResultSet.java:2796) at org.postgresql.jdbc2.AbstractJdbc2ResultSet.getLong(AbstractJdbc2ResultSet.java:2019) at org.postgresql.jdbc3g.Jdbc3gResultSet.getBlob(Jdbc3gResultSet.java:52) at org.postgresql.jdbc2.AbstractJdbc2ResultSet.getBlob(AbstractJdbc2ResultSet.java:335) FYI, setting the certBlob to lazy diff --git a/java/code/src/com/redhat/rhn/domain/satellite/SatelliteCertificate.hbm.xml b/java/code/src/com/redhat/rhn/domain/satellite/SatelliteCertificate.hbm. index 4363d48..1989496 100644 --- a/java/code/src/com/redhat/rhn/domain/satellite/SatelliteCertificate.hbm.xml +++ b/java/code/src/com/redhat/rhn/domain/satellite/SatelliteCertificate.hbm.xml @@ -9,7 +9,7 @@ PUBLIC -//Hibernate/Hibernate Mapping DTD 3.0//EN meta attribute=scope-setprotected/meta /id property name=label column=LABEL not-null=true type=string length=64 / -property name=certBlob column=CERT not-null=true type=blob / +property name=certBlob column=CERT not-null=true type=blob lazy=true / property name=issued column=ISSUED type=timestamp insert=false update=false/ property name=expires column=EXPIRES type=timestamp insert=false update=false/ property name=created column=CREATED not-null=true type=timestamp insert=false update=false/ did not help. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] org.postgresql.util.PSQLException: Bad value for type long while SatelliteCertificate.lookupNewestCertificate
On Wed, Jun 30, 2010 at 11:11:16AM +0200, Jan Pazdziora wrote: FYI, setting the certBlob to lazy [...] did not help. But dropping it completely diff --git a/java/code/src/com/redhat/rhn/domain/satellite/SatelliteCertificate.hbm.xml b/java/code/src/com/redhat/rhn/domain/satellite/SatelliteCertificate.hbm. index 1989496..83b09cf 100644 --- a/java/code/src/com/redhat/rhn/domain/satellite/SatelliteCertificate.hbm.xml +++ b/java/code/src/com/redhat/rhn/domain/satellite/SatelliteCertificate.hbm.xml @@ -9,7 +9,6 @@ PUBLIC -//Hibernate/Hibernate Mapping DTD 3.0//EN meta attribute=scope-setprotected/meta /id property name=label column=LABEL not-null=true type=string length=64 / -property name=certBlob column=CERT not-null=true type=blob lazy=true / property name=issued column=ISSUED type=timestamp insert=false update=false/ property name=expires column=EXPIRES type=timestamp insert=false update=false/ property name=created column=CREATED not-null=true type=timestamp insert=false update=false/ got me over to the Create Spacewalk Administrator page. Of course, we need some better solution for blob handling. But at least we know that the issue is indeed where it seems to be. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] org.postgresql.util.PSQLException: Bad value for type long while SatelliteCertificate.lookupNewestCertificate
at
com.redhat.rhn.common.hibernate.HibernateFactory.lookupObjectByNamedQuery(HibernateFactory.java:178)
at
com.redhat.rhn.domain.satellite.CertificateFactory.lookupNewestCertificate(CertificateFactory.java:46)
at
com.redhat.rhn.manager.satellite.CertificateManager.getGracePeriodEndDate(CertificateManager.java:88)
at
com.redhat.rhn.manager.satellite.CertificateManager.isSatelliteCertExpired(CertificateManager.java:57)
at
com.redhat.rhn.frontend.action.LoginSetupAction.execute(LoginSetupAction.java:47)
at
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431)
... 40 more
Caused by: org.hibernate.exception.DataException: could not execute query
at
org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:77)
at
org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
at org.hibernate.loader.Loader.doList(Loader.java:2223)
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2104)
at org.hibernate.loader.Loader.list(Loader.java:2099)
at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:378)
at
org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:338)
at
org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:172)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1121)
at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79)
at
org.hibernate.impl.AbstractQueryImpl.uniqueResult(AbstractQueryImpl.java:811)
at
com.redhat.rhn.common.hibernate.HibernateFactory.lookupObjectByNamedQuery(HibernateFactory.java:172)
... 45 more
Caused by: org.postgresql.util.PSQLException: Bad value for type long : ?xml
version=1.0 encoding=UTF-8?\012 ... /rhn-cert
at
org.postgresql.jdbc2.AbstractJdbc2ResultSet.toLong(AbstractJdbc2ResultSet.java:2796)
at
org.postgresql.jdbc2.AbstractJdbc2ResultSet.getLong(AbstractJdbc2ResultSet.java:2019)
at
org.postgresql.jdbc3g.Jdbc3gResultSet.getBlob(Jdbc3gResultSet.java:52)
at
org.postgresql.jdbc2.AbstractJdbc2ResultSet.getBlob(AbstractJdbc2ResultSet.java:335)
at
com.mchange.v2.c3p0.impl.NewProxyResultSet.getBlob(NewProxyResultSet.java:515)
at org.hibernate.type.BlobType.get(BlobType.java:57)
at org.hibernate.type.BlobType.nullSafeGet(BlobType.java:111)
at org.hibernate.type.AbstractType.hydrate(AbstractType.java:81)
at
org.hibernate.persister.entity.AbstractEntityPersister.hydrate(AbstractEntityPersister.java:2096)
at org.hibernate.loader.Loader.loadFromResultSet(Loader.java:1380)
at org.hibernate.loader.Loader.instanceNotYetLoaded(Loader.java:1308)
at org.hibernate.loader.Loader.getRow(Loader.java:1206)
at org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:580)
at org.hibernate.loader.Loader.doQuery(Loader.java:701)
at
org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236)
at org.hibernate.loader.Loader.doList(Loader.java:2220)
... 54 more
The issue seems to be cause by the fact that the class Jdbc3gResultSet
in org/postgresql/jdbc3g/Jdbc3gResultSet.java does
public java.sql.Blob getBlob(int i) throws SQLException
{
checkResultSet(i);
if (wasNullFlag)
return null;
return new Jdbc3gBlob(connection, getLong(i));
}
and AbstractJdbc2ResultSet in
org/postgresql/jdbc2/AbstractJdbc2ResultSet.java does
public long getLong(int columnIndex) throws SQLException
{
checkResultSet(columnIndex);
if (wasNullFlag)
return 0; // SQL NULL
Encoding encoding = connection.getEncoding();
if (encoding.hasAsciiNumbers()) {
try {
return getFastLong(columnIndex);
} catch (NumberFormatException ex) {
}
}
return toLong( getFixedString(columnIndex) );
}
So the getBlob tries to do a Jdbc3gBlob with connection and some oid,
while the getFixedString(columnIndex) already returns the blob
content.
I tried to google around, tried one recommendation to change the
type in SatelliteCertificate.hbm.xml from blob to binary, but that
lead to other errors.
Do you guys have an easy solution for our code which accesses
rhnSatelliteCert?
Thanks,
--
Jan Pazdziora
Principal Software Engineer, Satellite Engineering, Red Hat
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Primary is a reserved work -- used as column name in rhnPackageRepodata
Hello Justin, in the rhnPackageRepodata table definition, we have a column named primary. The word primary is reserved in SQL-92. Could you please rename that column to something which would not be a reserved word? It will save us some hacking and pain in the future. Thank you, -- Jan Pazdziora | adelton at #satellite*, #brno Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] New records get born in RHNDAEMONSTATE
Hello, while diffing schema contents of Spacewalk which was installed and started and Spacewalk which was never started (actually, just an old database schema upgraded to latest version), I came across the following inconsistence: select LABEL from RHNDAEMONSTATE order by LABEL channel_repodata clean_current_alerts compare_config_files daily_summary errata_cache errata_engine errata_queue kickstart_session_check last_task_completed package_cleanup repo_sync sandbox_cleanup satcert_check session_cleanup summary_populator sync_from_cobbler synch_probe_state While the schema which never had Spacewalk (and most probably, taskomatic) running only has four records there: entitlement_run_me email_engine payloader_engine pushed_users Which also matches the content of schema/spacewalk/common/data/rhnDaemonState.sql which populates the table with four records. So the table is considered to be a register or lookup table, having some specific list of records from installation time, and then we put more data there during runtime. What I don't like here is the fact that we go into some trouble populating the table with four records (and I believe that the intention was that whatever processes are using that table would only update the last_poll column for existing records), and then the application logic adds 17 more records there. For example, I've found summary_populator in java/code/src/com/redhat/rhn/taskomatic/task/SummaryPopulation.java Therefore I believe it's the application code which inserts new records. I believe that we should either populate the schema with the full list of labels that we are going to need, and never insert just update in the application code; or we should not populate anything (and I will remove this table from the list of tables that we verify the schema for). Or maybe the code cannot be prevented from doing insert to the table RHNDAEMONSTATE (maybe it does delete + insert), in which case we probably want different table holding the list of allowed labels and having RHNDAEMONSTATE.LABEL a foreign key to that table, so that the application code does not insert completely random labels. Thoughts? -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Removed the bulk-subscribe and unsubscribe which is not used anywhere
On Fri, Jun 11, 2010 at 11:49:17AM -0400, Partha Aji wrote: Jan the ssm change channel stuff got ported to Java. I should remove alter pxt also.. I 'll dig a bit more on this later today. Thanks for thepointer.. Hmmm, alter_subscriptions_conf.pxt is still referenced in Sniglets::ChannelLicense::channel_license_dialog_cb. And rhn:channel_license_dialog_cb is set as trap only in channel_license.pxt and that one is listed as the second rhn-tab-url. So maybe channel_license.pxt could go, taking some of Sniglets::ChannelLicense with it, taking alter_subscriptions_conf.pxt with it. While we are at it, display_license.pxt which is the other remaining place using Sniglets::ChannelLicense is only referenced as rhn-tab name=License acl=channel_licensed() url=/network/software/channels/display_license.pxt / and get_license_path does SELECT CFL.license_path INTO license_val FROM rhnChannelFamilyLicense CFL, rhnChannelFamilyMembers CFM WHERE CFM.channel_id = channel_id_in AND CFM.channel_family_id = CFL.channel_family_id; and rhnChannelFamilyLicense is empty on my Satellite 5.3. Is this table and rhnChannelFamilyLicenseConsent somehow used in Spacewalk / Satellite? -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] %changelogs in our packages
On Tue, Jun 01, 2010 at 08:36:05PM +0200, Sandro red Mathys wrote: On Tue, Jun 1, 2010 at 7:53 PM, Cliff cpe...@redhat.com wrote: I'd be interested in knowing if there is any general guideline from Fedora for package maintainers that we would need to adhere too? I'm pretty sure the fedora guidelines only state to add a new entry with every new release but does never say if or when you should remove old entries nor that you have to keep them forever. So I asked spot who wrote most of that guidelines and is sort of responsible for that stuff: hi spot, I was looking at the guidelines regarding the removal of old changelog entries but I didn't find anything on that matter. Do you think it would be okay to remove entries that are 1 year old? if you do, put them in a file and put the file in the package and put a note in the rpm changelog that says something like: * package changelogs older than June 2009 can be found in Fedora.Changelog.txt I do not think this really applies. Fedora's changelog entries are entries for changes done for given version of the package, basically describing changes done for the releases for one primary .tar.gz version. For example, on my Fedora 12, $ rpm -q --changelog perl | tail -3 * Thu Nov 29 2007 Robin Norwood rnorw...@redhat.com - 4:5.10.0_RC2-0.1 - first attempt at building 5.10.0 $ rpm -ql perl | grep -i changelog | wc -l 0 When perl was rebased to 5.10, new .tar.gz was put into Source*, and any changelog entries for older perls were dropped. With Spacewalk, we bump the version with every release, which means that we rebase with every new rpm we build. All packages where Spacewalk is the upstream have release equal to 1. So if we were following the Fedora example, we would never have more than one item in the %changelog, because after all, this rpm has vanilla upstream package and vanilla upstream .tar.gz, with no changes. I believe that storing the older changelog entries in an extra file is not needed. They don't include the full history anyway (we weren't that good maintaining the changelog in the past, so there are gaps there), and as the sources are available, it's possible to get the logs and exact changes from the git repo anyway. Currently I'm planning on removing changelog entries for 0.4 and earlier. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] java/code/libsrc in our repo?
Hello,
we have 27 .jars in java/code/libsrc in our repo. What are they used
for? I can see references to libsrc in
build.xml:arg value=${eclipse.libsrc.dirs} /
buildconf/build-props.xml: property name=eclipse.libsrc.dirs
location=${basedir}/code/libsrc /
conf/eclipse/rhn_eclipse_libraries.xml:archive
path=/usr/share/java/commons-beanutils.jar
source=/rhn-java/code/libsrc/commons-beanutils-1.7.0-src.j
[...]
conf/eclipse/rhn_eclipse_libraries.xml:archive
path=/usr/share/java/quartz.jar
source=/rhn-java/code/libsrc/quartz-1.5.1-src.jar/
conf/eclipse/rhn_eclipse_libraries.xml:archive
javadoc=file:/usr/share/javadoc/jakarta-commons-cli/
path=/usr/share/java/commons-cli.jar source=/r
But why are we using .jars from our source repo which might be out
of date with libraries that our Java stack is compiled with/against,
or run with?
Can we remove this directory and references to it?
--
Jan Pazdziora
Principal Software Engineer, Satellite Engineering, Red Hat
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Translations
On Thu, May 06, 2010 at 10:20:52AM +0200, Miroslav Suchý wrote: You can help with Spacewalk translation at: https://translate.fedoraproject.org/projects/p/spacewalk/ You should be able to log in using you FAS account. You are encouraged to work on following components: rhnsd yum-rhn-plugin rhn-client-tools Please do *not* work on spacewalk-server as 8bit characted currently make problem in xmlrpc communitacion. All changes in Transifex will be automaticaly saved in master branch of our git repo. Cool stuff, thank you, Mirek. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Pushed first commit
On Fri, Apr 23, 2010 at 08:14:24PM +0800, Colin Coe wrote: Hmm, I see it in 'gitk' and 'git log' shows: --- commit e8bc01bd4710cff6548e1790b48b101f1136b3a3 Author: Colin Coe colin@gmail.com Date: Thu Apr 22 21:13:23 2010 +0800 Make bash the default for syntax highlighting --- Not sure what I've done wrong. I followed the procedure in the git guide. You did not push your change. You've only committed to your local directory but you did not push it to the origin -- the http://git.fedorahosted.org/git/?p=spacewalk.git;a=commit;h=e8bc01bd4710cff6548e1790b48b101f1136b3a3 says 404 - Unknown commit object. Do rebase your change on top of current master (after you've pulled) and then do git push. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Bug space11 now created
Hello, I've created bug with alias space11 as tracker for bugs that will not make it into Spacewalk 1.0. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] read_cpuinfo in the client code
It looks like we have the same or very similar loop for most platforms. Maybe it would make sense to have the top level while and parsing of the /proc/cpuinfo to be common code, and only do the ifs when reading in the specific fields. Patches welcome, if anyone wants to give it a try. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk 1.0 vs 0.9?
On Thu, Apr 15, 2010 at 01:02:21PM -0400, Cliff wrote: So we are considering making the 0.9 release for Spacewalk a 1.0 release instead. Spacewalk has been maturing for 2 years now and has not had much code in it from 0.8 to destabilize. I feel that likely the code we have today in the nightlies is as close to ready for a 1.0 release we will likely have for the next 6+ months. We have been doing a lot of bugfixing these past months, with some enhancements. So, any objections? +1.0. No objection. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Patch: add arch to channel.list*Channels
On Tue, Apr 13, 2010 at 05:58:41AM +0800, Colin Coe wrote: Tomas, apologies for the original reply. My SQL skills are quite weak and doing the query wit joins did not occur to me. Is using the joins more efficient? I can't see a difference in the result returned when I run either of these queries. Since there is a foreign key on rhnChannel(channel_arch_id) pointing to rhnChannelArch(id), the queries will return exactly the same results. There is nothing wrong with your syntax or your query. The only issue might be that when you or someone else will further tweak the query to for example return rhnChannelArch.label as well, with your query they might end up doing another inline select, instead of using the rhnChannelArch from the FROM list. And since the foreign key ensures that the cardinality of the result is not changed by joining with the rhnChannelArch table, it's actually a tiny bit better to do it the way Tomas has suggested. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Rebasing one package (subdirectory) in git
This is mainly note to self, how to rebase one package (rhn-client-tools) while keeping the rest of the git repository intact. The initial situation is: - we are in some branch, let's assume in master; - we want to rebase content of the directory client/rhel/rhn-client-tools from branch b while keeping the rest of our master the same. $ git merge -s ours --no-commit b $ git rm -r client/rhel/rhn-client-tools $ git read-tree --prefix client/rhel/rhn-client-tools b:client/rhel/rhn-client-tools $ git show b:rel-eng/packages/rhn-client-tools rel-eng/packages/rhn-client-tools $ git add rel-eng/packages/rhn-client-tools $ git commit -m 'Rebase rhn-client-tools to latest from branch b.' $ git reset --hard HEAD The steps with rel-eng/packages/rhn-client-tools allow us to modify yet another file outside of the client/rhel/rhn-client-tools directory. Which is useful with Spacewalk because the version of rhn-client-tools in branch b will become visible and latest in master as well. After these steps and before git push, I recommend running gitk --all or similar and review what happened. In addition, I recommend to run checks like $ git diff origin/master..master | grep ^diff \ | grep -v 'diff --git a/client/rhel/rhn-client-tools/' which in our case should only show rel-eng/packages/rhn-client-tools -- nothing else besides that file and the client/rhel/rhn-client-tools directory should have changed in the master. And against branch b $ git diff b..master -- client/rhel/rhn-client-tools which should show nothing, as the whole subdirectory in master should have been correctly overwritten (rebased) to what we have in b. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Remove audit review cruft from spacewalk-setup
On Wed, Mar 31, 2010 at 04:24:01PM -0400, Joshua Roys wrote: OK- that sounds good. I'll write up a patch tomorrow or Friday to move it over. It will probably be something like /var/spacewalk/systemlogs. Do you have any recommendations on how to handle upgrades? Some options: - just make a release note about it, nothing else - have a %post script move the directory (gross!) - drop a line in rhn.conf pointing the audit code to /var/satellite/systemlogs from a %post - have the code look in both (also gross) My order of rpeference would be 1, 2, 3, 4. ;-) -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Remove audit review cruft from spacewalk-setup
On Tue, Mar 30, 2010 at 08:29:45AM -0400, Joshua Roys wrote: The main purpose of the systemlogs directory is to contain various logs from systems (namely the audit.log files) and the audit-review.log record-keeping file. I decided yesterday to have the default be /var/satellite/systemlogs irrespective of the 'mount_point' variable. The two reasons behind this are: - the AuditManager class uses a different variable, web.audit.logdir, to find the systemlogs directory. - when users would paste their spacewalk-setup output for help on spacewalk-list, I kept seeing chown errors; the directory /needs/ to be owned by tomcat now, and if spacewalk-setup made the directory but failed the chown, the audit code wouldn't be happy without manual intervention. This way, it can be assumed that everything is setup as needed- although moving the systemlogs directory would require a bit of knowledge at this point. Two things come out of this: first, I should probably write an spacewalk-audit-setup script, or somesuch, to facilitate moving the directory around and setting up various things. Secondly, and more long-term, I think it would be nice to have the audit records optionally be in the database (I say optionally because of the 4G limit of XE - but hopefully the psql port will eventually take care of that). What do you think? Do you agree? Or was it better how it was before? The problem is: traditionally, /var/satellite as the default values of the mount point was never maintained by the rpm database. There are use cases where people mount the /var/satellite over NFS or share among Satellites, etc. By now putting the rpm-managed /var/satellite/systemlogs directory there, I fear we might experience bad side-effects. I'm not opposed to having the directory for systemlogs rpm-managed, I'd just like it to be different directory than something withing the default mount point path. Maybe /var/spacewalk or /var/rhn or something similar? -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Remove audit review cruft from spacewalk-setup
On Mon, Mar 29, 2010 at 06:48:06PM +, Joshua Roys wrote:
java/spacewalk-java.spec|2 +-
spacewalk/setup/bin/spacewalk-setup |6 --
2 files changed, 1 insertion(+), 7 deletions(-)
New commits:
commit b77ae909987391ab6ce1c37bad1e20b2da46edbd
Author: Joshua Roys joshua.r...@gtri.gatech.edu
Date: Mon Mar 29 14:35:20 2010 -0400
Remove audit review cruft from spacewalk-setup
Rely on RPM %files and the O_CREAT behavior of FileWriter to create
our systemlogs directory and audit-review.log file.
diff --git a/java/spacewalk-java.spec b/java/spacewalk-java.spec
index 7cc0a09..c74fdfc 100644
--- a/java/spacewalk-java.spec
+++ b/java/spacewalk-java.spec
@@ -281,7 +281,7 @@ fi
%config(noreplace) %{_sysconfdir}/tomcat6/Catalina/localhost/rhn.xml
%endif
%{realcobsnippetsdir}/spacewalk
-%attr(755, apache, root) %{_var}/satellite/systemlogs
+%attr(755, tomcat, root) %{_var}/satellite/systemlogs
%ghost %attr(644, tomcat, root) %{_var}/satellite/systemlogs/audit-review.log
%files -n spacewalk-taskomatic
diff --git a/spacewalk/setup/bin/spacewalk-setup
b/spacewalk/setup/bin/spacewalk-setup
index 957ee66..868c42f 100755
--- a/spacewalk/setup/bin/spacewalk-setup
+++ b/spacewalk/setup/bin/spacewalk-setup
@@ -108,15 +108,9 @@ print Spacewalk::Setup::loc(* Performing initial
configuration.\n);
my $config_opts = populate_initial_configs(\%opts, \%answers);
mkdir_mount_points($config_opts-{'mount_point'},
$config_opts-{'mount_point'} . '/redhat',
- $config_opts-{'mount_point'} . '/systemlogs',
$config_opts-{'kickstart_mount_point'});
setup_sudoers(\%opts, \%answers);
-my $aurev_fn = $config_opts-{'mount_point'} .
'/systemlogs/audit-review.log';
-qx(touch $aurev_fn);
-qx(chown tomcat $aurev_fn);
-qx(chattr +a $aurev_fn);
-
Joshua,
what is the general intent behind the systemlogs directory? Is it
indeed supposed in the '/var/satellite' directory, no matter where
the mount point of /var/satellite is?
In other words, are you intending to have the audit-review.log in
/var/satellite/systemlogs, even if the .rpms are say in
/data/satellite/redhat?
--
Jan Pazdziora
Principal Software Engineer, Satellite Engineering, Red Hat
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Fix a memory leak in rhnsd
On Fri, Mar 19, 2010 at 11:22:38AM +0100, Jan Pazdziora wrote: commit f987184526fb2cecf47b9dce8bf69c1c66a86d88 Author: Joshua Roys joshua.r...@gtri.gatech.edu Date: Thu Mar 18 14:00:07 2010 + Fix a memory leak in rhnsd diff --git a/client/rhel/rhnsd/rhnsd.c b/client/rhel/rhnsd/rhnsd.c index 357c59d..1e8fe21 100644 --- a/client/rhel/rhnsd/rhnsd.c +++ b/client/rhel/rhnsd/rhnsd.c @@ -604,6 +604,7 @@ static int parse_systemid_path(char* systemid_path, int systemid_path_length) } fclose(config_file); } +regfree(re_systemIdPath); return ret; } Joshua, thanks for catching this. I wonder if you also want to add a check for the return value of that regcomp call. FYI, I've now tagged and built rhnsd-4.9.3-1.* into nightly client repo. Thanks! -- Jan Pazdziora | adelton at #satellite*, #brno Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Bug 559693 - Add md5sum in package description from channel.software.listAllPackages
On Fri, Mar 19, 2010 at 08:29:13AM +0800, Colin Coe wrote: I'd like to take over this bugzilla. It is already assigned to Justin Sherrill. Is there a procedure for taking over someone else's bugzillas or do I just take it? Just asking as I'd rather not tread on toes... It's good to ping the current assignee on IRC or via email (which is basically exactly what you did) to make sure he/she is not right in the middle of the work on that bugzilla. I assume Justin will confirm that he hasn't been working on this yet. As for the actual RFE, just note that it's no longer just MD5 that we care about -- the checksum situation got a bit more generic lately. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Fix a memory leak in rhnsd
commit f987184526fb2cecf47b9dce8bf69c1c66a86d88 Author: Joshua Roys joshua.r...@gtri.gatech.edu Date: Thu Mar 18 14:00:07 2010 + Fix a memory leak in rhnsd diff --git a/client/rhel/rhnsd/rhnsd.c b/client/rhel/rhnsd/rhnsd.c index 357c59d..1e8fe21 100644 --- a/client/rhel/rhnsd/rhnsd.c +++ b/client/rhel/rhnsd/rhnsd.c @@ -604,6 +604,7 @@ static int parse_systemid_path(char* systemid_path, int systemid_path_length) } fclose(config_file); } +regfree(re_systemIdPath); return ret; } Joshua, thanks for catching this. I wonder if you also want to add a check for the return value of that regcomp call. Yours, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Any reason to not add a FK constraint to rhnReleaseChannelMap
On Tue, Mar 02, 2010 at 12:45:23PM -0500, Justin Sherrill wrote: Can anyone think of reason why there isn't already a foreign key constraint for channel_id within the rhnReleaseChannelMap table? Same question for channel_arch_id. I'm proposing to add it as well as makeing channel_id on delete cascade. This information is populated during a satellite sync (when you sync the channel). +1 for any change that makes the schema more robust. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Selinux fix for taking backups of the oracle xe
On Tue, Dec 01, 2009 at 09:47:29PM +0100, George wrote:
Making a backup of spacewalk database:
environment: centos 5.3 running spacewalk 0.6 (according to
/etc/spacewalk-release: spacewalk release 0.6.4 (Alpha))
[...]
When trying to run backup script:
$
/usr/lib/oracle/xe/app/oracle/product/10.2.0/server/config/scripts/backup.sh
[...]
which translates into:
#= oracle_db_t ==
allow oracle_db_t sbin_t:dir { search getattr };
allow oracle_db_t tmp_t:file { read write ioctl };
allow oracle_db_t unconfined_t:process signull;
#= oracle_sqlplus_t ==
allow oracle_sqlplus_t httpd_sys_content_t:dir search;
allow oracle_sqlplus_t sbin_t:dir { search getattr };
allow oracle_sqlplus_t tmp_t:file write;
at this time ofcourse my backup worked ...
anyone can check these findings and confirm?
George,
with the following packages
oracle-instantclient-sqlplus-selinux-10.2-17.el5
oracle-nofcontext-selinux-0.1-23.13.el5
oracle-instantclient-selinux-10.2-17.el5
oracle-xe-selinux-10.2-15.el5
from Spacewalk 0.7, none of the above happens, so I assume we've fixed
it for 0.7.
also a note:
I see a lot of selinux messages like described (and probably patched) on
this page:
http://git.fedorahosted.org/git/?p=spacewalk.git;a=commitdiff;h=f73e3d94c589a634a972ac1d86583d5a34635836
Yes, I do see
allow oracle_db_t self:process ptrace;
allow oracle_db_t unconfined_t:process signull;
issues on my system, even if the ptrace is allowed in the policy module.
I'll try to investigated.
Luckily, these do not seem to affect the backup operation.
Yours,
--
Jan Pazdziora
Principal Software Engineer, Satellite Engineering, Red Hat
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] browser_css_compliance -- proposing to drop
On Tue, Dec 22, 2009 at 04:04:36PM +0100, Jan Pazdziora wrote:
we have function
# return a vague idea of how well the browser supports CSS. note that
# NN gets a 0, everything else a 1, roughly corresponding to CSS-1
# compliance
sub browser_css_compliance {
my $self = shift;
my $ua = $self-header_in('User-Agent');
if ($ua and $ua =~ m(Mozilla/4.[567])) {
return 0;
}
return 1;
}
in PXT/Request.pm.
I propose to drop it, including rhn-browser-css-compliance, as the
list of non compliant browsers is by no means exhaustive, we don't
check for CSS2 anyway, and the percentage of Mozilla 4.[567] browsers
is likely to be close to zero anyway.
Please complain now if you disagree,
FYI, it's gone now.
--
Jan Pazdziora
Principal Software Engineer, Satellite Engineering, Red Hat
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Selinux fix for taking backups of the oracle xe
On Tue, Dec 01, 2009 at 09:47:29PM +0100, George wrote: Making a backup of spacewalk database: environment: centos 5.3 running spacewalk 0.6 (according to /etc/spacewalk-release: spacewalk release 0.6.4 (Alpha)) [...] George, thank you for your post. I shall try to investigate and integrate the changes (I actually hit some earlier in the process when trying to run the backup, which I'm focusing on now). -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk client yum repo
On Fri, Nov 20, 2009 at 12:49:30PM -0600, Dennis Gilmore wrote: This is rubbish. Spacewalk repos are the upstream for whatever makes it into Fedora and EPEL. Why on Earth should upstream stop building and releasing their packages just because someone has decided to put those packages to Fedora or EPEL? Because thats what we said we were going to do at the start of this whole thing. typically upstreams only ship tarballs. the goal was to Currently, we don't even have a way (tooling + infrastructure) to only ship tarballs, list tarballs, etc. In addition, our development and testing setups consist of RHELs and Fedoras. If I commit a change to the git repository and I want to test that change, I need an rpm, not tarball. move everything into fedora/epel and stop building and shipping the spacewalk repos. Even if all our packages were in Fedora today, we still need a way to build packages and create repos of those packages. Fedora 11 might have Spacewalk 0.6 packages in it and when we release Spacewalk 0.7, we might not want to destabilize those F11 installations by rushing it all to F11 immediatelly. But we will still need a repo to install that Spacewalk 0.7 on F11 to check for regressions. What we might consider doing is actually yet another split, of both the server and the client packages. One repository which would only contain packages that are not in Fedora / EPEL, and one repository containing a bleeding edge of all packages where we are upstream. So, for example, since nocpulse-common made it to Fedora and is in F12, we probably should not have the rpm in Spacewalk 0.7 yum repository for Fedora, once we do 0.7 release. It should be fairly easy to do with the supporting packages, even if we'll have to take extra care to play nice with older versions of these supporting packages in our main application code (spacewalk-java, spacewalk-backend, etc.). But there has to be a yum repository with all our packages (those that we are upstream of) in latest versions, both for internal and external testing, so that people have a way to install the latest software. -- Jan Pazdziora | adelton at #satellite*, #brno Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk client yum repo
On Thu, Nov 19, 2009 at 02:13:08PM +0100, Jan Blazek wrote: I have an idea how to do this. If we don't want to split koji tags (which I think would be an overhead) we need to specify somewhere the lists of packages which would go to which repository. I'd prefer to use comps files as these lists. We take a similar approach for Satellite where there are two separate comps files for Satellite and EmbededDB. Next step would be to force mash to take into account only those packages specified in comps. This would need to patch mash to add this feature. How do you like this idea? While it would certainly be interesting to have this feature, patching the mash, getting it upstream, etc. seems like bringing unnecessary delay. Can you use the same mash config which is used now for the Spacewalk server repo, have that setup, and only then start working on patching mash to support comps, and once we get the new mash in EPEL or whatever is running on koji.rhndev.redhat.com, convert the current config to comps? I definitely prefer having the yum repo available today without comps over having it in two weeks with comps. Thank you, -- Jan Pazdziora Senior Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Spacewalk client yum repo
On Mon, Sep 07, 2009 at 09:46:07AM +0200, Miroslav Suchý wrote: Please create Spacewalk client yum repo in koji.rhndev.redhat.com and move the following packages from the Spacewalk server yum repo to it: rhcfg* rhn-custom-info osad rhn-applet-actions rhn-custom-info rhn-kickstart* rhn-virtualization* spacewalk-koan rhnlib rhnmd rhnsd rhn-check rhn-setup yum-rhn-plugin koan spacewalk-certs-tools spacewalk-koan Thank you, -- Jan Pazdziora Senior Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Re: [Spacewalk-list] Custom Certificate Creation - invalid mode signing cert
On Thu, Oct 15, 2009 at 02:12:56PM -0400, Greg Fuller wrote: I'm trying to create a custom spacewalk entitlement certificate. We're trying to get rid of the Spacewalk Public Cert being set as the default organization (which shows up in the main GUI all the time) and change it to our organization name. From my digging it looks like we need to create a custom entitlement certificate in order for this to work. I've following directions at the following 2 sites to try and get this working: https://fedorahosted.org/spacewalk/wiki/CertCreation http://www.cs.rug.nl/~jurjen/ApprenticesNotes/ch11.html#Installing_Space walk The 2nd link has more detail on creating the gpg keys for signing. My spacewalk install (v.6) did not come with the CertUtils.pm library, so I had to manually download that from the location below and put it in /usr/lib/perl5/vendor_perl/5.8.8/RHN/ https://fedorahosted.org/spacewalk/browser/web/modules/rhn/RHN/CertUtils .pm?rev=c43c7764d22ca8a78fd6f446b0892b6dec5e78a8 Now when I run the gen-oss-sat-cert.pl script I get the following So, my question is: why don't we ship the gen-oss-sat-cert.pl in some of our packages, and (looking at https://fedorahosted.org/spacewalk/attachment/wiki/CertCreation/gen-oss-sat-cert.pl) if the RHN::CertUtils is essential, also tship that one? Well, since RHN::CertUtils only has that one passphrase_prompt function in it, we might just as well inline it in gen-oss-sat-cert.pl. But what is the status of gen-oss-sat-cert.pl is the main question. -- Jan Pazdziora Senior Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Usage of column created?
Mirek, the commit message seems to suggest that you plan to store the rpm installation date in that created column. It that so? commit 78f52b089c82e725b77b2e38e68fb02d49fe1512 Author: Miroslav Suchý msu...@redhat.com Date: Mon Oct 19 15:08:07 2009 +0200 449167 - record rpm installation date diff --git a/schema/spacewalk/common/tables/rhnServerPackage.sql b/schema/spacewalk/common/tables/rhnServerPackage.sql index 6b9b091..b500019 100644 --- a/schema/spacewalk/common/tables/rhnServerPackage.sql +++ b/schema/spacewalk/common/tables/rhnServerPackage.sql @@ -24,7 +24,9 @@ CREATE TABLE rhnServerPackage evr_id NUMBER NOT NULL REFERENCES rhnPackageEVR (id), package_arch_id NUMBER - REFERENCES rhnPackageArch (id) + REFERENCES rhnPackageArch (id), +created DATE + DEFAULT (sysdate) NOT NULL ) TABLESPACE [[server_package_tablespace]] ENABLE ROW MOVEMENT It sounds like a bad plan to me, as in all other tables in Spacewalk schema we store the timestamp/date of when the record was created. Note that it might not be the same as when the rpm was installed -- the information about rpm installation might be delayed. Could we use a different column name? -- Jan Pazdziora | adelton at #satellite*, #brno Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Split of spacewalk yum repo?
On Tue, Sep 08, 2009 at 12:06:46PM -0500, Dennis Gilmore wrote: On Tuesday 08 September 2009 11:52:43 am Brandon Perkins wrote: As I understand it, the main concern that Miroslav was having in this case was avoiding installing new versions of packages from Spacewalk that are also shipped with RHEL or RHN Client Tools. Basically, wanting to avoid someone accidentally upgrading a Red Hat shipped package with a Spacewalk package and making support a little more cumbersome. Making sure we dont ship those packages I think is the right answer. There a few we need to not ship as fedora/EPEL ships them. I will work on blocking the packages that we should not ship. Hello Dennis, has this been done and is the client repository available for use somewhere? -- Jan Pazdziora Senior Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Split of spacewalk yum repo?
On Tue, Sep 08, 2009 at 10:41:18AM -0500, Dennis Gilmore wrote: We cant easily do this. Without creating a maintenance headache for ourselves. mash grabs all the packages from a koji tag and puts them into a repo. taking into account inheritance. To implement this we would need to setup additional tags inheriting from the build tags and then we would need to block all of the packages we dont want in the mashed repos. if any sub rpms are split across repos we cant do that. Keeping in mind we should be getting everything into Fedora/EPEL so that the koji we use can go away remember its only a temporary setup. This is alot of extra work for little gain. the blocking of packages would need to happen on each and every version bump of spacewalk. our best bet is likely to block the packages that are shipped in RHEL so we do not build our own version and make sure that CentOS ships them. and continue with our single repo. If mash cannot achieve what we need to achieve, perhaps we need to work with the upstream to add the features we need there, or consider using other tools (pungi?), or write our own. -- Jan Pazdziora | adelton at #satellite*, #brno Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Split of spacewalk yum repo?
On Mon, Sep 07, 2009 at 08:42:23AM +0200, Miroslav Suchý wrote: Jesus M. Rodriguez wrote: yum/0.7/proxy yum/0.7/server IMO this does not bring any benefit. A lot of packages are common. If you install proxy, yum will not install Spacewalk server packages and vice versa. Right. On the other hand, the split will make it easier to repo sync just the proxy repo to your Spacewalk server. Plus, it's what we do with Satellite and RHN Proxy as well. But if you install Proxy or Spacewalk, yum will install new client tools. Well, that's why Jesus had that yum/0.7/client there as well. -- Jan Pazdziora Senior Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Re: Branch 'sha256-support' - 135 commits - ... schema/spacewalk ...
On Mon, Jul 27, 2009 at 07:54:32PM +0200, Milan Zazrivec wrote: On Monday 27 July 2009 15:54:13 Pradeep Kilambi wrote: diff --git a/schema/spacewalk/rhnsat/tables/rhnChannel.sql b/schema/spacewalk/rhnsat/tables/rhnChannel.sql index 95a54dc..b4e1fab 100644 --- a/schema/spacewalk/rhnsat/tables/rhnChannel.sql +++ b/schema/spacewalk/rhnsat/tables/rhnChannel.sql @@ -49,6 +49,8 @@ rhnChannel gpg_key_id varchar2(14), gpg_key_fp varchar2(50), end_of_life date, +checksum_type_id number constraint rhn_channel_checksum_fk + references rhnChecksumType(id), receiving_updates char(1) default 'Y' constraint rhn_channel_ru_nn not null Now that rhnChannel table depends on rhnChecksumType, this relation needs to be put into the Makefile.deps (and the pgsql branch equivalent) so that the resulting schema deploys cleanly. Also, shouldn't the id in rhnChecksumType and that checksum_type_id here be some type of integer? It seems strange to see it defined as generic number. -- Jan Pazdziora Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Selinux Temporarily Disabled in Devel Repo
On Tue, Jul 21, 2009 at 05:33:51PM -0300, Devan Goodwin wrote:
On Mon, Jul 20, 2009 at 03:53:14PM -0300, Devan Goodwin wrote:
We've got both selinux build problems for Fedora 11, as well as
selinux denials post install on at least el5. As such I've
temporarily disabled
What are the AVC denials on EL 5? I'm aware of the build problems
Now filed here:
https://bugzilla.redhat.com/show_bug.cgi?id=513071
Happened on CentOS 5.2.
As it turns out to be user error and not a bug in the code, could you
please revert the commit which commented out the Requires of *-selinux
packages, and just put in a check for 0%{?fedora} == 11, similar to
spacewalk-monitoring.spec?
That way we still have *-selinux packages installed and hopefully
tested on F10 and EL5. As Spacewalk 0.5 worked with SELinux in
Enforcing on those two OSes, we should try not to introduce
regressions, and keeping the modules in the transaction seems like the
best way to achieve that.
Thank you,
--
Jan Pazdziora
Senior Software Engineer, Satellite Engineering, Red Hat
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Selinux Temporarily Disabled in Devel Repo
On Mon, Jul 20, 2009 at 03:53:14PM -0300, Devan Goodwin wrote: We've got both selinux build problems for Fedora 11, as well as selinux denials post install on at least el5. As such I've temporarily disabled What are the AVC denials on EL 5? I'm aware of the build problems on F11 but EL 5 should be clean. Do you have a bugzilla number? -- Jan Pazdziora | adelton at #satellite*, #brno Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] pgsql review
On Thu, May 14, 2009 at 11:24:33AM -0400, Jeff Ortel wrote: The views/rhnHistoryView.sql file seems to still contain definition of rhnHistoryView_pkglist function. Is that correct? Hmm... didn't expect to find function definitions in a view file so I didn't look. I agree this function should be split out and the view.deps updated. This file was just an example. If we are touching the file in any way, even if just moving it from one directory to another, and especially with this large schema restructuralization effort, the commit of the file is basically a seal of correctness. If we did not check the files manually or with some tools, we should not be changing or moving the file. I'm much in favor of schema validation tools which will in rpm build time catch issues like this one. I'm very much against reformatting tools that just change the spacing and lowercase to uppercase, if they do not contain the overall validation parts as well. -- Jan Pazdziora Senior Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Re: Proposed commit hook to catch suspicious merge commits
On Tue, May 12, 2009 at 03:25:53PM +0200, Jan Pazdziora wrote: Jan, is there something I can do to edit that message and get this push to work? The one of d1c65b572d1b9e1ccd863cce3104a853acc9ad9f? Nope. The best bet will probably be to ask the infrastructure guys to disable the hook, do the push, and enable it again. Upon subsequent pushes, the commit will already not be considered by the hook. I was thinking about this more. Can't you merge the commit just before the merge commit which causes a trouble, then cherry pick that commit's change with normal commit, and then merge the HEAD? That way, the git rev-list could be reporting the new non-merge commit, not the merge one. Could you give it a try? -- Jan Pazdziora Senior Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] pgsql review
On Tue, May 12, 2009 at 12:42:32PM -0400, Jeff Ortel wrote: All, I'd like to start getting some eyes on the pgsql branch in preparation of a merge to master. So far, the changes on this branch have been focused on porting the schema and updating the application infrastructure to work with both oracle and postgres databases. This might be a technicality but: do we want to merge or cherry pick? If we want to start with infrastructure work, I assume we will want to bring in the changes to master in small steps, addressing one issue at a time (SQL standard compliance, table / trigger DDL split, etc.). That way, the changes will have a chance to get verified and tested in Oracle environment while the diff against the pgsql branch will get smaller. I would not want to see huge merge commit landing in master. (I will probably send more responses to your post, commenting on one issue at a time.) -- Jan Pazdziora Senior Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] pgsql review
On Tue, May 12, 2009 at 12:42:32PM -0400, Jeff Ortel wrote: The goal here was to push as much of the schema into common as practical and make the schema code tree as developer friendly as possible. - The schema directory has been refactored replacing rhnsat/ with: oracle/ postgres/. - Forked (cannot be common) items: rhnsat/class/ rhnsat/types/ rhnsat/procs/ rhnsat/packages/ (git) moved to oracle/ and copied to postgres/ and ported to PG. It looks like you've renamed the rhnsat/ directory to common/. That however makes it very hard to do a diff against master to see what has changed. Do you plan to rename rhnsat/ to common/ any time soon in master (or temporarily rename it back in pgsql branch) so that diffing the changes is easier? -- Jan Pazdziora Senior Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] pgsql review
Another email, focusing on the tables/ directory. On Tue, May 12, 2009 at 12:42:32PM -0400, Jeff Ortel wrote: - Table files (rhnsat/tables/*) - table.sql files: - Most moved to common/tables/ - Trigger DDL split out and moved into existing or new oracle/triggers/table.sql - *_triggers.sql files: - (git) moved to oracle/triggers/ - _triggers suffix removed because redundant w/ directory scoping. - *_data.sql files: - Most (git) moved to common/data/ - Few files forked and (git) moved to oracle/data. Forked files copied to postgres/data and ported to PG. - _data suffix removed because redundant w/ directory scoping. - *_index.sql files consolidated into file w/ table DDL. Most of the indexes were already there anyway. This all sound like a sane to do for just Oracle anyway. Polishing the schema sources is always good thing, so I propose doing the changes in master where we can, one issue per commit, without waiting for PostgreSQL-specific parts to be ready. I see the following problems: The rhn_ksscript_mod_trig trigger is still defined on wrong table, see https://www.redhat.com/archives/spacewalk-devel/2008-September/msg00136.html That would signal that no validation of the semantics of the code was done. I'm very affraid that by doing large shuffles without having some more formal validation in place, we will lose information and potentially introduce many bugs. I also wonder if this would be a good time to generate the for each row begin :new.modified := sysdate; end; and other common types of triggers automatically. There seem to be not only moves of table DDL tables but also changes in the content. Things like -create table -web_user_site_type + +CREATE TABLE web_user_site_type ( - typechar(1) - constraint wust_type_nn not null - constraint wust_type_pk primary key, - description varchar2(64) - constraint wust_desc_nn not null +type CHAR(1) NOT NULL + CONSTRAINT wust_type_pk PRIMARY KEY, +description VARCHAR2(64) NOT NULL ) - enable row movement - ; +ENABLE ROW MOVEMENT +; Why were these changes done? They do not seem to be necessary, it's hard to see what is changing, and again, we potentially introduce bugs. The new code seems to have trailing spaces. Is that some kind of format=flowed thing or is this a bug which should be addressed? This particular patch also shows another issue -- the wust_type_nn constraint is dropped and pure NOT NULL clause is used. Which means that the cosntraint will have generated (SYS_*) name, which in turn will cause freshly installed and upgraded schemas to differ, making the validation hard(er) and more error-prone. Please do not remove those names. Isn't chameleon's optimizer supposed to do just that in build time? I can see that you've renamed tables/Makefile.deps to tables/tables.deps while also changing the indentation and introducing some extra trailing spaces. Again, it makes it very hard to see what has happened. I propose reverting the rename and/or doing the rename in master in one commit, and then the indentation in another commit, so that diff among the branches is possible. Shouldn't we be able to generate the dependency tree of tables automatically and render the tables/tables.deps file obsolete? With triggers removed from tables' DDL files, parsing the foreign key definitions shouldn't be that hard. Why is content file rhnArchTypeActions.sql duplicated both in oracle/data and in postgres/data when the file itself is the same? Why is it not in common/data? The file rhnBlacklistObsoletes.sql has the same problem. The rest of the files in oracle/data seems to only differ from the postgres content in the sequence's nextval syntax. Yet, many files in common/data have the Oracle syntax just fine, and looking at chameleon's code, this should again be a build time issue. I assume you want to review the database-specific data directories and put most of the cotnent back to common/data. -- Jan Pazdziora Senior Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] pgsql review
On Tue, May 12, 2009 at 12:42:32PM -0400, Jeff Ortel wrote: - Upgrades (upgrade/* directories files): - Most files (git) moved to common/upgrade/upgrade - Few files forked: (git) moved to oracle/upgrade/upgrade. - Few files forked: copied to postgres/upgrade/upgrade and ported to PG. There does not seem to be anything changed there, apart from the Makefile. Please put the files to common/upgrade if no changes are needed / intended. - Upgrade scripts containing updated things created as CREATE OR REPLACE like views procs and packages updated replacing cut-n-paste content that is redundant with install files with an include to the install (.sql) file. See examples in git tree. - So far, git only has 0.4 - 0.5 (example) upgrade scripts, rest to follow. For the view, function and package definition, I'd very much like to see us move towards specifying file (we will hopefully get rid of the symlinks) which should be executed, rather than duplicating the content in the upgrade directories. -- Jan Pazdziora Senior Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] pgsql review
On Tue, May 12, 2009 at 12:42:32PM -0400, Jeff Ortel wrote: MAKEFILES The Makefile.schema refactored into a /regular/ makefile. Dependency sorting and .sql file aggregation split out into a build tool named blend. Although, make does do dependency sorting with the .deps files, the Makefile.schema (although, a clever application of the technology) seems to exceed make's intended use and was difficult to maintain and debug. Blend also provides analysis of .deps files and reports unused rules, unfound references, duplicate files and circular dependencies. Anyway, if someone really believes we should go back to using make for this, I suppose we can. I'm confused. What does blend really do and how does it fit into the build chain? There still seem to be files like ./oracle/views/views.deps ./oracle/tables/tables.deps ./oracle/packages/packages.deps What are they for? And they generated? If they are, why do we have them in our sources in the first place? If they are not geenrated, what does blend really do what make could not? I wonder if we should (again, independently from the PostgreSQL port effort) focus on making the dependency resolution more automatic, rather than rewrite working thing with another thing. The types can be collated mostly automatically -- tables before triggers, types before tables, functions before triggers but after tables, etc. For the procedural code, we can recompile the whole schema anyway. For tables, we could generate the the graph / Makefile just by grepping the source code. For other types, I wonder if we could put the dependency information to the start of the SQL file, something like -- Copyright (c) 2008 Red Hat, Inc. -- -- This software is licensed to you under the GNU General Public License, -- [...] -- Requires: procs/lookup_cf_state create or replace function lookup_first_matching_cf ( [...] By having the dependency spelled out in the source code where the object is defined rather than in some separate long file, we would make it easier to maintain and keep up-to-date. I'd consider this a higher priority than any decision about make replacement. Maybe, when we do something about the dependencies in general, we will find out that any issues you might have hit with make are either gone or much more manageable. -- Jan Pazdziora Senior Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] pgsql review
On Tue, May 12, 2009 at 12:42:32PM -0400, Jeff Ortel wrote: PACKAGING The spacewalk-schema.spec was updated to package and install install / upgrade scripts for both oracle and postgres. The files are installed in: /etc/sysconif/rhn/oracle/ main.sql spacewalk_0.4-spacewalk_0.5.sql ... /etc/sysconif/rhn/postgres/ main.sql spacewalk_0.4-spacewalk_0.5.sql ... As you can see, the upgrade scripts are aggregated using blend just like the install scripts. Spacewalk::Setup and the spacewalk-schema-upgrade scripts need to be updated to support the new directory structure and files names. This work has been started but still needs more work. ** Milan, can you help with changes to spacewalk-schema-upgrade? Also, anyone know what the links are for in the upgrade directories? Do we need them? Can they be created during RPM install? You cannot aggregate upgrade scripts because other products (like Satellite) might want to address individual upgrade scripts (via symlinks, or, work-in-progress, via references). There is a reason we kept the upgrade scripts separated. As a matter of fact, I think that if would be good to have the main schema definition (universe.satellite.sql, or main.sql) split into individual source files as well -- basically just pack the source files and concatenate them at install time. The reason is that it would make schema overrides by Satellite schema package easier, and upgrade scripts could just reference file name of new package or function, rather than having the source code duplicated and potentially out of sync. So here I feel the move has been in the wrong direction. -- Jan Pazdziora Senior Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Why rhn-client-tools requires yum-rhn-plugin?
On Thu, May 14, 2009 at 10:50:11AM -0400, Pradeep Kilambi wrote: cdn support. If you use yum-rhn-plugin 0.5.3-30 with latest version of rhn-client tools it will break the multiarch support. If you use latest yum-rhn-plugin with older rhn-client-tools it will break cdn and versioning thats being sent across. Aha, so it is not requires, but rather conflicts with older versions. So should be more correct to put inside rhn-client-tools.spec instead of: Requires: yum-rhn-plugin = 0.5.3-30 this line: Conflicts: yum-rhn-plugin 0.5.3-30 ??? I'm not sure about yum-rhn-plugin.spec since I did not check its code and dunno if there should be conflict as well or if the code is really required. Its not a conflict. We should force users using latest yum-rhnplugin to get newer rhn-client-tools and vice-versa. So requires as we have should do it. Prad, if the user does have yum-rhnplugin but not rhn-client-tools, will yum-rhnplugin work? If it won't then it's Requires case. If it will work without rhn-client-tools or with new rhn-client-tools but not with old rhn-client-tools, it's Conflicts. And vice versa -- for does rhn-client-tools need yum-rhnplugin to work? -- Jan Pazdziora Senior Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] pgsql review
On Thu, May 14, 2009 at 03:18:25PM -0400, Jeff Ortel wrote: You cannot aggregate upgrade scripts because other products (like Satellite) might want to address individual upgrade scripts (via symlinks, or, work-in-progress, via references). There is a reason we kept the upgrade scripts separated. Can't this be handled at build time? No. You don't know what content is in the latest spacewalk-schema package when you build satellite-schema package, and vice versa. As a matter of fact, I think that if would be good to have the main schema definition (universe.satellite.sql, or main.sql) split into individual source files as well -- basically just pack the source files and concatenate them at install time. What is known at install time that is not known at build time? Files brought in by other packages and files needed by other packages, from other projects (Satellite, namely). -- Jan Pazdziora | adelton at #satellite*, #brno Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Re: Proposed commit hook to catch suspicious merge commits
On Tue, May 12, 2009 at 09:32:18AM -0300, Devan Goodwin wrote:
On Thu, Mar 12, 2009 at 09:33:44AM -0300, Devan Goodwin wrote:
Works for me. Yeah I'd be in favor of the commit hook.
My first attempt at the hook which would catch commits that seems to
be automatic merges done during git pull is in the attachment.
I did a merge master to pgsql merge yesterday, I used the default
commit msg at first and this was rejected by your script. I did a git
commit --amend and changed the message to not match the regex:
if ($msg =~ /^Merge branch \S+ of \S+\n*$/s) {
}
But I still get:
$ git push origin pgsql
Counting objects: 204, done.
Compressing objects: 100% (68/68), done.
Writing objects: 100% (74/74), 8.92 KiB, done.
Total 74 (delta 61), reused 0 (delta 0)
Commit [d1c65b572d1b9e1ccd863cce3104a853acc9ad9f] looks like automatic
merge when you did not rebase after pull.
To ssh://dgood...@git.fedorahosted.org/git/spacewalk.git
error: hooks/pre-receive exited with error code 1
! [remote rejected] pgsql - pgsql (pre-receive hook declined)
error: failed to push some refs to
'ssh://dgood...@git.fedorahosted.org/git/spacewalk.git'
The commit it's complaining about is not my most recent:
The hook checks all commits that are being added to the ref since
you can do multiple commits (and multiple merge commits) with one
push.
$ git show d1c65b572d1b9e1ccd863cce3104a853acc9ad9f
commit d1c65b572d1b9e1ccd863cce3104a853acc9ad9f
Merge: ef29cde... 1e0d837...
Author: Jan Pazdziora jpazdzi...@redhat.com
Date: Tue Apr 21 10:39:27 2009 +0200
Merge branch 'master' of ssh://git.fedorahosted.org/git/spacewalk
Jan, is there something I can do to edit that message and get this push
to work?
The one of d1c65b572d1b9e1ccd863cce3104a853acc9ad9f? Nope. The best
bet will probably be to ask the infrastructure guys to disable the
hook, do the push, and enable it again. Upon subsequent pushes, the
commit will already not be considered by the hook.
--
Jan Pazdziora
Senior Software Engineer, Satellite Engineering, Red Hat
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] something didn't get pushed or commited
On Wed, May 06, 2009 at 11:16:25PM -0400, Jesus M. Rodriguez wrote: trying to tag spacewalk-proxy-monitoring.spec I noticed the version was 0.6.4 but it stated it was 'Not committed yet' http://pastebin.com/m623f41b9 Not sure what's going on here. Not committed yet means that you have some local change (0.6.2 - 0.6.4, I assume) in your working copy. -- Jan Pazdziora Senior Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Re: something funky is going on with building/tagging
On Thu, May 07, 2009 at 09:42:16AM -0300, Devan Goodwin wrote: Author: Jan Pazdziora jpazdzi...@redhat.com AuthorDate: Tue May 5 17:22:32 2009 +0200 Commit: Jan Pazdziora jpazdzi...@redhat.com CommitDate: Tue May 5 17:22:32 2009 +0200 Automatic commit of package [spacewalk-monitoring-selinux] release [0.6.4-1]. I think it's just a missing git push --tags, the tag doesn't seem to be there. This is breaking in the new auto-changelog stuff so if you ever hit something like this you can just use --no-auto-changelog until we get it fixed up. Ah, sorry about that. Pushed now. -- Jan Pazdziora Senior Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Channel Name Length
On Thu, May 07, 2009 at 09:07:13AM -0400, Jason Dobies wrote: Before we open up this can of worms again look at this bug: https://bugzilla.redhat.com/show_bug.cgi?id=459827 (sorry private bug) jesus Increasing the length of the column probably isn't the right solution. Is there more to it than that (referring to the can of worms comment, I'm guessing there was a non-documented debate)? I'm not seeing a real reason why increasing the name to match the label size is a bad idea. This has come up twice in BZs now and I just saw it on the satellite mailing list as well. Isn't the main problem here the fact that whatever limit you chose, if the original channel is at or near the limit, the cloned one will be over limit? So the real fix is to - match the textfield length in the WebUI to the column width, whatever that one is; - if the generated name would end up longer, truncate it in such a way that the name is still unique; - when handling the form, verify that the data is indeed shorter or equal the column width. -- Jan Pazdziora Senior Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Changes to 'refs/tags/oracle-instantclient-selinux-10.2-10' (fwd)
On Wed, Apr 29, 2009 at 02:03:47PM -0400, Joshua Roys wrote: In man git-describe: EXAMPLES With something like git.git current tree, I get: [torva...@g5 git]$ git describe parent v1.0.4-14-g2414721 i.e. the current head of my parent branch is based on v1.0.4, but since it has a few commits on top of that, describe has added the number of additional commits (14) and an abbreviated object name for the commit itself (2414721) at the end. Oh, and the solution is right in the manpage too. Use --abbrev=0. Joshua, thanks a lot for looking into this. For out purposes, the git rev-list is not useful anyway, so I filed https://fedorahosted.org/fedora-infrastructure/ticket/1362 to get that part removed. -- Jan Pazdziora Senior Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] MySQL porting info
On Mon, Apr 27, 2009 at 03:13:09PM +0200, Matej Hasul wrote:
Hello, I started working on migrating tables to mysql.
Data types conversion looks like this:
varchar2 - varchar
number - numeric
date - timestamp
Following problems emerged:
1. Mysql doesn`t support user defined data type. So I have no idea what to
do with evr_t.
Please check what the deal with evr_t in PostgreSQL port was. IIRC,
the type is used for collation and presentation, so you should be able
to replace it with plain table and a couple of functions.
2. Mysql doesn`t support nested tables. For example something like create
or replace type channel_name_t as table of varchar(64). Does anyone know
some workaround?
Check if that type is needed at all. Looking around the source code,
it is only used in the channel_name_join function, and that one does
not seem to be called anywhere. So it both looks like a dead code to
me, which should be removed from the Oracle schema as well.
3. Check constraint not working. According to mysql documentation - The
CHECK clause is parsed but ignored by all storage engines.
Workaround: Use before-insert-or-update trigger to implement check
constraint.
OK.
4. Create table test(date1 date default (sysdate), date2 date default
(sysdate)) will not work in mysql, because there can be only one date column
with default clause.
Workaround: Use before-insert-or-update trigger to set actual date(s).
OK.
5. Missing sequence in mysql.
Workaround: One option is to use AUTO_INCREMENT and LAST_INSERT_ID().
Another option is to create table holding sequence number and create
procedures curval('seq_name') and nextval('seq_name').
With the table-holding-sequence-values approach (and I'm not sure
about the first one), keep in mind that it will be
transaction-aware -- if you rollback, you will get the same value next
time. That might or might not be a problem. Also, for the same reason,
the sessions will likely serialize on that table.
--
Jan Pazdziora
Senior Software Engineer, Satellite Engineering, Red Hat
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] MySQL porting info
On Tue, Apr 28, 2009 at 10:10:01AM -0400, Tom Lane wrote: The usual experience AFAIR is that the queries have to be dumbed down to the point that they no longer perform well on Oracle (or Postgres), because of mysql's crummy optimizer and lack of support for advanced join strategies. A lot of the Spacewalk code is now Java/Hibernate, so the queries are actually not that complex. -- Jan Pazdziora Senior Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Proposed commit hook to catch suspicious merge commits
On Thu, Apr 16, 2009 at 09:51:33AM +0200, Jan Pazdziora wrote: Since there were no objections, I assume people have tested the code and are OK with it. I'm about to drop an email to fedora-infrastructure -- please shout now if you do not want to see that commit hook on Spacewalk upstream repository. For your information -- the hook was activated on Spacewalk git repository at ssh://git.fedorahosted.org/git/spacewalk.git/ now. If you try to push a commit which is a merge and has a commit message which looks like an automatic merge, you will get an error like this: $ git push Counting objects: 12, done. Compressing objects: 100% (7/7), done. Writing objects: 100% (7/7), 763 bytes, done. Total 7 (delta 5), reused 0 (delta 0) Commit [22709bf42f9effdc4dcc3acc31eb95c2952e3386] looks like automatic merge when you did not rebase after pull. To ssh://git.fedorahosted.org/git/spacewalk.git/ ! [remote rejected] master - master (pre-receive hook declined) error: hooks/pre-receive exited with error code 1 error: failed to push some refs to 'ssh://git.fedorahosted.org/git/spacewalk.git/' In other words: if you see this error, it's because you are try to to push merge without rebase. The fix is to rebase: $ git rebase origin/master First, rewinding head to replay your work on top of it... Applying: spacewalk-selinux: amend %changelog. ... review the result with $ gitk --all ... and if you are happy with the result, push: $ git push Counting objects: 9, done. Compressing objects: 100% (5/5), done. Writing objects: 100% (5/5), 481 bytes, done. Total 5 (delta 4), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/spacewalk.git/ 15122b3..81ee3ac master - master $ -- Jan Pazdziora Senior Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Proposed commit hook to catch suspicious merge commits
On Thu, Apr 02, 2009 at 10:54:21AM +0200, Jan Pazdziora wrote: On Thu, Mar 12, 2009 at 09:33:44AM -0300, Devan Goodwin wrote: Works for me. Yeah I'd be in favor of the commit hook. My first attempt at the hook which would catch commits that seems to be automatic merges done during git pull is in the attachment. Since there were no objections, I assume people have tested the code and are OK with it. I'm about to drop an email to fedora-infrastructure -- please shout now if you do not want to see that commit hook on Spacewalk upstream repository. -- Jan Pazdziora Senior Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Commits should reference public bugzillas
On Wed, Apr 08, 2009 at 11:03:02AM +0200, Jan Pazdziora wrote: Hello, if you like me in the past committed a fix to Spacewalk repo Note! If you've for some reason parsed my previous email in such a way that it made you think the commit hook is in the repo on fedorahosted.org so you are automatically covered while running git push, please re-read that previous email. Thank you, -- Jan Pazdziora Senior Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Commits should reference public bugzillas
Hello,
if you like me in the past committed a fix to Spacewalk repo
referencing bugzilla which is not public, you might find the following
code useful. Just add it to .git/hooks/commit-msg and do
chmod a+x .git/hooks/commit-msg.
bugzilla_id=$( perl -lne 'if (/^(\d+) -/) { print $1 } exit' $1)
if [ -n $bugzilla_id ] ; then
if GET
https://bugzilla.redhat.com/show_bug.cgi?id=$bugzilla_idctype=xml; | grep -q
'bug error=NotPermitted' ; then
echo Bugzilla [$bugzilla_id] does not seem to be public.
Aborting.
exit 1
fi
fi
--
Jan Pazdziora
Senior Software Engineer, Satellite Engineering, Red Hat
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] fatal: ambiguous argument when pushing tags to Spacewalk repo
Hello, when running git push --tags, I seem to be getting some errors about spacewalk-java-0.6.1-1-11. What's strange there is that spacewalk-java-0.6.1-1-11 does not even look like a valid tag name: $ git push --tags Counting objects: 1, done. Writing objects: 100% (1/1), 217 bytes, done. Total 1 (delta 0), reused 0 (delta 0) fatal: ambiguous argument 'spacewalk-java-0.6.1-1-11..2b31b47d57bd0024deb6a7097f1388e3fa0e13ee': unknown revision or path not in the working tree. Use '--' to separate paths from revisions To ssh://git.fedorahosted.org/git/spacewalk.git/ fatal: ambiguous argument 'spacewalk-java-0.6.1-1-11..2b31b47d57bd0024deb6a7097f1388e3fa0e13ee': unknown revision or path not in the working tree. Use '--' to separate paths from revisions * [new tag] rhnpush-5.3.0-1 - rhnpush-5.3.0-1 Does anyone know what's going on there with the Spacewalk git repository? -- Jan Pazdziora Senior Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Proposed commit hook to catch suspicious merge commits
On Thu, Mar 12, 2009 at 09:33:44AM -0300, Devan Goodwin wrote:
Works for me. Yeah I'd be in favor of the commit hook.
My first attempt at the hook which would catch commits that seems to
be automatic merges done during git pull is in the attachment.
--
Jan Pazdziora
Senior Software Engineer, Satellite Engineering, Red Hat
#!/bin/bash
while read old_sha1 new_sha1 refname ; do
# echo stdin: [$old_sha1] [$new_sha1] [$refname]
git rev-list --parents $old_sha1..$new_sha1 \
| while read sha1 parents ; do
# echo commit: [$sha1] [$parents]
if [ ${parents/ /} != $parents ] ; then
# echo- merge
if ! ( git cat-file commit $sha1 \
| perl -e 'BEGIN { $/ = \n\n }
scalar();
my $msg = ;
if ($msg =~ /^Merge branch \S+
of \S+\n*$/s) {
exit 1
}' ) ; then
echo Commit [$sha1] looks like
automatic merge when you did not rebase after pull.
exit 1
fi
fi
done
[ $? -ne 0 ] exit 1
:
done
exit $?
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Certificate Generation
On Thu, Apr 02, 2009 at 12:53:39PM +0100, Rob James wrote: Wierd, I'm sure it gave an error about not being able to find libraries first time round but I've just retried and I don't get any error. Apologies for the confusion. It's probably the oracle-lib-compat which is in the Install section now which fixes the problem. -- Jan Pazdziora Senior Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Please submit spacewalk-repo packages to Spacewalk 0.5 yum repos
Hello, it looks like the spacewalk-repo packages were never updated from 0.4 to 0.5. I've now bumped up the version there, updated paths to point to what is now used on spacewalk.redhat.com/yum, and built new packages. Please upload spacewalk-repo-0.5-2.el5.noarch.rpm spacewalk-repo-0.5-2.fc10.noarch.rpm to spacewalk.redhat.com/yum. Thank you, -- Jan Pazdziora Senior Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] spacewalk-commits
On Thu, Apr 02, 2009 at 08:57:15AM +0200, Jan Pazdziora wrote: On Mon, Mar 30, 2009 at 01:59:09PM -0300, Devan Goodwin wrote: Hypothetically if we could figure out a way to get it down to one email per commit, with the subject being the *first* line of the commit message, would people be in favor of this? Yes, I'd appreciate one email per commit. Also, for this particular mailing list, I would actually appreciate if the emails had the [spacewalk-commits] indicator prefixed on their Subjects. -- Jan Pazdziora | adelton at #satellite*, #brno Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] 0.5 State of the Union
On Thu, Mar 26, 2009 at 09:32:44PM -0400, Jesus M. Rodriguez wrote: Jan please look at this bug: https://bugzilla.redhat.com/show_bug.cgi?id=492194 After long investigation, I've filed bugzilla 492378 for that. I'll try to find a way to work around the problem tomorrow. Ok that would be great. Done. I've built spacewalk-setup-0.5.27-1.fc10.noarch.rpm, please give it a try. -- Jan Pazdziora Senior Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] fix Source0 to point to fedorahosted.org
On Mon, Mar 16, 2009 at 02:51:38AM +, jmrodri wrote: I've seen a few of these, what does this do? jesus Sent to you by jmrodri via Google Reader: fix Source0 to point to fedorahosted.org via Fedora Hosted Git Repositories - spacewalk.git/rss log by Miroslav Suchý msu...@redhat.com on 3/13/09 fix Source0 to point to fedorahosted.org - [DH] spacewalk/certs-tools/spacewalk-certs-tools.spec Things you can do from here: - Subscribe to Fedora Hosted Git Repositories - spacewalk.git/rss log using Google Reader - Get started using Google Reader to easily keep up with all your favorite sites https://fedoraproject.org/wiki/Packaging/SourceURL The most common case is where upstream distributes source as a tar.gz, tar.bz2 or zip archive that we can download from an upstream website. In these cases you must use a full URL to the package in the SourceX: line. -- Jan Pazdziora Senior Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] fix bootstrap scripts to retrieve server cert using SSL
On Fri, Mar 13, 2009 at 09:33:36AM -0400, Joshua Roys wrote: Hello all, My sense of paranoia tells me this should be https. Will the https work, without certificates available on the client? -- Jan Pazdziora Senior Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Re: Merge branch 'master' of ssh://jlsherr...@git.fedorahosted.org/git/spacewalk
On Thu, Mar 12, 2009 at 07:27:19AM +0100, Jan Pazdziora wrote: On Wed, Mar 11, 2009 at 08:09:49PM -0700, Mike McCune wrote: http://git.fedorahosted.org/git/?p=spacewalk.git;a=commitdiff;h=6c1be4e0cc992afb834e8fedf7c3094746466ba4 'git pull --rebase' next time? It should be possible to do a post commit hook to refuse commits which introduce merges that have the default commit message (= likely not intended merge). Is this something we might want to try setting up? We should also be able to try to enforce the ^((\d+)\s-\s)? format for bugzilla numbers. -- Jan Pazdziora | adelton at #satellite*, #brno Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Re: Merge branch 'master' of ssh://jlsherr...@git.fedorahosted.org/git/spacewalk
On Thu, Mar 12, 2009 at 09:17:34AM -0300, Devan Goodwin wrote: Would like too, only reason not too I can think of is if you'd done some package tagging and intentionally done a pull without --rebase so as not to have to redo it. In that case you probably should --amend the commit to say why you did that merge. In which case the regexp will no longer match and you'll be OK. -- Jan Pazdziora Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Installation problems on the horizon (when jabberd-2.2.5 hits EPEL)
On Wed, Mar 04, 2009 at 03:28:59PM +0100, Milan Zazrivec wrote: Currently in Spacewalk we build and ship our own version of jabberd (jabberd-2.0). EPEL-5 testing currently contains jabberd-2.2.5-1, which does following in its %post: ... #create ssl certificate cd /etc/jabberd if [ ! -e server.pem ]; then /bin/sh /etc/pki/tls/certs/make-dummy-cert server.pem /bin/chown root.jabber server.pem /bin/chmod 640 server.pem fi So the new jabberd generates /etc/jabberd/server.pem which will conflict with certificate generated by rhn-ssl-tool (spacewalk-certs-tools) and the installation fails. Not a problem now, but it'll become an issue once the new jabberd hits EPEL-5. Any idea how to deal with this? Why will it conflict with certificate generated by spacewalk-certs-tools? That package does not own /etc/jabberd/server.pem, does it? -- Jan Pazdziora Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Change needed to Oracle Instructions
On Sat, Feb 28, 2009 at 02:25:55PM -0500, Travis Camechis wrote: I believe the instructions for setting up the oracle user env need to be moved. Currently it exists under the alternate web setup but I believe this needs to be done before you create the spacewalk user ( SQL method ). I I've tried the approach without having anything in ~oracle/.bash_profile, connecting to the Oracle XE server via sqlplus 'sys/password@//localhost:1521/xe as sysdba' and it seemed to work just fine. What issues do you hit with this approach? -- Jan Pazdziora | adelton at #satellite*, #brno Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] F10 Spacewalk Progress
On Sun, Feb 22, 2009 at 11:34:15PM -0400, Devan Goodwin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Staring at Spacewalk UI running on F10 right now! 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? -- Jan Pazdziora Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Automating Oracle-xe Setup
On Tue, Feb 24, 2009 at 11:48:36AM -0800, Mike McCune wrote: su - oracle -c 'sqlplus / as sysdba' EOS 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 we should consider adding the user creation steps to spacewalk-setup Do you mean spacewalk-setup the package, or spacewalk-setup the file in /usr/bin? The file in /usr/bin :) That's what I feared. Ideally, spacewalk-setup (the file, and the Spacewalk/Setup.pm) should how have anything embedded database or XE specific. That spacewalk-setup should receive connect string to use, and that connect string should point to a working, setup database user account. We could do something like oracle-xe-utils or spacewalk-oracle-xe (package) to hold any helper scripts. But we should aim at removing even the last embedded db bits away from spacewalk-setup, not add new ones. I've added the create user spacewalk SQL to https://fedorahosted.org/spacewalk/wiki/OracleXeSetup and I'm actually considering removing the part about http://127.0.0.1:9000/apex from that page, so the list of steps that you need to do on Oracle XE prior to running spacewalk-setup should get pretty short. -- Jan Pazdziora Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Automating Oracle-xe Setup
On Wed, Feb 18, 2009 at 11:30:30AM -0800, Mike McCune wrote: % And the creation of the spacewalk user / permissions? su - oracle -c 'sqlplus / as sysdba' EOS 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 we should consider adding the user creation steps to spacewalk-setup Do you mean spacewalk-setup the package, or spacewalk-setup the file in /usr/bin? -- Jan Pazdziora Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] build.py: CLI Changes Coming Soon
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? - - 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? - - 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? 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. -- Jan Pazdziora Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PGPORT: Another porting request.
On Mon, Feb 02, 2009 at 09:30:17PM -0400, Devan Goodwin wrote: 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? It looks like nvl is in Orafce. -- Jan Pazdziora | adelton at #satellite*, #brno Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
