Closed Bug 487567 Opened 15 years ago Closed 15 years ago

OS/2 cannot sign softokn3.dll after upgrade to nss-3.12.3

Categories

(NSS :: Build, defect, P2)

3.12.3
x86
OS/2
defect

Tracking

(status1.9.1 .2-fixed)

VERIFIED FIXED
3.12.3.1
Tracking Status
status1.9.1 --- .2-fixed

People

(Reporter: wuno, Assigned: mozilla)

References

Details

(Keywords: verified1.9.1)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9.2a1pre) Gecko/20090406 Minefield/3.6a1pre
Build Identifier: 

E:\MOZBUILD1\NSS\shlibsign -v -i E:/mozbuild1/dist/lib/softokn3.DLL 
C_Initialize failed: 0x00000030, CKR_DEVICE_ERROR                    
NSPR error code: -5977: Failure to load dynamic library
Initiailzing softoken failed: 0x00000030, CKR_DEVICE_ERROR                    
NSPR error code: -5977: Failure to load dynamic library
moduleSpec configdir='' certPrefix='' keyPrefix='' secmod='' flags=noCertDB, noModDB
make.exe[5]: Leaving directory `E:/usr/src/hg/mozilla-central/security/nss/cmd/shlibsign'

This seems to be the culprit (much earlier in the log, however in contrast to other components, the build of the nss modules goes on after the error until it tries to sign the dlls)

In file included from E:/usr/src/hg/mozilla-central/security/nss/lib/freebl/sysrand.c:52:
E:/usr/src/hg/mozilla-central/security/nss/lib/freebl/os2_rand.c: In function 'EnumSystemFiles':
E:/usr/src/hg/mozilla-central/security/nss/lib/freebl/os2_rand.c:123: warning: missing initializer
E:/usr/src/hg/mozilla-central/security/nss/lib/freebl/os2_rand.c:123: warning: (near initialization for 'fileBuf.fdateCreation')
E:/usr/src/hg/mozilla-central/security/nss/lib/freebl/os2_rand.c:139: warning: pointer targets in passing argument 1 of 'DosFindFirst' differ in signedness
E:/usr/src/hg/mozilla-central/security/nss/lib/freebl/os2_rand.c:150: warning: format '%d' expects type 'int', but argument 2 has type 'APIRET'
E:/usr/src/hg/mozilla-central/security/nss/lib/freebl/os2_rand.c:155: warning: format '%d' expects type 'int', but argument 2 has type 'APIRET'
E:/usr/src/hg/mozilla-central/security/nss/lib/freebl/os2_rand.c:158: warning: format '%d' expects type 'int', but argument 2 has type 'APIRET'
E:/usr/src/hg/mozilla-central/security/nss/lib/freebl/os2_rand.c: In function 'RNG_SystemInfoForRNG':
E:/usr/src/hg/mozilla-central/security/nss/lib/freebl/os2_rand.c:233: warning: missing initializer
E:/usr/src/hg/mozilla-central/security/nss/lib/freebl/os2_rand.c:233: warning: (near initialization for 'cc.codepage')
E:/usr/src/hg/mozilla-central/security/nss/lib/freebl/os2_rand.c:234: warning: missing initializer
E:/usr/src/hg/mozilla-central/security/nss/lib/freebl/os2_rand.c:234: warning: (near initialization for 'ci.codepage')
E:/usr/src/hg/mozilla-central/security/nss/lib/freebl/os2_rand.c:281: warning: pointer targets in passing argument 2 of 'DosQueryCurrentDir' differ in signedness
E:/usr/src/hg/mozilla-central/security/nss/lib/freebl/os2_rand.c:288: warning: pointer targets in passing argument 1 of 'DosQueryPathInfo' differ in signedness
E:/usr/src/hg/mozilla-central/security/nss/lib/freebl/os2_rand.c: In function 'RNG_SystemRNG':
E:/usr/src/hg/mozilla-central/security/nss/lib/freebl/os2_rand.c:372: error: 'maxlen' undeclared (first use in this function)
E:/usr/src/hg/mozilla-central/security/nss/lib/freebl/os2_rand.c:372: error: (Each undeclared identifier is reported only once
E:/usr/src/hg/mozilla-central/security/nss/lib/freebl/os2_rand.c:372: error: for each function it appears in.)
make.exe[7]: *** [E:/mozbuild1/nss/freebl/OS2_SINGLE_SHLIB/sysrand.o] Error 1

had not yet time to investigate, what changed

Reproducible: Always
Version: unspecified → trunk
For a long time, the NSS team had a volunteer who build and tested NSS 
regularly on OS/2.  But I believe that stopped quite a while ago, and 
today, AFAIK, the NSS team has no one with an OS/2 system to test changes.

If you'd like to volunteer to assume that duty, we'd certainly consider 
a patch for this file.
(In reply to comment #1)
> If you'd like to volunteer to assume that duty, we'd certainly consider 
> a patch for this file.
Yes I could do that, I'm building regularly mozilla apps (cc,mc and 1.9.1). By that I regularly check what you pushed over to the mozilla tree, but of course I'm behind what concerns CVS HEAD of nss/dbm.

>E:/usr/src/hg/mozilla-central/security/nss/lib/freebl/os2_rand.c:372: error:
'maxlen' undeclared (first use in this function)
looking at the other platform_rand.c files it appears that the break is caused by a typo, 'maxlen' should probably reed 'maxLen'.
Damn, I look through the CVS checkins still to catch such stuff but I missed the checkin for bug 457045 on 2009-02-12. It really looks like a typo.

Walter, I think what Nelson meant was that we need a NSS maintainer who can build NSS standalone with the current CVS HEAD. We should talk to Julien Pierre about how to set that up. (I tried this when looking at bug 466745 but I failed in the end and just did what you suggested: I replaced the NSS part of mozilla-central with NSS from CVS HEAD and rebuilt... Of course that is missing the NSS test suite.)
Attached patch fixSplinter Review
This fixes the build break. Nelson, if this is OK, could you please also check it into NSS trunk?
Assignee: nobody → mozilla
Status: NEW → ASSIGNED
Attachment #371913 - Flags: review?(nelson)
Attachment #371913 - Flags: review?(nelson) → review+
Comment on attachment 371913 [details] [diff] [review]
fix

r=nelson
Checking in os2_rand.c; new revision: 1.9; previous revision: 1.8
Just FYI, NSS patches are still required to be CVS diffs, not Hg patches.
It was not a big deal for a one line patch, but for a larger patch ...
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Priority: -- → P2
Target Milestone: --- → 3.12.4
Version: trunk → 3.12.3
While my OS/2 virtual machine is currently broken, I do have hopes to eventually be able to check the NSS build again on OS/2. However, the QA never ran on it.
I just was able to set up a standalone nss build system checking out NSPR_4_7_4_RTM and NSS_3_12_3_RTM. I followed the (slightly outdated with respect to the actual tags) build instructions
http://www.mozilla.org/projects/security/pki/nss/nss-3.11.4/nss-3.11.4-build.html#build
set BUILD_OPT=1; set NS_USE_GCC=1; set NO_MDUPDATE=1
Building worked well, but again it moved on this time even after signing showed the same error, so after a build one has to carefully check the log. As Julien said, QA won't work. After correcting the typo in os2_rand.c, I couldn't find any errors in the log and signing worked too.

What I can do in the future is building nss from time to time and check, if the build doesn't break.
I found it however difficult to get information how to checkout HEAD or the most recent tag of nss as well as nspr.
Perhaps we (Walter and me) could be notified (CCed on the respective bug?) when a new NSS tag is going to be pushed to mozilla-central (or mozilla-1.9.1). Then we could do a last minute test. If we are offline at that point, then it's of course still bad luck for us...

Sorry about the diff format, I am so used to Hg by now that I didn't think to use CVS.

Walter, great that you were able to get that standalone build running. :-)
Peter, Walter,

We always try to keep the trunk of NSS buildable. You can check it any time you like, daily, weekly. If the OS/2 build is ever broken, you can file bugs anytime.
Unfortunately we often don't have a lot of advance visibility into exact release dates. If you had an OS/2 tinderbox, it would be great, but unfortunately it could only check the build since the NSS QA cannot run on OS/2 without major efforts.
Peter, do you see any possibility to fix the file in the mozilla-1.9.1-branch locally? Look eg at bug501605, that modified files belonging to nss w/o updating the nss version in the tree.
Our fix here would not harm any other platform and its only a typo fix, so in fact its risk for impacting anything else than OS/2 is virtually zero.
Comment on attachment 371913 [details] [diff] [review]
fix

I think we need official approval on this one, because it's NSS. Even though this only fixes an obvious typo in an OS/2-only file.
Attachment #371913 - Flags: approval1.9.1.1?
This bug will be fixed in Firefox when Mozilla resolves bug 504080.
I suggest you go put yourself on the CC list for that bug.
Comment on attachment 371913 [details] [diff] [review]
fix

Approved for 1.9.1.2. a=NPOTB, aka ss for release-drivers

Please land on mozilla-1.9.1 and use the ".2-fixed" option of the "status1.9.1" flag.
Attachment #371913 - Flags: approval1.9.1.1? → approval1.9.1.2+
Samuel, 
I take your request in comment 15 to be a request for a CVS tag for NSS that 
some member of the Firefox team can then pull and commit to various Hg trees.  

The NSS team in planning to create such a tag soon (within a few weeks, hopefully).  It will be NSS_3_12_4_RTM.
As it was my request and not the NSS team's I would have thought that I am allowed to exceptionally check in just that patch, as happened for bug 501605. (We really don't want to wait more weeks just to fix a typo.)
Peter, 
Mozilla does not support NSS.  The NSS team supports NSS.  The NSS team only
supports builds of NSS that correspond to CVS tags produced by the NSS team,
with VERY few exceptions that occur under dire MoCo need.  The NSS team uses
the CVS tree exclusively.  MoCo's Hg trees are "downstream" copies of 
snapshots of the NSS tree, using CVS "release tags".  

Now, if every individual who contributes to Firefox says "I really need this 
one change, and I'm not going to wait for a new NSS tag" and commits the 
change he wants into the Hg tree, then pretty soon, the NSS sources in Hg 
will have diverged significantly from what's in the CVS tree that the NSS 
team supports.  Firefox will have bugs that do not occur in the NSS team's 
copy of NSS, and the NSS team's answer to MoCo will be: make the NSS source 
in the Hg tree match a released CVS tag of NSS.  

From time to time, when the NSS team makes a new release tag, someone in 
MoCo updates MoCo's Hg tree to match the new NSS CVS tag.  When that happens,
changes that have been committed to the Hg tree will be lost, unless they 
have also been made in the CVS tree.  

I think it's unfortunate that Hg offers no checkin controls on portions of 
the Hg tree like those that existed in the CVS tree, and no easy way to ask 
"what are the differences to NSS files between date X and today?".  
But that's a headache that MoCo must live with.
Nelson, I am aware of all that and I agree that this should not spread. But I don't make the decisions here, that's done by the 1.9.1 the branch drivers. I assume that they also were aware of this, when they granted permission. (You certainly have a good point, but in this case it's just a single typo in code that Firefox considers "not part of the build" because it's OS/2-only. I don't think it would make a good case for anybody else who was trying to circumvent NSS tags.)
The bug fix is in NSS 3.12.3.1.

In the future, please work with the NSS team to create an official
NSS CVS tag and follow the procedure in
https://developer.mozilla.org/en/Updating_NSPR_or_NSS_in_mozilla-central
to push the NSS tag to Hg.
Target Milestone: 3.12.4 → 3.12.3.1
Walter, Peter, could you help us verify this bug fix for 3.5.2?
Yes, the typo was fixed, the build succeeds now. But there is no verified1.9.1.2 keyword, otherwise I would have marked this bug accordingly.
Status: RESOLVED → VERIFIED
Thanks, Peter. Starting with 3.5.2 we track verifications with the verified1.9.1 and the ".n-fixed" status1.9.1 flag.
Keywords: verified1.9.1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: