This is a brown paper bag release. It turns out I managed to break the upgrade
path only 10 commits before the release.

What's new since 0.3.0?

• git cinnabar fsck doesn't fail to upgrade metadata.
• The remote.$remote.cinnabar-draft config works again.
• Don't fail to clone an empty repository.
• Allow to specify mercurial configuration items in a .git/hgrc file.

Git-cinnabar is a git remote helper to interact with mercurial repositories. It allows to clone, pull and push from/to mercurial remote repositories, using git.

Get it on github.

These release notes are also available on the git-cinnabar wiki.

Development had been stalled for a few months, with many improvements in the next branch without any new release. I used some time during the new year break and after in order to straighten things up in order to create a new release, delaying many of the originally planned changes to a future 0.4.0 release.

What's new since 0.2.2?

• Speed and memory usage were improved when doing git push.
• Now works on Windows, at least to some extent. See details.
• Support for pre-0.1.0 git-cinnabar repositories was removed. You must first
  use a git-cinnabar version between 0.1.0 and 0.2.2 to upgrade its metadata.
• It is now possible to attach/graft git-cinnabar metadata to existing commits
  matching mercurial changesets. This allows to migrate from some other
  hg-to-git tool to git-cinnabar while preserving the existing git commits.
  See an example of how this works with the git clone of the Gecko mercurial
  repository
• Avoid mercurial printing its progress bar, messing up with git-cinnabar's
  output.
• It is now possible to fetch from an incremental mercurial bundle (without
  a root changeset).
• It is now possible to push to a new mercurial repository without -f.
• By default, reject pushing a new root to a mercurial repository.
• Make the connection to a mercurial repository through ssh respect the
  GIT_SSH and GIT_SSH_COMMAND environment variables.
• git cinnabar now has a proper argument parser for all its subcommands.
• A new git cinnabar python command allows to run python scripts or open a python shell with the right sys.path to import the cinnabar module.
• All git-cinnabar metadata is now kept under a single ref (although for
  convenience, other refs are created, but they can be derived if necessary).
• Consequently, a new git cinnabar rollback command allows to roll back to
  previous metadata states.
• git-cinnabar metadata now tracks the manifests DAG.
• A new git cinnabar bundle command allows to create mercurial bundles,
  mostly for debugging purposes, without requiring to hit a mercurial server.
• Updated git to 2.7.0 for the native helper.

Development process changes

Up to before this release closing in, the master branch was dedicated to
releases, and development was happening on the next branch, until a new
release happens.

From now on, the release branch will take dot-release fixes and new
releases, while the master branch will receive all changes that are
validated through testing (currently semi-automatically tested with
out-of-tree tests based on four real-life mercurial repositories, with
some automated CI based on in-tree tests used in the future).

The next branch will receive changes to be tested in CI when things
will be hooked up, and may have rewritten history as a consequence of
wanting passing tests on every commit on master.

As of last nightly (2015-07-23), Firefox for Linux is using Gtk+3 instead of Gtk+2.

Thanks to the recent efforts of Andrew Comminos, all remaining test failures are gone and mozilla-central now defaults to Gtk+3 builds. Some jobs on treeherder are still not converted, but this will come soon (bug 1186748).

If you've been using elm builds for dogfooding, you should be automatically switched to standard nightlies today or tomorrow. The elm branch will be recycled to do Gtk+2 builds so that they keep working. Those builds won't be auto-updating, so don't use them.

It's been a frustration for a long time: oftentimes, you need to dig the log of the build or test run you just did, but didn't redirect it. When you have enough backlog in your terminal, that can work itself out, but usually, what happens is that you rerun the command, redirecting it to a log file, hoping what you're looking for will happen again.

For people working on the build system, it's even worse because it involves someone else: someone comes and say "my build fails with $message", and usually, thanks to parallel builds, the actual error message is buried deep in their terminal history... when they have a terminal history (Windows console, I'm looking at you).

Anyways, as of bug 985857, as long as you don't already redirect mach's output to a file, it will now save it for you automatically.

At the moment, the feature is basic, and will store the last log of the last command (mostly). So if you run mach build followed by mach xpcshell-test, only the log for the latter will be available, and the log of the former will be lost.

The log is stored in the same format as mach uses when you give it the -l argument, which is an aggregate of many json pieces, and not very user friendly. Which is why mach now also has a new command to read those logs:

