-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 4 Mar 2009 15:53:11 +0530
Gurjeet Singh gurjeet.si...@enterprisedb.com wrote:
Hi Devan,
In rhnSsmOperation.sql column user_id references rhnUser(id).
rhnUser table does not exist in Postgres port.
A little digging shows that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 04 Mar 2009 14:30:39 +0530
tushar tushar...@gmail.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In addition to that, this link
http://www.postgresql.org/docs/8.3/static/release-8-3.html would be
helpful.
Thanks for the
Hi I am new here.
I found this thread in archive[1], but I still has one doubt.
In case of Debian Packages, the Spacewalk will update its packages with
Repository of Debian?
[1] -
https://www.redhat.com/archives/spacewalk-devel/2009-January/msg00131.html
Rafael Gomes
Consultor em TI
Embaixador
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 4 Mar 2009 15:28:59 +0100
Milan Zazrivec mzazri...@redhat.com 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
Rafael Gomes wrote:
Current goal is very simple: let allow Debian system register to
Spacewalk - nothing more.
Sorry, but I didn't understand. Can you please explain me more?
Basicaly that rhn_register succeed. And Spacewalk will have record about
this client machine (set of
Karanbir Singh wrote:
Brandon Perkins wrote:
That's a fine point. So, I have RHEL, but don't have CentOS, so the
things I authoritatively know we deal with (many of these may already be
in CentOS):
Thanks for the list, I'll also look at Michael's repo and see what needs
adding. Anyone
Karanbir Singh wrote:
Brandon Perkins wrote:
That's a fine point. So, I have RHEL, but don't have CentOS, so the
things I authoritatively know we deal with (many of these may already be
in CentOS):
Thanks for the list, I'll also look at Michael's repo and see what needs
adding. Anyone
Do we 'really' need constants for EVERY configuration entry? I know it
makes a bit easier to use auto-completion in the IDE, but
it seems a bit redundant to modify a Config reader class every time.
And personally I really dislike the indirection, I always end
up with 2 greps one for the config
TestObjectStore? So this is to avoid the fact that every test has a new
setUp run before it?
Why didn't we do it the same as we did with AdvDataSourceTest?
public static Test suite()
throws Exception {
TestSuite suite = new TestSuite(AdvDataSourceTest.class);
TestSetup wrapper = new
just a heads up, I accidentally did a 'git push --all' (not sure why i
typed --all).
Looks like it pushed a bunch of my local junk:
* [new branch] 482779 - 482779
* [new branch] 482879 - 482879
* [new branch] b481767 - b481767
* [new branch] checkstyle - checkstyle
*
jmrodri wrote:
Do we 'really' need constants for EVERY configuration entry? I know it
makes a bit easier to use auto-completion in the IDE, but
it seems a bit redundant to modify a Config reader class every time. And
personally I really dislike the indirection, I always end
up with 2 greps
I'll leave it to mccune or paji for a more detailed explanation... but
the purpose as i understand it is to store cobbler values for the Mock
connection to simulate cobbler.
Although I *think* this will be changing soon, as the current
MockConnection/TestObjectStore doesn't handle all of our
12 matches
Mail list logo