Re: [Spacewalk-devel] Replace default page in proxy (patch)

[Miroslav Suchý]

Rob James wrote:

I've added a patch to
https://bugzilla.redhat.com/show_bug.cgi?id=457046 to change the RH
artwork in Proxy to Spacewalk versions. There's a couple of
screenshots in the bug to show the changes.

I applied it yesterday, thx.
--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Status of Monitoring in 0.2

[Miroslav Suchý]

Jesus M. Rodriguez wrote:

Mike McCune wrote:
I'm thinking we need to drop support for Monitoring in 0.2.  There are 

+1 it definitely need major clean up


Sigh. It's way too late in the game to fix all of this in
0.2. We're already late :) I know Mirek has >100 commits in
a monitoring branch that seem to fix a lot of these. Let's
see if we can get monitoring working properly in Spacewalk 0.3.


I already merged the monitoring branch with master and will continue 
working on monitoring there.


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Spacewalk Proxy Missing RPM

[Miroslav Suchý]

Rob James wrote:

Thanks Miroslav. I've attached a patch which fixes some of the issues
I ran into running configure-proxy.sh - hopefully it's in the right
format (first time using git!).

Patch applied, with some minor correction.


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] init script exit code (patch)

[Miroslav Suchý]

Rob James wrote:

Added a patch at https://bugzilla.redhat.com/show_bug.cgi?id=461747 to
fix up the exit code from the rhn-proxy init script (ran into it when
trying to check rhn-proxy status in a script). Also does a couple of
other minor tidy ups noted in the bug.


Thx, will review and apply tommorow.

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Re: Spacewalk 0.3 tags in brew

[Miroslav Suchý]

Dennis Gilmore wrote:

On Friday 05 September 2008 02:24:25 am Jan Pazdziora wrote:

Dennis,

could you create spacewalk-[45]E-0.3* tags in brew, with the similar
structure to spacewalk-[45]E-0.2*, but inheritting from
spacewalk-[45]E-0.2*?


Do not CC me directly on list mail.  and if you need to send me email on 
anything open source don't  use the @redhat.com address  use either 
@fedoraproject.org or @ausil.us.  either is fine.  


We need it build for rhel to do QA for Satellite 5.3.

Secondly for 0.3 I would rather see us layer on top of EPEL. Its something 
that will need doing at some point.  lets start now.  which means we will need 
to use our koji until we can drop oracle for postgres  and get spacewalk in 
Fedora and EPEL


Our packages are not in state of be accepted in Fedora (and therefore 
build in EPEL). With current speed we are 3 year far from this goal.


Of course I encourage you and other to work on it:
https://fedorahosted.org/spacewalk/wiki/GettingPackagesIntoFedora

So until we are part of Fedora, please provide us either working 
instance of Koji for RHEL/Centos or create that tags in Brew.

I think the last one is easiest, but it is up to you.
--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

[Spacewalk-devel] [Fwd: [engineering.redhat.com #28123] new tags for spacewalk 0.3 please]

[Miroslav Suchý]

FYI

 Original Message 
Subject: [engineering.redhat.com #28123] new tags for spacewalk 0.3 please
Date: Thu, 11 Sep 2008 09:08:31 -0400
From: nick petrov via RT <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
References: <[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>


Ticket https://engineering.redhat.com/rt3/Ticket/Display.html?id=28123 >



[EMAIL PROTECTED] - Thu Sep 11 08:32:03 2008]:

Could you please create spacewalk-[45]E-0.3* tags in brew, with the 
similar structure to spacewalk-[45]E-0.2*, but inheritting from

  spacewalk-[45]E-0.2*?

Thx


tags created.


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] perl-Satcon is present in git twice

[Miroslav Suchý]

Milan Zazrivec wrote:

Seemingly the version that got into spacewalk 0.2 is the one comming
from projects/perl-Satcon (tag: perl-Satcon-1.3-11).

Not a big deal, but perhaps we could get rid one of them (to avoid
confusion).

What do other guys think?

Correct. Go ahead and delete spec-tree/perl/perl-Satcon.
That version is newer and have several files, which 
spec-tree/perl/perl-Satcon do not have.


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] schema doc

[Miroslav Suchý]

Jesus M. Rodriguez wrote:

Mirek,

How do I regenerate the Spacewalk schema doc:

http://www.redhat.com/spacewalk/documentation/db-schema/spacewalk-0.1/


in git: documentation/how-to-generate-documentation.txt

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

[Spacewalk-devel] Status of monitoring packages

[Miroslav Suchý]

I just today finished cleaning up monitoring packages:
spacewalk-proxy-monitoring
ConfigPusher-general
eventReceivers
NOCpulsePlugins
NPalert
nocpulse-common
perl-NOCpulse-CLAC
perl-NOCpulse-Debug
perl-NOCpulse-Gritch
perl-NOCpulse-Object
perl-NOCpulse-OracleDB
perl-NOCpulse-PersistentConnection
perl-NOCpulse-Probe
perl-NOCpulse-ProcessPool
perl-NOCpulse-Scheduler
perl-NOCpulse-SetID
perl-NOCpulse-Utils
ssl_bridge
scdb
SNMPAlerts
SatConfig-bootstrap
SatConfig-bootstrap-server
SatConfig-cluster
SatConfig-dbsynch
SatConfig-general
SatConfig-generator
SatConfig-installer
SatConfig-spread
SputLite-client
SputLite-server
status_log_acceptor
tsdb
ProgAGoGo
NPalert
MessageQueue
oracle_perl  -- renamed to nocpulse-db-perl
nslogs -- removed logrotate is defined in nocpulse-common

I did:
- getting rid of /opt/nocpulse and /opt/notification directories. If you 
are curious what went where, you can get good overview from sql upgrade 
script in schema definition, where are all changes together. But 
basically home dir of nocpulse is now /usr/lib/nocpulse. Configuration 
files are in /etc/nocpulse/ and logs are in /var/log/nocpulse.
- changes to Makefile, getting rid of source and version files, so 
packages can actually be built using current infrastructure.

- changes to comply with Fedora Guidelines. With those exceptions:
  ** most of packages are missing documentation. We can either write
 propper POD section in perl modules or just put in some simple
 README.
  ** some packages (especial SatConfig-*) have code in /etc/rc.d/
 I did not move it out. I thing I break enough things for now.
  ** sys.v init scripts need probably some care, to comply with Fedora.
 Again, I have no morale to break too much stuff.

Several packages are built. But most of them need to be rebuild - 
Dennis, can you rebuild them in Brew for RHEL (probably in 
spacewalk-5E-0.3-candidate) [1]? And for Fedora in Koji? Builds should 
be ok, I tested all packages using "make test-rpm," but if there will be 
some probleme just write me off-list.


When it will be done, I'll be glad for every kind of test. A lot of 
paths has been changes and it will be miracle if everything will work 
without problem. Most changes have been in packages tsdb and NPalert.


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Re: Status of monitoring packages

[Miroslav Suchý]

Dennis Gilmore wrote:

please don't CC me on list email


You were To: not CC: :) Sorry, this is how I (and others) works. To be 
sure that email will not get lost or ignored. Most people have list 
filtered to separate folders and read them occasionally.



On Monday 29 September 2008 10:28:14 am you wrote:

script in schema definition, where are all changes together. But
basically home dir of nocpulse is now /usr/lib/nocpulse. Configuration

this is wrong it should be /var/lib/nocpulse
Correct - I wrote it wrong. Home dir is now /var/lib/nocpulse. I'm sorry 
for confusion.



  Again, I have no morale to break too much stuff.
better to break things once and have it right than have to break things 
multiple times.


If I change too much things at once and then something will stop 
working, it is than much harder to detect which change introduced that bug.



Dennis, can you rebuild them in Brew for RHEL (probably in
spacewalk-5E-0.3-candidate) [1]? And for Fedora in Koji? Builds should
Nothing spacewalk should be built in brew.  it should all be done in koji. 


And we have functional Koji?

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

[Spacewalk-devel] version of API

[Miroslav Suchý]

In Spacewalk 0.2 the api call api.getVersion return string 0.2.
I think that is is bad and we should return to 5.something. Why?
Because some satellite scripts may check, if we have sufficient api 
version. Now those scripts have to be rewritten.
We can discuss what should be  something in 5.something, but we should 
definitely bump it up back.


I suggest to bump it to 5.2.0 and then separate the numbering from 
numbering of satellite or spacewalk and with every change to api simple 
bump up the release part of api version number.


Please raise your voice now.
--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] version of API

[Miroslav Suchý]

Jesus M. Rodriguez wrote:

On Tue, Sep 30, 2008 at 11:38 AM, Miroslav Suchý <[EMAIL PROTECTED]> wrote:

In Spacewalk 0.2 the api call api.getVersion return string 0.2.
I think that is is bad and we should return to 5.something. Why?
Because some satellite scripts may check, if we have sufficient api version.
Now those scripts have to be rewritten.

The api returns the value from rhn.conf if the version in rhn.conf is
0.2, that's what it returns. That same value is used to display in the
webui.

So what problem are we fixing? did this break anyone? or just
potential for breakage.


It was used in rhn-proxy-activate. The API, which proxy need changed 
between 3.0 and 3.1 and there was check if api > 3.0. We had at least 
one case. I just removed that check since nobody has 3.0 or older.


So now it is potential for breakage. But not just for past written 
scripts. But in future. For example we recently change several 
namespaces in API and I can imagine, that people in future will check 
what version of API they have. And you really can not distinguish 
satellite from spacewalk.

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] s390x

[Miroslav Suchý]

[EMAIL PROTECTED] wrote:


Hi there

I have asked this question on the user list and got an answer, thanks 
for that. We would be happy to set up a build server to your 
specification on our Mainframe. There would be no ssh access (we are a 
bank). I have extensive distribution packaging knowledge and have 
contributed actively to 2 linux distros and been working with various 
Linux flavours for years, so happy and able to help getting it set up 
and building packages on a nightly build run for s390x.


Let me know what is required from a build server perspective, I guess it 
will be rhel4 as rhel5 is not supported as a server platform on s390x.


Satellite 5.2 will be supported on RHEL5 on s390x. So you may want to 
build it on both EL4 and EL5.


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] [PATCH] Make make test-rpm work for spacewalk-proxy-installer

[Miroslav Suchý]

Rob James wrote:

I had to make these couple of changes when I tried to build the
spacewalk-proxy-installer SRPM today. Could someone review?

Correct, I applied this patch.

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Removing spacewalk-proxy-tools package

[Miroslav Suchý]

Rob James wrote:

I was looking at doing a patch to remove the spacewalk-proxy-tools
package since it's fairly obsolete now but found that it's used for
upgrades - see https://bugzilla.redhat.com/show_bug.cgi?id=465947 for
the details. Does it look reasonable to merge all that stuff into the
installer package or is that going to cause problems for the RHN Proxy
product?

