Closed Bug 475961 Opened 13 years ago Closed 13 years ago

Update scratchbox to include a non-ancient version of hg

Categories

(Release Engineering :: General, defect)

x86
Maemo
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Pike, Assigned: aki)

References

Details

(Whiteboard: [fennec l10n])

We need to get a halfway recent version of hg onto the mobile refplatform.

This blocks getting the source stamps of our source into the build, and thus, reliable l10n repackaging.

I strongly suggest going for some version above 1.1 directly, as those include various other bug fixes.
Whiteboard: [fennec l10n]
Are you talking about Linux-ARM here ? And also about the version inside scratchbox ? The host version was recently upgraded to 1.1.2 and we use it for all hg operations for the en-US builds.
Why is the ARM box not reporting source stamps and repo urls then? Neither for buildconfig in toolkit/content, nor for application.ini, in mobile/app.

http://tinderbox.mozilla.org/showlog.cgi?log=Mobile/1233262098.1233263042.16400.gz&fulltext=1

Both should set variables for SOURCE_...

Something is funky, and Ted's assumption was the hg version there, but maybe it's worse than that.
OK, I meant pulling and updating mozilla-central and mobile repositories so that's not very "all". Anything the build system does will get the scratchbox hg, which is v0.9.1.
Summary: Update mobile ref platform to include a non-ancient version of hg → Update scratchbox to include a non-ancient version of hg
Chiming in since I'm moving the mobile builders to factory.py... I'm unfamiliar with source stamps, however.

I'm pretty sure all hg commands are run outside of scratchbox, so it should be version 1.1.2, unless the compilation/package steps run hg.

How does SOURCE_* get set in the standard factories?  I see

        bs = buildset.BuildSet(self.builderNames,
                               SourceStamp(branch=self.branch),
                               reason,
                               properties=self.properties)

in MozScheduler.doPeriodicBuild(), which mobile doesn't use currently... that could be it.

Also, linux mobile uses 2 repositories and wince uses 3 (m-c, mobile-browser, users/blassey_mozilla.com/wince-patches); which revision should we use?  Or can we have multiple repositories specified?
Updated Aki on #mobile.

We're hopeful to get the mq queue out of the way, so the bugs we have on file are good. We just need to get the fixes to actually work.
This is the pre-processed copy of application.ini
  http://mxr.mozilla.org/mozilla-central/source/browser/app/application.ini#44
which uses MOZ_SOURCE_STAMP, which is defined
  http://mxr.mozilla.org/mozilla-central/source/browser/app/Makefile.in#75

Line 80 there for repo.
OS: Mac OS X → Linux
Assignee: nobody → aki
OS: Linux → Linux (embedded)
Stuart,Brad: 

When we did the VM+scratchbox setup in August, iirc we needed specific versions of scratchbox, python and hg to be successful. Hence asking for a sanity check. 

1) Are you ok with us updating hg? Per discussion with aki in #mobile, if you want us to install hg v1.1 on all linux slaves, we can do that, so long as we know that is the correct version. 

2) Does hg v1.1 require changes to scratchbox, python also?
There isn't a readily available hg 1.1 package for scratchbox, as far as I know. Even if there were, it would probably depend on a newer python (bug 467595).
Right.  I've already updated python in my test scratchbox.  Installing mercurial in scratchbox is proving to be quite a bit trickier.

I'll keep trying, but I'm also curious as to whether it might make more sense to set these in the buildbot env before I start building in scratchbox.
Both the old version of python and the old version of hg block porting working build patches from Firefox to mobile.

Note, the current version of hg is 1.1.2, you probably don't want to invest into getting known bugs up and running ;-)
(In reply to comment #10)
> Both the old version of python and the old version of hg block porting working
> build patches from Firefox to mobile.

how so?  what patches are blocked?
The ones that are marked blocking of this patch.
the source stamp could be acquired from the host hg and passed in as an env var.  My point is that there are other options.
Great, discussion starting from scratch. See comment #2, it doesn't.
It doesn't because there aren't any buildbot steps to set those in the maemo factory atm...
That's bs, sorry.

Creating buildconfig.html in toolkit/content should get source stamp and repo, and does on any build but this dumb arm box.

Same goes for the creation of the data in platform.ini.

Both come with logic in the relevant makefiles to not fail the build if the getting of the source stamp and repo url fails, which is why the build succeeds.

Go to a build log, and search for -DSOURCE, and you'll find it in most builds, just not on ARM linux (the wince builds have it, fwiw).
Please disregard comment #1, or at least read it with the modification in comment #3.
I've got scratchbox python 2.5.2 + hg 1.1.2 working in staging, and see the -DSOURCE_ lines in the compile logs.  I'll roll out to production shortly.
Done on moz2-linux-slave01 through 17, and try-linux-slave01 through 05.
I'll update the ref image once I figure out which VM it is =)
aki, I was doing some an unrelated ref platform update so I ended up adding your changes into it, too.
Done on moz2-linux-slave18 and 19.
Fixed.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.