676757 - Provide nightly builds on the aurora channel

Status: RESOLVED FIXED

(Calendar :: Build Config, defect)

Description

[Matěj Cepl]

Attachment: error messages in the Javascript console

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.

Comment 1

[Matěj Cepl]

Attachment: about:support

Comment 2

[Matěj Cepl]

Attachment: actually timezone selector doesn't show even

Comment 3

[Matěj Cepl]

Attachment: data are not shown

Comment 4

[Philipp Kewisch [:Fallen][📱📆]]

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?

Comment 5

[Jay Rossiter]

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.

Comment 6

[Philipp Kewisch [:Fallen][📱📆]]

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

[Jay Rossiter]

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)

Comment 8

[Mark Banner (:standard8)]

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.

Comment 9

[Philipp Kewisch [:Fallen][📱📆]]

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?

Comment 10

[Mark Banner (:standard8)]

(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.

Comment 11

[Mark Banner (:standard8)]

Attachment: [checked in] Change lightning version to 1.0b6pre just for aurora

Just to go onto the aurora branch for now - bump the version to 1.0b6pre.

Comment 12

[Philipp Kewisch [:Fallen][📱📆]]

Comment on attachment 552041 [details] [diff] [review]
[checked in] Change lightning version to 1.0b6pre just for aurora

r=philipp

Comment 13

[Mark Banner (:standard8)]

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

Comment 14

[Mark Banner (:standard8)]

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.

Comment 15

[Mark Banner (:standard8)]

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

[Jay Rossiter]

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

Comment 17

[Mark Banner (:standard8)]

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?

Comment 18

[Philipp Kewisch [:Fallen][📱📆]]

> 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?

Comment 19

[Mark Banner (:standard8)]

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.

Comment 20

[John Hopkins (:jhopkins)]

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?

Comment 21

[Philipp Kewisch [:Fallen][📱📆]]

Nope, all we have is a manual patch on the master (I know, I know)

Comment 22

[Philipp Kewisch [:Fallen][📱📆]]

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?

Comment 23

[Mark Banner (:standard8)]

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.

Comment 24

[Philipp Kewisch [:Fallen][📱📆]]

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?

Comment 25

[Mark Banner (:standard8)]

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).