Yes, but not now.
https://bugzilla.redhat.com/show_bug.cgi?id=465947#c1


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

[Spacewalk-devel] Inter Spacewalk Sync (ISS)

[Miroslav Suchý]

I just merged ISS branch to master.

I'm going to write some white paper for this feature this week. But if 
you like to try ISS, here are general pointers


Are you curious what is ISS?
https://fedorahosted.org/spacewalk/wiki/InterSpacewalkServerSync

New configuration options are in:
/etc/rhn/default/rhn_server_iss.conf
/etc/rhn/default/rhn_server.conf

ISS is enabled by default, but since there is no allowed slaves, no one 
can sync from you by default.


in the first conf file you can set list of allowed slaves:
# Comma separated list of allowed iss slaves, like:
allowed_iss_slaves=slave1.domain.com,slave2.domain.com

This slaves than can sync from you. This slaves do not need to be 
registered to you satellite.


On your slave you can set value in /etc/rhn/default/rhn_server.conf to:
# Name of parent for ISS.
# # If left blank rhn_parent is taken by default.
# # This option can be overriden on satellite-sync command line.
iss_parent  =  master.domain.com

And then you can run satellite-sync on slave. Or you run:
satellite-sync --iss-parent=master.domain.com -l

By default satellite-sync import data do organization, which is stated 
in export. If you want to sync to different organization you can run:

satellite-sync --iss-parent=master.domain.com --orgid=42 -c rhel-i386-as-4

If you have question about ISS, you can ping prad or me.
--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Getting Packages Into Fedora

[Miroslav Suchý]

Dennis Gilmore wrote:

On Monday 13 October 2008 03:16:33 pm Miroslav Suchy wrote:

Here comes reminder:
https://fedorahosted.org/spacewalk/wiki/GettingPackagesIntoFedora

Please guys, pick up at least one package and go through Fedora Package
Review.

Guide:
http://fedoraproject.org/wiki/Package_Review_Process#Contributor

Feel free to ping me once you create BZ. I can give you review too.
or CC me on the bug,  if you need a sponsor and you do a good job of packaging 
i can sponsor you for packager.


Dennis can you please do review of:
https://bugzilla.redhat.com/show_bug.cgi?id=453111
It is there for long time and Lubomir do not respond. This package block 
all other nocpulse packages.



--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Getting Packages Into Fedora

[Miroslav Suchý]

Miroslav Suchý wrote:

Dennis can you please do review of:
https://bugzilla.redhat.com/show_bug.cgi?id=453111
It is there for long time and Lubomir do not respond. This package block 
all other nocpulse packages.


Err. I meant:
https://bugzilla.redhat.com/show_bug.cgi?id=453109

My other packages waiting for review:
https://bugzilla.redhat.com/show_bug.cgi?id=466879
https://bugzilla.redhat.com/show_bug.cgi?id=466777
https://bugzilla.redhat.com/show_bug.cgi?id=466953
https://bugzilla.redhat.com/show_bug.cgi?id=466906

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

[Spacewalk-devel] tar.gz files and nightly builds

[Miroslav Suchý]

It seems that we should provide tar.gz (see Original Message on bottom 
for Dennis reasoning). I disagree, but I'm not the one who do the review.


Dennis, can you provide us some tool for building tar.gz from our 
revision control? I suggest you to start with "make 
git-archive-to-tar-gz" target, which do the tar, but name it with 
current revision.


Additionaly - can we have some web space where we can put the tar.gz 
files? And if we can have nightly build somewhere too, it would be cool.


Mirek


 Original Message 
Subject: [Bug 453109] Review Request: nocpulse-common - Add NOCpulse 
users and includes common files for NOCpulse.

Date: Fri, 17 Oct 2008 02:32:01 -0400
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
References: <[EMAIL PROTECTED]>

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=453109





--- Comment #13 from Dennis Gilmore <[EMAIL PROTECTED]>  2008-10-17 
02:32:00 EDT ---
http://fedoraproject.org/wiki/Packaging/SourceURL#We_are_Upstream  says 
"There
is no public revision control system or publically released tarball for 
these

programs so there is no tarball to list"  there is a public revision control
system, and im saying there should be public tarballs.  this is 
something that
could be useful and useable by more than spacewalk.  spacewalk could 
also end

up in other distros. a traball should be provided.

otherwise it looks good.

--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You reported the bug.


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

[Spacewalk-devel] Re: tar.gz files and nightly builds

[Miroslav Suchý]

Dennis Gilmore wrote:
if this is a git snapshot then you have not named it correctly. 
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Snapshot_packages
you only need to provide tarballs for official releases.  which your 
packages look like.

https://fedoraproject.org/wiki/Packaging/SourceURL#Using_Revision_Control
when ive needed to ship straight from source control ive used a script 
and put that in the package.


It is not git snapshots (those are the .git.sha1). It is normal official 
package. But the question is if this version will be in Spacewalk 0.3? I 
do not know. And neither I, you or Fedora should care, 'cos fedora take 
package independently.


But I did not want or wanted to discuss this specific bug. I wanted to 
discuss tar.gz in general.



Note that you need to maintain the spec file in Fedora's cvs once its 
in. you can keep a copy in git  but you need to be aware that people 
might make modifications to the spec, at times.

I know.

On that note there is room on fedora hosted for tarballs.  but only 
officially released ones should go there.


What is officially? Every package I made is offically. I usually create 
several officially package.
Can you please tell me how can I put it on fedora hosted? I mean on 
daily bases.


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Where is rhnmd?

[Miroslav Suchý]

Miroslav Suchy wrote:
I can not find rhnmd package in git repo? 
Is there reason why it is not there? 
Unless somebody will object I'll import it from our old svn repo.


Imported to monitoring/rhnmd.
Although there is some strange errors during build. I'll try to solve it 
on Monday.


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

[Spacewalk-devel] Status of Fedora packages

[Miroslav Suchý]

11 packages are already in Fedora
3 packages are in review process
2 packages are waiting to be reviewed
14 packages are in prep (but for looong time)
163 packages waiting to be pushed for Fedora

Change we need. Join the Movement:
https://fedorahosted.org/spacewalk/wiki/GettingPackagesIntoFedora

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Re: tar.gz files and nightly builds

[Miroslav Suchý]

Dennis Gilmore wrote:
scp to fedorahosted.org:/srv/web/releases/s/p/spacewalk/they are available 
at https://fedorahosted.org/releases/s/p/spacewalk/  


scp nocpulse-common-2.0.6.tar.gz 
fedorahosted.org:/srv/web/releases/s/p/spacewalk/

scp yourfile-1.2.tar.gz scm.fedorahosted.org:$YOURPROJECT # No trailing /

So I tried:
scp nocpulse-common-2.0.6.tar.gz fedorahosted.org:spacewalk
nocpulse-common-2.0.6.tar.gz 
100% 6485 6.3KB/s   00:00


Perfect!
Odd think it goes to one dir. So there will be soon quite big mess. And 
I think that their FS will not like it.


you should only put tarballs there that have x.x.x releases  if its a git 
snapshot  that has the git hash as a release they should not go there.


Sure

I am going to ask you again. do not put me in the To or CC or BCC of email to 
mailing lists. 


Dennis, do not be angry. This is how everybody else works and why we 
have ReplyAll in mailing clients.
It is good protection in case you are not subscribed to mailing list. 
And such situation already happen at least once.


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Closed bugs

[Miroslav Suchý]

Jack Neely wrote:

I recently had a couple very old bugs closed.

 Bug 129178 -  Vetting System for Packages in RHN
 Bug 128680 -  RHN Needs User Hierarchy

Both of these are "closed due to inactivity" and have been open since
2004.  I'm really not sure how to react to this and I surely haven't


Just realign this bug to Satellite (or Spacewalk) and open it again.


Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Re: to and cc peeve :)

[Miroslav Suchý]

Dennis Gilmore wrote:

On Thursday 23 October 2008 09:48:37 am Jesus M. Rodriguez wrote:

I am going to ask you again. do not put me in the To or CC or BCC of
email to mailing lists.

Why does that annoy you so much? I don't think folks understand it
and have noticed you repeatedly asking about it. /me just curious

jesus
for one it messes up my filters.  since mailman doesn't send me a copy if i'm 
on the to, or CC list.  which then puts messages out of context.  I personally 
find it rude and overly aggressive and offensive.  none of the fedora lists 
operate that way,  people just reply to list.  If it was normal behaviour that 
im used i guess it wouldn't bother me.  but it not the normal behaviour.


FYI: mailman has this option:
Receive your own posts to the list?

Ordinarily, you will get a copy of every message you post to the list. 
If you don't want to receive this copy, set this option to No.


And by default is set to Yes.

I guess in a way since its not the expected behaviour it makes me feel like 
you think i'm not doing a good enough job if you have to resort to CC'ing me 
on email that I would have got and read anyway.


Some people here have hundred unread mails so CC'ing them directly will 
often help. Some may post to list, but are not subscribed. CC'ing them help.


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

[Spacewalk-devel] make upload-tgz

[Miroslav Suchý]

I make this changes to our Makefile

- new target which upload tar.gz to fedora hosted. We probably want to 
call on every package which is released.


- tgz target now remove build dir, which created.

- upload-tgz and tgz targets now check NO_TAR_GZ and reject to continue 
if set.


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] make upload-tgz

[Miroslav Suchý]

Dennis Gilmore wrote:
we should create some structure  and not dump everything to the root in the 
spacewalk namespace.  ie 
https://fedorahosted.org/releases/s/p/spacewalk/nocpulse-common-2.0.8.tar.gz  
should land in  https://fedorahosted.org/releases/s/p/spacewalk/nocpulse-

common/nocpulse-common-2.0.8.tar.gz


This is what I tried to say here:
https://www.redhat.com/archives/spacewalk-devel/2008-October/msg00109.html
:Perfect!
:Odd think it goes to one dir. So there will be soon quite big mess. And
:I think that their FS will not like it.

And your reply:
https://www.redhat.com/archives/spacewalk-devel/2008-October/msg00110.html
:it does  make a dir in there for your project   to create some
:organisation.

Well maybe due to my poor English you did not understood my previous 
email. So let me ask again:
Is there some way how to create some structure on fedorahosted.org? I 
did not find any hint in fedorahosted.org documentation.
Or do we have some other place, where we could place tgz files and not 
make mess on such filesystem?


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

[Spacewalk-devel] Re: First draft of a new build system for Spacewalk.

[Miroslav Suchý]

First draft of a new build system for Spacewalk.

Created out of the need to build Satellite packages based on Spacewalk, this 
code may replace the Makefile.git we use today depending on how things go.

Code currently only working with ./build.py --tgz in the java project. Other 
options coming soon as well as build.py's for the various sub-projects to 
replace Makefiles.

* [DH] java/build.py
* [DH] rel-eng/pybuilder/pybuilder.py


What is wrong on current Makefile?
Why we need to have rewritten to Python?

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] make upload-tgz

