Intent to remove old builds on July 1, 2018


As part of a project to clean out obsolete artifacts from, we intend to remove old files from on July 1, 2018.

On July 1 we will:

If removing these files will seriously impact you, please reply back to me and we can hopefully find a way to preserve the files you need while still cleaning up the majority of the old builds there.


(James Haggerty) #2

I currently have latest-mozilla-b2g44_v2_5-flame-kk/ on my phone. Would be nice to keep this as the last ‘stable’ release of FirefoxOS (and it postdates a lot of the blobs in latest-mozilla-central*, including latest-mozilla-central-flame-kk/ !). Perhaps all the latest--v2_2 and latest--v2_5 directories?

(Will) #3

Hi Catlee,

I agree with James’ suggestion to keep the latest “stable” build of each major version for each device. I started to try and make a summary of these. The best I could make myself were these site maps I posted on

EDIT: see next post.

As well as my post on XDA I also posted on reddit to ask anyone who has a need for any files to post here or in the mailing list.

Cheers :slight_smile:

(Will) #4

I tried to make a summary of the latest builds for each release branch and each target. I’ve no idea if this is complete or correct, or even if it’s useful to anyone.

EDIT: Desktop/Simulator/Mulet builds now added.

No project branches are included since I believe these were all merged or cancelled as dead ends.

The table isn’t displaying properly in Discourse because of the limited width of the view, but if you look at the HTML you can see the full table.

Latest builds from
FxOS version/branch mozilla-central b2g-ota b2g44_v2_5 b2g37_v2_2r b2g37_v2_2 b2g34_v2_1s b2g34_v2_1 b2g32_v2_0 b2g30_v1_4 b2g28_v1_3t b2g28_v1_3 b2g26_v1_2f b2g26_v1_2 b2g18_v1_1_0_hd b2g18_v1_1_0_hd b2g18_v1_0_1 b2g18_v1_0_0 b2g18

(Will) #5

@catlee, Have you made any changes about what you’re going to keep, is it still as described in the OP?



If we keep all the latest* directories, what builds are still left that would be useful?



(Will) #7

Hi Chris,

I think that all of the builds I listed in the table in my post above would be useful to keep. That table gives the latest build of every combination of device/branch (except project branches) within the archive. AFAIK the latest* builds are only from trunk and are probably less stable than the branches and as a result less useful (they may have been successful builds, but may still be full of bugs, unlike the branches which were feature-frozen and bugs fixed to improve their stability).

It would be very helpful and much appreciated if you could confirm explicitly (build by build) what you’re going to keep ~1 week in advance of you deleting everything else.

Thanks :slight_smile:


latest* would include directories such as, no?

(Will) #9

Yes it would, excuse me I didn’t recheck and assumed it was the same as in the OP.

Saving latest* only saves two versions of the desktop/simulator/mulet build, only a few emulators, no branches earlier than 2.1 and none of the Hamachi or Helix device builds.

With latest* you’d be keeping 40 builds I think (including project branches). My suggestions in the table above would add ~90 builds. The total number of builds in the archive is ~62000, so my suggestion is to save ~0.15% of the archive instead of 0.07%.


Could you get that table to me in list form? It will be much easier for automation to consume that way :slight_smile:

(Will) #11

I thought you’d never ask :wink:

There are some oddities, like there are no builds of 1_3t but lots of results txt.gz files saying “success”, was there a previous clearout or have I missed something?

Cheers :slight_smile:


I filed to track this work.

(Will) #13

@catlee and :oremj (can’t find his username in discourse) - thanks :smile: :+1:

(Will) #14

@catlee I realised that there are some repos in GitHub which included links to some of the builds which have been removed.

I know I’m a bit late with this and I should have thought of this before. Is there any way they can be reinstated? If yes, how should I got about raising this request?

The alternative is these repos are updated with reference to existing builds that are confirmed to work. However, I think that is unrealistic, may be @lissyx can confirm?

(Lissyx) #15

It’s way too late. You’d better rebuild yourself, it should still be possible.

(Will) #16

Fair enough, I thought I would be. On closer inspection the only ones which I think are essential for building are those that reference to download the SDK. These are:

Gaia makefile:
The Makefile references a different SDK depending on which branch it’s for. Any reason why the makefile references a specific date rather than just latest in a branch, e.g. the master branch needs v39? The archive does still contain the latest for some branches, so this should be an easy fix to the Makefile in most cases, if the latest SDK in each branch is a suitable substitute.

There’s also which references the SDK for B2G43. Unfortunately there’s not a copy of the v43 SDK in the archive anymore. Why would v43 be essential, not just the latest version?

There could be other important instances hidden in various branches but GitHub doesn’t search them so I couldn’t find them practicably.

As you said, we should be able to build these SDKs. It would still be nice to have them available in the archive to avoid having to build them.