mach show-log

By default, it will display the last log mach stored, but you can also give it the path to any log you got out of mach with the -l argument.

So you can do either:

mach <command>
mach show-log

or

mach -l log-file.json <command>
mach show-log log-file.json

Note that show-log will spawn less automatically, so that you have paging and search abilities.

Thanks to Lee Salzman, the state of GTK+3 support in Firefox got better. Unit tests went from looking like this:

To looking like this:

There's obviously some work left to make those look even better, but we've come a long way.

Ludovic Hirlimann recently asked if there were builds to dogfood and that prompted me to attempt making the builds from the elm branch auto-update. Which, after several attempts, I managed to get working with gross (but small) hacks of the build system.

So here we are, if you want to dogfood GTK+3 Firefox, here is what you can do::

• In a normal Linux nightly, go to about:config and create the following string preferences (right-click, New, String):
  • "app.update.url.override" with the value "https://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/elm-linux/latest/update.xml" for 32-bits builds, or "https://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/elm-linux64/latest/update.xml" for 64-bits builds,
  • "app.update.certs.3.issuerName" with the value "CN=DigiCert SHA2 Secure Server CA,O=DigiCert Inc,C=US",
  • "app.update.certs.3.commonName" with the value "ftp.mozilla.org".
• Open the burger menu, click the "?" icon, then choose "About Nightly". This should check for an update, find one, and download it. This will upgrade to a GTK+3 build.

Alternatively, you can just download and install the elm builds directly (32-bits, 64-bits).

If for some reason, you want to go back to a normal GTK+2 nightly, go to about:config, find the "app.update.url.override" preference and set it to an empty value. Triggering the update from "About Nightly" won't, however, work until the next nightly is available, so give it a day.

As mentioned in my previous post about GTK+3, if you're interested in making those builds work better, you are welcome to help:

• check the Gtk+ 3 tracking bug and its dependencies for a list of known issues or improvements to be made.
• file bugs for discrepancies you'd find between the GTK+3 and GTK+2 builds, or bugs you find in the GTK+3 build, and make them block the Gtk+ 3 tracking bug.
• check the treeherder oranges and reds on the elm branch, file bugs for them (I think at this point none are filed), or, better, fix them.
• and if you have level 1 commit access, you can test patches on the Try server, provided you pull from the elm branch or apply this patch on top of the tree you push there.

Gnome Shell, besides providing the main user interface for GNOME 3, is a Javascript shell with bindings to many native interfaces that allow e.g. Window manipulation, graphics rendering and animations, compositing, etc. It also allows developers to write extensions changing Gnome Shell's behavior.

Less known is that it is possible to replace the entire Javascript code base that Gnome Shell uses. It can be useful to hack on Gnome Shell itself (no need to fiddle with system files, or, since 3.12, no need to rebuild libgnome-shell.so), but it can also be used to implement a completely new User Interface in Javascript.

I'm starting to experiment with the latter, because I want to try building a window manager that fits my needs, while keeping away the boring details of EWMH, xinerama, and other X11 things. And because it's fun.

But baby steps, first: let's bootstrap a Hello world with Gnome shell.

• Create a directory that will hold your code.
• In that directory, create a ui subdirectory.
• In that ui directory, create a environment.js file, with the following contents:
  

  const Shell = imports.gi.Shell;
  
  function init() {
    window.global = Shell.Global.get();
  }
  

• In the same directory, create a main.js file, with the following contents:
  

  const St = imports.gi.St;
  
  function start() {
    let text = new St.Label({ text: "Hello, world!" });
    global.stage.add_actor(text);
    global.stage.show();
  }
  

• Run Gnome Shell with your code:
  

  $ GNOME_SHELL_JS=/path/to/parent/of/ui gnome-shell
  

  You may want to run this in a separate X server (I use Xephyr)

I tested this with Gnome Shell 3.14. Trying various older versions, I got different results for reasons I don't know. 3.4 doesn't display anything unless, paradoxically, global.stage.show() is removed, and 3.8 doesn't display anything no matter what.

I guess the next step is to go through some Clutter tutorials and transpose them to Javascript.

Update: On the other hand, a lot of the window managing is still done by mutter under the hood, which doesn't leave a lot of space for something really different.

[Update: An up-to-date version of this document is available on the git-cinnabar wiki]