[Miroslav Suchý]

Dennis Gilmore wrote:

Is there some way how to create some structure on fedorahosted.org? I
did not find any hint in fedorahosted.org documentation.
Or do we have some other place, where we could place tgz files and not
make mess on such filesystem?

yes make it yourself
you should be able to ssh in and make it.  or rsync it in place  using rsync  
over ssh.


It do not work. I tried it, this is why I'm asking.
$ ssh fedorahosted.org
Need a command
  Connection to fedorahosted.org closed.

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

[Spacewalk-devel] Nightly builds

[Miroslav Suchý]

I prepared nighlty builds:
http://miroslav.suchy.cz/spacewalk/rawhide/
http://miroslav.suchy.cz/spacewalk/rawhide-candidate/

It is created from packages in spacewalk-5E-[lastversion] resp. 
spacewalk-5E-[lastversion]-candidate tags in Brew.
It does not automatically build the needed packages (yet). You have to 
build yourself for now.


Repos are updated at 8.30 and 12.30 CET (which is 2.30 and 6.30 EDT).

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Nightly builds

[Miroslav Suchý]

Jan Pazdziora wrote:

Mirek, some packages seem to be missing from the repos. For example,
spacewalk-java-0.3.6-1.el5.sw is nowhere to be found even if it is
tagged in spacewalk-5E-0.3-candidate.

Am I doing something wrong?


Well, I'm using mash. With this configuration file:

$ cat /etc/mash/spacewalk-canidate.mash
# mash config file

[spacewalk-candidate]
rpm_path = %(arch)s/
source_path = SRPMS/
debuginfo = True
multilib = True
multilib_method = devel
tag = spacewalk-5E-0.3
inherit = False
strict_keys = False
#keys = 4F2A6FD2, 1AC70CE6, 30C9ECF8, DB42A60E, 897DA07A
repoviewurl = http://miroslav.suchy.cz/spacewalk/rawhide-candidate/%(arch)s/
repoviewtitle = "Spacewalk rawhide candidate %(arch)s"
arches = i386 x86_64
topdir = /mnt/redhat

Dunno why some rpm are not there. Will check when I will have time. But 
if somebody have more expirience with mash I'll appreciate help.



--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] make upload-tgz

[Miroslav Suchý]

Dennis Gilmore wrote:

On Thursday 30 October 2008 04:26:49 am Miroslav Suchý wrote:

Dennis Gilmore wrote:

Is there some way how to create some structure on fedorahosted.org? I
did not find any hint in fedorahosted.org documentation.
Or do we have some other place, where we could place tgz files and not
make mess on such filesystem?

yes make it yourself
you should be able to ssh in and make it.  or rsync it in place  using
rsync over ssh.

It do not work. I tried it, this is why I'm asking.
$ ssh fedorahosted.org
Need a command
   Connection to fedorahosted.org closed.
then put the tarball in /.tar.  and rsync it 
up


$ rsync -av MessageQueue/MessageQueue-3.26.2.tar.gz 
fedorahosted.org:spacewalk/MessageQueue/MessageQueue-3.26.2.tar.gz
Invalid command rsync --server -vlogDtpr . 
spacewalk/MessageQueue/MessageQueue-3.26.2.tar.gz

rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(463) 
[sender=2.6.8]


or even:

$ rsync -av MessageQueue/MessageQueue-3.26.2.tar.gz 
rsync://fedorahosted.org:spacewalk/MessageQueue/MessageQueue-3.26.2.tar.gz

@ERROR: Unknown module 'MessageQueue'
rsync error: error starting client-server protocol (code 5) at 
main.c(1296) [sender=2.6.8]


Any other ideas?

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Nightly builds

[Miroslav Suchý]

Jesus M. Rodriguez wrote:

On Thu, Oct 30, 2008 at 9:31 AM, Miroslav Suchý <[EMAIL PROTECTED]> wrote:

I prepared nighlty builds:
http://miroslav.suchy.cz/spacewalk/rawhide/
http://miroslav.suchy.cz/spacewalk/rawhide-candidate/

It is created from packages in spacewalk-5E-[lastversion] resp.
spacewalk-5E-[lastversion]-candidate tags in Brew.
It does not automatically build the needed packages (yet). You have to build
yourself for now.

Repos are updated at 8.30 and 12.30 CET (which is 2.30 and 6.30 EDT).



Can we not call it rawhide? I fear that it might be confused with pkgs
for rawhide of Fedora,
which they are not.


OK. Renamed to nightly and nightly-candidate.
As soon as our internal koji will be usable I can switch the script and 
start pulling the packages from koji.


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Announcing Spacewalk 0.3

[Miroslav Suchý]

Stephen John Smoogen wrote:

On Mon, Nov 10, 2008 at 1:53 PM, Michael DeHaan <[EMAIL PROTECTED]> wrote:

I am curious, what is the motivation for this change?


1) now if you install upstart (or something like that) you can start 
required services in parallel.


2) If you installed spacewalk it manipulated with services. Which is 
generaly bad. But the first impulse came that rhn-satellite 
started/stoped database service even if there were none (external) or 
have different service name (embedded db vs. xe).



Actually for some reason this seems to scream out LSB violation, but
its probably on the lines of "Well it it ain't, it darn well should


Actually /sbin/rhn-satellite is NOT init.d script. There is no link from 
rc.d to this file. It is there just to make easy life for admins. So 
instead calling

  service tomcat stop
  service satellite-httpd stop
  service jabberd stop
  service rhn-database stop
  service jabberd stop
  and the same in reverse order for start
they will write
  /sbin/rhn-satellite restart

We removed rhn-satellite as service and now we do not disable services, 
which we - in previous versions - disabled in %post section of some 
spacewalk package.


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

[Spacewalk-devel] root as contributor

[Miroslav Suchý]

Welcome root :)
http://miroslav.suchy.cz/spacewalk/gitstat/commit-detail.php?commit=6cdf4423e04ffd66fda796e4946a662a9a03e497
and 3 others commits

Can you please use your real identity for commits? Thx.
--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] root as contributor

[Miroslav Suchý]

Mike McCune wrote:

Miroslav Suchý wrote:

Welcome root :)
http://miroslav.suchy.cz/spacewalk/gitstat/commit-detail.php?commit=6cdf4423e04ffd66fda796e4946a662a9a03e497 


and 3 others commits

Can you please use your real identity for commits? Thx.


Anyone have any good tips on how we can change the author on those commits?




You can not change history. Unless all users changed their repo as well.
Let leave is as is and learn from this.

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

[Spacewalk-devel] Nightly repos

[Miroslav Suchý]

I updated (using data, which Dennis provided):
 http://miroslav.suchy.cz/spacewalk/nightly-candidate/
Now it contains 0.4-candidate packages. The build still have to be 
initiated by developer.


I deleted http://miroslav.suchy.cz/spacewalk/nightly because we stooped 
using it.


Packages are synced with content of our internal koji in:
 40 8,13,19 * * *

Enjoy
--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Dep Issues Installing From 0.4 Devel Repos

[Miroslav Suchý]

Devan Goodwin wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Running into the following problems which are preventing from
installing spacewalk from the devel repo at
http://miroslav.suchy.cz/spacewalk/nightly-candidate/.

- --> Finished Dependency Resolution
Error: Missing Dependency: perl(DBD::Oracle) is needed by package
spacewalk-base 
Error: Missing Dependency: perl(NOCpulse::DBRecord) is
needed by package SatConfig-generator 
Error: Missing Dependency:

perl(NOCpulse::NPRecords) is needed by package SatConfig-installer
Error: Missing Dependency: rhnpush is needed by package spacewalk
Error: Missing Dependency: perl(NOCpulse::Database) is needed by
package tsdb 
Error: Missing Dependency: perl(NOCpulse::NPRecords) is
needed by package perl-NOCpulse-Scheduler 
Error: Missing Dependency:
perl(DBD::Oracle) is needed by package NPalert 
Error: Missing

Dependency: perl(NOCpulse::CF_DB) is needed by package eventReceivers
Error: Missing Dependency: perl(NOCpulse::CF_DB) is needed by package
SputLite-server 
Error: Missing Dependency: perl(NOCpulse::Database) is

needed by package scdb E
rror: Missing Dependency:
perl(NOCpulse::NPRecords) is needed by package NOCpulsePlugins 
Error:

Missing Dependency: python(:DBAPI:oracle) is needed by package
spacewalk-backend-sql 
Error: Missing Dependency: perl-NOCpulse-OracleDB
is needed by package spacewalk 
Error: Missing Dependency:

perl(NOCpulse::NPRecords) is needed by package
SatConfig-bootstrap-server 
Error: Missing Dependency: nocpulse-db-perl
is needed by package spacewalk 
Error: Missing Dependency:
perl(NOCpulse::NPRecords) is needed by package SNMPAlerts 
Error:

Missing Dependency: perl(NOCpulse::NPRecords) is needed by package
MessageQueue 
Error: Missing Dependency: perl(NOCpulse::NPRecords) is
needed by package SatConfig-generator 
Error: Missing Dependency:

perl(DBD::Oracle) is needed by package perl-NOCpulse-Probe

Any thoughts?


Yes, wee need to import or build in Koji. perl-DBD-Oracle, cx_Oracle, 
and those require oracle-instant-client.


Dennis can you import those packages please?

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

[Spacewalk-devel] API version

[Miroslav Suchý]

Can we create new API call which add something to distinguish between 
satellite versioning and spacewalk versioning?


I have problem that I want to call proxy.isProxy() which will be only in
0.4+. But the expression "if api > 0.4" is true for old satellites (like 
5.0) as well.


I suggest to add some kind of epoch, but I have no idea how to make it 
compatible with olders api. Any idea?

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] API version

[Miroslav Suchý]

Dennis Gilmore wrote:

On Wednesday 19 November 2008 11:03:45 am Miroslav Suchý wrote:

Can we create new API call which add something to distinguish between
satellite versioning and spacewalk versioning?

I have problem that I want to call proxy.isProxy() which will be only in
0.4+. But the expression "if api > 0.4" is true for old satellites (like
5.0) as well.

I suggest to add some kind of epoch, but I have no idea how to make it
compatible with olders api. Any idea?


I would suggest using an internal API number that is different from release  
start with 1.0  and if there is minor changes resultin in incompatabilities 
just to 1.1  but major changes result in 2.0  or  even just start at 100  
Personally i do not think it needs to be tied to the spacewalk/satellite 
release.


According the code the the returned version is content of web.version 
/etc/rhn/default/rhn_web.conf
I see as best option to create new config option web.apiversion which we 
bump up independently on spacewalk version. And ideally return it back 
to 5.2 at least and act as API version 0.x  never exist.
Yes maybe we can bump it to 100 or 10 to clearly state that it has 
nothing to do with spacewalk versioning.


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] API version

[Miroslav Suchý]

Jesus M. Rodriguez wrote:

