Bug 448155 introduces showing the mozilla-central repo/changeset URL in about:buildconfig, we should investigate if it makes sense and we find a good solution to also show the comm-central changeset for comm-central-based apps. Maybe we even find a generic solution that all XULRunner-based apps can use to get their own repo/changeset in there.

I think we should keep the existing about:buildconfig with the info it has, as it's the "platform" configuration. (As I said, if you were running on XULrunner, I'd expect it to look that way.) However, we should figure out a way to get info about the app in there as well. I just had a crazy idea, though. Maybe we can make a way for apps to override the about:buildconfig URL, to show their own page, which could then include the original page in an iframe or something? (Or just put the two pages as a frameset?)

Two possibilities (amongst many I expect): 1) comm-central creates and generates its own version of buildconfig.html 2) buildconfig.html is changed so that where the source is inserted it is more generic, hence we could process it a second time in the comm-central adding an extra line to it.

Here's a proof of concept of my proposed solution. This change makes nsAboutRedirector check the pref "app.buildconfig.url", and if set, makes about:buildconfig redirect there instead of the existing URL. It also adds an "about:platformbuildconfig" URL (sucky, I know) that always points to the default buildconfig.html. Finally, it adds a buildconfigsample.html (which winds up in the same location as buildconfig.html), that has some content, and an <iframe src="about:platformbuildconfig>. To try this out, apply this patch and rebuild, then set the pref "app.buildconfig.url" to "chrome://global/content/buildconfigsample.html" and restart your browser. Then load about:buildconfig, and it should show the new page, with the original page in an iframe. This should be a workable solution for any app. Just write your own buildconfig page, however you'd like, optionally include the original in a frame, and then set the pref to point to whatever chrome URL your new buildconfig page is at. The implementation leaves a bit to be desired though.

Here's what the sample looks like.

Would there be a way to simply overlay about:buildconfig with comm-central data? (as Ted suggested in bug 479755 comment 1.) NB: Hoping the situation (wrt application.ini/platform.ini/etc) is "even better" now than it was 3 months ago, fwiw.

I don't think you can do that, no. My proof of concept here works, it just has some ugly bits that would need to be smoothed out.

Wouldn't the simpler option be to do something like: messenger.jar: *+ content/messenger/buildconfig.html (buildconfig-comm-central.html) % override chrome://global/content/buildconfig.html chrome://messenger/content/buildconfig.html Which is pretty much the same as we currently do with license.html? (in this case we'd just be maintaining our own copy of buildconfig.html rather than processing the toolkit version slightly differently).

I just hacked this together in a few minutes (there's bugs in it, don't try and review it). It overrides toolkit's buildconfig.html with our own - which we can generate ourselves. As the patch indicates I was going to do this generically for all of comm-central. I started pondering if SeaMonkey wanted to do something different for extension versions - but then I realised that extensions really need to look after themselves (e.g. extensions updated in the profile) and therefore extension changesets don't really apply. So I think if I can find an appropriate non-core jar location (or way of selecting the jar), then we can have this generic for all comm-central applications.

Sure, if you want to process your own buildconfig completely, that's fine. My proposal, although hacky in ways, would be workable for an app built on top of a xulrunner SDK as well.

I'd expect that to fail for universal builds - see http://mxr.mozilla.org/comm-central/source/mozilla/build/macosx/universal/fix-buildconfig#47 If you want to replace content/global/buildconfig.html, why not do the simple thing? toolkit.jar: * content/global/buildconfig.html (buildconfig.html) (The only time you ever need *+ is when you think someone might remove preprocessing (which always replaces), which they won't here, and you want to ensure that they leave the + to still replace newer files, which they probably wouldn't know to do unless you add a comment saying why it's *+, in which case the comment could just say "This needs to be either * or +, to always replace.")

