1 2014-06-02 00:08:07 <sipa> kanzure: there is a dos score in bitcoind
  2 2014-06-02 00:08:18 <sipa> andnif you exceed a treshold you're disconnected and banned
  3 2014-06-02 00:08:20 <kanzure> ah okay
  4 2014-06-02 00:09:03 <kanzure> phantomcircuit: have you collected data about how long it takes for network saturation?
  5 2014-06-02 00:09:03 <phantomcircuit> sipa, there's very few things you can do to actually increase that score though
  6 2014-06-02 00:09:19 <sipa> phantomcircuit: almost any consensus rule breaking triggers it
  7 2014-06-02 00:09:32 <sipa> most policy things don't
  8 2014-06-02 00:09:55 <sipa> and recently introduced consensus ruoes don't either, as that would risk splittingnthe network
  9 2014-06-02 00:10:28 <sipa> (old nodes broadcast something among themsepf, but grt banned by new nodes immediately when it propagates across the old-new boundary)
 10 2014-06-02 00:10:48 <phantomcircuit> sipa, ah yeah i see
 11 2014-06-02 00:11:01 <phantomcircuit> that's not an issue unless you're doing something super bizarre though
 12 2014-06-02 00:11:21 <sipa> but an invalid signature or wrong pow or ... certainly does trigger it
 13 2014-06-02 00:11:32 <phantomcircuit> right
 14 2014-06-02 00:11:34 <phantomcircuit> lol
 15 2014-06-02 00:11:45 <phantomcircuit> shipped ~2% of the network across the country yesterday
 16 2014-06-02 00:11:54 <sipa> ;;nethash
 17 2014-06-02 00:11:55 <gribble> 86679508.1869
 18 2014-06-02 00:12:09 <phantomcircuit> literally fits on a single truck
 19 2014-06-02 00:12:23 <sipa> > 1 PH/s? :o
 20 2014-06-02 00:12:31 <phantomcircuit> sipa, lol yeah
 21 2014-06-02 00:12:50 <sipa> 
ACTION has 1/100000th of thay

 22 2014-06-02 00:12:55 <sipa> *that
 23 2014-06-02 00:13:00 <phantomcircuit> aha
 24 2014-06-02 00:13:21 <phantomcircuit> sipa, i'd send you a ct box but there's like an 80% chance it wouldn't work on arrival
 25 2014-06-02 00:13:22 <phantomcircuit> >.>
 26 2014-06-02 00:13:25 <phantomcircuit> <.<
 27 2014-06-02 00:15:15 <sipa> ct box?
 28 2014-06-02 00:15:28 <phantomcircuit> cointerra
 29 2014-06-02 00:15:32 <sipa> right
 30 2014-06-02 00:15:57 <sipa> i haven't followed up on mining at all since my BFL jalapenos became worthless :p
 31 2014-06-02 00:16:28 <phantomcircuit> sipa, they're still technically profitable upto iirc 250 Ph/s
 32 2014-06-02 00:16:36 <sipa> too much business, too little fun
 33 2014-06-02 00:16:38 <phantomcircuit> well at least they are if you have fairly cheap power
 34 2014-06-02 00:16:44 <phantomcircuit> yeah
 35 2014-06-02 00:16:50 <sipa> ;;genrate 11000
 36 2014-06-02 00:16:51 <gribble> The expected generation output, at 11000.0 Mhps, given difficulty of 10455720138.5, is 0.000529085668655 BTC per day and 2.2045236194e-05 BTC per hour.
 37 2014-06-02 00:17:07 <phantomcircuit> sipa, a lot of the people thinking that mining will be decentralized fundamentally dont understand the economics of it
 38 2014-06-02 00:17:14 <jaekwon> how about the effect of using TCP?  (swift works on UDP).
 39 2014-06-02 00:17:35 <sipa> at 0.2$ per day i really won't bother
 40 2014-06-02 00:17:40 <phantomcircuit> jaekwon, bitcoin connections are long lived, i dont think the congestion control stuff is much of an issue
 41 2014-06-02 00:17:47 <jaekwon> gotcha.
 42 2014-06-02 00:18:06 <phantomcircuit> sipa, yeah, but if you have 10k of them
 43 2014-06-02 00:18:17 <phantomcircuit> you'd sell them on ebay
 44 2014-06-02 00:18:18 <phantomcircuit> lol
 45 2014-06-02 00:18:49 <jcorgan> phantomcircuit: almost all capital intensive businesses have economies of scale that result in a power law distribution of business sizes.  Bitcoin mining is no different.
 46 2014-06-02 00:19:27 <phantomcircuit> jcorgan, except bitcoin mining isn't actually capital intensive outside of the short run
 47 2014-06-02 00:19:51 <phantomcircuit> operations and straight power/cooling costs rapidly dwarf the capital costs
 48 2014-06-02 00:20:14 <phantomcircuit> for an example
 49 2014-06-02 00:20:30 <kanzure> i've been meaning to do an analysis of the minimum capital requirements for asic production (outside of the existing asic fabs)
 50 2014-06-02 00:20:31 <phantomcircuit> cointerra is selling mining contracts for $2.50/Gh (or they were they raised their prices)
 51 2014-06-02 00:20:46 <phantomcircuit> the power/cooling on 1 Gh/s for their boxes is ~$1.25/year
 52 2014-06-02 00:21:07 <jcorgan> well, with the current (last couple years?) continuous difficulty increase, replacement of mining gear with new, faster hardware is capital cost, no?
 53 2014-06-02 00:21:16 <phantomcircuit> which leaves them with $1.25 to pay for the hardware, installation, and ongoing maintenance of all that shit
 54 2014-06-02 00:21:26 <phantomcircuit> (hint they're going to lose tons of money at that price point)
 55 2014-06-02 00:21:58 <phantomcircuit> jcorgan, there isn't a whole lot of space between where bitcoin mining chips are and the limits of the technology
 56 2014-06-02 00:22:27 <jcorgan> sure, i see that leveling off or at least becoming sub-exponential in a year or two
 57 2014-06-02 00:22:41 <jaekwon> warehousing, cooling, and energy sources don't need to be replaced
 58 2014-06-02 00:22:46 <phantomcircuit> jcorgan, uh much sooner than that
 59 2014-06-02 00:23:11 <phantomcircuit> if we continue at 1%/day for another 8 months bitcoin miners will be using like 10 hoover dams worth of electricity
 60 2014-06-02 00:23:16 <phantomcircuit> that doesn't seem very likely
 61 2014-06-02 00:23:51 <jaekwon> well
 62 2014-06-02 00:24:12 <phantomcircuit> we're at ~85Ph/s today
 63 2014-06-02 00:24:15 <jaekwon> that day might come, for better or for worse.
 64 2014-06-02 00:24:21 <phantomcircuit> given the mix of hardware going to that
 65 2014-06-02 00:24:32 <jcorgan> fair enough.  my original point was more that economies of scale result in power law distributions of production capacity, with high capital costs, even more so.  so the presence of 2-3 large firms and a tail of many smaller ones is normal.
 66 2014-06-02 00:24:32 <phantomcircuit> im guessing that's about 150MW of electricity
 67 2014-06-02 00:25:07 <phantomcircuit> assuming we wont see full machines doing better than 0.3J/Gh within 12 months
 68 2014-06-02 00:25:27 <jcorgan> so hashrate distribution in the bitcoin economy doesn't seem overly centralized to me; it pretty much looks the way i'd expect.
 69 2014-06-02 00:25:34 <phantomcircuit> and that all the hw is replaced with that more efficient hw
 70 2014-06-02 00:25:37 <jcorgan> but this is probably #bitcoin, not -dev
 71 2014-06-02 00:25:38 <kanzure> jcorgan: often i've been finding that the capital costs are balogna, or based on knowledge arbitration (industrial equipment often costs way more than it would cost you to build it)
 72 2014-06-02 00:25:49 <phantomcircuit> that's 3200 Ph/s in 365 days
 73 2014-06-02 00:26:21 <phantomcircuit> which would be enough power for like all of new york city
 74 2014-06-02 00:26:46 <phantomcircuit> that would be difficult to cool even in the artic circle, you'd be raising the ambient temperature of the outside air...
 75 2014-06-02 00:27:36 <phantomcircuit> anyways
 76 2014-06-02 00:27:39 <phantomcircuit> back to the original point
 77 2014-06-02 00:28:00 <phantomcircuit> kanzure, i dont think you're going to substantially improve the initial sync
 78 2014-06-02 00:28:25 <phantomcircuit> just compressing the blockchain data would be a much larger improvement than anything else
 79 2014-06-02 00:28:45 <kanzure> if you have supernodes that are each connected to different parts of the graph and pipe your data straight to your supernodes, then transactions can reach network saturation  faster, i think
 80 2014-06-02 00:29:38 <kanzure> oh, initial sync.. dunno.
 81 2014-06-02 00:31:28 <phantomcircuit> kanzure, that's true only if you assume that the first node to get the data doesn't have sufficient bandwidth to push the block to the entire network (to be fair that is almost universally the case)
 82 2014-06-02 00:31:33 <jaekwon> seems like a good way is to propagate the blockheader first, then libswift on all the blocktransactions… even if the block is invalid, it should only happen occasionally & it's the miner's loss.
 83 2014-06-02 00:31:50 <kanzure> when you mention swift you don't mean the bank-to-bank protocol?
 84 2014-06-02 00:32:09 <jaekwon> no, libswift.
 85 2014-06-02 00:32:15 <jaekwon> the UDP merkle based p2p protocol.
 86 2014-06-02 00:32:16 <phantomcircuit> no confusingly he's talking about a p2p content network
 87 2014-06-02 00:32:20 <kanzure> "swift is a multiparty transport protocol. Its mission is to disseminate content among a swarm of peers.", oh, like serf
 88 2014-06-02 00:32:21 <jaekwon> :)
 89 2014-06-02 00:34:36 <dgenr8> to build and maintain the tx index, I need to run with -reindex and -txindex once, then run with only -txindex thereafter.  have I got that right?
 90 2014-06-02 00:34:56 <phantomcircuit> 1MB * 7739 nodes = 7739 MB = 61912 megabits
 91 2014-06-02 00:35:01 <phantomcircuit> assuming a 10gbps connection
 92 2014-06-02 00:35:06 <jaekwon> yes, dgenr8
 93 2014-06-02 00:35:24 <phantomcircuit> that's 6.1912 seconds to push to the entire network
 94 2014-06-02 00:35:41 <phantomcircuit> getting the logic right on doing that without causing tcp congestion control is non trivial
 95 2014-06-02 00:36:06 <dgenr8> jaekwon: ty
 96 2014-06-02 00:41:53 <jaekwon> kanzure: not familiar with serf. i'd say libswift is more like libtorrent.  is serf resistant to malicious nodes, or better suited for intranets?
 97 2014-06-02 00:42:02 <mr_burdell> does anyone know of a python script that runs the isstandard checks on a transaction?
 98 2014-06-02 00:42:20 <kanzure> jaekwon: it's just a gossip protocol
 99 2014-06-02 01:43:58 <brandondahler> Does anyone know if there is any existing documentation of the LevelDB entry types
