41349 - Need updates to client.mk to allow OS/2 to pull code

Status: VERIFIED FIXED

(SeaMonkey :: Build Config, defect, P3)

Description

[Mike Kaply [:mkaply]]

Need updates to client.mk to allow OS/2 to pull code

Comment 1

[cls]

Details?

Comment 2

[Mike Kaply [:mkaply]]

Assign it to me.

It is a valid bug, but I was conducting a little test to see if anyone gets 
automatically notified because I set the platform to OS/2

The answer was no.

What we are going to have to do for this bug is either:

a. Change client.mk to have platform checks in it (perhaps using uname)

or

b. Create a client.os2.mk

Our basic problems are the SH being /bin/sh (needs to be sh) and for some reason 
the first two line in real_checkout don't work on OS/2 - if we comment them out 
the checkout happens.

Comment 3

[Jon Granrose]

actually, both cls and I get notified.  bugzilla automatically notifies the 
reporter, owner, and QA contact whenever a bug is created or modified.

anyone else you want to be notified you have to put on the cc.  if you want 
yourself or someone else to be automatically notified for any OS/2 bugs, you'd 
want to ask about that on the netscape.public.mozilla.webtools or bugzilla 
newsgroups.

Comment 4

[Mike Kaply [:mkaply]]

Attachment: Client.mk changes for checkout in rootdir

Comment 5

[Mike Kaply [:mkaply]]

OK, I found a big part of our problem and here is a patch.

This problem is probably recreateable on Unix.

If you do a build in /mozilla, than the ROOTDIR becomes // rather than / when 
used everywhere because /FILENAME gets concatenated to it.

So whenever the ROOTDIR comes back /, we make it /.

Let me know what you think.

Note this would be typical in a PC build - create a dir mozilla, do a build.

Thanks

Comment 6

[cls]

Looks good to me. r=cls

Comment 7

[Mike Kaply [:mkaply]]

Should I check it in?

Lead said I can check in on the M16 branch. Do you think this is OK for that?

Comment 8

[Mike Kaply [:mkaply]]

OK, next set of problems (actually the last)

The following lines in client.mk break us, I don't know why:

	@: Backup the last checkout log.

	@: Start the checkout. Split the output to the tty and a log file. \
	 : If it fails, touch an error file because "tee" hides the error.

	@: Check the log for conflicts. ;\

Our gmake gives an error. I have no idea why.

What exactly do these lines do? Are they just comments? Do they output to a log 
or to the screen? What is the @: command to gbash?

Thanks

Comment 9

[cls]

The patch is fine for M16.  
@: blah blah is basically a comment
gmake doesn't echo commands that start with @ . And : is basically a no op 
command for bash.  Can you run do ': blah blah' from the bash command line?

Comment 10

[Mike Kaply [:mkaply]]

That's the strange part. : blah blah works find from the command line 
in the bash shell.

The error I get from gmake is:

gmake: :: Command not found

Comment 11

[Mike Kaply [:mkaply]]

One more problem

PSM_CO_TAG = SECURITY_CLIENT_BRANCH

SECURITY_CLIENT_BRANCH is way old.

It doesn't look like the crypto team is updating their static tag.

We need a later SECURITY_CLIENT_BRANCH that has the OS/2 changes in it.

Comment 12

[cls]

Ugh.  It sounds like another bug in your gmake port.  As far as I'm concerned, 
the @: comments can be converted to #.  I was under the impression that changes 
to PSM client were going to occur on the SECURITY_CLIENT_BRANCH as well as the 
tip?  

Comment 13

[Mike Kaply [:mkaply]]

Should I interpret that as permission to comment out the lines?

As far as the SECURITY_CLIENT_BRANCH, it looks like changes are NOT going there.

Checkout newproto.c in security/psm/lib/protocol

The OS/2 change went in at 1.2 and never made it in a branch.

Any idea who I would talk to?

Comment 14

[cls]

Yes, comment out the lines.  I was hoping thayes knew of someone in the psm
group that could update the client branch if necessary.  Let's try welch.

Comment 15

[Mike Kaply [:mkaply]]

I think I might understand the : thing - we are invoking gmake from our OS 
command processor, NOT bash. Normally, when bash is needed, the makefile does 
$(shell pwd) and because shell is set to gbash, these lines work.

But if gmake is invoked from a non bash shell, these lines fail because they are 
not OS commands.

I will test this hypothesis later, but I think the result is kind of irrelevant 
as $(shell) would just clutter the code. They should probably have just been 
comments in the first place.

Comment 16

[Terry Hayes]

For changes to code in mozilla/security you can make changes to the 
SECURITY_CLIENT_BRANCH (for build problems and other immediate requirements).  
However, these changes need to be merge onto the tip as well.  You can do that 
yourself, or you can wait for us to do it when we move the client tag.  (I'd 
prefer the former, I think -- however it will be more trouble for you).

The client tag is not "way old"; it just doesn't have the latest new features 
that are being staged for release.

Comment 17

[Mike Kaply [:mkaply]]

Is M16 going to use the SECURITY_CLIENT_BRANCH?

Or will there be a new security tag/branch for M16?

Comment 18

[Jon Granrose]

milestones only use the milestone tag, in this case SeaMonkey_M16_BRANCH.  We 
pull a tree using client.mk on unix, tag it, and then all future pulls are done 
with the branch tag.  client.mk uses SECURITY_CLIENT_BRANCH on the trunk.

Comment 19

[snizinsk]

fixed

Comment 20

[Jon Granrose]

verified.

rereading my comments on SECURITY_CLIENT_BRANCH they weren't very clear.  The
tip pulls using that branch, and that branch tag is periodically moved forward
by the security team when the tip is deemed stable and/or milestone.