Closed Bug 538170 Opened 15 years ago Closed 15 years ago

Mac trunk builds failing running merge-installrdf.py

Categories

(Calendar :: Build Config, defect)

All
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: standard8, Assigned: gozer)

Details

The Mac trunk builds of Lightning are currently failing when they try to run merge-installrdf.py: http://tinderbox.mozilla.org/showlog.cgi?log=Sunbird/1262773881.1262778358.18198.gz /tools/python/bin/python /builds/buildbot/comm-central-lightning-macosx/build/build/merge-installrdf.py objdir-tb/ppc/mozilla/dist/thunderbird/Shredder.app/Contents/MacOS/extensions/\{e2fda1a4-762b-4020-b5ad-a41df1933103\} objdir-tb/i386/mozilla/dist/thunderbird/Shredder.app/Contents/MacOS/extensions/\{e2fda1a4-762b-4020-b5ad-a41df1933103\} > objdir-tb/ppc/mozilla/dist/thunderbird/Shredder.app/Contents/MacOS/extensions/\{e2fda1a4-762b-4020-b5ad-a41df1933103\}/install.rdf_ /bin/sh: objdir-tb/ppc/mozilla/dist/thunderbird/Shredder.app/Contents/MacOS/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/install.rdf_: No such file or directory make[1]: *** [postflight_all] Error 1 I tried building it myself and found that both directories: objdir-tb/ppc/mozilla/dist/thunderbird/Shredder.app/Contents/MacOS/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/ objdir-tb/i386/mozilla/dist/thunderbird/Shredder.app/Contents/MacOS/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/ don't actually exist. This looks like it is due to the fact that we've now got a packaging manifest on all platforms for Thunderbird, so Lightning isn't packaged and the extensions directory doesn't get copied into the location above. However, what I don't understand is that there also seems to be a DISABLE_LIGHTNING_INSTALL variable that is meant to disable that part of the process - and just the xpi-stage created xpi gets uploaded. So should a) buildbot be specifying DISABLE_LIGHTNING_INSTALL (will it still work and upload the correct bits)? or b) we need to tweak the Thunderbird packaging manifest to include Lightning (which I'd prefer not to do at this stage because that may start other complications).
Answering my own question, it looks like adding DISABLE_LIGHTNING_INSTALL is the way to go as buildbot uploads from objdir-tb/mozilla/dist/xpi-stage/{lightning,gdata-provider}.xpi So can this be added to mozconfig, or does it need adding to the build environment?
Just a short note since I need to run, but isn't this already in some of our mozconfigs? I think it needs to be part of the env, since its not an mk_ option. Maybe we should look at what windows does.
Flags: blocking-calendar1.0+
As discussed on irc with Fallen, I tried adding this to the .mozconfig, however that didn't work. So I then tried it locally in a variety of ways and found that the build would complete if DISABLE_LIGHTNING_INSTALL was set in the environment. Therefore passing to gozer. We need DISABLE_LIGHTNING_INSTALL=1 set in the environment for at least the compilation step of Lightning builds on trunk/1.9.2 branches please.
Assignee: nobody → gozer
Mark, did you also try "export DISABLE_LIGHTNING_INSTALL=1" in the mozconfig? I've seen this for other variables in other mozconfigs before.
(In reply to comment #4) > Mark, did you also try "export DISABLE_LIGHTNING_INSTALL=1" in the mozconfig? > I've seen this for other variables in other mozconfigs before. Hmm, I forgot that option, although I did try just "DISABLE_LIGHTNING_INSTALL=1". I'll try it now.
(In reply to comment #5) > (In reply to comment #4) > > Mark, did you also try "export DISABLE_LIGHTNING_INSTALL=1" in the mozconfig? > > I've seen this for other variables in other mozconfigs before. > > Hmm, I forgot that option, although I did try just > "DISABLE_LIGHTNING_INSTALL=1". I'll try it now. Nope, that doesn't work. Definitely needs setting in global environment.
changeset: 1945:bf4046488667 tag: tip user: Philippe M. Chiasson <gozer@mozillamessaging.com> date: Thu Jan 14 12:24:34 2010 -0500 summary: Bug 538170 - Add DISABLE_LIGHTNING_INSTALL to comm-central lightning builds
gozer, can this bug be closed, or is there anything else you'd like to take care of here?
(In reply to comment #8) > gozer, can this bug be closed, or is there anything else you'd like to take > care of here? We can close this - I suspect gozer didn't know about what to look for. I had been waiting to see the nightly go green as well and had forgotten about it.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.