Closed Bug 529140 Opened 10 years ago Closed 10 years ago
upload Fennec single-locale tar and deb files under "en-US" sub-directory
The purpose of doing is to have everything that is with regards the single-locale separated from the multi-locale and the overwriting of the single-locale fennec deb (since it shares names with the multi-locale one). The binaries will be uploaded under latest-mobile-%(branch)/en-US On https://bug527076.bugzilla.mozilla.org/attachment.cgi?id=412120 Aki passed -r to packageGlob and that was good enough to scp the whole sub-directory. Bug 524519 and bug 527928 were attempting to solve this in a similar way as in Firefox and not having to do a hack to MozillaStage since we are planning on dropping it at some point. This also removes the uncertainty if we are creating a locale off the single-locale or off the multi-locale. - wget time of one of the locales 1:47:58 - single-locale upload time 1:44:25 - multi-locale upload time 1:46:15 Nevertheless, I was expecting a bigger gap between the two upload steps and one or more of the locale to wget sometime in that frame.
I have also modified the addPackageSteps to create the packages for both scenarios. This means that we will have xulrunner deb and tar files under latest and en-US. Let me know what your thoughts are. Under http://staging-stage.build.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mobile-1.9.2/ you can find these binaries: * fennec-1.0b6pre.multi.linux-gnueabi-arm.tar.bz2 * fennec_1.0b6pre_armel.deb * xulrunner-1.9.2b4pre.multi.linux-gnueabi-arm.tar.bz2 * xulrunner-1.9.2b4pre.multi.linux-gnueabi-arm.tests.tar.bz2 * xulrunner_1.9.2b4pre-20091117152614_armel.deb and under http://staging-stage.build.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mobile-1.9.2/en-US/ you can find: * fennec-1.0b6pre.en-US.linux-gnueabi-arm.tar.bz2 * fennec_1.0b6pre_armel.deb * xulrunner-1.9.2b4pre.en-US.linux-gnueabi-arm.tar.bz2 * xulrunner-1.9.2b4pre.en-US.linux-gnueabi-arm.tests.tar.bz2 * xulrunner_1.9.2b4pre-20091117152614_armel.deb
(In reply to comment #1) > * fennec_1.0b6pre_armel.deb > * xulrunner-1.9.2b4pre.en-US.linux-gnueabi-arm.tar.bz2 > * xulrunner-1.9.2b4pre.en-US.linux-gnueabi-arm.tests.tar.bz2 > * xulrunner_1.9.2b4pre-20091117152614_armel.deb Why the duplication of these files? Can we not just upload one set and save that space?
(In reply to comment #2) > (In reply to comment #1) > > * fennec_1.0b6pre_armel.deb > > * xulrunner-1.9.2b4pre.en-US.linux-gnueabi-arm.tar.bz2 > > * xulrunner-1.9.2b4pre.en-US.linux-gnueabi-arm.tests.tar.bz2 > > * xulrunner_1.9.2b4pre-20091117152614_armel.deb > > Why the duplication of these files? Can we not just upload one set and save > that space? > I didn't want to make that call. I do agree. Does it make sense to upload only these 2 binaries under en-US? * fennec-1.0b6pre.en-US.linux-gnueabi-arm.tar.bz2 * fennec_1.0b6pre_armel.deb Or just the deb will do?
I think "fennec_1.0b6pre_armel.deb" is enough for the en-US folder. Getting "fennec-1.0b6pre.en-US.linux-gnueabi-arm.tar.bz2" would be nice, so we have a full bundle (fennec+xulrunner) in the en-US, but it's not mandatory
It only uploads fennec's deb and tar ball for single-locale
Summary: upload en-US single-locale Maemo binaries (debs included) under "en-US" sub-directory → upload Fennec single-locale tar and deb files under "en-US" sub-directory
Comment on attachment 413167 [details] [diff] [review] [buildbotcustom] upload fennec single-locale tar and deb files under "en-US" subdirectory >diff --git a/process/factory.py b/process/factory.py >--- a/process/factory.py >+++ b/process/factory.py >@@ -3992,46 +3992,48 @@ class MaemoBuildFactory(MobileBuildFacto > if self.multiLocale: >+ # we only upload the Fennec tar ball and deb for the single-locale >+ self.packageGlob = "mobile/dist/*.tar.bz2 mobile/mobile/*.deb" I got confused by this comment. The comment is about single-locale builds, but it's sitting in a multiLocale block. The comment should talk about what the multiLocale block is doing, rather than what some other block isn't doing. >+ if multiLocale: > self.addStep(ShellCommand, > name='make_pkg_tests', Likewise, can we get a comment in front of this block, please? r+ with those changes.
Attachment #413167 - Flags: review?(ccooper) → review+
I have addresses the comments. The previous patch would have not generated all binaries for the dependent builds which is required (xulrunner would have different naming, due to buildid, compared to the nightly's xulrunner deb) Green builds on staging. Multi-locale: http://staging-stage.build.mozilla.org/pub/mozilla.org/firefox/nightly/2009/11/2009-11-19-13-mobile-1.9.2/ Single-locale: http://staging-stage.build.mozilla.org/pub/mozilla.org/firefox/nightly/2009/11/2009-11-19-13-mobile-1.9.2/en-US/ Dependent build: http://staging-stage.build.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mobile-1.9.2/1258660442/en-US/
Attachment #413435 - Flags: review?(ccooper) → review+
Comment on attachment 413435 [details] [diff] [review] [buildbotcustom] upload fennec single-locale tar and deb files under "en-US" subdirectory http://hg.mozilla.org/build/buildbotcustom/rev/73f720ff5f1e
Attachment #413435 - Flags: checked-in+
I was able to trigger a dependent build which did what I expected it to do, that is to upload an "en-US" directory: http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mobile-1.9.2/1258734751/en-US/ but I was not able to reschedule a new Maemo nightly build (due to a bug we can't use "force build" button) due to bug 530119. This bug might be fixed but I will have to wait until tomorrow's nightly.
Attachment #413859 - Flags: review?(armenzg) → review+
The en-US single-locale nightly is being upload under the "en-US" subdirectory as expected. http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mobile-1.9.2/en-US/ The multi-locale gets uploaded to the same place as before (latest) with all of its binaries but without doing any overwriting of the single-locale as it happened before.
Comment on attachment 413859 [details] [diff] [review] look for multi tarball instead of en-US one. actually, this doesn't work... multis aren't built on change. i'll write another patch.
Attachment #413859 - Attachment is obsolete: true
Aki anything left to be done in here? Can we close it?
Status: ASSIGNED → RESOLVED
Closed: 10 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.