Firefox Edge is not using Nightly


#1

Why is Firefox Edge not using Nightly? I was hoping to use Nightly alongside Stable thanks to the new parallel installs feature but Edge is on 63, not 64, despite 64 being out for a month?


#2

Mozilla is not publishing the nightly to the store. We have discussed it and I think if they did it they would use a separate track rather than edge. Just like they use a track for ESR releases. @JohanLorenzo would you consider a nightly track?


#3

Thank you for your interest in Nightly :slight_smile: Edge would be the way to go, I think.

The work is tracked at https://bugzilla.mozilla.org/show_bug.cgi?id=1451694. FYI: the project is currently blocked by delta updates:


#4

I love that Mozilla is supporting snaps for the beta and nightly releases (or at least has plans to)! Snaps have me more optimistic than I have ever been about the Linux software ecosystem. :smiley:


#5

Can you explain why delta uploads not working is blocking you? :thinking:

Delta uploads are an optimisation, and shouldn’t cause any material change of behaviour (your system will upload the whole snap instead of a [hopefully smaller] delta).

I would love to use Nightly through the edge channel. :heart:


#6

Sure! :slight_smile:

Firefox snaps are 200MB big. We build nightlies twice a day. Snapd forces updates once a day. If I understand correctly, this means Nightly users will download at least 200MB of Firefox per day, or 1.4GB per week. For reference, betas are only uploaded twice a week, reducing the network usage down to 400MB/week.

Mozilla has provided partials updates for Nightly users outside of Snap. These days, partial updates are less than 10 MB big: https://archive.mozilla.org/pub/firefox/nightly/partials/2018/10/2018-10-04-10-02-22-mozilla-central/.

Therefore, the ratio between regular updates and Snap ones is about 20.

Please let me know if I missed something :slight_smile:


#7

Thanks for explaining it so thoroughly.

I think what you’ve missed is that upload deltas are different from download deltas. The bug you linked to is a failure to generate a delta for the upload, which, if working, would minimise the amount of data you have to send to the store. The store itself will, all being well, generate download deltas independently of the upload ones, and give users of the snap a smaller download.


#8

Ah I see! Thank you for pointing this out. So far, I’ve thought the Snap store just sent the same snap publishers provide + the GPG signature made by the store. Would you have some documentation about how download delta are crafted/published?


#9

There’s a blog post which talks about it, is that sufficient?


#10

Sweet! I think this blog post covers enough of the topic to unblock Nightly. I’ll see if I can get it prioritized this quarter.

It’s important to note that after this process snapd verifies that the assertions about this snap package still apply (‘assertions’ in the Ubuntu Core vernacular are cryptographically signed documents stating facts about a snap). This means that the result of applying a delta must be bit-for-bit identical with the full target snap.

I’m curious this statement. How does snapd process the delta? Does it:

  1. download it,
  2. construct the full snap in isolation,
  3. verify the assertions of the full snap,
  4. and install the full snap and copy the user’s data over the new folder?

#11

basically, yes. The logic is complicated a little by retries and continuations, but it

  1. downloads the metadata,
  2. downloads the delta,
  3. builds an updated snap from the old one + the delta,
  4. SHA3_384 hashes the resulting snap, compares with the one in metadata (which will match the assertions, and will match the SHA3_384 hash of the snap the developer asked to upload)
  5. move into snaps directory, mount, disable old current, copy data, make current

if you read Go, you can probably follow along.


#12

Awesome! Thanks for the clarification and the pointer :slight_smile: