1201520 - (MozillaBuild2.1) MozillaBuild 2.1 tracking thread

Status: RESOLVED FIXED

(Firefox Build System :: MozillaBuild, task)

Description

[Ryan VanderMeulen [:RyanVM]]

Just a maintenance release to pick up some newer packages and bugfixes.

Comment 1

[Ryan VanderMeulen [:RyanVM]]

First test build:
http://people.mozilla.org/~rvandermeulen/MozillaBuildSetup2.1.0pre.exe (77.6MB)
sha1: A8EDBAAF4F217C00E71F65F0B014125CE5277D8B

Local testing hasn't turned up any issues so far. Will probably release at the end of the week if nothing turns up.

Comment 2

[Ryan VanderMeulen [:RyanVM]]

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #1)

gkw found a bug in the bundleclone inclusion (i.e. it didn't actually work). I've updated the test build to include that fix and removed NSIS 3.0b2 since updating that is more involved than I really want to do for this release.

http://people.mozilla.org/~rvandermeulen/MozillaBuildSetup2.1.0pre.exe (77.6MB)
SHA1: 174D4A5DE8F2CE89A9E3542AEFCBC9D5B244CAA6

Comment 3

[Ryan VanderMeulen [:RyanVM]]

I've uploaded an updated test build that includes the fixes for bug 1204237 and bug 1221188. If no major issues are found, I intend to respin it as the final release. The other known issues I'm aware of are edge-case enough that I'm not going to block on them.

http://people.mozilla.org/~rvandermeulen/MozillaBuildSetup2.1.0pre2.exe (77.6MB)
SHA1: 473CB6C3491CC3DBD0EF41CB0090CC9316C36DCA

Comment 4

[Avi Halachmi (:avih)]

I tried that build.

Out of the box, `hg --version` and various other commands failed due to "bad 3rd party extensions". Same goes for ./mach mercurial-setup --update-only

I commented out the mozilla extensions (I had few-weeks-old bundleclone, push-to-try, qimportbz, firefoxtree) - it kept failing until I removed all of them - and then hg started working.

My tree was updated few hours earlier with hg 3.4.1. I then tried 'hg pull -u' with the new hg 3.6, and it started downloading a bundle - which it should since the tree is fairly updated. After more than 10 mins I aborted, then had to issue a 'hg recover' which took many more minutes.

Now the tree seems in order but I dare not issue another update. gps said on IRC "yeah, this is a serious bug. writing patch now."

So yeah, not ready yet :)

Comment 5

[Ryan VanderMeulen [:RyanVM]]

2.1.0pre3 should fix the issues reported in comment 4.

http://people.mozilla.org/~rvandermeulen/MozillaBuildSetup2.1.0pre3.exe (77.6MB)
SHA1: 53B0DE11597F476D46A0D435E96624398C150C24

Comment 6

[Xidorn Quan [:xidorn] UTC+10]

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #5)
> 2.1.0pre3 should fix the issues reported in comment 4.
> 
> http://people.mozilla.org/~rvandermeulen/MozillaBuildSetup2.1.0pre3.exe
> (77.6MB)
> SHA1: 53B0DE11597F476D46A0D435E96624398C150C24

FWIW, I'd suggest you provide SHA-256 instead, or at least in addition of SHA-1. SHA-1 is on the way to be deprecated, and some collision has already been found.

Comment 7

[Avi Halachmi (:avih)]

I started using pre3 and so far it looks good. hg update didn't download a bundle, and the update completed successfully.

I already had all my Mozilla extensions disabled following comment 4, and now I also deleted ~/.mozillabuild and ran ./mach mercurial-setup - which also worked well. I didn't let it install the bundleclone extension.

Few subject to verify before it gets released:
- I assume pre3 includes the upstream fixes for the bundle download issue. Correct?
- Make sure hg works correctly with already installed and enabled mozilla extensions.
- Make sure ./mach mercurial-setup works correctly with existing ~/.mozillabuild
- Handle the case where bundleclone is already installed since hg 3.6 doesn't need it.

Comment 8

[Ryan VanderMeulen [:RyanVM]]

Release candidate build including Mercurial 3.6.1.
http://people.mozilla.org/~rvandermeulen/MozillaBuildSetup2.1.0RC1.exe (77.6MB)
SHA-256: a6c3f28e9247b49abd3b6e24c87e9824105561852a429e7d7a4366a0f6efe9b2

(In reply to Avi Halachmi (:avih) from comment #7)
> Few subject to verify before it gets released:
> - I assume pre3 includes the upstream fixes for the bundle download issue.
> Correct?

Yes, albeit moot now since the RC build includes Mercurial 3.6.1 instead.

> - Make sure hg works correctly with already installed and enabled mozilla
> extensions.

The extensions I use all appear to work OK. Would love more verification from others on that too :)

> - Make sure ./mach mercurial-setup works correctly with existing
> ~/.mozillabuild

WFM

> - Handle the case where bundleclone is already installed since hg 3.6
> doesn't need it.

gps updated the bundleclone extension in version-control-tools to basically be a thin wrapper around clonebundles if detected. The main thing that needs to be communicated IMO is that people should run ./mach mercurial-setup --update-only either immediately before or immediately after upgrading to ensure that they've got an up-to-date version installed.

Comment 9

[Gregory Szorc [:gps]]

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #8)
> > - Handle the case where bundleclone is already installed since hg 3.6
> > doesn't need it.
> 
> gps updated the bundleclone extension in version-control-tools to basically
> be a thin wrapper around clonebundles if detected. The main thing that needs
> to be communicated IMO is that people should run ./mach mercurial-setup
> --update-only either immediately before or immediately after upgrading to
> ensure that they've got an up-to-date version installed.

It's reasons like this that mach was forcing people to run `mach mercurial-setup` every 30 days. Unfortunately, we recently disabled that because too many people complained.

We do have a mechanism in MozReview to force people to update version-control-tools in order to submit code reviews. But this only applies to users of MozReview, which I don't think is even 50% of Firefox submissions yet :/

Comment 10

[Avi Halachmi (:avih)]

(In reply to Gregory Szorc [:gps] from comment #9)
> It's reasons like this that mach was forcing people to run `mach
> mercurial-setup` every 30 days. Unfortunately, we recently disabled that
> because too many people complained.

Not sure how that was implemented, but maybe it was too intrusive and interrupting.

I'm sure that if mach could do that automatically + silently + quickly (whenever invoked) and only inform users if there's a need for update, it would be much more tolerated.

Maybe like m-c clobbering, but a clobber file for mercurial setup at the repo[s]? this way, mach could check this file every time it's invoked - which can be quick and silent, and if required, prompt the user?

Comment 11

[Ryan VanderMeulen [:RyanVM]]

The RC1 build from comment 8 has been officially staged as the final release.

https://ftp.mozilla.org/pub/mozilla/libraries/win32/MozillaBuildSetup-2.1.0.exe (77.6MB)
SHA-256: a6c3f28e9247b49abd3b6e24c87e9824105561852a429e7d7a4366a0f6efe9b2

https://groups.google.com/d/msg/mozilla.dev.platform/qpO21XQaNV8/-D5mNKqnCAAJ