Miroslav Suchý wrote:

According the code the the returned version is content of web.version
/etc/rhn/default/rhn_web.conf
I see as best option to create new config option web.apiversion which we
bump up independently on spacewalk version. And ideally return it back to
5.2 at least and act as API version 0.x  never exist.
Yes maybe we can bump it to 100 or 10 to clearly state that it has nothing
to do with spacewalk versioning.


I'm ok with this, seems like using the web_version has caused some problems with
some scripts.


OK. Done as:
https://bugzilla.redhat.com/show_bug.cgi?id=472346



So to summarize what should happen,

1) add web.apiversion to /etc/rhn/default/rhn_web.conf
2) set the initial value to be 5.2

I set it to 10.0


At current it returns web.version + " Java"
http://tinyurl.com/5c2egq
I removed the Java suffix as we do no need it now to distinguish between 
api.get_system_version and api.get_version. If this can be problem raise 
your voice.



5) if you are relying on the value of api.get_system_version() please
switch the appropriate api.get_version() method.


Please now whenever you add new API call modify minor version 
web.apiversion in web/conf/rhn_web.conf. And every Spacewalk release 
bump up major version.

If you have better idea how to handle api versioning share the idea.

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] API version

[Miroslav Suchý]

Jesus Rodriguez wrote:

Why 10.0? Seems really arbitrary. If that was the intent, I can live
with it.


If we make is 5.2, people can expected that Satellite 5.3 will have API 
5.3, whereas it will meantime bump up to 6.5 or something like that.
I take it as explicitly notice - api version has now no releation to 
spacewalk/satellite version. And I did not bump it up to 100 as Dennis 
suggested as that is imho too much.



5) if you are relying on the value of api.get_system_version() please
switch the appropriate api.get_version() method.
Please now whenever you add new API call modify minor version  
web.apiversion in web/conf/rhn_web.conf. And every Spacewalk release  
bump up major version.

If you have better idea how to handle api versioning share the idea.


How would this work under a normal development cycle? For example, in
sw 0.4, if brad adds 4 new apis and I add 5 more, do we bump up the
minor release by 9 i.e. 10.9? 


Because if brad will think "oh, zeus will be adding some api tommorow, 
he will bump it up for me" and you will think "brad alredy added api, so 
he for sure bumped it up".
It is no problem if we skip some number due this process. E.g. if 
space04 will have API 10.5 and space05 will have API 11.4.

But it is problem if we forget to bump up the version.

Additionaly it will be nice if we start putting in javadoc comments (and 
in help generated from this) that this api call is available since api 
version 10.1.


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] API version

[Miroslav Suchý]

Devan Goodwin wrote:
The reason that I ask is that we don't bump the Spacewalk version for 
every change that is submitted to it.  I also suspect that over time 

Why?


many folks will forget to bump the API version as they submit changes
to the APIs, so the might become less reliable/useful.

This is what I have on my mind. To prevent forgeting on bump up api version.


IMO we should up the API version once and only once per spacewalk
release. (either right before it goes out the door, or right after the
last release is made, actually the latter sounds better) Even if there
are API bugfixes post-release they won't be changing the signature for
calls and thus no need for a minor version increase. (if I understand
the purpose of API version anyhow)


Hmm, can be. If we make it part of branch process, it will work.
So right after freezing release into separate branch, bump up apiversion 
 in master.


So what to do with major and minor then? What about increase minor 
number every spacewalk release and increase major number for every 
"stable release" i.e. the release, from which satellite will be made.


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

[Spacewalk-devel] Developers: please rebuild packages

[Miroslav Suchý]

$ rel-eng/koji-missing-builds.pl dist-5E-sw-0.4-candidate
Extra builds in koji:
spacewalk-selinux-0.4.1-1.el5
spacewalk-setup-0.4.2-1.el5
Builds missing in koji:
Crypt-GeneratePassword-0.03-12
MessageQueue-3.26.2-1
NOCpulsePlugins-2.208.2-1
NPalert-1.125.20-1
SNMPAlerts-0.5.2-1
SatConfig-bootstrap-1.11.2-1
SatConfig-bootstrap-server-1.13.1-1
SatConfig-cluster-1.54.4-1
SatConfig-dbsynch-1.3.1-1
SatConfig-general-1.215.43-1
SatConfig-generator-2.29.8-1
SatConfig-installer-3.24.3-1
SatConfig-spread-1.1.2-1
SputLite-0.48.2-1
buildsys-macros-0.2-1.sw
cx_Oracle-4.2.1-5
eventReceivers-2.20.9-1
jabberpy-0.5-0.15
nocpulse-common-2.0.13-1
nocpulse-db-perl-3.6.2-1
oracle-instantclient-selinux-10.2-2
oracle-lib-compat-10.2-13
oracle-rhnsat-selinux-10.2-2
oracle-selinux-0.1-23.1
osad-0.3.2-1
perl-Crypt-OpenPGP-1.03-15
perl-Crypt-RIPEMD160-0.04-15
perl-DBD-Oracle-1.21-4
perl-DateTime-Locale-0.09-9
perl-DateTime-TimeZone-0.59-6
perl-Filesys-Df-0.92-4
perl-Frontier-RPC-0.07b4p1-6
perl-Math-FFT-1.28-2
perl-NOCpulse-CLAC-1.9.6-1
perl-NOCpulse-Debug-1.23.8-1
perl-NOCpulse-Gritch-1.27.2-1
perl-NOCpulse-Object-1.26.7-1
perl-NOCpulse-OracleDB-1.28.10-1
perl-NOCpulse-PersistentConnection-1.5.2-1
perl-NOCpulse-Probe-1.183.3-1
perl-NOCpulse-ProcessPool-0.10.2-1
perl-NOCpulse-Scheduler-1.58.8-1
perl-NOCpulse-SetID-1.6.8-1
perl-NOCpulse-Utils-1.14.9-1
perl-Satcon-1.9-1
perl-Schedule-Cron-Events-1.8-15
perl-Set-Crontab-1.02-3
python-gzipstream-1.4.0-16
rhn-custom-info-0.2.2-1
rhn-kickstart-0.2.1-1
rhn-oracle-jdbc-1.0-19
rhn-virtualization-0.3.2-1
rhncfg-0.3.1-1
rhnmd-5.1.1-1
rhnpush-0.3.1-1
scdb-1.15.5-1
spacewalk-branding-0.1.6-1
spacewalk-certs-tools-0.3.1-1
spacewalk-config-0.3.3-1
spacewalk-koan-0.3.2-1
spacewalk-proxy-0.3.3-1
spacewalk-proxy-docs-0.1-2
spacewalk-proxy-html-0.4.1-1
spacewalk-proxy-installer-0.4.2-1
spacewalk-proxy-monitoring-0.3.2-1
spacewalk-repo-0.3-1
spacewalk-search-0.3.4-1
spacewalk-selinux-0.4.1-2
spacewalk-setup-0.4.3-1
spacewalk-ssl-cert-check-1.4-10.10
ssl_bridge-1.9.2-1
status_log_acceptor-0.12.6-1
stringtree-json-2.0.9-3
tsdb-1.27.16-1

I'm going to rebuild monitoring and proxy packages, but If you recently 
worked on some package and tagged it in git and did not rebuild it 
please do it.


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Developers: please rebuild packages

[Miroslav Suchý]

Jesus M. Rodriguez wrote:

We're rebuilding only the stuff that has changed right? I don't see
any reason to rebuild anything if nothing has changed.


Correct. So if somebody tagged package, it surely changed. When it is 
tagged and not build. I can speak for my packages: I change it and 
tagged when Koji did not worked. I recall to rebuild it today.



I'm going to rebuild monitoring and proxy packages, but If you recently
worked on some package and tagged it in git and did not rebuild it please do
it.


But never mind. There is no need to do it. I did it for you. I just create:
  rel-eng/build-missing-builds-in-koji.sh
And it is running right now.

Dennis can you add it to some crontab?

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

[Spacewalk-devel] cx_Oracle

[Miroslav Suchý]

4 weeks ago has been released new cx_Oracle in version 4.4.1
I now that Michael tried to replace current version we use (4.2.1) with 
some 4.3.x version and it did not worked so he gave up.


The new version has one important feature and it is forward 
compatibility with upcoming 5.0. So it may be worth to spend some cycles 
on making Spacewalk working with cx_Oracle 4.4.1 as it should then work 
with 5.0.

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

[Spacewalk-devel] Rebuild of packages in Koji - some problems

[Miroslav Suchý]

Last friday I let rebuild of all packages which has tag in git and has 
not been builded in Koji. Two problems has been found:


perl-DBD-Oracle:
http://koji.rhndev.redhat.com/koji/buildinfo?buildID=9271
I will take care about it.

stringtree-json
http://koji.rhndev.redhat.com/koji/buildinfo?buildID=9307
Missing requires for unzip.
Can you - Jesus or Partha - fix it?

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Spacewalk 0.4 update

[Miroslav Suchý]

Mike McCune wrote:
I'd advocate we instead release a QA build to the public on 12/15 and do 


QA build aka nightly builds are released every day at:
http://miroslav.suchy.cz/spacewalk/nightly-candidate/
Just make sure you tag the package when you commit some fix/feature.

BTW: It seems that there is a lot of packages with some commits and 
which are not tagged:
[EMAIL PROTECTED]/~/rhn/spacewalk.pub/rel-eng]$ ./git-untagged-commits.pl 
|grep HEAD

SatConfig-bootstrap-server-1.13.1-1..HEAD:
jabberpy-0.5-0.15..HEAD:
nocpulse-common-2.0.13-1..HEAD:
oracle-instantclient-selinux-10.2-2..HEAD:
oracle-xe-selinux-10.2-5..HEAD:
osad-0.3.2-1..HEAD:
perl-Crypt-OpenPGP-1.03-15..HEAD:
perl-Crypt-RIPEMD160-0.04-15..HEAD:
perl-DBD-Oracle-1.21-4..HEAD:
perl-NOCpulse-PersistentConnection-1.5.2-1..HEAD:
rhn-custom-info-0.2.2-1..HEAD:
rhn-virtualization-0.3.2-1..HEAD:
rhncfg-0.3.1-1..HEAD:
rhnpush-0.3.1-1..HEAD:
spacewalk-0.4.2-1..HEAD:
spacewalk-admin-0.4.2-1..HEAD:
spacewalk-backend-0.4.5-1..HEAD:
spacewalk-branding-0.1.6-1..HEAD:
spacewalk-certs-tools-0.3.1-1..HEAD:
spacewalk-config-0.3.3-1..HEAD:
spacewalk-java-0.4.2-1..HEAD:
fatal: bad revision 'spacewalk-koan-0.3.2-1..HEAD'
spacewalk-proxy-0.3.3-1..HEAD:
spacewalk-proxy-monitoring-0.3.2-1..HEAD:
spacewalk-repo-0.3-1..HEAD:
spacewalk-schema-0.4.3-1..HEAD:
spacewalk-search-0.3.4-1..HEAD:
spacewalk-web-0.4.2-1..HEAD:
stringtree-json-2.0.9-3..HEAD:
tsdb-1.27.16-1..HEAD:


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Spacewalk 0.4 update

[Miroslav Suchý]

Jan Pazdziora wrote:

perl-Crypt-OpenPGP-1.03-15..HEAD:
perl-Crypt-RIPEMD160-0.04-15..HEAD:


Shouldn't these be gone by now? If yes, removing


Indeed.



rel-eng/packages/perl-Crypt-OpenPGP
rel-eng/packages/perl-Crypt-RIPEMD160

will pretend the packages never existed.


Removed.
What did you say, that did not existed? :)


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

[Spacewalk-devel] Reason why we should use dist-5E-sw-0.4

[Miroslav Suchý]

Right now we build into tag dist-5E-sw-0.4-candidate. When I have been 
working on that nightly repo I find one good reason why we should use 
tag dist-5E-sw-0.4 and only successful builds tagged there from 
dist-5E-sw-0.4-candidate. The reason are nightly builds.


Now the package get into nightly repo only if you tagged that package in 
git. If you do not tagged it there we have two possibility how to build 
the package.


1) Automatically tag the package in git and current script will then 
automatically pick it up for rebuild.

Honestly - I do not like such option.

2) Create tag dist-5E-sw-0.4. Normally build into 
dist-5E-sw-0.4-candidate as now and unsuccessful builds tag into 
dist-5E-sw-0.4. Final Spacewalk create from dist-5E-sw-0.4 tag.
For nightly builds, let call "make test-srpm" on untagged packages and 
build in koji the packages with .git.longsha1 dist tag.
This way you make sure when somebody finally tag the package (which bump 
up the version automatically) such package will be upgraded to last version.

I prefer this option.

3) OK. There is third option. To build .git.longsha1 packages in 
dist-5E-sw-0.4-candidate and not creating dist-5E-sw-0.4. But it will 
create only mess. I'm scratching such option.


How do you like it? Or do you have another idea how to implement nightly 
builds?

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] multiarch - SSM remove packages issue

[Miroslav Suchý]

Jason Dobies wrote:

I ran into a wall while adding multiarch support to the SSM remove
packages flow.

Currently, we store the packages the user selects into an rhnSet. When
determining on which servers the selected packages exist, the query uses
the rhnSet of packages and the set of systems to let the DB do all the
heavy lifting.

The problem is in the two element approach in rhnSet; there's no room
for arch (it's currently holding the name ID and evr ID in the two
slots). This keeps me from using rhnSet to hold the packages for that
query (I can easily hang on to them in memory with SessionSet).

Likewise, an IN clause is probably out for all of the reasons I'm sure
we've hit a number of other places.

So I'm kinda stuck. Any ideas are appreciated.


Ehm... Why do you need to store arch in db in first place?

I though that the process should be:
1. choose in SSM packages to remove
2. store them name and evr in rhnset.
3. foreach machine in SSM do
	select name_id, evd_id, package_arch_id from RHNSERVERPACKAGE where 
server_id=machine

delete on machine the package(name_id, evd_id, package_arch_id)

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] New Makefile.git(2) committed

[Miroslav Suchý]

Jesus M. Rodriguez wrote:

How does this compare to the build.py stuff we added?


The formula for comparability is:
 Makefile.git > build.py
:)

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Reason why we should use dist-5E-sw-0.4

[Miroslav Suchý]

Jan Pazdziora wrote:

I'd consider it a feature. The developer should tag the package when
he/she feels it is reasonably stable to be built into -candidate.
There is however nothing wrong with the developer pushing their work
to the public repo (for others to see and work on), even if the thing
is not yet stable enough to be usable.


That is probably OK with small packages (like nocpulse-common), but it 
do not work with main packages (like java), which are usually rebuild 
only once just before the final release. Therefore nobody can test it.



Why do you want to build packages from state when they were not tagged
(= signed off by developer)? Just wait for the developer to make
tag(-minor)-release.


That is for what people create nightly builds.
You do not want it? Do not use it and wait for QA repo.
You want test even partial work. Use it.
And the code in git should work. If it do not work, why did you push it 
there in first place.

But again the main reason is stated in my first paragraph of this email.

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Reason why we should use dist-5E-sw-0.4

[Miroslav Suchý]

Dennis Gilmore wrote:
I think we can assume if its not tagged that means that the work is not 
complete and not ready to be built or tested.


I spoke about make tag-release, which make git tag. Do not mistake it 
for koji tag.



2) Create tag dist-5E-sw-0.4. Normally build into
dist-5E-sw-0.4-candidate as now and unsuccessful builds tag into
dist-5E-sw-0.4. Final Spacewalk create from dist-5E-sw-0.4 tag.
For nightly builds, let call "make test-srpm" on untagged packages and
build in koji the packages with .git.longsha1 dist tag.
This way you make sure when somebody finally tag the package (which bump
up the version automatically) such package will be upgraded to last
version. I prefer this option.
Im assuming that you mean moving successful builds into dist-5E-sw-0.4 


No I meant koji tag-pkg dist-5E-sw-0.4 sucessfull-build
I really do not see benefit of moving in compare to tag it to final tag 
as well (beside the -candidate one)


I do not thing we are that far away from teh same goals.  I just think that 
doing builds needs to be the deliberate action of an engineer.  We can and 
should make "make  tag" do the build also.


Are we still speaking about nightly builds? Now I only care about final 
release that way that I do not want to break process of final release.


Ok. So make the question straight:
Will I break something in your rel-eng realm, if I start building 
testing packages (like 
SatConfig-installer-3.24.4-1.git.a352eaab737b87fd46849a6e982c096aa99cc636.src.rpm) 
in  dist-5E-sw-0.4-candidate?


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Reason why we should use dist-5E-sw-0.4

[Miroslav Suchý]

Jesus M. Rodriguez wrote:

As far as auto building the rpm, I don't like that idea. I prefer that
a developer
build it manually.


OK. I'm outvoted :)
So we keep the nightly repos in current state, where it builds only 
package, which are git-tagged.


Can I politely ask all you folks to do
 add changelog entry in .spec file
 make tag-release && gitk -all && git push && git push --tags
whenever you finish some bug or feature.

Thanks
--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] New Makefile.git(2) committed

[Miroslav Suchý]

Jan Pazdziora wrote:

However, if build.py is what you guys want and what you guys will
develop and maintain, so be it. Just put the info to the wiki and
I'll switch to using that. Until that happens, I'm ready to
maintain and improve Makefile.git.



Err. Am I missing something? Neither you nor Devan should do it. 
According Cliff notes:


In general Satellite Release Engineer maintains Release Engineering 
tools and processes needed to get built packages into a consumable 
format. Such as:


* Top level/master Makefiles used globally




--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Rebuild of packages in Koji - some problems

[Miroslav Suchý]

Jesus Rodriguez wrote:

On Mon, Nov 24, 2008 at 09:34:43AM -0600, Dennis Gilmore wrote:

On Monday 24 November 2008 02:55:30 am Miroslav Suchý wrote:

stringtree-json
http://koji.rhndev.redhat.com/koji/buildinfo?buildID=9307
Missing requires for unzip.
Can you - Jesus or Partha - fix it?

thats missing BuildRequires unzip  its not included in the minimal buildroot


I can fix this.


I fixed that.

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

[Spacewalk-devel] Looking for reviewer for Fedora

[Miroslav Suchý]

 Bug 466953 -  (perl-NOCpulse-Utils) Review Request: 
perl-NOCpulse-Utils - NOCpulse utility packages

https://bugzilla.redhat.com/show_bug.cgi?id=466953

This review request is in queue for one month. I'm looking for some 
Fedora developer who want to make good turn.


Thanks in advance.
--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

[Spacewalk-devel] Monitoring is working in master

[Miroslav Suchý]

It takes long time... But yeah, monitoring is working now.

If you install Spacewalk from nightly repo:
 http://miroslav.suchy.cz/spacewalk/nightly-candidate/
you should be able to work with monitoring. There are 2 know bugs. Both 
has known workaround.


[Bug 472895] Monitoring fails to start with new perl-Class-MethodMaker
https://bugzilla.redhat.com/show_bug.cgi?id=472895
In epel is new package of perl-Class-MethodMaker and our code do not 
work with it. You should downgrade to perl-Class-MethodMaker-1.12 version.


[Bug 474774] Probe details do not show neither graph nor event log
https://bugzilla.redhat.com/show_bug.cgi?id=474774
You must click "Download CVS data" to get collected data.


So - what happen in monitoring code?
There is no new functionality. All changes has been made to comply with 
Fedora Packaging Guidelines. There are even two first packages in Fedora 
and Epel (nocpulse-common and perl-Satcon). Other are under Package 
Review process right now.


What did I changed:
 * There is no code under /opt.
   * Configuration files are in /etc/nocpulse  (/etc/NOCpulse.ini is 
still on same place).
   * Data files are in /var/lib/nocpulse (which homedir of nocpulse 
user) or /var/lib/notification.

   * Log files are in /var/log/nocpulse or /var/log/notification
   * cgi scripts and html files are in /usr/share/nocpulse
* nocops user has been removed
* SysVinit script are no more symlinks so we support chkconfig and has 
LSB header so we should support upstart and plymouth
* code cleanup - I moved lot of code, which we do not use into 
monitoring/NOT-USED and monitoring/PerlModules/NP/NOT-USED. These 
packages contain a lot of useful code, therefore I do not want to 
delete. We may use it someday.

* And of course SPEC file are far away from previous mess it has been.

