1 2012-06-29 02:17:21 <doublec> with latest git my debug log tends to fill up with "socket send buffer full warning". What's that log for?
  2 2012-06-29 02:25:01 <gribble> New news from bitcoinrss: jgarzik opened pull request 1531 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1531>
  3 2012-06-29 05:10:51 <maaku> i think gitian-descriptors/deps-win32.yml is broken
  4 2012-06-29 05:11:22 <maaku> or rather the miniupnpc build process is; it's not setup for cross-compilation
  5 2012-06-29 05:12:37 <maaku> it builds an .exe, wingenminiupnpcstrings, then tries to execute it, which doesn't work in the gitian build environment
  6 2012-06-29 05:12:43 <maaku> anyone know how to get around this?
  7 2012-06-29 07:34:25 <gribble> New news from bitcoinrss: fanquake opened pull request 1532 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1532>
  8 2012-06-29 09:20:11 <Geebus> anyone know how I can get the pubkey of the sender from an unconfirmed transaction fairly easily?
  9 2012-06-29 09:26:40 <tcatm> Geebus: It's in the scriptsig
 10 2012-06-29 09:27:06 <Geebus> tcatm: is there a format for the scriptsig public anywhere?
 11 2012-06-29 09:28:41 <tcatm> Depends on the transaction. https://en.bitcoin.it/wiki/Script
 12 2012-06-29 09:29:32 <sipa> Geebus: bitcoin transactions do not have a well-defined "sender"
 13 2012-06-29 09:30:02 <sipa> they have one or more inputs, each of which may or may not have a recognisable pubkey/address it was previously sent to
 14 2012-06-29 09:30:28 <Geebus> I'm trying to find a fairly simple way to determine all of the inpoints for a transaction that has yet to be confirmed.
 15 2012-06-29 09:31:19 <sipa> what for? :)
 16 2012-06-29 09:31:25 <Geebus> A sends to B, where A may be multiple addresses... I need to be able to determine all of A.
 17 2012-06-29 09:31:45 <tcatm> You could probably do that by looking at prev_out
 18 2012-06-29 09:31:56 <sipa> prevout tells you txid:n
 19 2012-06-29 09:32:25 <sipa> you can look those up in the transaction database (of a full node) to find what txout corresponds to that
 20 2012-06-29 09:32:40 <sipa> but you'll get a script, not a pubkey or an address
 21 2012-06-29 09:33:02 <sipa> if it was a send-to-address, you can find the address in the prev txout, and the pubkey in the txin
 22 2012-06-29 09:33:20 <sipa> if it was a send-to-pubkey, you can find the pubkey in the prev txout, and the address as the hash of it
 23 2012-06-29 09:33:42 <sipa> if it was a send-to-script, you can find the pubkey(s) in the prev txout
 24 2012-06-29 09:33:57 <sipa> sorry, in the txin
 25 2012-06-29 09:34:33 <Geebus> Still viable to find them on a TX not yet in the blockchain?
 26 2012-06-29 09:35:58 <sipa> if the input isn't confirmed yet, you'll need to look in the mempool as well
 27 2012-06-29 09:38:43 <Geebus> I was looking at the mempool earlier, but can't find a reference on the byte structure or format of the transactions in it. My forum and Wiki-fu skills are lacking, apparently.
 28 2012-06-29 09:42:36 <Geebus> Is there a reference available anywhere? I would prefer not to have to dig through source code.
 29 2012-06-29 09:42:47 <epscy> error: {"code":-4,"message":"Error: Transaction creation failed  "}
 30 2012-06-29 09:42:58 <epscy> i can't send :(
 31 2012-06-29 09:43:22 <epscy> 0.6.3
 32 2012-06-29 09:43:31 <epscy> ubuntu
 33 2012-06-29 09:44:13 <Geebus> epscy: the transaction amount + fee exceeds your wallet balance
 34 2012-06-29 09:44:45 <Geebus> epscy: likely, you have a ton of small amounts received into your wallet that are complicating the transaction to cause enormous fees
 35 2012-06-29 09:44:59 <epscy> hmmm
 36 2012-06-29 09:45:00 <epscy> ok
 37 2012-06-29 09:45:14 <Geebus> epscy: currently, there is no way to spend those coins.
 38 2012-06-29 09:46:26 <Geebus> epscy: I had a similar situation with 0.00002068 BTC comprised of a little over 1000 micro amount sources requiring a fee of over 1000.0 BTC to send.
 39 2012-06-29 09:46:41 <epscy> Geebus: wouldn't using an older client work?
 40 2012-06-29 09:46:56 <epscy> or waiting for the txes to mature?
 41 2012-06-29 09:47:08 <sipa> over 1000 BTC seems very unlikely
 42 2012-06-29 09:47:32 <Geebus> sipa: unlikely, unreasonable, but entirely valid.
 43 2012-06-29 09:47:39 <Geebus> epscy: I don'
 44 2012-06-29 09:47:42 <sipa> gmaxwell did some calculations on the maximum fee the client ever requests
 45 2012-06-29 09:47:51 <sipa> s/requests/enforces/
 46 2012-06-29 09:47:57 <Geebus> t know about the maturity, but an older client might work.
 47 2012-06-29 09:48:34 <sipa> mandatory fees were introduced in 0.3.20 iirc, and since them they've only been decreased
 48 2012-06-29 09:49:00 <sipa> and such an old client won't be able to open your wallet file
 49 2012-06-29 09:49:11 <epscy> awesome
 50 2012-06-29 09:49:29 <Geebus> I'd have to get on my other box to take a screenshot, but my calculated fee was over 1k to send less than 1 cent.
 51 2012-06-29 09:49:46 <sipa> did you set the voluntary fee very high?
 52 2012-06-29 09:49:47 <epscy> Geebus: how can you check that?
 53 2012-06-29 09:49:55 <epscy> is there a command to do it?
 54 2012-06-29 09:50:07 <Geebus> sipa: I tried setting it to 10 BTC at one point and it still wouldn't work.
 55 2012-06-29 09:50:17 <sipa> ?
 56 2012-06-29 09:50:23 <Geebus> epscy: no, I had to modify the source.
 57 2012-06-29 09:50:38 <sipa> if you increase the voluntary fee, it will only send more obviously
 58 2012-06-29 09:51:11 <epscy> sipa: but over time i should be able to spend the coins right?
 59 2012-06-29 09:51:22 <sipa> the transaction will not become any less complex
 60 2012-06-29 09:51:34 <Geebus> Well, cause or calculation aside, currently, there is no way to spend those coins.
 61 2012-06-29 09:51:34 <sipa> so the fee won't change
 62 2012-06-29 09:51:46 <sipa> only the fact whether it requires a fee at all, or not
 63 2012-06-29 09:52:14 <sipa> but if you set the voluntary fee high, you'll pay high fees - especially for a complex transaction with many inputs
 64 2012-06-29 09:52:28 <Geebus> I tried setting low fees as well
 65 2012-06-29 09:52:49 <sipa> well, i don't believe it required a 1000 BTC fee when you set the voluntary fee to 0
 66 2012-06-29 09:53:03 <sipa> but yes, bitcoin is not intended to do micro transactions
 67 2012-06-29 09:54:05 <epscy> so i see
 68 2012-06-29 09:54:28 <Geebus> With a fixed amount of bitcoins possible to be generated, and billions of people on the planet, with even a small percentage of the population adopting it, micro transactions are the inevitable fate of Bitcoin.
 69 2012-06-29 09:55:02 <sipa> by micro-transactions i mean very small amounts of value; not very small amounts of bitcoin
 70 2012-06-29 09:55:32 <Geebus> txes in sizes of 0.00000001, for example.
 71 2012-06-29 09:55:33 <sipa> if bitcoin becomes more popular, and more used, and its value rises accordingly, the network will scale to adapt more usage
 72 2012-06-29 09:56:23 <Geebus> With it's current popularity, this is already an issue.
 73 2012-06-29 09:56:32 <sipa> but small transactions cost the bitcoin network (which is a very expensive beast, but maintained voluntarily by anyone who sees value in having such a system) the same amount as large transactions
 74 2012-06-29 09:56:56 <Geebus> I know of at least a few people with wallets that are essentially unusable due to this exact situation/error/cause
 75 2012-06-29 09:57:10 <epscy> so let's just be clear here, this isn't a limitation of the protocol
 76 2012-06-29 09:57:19 <epscy> this is the stock bitcoin client enforcing this?
 77 2012-06-29 09:57:22 <sipa> no, the protocol can deal with it
 78 2012-06-29 09:57:23 <sipa> yes
 79 2012-06-29 09:57:44 <sipa> Geebus: and why do they have such small amounts in the first place?
 80 2012-06-29 09:57:46 <sipa> satoshidice?
 81 2012-06-29 09:57:55 <Geebus> Possibly, sure.
 82 2012-06-29 09:58:04 <coiax> I'm confused, what stops a client combining gradually through multiple transactions, a number of smaller amounts into a single address?
 83 2012-06-29 09:58:26 <sipa> coiax: bitcoin does internally not reason in terms of addresses; those are just the authentication layer on top
 84 2012-06-29 09:58:28 <epscy> could i send my coins to myself?
 85 2012-06-29 09:58:31 <sipa> yes
 86 2012-06-29 09:58:32 <epscy> would that fix it?
 87 2012-06-29 09:58:34 <sipa> no
 88 2012-06-29 09:58:37 <Geebus> epscy: no
 89 2012-06-29 09:58:44 <epscy> why not?
 90 2012-06-29 09:58:55 <Geebus> Because it is still a complex transaction
 91 2012-06-29 09:59:01 <sipa> to the bitcoin network, a send-to-self is indistinguishable from another transaction
 92 2012-06-29 09:59:02 <Geebus> comprised of many inputs
 93 2012-06-29 09:59:28 <epscy> ok
 94 2012-06-29 10:00:05 <epscy> i assumed that sending all my coins to one address would make future transactions less complex
 95 2012-06-29 10:00:10 <sipa> yes
 96 2012-06-29 10:00:16 <sipa> it would
 97 2012-06-29 10:00:25 <epscy> so worth trying?
 98 2012-06-29 10:00:31 <sipa> but the transaction to combine them would be just as complex
 99 2012-06-29 10:00:34 <sipa> or even more