The next branch of git-cinnabar now has minimal support for grafting, enough to allow to graft a clone of gecko-dev to mozilla-central and other Mozilla branches. This will be available in version 0.3 (which I don't expect to release before June), but if you are interested, you can already try it.

There are two ways you can work with gecko-dev and git-cinnabar.

Switching to git-cinnabar

This is the recommended setup.

There are several reasons one would want to start from gecko-dev instead of a fresh clone of mozilla-central. One is to get the full history from before Mozilla switched to Mercurial, which gecko-dev contains. Another is if you already have a gecko-dev clone with local branches, where rebasing against a fresh clone would not be very convenient (but not impossible).

The idea here is to use gecko-dev as a start point, and from there on, use cinnabar to pull and push from/to Mercurial. The main caveat is that new commits pulled from Mercurial after this will not have the same SHA-1s as those on gecko-dev. Only the commits until the switch will. This also means different people grafting gecko-dev at different moments will have different SHA-1s for new commits. Eventually, I hope we can switch gecko-dev itself to use git-cinnabar instead of hg-git, which would solve this issue.

Assuming you already have a gecko-dev clone, and git-cinnabar next installed:

• Change the remote URL:
  

  $ git remote set-url origin hg::https://hg.mozilla.org/mozilla-central

  (replace origin with the remote name for gecko-dev if it's not origin)

• Add other mercurial repositories you want to track as well:
  

  $ git remote add inbound hg::https://hg.mozilla.org/integration/mozilla-inbound
  $ git remote add aurora hg::https://hg.mozilla.org/releases/mozilla-aurora
  (...)

• Pull with grafting enabled:
  

  $ git -c cinnabar.graft=true -c cinnabar.graft-refs=refs/remotes/origin/* remote update

  (replace origin with the remote name for gecko-dev if it's not origin)

• Finish the setup by setting push urls for all those remotes:
  

  $ git remote set-url --push origin hg::ssh://hg.mozilla.org/mozilla-central
  $ git remote set-url --push inbound hg::ssh://hg.mozilla.org/integration/mozilla-inbound
  $ git remote set-url --push aurora hg::ssh://hg.mozilla.org/releases/mozilla-aurora
  (...)

Now, you're mostly done setting things up. Check out my git workflow for Gecko development for how to work from there.

Following gecko-dev

This setup allows to keep pulling from gecko-dev and thus keep the same SHA-1s. It relies on everything pulled from Mercurial existing in gecko-dev, which makes it cumbersome, which is why I don't recommend using it. For instance, you may end up pulling from Mercurial before the server-side mirroring made things available in gecko-dev, and that will fail. Some commands such as git pull --rebase will require you to ensure gecko-dev is up-to-date first (that makes winning push races essentially impossible). And more importantly, in some cases, what you push to Mercurial won't have the same commit SHA-1 in gecko-dev, so you'll have to manually deal with that (fortunately, it most cases, this shouldn't happen).

Assuming you already have a gecko-dev clone, and git-cinnabar next installed:

• Add a remote for all mercurial repositories you want to track:
  

  $ git remote add central hg::https://hg.mozilla.org/mozilla-central
  $ git remote add inbound hg::https://hg.mozilla.org/integration/mozilla-inbound
  $ git remote add aurora hg::https://hg.mozilla.org/releases/mozilla-aurora
  (...)

• For each of those remotes, set a push url:
  

  $ git remote set-url --push origin hg::ssh://hg.mozilla.org/mozilla-central
  $ git remote set-url --push inbound hg::ssh://hg.mozilla.org/integration/mozilla-inbound
  $ git remote set-url --push aurora hg::ssh://hg.mozilla.org/releases/mozilla-aurora
  (...)

• For each of those remotes, set a refspec that limits to pulling the tip of the default branch:
  

  $ git config remote.central.fetch +refs/heads/branches/default/tip:refs/remotes/central/default
  $ git config remote.inbound.fetch +refs/heads/branches/default/tip:refs/remotes/inbound/default
  $ git config remote.aurora.fetch +refs/heads/branches/default/tip:refs/remotes/aurora/default
  (...)

  Other branches can be added, but that must be done with care, because not all branches are exposed on gecko-dev.

• Set git-cinnabar grafting mode permanently:
  

  $ git config cinnabar.graft only

• Make git-cinnabar never store metadata when pushing:
  

  $ git config cinnabar.data never

• Make git-cinnabar only graft with gecko-dev commits:
  

  $ git config cinnabar.graft-refs refs/remotes/origin/*

  (replace origin with the remote name for gecko-dev if it's not origin)

• Then pull from all remotes:
  

  $ git remote update

  Retry as long as you see errors about "Not allowing non-graft import". This will keep happening until all Mercurial changesets you're trying to pull make it to gecko-dev.

With this setup, you can now happily push to Mercurial and see your commits appear in gecko-dev after a while. As long as you don't copy or move files, their SHA-1 should be the same as what you pushed.

Git-cinnabar is a git remote helper to interact with mercurial repositories. It allows to clone, pull and push from/to mercurial remote repositories, using git.

Get it on github.

What's new since 0.2.1?

• Don't require core.ignorecase to be set to false on the repository when using a case-insensitive file system. If you did set core.ignorecase to false because git-cinnabar told you to, you can now set it back to true.
• Raise an exception when git update-ref or git fast-import return an error. Silently ignoring those errors could lead to bad repositories after an upgrade from pre-0.1.0 versions on OS X, where the default maximum number of open files is low (256), and where git update-ref uses a lot of lock files for large transactions.
• Updated git to 2.4.0, when building with the native helper.
• When doing git cinnabar reclone, skip remotes with remote.$remote.skipDefaultUpdate set to true.

Git-cinnabar is a git remote helper to interact with mercurial repositories. It allows to clone, pull and push from/to mercurial remote repositories, using git.

Get it on github.

What's new since 0.2.0?

Not much, but this felt important enough to warrant a release, even though the issue has been there since before 0.1.0:

Mercurial can be slower when cloning or pulling a list of "heads" that contain non-topological heads. On repositories like the mercurial repository, it's not so much of a big deal, taking 7s instead of 4s. But on big repositories like mozilla-central, it's taking 23 minutes instead of 2 minutes and 20s (on my machine). And that's with 100% CPU use on the server side.

The problem is that mozilla-central recently merged some old closed heads, such that it now has branch heads that aren't topological heads. Git-cinnabar, until this release, would request those branch heads, leading the server to use the slow path mentioned above. This release works around the issue.

It also fixes an issue pushing to a remote empty mercurial repository.

Confusingly, GCC has a new, weird, version scheme. The first release of GCC 5 will be 5.1. It is due soon (next week). For that reason, and because it's better to find compiler bugs before it's released, I started looking into building Firefox with it.

The first round of builds I did was with 5-20150405. That got me to find a small bunch of issues:

• The new libstdc++ ABI breaks our compatibility with older libstdc++, which we've been going into great length to keep. Fortunately, it's still possible to build with some level of compatibility by compiling with -D_GLIBCXX_USE_CXX11_ABI=0.
• Some build failure in pkix gtests because of unused gtest-generated variables in an anonymous namespace.
• New false positive hits on -Warray-bounds, which, with -Werror, led the build to fail.
• New libstdc++ compatibility issue that prevented from running elfhack during the build (we don't set LD_LIBRARY_PATH to use the libstdc++ that comes with GCC). Incidentally, I found that the check to ensure we don't introduce dependencies on unwanted symbols from libstdc++ has been broken (by myself) for a few months. Fortunately, nothing slipped in between.
• An Internal Compiler Error (ICE) on --enable-debug builds, which turned out to be already fixed.

So that got me to do a second round with the first 5.1 RC, which had the fix for that ICE.

With all the above fixed, I could finally get builds out of try, and tests running, which revealed two more issues:

• Another (quickly fixed) Internal Compiler Error on 32-bits PGO builds (but only for a nightly setup, with --enable-profiling, not for a release setup, which doesn't have it).
• JS engine assertions during some JIT tests on 64-bits builds (with or without PGO), which Dan Gohman kindly tracked down and reduced to a small test case allowing to file a GCC bug and bisect to pinpoint at the GCC upstream commit that broke it (yay git bisect run on a 36-CPU EC2 instance).

Preliminary results are promising, with benchmarks improving up to 16%, but the comparison wasn't entirely fair, because they compared GCC 4.8 builds with frame pointers and JS engine diagnostics to GCC 5.1 builds without.

I'll also give a spin to LTO, possibly finding more GCC bugs in the process.