Recent comments on posts in the blog:

Stephen Kitt also pointed that Debian Stretch's MinGW has improved reproducibility provided you trigger it with SOURCE_DATE_EPOCH.
'-Wl,--no-insert-timestamp' helps too. I'm currently running additional tests, I'll probably post a follow-up :)

Comment by beuc Sat Mar 25 20:37:27 2017

Windows executables include a "link time" field which you need to fix. If you build a PDB they will also contain the absolute path to that by default.

(There are probably some other issues; I haven't worked on Windows for a long time.)

Comment by Anonymous Sat Mar 25 04:26:34 2017

Following the discussions, Replicant is currently thinking about earlier, SDK-focused ports, and F-Droid expressed interest in freeing the SDK&NDK they use (although the diversity of the packages means all SDK platform versions need to be available).

I think it's important to keep rebuilding and testing the dev tools, to assess feasibility and raise confidence.

Comment by beuc Wed Oct 7 14:07:21 2015
Comment by beuc Sun Oct 4 13:13:32 2015

Interesting projects.

  • bbqlinux: we could approach Arch, which provides a binary package/wrapper for the SDK, so they package an independent rebuilt instead
  • linuxonandroid: running Debian inside Android, not really relevent here I think
  • androidx86: running Android on PC - I believe this is now officially supported by Android?
Comment by beuc Sun Oct 4 13:13:00 2015

Interesting that Google cloned Java and is now throwing roadblocks.

I wonder if running this as a VM client inside Debian helps:

And linux tools in Andorid are GPL

Comment by Anonymous Fri Oct 2 01:36:04 2015
Quite interested and with lots of powerful resources ;) let's talk about I can also support for Debian package too nigifabio (at)
Comment by Anonymous Fri Oct 2 00:47:58 2015

I'd welcome help figuring out how to publish a full SDK in Debian.

I'm pretty sure that we'll get loads of nitpicks over duplicate (and patched) GCC versions and not following the FHS, need to generate 10-20GB source tarballs, patches to deal with different build dep versions (they standardize on Ubuntu LTS), etc. Also the SDK itself, even already large, is just an empty shell, and requires to download "API platforms", some of them built long ago and requiring an old build environment to be reproduced.

We could also find a completely new way to build the SDK/NDK/etc. in a more modular fashion, possibly incompatible with other dev tools for Android - probably what the Debian Android Team has been trying for the past 5 years ;)

Having the SDK in Debian would be really nice - but how? Suggestions?

Comment by beuc Thu Sep 24 11:57:56 2015
Each time I think of writing code for Android I wonder why I have to download the SDK as a massive tarball from Google. It would be so much better the tools from the SDK could be packaged and included in Debian.
Comment by edward Wed Sep 23 13:11:38 2015

I'm sure I remember the restriction in point 3.3 b "[You may not] load any part of the SDK onto a mobile handset or any other hardware device except a personal computer" from when I've read the terms and conditions of the SDK back in the times of Android 1.4 - 1.6 when I decided that I didn't want anything to do with the binary SDK and tried to build it myself; it wasn't the only reason, so probably at least some other conditions were already there.

I had some success with 1.4, but then I've never had a computer powerful enough to build the SDK and just decided to ignore it and maybe hope that one day the SDK would have been available in Debian as a package.

Comment by Anonymous Tue Sep 22 09:48:56 2015