100 2012-06-29 10:00:48 <epscy> what's the worst that could happen?
101 2012-06-29 10:00:55 <sipa> the transaction doesn't config
102 2012-06-29 10:00:57 <sipa> confirm
103 2012-06-29 10:00:58 <Geebus> epscy: you lose a bunch of coins in tx fees
104 2012-06-29 10:01:38 <epscy> hmmm, this "you don't know what the tx fee will be until you send it" stuff is annoying
105 2012-06-29 10:02:06 <Geebus> epscy: in this case, you don't know the tx fee at all, because it determined that it is just too high to even bother telling you.
106 2012-06-29 10:06:46 <Geebus> sipa: thanks for the info earlier. I appreciate it.
107 2012-06-29 10:06:51 <Geebus> Off to sleep.
108 2012-06-29 10:20:29 <gribble> New news from bitcoinrss: mhredmond21 opened pull request 1533 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1533>
109 2012-06-29 12:43:59 <sipa> ;;bc,gen 10000
110 2012-06-29 12:44:00 <gribble> The expected generation output, at 10000 Khps, given current difficulty of 1726566.5591935 , is 0.0058255986439 BTC per day and 0.000242733276829 BTC per hour.
111 2012-06-29 12:49:11 <drizztbsd> lol? 10m
112 2012-06-29 12:51:21 <jgarzik> ;;bc,calc 10000
113 2012-06-29 12:51:22 <gribble> The average time to generate a block at 10000 Khps, given current difficulty of 1726566.5591935 , is 23 years, 26 weeks, 5 days, 19 hours, 24 minutes, and 50 seconds
114 2012-06-29 12:51:41 <jgarzik> ...but you never know, with a martingale bot you might get lucky!
115 2012-06-29 13:03:47 <jgarzik> ;;bc,calc 100000
116 2012-06-29 13:03:48 <gribble> The average time to generate a block at 100000 Khps, given current difficulty of 1726566.5591935 , is 2 years, 18 weeks, 2 days, 6 hours, 44 minutes, and 29 seconds
117 2012-06-29 13:04:01 <jgarzik> ;;bc,calc 1000
118 2012-06-29 13:04:02 <gribble> The average time to generate a block at 1000 Khps, given current difficulty of 1726566.5591935 , is 235 years, 7 weeks, 4 days, 2 hours, 8 minutes, and 26 seconds
119 2012-06-29 13:04:05 <jgarzik> heh
120 2012-06-29 13:04:14 <jgarzik> and for pyminer...
121 2012-06-29 13:04:18 <gribble> The average time to generate a block at 50 Khps, given current difficulty of 1726566.5591935 , is 4702 years, 47 weeks, 2 days, 18 hours, 48 minutes, and 42 seconds
122 2012-06-29 13:04:18 <jgarzik> ;;bc,calc 50
123 2012-06-29 13:04:56 <gmaxwell> meh, a few months on that is still better than most lotteries!
124 2012-06-29 13:05:58 <gavinandresen> what's the number for the BFL jalapeno gadget supposed to be?
125 2012-06-29 13:06:12 <Obsi> 3.5 ghash
126 2012-06-29 13:06:33 <gavinandresen> ;;bc,calc 3500000
127 2012-06-29 13:06:34 <gribble> The average time to generate a block at 3500000 Khps, given current difficulty of 1726566.5591935 , is 3 weeks, 3 days, 12 hours, 32 minutes, and 7 seconds
128 2012-06-29 13:14:41 <jgarzik> ;;bc,calc 40000000
129 2012-06-29 13:14:42 <gribble> The average time to generate a block at 40000000 Khps, given current difficulty of 1726566.5591935 , is 2 days, 3 hours, 29 minutes, and 48 seconds
130 2012-06-29 13:15:02 <jgarzik> (BFL SC Single)
131 2012-06-29 13:15:13 <Obsi> did you order any BFL hardware?
132 2012-06-29 13:15:58 <sipa> if they really get 3.5 GH/s for $150, the impact on the mining economy will be huge
133 2012-06-29 13:16:26 <Obsi> it will help spread it out that's for sure. I bought some for family & friends
134 2012-06-29 13:16:55 <epscy> Obsi: people keep saying that, but I am not so sure
135 2012-06-29 13:17:18 <epscy> I think any decentralization of mining that occurs will be shortlived
136 2012-06-29 13:17:41 <jgarzik> the difficulty will shoot up, then everything else will return to normal.
137 2012-06-29 13:17:57 <sipa> uhu
138 2012-06-29 13:18:17 <Obsi> they run off USB power so the draw will be negligible, plus everyone I know drinks coffee :)
139 2012-06-29 13:19:22 <sipa> where do you read that?
140 2012-06-29 13:20:07 <epscy> Obsi: yeah i am not totally convinced by the coffee warmer concept
141 2012-06-29 13:20:13 <jgarzik> In the short term, as long as BFL doesn't ship a huge percentage of chips to a single entity, things should be ok.  In the long term, ASIC competitors are inevitable.
142 2012-06-29 13:20:24 <jgarzik> even private ASIC competitors
143 2012-06-29 13:20:43 <epscy> so i have a cup of coffee
144 2012-06-29 13:20:54 <epscy> and it is plugged in to the wall?
145 2012-06-29 13:21:07 <epscy> or it has batteries which i need to replace periodically?
146 2012-06-29 13:21:09 <gavinandresen> no, it sits on top of the little USB-powered doohickey
147 2012-06-29 13:21:29 <gavinandresen> Actually, probably not USB powered, probably USB and separate plug....
148 2012-06-29 13:21:44 <epscy> gavinandresen: ahh, that does make more sense
149 2012-06-29 13:22:02 <jgarzik> As long as bitcoin is this tiny, it is "for sale" to anyone with a few million dollars to spare.
150 2012-06-29 13:22:07 <sipa> USB is limited to what what? 5W?
151 2012-06-29 13:22:14 <Graet> they claim usb3 will provide enough power
152 2012-06-29 13:22:17 <jgarzik> The community just needs to be vigilant about usage.
153 2012-06-29 13:22:20 <epscy> still think they will end up being equivalent to a cheap GPU today
154 2012-06-29 13:22:20 <sipa> if they managed to get 3.5 GH/s in 5W ...
155 2012-06-29 13:22:42 <jgarzik> If anyone disrupts bitcoin overmuch, the community will surely take action and route around that annoyance.
156 2012-06-29 13:22:47 <sipa> ah, USB3 goes to 9W
157 2012-06-29 13:22:55 <gavinandresen> 9W coffee warmer works
158 2012-06-29 13:29:16 <helo> so long as the chip doesn't mind a fresh cup of 90C coffee sitting on it
159 2012-06-29 13:30:03 <epscy> helo: yeah i would assume air is a better conductor of heat than a cup of coffee
160 2012-06-29 13:30:11 <epscy> but i assume they have thought of that
161 2012-06-29 13:30:33 <gmaxwell> Certantly it's possible to build things that don't mind; milspec for ICs goes up to 125c or so.
162 2012-06-29 13:39:17 <[Tycho]> Heh :)
163 2012-06-29 13:59:13 <gribble> New news from bitcoinrss: mhredmond21 opened issue 1534 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1534>
164 2012-06-29 14:27:09 <sturles> UB3 can only deliver 9W in charger mode with no data connection.  9W with data connection violates spec because ground will get pulled to high on the device.
165 2012-06-29 14:28:18 <sturles> It may work with a short cable, but still violates spec.
166 2012-06-29 14:28:59 <Diablo-D3> ub3? usb3?
167 2012-06-29 14:31:12 <luke-jr> sipa: Jalapeno on USB 2 requires another power source IIRC
168 2012-06-29 14:32:27 <sturles> Yes, USB3.
169 2012-06-29 14:33:28 <Diablo-D3> usb3 can do up to 900ma
170 2012-06-29 14:33:51 <Diablo-D3> both usb2 and 3 can do charger spec, but you have to short the data pins to enable it
171 2012-06-29 14:34:15 <Diablo-D3> sturles: 9 watts is too high though
172 2012-06-29 14:37:04 <Diablo-D3> sturles: oh wait a second
173 2012-06-29 14:37:09 <Diablo-D3> Im wrong
174 2012-06-29 14:37:23 <Diablo-D3> usb2 or 3 doing charger spec can do 1.5a WITHOUT shorting the pins
175 2012-06-29 14:37:38 <Diablo-D3> 5a while in charger mode
176 2012-06-29 14:40:01 <luke-jr> sturles: no, USB 3 works without another powr source :p
177 2012-06-29 14:40:23 <luke-jr> sturles: USB 2 requires a separate power source
178 2012-06-29 14:41:13 <luke-jr> in other news, crashing Bitcoin right at the start of CWallet::AddToWallet results in losing that transaction in your wallet and it not being picked up later&
179 2012-06-29 14:43:10 <sturles> Hmm.  I checked, and it seems they have solved the problem by specifying a minimum voltage of 4 in USB3 vs 4.4 in USB2.  So a USB3 device may pull 900mA (4.5W) without vilolating spec.
180 2012-06-29 14:44:23 <Diablo-D3> sturles: 900ma at 5v
181 2012-06-29 14:45:33 <luke-jr> -rescan helps ofc
182 2012-06-29 14:50:07 <gribble> New news from bitcoinrss: luke-jr opened issue 1535 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1535>
183 2012-06-29 15:11:04 <sturles> Diablo-D3: Which will be 4V at the device if the cable is maximum length according to spec.
184 2012-06-29 15:11:19 <sturles> Diablo-D3: Due to resistance in cable and connectors.
185 2012-06-29 17:17:30 <gribble> New news from bitcoinrss: coblee opened pull request 1536 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1536>
186 2012-06-29 17:43:14 <yellowhat> blockexplorer.com down apparently
187 2012-06-29 17:43:43 <yellowhat> and blockchain.info behind about 5 blocks
188 2012-06-29 17:43:57 <yellowhat> something is fishy?
189 2012-06-29 17:45:49 <andytoshi> i am reading the commits for this week, and see a lot of tor stuff
190 2012-06-29 17:45:59 <andytoshi> very cool -- thanks, sipa
191 2012-06-29 18:14:28 <sipa> andytoshi: :)
192 2012-06-29 19:22:47 <yexxxxx> hello is it possible to merge all the bitcoin in diferent addresses in just one in a wallet?
193 2012-06-29 19:24:31 <yexxxxx> i am accepting micropayments, so when i transfer all the bitcoins to my outside wallet the transaction size is too big
194 2012-06-29 19:24:37 <yexxxxx> so it has a very high fee
195 2012-06-29 19:24:49 <yexxxxx> is it possible?
196 2012-06-29 19:25:02 <sipa> you can send them to an address of your own
197 2012-06-29 19:25:28 <sipa> but that will still require you to create a transaction that combines all those coins
198 2012-06-29 19:25:45 <yexxxxx> i've just did a test
199 2012-06-29 19:25:51 <yexxxxx> doing that
200 2012-06-29 19:25:56 <yexxxxx> http://blockchain.info/tx-index/10898413/5229002d5d88fa78e6d5245784a68fc204d70708c6d2b20a4542510be79de6c2
201 2012-06-29 19:26:21 <yexxxxx> i have thousands of addresses with very little amount of bitcoins
202 2012-06-29 19:26:28 <yexxxxx> is there a solution?
203 2012-06-29 19:27:29 <sipa> not accepting such small amounts in the first place; bitcoin is not intended for microtransactions
204 2012-06-29 19:28:13 <sipa> you can try to find a miner which wants to mine them for a possible lower fee, and send the transactions directly there
205 2012-06-29 19:28:14 <Prattler> can also wait if bitcoin ever costs $1000+
206 2012-06-29 19:28:21 <Prattler> then your small transactions are no longer small
207 2012-06-29 19:28:51 <maaku> BlueMatt: did you document how you setup jenkins.bluematt.me?
208 2012-06-29 19:29:07 <maaku> I'm attempting a similar bitcoind continuous integration setup
209 2012-06-29 19:29:35 <yexxxxx> can i send them to me without confirmation and then send them to another wallet and spect them to be confirmed?
210 2012-06-29 19:30:06 <yexxxxx> with fee = 0
211 2012-06-29 19:30:27 <sipa> from the viewpoint of the network, there is no difference between a send to self a send elsewhere
212 2012-06-29 19:30:38 <sipa> there is not even a way to distinguish them
213 2012-06-29 19:30:42 <yexxxxx> send them to me with fee = 0 and then setup a higher fee and send them to other address
214 2012-06-29 19:30:53 <sipa> in theory, yes
215 2012-06-29 19:31:08 <yexxxxx> with fee = 0 i assume they are not going to be mined, but i can accept them anyway?
216 2012-06-29 19:31:30 <sipa> right now, sending any transaction with fee=0 is dangerous
217 2012-06-29 19:31:30 <yexxxxx> and then send them and have them mined?
218 2012-06-29 19:32:18 <sipa> the client does not deal well with non-confirming transactions, and miners do not use fees from subsequent transactions to determine the priorities of earlier unconfirmed transactions
219 2012-06-29 19:32:36 <sipa> in the long term, i expect that to change and become more common
220 2012-06-29 19:33:14 <yexxxxx> ok
221 2012-06-29 19:33:40 <yexxxxx> so there's no solution at this point of the story... ok :)
222 2012-06-29 19:33:59 <maaku> there is a solution: don't use the block chain
223 2012-06-29 19:34:33 <sipa> but you still need to get your transaction in the chain, before you want any payment done using its outputs to be confirmable
224 2012-06-29 19:35:53 <maaku> i meant request people to use some other wallet service (mtgox, bitinstant, roll your own, whatever)
225 2012-06-29 19:36:32 <yexxxxx> i will request a fee for each transaction
226 2012-06-29 19:39:35 <maaku> BlueMatt: n/m, I found it in the console log :)
227 2012-06-29 19:48:59 <Obsi> hypothetically, if one were to notice a 51% threat to the network, what would be the proper avenue of disclosure?
228 2012-06-29 19:50:11 <BlueMatt> maaku: if you want the bash script which jenkins runs, Ill gladly forward them
229 2012-06-29 19:50:52 <BlueMatt> maaku: also, if you want to improve them (and add actually useful test cases aside from very, very basic sanity tests, Id gladly give you access to jenkins so you can tweak the bash scripts)
230 2012-06-29 19:50:55 <maaku> yes, that'd be great; although I think I found it anyway at the top of the latest console output
231 2012-06-29 19:52:59 <luke-jr> Obsi: like, someone has 51%, or there's a vuln making it easier to do?
232 2012-06-29 19:53:25 <BlueMatt> maaku: http://pastebin.com/zpUU2eMT
233 2012-06-29 19:53:27 <Obsi> like someone has 51%
234 2012-06-29 19:53:37 <BlueMatt> (3 separate scripts there)
235 2012-06-29 19:53:42 <luke-jr> Obsi: I think just shout it to the world - it's not like the info can be abused
236 2012-06-29 19:53:53 <maaku> BlueMatt: awesome, thanks :)
237 2012-06-29 19:53:55 <Obsi> kk, ty
238 2012-06-29 19:54:06 <luke-jr> Obsi: wait for someone else to agree :p
239 2012-06-29 19:54:54 <maaku> I'm setting up a jenkins build bot to do mac, linux, & windows builds on each commit
240 2012-06-29 19:55:15 <BlueMatt> maaku: mac, I dont do, windows and linux builds are done on those scripts
241 2012-06-29 19:55:42 <maaku> BlueMatt: cool, thanks; i'll share my changes
242 2012-06-29 19:55:44 <BlueMatt> maaku: if you wish to contribute stuff for mac builds, Ill gladly give you enough access to jenkins.bluematt.me to do so, if you dont feel like duplicating effort there
243 2012-06-29 19:56:51 <Diapolo> maaku: Are you working in the Qt Mac version, too?
244 2012-06-29 19:57:35 <maaku> Diapolo: yes
245 2012-06-29 19:59:14 <Diapolo> maaku: Can you take a look at the #ifdef Q_WS_MAC stuf for GUI layout ... it would be nice if those can be removed at some time at least for GUI element widths and that stuff.
246 2012-06-29 19:59:20 <Diapolo> +f
247 2012-06-29 19:59:54 <maaku> BlueMatt: sure. at the moment it's just a Mac Mini jenkins build-slave. once it's working and I'm happy with the performance i can have it connect to your jenkins server too, to do the Mac builds
248 2012-06-29 20:00:16 <BlueMatt> maaku: would be awesome
249 2012-06-29 20:10:03 <luke-jr> maaku: just for master, or all branches? ;)
250 2012-06-29 20:10:31 <BlueMatt> luke-jr: oh...yea need to do your branches...let me go set up duplicate jobs for that
251 2012-06-29 20:11:34 <maaku> luke-jr: whatever branches there's a demand for
252 2012-06-29 20:12:11 <BlueMatt> luke-jr: pull requests is hard to do, doing any given git branch isnt...
253 2012-06-29 20:12:31 <luke-jr> BlueMatt: can't just iterate over all the pullreq branches?
254 2012-06-29 20:13:06 <maaku> this exceeds my jenkins-foo :\n3885003
255 2012-06-29 20:13:12 <maaku> luke-jr: ah, ok that might be possible then
256 2012-06-29 20:13:30 <luke-jr> [remote "origin-pull"]
257 2012-06-29 20:13:31 <luke-jr> fetch = +refs/pull/*:refs/remotes/origin-pull/*
258 2012-06-29 20:13:33 <luke-jr> url = git://github.com/bitcoin/bitcoin.git
259 2012-06-29 20:13:34 <luke-jr> in .git/config
260 2012-06-29 20:14:23 <BlueMatt> luke-jr: requiring everyone to number their branches properly doesnt really help...dunno, Ill have to look into github's api sometime to see if they provide enough info to do it easily in bash
261 2012-06-29 20:14:48 <luke-jr> BlueMatt: it's automatic
262 2012-06-29 20:15:08 <luke-jr> add that .git/config remote section, then just: git fetch origin-pull
263 2012-06-29 20:15:11 <luke-jr> it makes all the branches by number
264 2012-06-29 20:16:04 <maaku> luke-jr: definitely is possible then, but not sure how to integrate it into jenkins in a way that makes sense&
265 2012-06-29 20:16:20 <maaku> a separate jenkins project for each pull request, or &?
266 2012-06-29 20:16:45 <luke-jr> I'm not familiar with jenkins
267 2012-06-29 20:17:57 <BlueMatt> maaku: no, Id guess do a loop in bash to iterate over the pull requests
268 2012-06-29 20:18:32 <BlueMatt> luke-jr: all you need to know about jenkins: run bash script: if (returns error) build fails; else build succeeds;
269 2012-06-29 20:18:41 <maaku> BlueMatt: yeah, that's what I thought, but where? in the build script? then all pull requests would show up as a single job
270 2012-06-29 20:18:48 <BlueMatt> (well, it has more options for java, etc projects, but for me...its all bash)
271 2012-06-29 20:19:31 <maaku> BlueMatt: it'd be better to have a "Pull-Requests" tab (like you have for "Bitcoin-Mainline" and "Bitcoin-Testing") with each pull-request listed as a job
272 2012-06-29 20:19:33 <BlueMatt> maaku: Id think that'd be the way to do it...maybe if gihub's api has an option to comment on a pull, just comment "Build failed, see: jenkins.bluematt.me/...
273 2012-06-29 20:19:36 <luke-jr> BlueMatt: why not have jenkins use gitian then? :p
274 2012-06-29 20:19:48 <maaku> luke-jr: that's what I'm doing
275 2012-06-29 20:19:52 <BlueMatt> luke-jr: because it already runs in a vm...or didnt that get fixed?
276 2012-06-29 20:20:01 <maaku> gitian now supports LXC
277 2012-06-29 20:20:07 <maaku> although it's broken, I've found out
278 2012-06-29 20:20:11 <BlueMatt> luke-jr: meh, it runs pretty close to the actual gitian build scripts anyway
279 2012-06-29 20:20:30 <luke-jr> BlueMatt: I enjoy nested VMs
280 2012-06-29 20:21:01 <BlueMatt> luke-jr: well, Im not saying jenkins couldnt use some man-hours to really improve it to make it more sane, but...for now, it works
281 2012-06-29 20:21:08 <luke-jr> ;)
282 2012-06-29 20:21:16 <BlueMatt> luke-jr: anyway, patches/help absolutely welcome, I just havent spent much time on it
283 2012-06-29 20:23:15 <BlueMatt> luke-jr: (if you, or anyone else who wants to help, want an account on the jenkins site so you can tweak the bash scripts, Ill gladly provide them)
284 2012-06-29 20:23:28 <maaku> ok. i'm going to get it jenkins working using gitian LXC + darwin builds (about half-way there already), then see about pull-requests and setting up my mac as a build-bot for jenkins.bluematt.me
285 2012-06-29 20:24:01 <BlueMatt> maaku: alright, well if you want an account on jenkins.bluematt.me so you can modify it, Ill gladly provide one
286 2012-06-29 20:24:10 <BlueMatt> (when you get far enough, that is)
287 2012-06-29 20:24:16 <maaku> alright thx i'll let you know then :)
288 2012-06-29 21:17:24 <gribble> New news from bitcoinrss: Diapolo opened pull request 1537 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1537>