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. Makefile.in) 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 expertise). Oh, and reassign the component as needed because (as per normal) I couldn't sort out which one was the right one.
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.
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/Makefile.in U mozilla/directory/c-sdk/ldap/libraries/libiutil/README U mozilla/directory/c-sdk/ldap/libraries/libiutil/iutil-lock.c but lxr.mozilla.org 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
MASS-CHANGE: 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
Status: NEW → UNCONFIRMED
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
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.