1214403 - comm- mac unit test packaging is not run in the right objdir

Status: RESOLVED INVALID

(Release Engineering :: General, defect)

Description

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

Once bug 1195442 is fixed, there will be another failure. IIRC the test packages are run in the base objdir, not in the platform specific sub-directories.

Comment 1

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

Attachment: Fix - v1

Comment 2

[Rail Aliiev [:rail]]

Comment on attachment 8673324 [details] [diff] [review]
Fix - v1

Review of attachment 8673324 [details] [diff] [review]:
-----------------------------------------------------------------

::: process/factory.py
@@ +1517,5 @@
>                           warnOnFailure=False,
>                           ))
> +            project = os.path.basename(self.objdir)
> +            if project in ('i386', 'x86_64'):
> +                pkg_env['MOZ_CURRENT_PROJECT'] = project

I'm not familiar with MOZ_CURRENT_PROJECT. I'd ask glandium (from https://hg.mozilla.org/mozilla-central/diff/ce1c57e03b88/python/mozbuild/mozbuild/base.py#l1.13) about the possible impact.

@@ +1570,5 @@
>              pkg_env = self.env.copy()
>          else:
>              pkg_env = {}
>  
> +        if self.platform.startswith('macosx'):

IS there any reason for this condition specifically for this place? It's not the same above.

Comment 3

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

(In reply to Rail Aliiev [:rail] from comment #2)
> Comment on attachment 8673324 [details] [diff] [review]
> Fix - v1
> 
> Review of attachment 8673324 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: process/factory.py
> @@ +1517,5 @@
> >                           warnOnFailure=False,
> >                           ))
> > +            project = os.path.basename(self.objdir)
> > +            if project in ('i386', 'x86_64'):
> > +                pkg_env['MOZ_CURRENT_PROJECT'] = project
> 
> I'm not familiar with MOZ_CURRENT_PROJECT. I'd ask glandium (from
> https://hg.mozilla.org/mozilla-central/diff/ce1c57e03b88/python/mozbuild/
> mozbuild/base.py#l1.13) about the possible impact.

MOZ_CURRENT_PROJECT is used in mozbuild to determine the mozconfig location and objdir, see <http://mxr.mozilla.org/comm-central/source/mozilla/python/mozbuild/mozbuild/base.py#168>. If this is not set, then the directory containing i386/ and x86_64/ will be taken for the top objdir, which is why we were getting errors.

I asked ted if this approach is ok beforehand, but it was only a quick question on IRC so it would be nice to get more eyes on it.

 
> > +        if self.platform.startswith('macosx'):
> IS there any reason for this condition specifically for this place? It's not
> the same above.

I matched this with various other lines that use |self.platform.startswith(...)|, using |'name' in self.platform| is far less common in that file. I'm fine either way though.

Comment 4

[Mike Hommey [:glandium]]

This looks fine, but bears the question: why did this work for Firefox mac builds without this?

Comment 5

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

I suspect that Firefox mac test builds are run differently and don't use the buildbot code here. I'll give this a spin on staging.

Comment 6

[aleth [:aleth]]

mozbuild.base.ObjdirMismatchException: Objdir mismatch: /builds/slave/tb-c-cen-m64-00000000000000000/build/objdir-tb/i386 != /builds/slave/tb-c-cen-m64-00000000000000000/build/objdir-tb

Comment 7

[aleth [:aleth]]

(In reply to aleth [:aleth] from comment #6)
> mozbuild.base.ObjdirMismatchException: Objdir mismatch:
> /builds/slave/tb-c-cen-m64-00000000000000000/build/objdir-tb/i386 !=
> /builds/slave/tb-c-cen-m64-00000000000000000/build/objdir-tb

This was unrelated, sorry.

Comment 8

[aleth [:aleth]]

Is this related to the current 10.10 opt mozmill failure? OSX xpcshell appears to be working.

Comment 9

[aleth [:aleth]]

(In reply to aleth [:aleth] from comment #8)
> Is this related to the current 10.10 opt mozmill failure? OSX xpcshell
> appears to be working.

Doesn't seem likely, so I assume this bug is resolved wfm?

Comment 10

[Wayne Mery (:wsmwk)]

Is this an adequate follow up to bug 1220018 comment 6?

Comment 11

[aleth [:aleth]]

(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #10)
> Is this an adequate follow up to bug 1220018 comment 6?

No idea, iirc Fallen was going to test this some time ago, not sure what the outcome was or if it's still needed.

Comment 12

[aleth [:aleth]]

Fallen, OSX xpcshell tests currently run in /builds/slave/test/build/tests/xpcshell/tests/toolkit/components/osfile/tests/xpcshell. Is this correct or not?

There are some puzzling xpcshell/mozmill failures that don't happen locally and it would be nice to rule out this as the cause.

Comment 13

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

This issue is about /builds/slave/tb-c-cen-m64-00000000000000000/build/objdir-tb/i386 vs /builds/slave/tb-c-cen-m64-00000000000000000/build/objdir-tb and IIRC should be occurring during the actual build, where the test package is packaged. If you want to reproduce it, you need to do a mac universal build.

I don't think this relates to the osfile failures.

Comment 14

[aleth [:aleth]]

(In reply to Philipp Kewisch [:Fallen] from comment #13)
> I don't think this relates to the osfile failures.

I'm not so sure about bug 1093012 though.

Comment 15

[aleth [:aleth]]

(In reply to aleth [:aleth] from comment #14)
> (In reply to Philipp Kewisch [:Fallen] from comment #13)
> > I don't think this relates to the osfile failures.
> 
> I'm not so sure about bug 1093012 though.

On investigation, turned out to be unrelated.

Comment 16

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

I think we can close this bug, I believe we've dropped the i386 builds by now.