These files should not exist after building



16 years ago
9 years ago


(Reporter: d_king, Unassigned)


Windows XP

Firefox Tracking Flags

(Not tracked)


(Whiteboard: bugday0420, URL)



16 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624

Whenever I refresh my tree with CVS after building, I get the following
messages. From looking at LXR, these files (i.e. don't exist, and
it appears that the directory they appear in doesn't exist either.

M mozilla/directory/c-sdk/config/Makefile
M mozilla/directory/c-sdk/ldap/clients/tools/Makefile
M mozilla/directory/c-sdk/ldap/libraries/libiutil/Makefile
M mozilla/directory/c-sdk/ldap/libraries/libldif/Makefile
M mozilla/directory/c-sdk/ldap/libraries/libssldap/Makefile

Seems to me that something somewhere is creating these when it shouldn't be.

Reproducible: Always

Steps to Reproduce:
1. Pull CVS files.
2. Build tree
3. Refresh tree (CVS checkout)
Actual Results:  
Orphaned Makefile's

Expected Results:  
They shuoldn't exist?

I'm going to do a bit of digging, but don't be surprised if I don't find
anything as this is somewhat out of my area of expertise (or even pretended

Oh, and reassign the component as needed because (as per normal) I couldn't sort
out which one was the right one.

Comment 1

16 years ago
Hmmm, looks like my CVS Checkout is complaining about these files, but not
changing other files in directory that have changed....I'm going to splash the
c-sdk dir, repull and rebuild.

Comment 2

16 years ago
OK, so pulling with CVS gives me these -

U mozilla/directory/c-sdk/ldap/libraries/libiutil/Makefile
U mozilla/directory/c-sdk/ldap/libraries/libiutil/Makefile.client
U mozilla/directory/c-sdk/ldap/libraries/libiutil/
U mozilla/directory/c-sdk/ldap/libraries/libiutil/README
U mozilla/directory/c-sdk/ldap/libraries/libiutil/iutil-lock.c

but knows nothing about them. I'm hoping it's just CVS-Mirror
that is out of sync with reality.... ;-)

Bumping severity as CVS-Mirror needs to be accurate.
Severity: trivial → major
Product: Browser → Seamonkey

Comment 3

10 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Moving to Build Config (please check if correct Product::Component)

I cannot check this (I don't compile Sm myself) but I suppose this CVS-related bug is either WONTFIX or WORKSFORME unless it is seen also on Mercurial mirrors.
Assignee: general → nobody
Component: General → Build Config
QA Contact: general → build-config
Whiteboard: bugday0420

Comment 5

9 years ago
Closing as INCOMPLETE for now. Please try to reproduce on current Mercurial-based setups, I suspect that just works there. I never see problems in my "hg status" that mention this.
Last Resolved: 9 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.