Currently all of our win32 partner repacks get uploaded to unsigned/partner-repacks/$partner/win32. This is great for most of them, but not for EUballot, which gets pushed to mirrors in win32-EUballot. If the partner repack scripts/builder uploaded these to unsigned/win32-EUballot the signing scripts would put them in win32-EUballot and we'd be set. Another possible implementation is having the signing scripts move them. Possibly harder to deal with since we only have them for a single branch.

Planning to fix this this quarter.

This is a fairly big patch, but not as invasive as it looks. Here's a summary of the changes: - Get rid of relative paths - Use path.join() everywhere - Set a global default for the output directory, make it overridable in the repack config - Mirror candidates directory structure exactly, to allow us to rsync the entire thing to stage (necessary because we're uploading two different directories on Windows now). I've got an accompanying patch to PartnerRepackFactory to post, too. I've tested this through Buildbot on 3.6.14build1 on all platforms, the results are here: http://staging-stage.build.mozilla.org/pub/mozilla.org/firefox/nightly/3.6.14-candidates/build1/unsigned/ I've also tested 1.1rc1build3 on Maemo4. This was done by hand emulating Buildbot as best I could. Results for it are here: http://staging-stage.build.mozilla.org/pub/mozilla.org/mobile/candidates/1.1rc1-candidates/build3/unsigned/

This patch: - Rsyncs the entire candidates directory to stageServer - Drops createRemoteStageDir, because the new rsync makes it unnecessary

Comment on attachment 509160 [details] [diff] [review] mobile release automation config adjustment Did you mean to bump mozilla/release-firefox-mozilla-2.0.py here?

(In reply to comment #5) > Comment on attachment 509160 [details] [diff] [review] > mobile release automation config adjustment > > Did you mean to bump mozilla/release-firefox-mozilla-2.0.py here? d'oh, that's just me forgetting to merge default to my working branch. please ignore

(In reply to comment #2) > I've also tested 1.1rc1build3 on Maemo4. This was done by hand emulating > Buildbot as best I could. Results for it are here: > http://staging-stage.build.mozilla.org/pub/mozilla.org/mobile/candidates/1.1rc1-candidates/build3/unsigned/ I extracted this deb, as well as the actual partner repack deb for 1.1. Then I recursive checksummed the contents: deathduck:~/Desktop/ben/real [13:53:50] $ find . -type f -exec sum {} \; >> ../real.sum deathduck:~/Desktop/ben/real [13:54:36] $ cd .. deathduck:~/Desktop/ben [13:54:37] $ cd test deathduck:~/Desktop/ben/test [13:54:39] $ find . -type f -exec sum {} \; >> ../test.sum deathduck:~/Desktop/ben/test [13:54:43] $ cd .. deathduck:~/Desktop/ben [13:54:44] $ diff real.sum test.sum | more 118d117 < 47961 1 ./opt/mozilla/fennec-1.1/defaults/pref/partner.js The test deb doesn't include the actual partner repack file, so is essentially the same as a non-partner-repacked deb. Not sure if this is a manual error or a script error.

I re-ran the maemo repack without my patches in the same environment and got a build that matched the original 1.1rc1 maemo ovi repack -- so there's definitely a bug in my code. I'll track it down and fix. Planning to do file-level verification on the 3.6.14 repacks, too.

Fixed the Maemo issue, verified with: [sbox-CHINOOK-ARMEL-2007: ~/bh/old] > find . > ../old.txt [sbox-CHINOOK-ARMEL-2007: ~/bh/old] > cd ../new [sbox-CHINOOK-ARMEL-2007: ~/bh/new] > find . > ../new.txt [sbox-CHINOOK-ARMEL-2007: ~/bh/new] > cd .. [sbox-CHINOOK-ARMEL-2007: ~/bh] > diff -Naur old.txt new.txt [sbox-CHINOOK-ARMEL-2007: ~/bh] > diff -Naur old/ new/ diff: old/etc/others-menu/0112_fennec.desktop: No such file or directory diff: new/etc/others-menu/0112_fennec.desktop: No such file or directory diff: old/usr/bin/fennec: No such file or directory diff: new/usr/bin/fennec: No such file or directory ("old" is the original repack direct from stage.m.o, "new" is the newly uploaded on staging-stage -- both unpacked with "dpkg-deb -x *.deb .") I also did full unpacking of all Linux and Windows partner repacks, and did diffs. All are identical. I spot checked 3 Mac partner repacks, only because I had a lot of issues getting it done in a scripted manner. The 3 that I checked are OK and combined with my other checks, I'm confident the rest are fine, too. This updated patch is a very tiny change from the original, just a re-addition of a line I had thought was unnecessary. Meta-diff is as follows: @@ -195,7 +193,7 @@ def cleanup(self): - print self.final_dir - move(os.path.join(self.base_dir, self.build), "../%s" % self.final_dir) -+ move(path.join(self.base_dir, self.build), path.join("..", self.final_dir)) ++ super(RepackMaemo, self).cleanup() rmdirRecursive(self.tmpdir) def doRepack(self):

Comment on attachment 509583 [details] [diff] [review] fixed partner repack scripts I'm not entirely sure we need to path.join scratchbox paths, when those are only on linux, but it doesn't hurt. I think the .hgtags diff is cruft: remove? r=me without .hgtags.

Comment on attachment 509160 [details] [diff] [review] mobile release automation config adjustment r=me for the release_mobile_master portions.

Comment on attachment 509159 [details] [diff] [review] rsync entire candidates directory I tend to create the dir, and then rsync from dir1/. to dir2/. since that way I am rock-solid-clear about what it's going to be doing (as opposed to, do the to: or from: directories have trailing slashes?). However, I tried various permutations of the dir1/ to dir2 rsync and wasn't able to break it. I think this is good. r=me

Comment on attachment 509583 [details] [diff] [review] fixed partner repack scripts Echoing aki's comment about .hgtags.

cc-ing kev in case this affects with BYOB repacks at all.

should not affect, thanks for the heads-up, and agree with the override in repack.cfg approach.

fwiw, the .hgtags stuff is a testing artifact, and I definitely will not be landing it!

Comment on attachment 509159 [details] [diff] [review] rsync entire candidates directory Landed this patch on default & buildbot-0.7 branches of buildbotcustom.

After the next reconfig we'll be all done here.

Made it to production last week.