100 2014-06-02 01:44:56 <brandondahler> I know it is all in the txdb.cpp file, just wondering if there's actual documentation
101 2014-06-02 01:49:06 <maaku> no
102 2014-06-02 01:49:17 <maaku> the source code is the documentation
103 2014-06-02 03:20:10 <justanotheruser> There isn't any page documenting what all the source files in bitcoin core exactly do is there? The code is someone hard to follow with all the different function calls and threads.
104 2014-06-02 03:49:37 <brandondahler> Would anybody have feelings on a proposal to split all of the leveldb entry types into their own leveldbs?  The rationale is that it would localize the types of reindexing required when one has been corrupted.
105 2014-06-02 03:50:28 <justanotheruser> ^interested in the answer
106 2014-06-02 04:01:43 <gmaxwell> brandondahler: uh, they're already split.
107 2014-06-02 05:17:03 <warren> 2d5367ee5d06224773c5064f6f3ea9d742a8c7780252c4e64b5aa002caff4732  qt-linux32-4.6.4-gitian-r1.tar.gz
108 2014-06-02 05:17:03 <warren> e503b2b8c8f91f23dfa4442aa2b5cf84075571e291296100003fcac3362438e8  qt-linux64-4.6.4-gitian-r1.tar.gz
109 2014-06-02 06:15:18 <michagogo> warren: okay, so not just me
110 2014-06-02 06:23:23 <michagogo> Is there a second set of hashes besides wumpus's to check for determinism in the end product?
111 2014-06-02 06:25:14 <wumpus> gavin also uploaded sigs to gitian
112 2014-06-02 06:25:55 <michagogo> Did they match?
113 2014-06-02 06:26:56 <michagogo> (On phone atm)
114 2014-06-02 06:27:06 <wumpus> for the linux build it seems -cli and bitcoind match, but not -qt
115 2014-06-02 06:27:19 <michagogo> Ouch.
116 2014-06-02 06:28:31 <michagogo> Later today I should be able to give you my qt, if it helps...
117 2014-06-02 06:28:47 <wumpus> windows matches
118 2014-06-02 06:28:57 <michagogo> (Note to self: upload results next time)
119 2014-06-02 06:29:11 <wumpus> the final executables are fine, too
120 2014-06-02 06:29:25 <michagogo> Fine as is they work?
121 2014-06-02 06:29:28 <michagogo> That's good.
122 2014-06-02 06:29:28 <wumpus> if you don't have qt anymore
123 2014-06-02 06:29:31 <wumpus> no, if you could upload them
124 2014-06-02 06:30:18 <michagogo> Oh, I see
125 2014-06-02 06:30:23 <michagogo> I don't have finals yet
126 2014-06-02 06:30:37 <michagogo> Part way through the assorted deps when I had to go
127 2014-06-02 06:31:45 <wumpus> mac dmg also doesn't match between gavin and me
128 2014-06-02 06:32:03 <michagogo> wumpus: I just mean that I didn't upload them before I went to sleep, so I can't point you at them now
129 2014-06-02 06:32:20 <wumpus> so I suppose rc1 is officially dead...
130 2014-06-02 06:32:26 <michagogo> (They're inside a VM on my laptop)
131 2014-06-02 06:32:42 <wumpus> ok, no problem, if you can upload them later that'd be useful
132 2014-06-02 06:33:56 <michagogo> wumpus: they will be at gitian.michagogo.cadoth.net
133 2014-06-02 06:40:58 <SomeoneWeird> is there a tutorial somewhere about setting up gitian?
134 2014-06-02 06:41:23 <wumpus> SomeoneWeird: https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-building.md
135 2014-06-02 06:42:12 <SomeoneWeird> wumpus, thx
136 2014-06-02 06:50:57 <SomeoneWeird> wumpus, seems the netinst link is broken, btw
137 2014-06-02 06:51:14 <wumpus> sigh, already
138 2014-06-02 06:57:18 <wumpus> seems 7.5.0 was released, and they threw away the 7.4.0 files immediately
139 2014-06-02 06:57:22 <SomeoneWeird> http://ftp.acc.umu.se/debian-cd/7.5.0/amd64/iso-cd/debian-7.5.0-amd64-netinst.iso
140 2014-06-02 06:57:23 <SomeoneWeird> heh, yeah
141 2014-06-02 06:57:32 <wumpus> I don't think there's any problem with using 7.5 tho
142 2014-06-02 07:07:55 <michagogo> 7.4 is still available at http://cdimage.debian.org/cdimage/archive/7.4.0/amd64/iso-cd/debian-7.4.0-amd64-netinst.iso
143 2014-06-02 07:08:39 <michagogo> But if it's like Ubuntu's point releases, it doesn't matter because an apt-get upgrade will bring you to 7.5.0 anyway
144 2014-06-02 07:09:00 <michagogo> (it's really annoying how I keep needing to reinstall VBox guest additions...)
145 2014-06-02 07:09:22 <michagogo> Just yesterday, I booted and it worked fine
146 2014-06-02 07:09:40 <michagogo> But now when I start it again, nope. No integration.
147 2014-06-02 07:10:00 <michagogo> (and the installer even detects and removes the current installation...)
148 2014-06-02 07:11:38 <wumpus> strange; I never had problems with that
149 2014-06-02 07:12:02 <wumpus> somehow it must disable/remove the virtualbox-guest-* packages?
150 2014-06-02 07:12:39 <michagogo> Oh, wait a minute
151 2014-06-02 07:12:51 <michagogo> Maybe it has to do with the updates I installed
152 2014-06-02 07:13:17 <michagogo> Oh, actually, I think the guest extensions hook into the kernel
153 2014-06-02 07:13:45 <michagogo> Maybe when the kernel gets upgraded they break.
154 2014-06-02 07:14:12 <wumpus> in theory, 'DKMS' should automatically build them for the new kernel
155 2014-06-02 07:28:15 <michagogo> wumpus: ping
156 2014-06-02 07:28:24 <michagogo> qt uploading right now
157 2014-06-02 07:29:06 <wumpus> I think I already found the reason for the non-determinism, a qt installation date snuck into the host utils (lrelease etc)
158 2014-06-02 07:29:29 <wumpus> that shouldn't affect the end product though, so it doesn't explain why gavin's and mine build is different
159 2014-06-02 07:30:55 <michagogo> wumpus: 32 is up, 64 uploading
160 2014-06-02 07:31:25 <michagogo> Actually, I'll kill my windows deps build and build linux release first
161 2014-06-02 07:46:44 <wumpus> michagogo: https://github.com/bitcoin/bitcoin/pull/4270
162 2014-06-02 07:49:59 <michagogo> wumpus: Okay, I'll build qt with that change after linux finishes building
163 2014-06-02 07:50:23 <wumpus> yes I wonder what end product you get
164 2014-06-02 07:50:43 <michagogo> Did you get Gavin's outputs to compare, or just the sigs?
165 2014-06-02 07:51:24 <wumpus> if it matches mine, then it's caused by Gavin's non-standard build setup
166 2014-06-02 07:51:52 <wumpus> I compare the gitian .assert file
167 2014-06-02 07:53:10 <michagogo> Do you KVM or LXC?
168 2014-06-02 07:53:27 <wumpus> I really doubt that matters here, but I use KVM
169 2014-06-02 07:53:51 <michagogo> Well, it's more that I'd like to make sure we have at least one person using kvm
170 2014-06-02 07:54:26 <michagogo> Okay, don't have an assert yet, but 32-bit did finish
171 2014-06-02 07:55:04 <michagogo> 01466bc58f824c6bb9092f8e74534a8d802018b54981715f2b061fed6c7f3a12  build/out/bin/32/bitcoind
172 2014-06-02 07:55:04 <michagogo> 0d79efee384d8af6cd8d4c6d5ef173d2329a3f9bd8f686990ddfb3b5cd808d44  build/out/bin/32/bitcoin-qt
173 2014-06-02 07:55:04 <michagogo> 72d824bf204ea070e302ca506e55d36a27ac90c1fd8416f51ca92f4c1ea4dd57  build/out/bin/32/test_bitcoin-qt
174 2014-06-02 07:55:04 <michagogo> b28886a94550d8d1f347b27c53517d7cdf8535e0d740396ce22de56179bd20bd  build/out/bin/32/test_bitcoin
175 2014-06-02 07:55:04 <michagogo> bf16510ce7b46b338348e9548eaae0ed05cd76fc647748af501d85be889d801c  build/out/src/bitcoin-0.9.2.tar.gz
176 2014-06-02 07:55:04 <michagogo> c33d0ed67703a4b82d8e8dda5f3fdd65ecace53cb8324194d1baa093f0e5b8c1  build/out/bin/32/bitcoin-cli
177 2014-06-02 07:55:40 <wumpus> matches mine (https://github.com/bitcoin/gitian.sigs/blob/master/0.9.2rc1/laanwj/bitcoin-build.assert)
178 2014-06-02 07:56:22 <wumpus> so as I expected, gavin's is the odd duck out :)
179 2014-06-02 07:57:20 <michagogo> Interesting
180 2014-06-02 07:58:07 <michagogo> What does he use again?
181 2014-06-02 07:58:15 <michagogo> VBox with a bunch of packages installed for all builds?
182 2014-06-02 07:58:22 <wumpus> maybe he's somehow still building against qt 4.8 dev packages instaad of the qt 4.6 we build ourselves
183 2014-06-02 07:58:23 <wumpus> yes
184 2014-06-02 07:58:43 <michagogo> I guess he didn't post his bins somewhere?
185 2014-06-02 07:59:34 <wumpus> in that case his output will be problematic, as it will not be compatible with older linux versions
186 2014-06-02 08:01:31 <wumpus> we explicitly set PKG_CONFIG_PATH to "$STAGING/lib/pkgconfig" , so from what I understand our qt library should take precedence...
187 2014-06-02 08:02:32 <wumpus> let's see what happens if I add back the conflicting qt dev package
188 2014-06-02 08:03:28 <michagogo> Heh...  https://plus.google.com/app/basic/photos/+BrunoOliveira/album/6019700701442528065/6019700701980497298
189 2014-06-02 08:04:11 <michagogo> erm, that's the mobile version. oops.
190 2014-06-02 08:04:49 <michagogo> https://plus.google.com/photos/+BrunoOliveira/album/6019700701442528065/6019700701980497298
191 2014-06-02 08:18:17 <michagogo> 256fed66c98f362b78e9e98e4cd112b36e579e99c290567bfaf8a30fd3e3138e  bin/64/bitcoin-cli
192 2014-06-02 08:18:18 <michagogo> 5209679c2e776bb9b498a17aef50776c01cae8c35da44338281b887a4d62b303  bin/64/test_bitcoin
193 2014-06-02 08:18:18 <michagogo> 8137465173b2ee352fba63bd8cd12063d0533c9270a4aa895511a8f92f1a1086  bin/64/test_bitcoin-qt
194 2014-06-02 08:18:18 <michagogo> 89d3dc0093dd586d799d3c556f7777d154553056a48249beffb1c5fc4931235e  bin/64/bitcoin-qt
195 2014-06-02 08:18:18 <michagogo> 93fafc01d702337ab23c24ecc624f767a69ff82ff07ca835db653312630c7eb5  bin/64/bitcoind
196 2014-06-02 08:19:10 <wumpus> michagogo: no need to paste all that here, you can just compare with my gitian assert
197 2014-06-02 08:20:59 <t7> thats a long hash
198 2014-06-02 08:21:30 <wumpus> HAH, I managed to match gavin's hashes by adding the libqt4-dev package
199 2014-06-02 08:22:35 <michagogo> Heh.
200 2014-06-02 08:22:55 <t7> i guess its because its not in base64
201 2014-06-02 08:22:55 <wumpus> this sucks though
202 2014-06-02 08:26:15 <sipa> wumpus: what's your hypothesis?
203 2014-06-02 08:28:50 <michagogo> wumpus: are you able to figure out from the binary what's different
204 2014-06-02 08:28:51 <michagogo> ?
205 2014-06-02 08:29:17 <wumpus> sipa, michagogo see my post in https://github.com/bitcoin/bitcoin/pull/4270
206 2014-06-02 08:29:53 <michagogo> Well, IMHO while it's annoying, it's not our problem per se
207 2014-06-02 08:30:21 <michagogo> It works fine in the configuration that we specify, with a clean gitian image
208 2014-06-02 08:31:44 <wumpus> right, if gavin were to uninstall the libqt4 dev packages from his VM, it would work
209 2014-06-02 08:31:58 <sipa> how does it have those in his VM?
210 2014-06-02 08:32:00 <wumpus> if that avoids having to scrap rc1 that'd be nice
211 2014-06-02 08:32:14 <wumpus> sipa: he has a VM preloaded with all kinds of packages
212 2014-06-02 08:32:16 <michagogo> sipa: he has a whole bunch of extra packages in his base vm
213 2014-06-02 08:32:35 <michagogo> (as you can tell from looking at his base manifests)
214 2014-06-02 08:33:32 <sipa> ic
215 2014-06-02 08:34:12 <michagogo> wumpus: did you say the os x was also not matching?
216 2014-06-02 08:34:30 <wumpus> michagogo: yes; all the inputs seem to match, but not the dmg itself
217 2014-06-02 08:34:42 <wumpus> michagogo: let's see what you get, may be the same problem
218 2014-06-02 08:35:07 <wumpus> there are just too many gitian environments that we have to support :/
219 2014-06-02 08:35:21 <sipa> ... wasn't that the problem gitian was supposed to solve? :)
220 2014-06-02 08:35:23 <michagogo> IMHO we shouldn't support environments like Gavin...
221 2014-06-02 08:35:29 <michagogo> Gavin's*
222 2014-06-02 08:35:32 <wumpus> sipa: yes :P it's sad
223 2014-06-02 08:36:16 <michagogo> Installing a bunch of packages in the base VM kinda defeats the purpose of gitian
224 2014-06-02 08:36:25 <michagogo> Well, maybe not exactly
225 2014-06-02 08:36:36 <sipa> how about we add support for some deterministic turing machine to LLVM?
226 2014-06-02 08:36:40 <wumpus> we reallly need a consistentVM that can be used on every OS, and behaves on every OS in the same way, but doesn't forego processor acceleration to achieve that ...
227 2014-06-02 08:36:51 <sipa> :)
228 2014-06-02 08:37:19 <michagogo> Well, the issue is that you need utilities on the host as well
229 2014-06-02 08:37:29 <michagogo> apt-cacher-ng, etc
230 2014-06-02 08:37:44 <sipa> wumpus: i'd like to see 4261 in rc2, if there is one :)
231 2014-06-02 08:37:45 <michagogo> Oh, I see what you're saying (maybe?)
232 2014-06-02 08:38:37 <wumpus> sipa: ok
233 2014-06-02 08:38:49 <michagogo> A VM that would run the same way on any OS, within which we could run a Debian or an Ubuntu or something, within which we could run KVM gitian?
234 2014-06-02 08:39:21 <wumpus> michagogo: we need platform independent versions of the host tools, for example implement all the stuff in python/ruby
235 2014-06-02 08:39:30 <michagogo> Right
236 2014-06-02 08:39:39 <michagogo> What tools are involved here again?
237 2014-06-02 08:39:43 <wumpus> michagogo: mimicing apt-cacher-ng behavior would be pretty easy in python
238 2014-06-02 08:39:47 <gribble> Gitian: a secure software distribution method: <http://gitian.org/>; devrandom/gitian-builder · GitHub: <https://github.com/devrandom/gitian-builder>; Building bitcoin with gitian-builder - Gists - GitHub: <https://gist.github.com/806265>
239 2014-06-02 08:39:47 <michagogo> ;;google gitian-builder
240 2014-06-02 08:39:52 <wumpus> it's just a web proxy/cache...
241 2014-06-02 08:40:10 <wumpus> I think the difficult part is building the VM image
242 2014-06-02 08:40:20 <wumpus> it requires all kinds of obscure tools
243 2014-06-02 08:40:30 <wumpus> but once that's built, from there it's easy
244 2014-06-02 08:40:31 <michagogo> sudo apt-get install git apache2 apt-cacher-ng python-vm-builder ruby qemu-utils qemu-kvm debootstrap lxc
245 2014-06-02 08:41:15 <wumpus> note that apache2 is not needed
246 2014-06-02 08:41:34 <michagogo> sudo vmbuilder kvm ubuntu --rootsize 10240 --arch=$ARCH --suite=$SUITE --addpkg=$addpkg --removepkg=$removepkg --ssh-key=var/id_dsa.pub --ssh-user-key=var/id_dsa.pub --mirror=$MIRROR --security-mirror=$SECURITY_MIRROR --dest=$OUT --flavour=$FLAVOUR --firstboot=`pwd`/target-bin/bootstrap-fixup
247 2014-06-02 08:41:48 <michagogo> That's the command that actually builds the VM, it looks like
248 2014-06-02 08:41:56 <wumpus> yes the vmbuilder/debootstrap stuff
249 2014-06-02 08:42:21 <wumpus> I wonder if we could build the VM in a VM
250 2014-06-02 08:42:24 <wumpus> oh wait :)
251 2014-06-02 08:42:39 <michagogo> We do :P
252 2014-06-02 08:43:04 <wumpus> right, that's what vmbuilder does, and vmbuilder is just a set of ruby scripts isn't it?
253 2014-06-02 08:43:16 <michagogo> https://launchpad.net/vmbuilder
254 2014-06-02 08:44:05 <michagogo> http://bazaar.launchpad.net/~vmbuilder-dev/vmbuilder/0.12/files
255 2014-06-02 08:44:33 <wumpus> anyhow: creating a debian VM image and using LXC inside, as described in my gitian guide, works reliably
256 2014-06-02 08:45:17 <wumpus> you get this container-in-a-VM thing which isn't very elegant, but it works, and takes no extra work to port utilities and such...
257 2014-06-02 08:45:28 <michagogo> Right
258 2014-06-02 08:45:50 <michagogo> Basically what I use (except that I use an Ubuntu VM)
259 2014-06-02 08:47:48 <warren> vmbuilder is python
260 2014-06-02 08:49:41 <michagogo> Well, yeah
261 2014-06-02 08:49:50 <michagogo> The package's name is python-vm-builder :P
262 2014-06-02 08:50:25 <michagogo> I think it uses debootstrap, though
263 2014-06-02 08:50:32 <michagogo> I don't know what that's written in
264 2014-06-02 08:53:06 <wumpus> those linux-specific tools are used to extract the partition for LXC
265 2014-06-02 08:58:03 <michagogo> erm
266 2014-06-02 08:58:10 <michagogo> wumpus: I don't match hashes on the windows deps
267 2014-06-02 08:58:20 <wumpus> which makes sense, as LXC is linux specific in the first place
268 2014-06-02 08:58:22 <michagogo> and a3e5a62fcdad81f758e41848035e6a27be390981a14d590f2cf2509f87417a42  bitcoin-deps-win64-gitian-r12.zip
269 2014-06-02 08:58:22 <michagogo> I have acd59690a49dfbad6b436379843fe4ad1857ad91c603d52506690bc55f2a01a4  bitcoin-deps-win32-gitian-r12.zip
270 2014-06-02 08:58:32 <michagogo> Oh, wait a second
271 2014-06-02 08:59:13 <michagogo> The win deps version got bumped from 11 to 12
272 2014-06-02 08:59:21 <michagogo> Without updating r-p.md
273 2014-06-02 08:59:40 <wumpus> ok - the files match mine
274 2014-06-02 09:00:09 <michagogo> looks like it was https://github.com/bitcoin/bitcoin/commit/25d4911e8672a740e89d30c26373099e60242db8#diff-e583cf69ba561d0ad5169409d2c8a091R16
275 2014-06-02 09:00:45 <wumpus> ok
276 2014-06-02 09:00:57 <wumpus> going to add a commit to #4270 for that
277 2014-06-02 09:01:40 <michagogo> Maybe retitle it
278 2014-06-02 09:01:49 <wumpus> no
279 2014-06-02 09:02:07 <wumpus> really not important enough for that
280 2014-06-02 09:02:29 <michagogo> Can PR titles not be edited?
281 2014-06-02 09:03:06 <wumpus> sure they can, but I don't want to change the discussion in the PR, the actual problem that we have now is non-matching linux output
282 2014-06-02 09:03:58 <michagogo> But if you're sticking in something unrelated in the same PR...
283 2014-06-02 09:04:10 <wumpus> who cares it's just a doc update
284 2014-06-02 09:04:49 <michagogo> I want to go through release-process.md and clean it up a bit anyway
285 2014-06-02 09:05:13 <michagogo> A bunch of stuff was messed up in the os x merge, indents and stuff
286 2014-06-02 09:05:20 <michagogo> I'll just put the new hash in there
287 2014-06-02 09:05:25 <michagogo> 
ACTION updates his fork

288 2014-06-02 09:05:28 <warren> sorry, did I miss a call for gitian sigs?
289 2014-06-02 09:05:36 <wumpus> michagogo: already pushed it to the PR
290 2014-06-02 09:05:53 <wumpus> warren: 0.9.2rc1 was tagged
291 2014-06-02 09:06:05 <warren> need more?
292 2014-06-02 09:06:15 <wumpus> is usual, it's really painful
293 2014-06-02 09:06:18 <wumpus> as*
294 2014-06-02 09:06:26 <wumpus> warren: always!
295 2014-06-02 09:06:58 <michagogo> My PR should be off of master, right?
296 2014-06-02 09:07:57 <wumpus> yes
297 2014-06-02 09:10:01 <warren> "I've managed to reproduce @gavinandresen 's gitian build by adding the libqt4-dev package to the gitian-linux.yml"
298 2014-06-02 09:10:13 <warren> wumpus: this is the same reason why cory insisted on a clean VM for the mac build
299 2014-06-02 09:10:24 <michagogo> warren: yep...
300 2014-06-02 09:10:55 <wumpus> warren: yes, non-clean VMs make our work a lot harder
301 2014-06-02 09:11:10 <warren> hmm, my x86_64 is nonclean
302 2014-06-02 09:11:14 <warren> I made i386 clean just for mac
303 2014-06-02 09:12:11 <wumpus> well you could just uninstall the libqt4-dev package from the vm (and possible other packages that come with it...)
304 2014-06-02 09:12:50 <wumpus> no idea if there are seperate dev packages for all the  qt components, but they'd all have to be removed
305 2014-06-02 09:42:38 <michagogo> Gah, I think I may have a bad shell extension
306 2014-06-02 09:42:49 <michagogo> Right-clicking files is freezing Explorer :-/
307 2014-06-02 09:43:43 <gdm85> michagogo: you are trying to build in an LXC container?
308 2014-06-02 09:43:58 <michagogo> gdm85: I am building in LXC, yes
309 2014-06-02 09:44:21 <gdm85> michagogo: I gave this a try too. which version are you building?
310 2014-06-02 09:44:35 <michagogo> Working on v0.9.2rc1 atm. Why?
311 2014-06-02 09:44:59 <gdm85> michagogo: I am hitting 0.9.1. just curious. do you get matching signatures with other 0.9.2rc1?
312 2014-06-02 09:45:27 <michagogo> gdm85: Still working on Win and OS X, but I matched Linux with wumpus
313 2014-06-02 09:46:05 <gdm85> I agree with wumpus about using as much as possible deterministic compilers..
314 2014-06-02 09:46:12 <michagogo> Eh?
315 2014-06-02 09:47:28 <gdm85> michagogo: a while ago he said "we reallly need a consistentVM that can be used on every OS, and behaves on every OS in the same way"
316 2014-06-02 09:47:38 <gdm85> that would be nice
317 2014-06-02 09:48:17 <michagogo> Ah, yes
318 2014-06-02 09:48:27 <michagogo> We already use deterministic compilers :P
319 2014-06-02 09:48:35 <gdm85> btw, check out https://github.com/gdm85/tenku/tree/master/docker/gitian-host and the issue at gitian-builder: https://github.com/devrandom/gitian-builder/issues/53
320 2014-06-02 09:48:55 <gdm85> I managed to make this build environment through a privileged docker container
321 2014-06-02 09:49:30 <gdm85> I didn't get (all) matching signatures at first try, but I will make a second attempt
322 2014-06-02 09:54:22 <michagogo> Does the OS X build just output the single .dmg?
323 2014-06-02 09:54:39 <gdm85> unfortunately I am targeting only Linux, can't say
324 2014-06-02 09:55:18 <gdm85> good to know we use deterministic compilers, I was scared a bit by the paper about DDC
325 2014-06-02 09:55:24 <gdm85> 
ACTION http://www.dwheeler.com/trusting-trust/

326 2014-06-02 10:32:03 <rebroad> Is anything like darksend going to be added to bitcoin anytime soon? Somehow I think this is something needed if we're to address the darkcoin hype (their implementation actually doesn't even work, from what I've read)
327 2014-06-02 10:44:27 <michagogo> wumpus: Hm, should we also zip up or rename the dmg?
328 2014-06-02 10:45:04 <michagogo> It's kinda weird that the output of the gbuilds is bitcoin-${VERSION}-linux-gitian.zip, bitcoin-${VERSION}-win-gitian.zip, and Bitcoin-Qt.dmg
329 2014-06-02 10:46:27 <wumpus> rebroad: I doubt it will land in bitcoin core's wallet any time soon, not much active development happening there, but for example Amir's darkwallet already has it
330 2014-06-02 10:46:49 <buZz> darksend = coinjoin , right?
331 2014-06-02 10:46:56 <michagogo> Okay, I have win deps built and osx natives built
332 2014-06-02 10:46:59 <wumpus> yes
333 2014-06-02 10:47:02 <buZz> alright :)
334 2014-06-02 10:47:10 <michagogo> I g2g for now, though
335 2014-06-02 10:47:18 <rebroad> is darkwallet or coinjoin something that could be incorporated into bitcoin-qt?
336 2014-06-02 10:47:20 <buZz> all these 'dark....' names are way too confusing
337 2014-06-02 10:47:29 <michagogo> (all the various win intermediates, I mean)
338 2014-06-02 10:47:45 <wumpus> rebroad: as I've said before: if the implementation makes sense, sure
339 2014-06-02 10:47:46 <buZz> darkwallet replaces bitcoin-qt
340 2014-06-02 10:48:17 <wumpus> rebroad: darkcoin's implementation is not even open source at this point so who is to say
341 2014-06-02 10:48:23 <michagogo> Oh, also: Do we have the OS X intermediates deterministic yet?
342 2014-06-02 10:48:26 <wumpus> rebroad: I'd suggest just using a different wallet that does implement it though
343 2014-06-02 10:48:30 <michagogo> I have 512bc0622c883e2e0f4cbc3fedfd8c2402d06c004ce6fb32303cc2a6f405b6df  osx-native-depends-r3.tar.gz
344 2014-06-02 10:48:33 <rebroad> darkcoin is on github isn't it?
345 2014-06-02 10:49:00 <buZz> darkwallet has nothing to do with darkcoin
346 2014-06-02 10:50:10 <Apocalyptic> anyway all this darkcoin talk is off-topic
347 2014-06-02 10:51:19 <buZz> darkwallet is a bitcoin wallet
348 2014-06-02 10:51:29 <michagogo> https://github.com/bitcoin/bitcoin/pull/4271
349 2014-06-02 10:51:39 <michagogo> bbl
350 2014-06-02 10:52:08 <buZz> and has an opensource coinjoin implementation
351 2014-06-02 10:54:48 <wumpus> right
352 2014-06-02 13:17:11 <wumpus> warren: btw, had any luck yet debugging the setgenerate issue?
353 2014-06-02 13:21:44 <hearn> hi there
354 2014-06-02 13:23:56 <wumpus> hello
355 2014-06-02 13:51:59 <gavinandresen> michagogo: I bet it won't....
356 2014-06-02 13:53:07 <michagogo> gavinandresen: hm?
357 2014-06-02 13:53:25 <michagogo> Oh
358 2014-06-02 14:02:42 <wumpus> gavinandresen: btw, if you uninstall libqt4-dev from your gitian vm, you should get the same linux output as the rest (see https://github.com/bitcoin/bitcoin/pull/4270 - it picks the wrong qt headers)
359 2014-06-02 14:03:39 <gavinandresen> wumpus: ok, will do.
360 2014-06-02 14:03:57 <gavinandresen> I need to do that for both the i386 and amd64 vms?
361 2014-06-02 14:04:42 <wumpus> gavinandresen: yes, the problem exist on both
362 2014-06-02 14:04:57 <AndyOfiesh> I tested a couple multi sig p2sh txs with 3 of 5 and 5 of 5 on main net (total value under $20), the network didn't like it when I tried to spend the TxOuts. Had no problem with 2 of 3 and 3 of 4. Are these to big to be standard?
363 2014-06-02 14:05:24 <michagogo> gavinandresen: you bet what won't?
364 2014-06-02 14:06:00 <gavinandresen> michagogo: I bet the non-deterministic intermediate qt output won't affect the final binaries (and it doesn't)
365 2014-06-02 14:06:04 <michagogo> Ah
366 2014-06-02 14:06:07 <AndyOfiesh> Luke-Jr can you help me mine the spend of these two tx-outs
367 2014-06-02 14:06:20 <michagogo> Yeah, turns out it's just a build date stamp
368 2014-06-02 14:06:54 <gavinandresen> I hate Mondays… having hardware trouble with this machine....
369 2014-06-02 14:07:01 <michagogo> gavinandresen: how come you don't use clean VMs, btw?
370 2014-06-02 14:07:05 <wumpus> AndyOfiesh: that's strange, P2SH should be able to handle much larger M-of-N transactions
371 2014-06-02 14:07:31 <AndyOfiesh> That's good to know, I can start looking at other reasons why it wasn't accepted
372 2014-06-02 14:07:51 <AndyOfiesh> I was under that impression as well, or I wouldn't have risked any real btc on a test.
373 2014-06-02 14:07:53 <gavinandresen> michagogo: because building is much faster when the VMs don't have to download and install all dependencies every time
374 2014-06-02 14:09:05 <michagogo> gavinandresen: download? Isn't it cached?
375 2014-06-02 14:09:21 <wumpus> AndyOfiesh:  15-of-15 (1650 bytes txin) is max
376 2014-06-02 14:09:57 <wumpus> michagogo: it's cached; unfortunately, the installation is the slow part
377 2014-06-02 14:10:01 <dabura667> Anyone familiar with pre-p2kh? Out of curiosity, when they needed to do <pubkey> OP_CHECKSIG... how did they know the pubkey? Were bitcoin addresses different back then?
378 2014-06-02 14:10:29 <gavinandresen> michagogo: if you run apt-cacher-ng, which I'm not because I'm VirtualBox on OSX.  Although latest way of doing VirtualBox builds might cache the right stuff and I'm just stuck in the way I first did it
379 2014-06-02 14:11:22 <gavinandresen> dabura667: there were no bitcoin addresses back then, you would put in the IP address of the person you wanted to pay and a direct connection was made
380 2014-06-02 14:11:40 <gavinandresen> (if they didn't happen to be online at the time then you were out of luck)
381 2014-06-02 14:12:37 <dabura667> gavinandresen: thanks for the answer. I am writing some stuff on the history of Bitcoin in Japanese. This will help a lot. Did people usually meet up on IRC to send to each other?
382 2014-06-02 14:12:59 <gavinandresen> dabura667: I don't know, that was all before my time.
383 2014-06-02 14:13:03 <wumpus> right, there was a little protocol to negotiate the transaction directly over IP, it was removed at some point as it was very vulnerable to MITM attacks
384 2014-06-02 14:13:31 <dabura667> awesome. Thanks so much.
385 2014-06-02 14:13:57 <wumpus> the payment protocol could be seen as a better, more secure version of it
386 2014-06-02 14:14:52 <wumpus> (with the payment protocol you also don't really need addresses, the payment message could contain a pay-to-pubkey transaction)
387 2014-06-02 14:15:37 <dabura667> hmmm, interesting.
388 2014-06-02 14:34:04 <hearn> dabura667: mostly email
389 2014-06-02 14:34:13 <hearn> dabura667: not sure irc was used much in the very early days
390 2014-06-02 14:55:18 <michagogo> Hm, did pay-to-IP work in the opposite direction?
391 2014-06-02 14:55:40 <michagogo> (Connect to someone to request payment)
392 2014-06-02 14:59:23 <coryfields> wumpus: around?
393 2014-06-02 14:59:30 <coryfields> i'm trying to make sense of the linux/qt build issue
394 2014-06-02 15:00:27 <coryfields> wumpus: i don't see how that could happen unless gitian environments have been mixed
395 2014-06-02 15:00:51 <michagogo> coryfields: Gavin installed a whole bunch of packages in his base vm
396 2014-06-02 15:01:15 <michagogo> (Since he doesn't have apt-cacher)
397 2014-06-02 15:01:25 <coryfields> well, did someone properly smack him? :)
398 2014-06-02 15:01:55 <michagogo> coryfields: I don't know about smack
399 2014-06-02 15:02:12 <gavinandresen> Being able to say "Please don't pay attention to that package over there behind the curtain" … should be a required feature for any sane build system
400 2014-06-02 15:02:24 <coryfields> gavinandresen: sure, but gitian is not a build system
401 2014-06-02 15:02:27 <michagogo> Should be, yes.
402 2014-06-02 15:02:29 <coryfields> nor is it sane.
403 2014-06-02 15:02:38 <gavinandresen> okey dokey.
404 2014-06-02 15:03:09 <gavinandresen> I'm just saying what I done did SHOULD work in a theoretically perfect world
405 2014-06-02 15:03:11 <coryfields> gavinandresen: to be more useful: gitian has a very specific purpose, and that is to spit out byte-exact builds
406 2014-06-02 15:03:14 <sipa> michagogo: no, you connected to request a paymentrequest :)
407 2014-06-02 15:03:15 <michagogo> I mean, with gitian, isn't having a clean, identical environment kinda the whole point?
408 2014-06-02 15:03:27 <coryfields> treating it as a build-system to automate things is a really really bad idea
409 2014-06-02 15:03:29 <michagogo> sipa: that's what I thought.
410 2014-06-02 15:03:49 <gavinandresen> coryfields: I thought the issue is that ./configure is not paying attention to where to search for qt headers
411 2014-06-02 15:04:00 <gavinandresen> (or make or qmake or something)
412 2014-06-02 15:04:31 <michagogo> sipa: ...which means, I assume, that it was impossible to receive funds without being reachable from tbe internet?
413 2014-06-02 15:04:38 <sipa> michagogo: correct
414 2014-06-02 15:04:41 <coryfields> gavinandresen: when there are 2 sets of headers, there's no real correct answer for "which one to use"
415 2014-06-02 15:04:45 <michagogo> Wtf? It autocorrected to "tbe"?
416 2014-06-02 15:05:15 <coryfields> gavinandresen: i'll look over the specifics. And it's possible that they could be made to coexist. But I maintain that it's a bad idea to assume anything other than a clean base for building
417 2014-06-02 15:05:16 <gavinandresen> coryfields: the correct answer should be "the one I tell you to use" -- if gitian ./configure doesn't do that, then it is a bug in the gitian configure script in my opinion
418 2014-06-02 15:05:17 <michagogo> I typed "the" and then a slight misspelling of internet
419 2014-06-02 15:05:28 <coryfields> 'cause you never know what could end up affecting it
420 2014-06-02 15:05:36 <michagogo> gavinandresen: well, it's not the gitian configure script
421 2014-06-02 15:05:48 <michagogo> It's just our configure script, running in gitian
422 2014-06-02 15:06:06 <michagogo> ...and it autocorrected to "tbe internet"
423 2014-06-02 15:06:07 <gavinandresen> please don't be pedantic, it is monday and I am grumpy.
424 2014-06-02 15:06:18 <michagogo> gavinandresen: no, there's a difference
425 2014-06-02 15:06:23 <michagogo> The problem isn't with gitian
426 2014-06-02 15:06:27 <coryfields> gavinandresen: sure, we can do that with configure. See the --with-qt-* options. But those aren't set in the gitian scripts because it was assumed to be a predefined environment
427 2014-06-02 15:06:27 <gavinandresen> fine
428 2014-06-02 15:06:28 <michagogo> It's with our build system
429 2014-06-02 15:06:30 <gavinandresen> our use of gitian
430 2014-06-02 15:07:12 <coryfields> which imo is a fair assumption for gitian. If that can't be assumed, then many other changes are needed as well.
431 2014-06-02 15:07:17 <michagogo> Oh, I see
432 2014-06-02 15:07:34 <gavinandresen> coryfields: I'd argue assuming that is the bug.  Make everything explicit, because you never know what will affect deterministic output
433 2014-06-02 15:08:20 <coryfields> gavinandresen: i strongly disagree. We know exactly what will affect deterministic output, which is why we set those specific inputs and only those specific inputs
434 2014-06-02 15:08:36 <coryfields> if you throw another random system package in there, all bets are off
435 2014-06-02 15:08:45 <michagogo> gavinandresen: I think the idea is, usually auto detection is fine. If you need a specific one, specify it. We don't do that in gitian because gitian is a clean VM
436 2014-06-02 15:08:49 <gavinandresen> coryfields: ok, I yield, you're the expert
437 2014-06-02 15:08:55 <michagogo> A gitian VM, I mean
438 2014-06-02 15:09:29 <michagogo> Once you use a VM that's not as-is from make-base-vm, you're arguably not exactly using gitian
439 2014-06-02 15:09:36 <sipa> well i do agree philosophically with coryfields here: if we're going to deal with indeterminsm inside gitian, why do we have it? the whole purpose of it is to have a known environment to build in, so we can rely on it
440 2014-06-02 15:09:53 <michagogo> sipa: +1
441 2014-06-02 15:10:02 <coryfields> right
442 2014-06-02 15:10:06 <coryfields> however
443 2014-06-02 15:10:17 <michagogo> (I think wumpus and I were saying just about that earlier)
444 2014-06-02 15:10:28 <gavinandresen> mmm.  I predict when we move from precise to new VMs we'll wish we had explictly set paths to qt and compilers and etc.....
445 2014-06-02 15:10:30 <coryfields> it could be a reasonable compromise to allow for known things to be installed simultaneously
446 2014-06-02 15:10:42 <coryfields> for example, linux+osx could be built to knowingly not conflict with eachother
447 2014-06-02 15:10:49 <sipa> fair enough
448 2014-06-02 15:11:21 <gavinandresen> … because then things will break early and we'll realize "oh, /usr/bin/g++ in Zany Zebra is actually not the compiler we want…"  (or whatever)
449 2014-06-02 15:11:58 <wumpus> coryfields: I do set the --with-qt option, I even override the pkgconfig path, but still it chooses the system's qt library instead of the one we build ourselves
450 2014-06-02 15:12:30 <coryfields> wumpus: if that's a case, that's a legitimate bug then. will have a look.
451 2014-06-02 15:12:32 <wumpus> coryfields: see my post here: https://github.com/bitcoin/bitcoin/pull/4270
452 2014-06-02 15:13:21 <sipa> wumpus: oh, thanks for clearing that up
453 2014-06-02 15:14:58 <wumpus> for now it's fine to just say 'uninstall the libqt4-dev', but that was meant as a workaround
454 2014-06-02 15:15:35 <coryfields> wumpus: is any of this holding up the current release? (I'm still catching up on backlog from this weekend)
455 2014-06-02 15:15:41 <wumpus> no, it's not
456 2014-06-02 15:15:48 <coryfields> ok
457 2014-06-02 15:15:55 <wumpus> we have a workaround
458 2014-06-02 15:17:22 <coryfields> wumpus: to repro, all i need to do is add in the libqt4-dev dependency, then?
459 2014-06-02 15:18:01 <wumpus> coryfields: yes
460 2014-06-02 15:20:10 <coryfields> wumpus: everything else went ok with building? osx was fine?
461 2014-06-02 15:21:13 <coryfields> i wish i wouldn'tve been dragged to a long, boring wedding instead of enjoying the build fun :\
462 2014-06-02 15:21:22 <gavinandresen> coryfields: I'm going to try code-signing and uploading osx now
463 2014-06-02 15:21:26 <wumpus> coryfields: build worked fine, gavin and I had a different dmg though, but the intermediates look the same
464 2014-06-02 15:21:36 <sipa> why codesign before final release?
465 2014-06-02 15:21:47 <gavinandresen> sipa: to make sure the process works
466 2014-06-02 15:21:52 <sipa> ok!
467 2014-06-02 15:22:20 <coryfields> gavinandresen: you mean the regular codesign process for rc1? or the detached deterministic stuff?
468 2014-06-02 15:22:30 <gavinandresen> coryfields: detached deterministic stuff
469 2014-06-02 15:22:40 <coryfields> ok
470 2014-06-02 15:23:07 <coryfields> have you verified that the other still works ok? I realize now that we never actually tested that either
471 2014-06-02 15:23:49 <gavinandresen> nope, but I can't imagine it would break-- codesigning a .dmg is codesigning a .dmg.....
472 2014-06-02 15:23:58 <gavinandresen> err, a .app ...
473 2014-06-02 15:24:32 <coryfields> gavinandresen: i suppose the reason i'm nervous is that 10.9 seemed to have dropped a bunch of back-compat stuff that just worked before, even if it wasn't technically supposed to
474 2014-06-02 15:24:41 <coryfields> you use 10.6 or so for signing though, i guess?
475 2014-06-02 15:25:40 <gavinandresen> coryfields: let me remember… I believe I'd build on a 10.6 machine against the 10.5 SDK. Then copy the .dmg to my 10.8 machine, unpack the dmg, sign the .app, then repack the .dmg which was then released.
476 2014-06-02 15:26:30 <coryfields> ok. i suppose we'll cross the bridges as we come to 'em. Maybe 10.8 plays nicer.
477 2014-06-02 15:26:56 <gavinandresen> … beacuse I think GateKeeper didn't like it if I signed on 10.6, and I couldn't build 32-bit on 10.8 with the 10.5 SDK.  But I may be mis-remembering.
478 2014-06-02 15:27:26 <coryfields> no, that sounds about right.
479 2014-06-02 15:31:30 <coryfields> wumpus: erm, I'm quite confused about the qt linux build
480 2014-06-02 15:31:47 <coryfields> i guess i missed that discussion. Got a few min to discuss/clue me in?
481 2014-06-02 15:37:06 <dsnrk> coryfields: you're in luck too, 10.10 is dropping in a few hours to screw things up even more :)
482 2014-06-02 15:38:30 <coryfields> heh
483 2014-06-02 15:39:40 <wumpus> coryfields: we build against the headers of qt 4.6, for backward compatibility with older distributions
484 2014-06-02 15:39:47 <gavinandresen> coryfields: there's a bash quoting bug in detached-sig-create.sh
485 2014-06-02 15:39:58 <gavinandresen> coryfields: "Developer: no identity found
486 2014-06-02 15:40:08 <wumpus> coryfields: precise has qt 4.8 headers by default, which are too new
487 2014-06-02 15:40:35 <wumpus> coryfields: also we build the 4.6 developer tools (moc, uic) to go with it
488 2014-06-02 15:40:41 <gavinandresen> ls
489 2014-06-02 15:42:17 <wumpus> coryfields: anyhow, it works great as long as the libqt4-dev package is not installed
490 2014-06-02 15:43:11 <coryfields> gavinandresen: right. i can fix up and ping you if you'd rather not dive in there
491 2014-06-02 15:43:51 <gavinandresen> coryfields: mmm, my first attempt at a fix ( "${CODESIGNARGS}" )  doesn't work, and I don't remember the bash syntax for making it work
492 2014-06-02 15:43:53 <coryfields> wumpus: that sounds quite painful. What's the benefit over just using all of our self-built qt?
493 2014-06-02 15:44:25 <coryfields> gavinandresen: ok, will take a crack at it
494 2014-06-02 15:44:36 <coryfields> gavinandresen: fwiw, i tested using: CODESIGNARGS="-s Cory"
495 2014-06-02 15:44:49 <coryfields> gavinandresen: possible you don't need that 2nd argument?
496 2014-06-02 15:45:12 <coryfields> (just for now, of course)
497 2014-06-02 15:45:13 <wumpus> coryfields: we want to use the system's qt, because that integrates into the window environment etc
498 2014-06-02 15:45:14 <gavinandresen> coryfields: the identity name has spaces in it
499 2014-06-02 15:45:22 <gavinandresen> my CODESIGNARGS is:   --keychain /Users/gavin/Library/Keychains/CodeSigning.keychain --sign "Developer ID Application: BITCOIN FOUNDATION, INC., THE"
500 2014-06-02 15:45:51 <wumpus> coryfields: building a static qt as for windows would be a nightmare on linux, you're stuck with all kinds of X development dependencies
501 2014-06-02 15:45:55 <coryfields> oh, that is your -s. ok. I was thinking it was the number of args that messed it up.
502 2014-06-02 15:46:31 <coryfields> wumpus: hmm, ok
503 2014-06-02 15:46:37 <wumpus> we just don't want that
504 2014-06-02 15:48:21 <coryfields> wumpus: well in this case, i'm not sure what we can do with the bitcoin build-system. It's likely detecting that there are headers but the libs are missing, so it skips and detects the working pair
505 2014-06-02 15:48:59 <coryfields> i suppose you could say "let me shoot myself in the foot", which is reasonable i guess. Will think on it.
506 2014-06-02 15:49:02 <wumpus> coryfields: well even the libs are there, they are symbolic-linked
507 2014-06-02 15:49:16 <wumpus> coryfields: and they are specified in the .pc file
508 2014-06-02 15:49:54 <wumpus> coryfields: I'm not sure it should be trying to do anything smart apart from just following what is in the pkgconfig files
509 2014-06-02 15:51:02 <wumpus> and the pkgconfig files in PKG_CONFIG_PATH take precedence over the system ones right?
510 2014-06-02 15:51:03 <coryfields> fair enough. Ok, I won't speculate anymore. I understand the issue. I'll update the PR when I can nail down why it's not doing ^^
511 2014-06-02 15:51:31 <coryfields> correct
512 2014-06-02 16:44:04 <gdm85> wumpus: I am tracking down an issue related to possibly similar causes, trying to make deterministic builds in LXC containers
513 2014-06-02 16:44:25 <gdm85> and another one related to order of files in the tar archive
514 2014-06-02 16:54:14 <coryfields> gavinandresen: https://github.com/theuni/bitcoin/commit/45a663450a1a88af25e50b7de9a28aafc2858a68
515 2014-06-02 16:54:31 <coryfields> gdm85: notice the way we tar for osx
516 2014-06-02 16:55:07 <coryfields> gdm85: https://github.com/bitcoin/bitcoin/blob/master/contrib/gitian-descriptors/gitian-osx-native.yml#L177
517 2014-06-02 16:55:15 <coryfields> that fixes random file orders
518 2014-06-02 17:12:05 <gavinandresen> coryfields: send you email RE: detached-sig-create
519 2014-06-02 17:13:03 <coryfields> gavinandresen: damn, that looks like the one i was worried about
520 2014-06-02 17:13:27 <coryfields> 10.9 wants each version signed. before, it wanted the whole framework signed
521 2014-06-02 17:13:55 <gavinandresen> Ah. So signing might work if I was running 10.9?
522 2014-06-02 17:14:01 <gavinandresen> I think I have a 10.9 VM I can fire up....
523 2014-06-02 17:14:06 <coryfields> oh wait, did you use a gitian output rather than the one i sent you?
524 2014-06-02 17:14:12 <gavinandresen> yes, I used gitian output.
525 2014-06-02 17:14:54 <coryfields> that's missing the packaging changes for codesigning
526 2014-06-02 17:15:18 <coryfields> https://github.com/theuni/bitcoin/commit/953fbf3b486fadb83db243612d71626b16c779db <-- that one
527 2014-06-02 17:15:26 <gavinandresen> … so for 0.9.2 we'll use the old way of codesigning?
528 2014-06-02 17:16:09 <coryfields> yea, i didn't think there was any hope of having this ready without blocking 0.9.2 for too long, figured we'd do it for the next
529 2014-06-02 17:16:22 <gavinandresen> ok
530 2014-06-02 17:16:24 <coryfields> sorry if i wasn't clear on that
531 2014-06-02 19:10:20 <coryfields> wumpus: where are you seeing that it picked up the system headers before ours?