(In reply to comment #11) > I'd expect that to fail for universal builds - see > http://mxr.mozilla.org/comm-central/source/mozilla/build/macosx/universal/fix-buildconfig#47 damn, forgot about that. > If you want to replace content/global/buildconfig.html, why not do the simple > thing? Because you can't replace something in toolkit.jar if you become an xulrunner build. I think Ted's way may work better, but I can't really see how to sensibly get the source information into it (including the args) - I guess buildconfigsample.html would be in comm-central and we'd need to do something similar to call fix-buildconfig if we wanted the comm-central build arguments displayed.

How much do we care about getting "second configure" arguments into about:buildconfig? Is it that common outside of comm-*, and is it a blocker for comm-*? For the simple case (e.g., apps that just want to put their own changeset in buildconfig), wouldn't it be simpler if buildconfig was already set up with extra changeset blocks and apps just pushed their defines in? Or are the requirements for XULRunner that this not be a build-time thing, but rather something that can be done entirely at runtime? And/or do defines set in comm-* apps' app-config.mk not propagate into mozilla-*? Attached is a POC to do what I suggested above (both toolkit/content/buildconfig.html plus camino/app-config.mk to illustrate the define-setting), with two APP_* blocks pre-inserted in buildconfig.html (SeaMonkey or other apps may want more, but you get the point). Any unused blocks get preprocessed out, so it's a no-op for Firefox/anyone who doesn't care.

How about making the buildconfig.html and xhtml and have an empty content DTD file, which apps can overload with an non-empty one? We could probably even insert a DTD block for the source info for localized builds the same way.

Smokey: I don't think anyone has decided that either of a build time vs. run time solution are better. My POC is a bit complicated but works at run time, but it may not be worth that complexity.

Ted: OK. I wasn't sure what the requirements, scope, and technical constraints for this bug (and its fix) were ;) The summary only mentions changesets, but the dupe also mentioned the two sets of configure args (which I apparently misread as "wanting them in separate blocks" rather than "stripping out duplicate parts"); your solution was run-time but standard8's was build-time, and so forth.

I wondered earlier how to find out the comm-central rev a SeaMonkey build is built from. Is anyone still working on this bug?

(In reply to comment #18) You have to look at the files, either on ftp or in the zip.

(In reply to comment #18) > I wondered earlier how to find out the comm-central rev a SeaMonkey build is > built from. You can check the "build info" .txt files that live in the same directory on the ftp site, since due to "bugs" in the current impl, that gives you the c-c rev rather than the m-c one (the new impl in bug 549958 will give you both; we have to wait on Socorro 1.8 to be deployed before it can be landed). > Is anyone still working on this bug? I'm happy to continue working on my proposal if there's a decision that it is the desired way to go. (I could probably be convinced to implement Axel's, too; it might be a middle-ground solution that's relatively simple to implement in Gecko and for consumers like my POC, but which allows run-time substitution of the changesets rather than requiring processing of buildconfig.html at build-time, which would be friendly to prebuilt-XULRunner consumers.)

The good news here is that I have an implementation of what I think Axel suggested, and it works wonderfully on 1.9.2. We (non-Firefox apps) can generate the needed .dtd (and chrome packaging/directive) at build-time, but the substitution happens at runtime, so that people using apps based on stock XULRunner, for instance, can also add their changeset info without having to compile the toolkit (generating their dtd and chrome packaging/directive however fits into their app's build system). On the other hand, I've been pulling my hair out for the last two days tracking down obscure failures trying to get it working on mozilla-central (where I can no longer build Universal); I think I've tracked the last failure down to bug 600133, but we'll see.

(In reply to comment #21) > obscure failures trying to get it working on mozilla-central (where I can > no longer build Universal); A fix similar to the one we made in bug 599796 should be able to help with building universal. Note that PPC is in the process of being desupported on m-c but right now it's been downgraded to "builds but isn't actively maintained or shipped for Firefox".

Here's the circa September 2010 patch for using a .dtd for additional source info and converting buildconfig to .xhtml. It probably doesn't apply anymore, but it's doing no-one any good sitting on my HD, either. Expected use-case is that non-Firefox apps generate a buildconfig.dtd with the proper changeset info during their build process and jar it up with an override URL, allowing the buildconfig.xhtml to display a non-empty secondarySourceInfo entity. E.g., for Camino, we'd add this goop (probably the same goop as you're using for bug 549958) to the Makefile that controls our jarring (geckochrome/Makefile.in): # make+shell+sed = awful _dollar=$$ APP_REPO := $(shell cd $(topsrcdir)/$(MOZ_BUILD_APP) && hg showconfig paths.default 2>/dev/null | head -n1 | sed -e "s/^ssh:/http:/" -e "s/\/$(_dollar)//" ) ifdef APP_REPO DEFINES += -DAPP_REPO="$(APP_REPO)" endif APP_CHANGESET := $(shell hg -R $(topsrcdir)/$(MOZ_BUILD_APP) parent --template="{node|short}\n" 2>/dev/null) ifdef APP_CHANGESET DEFINES += -DAPP_CHANGESET="$(APP_CHANGESET)" endif and our geckochrome/content/global/buildconfig.dtd would have the following two lines as contents: #filter substitution <!ENTITY secondarySourceInfo '<p>Built from <a href="@APP_REPO@/rev/@APP_CHANGESET@">@APP_REPO@/rev/@APP_CHANGESET@</a></p>'> and we'd add these three lines to our geckochrome/jar.mn: # Include our changeset information in about:buildconfig *+ content/camino/buildconfig.dtd (content/global/buildconfig.dtd) % override chrome://global/content/buildconfig.dtd chrome://camino/content/buildconfig.dtd As it's probably very obvious by now, I don't have the time to see this through into the tree, but I offer up the patch in the hopes that it's helpful to my friends in Tb- and Sm-land, and that one of their fabulous build-hackers might want to update it to the tip and push it through.

In reply to comment #24: Does this replace the "Built from <mozilla-central URL>" in about:buildconfig or add to it? IMHO it would be better to have both, both when trying to narrow down a culprit (which could be in comm-central or mozilla-central) from a regression range, and when determining if we've got a nightly or hourly from after a given fix (which would be in either comm-central or mozilla-central) in order to VERIFY the fix. I'd even be so bold as to say that (if we can't have both) it's more important to have the mozilla-central changeset than the comm-central one, because there are more changes per unit of time in mozilla-central.

(In reply to Tony Mechelynck [:tonymec] from comment #25) > In reply to comment #24: > Does this replace the "Built from <mozilla-central URL>" in > about:buildconfig or add to it? It allows non-Firefox applications the ability to add one or many additional URLs (or whatever the non-Firefox application desires to add, really; they can ship whatever contents in the DTD that are valid in a DTD) to the stock Gecko repository URL, which is not changed. Attached is a screenshot of about:buildconfig in Camino from when I was implementing attachment 556364 [details] [diff] [review].

In reply to comment #26: ah, OK, so it's "in addition to", not "instead of". You relieve my fears. :-)

Workaround (not for the faint of heart — yet): The next version of the Nightly Tester Tools extension will by default paste the following (in the SeaMonkey trunk hourly I'm running ATM) when using its menuitem "Tools → Nightly Tester Tools → Insert Build ID into Textbox": Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Firefox/17.0 SeaMonkey/2.14a1 ID:20120731025549 CSet: 9fbaed739443 The "CSet" is the comm-central changeset here. (In Firefox of course it isn't.) The current version from AMO (3.3) doesn't do it right though. See https://github.com/mozilla/nightlytt (and scroll down the page) about how to clone the git master and produce an xpi from it by means of the ant utility. (The first install method didn't work for me.)

(In reply to Serge Gautherie (:sgautherie) from comment #6) > Would there be a way to simply overlay about:buildconfig with comm-central > data? > (as Ted suggested in bug 479755 comment 1.) > > NB: Hoping the situation (wrt application.ini/platform.ini/etc) is "even > better" now than it was 3 months ago, fwiw. application.ini has been broken since 2016/Feb/12. See Bug 1267270. And also "Nightly Tester Tools" has been broken. So, there are no way to determine c-c cset from executable. Please fix this or Bug 1267270.

(In reply to Alice0775 White from comment #31) > (In reply to Serge Gautherie (:sgautherie) from comment #6) > > Would there be a way to simply overlay about:buildconfig with comm-central > > data? > > (as Ted suggested in bug 479755 comment 1.) > > > > NB: Hoping the situation (wrt application.ini/platform.ini/etc) is "even > > better" now than it was 3 months ago, fwiw. > > application.ini has been broken since 2016/Feb/12. See Bug 1267270. > And also "Nightly Tester Tools" has been broken. > > So, there are no way to determine c-c cset from executable. > Please fix this or Bug 1267270. Actually, the CSID shown in SeaMonkey, be it in about:buildconfig, in seamonkey-2.48a1.en-US.linux-x86_64.txt, or in Nightly Tester Tools development version's ${Changeset} and ${PlatformChangeset}, is now the comm-central CSID everywhere (twice, in long and short form, in the .txt file). It is the mozilla-central CSID which cannot be determined in SeaMonkey anymore. This is a recent development, much later than comment #31. about:buildconfig used to have the mozilla-central CSID, and seamonkey-2.48a1.en-US.linux-x86_64.txt used to have both. NTT used to have the comm-central CSID in ${Changeset} (all versions) and the mozilla-central CSID in ${PlatformChangeset} (development version only), but the latter has been broken for some time, possibly since before comment #31, I'm not sure. I was about to open a new bug in SeaMonkey :: Build Config, but for the time being this bug seems to cover the problem already. :xabolcs, :frg, and others, if you think there is more than just a Toolkit problem, feel free to open an additional bug.

In reply to comment #32 There was a gap with no SeaMonkey trunk nightlies for any platform between 2016-08-10 (which has both CSIDs in its .txt file = "Good") and 2016-08-15 (which has comm-central twice = "Bad"). I'll file a bug for this in SeaMonkey :: Build Config, since it is not directly related to about:buildconfig.

UA:"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49a1" ID:20161025003001 en-US c-c:2294e347fd430898dfb226cf61b1496cd031d475 m-c:c845bfd0accb7e0c29b41713255963b08006e701 Maybe as a result of the fix for bug 1298719, about:buildconfig now displays the comm-central CSID, but OTOH it has lost the mozilla-central CSID.

(mobile-browser and camino is removed from the title because these are now discontinued.) According to the title, this bug is not SeaMonkey Specific. If you need SeaMonkey specific work for this, Please file a new bug.