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)
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)
336 bytes,
patch
|
nelson
:
review+
samuel.sidler+old
:
approval1.9.1.2+
|
Details | Diff | Splinter Review |
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
Reporter | ||
Updated•15 years ago
|
Version: unspecified → trunk
Comment 1•15 years ago
|
||
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.
Reporter | ||
Comment 2•15 years ago
|
||
(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'.
Assignee | ||
Comment 3•15 years ago
|
||
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.)
Assignee | ||
Comment 4•15 years ago
|
||
This fixes the build break. Nelson, if this is OK, could you please also check it into NSS trunk?
Updated•15 years ago
|
Attachment #371913 -
Flags: review?(nelson) → review+
Comment 5•15 years ago
|
||
Comment on attachment 371913 [details] [diff] [review] fix r=nelson Checking in os2_rand.c; new revision: 1.9; previous revision: 1.8
Comment 6•15 years ago
|
||
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
Updated•15 years ago
|
Priority: -- → P2
Target Milestone: --- → 3.12.4
Version: trunk → 3.12.3
Comment 7•15 years ago
|
||
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.
Reporter | ||
Comment 8•15 years ago
|
||
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.
Assignee | ||
Comment 9•15 years ago
|
||
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. :-)
Comment 10•15 years ago
|
||
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.
Reporter | ||
Comment 12•15 years ago
|
||
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.
Assignee | ||
Comment 13•15 years ago
|
||
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?
Comment 14•15 years ago
|
||
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 15•15 years ago
|
||
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+
Comment 16•15 years ago
|
||
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.
Assignee | ||
Comment 17•15 years ago
|
||
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.)
Assignee | ||
Comment 18•15 years ago
|
||
Done that now: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/9e13c6ee8629
status1.9.1:
--- → .2-fixed
Comment 19•15 years ago
|
||
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.
Assignee | ||
Comment 20•15 years ago
|
||
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.)
Comment 21•15 years ago
|
||
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
Comment 22•15 years ago
|
||
Walter, Peter, could you help us verify this bug fix for 3.5.2?
Assignee | ||
Comment 23•15 years ago
|
||
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
Comment 24•15 years ago
|
||
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.
Description
•