Create a project branch for Add-ons Manager Rewrite

VERIFIED FIXED

Status

Release Engineering
Other
VERIFIED FIXED
7 years ago
4 years ago

People

(Reporter: mossop, Assigned: lsblakk)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(8 attachments, 9 obsolete attachments)

6.45 KB, patch
Details | Diff | Splinter Review
780 bytes, text/plain
Details
10.45 KB, patch
nthomas
: review+
lsblakk
: checked-in+
Details | Diff | Splinter Review
9.51 KB, patch
aki
: review+
lsblakk
: checked-in+
Details | Diff | Splinter Review
10.23 KB, patch
nthomas
: review+
alice
: review+
lsblakk
: checked-in+
Details | Diff | Splinter Review
8.63 KB, patch
aki
: review+
lsblakk
: checked-in+
Details | Diff | Splinter Review
5.44 KB, patch
aki
: review+
lsblakk
: checked-in+
Details | Diff | Splinter Review
3.98 KB, patch
nthomas
: review+
lsblakk
: checked-in+
Details | Diff | Splinter Review
(Reporter)

Description

7 years ago
*do you want builds?

Yes, all OS supported by trunk

** incremental-build-on-checkin?

Yes

** nightlies?

No (assuming we still get to download regular builds)

** Are en-US builds enough, with no l10n? y/n

Just en-US is fine

* do you want unittests?

All unittests run on mozilla-central

* do you want talos?

Talos on all OS like mozilla-central but we probably don't need sunspider, dhtml, svg or gfx testing. Startup, shutdown and page load are the main things we are interested in monitoring.

*name of branch owner

Mossop

*timeline:
** when can we start project branch

As soon as practical

** approx expected life span of project branch - if known?

The main project should be complete and merged to mozilla-central by April however we may decide to keep the branch open at that point to work on other large scale changes.

*misc:
** need any changes to toolchain used in m-c?

Nope

** need any changes to the compile/link/repack steps used in m-c?

Nope

** preference on tinderbox waterfall name?

ExtensibleMonkey?

** preference on where to put builds on ftp.m.o?

extensible-monkey?

** preference on name of project branch in hg?

projects/extensible-monkey

** what unofficial projectname do you want on this project branch?

Just keeping Minefield should be fine I think
(Reporter)

Comment 1

7 years ago
From talking with joduinn, just use Addons as the name for this branch.
(Assignee)

Updated

7 years ago
Assignee: nobody → lsblakk
Any ETA on this?
(Assignee)

Comment 3

7 years ago
What repo will this branch be using? If it doesn't already exist, we will need to file a bug asking for the repo to be created.  Let's use projects/addons if there's not already one set up.
(Assignee)

Comment 4

7 years ago
(In reply to comment #2)
> Any ETA on this?

I'll get patches together to test this in staging, only hold up here is a repo.
(Assignee)

Comment 5

7 years ago
(In reply to comment #2)
> Any ETA on this?

So more specifically - it generally takes about 2 weeks end-to-end with a branch that has no special needs (such as this one).  I'll do my best to improve on that but some of it is just procedural, testing and whatnot, before going live in production.
(Reporter)

Updated

7 years ago
Depends on: 549357
(Assignee)

Comment 6

7 years ago
Tinderbox tree "Addons" has been created for this branch.
(In reply to comment #1)
> From talking with joduinn, just use Addons as the name for this branch.

Addons seems way too vague for something dealing with the Add-ons Manager... How about AddonsMgr or something?
(Assignee)

Comment 8

7 years ago
It's not vague compared to other branch names in our configs - Addons is short and succinct and works just fine in a list with "Places", "Electrolysis" and "Tracemonkey" so let's not bikeshed on the project name.
(In reply to comment #8)
> It's not vague compared to other branch names in our configs - Addons is short
> and succinct and works just fine in a list with "Places", "Electrolysis" and
> "Tracemonkey" so let's not bikeshed on the project name.

Places, Electrolysis, and Tracemonkey all refer to specific things... Addons, however, refers to a ton of different things. It's just going to be confusing.
This is an internal-facing config naming that only matters for the repo, the tinderbox tree, and the build/unittest waterfalls.  There's nothing to be "confused" about here since there is no other addon related work in those places. 
As we learned with the recent Firefox-Lorentz/Lorentz branch, we need consistent naming across the board and "addons" is short and clear. 

No other build or performance testing is related to addons and if at some point another project branch is created it can use addons-{new branch's purpose}.
Okay, we'll go with "addonsmgr" across the board.  /bikeshed
Created attachment 429608 [details] [diff] [review]
Add addonsmgr to graphserver
Created attachment 429609 [details] [diff] [review]
[untested] staging configs for addonsmgr

will test this once repo exists.
(Reporter)

Comment 14

7 years ago
(In reply to comment #13)
> Created an attachment (id=429609) [details]
> [untested] staging configs for addonsmgr
> 
> will test this once repo exists.

The repo exists, shall I push a copy of mozilla-central into it?
Yes, please do that so there's something to check out for staging tests.
(Reporter)

Comment 16

7 years ago
I've pushed a copy of mozilla-central to the repository
OS: Mac OS X → All
Hardware: x86 → All
Requesting the following be added to staging-graphserver for testing:

insert into branches values (NULL,"Addonsmgr");
insert into machines values (NULL,6,0,NULL,"Linux_addonsmgr",1,unix_timestamp());
insert into machines values (NULL,6,0,NULL,"Linux_addonsmgr_leak_test",1,unix_timestamp());
insert into machines values (NULL,7,0,NULL,"OS_X_10.5.2_addonsmgr",1,unix_timestamp());
insert into machines values (NULL,7,0,NULL,"OS_X_10.5.2_addonsmgr_leak_test",1,unix_timestamp());
insert into machines values (NULL,8,0,NULL,"WINNT_5.2_addonsmgr",1,unix_timestamp());
insert into machines values (NULL,8,0,NULL,"WINNT_5.2_addonsmgr_leak_test",1,unix_timestamp());
insert into machines values (NULL,18,0,NULL,"Linux_x86-64_addonsmgr",1,unix_timestamp());
insert into machines values (NULL,18,0,NULL,"Linux_x86-64_addonsmgr_leak_test",1,unix_timestamp());
Created attachment 429863 [details]
insert statements for graphServer db
(Assignee)

Updated

7 years ago
Attachment #429863 - Attachment mime type: application/octet-stream → text/plain
Created attachment 430468 [details]
insert sql for addonsmgr to staging-graphserver
Comment on attachment 430468 [details]
insert sql for addonsmgr to staging-graphserver

oops - dupe.
Attachment #430468 - Attachment is obsolete: true
Created attachment 431226 [details] [diff] [review]
[Tested] staging configs for addonsmgr
Attachment #429609 - Attachment is obsolete: true
Attachment #431226 - Flags: review?(nrthomas)
Created attachment 431227 [details] [diff] [review]
Production configs for addonsmgr
Attachment #431227 - Flags: review?(nrthomas)
Comment on attachment 431226 [details] [diff] [review]
[Tested] staging configs for addonsmgr

>diff --git a/mozilla2-staging/config.py b/mozilla2-staging/config.py
>+BRANCHES['addonsmgr']['platforms']['win32']['profiled_build'] = False

I think we should leave this on so that win32 talos results are comparable to m-c, so just remove this line.

>+# Enable unit tests
>+BRANCHES['addonsmgr']['platforms']['linux']['enable_unittests'] = True
>+BRANCHES['addonsmgr']['platforms']['linux64']['enable_unittests'] = True
>+BRANCHES['addonsmgr']['platforms']['macosx']['enable_unittests'] = True
>+BRANCHES['addonsmgr']['platforms']['win32']['enable_unittests'] = True

We should just use the opt and debug packaged tests if we want to match m-c, so False for these. And add the 4 lines like
 BRANCHES['addonsmgr']['platforms']['linux-debug']['enable_unittests'] = True

>+BRANCHES['addonsmgr']['platforms']['linux']['update_platform'] = 'fake'
>+BRANCHES['addonsmgr']['platforms']['linux64']['update_platform'] = 'fake'
>+BRANCHES['addonsmgr']['platforms']['win32']['update_platform'] = 'fake'
>+BRANCHES['addonsmgr']['platforms']['macosx']['update_platform'] = 'fake'

These can be left out, the values set in PLATFORM_VARS are fine and won't be used anyway.

>diff --git a/mozilla2-staging/win32/addonsmgr/unittest/mozconfig b/mozilla2-staging/win32/addonsmgr/unittest/mozconfig

Don't need this one given the above.

>diff --git a/talos-staging-pool/config.py b/talos-staging-pool/config.py

Not really my area of knowledge, seek review from alice or catlee.
Attachment #431226 - Flags: review?(nrthomas) → review-
Comment on attachment 431227 [details] [diff] [review]
Production configs for addonsmgr

The comments for attachment 431226 [details] [diff] [review] apply here too.

>diff --git a/mozilla2/config.py b/mozilla2/config.py
>diff --git a/mozilla2/linux/addonsmgr b/mozilla2/linux/addonsmgr
>diff --git a/mozilla2/linux64/addonsmgr b/mozilla2/linux64/addonsmgr
>diff --git a/mozilla2/macosx/addonsmgr b/mozilla2/macosx/addonsmgr
>+mozilla-central/

Remove the trailing /. 

Mossop, does 'Yes, all OS supported by trunk' (in comment #0) include Maemo/WinMo/kitchen sink ?
Attachment #431227 - Flags: review?(nrthomas) → review-
(Reporter)

Comment 25

7 years ago
(In reply to comment #24)
> (From update of attachment 431227 [details] [diff] [review])
> The comments for attachment 431226 [details] [diff] [review] apply here too.
> 
> >diff --git a/mozilla2/config.py b/mozilla2/config.py
> >diff --git a/mozilla2/linux/addonsmgr b/mozilla2/linux/addonsmgr
> >diff --git a/mozilla2/linux64/addonsmgr b/mozilla2/linux64/addonsmgr
> >diff --git a/mozilla2/macosx/addonsmgr b/mozilla2/macosx/addonsmgr
> >+mozilla-central/
> 
> Remove the trailing /. 
> 
> Mossop, does 'Yes, all OS supported by trunk' (in comment #0) include
> Maemo/WinMo/kitchen sink ?

I'm expected performance impact so having data from Maemo and WinMo would be extremely useful yes.
Created attachment 431258 [details] [diff] [review]
Production configs for addonsmgr

Adding alice to review this for talos
Attachment #431227 - Attachment is obsolete: true
Attachment #431258 - Flags: review?(nrthomas)
Attachment #431258 - Flags: feedback?(anodelman)
Created attachment 431260 [details] [diff] [review]
[Tested] staging configs for addonsmgr

Made the same changes as in production configs, adding alice for talos review.
Attachment #431226 - Attachment is obsolete: true
Attachment #431260 - Flags: review?(nrthomas)
Attachment #431260 - Flags: feedback?(anodelman)
Comment on attachment 431260 [details] [diff] [review]
[Tested] staging configs for addonsmgr

This is the same as attachment 431226 [details] [diff] [review].
Attachment #431260 - Attachment is obsolete: true
Attachment #431260 - Flags: review?(nrthomas)
Attachment #431260 - Flags: feedback?(anodelman)
Created attachment 431274 [details] [diff] [review]
[Tested] staging configs for addonsmgr

Sorry about that.  Here's the updated patch.
Attachment #431274 - Flags: review?(nrthomas)
Attachment #431274 - Flags: feedback?(anodelman)
Created attachment 431283 [details] [diff] [review]
[tested] staging mobile configs for addonsmgr
Attachment #431283 - Flags: review?(aki)

Comment 31

7 years ago
Comment on attachment 431283 [details] [diff] [review]
[tested] staging mobile configs for addonsmgr

Looks like you're missing the enable_l10n_onchange option (which should be False as well).

r=me with that added.
Attachment #431283 - Flags: review?(aki) → review+
Created attachment 431284 [details] [diff] [review]
[tested] staging mobile configs for addonsmgr

setting create_snippet to False
Attachment #431283 - Attachment is obsolete: true
Attachment #431284 - Flags: review?(aki)
Created attachment 431285 [details] [diff] [review]
Production configs for mobile-addonsmgr
Attachment #431285 - Flags: review?(aki)
(Assignee)

Updated

7 years ago
Blocks: 551102

Updated

7 years ago
Attachment #431284 - Flags: review?(aki) → review+

Comment 34

7 years ago
Comment on attachment 431284 [details] [diff] [review]
[tested] staging mobile configs for addonsmgr

Same as above, looks like you're missing the enable_l10n_onchange option (which should be
False as well).

(You'll need to update your buildbot-configs and buildbotcustom to see the appropriate changes changes from today)

Comment 35

7 years ago
Comment on attachment 431285 [details] [diff] [review]
Production configs for mobile-addonsmgr

>diff --git a/mozilla2-staging/mobile_config.py b/mozilla2-staging/mobile_config.py
>--- a/mozilla2-staging/mobile_config.py
>+++ b/mozilla2-staging/mobile_config.py
>@@ -415,37 +415,37 @@ 
<snip>
>-MOBILE_BRANCHES['mobile-addonsmgr']['tinderbox_tree'] = 'MozillaTest'
>-MOBILE_BRANCHES['mobile-addonsmgr']['l10n_tinderbox_tree'] = 'MozillaStaging'
>+MOBILE_BRANCHES['mobile-addonsmgr']['tinderbox_tree'] = 'AddonsMgr'
>+MOBILE_BRANCHES['mobile-addonsmgr']['l10n_tinderbox_tree'] = 'Mozilla-l10n'

Looks like you're changing the staging configs to send to the production tinderbox trees?

>diff --git a/mozilla2/mobile_config.py b/mozilla2/mobile_config.py
>--- a/mozilla2/mobile_config.py
>+++ b/mozilla2/mobile_config.py
>@@ -20,16 +20,17 @@ mobile_slaves = {

>+
>+### mozilla-central

Comment nit!

>+MOBILE_BRANCHES['mobile-addonsmgr']['enable_l10n'] = False
>+MOBILE_BRANCHES['mobile-addonsmgr']['enable_multi_locale'] = False

Ok.
Looks like you're enabling l10n on staging, but not production? (checking to see if that's what you wanted.)

If you meant to enable, please set these to True, but set enable_l10n_onchange to False until we track down the weirdness related to bug 550940 and bug 548178.

>+MOBILE_BRANCHES['mobile-addonsmgr']['tinderbox_tree'] = 'MozillaTest'
>+MOBILE_BRANCHES['mobile-addonsmgr']['l10n_tinderbox_tree'] = 'MozillaStaging'

Aha, I think you edited the wrong file =)

I'm going to chalk this one up to the late hour.
Attachment #431285 - Flags: review?(aki) → review-
No longer blocks: 551102
URL: 551102
URL: 551102
Depends on: 551102
Comment on attachment 431274 [details] [diff] [review]
[Tested] staging configs for addonsmgr

>diff --git a/mozilla2-staging/config.py b/mozilla2-staging/config.py
>+BRANCHES['addonsmgr']['unittest_build_space'] = 6

Nit: No need to set this for builds we're not doing.
Attachment #431274 - Flags: review?(nrthomas) → review+
Comment on attachment 431258 [details] [diff] [review]
Production configs for addonsmgr

>diff --git a/mozilla2/config.py b/mozilla2/config.py
>+BRANCHES['addonsmgr']['platforms']['win32']['profiled_build'] = False

This should be removed to match staging.

>+BRANCHES['addonsmgr']['unittest_build_space'] = 6

Nit: No need to set this for builds we're not doing.

There's no change to mozilla2/master2.cfg in this patch (adding addonsmgr to the ACTIVE_BRANCHES list).

>diff --git a/talos-pool/config.py b/talos-pool/config.py

This should be against talos-r3. These days talos-pool is only doing Tiger jobs and so not useful for mozilla-central based project branch.
Attachment #431258 - Flags: review?(nrthomas) → review-
BTW I am assuming that we are only enabling l10n for release branches (mc, m191 and m192) and not for project branches (to the exception of lorentz).
Has this change?

Comment 39

7 years ago
(In reply to comment #38)
> BTW I am assuming that we are only enabling l10n for release branches (mc, m191
> and m192) and not for project branches (to the exception of lorentz).
> Has this change?

What about create an additional branch in l10n-central repo for addonsmgr?
(In reply to comment #39)
> (In reply to comment #38)
> > BTW I am assuming that we are only enabling l10n for release branches (mc, m191
> > and m192) and not for project branches (to the exception of lorentz).
> > Has this change?
> 
> What about create an additional branch in l10n-central repo for addonsmgr?
I am sorry Tymerkaev but we are only putting machine time into release branches and lorentz for now. This addons project branch is mainly for developers to add features in their own branch and at certain points to port their features to trunk and eventually to release branches. Then and only then, if there are strings changes, it makes sense for localizers to localize and expect results from our build machines.

I hope this makes sense.
(Assignee)

Updated

7 years ago
Blocks: 551102
No longer depends on: 551102

Updated

7 years ago
Blocks: 551205
Created attachment 431392 [details] [diff] [review]
Production configs for addonsmgr

Cleaned up production, and updated talos-r3
Attachment #431258 - Attachment is obsolete: true
Attachment #431392 - Flags: review?(nrthomas)
Attachment #431392 - Flags: feedback?(anodelman)
Attachment #431258 - Flags: feedback?(anodelman)
Created attachment 431395 [details] [diff] [review]
Production configs for addonsmgr

Sorry for the bug spam, did refresh my queue and was missing the master2.cfg change.
Attachment #431392 - Attachment is obsolete: true
Attachment #431395 - Flags: review?(nrthomas)
Attachment #431395 - Flags: feedback?(anodelman)
Attachment #431392 - Flags: review?(nrthomas)
Attachment #431392 - Flags: feedback?(anodelman)
(Assignee)

Updated

7 years ago
Attachment #431274 - Flags: feedback?(anodelman) → checked-in+
Comment on attachment 431274 [details] [diff] [review]
[Tested] staging configs for addonsmgr

http://hg.mozilla.org/build/buildbot-configs/rev/680b69e5e4e2
Comment on attachment 431284 [details] [diff] [review]
[tested] staging mobile configs for addonsmgr

checked in with enable_l10n_onchange set to False

http://hg.mozilla.org/build/buildbot-configs/rev/27156a96f2b7
Attachment #431284 - Flags: checked-in+
(In reply to comment #38)
> BTW I am assuming that we are only enabling l10n for release branches (mc, m191
> and m192) and not for project branches (to the exception of lorentz).
> Has this change?

Armen, good catch - there will not be 110n enabled for this.
Created attachment 431422 [details] [diff] [review]
Production configs for mobile-addonsmgr

Fixed it, on production no less, according to Aki's comments.  Turned off l10n as well since we don't need it on a project (non-release) branch.
Attachment #431285 - Attachment is obsolete: true
Attachment #431422 - Flags: review?(aki)
Created attachment 431426 [details] [diff] [review]
Mobile-staging clean-up - removing mobile l10n in config
Attachment #431426 - Flags: review?(aki)

Updated

7 years ago
Attachment #431426 - Flags: review?(aki) → review+

Comment 48

7 years ago
Comment on attachment 431422 [details] [diff] [review]
Production configs for mobile-addonsmgr

This doesn't checkconfig out of the box, but that's only because it's dependent on config.BRANCHES['addonsmgr'] existing.

so r=me but it's dependent on the other production patch. (you probably know this already)
Attachment #431422 - Flags: review?(aki) → review+
(Assignee)

Updated

7 years ago
Attachment #431426 - Flags: checked-in+
> so r=me but it's dependent on the other production patch. (you probably know
> this already)


Yes, both production patches will be checked in during the downtime on Thursday, March 11th.
Comment on attachment 431395 [details] [diff] [review]
Production configs for addonsmgr

r+ for the non-talos parts.

>diff --git a/mozilla2/config.py b/mozilla2/config.py
>-
>+ 

Remove the space added here on checkin.
Attachment #431395 - Flags: review?(nrthomas)
Attachment #431395 - Flags: review?(anodelman)
Attachment #431395 - Flags: review+
Attachment #431395 - Flags: feedback?(anodelman)
Attachment #431395 - Flags: review?(anodelman) → review+
Comment on attachment 431395 [details] [diff] [review]
Production configs for addonsmgr

http://hg.mozilla.org/build/buildbot-configs/rev/d1048144f9ac
Attachment #431395 - Flags: checked-in+
Comment on attachment 431422 [details] [diff] [review]
Production configs for mobile-addonsmgr

http://hg.mozilla.org/build/buildbot-configs/rev/c6646140a6cb
Attachment #431422 - Flags: checked-in+
Comment on attachment 429863 [details]
insert statements for graphServer db

mysql> insert into branches values (NULL,"Addonsmgr");
Query OK, 1 row affected (0.00 sec)

mysql> insert into machines values (NULL,6,0,NULL,"Linux_addonsmgr",1,unix_timestamp());
Query OK, 1 row affected (0.00 sec)

mysql> insert into machines values (NULL,6,0,NULL,"Linux_addonsmgr_leak_test",1,unix_timestamp());
Query OK, 1 row affected (0.00 sec)

mysql> insert into machines values (NULL,7,0,NULL,"OS_X_10.5.2_addonsmgr",1,unix_timestamp());
Query OK, 1 row affected (0.00 sec)

mysql> insert into machines values (NULL,7,0,NULL,"OS_X_10.5.2_addonsmgr_leak_test",1,unix_timestamp());
Query OK, 1 row affected (0.00 sec)

mysql> insert into machines values (NULL,8,0,NULL,"WINNT_5.2_addonsmgr",1,unix_timestamp());
Query OK, 1 row affected (0.00 sec)

mysql> insert into machines values (NULL,8,0,NULL,"WINNT_5.2_addonsmgr_leak_test",1,unix_timestamp());
Query OK, 1 row affected (0.00 sec)

mysql> insert into machines values (NULL,18,0,NULL,"Linux_x86-64_addonsmgr",1,unix_timestamp());
Query OK, 1 row affected (0.00 sec)

mysql> insert into machines values (NULL,18,0,NULL,"Linux_x86-64_addonsmgr_leak_test",1,unix_timestamp());
Query OK, 1 row affected (0.01 sec)
Turned on this branch for production in this morning's downtime.  Leaving the bug open as we sort out nagios monitoring and just in case any issues arise in the first few days of operating.
(Reporter)

Comment 55

7 years ago
Both the linux x86-64 and linux leak test builds seem to be failing on something relating to the setup. See this from the leak test:

======== BuildStep started ========
'wget -O ...' failed
=== Output ===
wget -O bloat.log.old http://stage.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/addonsmgr-linux//bloat.log
 in dir /builds/slave/addonsmgr-linux-debug/. (timeout 1200 secs)
 watching logfiles {}
 argv: ['wget', '-O', 'bloat.log.old', 'http://stage.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/addonsmgr-linux//bloat.log']
 environment:
  CC=/tools/gcc/bin/gcc
  CCACHE_DIR=/builds/ccache
  CCACHE_UMASK=002
  CVS_RSH=ssh
  CXX=/tools/gcc/bin/g++
  DISPLAY=:2
  G_BROKEN_FILENAMES=1
  HISTSIZE=1000
  HOME=/home/cltbld
  HOSTNAME=moz2-linux-slave43.build.mozilla.org
  INPUTRC=/etc/inputrc
  JAVA_HOME=/builds/jdk
  LANG=en_US.UTF-8
  LD_LIBRARY_PATH=obj-firefox/dist/bin
  LESSOPEN=|/usr/bin/lesspipe.sh %s
  LOGNAME=cltbld
  LS_COLORS=no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=01;32:*.cmd=01;32:*.exe=01;32:*.com=01;32:*.btm=01;32:*.bat=01;32:*.sh=01;32:*.csh=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.bz2=01;31:*.bz=01;31:*.tz=01;31:*.rpm=01;31:*.cpio=01;31:*.jpg=01;35:*.gif=01;35:*.bmp=01;35:*.xbm=01;35:*.xpm=01;35:*.png=01;35:*.tif=01;35:
  MAIL=/var/spool/mail/cltbld
  MOZ_CRASHREPORTER_NO_REPORT=1
  MOZ_OBJDIR=obj-firefox
  PATH=/opt/local/bin:/tools/buildbot/bin:/tools/twisted/bin:/tools/twisted-core/bin:/tools/python/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/home/cltbld/bin
  PWD=/builds/slave/addonsmgr-linux-debug
  PYTHONHOME=/tools/python
  PYTHONPATH=/tools/buildbotcustom:/tools/buildbot/lib/python2.5/site-packages:/tools/twisted/lib/python2.5/site-packages:/tools/twisted-core/lib/python2.5/site-packages:/tools/zope-interface/lib/python2.5/site-packages/
  SHELL=/bin/bash
  SHLVL=1
  SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass
  TBOX_CLIENT_CVS_DIR=/builds/tinderbox/mozilla/tools
  TERM=linux
  USER=cltbld
  XPCOM_DEBUG_BREAK=stack-and-abort
  _=/tools/buildbot/bin/buildbot
 closing stdin
 using PTY: True
--20:05:45--  http://stage.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/addonsmgr-linux//bloat.log
Resolving stage.mozilla.org... 10.2.74.116
Connecting to stage.mozilla.org|10.2.74.116|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
20:05:45 ERROR 404: Not Found.

program finished with exit code 1
elapsedTime=0.114581
=== Output ended ===

And this on the x86-64:

======== BuildStep ended ========
======== BuildStep started ========
'wget -O ...' failed
=== Output ===
wget -O codesize-auto-old.log http://stage.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/addonsmgr-linux64//codesize-auto.log
 in dir /builds/slave/addonsmgr-linux64/. (timeout 1200 secs)
 watching logfiles {}
 argv: ['wget', '-O', 'codesize-auto-old.log', 'http://stage.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/addonsmgr-linux64//codesize-auto.log']
 environment:
  CC=/tools/gcc/bin/gcc
  CCACHE_DIR=/builds/ccache
  CCACHE_UMASK=002
  CVS_RSH=ssh
  CXX=/tools/gcc/bin/g++
  G_BROKEN_FILENAMES=1
  HISTSIZE=1000
  HOME=/home/cltbld
  HOSTNAME=moz2-linux64-slave11.build.mozilla.org
  INPUTRC=/etc/inputrc
  JAVA_HOME=/builds/jdk
  LANG=en_US.UTF-8
  LESSOPEN=|/usr/bin/lesspipe.sh %s
  LOGNAME=cltbld
  LS_COLORS=no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=01;32:*.cmd=01;32:*.exe=01;32:*.com=01;32:*.btm=01;32:*.bat=01;32:*.sh=01;32:*.csh=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.bz2=01;31:*.bz=01;31:*.tz=01;31:*.rpm=01;31:*.cpio=01;31:*.jpg=01;35:*.gif=01;35:*.bmp=01;35:*.xbm=01;35:*.xpm=01;35:*.png=01;35:*.tif=01;35:
  MAIL=/var/spool/mail/cltbld
  MOZ_CRASHREPORTER_NO_REPORT=1
  MOZ_OBJDIR=obj-firefox
  MOZ_SYMBOLS_EXTRA_BUILDID=linux64-addonsmgr
  PATH=/opt/local/bin:/tools/buildbot/bin:/tools/twisted/bin:/tools/twisted-core/bin:/tools/python/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/home/cltbld/bin
  PWD=/builds/slave/addonsmgr-linux64
  PYTHONHOME=/tools/python
  PYTHONPATH=/tools/buildbotcustom:/tools/buildbot/lib/python2.5/site-packages:/tools/twisted/lib/python2.5/site-packages:/tools/twisted-core/lib/python2.5/site-packages:/tools/zope-interface/lib/python2.5/site-packages/
  SHELL=/bin/bash
  SHLVL=1
  SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass
  SYMBOL_SERVER_HOST=dm-symbolpush01.mozilla.org
  SYMBOL_SERVER_PATH=/mnt/netapp/breakpad/symbols_ffx/
  SYMBOL_SERVER_SSH_KEY=/home/cltbld/.ssh/ffxbld_dsa
  SYMBOL_SERVER_USER=ffxbld
  TBOX_CLIENT_CVS_DIR=/builds/tinderbox/mozilla/tools
  TERM=linux
  TINDERBOX_OUTPUT=1
  USER=cltbld
  _=/tools/buildbot/bin/buildbot
 closing stdin
 using PTY: True
--19:39:56--  http://stage.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/addonsmgr-linux64//codesize-auto.log
Resolving stage.mozilla.org... 10.2.74.116
Connecting to stage.mozilla.org|10.2.74.116|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
19:39:56 ERROR 404: Not Found.

program finished with exit code 1
elapsedTime=0.189046
=== Output ended ===
======== BuildStep ended ========
Just enabled scraping on a bajillion columns on the addons tree.
Dave, I've kicked off another build to see if it was just the lack of previous logs to compare against that is the issue here.
(Reporter)

Comment 58

7 years ago
(In reply to comment #57)
> Dave, I've kicked off another build to see if it was just the lack of previous
> logs to compare against that is the issue here.

That seems to have solved it. A couple of other issues appear to be showing:

There are tests running for linux 64bit, apparently this isn't normal and they are always failing (for expected reasons).
WinMo Addonsmgr build is consistently failing with errors about missing pthread.h and freetype2.lib2, perhaps this is because I have a slightly outdated mozilla-central in the repository right now?
WinMo Addonsmgr nightly is consistently timing out cloning the repository, not sure why it is there though I didn't ask for nightlies.

Also one oddity, the nightly directory is getting things added to it, not sure if that is just an expected side effect.
(In reply to comment #58)
> There are tests running for linux 64bit, apparently this isn't normal and they
> are always failing (for expected reasons).

gah review fail. Lukas, we should remove these:
BRANCHES['addonsmgr']['platforms']['linux64']['enable_opt_unittests'] = True
BRANCHES['addonsmgr']['platforms']['linux64-debug']['enable_unittests'] = True

> WinMo Addonsmgr nightly is consistently timing out cloning the repository, not
> sure why it is there though I didn't ask for nightlies.

Mobile config probably doesn't know about the enable_nightly parameter.

> Also one oddity, the nightly directory is getting things added to it, not sure
> if that is just an expected side effect.

That's the shark build, which isn't controlled by the enable_nightly parameter either. We can turn that off if you like.
(Reporter)

Comment 60

7 years ago
(In reply to comment #59)
> > Also one oddity, the nightly directory is getting things added to it, not sure
> > if that is just an expected side effect.
> 
> That's the shark build, which isn't controlled by the enable_nightly parameter
> either. We can turn that off if you like.

Not really bothered, just thought I'd point it out as an oddity.
Created attachment 432596 [details] [diff] [review]
Turn off linux64 opt_unittests/debug_unittests for addonsmgr
Attachment #432596 - Flags: review?(nrthomas)
Comment on attachment 432596 [details] [diff] [review]
Turn off linux64 opt_unittests/debug_unittests for addonsmgr

>diff --git a/mozilla2-staging/config.py b/mozilla2-staging/config.py
>-BRANCHES['tryserver']['platforms']['linux64']['enable_opt_unittests'] = True
>+BRANCHES['tryserver']['platforms']['linux64']['enable_opt_unittests'] = False

We seem to have this turned on elsewhere in staging, so you could leave this out.

>diff --git a/mozilla2/config.py b/mozilla2/config.py
>+BRANCHES['enable_shark'] = False

We should make this change to the staging config to keep it in sync as much as possible.

r+ to fix on landing.
Attachment #432596 - Flags: review?(nrthomas) → review+
Comment on attachment 432596 [details] [diff] [review]
Turn off linux64 opt_unittests/debug_unittests for addonsmgr

http://hg.mozilla.org/build/buildbot-configs/rev/f28ed9851441

matched on staging/production to turn off shark, and opt/debug unittest for linux64
Attachment #432596 - Flags: checked-in+
The turning off of opt/debug tests for linux 64 went into a reconfig of pm02 today.
CLosing this bug since the branch is now live - please file new bugs if issues arise.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Thanks Lukas! Looks good so far. QA can already use the builds for testing. Marking as verified fixed.
Status: RESOLVED → VERIFIED
Shall we file a new bug to get the project branch deleted? We don't have to use it anymore.

Updated

7 years ago
Depends on: 571465
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.