We will still have to do one thing. There is nocpulse code in 
/etc/rc.d/np.d/ and we should move it to /usr/share
It *should* be easy. But I'm not 100% sure. And last thing I want to do 
right now is to destabilize monitoring code for another several weeks. I 
want to have at least one release of Spacewalk with functional 
monitoring. After release of 0.4, I plan to do the move /etc/rc.d/np.d/* 
to %{perl_vendorlib}/NOCpulse/


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] If you want to install monitoring ...

[Miroslav Suchý]

Jan Pazdziora wrote:

On Mon, Dec 15, 2008 at 09:08:43AM -0500, Miroslav Suchy wrote:
We hit one rpm/yum bug in monitoring. Due this bug yum pick up old monitoring package. 
It will be solved in rhel5.3. Until then if you want to install spacewalk with propper installed monitoring you shoudl do:

yum install nocpulse-common
and after it
yum install spacewalk


Mirek,

can't we just untag the NPusers builds from the koji tag, get it
removed from that nightly repo, and be happy ever after?


Correct. It is inherited from 0.3 so it can not be untagged and should 
be blocked. Filled rel-eng ticket.


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

[Spacewalk-devel] MySQL support for Spacewalk

[Miroslav Suchý]

I pleased to announce you that Matej Hašuľ started working on his Master 
Thesis which has goal to add support for MySQL as database backend for 
Spacewalk.

We will track his progress on page:
https://fedorahosted.org/spacewalk/wiki/MySQL_support
He can work for 3 semesters on his thesis. Therefore the output of this 
work is targeted on summer 2010.

He is supposed to watch our work on PostgreSQL and build upon this work.

If you find this project interesting, you can send your patches to Matej 
for review.

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Monitoring is working in master

[Miroslav Suchý]

Miroslav Suchý wrote:
you should be able to work with monitoring. There are 2 know bugs. Both 
has known workaround.


[Bug 472895] Monitoring fails to start with new perl-Class-MethodMaker
https://bugzilla.redhat.com/show_bug.cgi?id=472895
In epel is new package of perl-Class-MethodMaker and our code do not 
work with it. You should downgrade to perl-Class-MethodMaker-1.12 version.


It is fixed now. Monitoring works even with recent perl-Class-MethodMaker.

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Building RPMs w/ build.py

[Miroslav Suchý]

Devan Goodwin wrote:

This was on my TODO but hasn't been done yet, I'll try to get it in
there today. 


Is is just me or 
I had the impression that you start working on build.py so that it will 
be easier to read/maintain.


But if I compare:
$ wc -l Makefile.*
   85 Makefile.git
  189 Makefile.srpm
  113 Makefile.tag-release
  387 total

$ wc -l bin/build.py lib/spacewalk/__init__.py lib/spacewalk/releng/*
   26 bin/build.py
0 lib/spacewalk/__init__.py
  383 lib/spacewalk/releng/builder.py
  155 lib/spacewalk/releng/cli.py
  178 lib/spacewalk/releng/common.py
   19 lib/spacewalk/releng/__init__.py
  251 lib/spacewalk/releng/tagger.py
 1012 total

And I do not see build.py much readable then Makefile

And build.py still do not have the functionality of Makefile.

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] If you want to install monitoring ...

[Miroslav Suchý]

Mike McCune wrote:

Is this expected from spacewalk-setup:


Not known till now.


* Enabling Monitoring.
RHN::Exception: Attempt to get satellite_org_id on database with more 
than one org
  RHN::DB::SatInstall 
/usr/lib/perl5/site_perl/5.8.8/RHN/DB/SatInstall.pm 384 
RHN::Exception::throw
  main /usr/bin/spacewalk-setup 1036 
RHN::DB::SatInstall::get_satellite_org_id

  main /usr/bin/spacewalk-setup 131 main::setup_monitoring



The bug in that code is obvious.
I filled in:
https://bugzilla.redhat.com/show_bug.cgi?id=476812
Should be already fixed. Can you try it again.

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

[Spacewalk-devel] Please tag package when you finish BZ

[Miroslav Suchý]

I run several times into some bug, which has been already fixed in our code.
Please tag your package using "make tag-release && git push --tags" when 
you finish work on some BZ. This way your work will appear in nigtly 
repo and others (including me) can benefit from working on fixed spacewalk.


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] If you want to install monitoring ...

[Miroslav Suchý]

Jan Pazdziora wrote:

On Tue, Dec 16, 2008 at 02:01:43PM +0100, Miroslav Suchý wrote:

Mirek,

can't we just untag the NPusers builds from the koji tag, get it
removed from that nightly repo, and be happy ever after?
Correct. It is inherited from 0.3 so it can not be untagged and should  
be blocked. Filled rel-eng ticket.


Heya Mirek,

I just tried to install spacewalk (without installing nocpulse-common
first) and the problem and the NPusers rpm is still in the repository.
Could you please resolve it ASAP?


Unfortunatelly no. I have no ACL for this. I sent email to rel-...@r.c 
on 12/16/2008 02:00 PM, but this ticket [#32619] still have status NEW 
and nobody picked it up.


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

[Spacewalk-devel] cobbler in spacewalk-backend

[Miroslav Suchý]

Is there some reason why spacewalk-backend requires cobbler?
I could not find any reference in backend code now. So is it residuum or 
we actually need.
I ask because spacewalk-backend is required by spacewalk proxy and 
therefore cobbler appear in proxy as well. Which I'm not sure is what we 
want to.

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

[Spacewalk-devel] cobller traceback

[Miroslav Suchý]

I run on this when install sw from nightly:

spacewalk-setup --disconnected
.
* Setting up Cobbler..
Traceback (most recent call last):
  File "/usr/bin/cobbler-setup", line 53, in ?
main()
  File "/usr/bin/cobbler-setup", line 38, in main
answers = loadFile(DEFAULTS).next()
  File "/usr/lib/python2.4/site-packages/cobbler/yaml/load.py", line 
36, in loadFile

return loadStream(FileStream(filename),typeResolver)
  File "/usr/lib/python2.4/site-packages/cobbler/yaml/stream.py", line 
33, in __init__

self.fp = open(filename)
IOError: [Errno 2] No such file or directory: 
'/usr/share/cobbler/installer_templates/defaults'



Is it known?

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Question regarding sending patches

[Miroslav Suchý]

Coe, Colin C. (Unix Engineer) wrote:

Hi all

to include a 'nicer' editor, replacing the default textarea on a few screens.  


BTW: I use "It's All Text" Firefox plugin 
https://addons.mozilla.org/cs/firefox/addon/4125
which gives you the possibility to edit textareas using your favorite 
editor (gvim in my case).



should I send the editor itself for inclusion in spacewalk?  It's shipped as a 
.zip file.  Should I just do a 'git add' on all the files it provides?


/me wonder if we should create it as standalone package and push it to 
Fedora. Other systems may use it as well.


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Why do we hate specspo?

[Miroslav Suchý]

Jan Pazdziora wrote:

On Thu, Jan 08, 2009 at 08:56:03AM -0500, Pradeep Kilambi wrote:
As I recall cliff mentioning to me once.. there is a bug in the specspo  
libraries with rpm which cause apache heap corruption due to specspo  
translating strings within memory when you use rhnpush to upload  
packages into a Satellite it would not free memory correctly.. I may  
have been fixed in specspo now..I'm not sure about that.


Looking at

# rpm -ql specspo

output in RHEL 5, there are not libraries there -- just message
catalogues and one small rpm macro file.


There have not been libraries in past as well. See:
 https://bugzilla.redhat.com/show_bug.cgi?id=173424#c26
for content of specspo when Cliff has been working on that problem.


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Why do we hate specspo?

[Miroslav Suchý]

Jan Pazdziora wrote:

On Thu, Jan 08, 2009 at 09:23:32AM -0500, Jesus M. Rodriguez wrote:

This bug seems to describe why we conflict with specspo:

https://bugzilla.redhat.com/show_bug.cgi?id=175774


OK, but shouldn't LANG=C in front of that rpm command (or some
setlocale if we call the rpm library internally) achieve the same
effect?


Yes, thats what Cliff finally suggested in:
https://bugzilla.redhat.com/show_bug.cgi?id=173424#c24


According:
https://bugzilla.redhat.com/show_bug.cgi?id=173424#c15
https://bugzilla.redhat.com/show_bug.cgi?id=173424#c25
the bug may be in:
/lib/misc.c in rpm lib. I just checked last version of rpm package and 
the problematic part is still there.


Therefore before removing specspo conflict you may want to fill bug 
against rpm and wait before they remove the leak.


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Is Spacewalk Proxy rawhide supposed to work?

[Miroslav Suchý]

Jan Pazdziora wrote:

I thought I'd give Spacewalk Proxy a try. So I followed instructions
in

https://fedorahosted.org/spacewalk/wiki/HowToInstallProxy

only with repo pointing to

http://miroslav.suchy.cz/spacewalk/nightly-candidate/i386/os/


And you done well.


I was surprised to see

...

Why aren't packages like

...

in that transaction?


That is long story. If you want just short answer - yes, it is working.

But it is winter time and you may want to read some story during long 
evenings. So make yourself some hot tee and sit down comfortably. This 
is story about chicken and egg...


In Satellite you have proxy packages in Proxy channel and since we 
wanted to created command line installer (CLI) for proxy and only 
possible way to make proxy channel available from command line is 
rhn-proxy-activate and since this command is in Proxy channel ... you 
are busted.
So I have to cut this circle somewhere and I decided to move 
rhn-proxy-activate to separate package (in spacewalk 
spacewalk-proxy-installer) and it is available in RHN Tools channel.
So if you install spacewalk-proxy-installer you will only install 
packages needed for installer run.
When you run configure-proxy.sh it will then activate you as Proxy 
(which enable you Proxy channel in Satellite) and it will then install 
spacewalk-proxy-management (which is proxy itself) and it will then 
install require and install all the packages you mentioned.


And before you start - yes we can make it easier for spacewalk, but it 
can not be done easier for Satellite.


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Versions of rhncfg* packages

[Miroslav Suchý]

Jan Pazdziora wrote:

Slightly to my previous post about Spacewalk Proxy:

the rhncfg* packages got installed from RHN Tools

=
 Package Arch   Version  RepositorySize 
=

Installing:
 spacewalk-proxy-installer  noarch 0.4.4-1.el5  spacewalk  28 k
Installing for dependencies:
 apr i386   1.2.7-11 rhel-i386-server-5  123 k
 apr-utili386   1.2.7-7.el5  rhel-i386-server-5   76 k
 httpd   i386   2.2.3-11.el5_2.4  rhel-i386-server-5  1.1 M
 postgresql-libs i386   8.1.11-1.el5_1.1  rhel-i386-server-5  196 k
 rhncfg  noarch 5.1.0-3.el5  
rhn-tools-rhel-i386-server-5   51 k
 rhncfg-actions  noarch 5.1.0-3.el5  
rhn-tools-rhel-i386-server-5   27 k
 rhncfg-client   noarch 5.1.0-3.el5  
rhn-tools-rhel-i386-server-5   23 k
 rhncfg-management   noarch 5.1.0-3.el5  
rhn-tools-rhel-i386-server-5   33 k

because their version (5.1.0-3) is greater than what is in the
Spacewalk repo (0.3.1-1). Is that right? Is Spacewalk (Proxy, but
I assume it might also affect clients) only supported for machines
that are not subscribed to the RHN Tools channel?

Shouldn't we bring the version of rhncfg* back?


Yes. When we lower the version, we should bump up epoch. Or we should 
not lower it in first place.

Anyone willing to raise up the version and tag package?


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Which jabberd in Spacewalk?

[Miroslav Suchý]

Jan Pazdziora wrote:

So, I've tried to make my mind about jabberd and how to go about
SELinux support.

We seem to be shipping our own version jabberd-2.0s10-3.42.el5 in
Spacewalk repository. However, there already is
jabberd-2.2.4-1.fc10 in Fedora, so for anybody installing Spacewalk on
Fedora, this will be the package they'll have after the first upgrade.

Since the package is already in Fedora, it is not listed on the
infamous

https://fedorahosted.org/spacewalk/wiki/GettingPackagesIntoFedora

page. However, jabberd is *not* in EPEL.

What are our plans with that thing?


Let assume that it is rhetorical question. Rhetorical answer:
Upgrade to 2.2.4 and ask maintainer if he can build jabberd for EPEL?

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] #!/usr/bin/env python to #!/usr/bin/python

[Miroslav Suchý]

Clifford Perry wrote:

Jan Pazdziora wrote:

If you have Python in a weird location, you probably won't have
osa-dispatcher .py files installed in its PYTHONHOME, will you? So,
the first import which assumes that the python you run actually has
all the prerequisites installed, will fail. Alternatively, mixing
different pythons and libraries from different pythons might produce
weird results because symbols referenced in one library might not be
present in the library from that second python.

We actually have (non-public) bugzilla about this very problem. I'd
argue that we should stop pretending that /usr/bin/env python will
work in the general case, any just put /usr/bin/python there. If
someone needs to run it with different interpreter, they can always do

python /the/path/to/the/script


I would prefer the hard code path to the python binary for reasons 
stated by Jan above.


Folks - other than preference normally - please give feedback based on 
this above information.


+1
We do the same for perl already.

If somebody have python in different location, he is on his own. If he 
want compatibility he should create symlink from /usr/bin/python.


If he do not want compatibility, then lets break.

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] PGPORT Initial porting guidelines.

[Miroslav Suchý]

Devan Goodwin wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, 15 Jan 2009 15:36:55 +0530
"Gurjeet Singh"  wrote:


Hi All,

Just finished Wikifying the initial guidelines on how to go about
porting to Postgres. You can find it here:

https://fedorahosted.org/spacewalk/wiki/PostgresPortingGuidelines

These are my opinions on the issues I could see directly (in
schema/ or through grepping). There are many places where some debate
is needed, and then there are some places where core developers can
help out making decisions based on their knowledge.

I am attaching the text file here. Lets discuss the issues here,
and finalize them, before going ahead with the actual modifications.

Best regards,


Great guidelines Gurjeet,

We'll have to get Orafce packages into Fedora/EPEL, will we need some


FYI:
It is already in Package Review process, but failed to pass several times.



--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] PGPORT Initial porting guidelines.

[Miroslav Suchý]

Miroslav Suchý wrote:

FYI:
It is already in Package Review process, but failed to pass several times.

I forgot to say BZ number
https://bugzilla.redhat.com/show_bug.cgi?id=251805

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Is Spacewalk Proxy rawhide supposed to work?

[Miroslav Suchý]

Jan Pazdziora wrote:

So, rhncfg, rhncfg-actions, rhncfg-client, and rhncfg-management are


Not really, spacewalk-proxy-tools require it. But I'm slowly moving 
thing out of this package due:

https://bugzilla.redhat.com/show_bug.cgi?id=465947
Remove spacewalk-proxy-tools package
So I really do not consider it as bug, but as feature. :)
Hopefully I will move the calling of rhncfg to proper place in installer 
one day.



really all needed to run the installer and activate the proxy? And
httpd?
Same issue. Previously spacewalk-proxy-tools require it and I move it to 
installer.
But I agree that individual package which really use it should require 
it insteaed (like spacewalk-proxy-broker, spacewalk-proxy-redirect and 
spacewalk-proxy-tools atm.). Feel free to fill in BZ for this.


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] PGPORT (installation issue using make)

[Miroslav Suchý]

Devan Goodwin wrote:

But whenever i am trying to  open browser for spacewalk server(
https://localhost.localdomain)
 i am getting this error message

Forbidden

You don't have permission to access / on this server.

Additionally, a 403 Forbidden error was encountered while trying to
use an ErrorDocument to handle the request.
--
Apache/2.2.3 (Red Hat) Server at 127.0.0.1 Port 80

it look like a Apache issue but i am not able to solve it.

Any idea how to solve this ?


Could you try hitting from a non-localhost IP, this historically does
not work in spacewalk and I don't recall that changing anytime recently.


To be specific: Not need to access from different IP, but using fully 
qualified domain name.


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

[Spacewalk-devel] Re: [Spacewalk-list] Spacewalk 0.4 is here!

[Miroslav Suchý]

Jesus M. Rodriguez wrote:

The Spacewalk team is happy to announce the release of Spacewalk 0.4.
In a few hours, the repos will be accessible and you can install 0.4
and try it out.


FYI:
Freshmeat page updated:
http://freshmeat.net/projects/spacewalk/?branch_id=76942&release_id=292281

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

[Spacewalk-devel] Re: [Spacewalk-list] Spacewalk 0.4 is here!

[Miroslav Suchý]

Jesus M. Rodriguez wrote:

Please note that with this release, Spacewalk 0.2 will no longer be
available. If you are still using Spacewalk 0.2, please upgrade to
Spacewalk 0.4.


Jesus,
I find one problem post release as well. Monitoring started sending 
Notification Meltdown after one day. I spend this day on this problem 
and hopefully fixed it. Backports are in SPACEWALK-0.4 branch already 
and the packages are build right now.

Can you push it to repo when finished please:
buildID=13873
buildID=13874

E. The builds failed:
GenericError: Unable to complete build: release mismatch (build: 1.el5, 
rpm: 1)


Dennis, is it possible that you removed buildsys-macros from 
dist-5E-sw-0.4-candidate ?



Thx
--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

[Spacewalk-devel] rhn-proxy-debug and spacewalk-proxy-tools are removed

[Miroslav Suchý]

I finished:
https://bugzilla.redhat.com/show_bug.cgi?id=465947

Which means that package spacewalk-proxy-tools is removed (Dennis can 
you make note to remove it from comps?)


Command rhn-proxy-debug is deleted as well and you should use "sos -o 
rhn" instead.


/etc/rc.d/init.d/rhn-proxy is moved to /usr/sbin/rhn-proxy and rhn-proxy 
is not service any more. Each service is started/stoped individually as 
in Spacewalk.


And before you start the question: "Who is root 
" - it is me. I did not noticed that I'm 
root and saw that after push - too late to revert it. Shame on me.


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] make upload-tgz

[Miroslav Suchý]

Dennis Gilmore wrote:
I changed make upload-tgz behaviour.  previously it was using a user in the 
scp which it was determining from whoami.  my fas account name does not match 
my local user name so trying to upload resulted in my getting blocked by 


It is not true. If you run "make help" and you read its output you can 
see there:

 The Makefile.git includes file ~/.spacewalk-build-rc if it exists.
 ...
 The line
FEDORAHOSTED_USER = login
 allow you to set login name for uploading tgz files to
 fedorahosted.org if you current login differ.


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] building packages in remote branch

[Miroslav Suchý]

Mike McCune wrote:

If I tag a release in the SPACEWALK-0.4 release branch:

http://git.fedorahosted.org/git/spacewalk.git?p=spacewalk.git;a=commit;h=1ac7a83c472b8b6bf45bb54b6477c3c825254401 



Do I need to push any of that into master? If not, won't the versions 
get out of date in master (behind the release branch)?


If you tag package in SPACEWALK-0.4 you will get another 0.4 version - 
0.4.17-1 in your case.
When you make some changes in master after branching you should bump up 
version number - to 0.5.0 in this case. Then after you tag the package 
you will get 0.5.1-1 version.

That is everything perfect.

The scenario when you hit some problem is when you tag release in 
SPACEWALK-0.4 branch (and you will get 0.4.17-1) and then you forgot to 
bump up version in master you tag there release as well and you will get 
0.4.17-1 as well. But either git pull or git push --tags will stop you 
since you can not have one tag for two different commits. Therefore it 
is nearly impossible to do things wrong.


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

[Spacewalk-devel] Proofreading

[Miroslav Suchý]

Can I ask somebody with English as native language to read my commit 
084b882ef21f0b68631c222135e5c3f340db2495 and edit my errors I made in 
that man page?

Thx in advance.
--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Informal Devel Environment Survey

[Miroslav Suchý]

Devan Goodwin wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Noticing a lot of newcomers really struggling with our devel setup
lately and got to wondering how many others out there aren't actually
even using it. Anyone feel like sharing what, if anything, they're
doing differently from the standard devel environment setup defined
here (and why):

https://fedorahosted.org/spacewalk/wiki/DevelopmentWorkstationSetup

I have a gut feeling we should recommend something drastically
different to lower the barrier to entry.


I personally disagree with the whole DevelopmentWorkstationSetup idea. 
Since you will get something which differs from final Spacewalk. And I 
do not want to run tests and experiments directly on my workstation.


I prefer to have Spacewalk installed on different virtual machine and 
test the code there. I write code on my machine.

Python/perl code I then copy directly.
For java I use this workflow:
I edit .java file in git on my machine and then in virtual machine as root:
# cd /tmp
# mkdir -p com/redhat/rhn/domain/kickstart/
# scp 
myn...@mymachine:spacewalk.git/java/src/com/redhat/rhn/domain/kickstart/KickstartCommand.java 
 com/redhat/rhn/domain/kickstart/
# javac -extdirs /var/lib/tomcat5/webapps/rhn/WEB-INF/lib/ 
com/redhat/rhn/domain/kickstart/KickstartCommand.java
# jar uf /usr/share/rhn/lib/rhn.jar 
com/redhat/rhn/domain/kickstart/KickstartCommand.class

# /etc/init.d/tomcat5 restart

If I make changes in a lot of files I run "make test-rpm" in directory 
where the package reside (can be find by cat rel-eng/packages/package>) and then copy and install the resulting rpm to that virtual 
machine.


This way I'll get exact copy of Spacewalk as others will have, when I 
commit and push my changes. No problems with schema or wrong symlinks.



--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] beginning spacewalk development

[Miroslav Suchý]

Devan Goodwin wrote:

1. Getting packages into Fedora:
https://fedorahosted.org/spacewalk/wiki/GettingPackagesIntoFedora

This entails getting approved as a Fedora packager and learning the ins
and outs of rpm's and spec files but it's really not that hard once you
do it a couple times, and it can prove to be very valuable knowledge to
have as well. The end goal is a great one as well, spacewalk
installable straight out of Fedora/EPEL yum repos.


And you can even review our packages which wait for review:
https://bugzilla.redhat.com/show_bug.cgi?id=466906
https://bugzilla.redhat.com/show_bug.cgi?id=466953


2. Migrate Perl pages to Java:
https://fedorahosted.org/spacewalk/wiki/RemainingPxtPages


3. Try to understand the code and its workflow and write or enhance 
current documentation. Ideally by changing the comments in code from 
which are the documentation automatically generated:

https://fedorahosted.org/spacewalk/wiki/DeveloperDocs

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] cleanup external projects from git

[Miroslav Suchý]

Dennis Gilmore wrote:

On Friday 23 January 2009 12:18:31 am Dennis Gilmore wrote:

jabberpy and perl-Filesys-Df  are both in fedora and EPEL,  I plan to

perl-Set-Crontab
perl-Crypt-GeneratePassword
perl-Frontier-RPC
perl-Math-FFT
perl-Schedule-Cron-Events

will be removed also.  they are all in fedora and epel also


I would like the rise the issue of perl-Satcon, nocpulse-common and 
other packages we already pushed to Fedora. They are in Fedora and Epel 
as well. But we are upstream of such packages.


I will welcome some tool which we can run after each release of 
Spacewalk and which will say something like:

# rel-eng/what-is-fedora-missing
Following packages in Fedora and Epel packages are older than release 
which can be found in rel-eng/packages/ and should be updated:

perl-Satcon
git:  perl-Satcon-0.2-1
F-10: perl-Satcon-0.1-1
...
nocpulse-common:
git: nocpulse-common-0.3-1
F-10: nocpulse-common-0.2-1
...

# rel-eng/update-package-in-Fedora F-10 nocpulse-common
Package nocpulse-common updated in branch F-10.
Build of nocpulse-common updated in branch F-10 has been requested.
# rel-eng/update-package-in-Fedora devel nocpulse-common
Package nocpulse-common updated in branch devel.
Build of nocpulse-common updated in branch devel has been requested.
# rel-eng/update-package-in-Fedora EL-5 nocpulse-common
Package nocpulse-common updated in branch EL-5.
Build of nocpulse-common updated in branch EL-5 has been requested.

Or something like that.

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] cleanup external projects from git

[Miroslav Suchý]

Dennis Gilmore wrote:

On Friday 23 January 2009 12:18:31 am Dennis Gilmore wrote:

jabberpy and perl-Filesys-Df  are both in fedora and EPEL,  I plan to
remove them from spacewalk git tomorrow afternoon. please yell if you think
they should be kept.  ive already blocked them from being built in
spacewalk koji.

Dennis

perl-Set-Crontab
perl-Crypt-GeneratePassword
perl-Frontier-RPC
perl-Math-FFT
perl-Schedule-Cron-Events

will be removed also.  they are all in fedora and epel also


When you remove some package or block it from Spacewalk tag, please 
remove file(s) rel-eng/packages/ as well. Otherwise 
rel-eng/build-missing-builds-in-koji.sh will try to build these packages 
3 times per day.

Thx

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] SSM Asynchronous Actions

[Miroslav Suchý]

Jason Dobies wrote:

As I was working on the performance enhancements for the SSM bulk
channel subscription change
(https://bugzilla.redhat.com/show_bug.cgi?id=469984) I started to wonder
if our approach to the SSM in general could use a little work. Given the
fact that there can potentially be a large number of servers selected, I
think the whole setup lends itself towards an asynchronous model.


Quick question: what is the longest time for SSM action execution. I 
mean either you personally experienced, or customer experienced or 
whoever else experienced.

Do we speak about seconds, minutes or hours?
--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Fedora Status

[Miroslav Suchý]

Dennis Gilmore wrote:

All but 2 packages in git are built for fedora.

Good. Thx.

Please when you build build for F-10 also.  instructions are 
https://fedorahosted.org/spacewalk/wiki/ReleaseProcess  


It wil be nice to have some target in Makefile.git (and/or build.py) to 
build in both tags at once. Something like:

 make release
like we have for sat520.

Will you do it or should I do it?
--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Fedora Status

[Miroslav Suchý]

Dennis Gilmore wrote:

All but 2 packages in git are built for fedora.


I changed
 rel-eng/build-missing-builds-in-koji.sh
so it now automatically builds all tagged packages in tag 
dist-f10-sw-0.5-candidate as well.


Dennis is the F-10 repo available on koji for rsync too? What is the 
url? I would like to add it to public nightly repo as well.


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Fedora Status

[Miroslav Suchý]

Dennis Gilmore wrote:

Dennis is the F-10 repo available on koji for rsync too? What is the
url? I would like to add it to public nightly repo as well.

Hi Miroslav,

thanks in advance its at rsync://koji.rhndev.redhat.com/spacewalk/spacewalk-
f10/spacewalk-f10-0.5/


it update at the same times as the EL-5 repos


OK. Public nigthly repo for Fedora 10 is available at:
 http://miroslav.suchy.cz/spacewalk/nightly-candidate-f10/

Enjoy.

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Fedora Status

[Miroslav Suchý]

Dennis Gilmore wrote:

On Thursday 29 January 2009 09:12:07 am Miroslav Suchý wrote:

Dennis Gilmore wrote:

All but 2 packages in git are built for fedora.

I changed
  rel-eng/build-missing-builds-in-koji.sh
so it now automatically builds all tagged packages in tag
dist-f10-sw-0.5-candidate as well.

Dennis is the F-10 repo available on koji for rsync too? What is the
url? I would like to add it to public nightly repo as well.


Hi Miroslav,

the disttag for F-10 is .fc10 not .f10  the automated builds all failed 


Aha. Fixed.

because of this.  and i was unable to fix as you have not pushed your changes 
up.


Yes. Either forgot or the push failed and I did not noticed. It is 
pushed now with correct disttag.


Thx for correction.

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

[Spacewalk-devel] perl-DateTime-TimeZone failing to build for fc-10

[Miroslav Suchý]

from build.log:
t/01load
Can't locate Test/More.pm in @INC (@INC contains: 
/builddir/build/BUILD/DateTime-TimeZone-0.59/blib/lib 
/builddir/build/BUILD/DateTime-TimeZone-0.59/blib/arch 
/usr/lib/perl5/5.10.0/i386-linux-thread-multi /usr/lib/perl5/5.10.0 
/usr/local/lib/perl5/site_perl/5.10.0/i386-linux-thread-multi 
/usr/local/lib/perl5/site_perl/5.10.0 
/usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi 
/usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl 
/usr/local/lib/perl5/site_perl .) at t/01load.t line 6.

BEGIN failed--compilation aborted at t/01load.t line 6.

Test/More.pm seems to be part of the perl, so what can be problem. Can 
you Dennis investigate it?


Additionaly it seems that we downgraded the package from 0.62 to 0.59. 
What was the reason? Mike?


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] perl-DateTime-TimeZone failing to build for fc-10

[Miroslav Suchý]

Miroslav Suchý wrote:
Test/More.pm seems to be part of the perl, so what can be problem. Can 
you Dennis investigate it?


Ough, Jan just told me that perl(Test::More) is not more part of perl in 
F10. I added build requires to spec. Now it build without problem.


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] #!/usr/bin/env python to #!/usr/bin/python

[Miroslav Suchý]

Jan Pazdziora wrote:

I propose to phase out

#!/usr/bin/env python

in favour of

#!/usr/bin/python

in our python scripts.

Speak now or forever hold your peace.

Note that we already use the second form 182 times in non-test
scripts, while we use env 63 times.


I just find interesting case which speak for using:
  #!/usr/bin/python

If you have daemon with shebang #!/usr/bin/env python then 
/etc/rc.d/init.d/functions is not able to correctly give status of such 
daemon. At least for RHEL4.


More info at:
https://bugzilla.redhat.com/show_bug.cgi?id=468060

For consistency I done
  perl -i -pe 's|\!#/usr/bin/env python|!#/usr/bin/python|
for all python scripts.
sy
--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] Do I report this as a bug?

[Miroslav Suchý]

Stephen John Smoogen wrote:

On Thu, Feb 5, 2009 at 2:19 PM, Devan Goodwin  wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu,  5 Feb 2009 15:33:58 -0500 (EST)
 wrote:


I've tried to install both the 64-bit version and the 32-bit version,
both on CentOS 5.2 (Final). I've been trying this for a week (29/30
Jan). Fresh install of o/s (running under VMware ESX as a "guest"
system). What I've installed is what's pulled down with yum for
spacewalk .4

I've followed all the directions, including the oracle post-install
additional config, and put selinux in permissive mode. I've also
made /etc/rhn/rhn.conf readable by apache. And run cobbler-setup. And
fixed some issues that cobbler check wanted.

This right here sets off alarm bells, whatever is causing
you to have to do these above steps (chmod rhn.conf, cobbler-setup,
etc) is very likely to be the root of your problems. I think you need
to hit the brakes here and figure out what's causing this before
proceeding.


It sounds to me that a system wide umask is causing problems. That
would also cause problems with 500. I remember having this problem
with cfengine and rpm a long time ago.. it would set its umask to 077
and everything coming out would be wrong permissions causing all kinds
of odd behavior.


+1
just for curiosity:
ls -l /etc/rhn/
ls -l /etc/rhn/default/

--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] rhn-client-tools with python2.5

[Miroslav Suchý]

Lukas Durfina wrote:


Hi,

  I am trying run rhnreg_ks with python2.5.
I have this problem:


...
  File "/var/lib/python-support/python2.5/rhn/transports.py", line 225, 
in parse

_response
p, u = self.getparser()
  File "/usr/lib/python2.5/xmlrpclib.py", line 1210, in getparser
return getparser(use_datetime=self._use_datetime)
: Transport instance has no attribute 
'_use_da

tetime'


Looking at transports.py I see that we use in class Transport:
def __init__(self, transfer=0, encoding=0, refreshCallback=None,
progressCallback=None, use_datetime=None):

whereas original xmlrpclib.py use use_datetime=0
Can it be the difference/problem? Can you try it and test it and send 
patch if it will be the solution?


--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] build.py: CLI Changes Coming Soon

[Miroslav Suchý]

Devan Goodwin wrote:

1. Make it installable via setup.py:
Why would I want it to install? How I manage the updates if I install 
it? Should I then manualy track the changes in rel-eng/bin and when file 
change, then reinstall it?


- - re-run when you need to get the latest code. 

How would I know when to re-run it?


- - Doing this because tracking the code in specific branches is
  going to bite someone sooner or later. (something's fixed in master
  that you need when building in another branch or repo)
Jan had ionce idea for Makefile, that the Makefile will do as first 
think checkout of rel-eng/ from master and then will call the Makefile 
from this checkout. This way you will have always fresh code even if you 
are building from some old branch.

But this idea never been implemented.

- - Was thinking 'tito', our magical rel-eng helper. 

+1


3. Restructure the CLI into modules like yum or cobbler:
Instead of refactoring cli can you instead change the behavior to be 
more friendly?


My dislikes with build.py:
Have to specify path for each run (sometimes it can be dot hell):
  $ ../rel-eng/bin/build.py --srpm
compared to
  $ make srpm
And - no, I do not want to modify PATH since I have more then one 
checkout and I want to use the script from that checkout I'm currently 
using.


$ cat build.py.props
[buildconfig]
builder = spacewalk.releng.builder.Builder
tagger = spacewalk.releng.tagger.VersionTagger

Compare to:
$ cat Makefile
include ../../rel-eng/Makefile

Why should I care about some classes? Why can not I use some simple 
switch like:

KEEP_VERSION=1
I really do not want to study code of build.py when I create build.py.props





--
Miroslav Suchy
RHN Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel