Provide nightly builds on the aurora channel

RESOLVED FIXED

Status

defect
--
major
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: mcepl, Assigned: jhopkins)

Tracking

Trunk
x86_64
Linux
Dependency tree / graph

Details

Attachments

(5 attachments)

Reporter

Description

8 years ago
I have tried Earlybird and the latest Lightning (mostly intrigued by http://mozillalabs.com/messaging/eds-contacts-integration-for-thunderbird/ which looks absolutely awesome to me). Neither latest stable Lightning nor the latest nightly displays any data in my calendars.

Javascript console is full of error messages.
Reporter

Comment 1

8 years ago
Posted file about:support
Reporter

Comment 3

8 years ago
Posted image data are not shown
Reporter

Updated

8 years ago
Severity: normal → major
Native module at path '/home/matej/.thunderbird/69bvycnp.Zimbra/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components/libcalbasecomps.so' is incompatible with this version of Firefox, has version 8, expected 7.


We currently only offer nightly builds for Tb8 and Tb5, although thats obviously not correct. Our Tb5 nightly builds should move to aurora (Tb7).

jhopkins, do you think you could do the switch for us?
Component: General → Build Config
QA Contact: general → build
Summary: Last Lightning doesn't show any calendars (local or remote) with the current Earlybird → Provide nightly builds on the aurora channel

Comment 5

8 years ago
This has been affecting me for weeks now, ever since automatically Aurora migrated from 5.0 to 7.0.  I'd seen this discussion elsewhere (WRT build changes), so I'm baffled that this bug was only created... 120 minutes ago.  I thought it had been around for ages and was roadblocked by something.
It sbeen around for ages, but it hasn't been put in a bug yet. Sorry about that! In the future I hope we'll better be in sync with Thunderbird so this happens automatically.

Comment 7

8 years ago
The Calendar Versions wiki (https://developer.mozilla.org/en/Calendar/Calendar_Versions) could use updating in relation to this bug, as well.  It lists latest-comm-miramar as being appropriate for Aurora (which is listed as 6.0, not 7.0)
I've now landed changes to build Aurora rather than Miramar for Lightning. The Calendar1.0 tree is currently showing the new builds taking place:

http://tinderbox.mozilla.org/showbuilds.cgi?tree=Calendar1.0

I'm keeping comm-central closed for now as it is burning and the builders have had a clobber, so I expect it'll be a while before they are ready.

Changes I've done so far:

* Build comm-aurora instead of comm-miramar
* Disable the periodic scheduler on comm-central.
** This was set for every 6 hours and isn't really necessary these days, but just takes up more builder time. I've Therefore dropped it for now, we can always add it back later.
* Increased the periodic scheduler on comm-aurora from 6 hours to 10 hours.
** This will keep them on tinderbox for now, but if you use tinderboxpushlog, you'll probably still get reasonable results anyway.
* Disabled the nightly builders for comm-aurora.
** There's a few todos that I didn't have time for tonight, that I thought it best addressed before we push out nightly builds.

The todos:

* Check the mozconfigs are based on the same as Thunderbird's - I think we may have changed gcc versions, along the way for instance.
* Check the version number and the min/max compatibility range.

Philipp, if you disagree with anything let me know, hopefully we can get nightly builds enabled tomorrow fairly easily.
Assignee: nobody → mbanner
Sounds fine to me. One thing we should look into is patches that may be missing on aurora. When we did the 1.0b5 release, I cross-pushed changesets on comm-central and comm-miramar. I also transplanted a bunch of changes to comm-beta to make 1.0b5 compatible with Tb6. This might still mean that aurora is missing some changesets, but on the other hand, this might be auto-fixed on August 16th when the merge happens?
(In reply to Philipp Kewisch [:Fallen] from comment #9)
> This might still mean that
> aurora is missing some changesets, but on the other hand, this might be
> auto-fixed on August 16th when the merge happens?

Aurora will get "fixed" on 16th August, but then comm-beta won't have those fixes. So you'll need to move fixes across one way or another.
Just to go onto the aurora branch for now - bump the version to 1.0b6pre.
Attachment #552041 - Flags: review?(philipp)
Comment on attachment 552041 [details] [diff] [review]
[checked in] Change lightning version to 1.0b6pre just for aurora

r=philipp
Attachment #552041 - Flags: review?(philipp) → review+
Comment on attachment 552041 [details] [diff] [review]
[checked in] Change lightning version to 1.0b6pre just for aurora

Checked in: http://hg.mozilla.org/releases/comm-aurora/rev/7ef5c796fa98
Attachment #552041 - Attachment description: Change lightning version to 1.0b6pre just for aurora → [checked in] Change lightning version to 1.0b6pre just for aurora
I've also updated the mozconfigs for Lightning:

http://hg.mozilla.org/build/buildbot-configs/rev/0bd01fbdfcd4
http://hg.mozilla.org/build/buildbot-configs/rev/5184ab5a2d19

These switch the linux builders to gcc 4.5 (just like the Thunderbird ones), correct the symbol generation on linux32, and generally enable ccache and multiple cores where appropriate.

The builders have been clobbered and are currently building.
Depends on: 678013
First round of builds are here:

http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/latest-comm-aurora/

I've also enabled nightly builds to run each day (next run will be tomorrow now).

Comment 16

8 years ago
Thank you, Mark!  First build verified to be working on Thunderbird Aurora - Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a2) Gecko/20110811 Thunderbird/7.0a2 ID:20110811030037
I've just tried fixing the l10n nightlies, and I've got past the configure failure by stopping the nightlies getting the mozconfigs (because they don't need it).

Now they are stuck with no wget-en-US target. Philipp, any ideas?
> make wget-en-US
>  in dir /buildbot/comm-aurora-lightning-linux64-l10n-ext/build/comm-aurora //calendar/lightning (timeout 1200 secs)
> watching logfiles {}
> argv: ['make', 'wget-en-US']

It seems the object directory is not being expanded there and its broken for comm-central too. Maybe something in buildbot not passing the right environment?
Ok, my previous hack to get the mozconfig stuff working had broken the configuration of the build, but I also knew what I was working around had been fixed, so I backed that out.

Now we're onto the part where the upload is failing because the directory doesn't fully exist. This is where I pass over to jhopkins as I know there were some recent changes to how we upload things to the dated directories and I think that's probably what is affecting things here.
Assignee: mbanner → jhopkins
Assignee

Comment 20

8 years ago
Here's the "dated dirs" patch in our buildbotcustom fork:

https://hg.mozilla.org/users/gozer_mozillamessaging.com/buildbotcustom-thunderbird/rev/3a166f4d96d2

Is there a calendar buildbotcustom fork hosted somewhere?
Nope, all we have is a manual patch on the master (I know, I know)
Oh, l10n uploads failing! This also happens when the xpi could not be created because the locale is not fully translated. Maybe this is what you were seeing?
There's no errors on the repack step, and the upload step is saying:

d:/mozilla-build/python25/python2.5.exe ../../mozilla/build/upload.py --base-path ../../mozilla/dist/xpi-stage/  "../../mozilla/dist/xpi-stage/lightning-cs.xpi"
http://stage.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/2011/08/2011-08-25-00-44-33-comm-aurora-l10n/win32-xpi/lightning-cs.xpi
Traceback (most recent call last):
  File "/usr/local/bin/post_upload.py", line 448, in ?
    func(options, upload_dir, files)
  File "/usr/local/bin/post_upload.py", line 132, in ReleaseToDated
    os.symlink(longDir, shortDir)
OSError: [Errno 2] No such file or directory

So actually, I think it can't work out how/where to create the symlink which would likely mean we do need the patch that John is referencing.
Yes, taking a closer look you are right. How should we best set this up? Just apply the patch on the master, or do the real thing and make sure the buildbotcustom on the server is your fork, or even a new fork?
After applying the patch in comment 20 and finding this still didn't work, I added the --no-shortdir option to calling post_upload.py in calendar's extensionfactory.py. This has now fixed the redness, and we're getting green repacks again (note the repacks were being uploaded anyway, just the final bit of trying to do a symlink was failing).
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.