Closed Bug 506502 Opened 10 years ago Closed 10 years ago

Remove "MOZ_BITS == 16" parts, in nsprpub (and m-c)

Categories

(NSPR :: NSPR, defect, trivial)

defect
Not set
trivial

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: sgautherie, Assigned: sgautherie)

References

()

Details

Attachments

(2 files, 1 obsolete file)

I assume MOZ_BITS could be used with a '64' value someday,
but it's '32' only nowadays and '16' is obsolete, is it not?
Yes, MOZ_BITS is obsolete.  NSS use USE_64=1 to create a build for
64-bit Windows.

We can remove the two Makefile.win files for nmake under 'dbm'.
(By the way, we should probably remove
  config/javarules.mak
  js/jsd/jsdshell.mak
  js/jsd/jsd.mak
which are also for nmake.)
Keywords: helpwanted
Whiteboard: [good first bug]
Assignee: wtc → sgautherie.bz
Status: NEW → ASSIGNED
Attachment #392138 - Flags: review?(wtc)
Comment on attachment 392138 [details] [diff] [review]
(Av1) Remove 2 Makefile.win for nmake
[See bug 512482 comment 9]


NB: Please, check if something like
http://mxr.mozilla.org/mozilla/source/db/makefile.win
is needed.
Attachment #392141 - Flags: review?(wtc) → review+
Comment on attachment 392141 [details] [diff] [review]
(Cv1) Remove "MOZ_BITS == 16" blocks
[Checkin: Comment 9]

r=wtc.

Serge, I just gave you CVS commit access to the NSPR trunk.
Please check in this patch on the NSPR trunk in CVS (not Hg).
Our tinderbox is the NSS tinderbox at
http://tinderbox.mozilla.org/showbuilds.cgi?tree=NSS

Thanks!
Attachment #392138 - Flags: review?(wtc) → review+
Comment on attachment 392138 [details] [diff] [review]
(Av1) Remove 2 Makefile.win for nmake
[See bug 512482 comment 9]

r=wtc.

mozilla/dbm is part of the "Security" module in CVS.  My status
in the Security module is lower, just a "peer", so I can't
unilateral give you CVS commit access.  One of us will check in
this patch for you.
Wan-Teh, IINM the DBM source code is inside the FIPS boundary, because the 
shared library that includes that code is inside the boundary.  Is it not?
Whiteboard: [good first bug] → [good first bug] FIPS
Keywords: checkin-needed
Comment on attachment 392141 [details] [diff] [review]
(Cv1) Remove "MOZ_BITS == 16" blocks
[Checkin: Comment 9]


http://bonsai.mozilla.org/cvsquery.cgi?module=NSPR&date=explicit&mindate=2009-08-04+11%3A07&maxdate=2009-08-04+11%3A07
Attachment #392141 - Attachment description: (Cv1) Remove "MOZ_BITS == 16" blocks → (Cv1) Remove "MOZ_BITS == 16" blocks [Checkin: Comment 9]
Nelson, yes, DBM is inside the FIPS boundary.  Thanks for the reminder.
With all the hi priority vulnerability issues being worked on now, I'm 
trying to understand why bugs like this one are being treated as high 
priority.
Attachment #392139 - Flags: review?(gal) → review+
Comment on attachment 392139 [details] [diff] [review]
(Bv1-MC) Remove (last) 3 *.mak
[Checkin: Comment 12]


http://hg.mozilla.org/mozilla-central/rev/e2cc9f1841d7
Attachment #392139 - Attachment description: (Bv1-MC) Remove (last) 3 *.mak → (Bv1-MC) Remove (last) 3 *.mak [Checkin: Comment 12]
(In reply to comment #7)
> (From update of attachment 392138 [details] [diff] [review])
> One of us will check in this patch for you.

Any hint about when?

(In reply to comment #10)
> DBM is inside the FIPS boundary.

What's the impact on check-in?
Whiteboard: [good first bug] FIPS → [c-n: Av1 to cvs=1.9.0] [good first bug] FIPS
The impact is that it will not get checked into any release for NSS for a 
long time to come (like, possibly a year or more).  It will get committed 
on a special branch of changes that are waiting for the NEXT FIPS release, 
which may be NSS 3.13.
Depends on: 512482
(In reply to comment #14)

Thanks for the explanation.
Moving check-in action to bug 512482.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Summary: Remove "MOZ_BITS == 16" parts (in dbm and nsprpub) → Remove "MOZ_BITS == 16" parts, in nsprpub (and m-c)
Whiteboard: [c-n: Av1 to cvs=1.9.0] [good first bug] FIPS
Wait, Maybe I'm hopelessly confused.
In some comments above, we were discussing DBM.  DBM is part of NSS.
NSS suffers from FIPS-induced delays, but this is an NSPR bug. 
NSPR does not suffer any FIPS-induced delays.
To the extent that this bug covers DBM, it is delayed by FIPS.  
To the extent that it is in NSPR, it is not delayed by FIPS.
(In reply to comment #16)

That's how I understood it:

> To the extent that this bug covers DBM, it is delayed by FIPS.  

Filed bug 512482.

> To the extent that it is in NSPR, it is not delayed by FIPS.

Morphed this very bug accordingly.
So, is the NSPR part of this bug all committed in CVS now?
(In reply to comment #18)

Yes: comment 9.
Attachment #392138 - Attachment description: (Av1) Remove 2 Makefile.win for nmake → (Av1) Remove 2 Makefile.win for nmake [See bug 512482 comment 9]
Attachment #392138 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.