1 2016-07-28 11:39:48 <rafalcpp> while building Bitcoin in gitian, it seems it tries to build from source most dependencies, and that it builds it for all platforms or something. Either way, it fails with The specified system/compiler is not supported /home/ubuntu/build/bitcoin/depends/work/build/arm-linux-gnueabihf/qt/5.5.0-a0fe95d23e3/qtbase/mkspecs/arm-linux-gnueabihf
 2 2016-07-28 11:40:50 <rafalcpp> I read that some time ago bitcoin had trouble building the GUI version for arm. So what should the people rebuilding bitcoin (and signing it) do, do we need to customize the build process to skip some targets?
 3 2016-07-28 11:41:40 <wumpus> correct, it can't build the GUI version for ARM. But the gitian descriptiors aren't doing this either
 4 2016-07-28 11:42:41 <rafalcpp> ( that bug re building GUI on ARM was https://github.com/bitcoin/bitcoin/issues/5339 but it's now closed)
 5 2016-07-28 11:42:49 <wumpus> e.g. by looking at the sizes rc1 executables this is already clear: https://bitcoin.org/bin/bitcoin-core-0.13.0/test.rc1/
 6 2016-07-28 11:43:11 <wumpus> you don't need to do anything for that, the descriptors won't even try to build GUI for ARM
 7 2016-07-28 11:44:02 <wumpus> yes that issue is closed because we don't regard it as an issue, not because it was ever solved
 8 2016-07-28 11:44:47 <wumpus> even modern ARM boards are generally just strong enough to run a node, let alone trying to run bitcoin-qt and graphical shell with it
 9 2016-07-28 11:45:30 <rafalcpp> wumpus: it seems to do that by default, when I do   ./bin/gbuild --commit bitcoin=v${VERSION} ../bitcoin/contrib/gitian-descriptors/gitian-linux.yml    (using LXC approach)
10 2016-07-28 11:52:52 <rafalcpp> wumpus: do you use other command?
11 2016-07-28 11:53:48 <wumpus> you may have a conflict between the descriptors you are using and the commit you are building
12 2016-07-28 11:57:22 <rafalcpp> wumpus: gitian-builder is current, that is ee1b69d6949810069453d5540af7a0b3ca63ea8d  Wed Jun 15 21:25:42 2016 -0700, and VERSION (of bitcoin) is 0.12.0.  Should I try other one?  Details http://pastebin.com/raw/7BMuibQX
13 2016-07-28 11:58:09 <wumpus> I don't mean the version of gitian-builder, but the version of the bitcoin tree where you're using the descriptors from
14 2016-07-28 11:58:27 <wumpus> what is checked out there should match the tag/commit that you are building
15 2016-07-28 11:58:41 <wumpus> it almost looks like you're trying to build 0.12 with 0.13's descriptors, that just won't work
16 2016-07-28 11:58:58 <rafalcpp> wumpus: oh, I though it was doing a git checkout itself on the tag from $VERSION. ok will try that
17 2016-07-28 15:45:19 <rafalcpp> yeap it works then
18 2016-07-28 16:12:48 <rafalcpp> bitcoin build produced other checksums for the bitcoin deb and ~half of the libs, but I see also there are other versions of the libs used
19 2016-07-28 16:13:13 <rafalcpp> what lxc image should be created to build v0.12.0, ubuntu trusty or ubuntu precise?
20 2016-07-28 16:13:46 <rafalcpp> https://github.com/bitcoin/bitcoin/blob/v0.12.0/doc/gitian-building.md  says to use " Currently this is Ubuntu Precise x86_64. "  but then it continues to give command "bin/make-base-vm --lxc --arch amd64 --suite trusty"
21 2016-07-28 16:14:11 <rafalcpp> also building based on trusty given me too new libs (and wrong checksums of course)
22 2016-07-28 16:16:04 <rafalcpp> e.g. my assert yml generated with "apt-utils_1.0.1ubuntu2.14_amd64.deb" intead of "apt-utils_1.0.1ubuntu2.11_amd64.deb" as it should be according to https://raw.githubusercontent.com/bitcoin-core/gitian.sigs/master/0.12.0-linux/theymos/bitcoin-linux-0.12-build.assert
23 2016-07-28 16:16:29 <rafalcpp> (i'm trying to rebuild 0.12.0 in gitian and get same checksums as them)
24 2016-07-28 16:21:29 <rafalcpp> gitian-linux.yml also says Trusty so I guess it must be the one, but then how to get older libs there
25 2016-07-28 16:25:44 <rafalcpp> should Gitian build be reproducible still when distro moved on and updated package?  it was at 1.0.1ubuntu2.11 when built by bitcoin core, but now it is at ubuntu2.13 in trusty, ubuntu2.14 in trusty-updates
26 2016-07-28 16:31:49 <rafalcpp> Btw why we use Ubuntu for LXC guest on wich gitian should run? it changes a lot.  Also gitian crates vms but downloading some images of boxes? Shouldn't we use some more verifiable approach like some deboostrap?
27 2016-07-28 17:01:33 <rafalcpp> wumpus: do I understand correctly that in current setup of gitian you can not easily reproduce few-months-old build, because some parts of it are doing apt-get update / safe-upgrade and are getting too new versions of libs?  Is this an open problem?
28 2016-07-28 17:02:22 <rafalcpp> if yes then is it an non-taken open and worth-while task to write small script that will take the base-image (of lxc) and add script that installs exact pinned versions of libraries?
29 2016-07-28 17:03:16 <rafalcpp> I guess it should support fully offline use case, in case older versions of libs have vulns but we must keep them pinned for build
30 2016-07-28 18:59:36 <wumpus> rafalcpp: note that the exact apt packages versions are part of the assert, which is committed to the signatures repository and signed, so at least in theory you can exactly reproduce the setup, although finding specific older versions of packages may be a challenge
31 2016-07-28 19:00:14 <wumpus> rafalcpp: it's not really a problem; even with changed packages the output hardly changes, most don't affect the output except some changes to gcc/g++, but these are fairly rare
32 2016-07-28 19:00:51 <wumpus> rafalcpp: specifically, libraries hardly affect the result because we build all our own dependencies