Closed Bug 327188 Opened 14 years ago Closed 14 years ago
Enable places by default
Per the product team meeting today, we're going to enable places by default after the nightly builds have finished tomorrow morning (15-Feb).
*** Bug 327196 has been marked as a duplicate of this bug. ***
This patch enables places by default for ffox/xulrunner, and fixes up toolkit/library and a few uses of LIBXUL_LIBRARY so that a places xulrunner builds correctly.
Comment on attachment 211909 [details] [diff] [review] Patch to be committed, rev. 1 I can sr, does someone like bryner need to r=?
Attachment #211909 - Flags: review?(bryner)
Comment on attachment 211909 [details] [diff] [review] Patch to be committed, rev. 1 not sure why storage has to move earlier in the build order, but r=me either way
Attachment #211909 - Flags: review?(bryner) → review+
Fixed on trunk. I needed to move storage above libxul in order to link it into libxul.
Equivalent 1.8 branch patch
Wouldn't this break the l10n builds? See http://lxr.mozilla.org/mozilla/source/browser/components/places/locale/README
Yes, it does. It doesn't break the build, but the places stuff is hard-linked into en-US.jar, which we remove during repackaging. If you move stuff into browser/locales/, please be sure to use good paths in the jar, namely jar:en-US.jar!/locale/en-US/browser/places
possible regression - BeOS builds broken in /storage. Builds were OK <24 hours ago.
(In reply to comment #9) > possible regression - BeOS builds broken in /storage. Builds were OK <24 hours > ago. > Bug 327471 opened for regression.
So... the tree's been closed for over 24 hours at this point due to this change. Is there an ETA for when we think we'll reopen it (either by getting the fallout fixed or by reverting the configure change until the necessary followup patches land)?
I turned off places in configure.in just now (not by reverting the whole patch above, just by commenting out the two occurances of MOZ_PLACES=1 in the application sections). We're going to get a handle on the leaks etc. and then turn this back on hopefully next week.
Matching changes checked in on the 1.8 branch, so this can be enabled on trunk and branch by simply un-commenting the # MOZ_PLACES=1 lines in configure.in
Note that the l10n part of this is not fixed yet AFAICT, that is, turning places on will break the l10n builds without showing that on the tinderboxens.
This seems to be enabled on trunk again - is that right?
It was re-enabled March 1 in the early evening US pacific time.
Should this be resolved fixed?
(In reply to comment #17) > Should this be resolved fixed? I think so.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Sorry for the bugspam, but I've been looking around, and I can't find any place where people are having a discussion about whether this feature is: a) The greatest thing since sliced bread. or b) An unusable poorly thought out broken wad of garbage. Is there such a forum? I'm in the b) category myself, but I'd really like to hear some arguments from those in the a) camp to show me the one true way.
(In reply to comment #19) > Sorry for the bugspam, but I've been looking around, and I can't find any place > where people are having a discussion about whether this feature is: > > a) The greatest thing since sliced bread. > or > b) An unusable poorly thought out broken wad of garbage. > > Is there such a forum? > > I'm in the b) category myself, but I'd really like to hear some arguments from > those in the a) camp to show me the one true way. > Have you seen this forum? http://forums.mozillazine.org/viewtopic.php?t=382152 You won't find many arguments from people in the a) camp though from what I have seen.
Component: Build Config → General
Product: Firefox → Firefox Build System
Target Milestone: Firefox 2 alpha1 → mozilla2 alpha1
You need to log in before you can comment on or make changes to this bug.