May 10th, 2016

Using git to access mercurial repositories, without mercurial

If you’ve been following this blog, you know I’ve been working on a git remote helper that gives access to mercurial repositories, named git-cinnabar. So far, it has been using libraries from mercurial itself in order to talk to local or remote repositories.

That is, until today. The current master branch now has experimental support for direct access to remote mercurial repositories, without mercurial.

2016-05-10 17:45:35+0200

cinnabar, p.m.o | 3 Comments »

April 28th, 2016

Announcing git-cinnabar 0.3.2

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.

This is mostly a bug and regression-fixing release.

What’s new since 0.3.1?

  • Fixed a performance regression when cloning big repositories on OSX.
  • git configuration items with line breaks are now supported.
  • Fixed a number of issues with corner cases in mercurial data (such as, but not limited to nodes with no first parent, malformed .hgtags, etc.)
  • Fixed a stack overflow, a buffer overflow and a use-after free in cinnabar-helper.
  • Better work with git worktrees, or when called from subdirectories.
  • Updated git to 2.7.4 for cinnabar-helper.
  • Properly remove all refs meant to be removed when using git version lower than 2.1.

2016-04-28 00:42:56+0200

cinnabar, p.m.o | No Comments »

March 10th, 2016

RIP Iceweasel, 13 Nov 2006 – 10 Mar 2016

This took longer than it should have, but a page is now officially turned. I uploaded Firefox and Firefox ESR to Debian unstable. They will have to go through the Debian NEW queue because they are new source packages, so won’t be immediately available, but they should arrive soon enough.

People using Iceweasel from Debian unstable will be upgraded to Firefox ESR.

Debian stable will receive Firefox ESR after Iceweasel/Firefox ESR38 is end-of-lifed, in about 3 months.

Thanks go to Sylvestre Ledru, Mike Connor (the same who filed bug 354622) and Stefano Zacchiroli.

2016-03-10 13:36:28+0200

p.d.o, p.m.o | 14 Comments »

February 8th, 2016

SSH through jump hosts, revisited

Close to 7 years ago, I wrote about SSH through jump hosts. Twice. While the method used back then still works, Openssh has grown an new option in version 5.3 that allows it to be simplified a bit, by not using nc.

So here is an updated rule, version 2016:

Host *+*
ProxyCommand ssh -W $(echo %h | sed 's/^.*+//;s/^\([^:]*$\)/\1:22/') $(echo %h | sed 's/+[^+]*$//;s/\([^+%%]*\)%%\([^+]*\)$/\2 -l \1/;s/:\([^:+]*\)$/ -p \1/')

The syntax you can use to connect through jump hosts hasn’t changed compared to previous blog posts:

  • With one jump host:
    $ ssh login1%host1:port1+host2:port2 -l login2
  • With two jump hosts:
    $ ssh login1%host1:port1+login2%host2:port2+host3:port3 -l login3
  • With three jump hosts:
    $ ssh login1%host1:port1+login2%host2:port2+login3%host3:port3+host4:port4 -l login4
  • etc.

Logins and ports can be omitted.

Update: Add missing port to -W flag when one is not given.

2016-02-08 00:26:53+0200

p.d.o, p.m.o | 5 Comments »

February 5th, 2016

Going beyond NS_ProcessNextEvent

If you’ve been debugging Gecko, you’ve probably hit the frustration of having the code you’re inspecting being called asynchronously, and your stack trace rooting through NS_ProcessNextEvent, which means you don’t know at first glance how your code ended up being called in the first place.

Events running from the Gecko event loop are all nsRunnable instances. So at some level close to NS_ProcessNextEvent, in your backtrace, you will see Class::Run. If you’re lucky, you can find where the nsRunnable was created. But that requires the stars to be perfectly aligned. In many cases, they’re not.

There comes your savior: rr. If you don’t know it, check it out. The downside is that you must first rr record a Firefox session doing what you’re debugging. Then, rr replay will give you a debugger with the capabilities of a time machine.

Note, I’m kind of jinxed, I don’t do much C++ debugging these days, so every time I use rr replay, I end up hitting a new error. Tip #1: try again with rr’s current master. Tip #2: roc is very helpful. But my takeaway is that it’s well worth the trouble. It is a game changer for debugging.

Anyways, once you’re in rr replay and have hit your crasher or whatever execution path you’re interested in, and you want to go beyond that NS_ProcessNextEvent, here is what you can do:

(rr) break nsEventQueue.cpp:60
(rr) reverse-continue

(Adjust the line number to match wherever the *aResult = mHead->mEvents[mOffsetHead++]; line is in your tree).

(rr) disable
(rr) watch -l mHead->mEvents[mOffsetHead]
(rr) reverse-continue
(rr) disable

And there you are, you just found where the exact event that triggered the executed code you were looking at was put on the event queue. (assuming there isn’t a nested event loop processed during the first reverse-continue)

Rinse and repeat.

2016-02-05 07:19:41+0200

p.m.o | 1 Comment »

January 30th, 2016

Enabling TLS on this blog

Long overdue, I finally enabled TLS on this blog. It went almost like a breeze.

I used simp_le to get the certificate from Let’s Encrypt, along Mozilla’s Web Server Configuration generator. SSL Labs now reports a rating of A+.

I just had a few issues:

  • I had some hard-coded http:// links in my wordpress theme, that needed changes,
  • Since my wordpress instance is reverse-proxied and the real server not behind HTTPS, I had to adjust the wordpress configuration so that it doesn’t do an infinite redirect loop,
  • Nginx’s config for multiple virtualhosts needs SSL configuration to be repeated. Fortunately, one can use include statements,
  • Contrary to the suggested configuration, setting ssl_session_tickets off; makes browsers unhappy (at least, it made my Firefox unhappy, with a SSL_ERROR_RX_UNEXPECTED_NEW_SESSION_TICKET error message).

I’m glad that there are tools helping to get a proper configuration of SSL. It is sad, though, that the defaults are not better and that we still need to tweak at all. Setting where the certificate and the private key files are should, in 2016, be the only thing to do to have a secure web server.

2016-01-30 07:22:42+0200

p.d.o, p.m.o, website | 1 Comment »

January 16th, 2016

Announcing git-cinnabar 0.3.1

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.

2016-01-16 12:26:45+0200

cinnabar, p.m.o | No Comments »

January 15th, 2016

Announcing git-cinnabar 0.3.0

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.

2016-01-15 09:56:40+0200

cinnabar, p.m.o | 2 Comments »

July 24th, 2015

Firefox nightlies for Linux are now using Gtk+3

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.

2015-07-24 02:25:37+0200

p.m.o | 2 Comments »

June 10th, 2015

PSA: mach now stores its log automatically

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.

2015-06-10 06:01:13+0200

p.m.o | 2 Comments »