1 2015-04-20 00:12:46 <CodeShark> what's the current behavior if you attempt an operation that requires a deeper stack than you have?
  2 2015-04-20 00:12:56 <CodeShark> does the script terminate and return false>
  3 2015-04-20 00:12:58 <CodeShark> ?
  4 2015-04-20 00:15:46 <CodeShark> I guess so: return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
  5 2015-04-20 02:24:03 <deego> http://www.reddit.com/r/Bitcoin/comments/334qvx/is_there_any_way_i_can_determine_what_age_my/ - the answer is yes and yes, right? Every satoshi can be traced back to when it was mined, right?
  6 2015-04-20 02:29:25 <adlai> deego: this is more for #bitcoin, but - the answer isn't a clean yes; imagine a tx with two inputs and one output. you need some assumption about how to map each output satoshi to one of the two inputs.
  7 2015-04-20 02:29:56 <deego> adlai: apologies. And, thanks. I see.
  8 2015-04-20 03:03:01 <kedd> I just made this transaction with bitcoind: https://blockchain.info/tx/a63243d433f3bff5aae4ae8e02288bf37b2645e9a9c0979097d26bca1009a153
  9 2015-04-20 03:03:15 <kedd> Doesn't that ouput 0 look a little extraneous?
 10 2015-04-20 03:07:10 <kedd> I guess to say, I would've preferred it not to have sourced the 10005 bit input, and not had a change address
 11 2015-04-20 03:22:14 <gmaxwell> The algorithim is greedy and can sometimes find it needs fees; go try to add them, then find it doesn't need them anymore.
 12 2015-04-20 04:26:52 <dcousens> is there a way I can get the block header (serialized) using the RPC w/o grabbing all the transactions as well?
 13 2015-04-20 04:56:47 <gmaxwell> Want to see the slides for my last part? those are completely transacribed now http://people.xiph.org/~greg/preso1.pdf
 14 2015-04-20 04:57:16 <gmaxwell> oops mistype, wrong channel; there is nothing to see there.
 15 2015-04-20 04:57:43 <gmaxwell> (unless you clicked super fast; in which case please keep it to yourself)
 16 2015-04-20 05:33:17 <jcrubino> is total coins released and total coin supply with rpc calls?
 17 2015-04-20 05:49:54 <jcrubino> gmaxwell: so its not available in the rpc calls?
 18 2015-04-20 05:56:10 <Manuel-Calavera> Greetings everyone
 19 2015-04-20 06:18:32 <petertodd> e/away
 20 2015-04-20 06:19:19 <petertodd> FWIW, just released python-bitcoinlib-v0.4.0 - shouldn't be anything too major, but if I'm about to make a fool of myself let me know... https://github.com/petertodd/python-bitcoinlib/commit/f8606134765aa986537e897598df7b7833e0e6da
 21 2015-04-20 09:40:45 <sipa> CodeShark: that is about the script stack, not the if/else stack
 22 2015-04-20 09:41:12 <sipa> CodeShark: the stack error is when you try to pop an element when the stack is empty, mostly
 23 2015-04-20 09:41:14 <CodeShark> yes, I know - separate issue entirely
 24 2015-04-20 09:41:41 <CodeShark> I figured it out
 25 2015-04-20 09:41:53 <sipa> ok
 26 2015-04-20 09:46:37 <CodeShark> thanks, though :)
 27 2015-04-20 10:02:18 <bitcoin-dev082> Hi, is there any possibility to delete Watch-only address ?
 28 2015-04-20 10:03:48 <kinlo> bitcoin-dev082: it might be better to ask those questions on #bitcoin, this channel is for development purposes
 29 2015-04-20 10:06:19 <bitcoin-dev082> also found such issue with watch-only addresses getreceivedbyaddress doesn`t show correct amount, it differs from blockchain and origin wallet
 30 2015-04-20 10:07:45 <stonecoldpat> bitcoin-dev082: you may need to reindex the bitcoin core's blockchain (i assume you added this watch-only address to bitcoin core, after it had already received funds?), but this is probably more #bitcoin as kinlo said
 31 2015-04-20 10:08:58 <bitcoin-dev082> ok, thanks
 32 2015-04-20 10:17:44 <jonasschnelli> cdecker: Regarding: http://bitcoinstats.com/network/dns-servers/: where is you client located (in terms of calculating the response time)?
 33 2015-04-20 10:23:14 <rubensayshi> hmm, this is weird, why did my (testnet) node decide to go back to a shorter chain? https://gist.githubusercontent.com/rubensayshi/c404e980523ef494942a/raw/a43765a2c936161fa09f02740a35d3b4ff32ccb6/gistfile1.txt
 34 2015-04-20 10:23:18 <cdecker> jonasschnelli: they are currently in Zurich, but I'd like to eventually extend them to be located in several regions
 35 2015-04-20 10:26:59 <Luke-Jr> rubensayshi: it had more work
 36 2015-04-20 10:27:54 <rubensayshi> ah, I never considered that, but I guess considering the low diff on testnet it's possible that a chain with less blocks has more work?
 37 2015-04-20 10:40:33 <wumpus> rubensayshi: that's certainly possible, remember that lots of blocks on testnets have difficulty 1 due to the 20-minute rule
 38 2015-04-20 10:41:07 <Luke-Jr>  not even improbable I think
 39 2015-04-20 10:41:13 <rubensayshi> yea
 40 2015-04-20 10:41:21 <rubensayshi> and not all mining software supports the 20min thing
 41 2015-04-20 10:41:53 <wumpus> does mining software need special support for that?
 42 2015-04-20 10:42:44 <Luke-Jr> no
 43 2015-04-20 10:42:55 <wumpus> isn't it the node that gives, through getblocktemplate, what block to mine on top of, and the difficulty?
 44 2015-04-20 10:43:15 <rubensayshi> hmm, guess I've just been very unlucky when I tried to mine testnet for some coins a while back :/
 45 2015-04-20 10:43:24 <wumpus> my guess is that someone either deliberately is messing with testnet, or started mining on an old block by accident
 46 2015-04-20 10:43:46 <wumpus> very likely the first :-)
 47 2015-04-20 10:44:33 <rubensayshi> yea, there are a lot of orphans around the height I'm looking at
 48 2015-04-20 10:44:38 <Luke-Jr> someone has too much free time
 49 2015-04-20 10:44:40 <Luke-Jr> lol
 50 2015-04-20 10:44:53 <wumpus> rubensayshi: what tends to happen is that the official difficulty of testnet is fairly high, then most actual blocks get mined with the 20-minute rule
 51 2015-04-20 10:45:17 <Luke-Jr> 
ACTION looks forward to getting rid of the 20 minute rule

 52 2015-04-20 10:45:19 <wumpus> rubensayshi: (also by adjusting the time of the blocks)
 53 2015-04-20 10:46:15 <rubensayshi> yea, a while back the testnet was constantly at +2hrs because of it
 54 2015-04-20 10:46:41 <wumpus> it's a continuous race to +2hrs
 55 2015-04-20 10:48:57 <rubensayshi> I guess the occasional retarget to diff 1 and the high amount of orphans can be good for people testing stuff xD
 56 2015-04-20 10:50:11 <wumpus> that's the point of using the chaotic testnet instead of a tightly controlled private regtest
 57 2015-04-20 10:51:18 <rubensayshi> so I guess we need more people trying to create chaos :D
 58 2015-04-20 10:51:54 <jonasschnelli> cdecker: Ah Zurich. So the ping around 11:30 worries me. Could that also be on your side?
 59 2015-04-20 10:53:02 <wumpus> rubensayshi: hahaha up to a point, but yes I tend to encourage testnet rascals, better to find bugs there
 60 2015-04-20 10:53:03 <jonasschnelli> cdecker: i checked my servers munin stats and cannot see any issues around 11:30 GMT. Maybe it's somewhere between our two servers.
 61 2015-04-20 12:07:02 <wumpus> going to tag 0.10.1rc3 in a few hours ,let me know if I forgot anything
 62 2015-04-20 13:14:49 <cdecker> jonasschnelli: looks like a cronjob :-)
 63 2015-04-20 13:16:59 <cdecker> I am sitting on the swiss backbone through Switch, so I'd be very surprised if they have regular spikes in their latency
 64 2015-04-20 13:31:18 <jonasschnelli> cdecker: Right. Must be on my side. Thanks.
 65 2015-04-20 13:50:42 <cdecker> jonasschnelli: I am wondering myself what this might be, some other seeds also have daily spikes every day, could this be the backup time at the datacenter?
 66 2015-04-20 13:52:34 <jonasschnelli> cdecker: for my endpoint: there are some backup related rdiff cron-jobs which could cause the spike. But >125ms is even in a backup situation strange.
 67 2015-04-20 13:55:59 <earlz> So, this seems like a dumb question, but how can I disable building the GUI on bitcoin core?
 68 2015-04-20 13:56:23 <earlz> I used --with-gui=none (which I swear use to work) but that results in errors about not being able to find the Qt dependencies
 69 2015-04-20 13:56:39 <earlz> I've heard about --disable-gui... but that doesn't seem to actually do anything
 70 2015-04-20 13:59:39 <earlz> oh, it's case sensitive
 71 2015-04-20 14:00:08 <earlz> I tried --with-gui=NO, and it needs to be --with-gui=no
 72 2015-04-20 14:02:18 <wumpus> --without-gui works too
 73 2015-04-20 14:03:37 <wumpus> and yes all the settings are case sensitive, you should use exactly what the ./configure --help shows
 74 2015-04-20 14:05:56 <priidu> btw
 75 2015-04-20 14:06:10 <priidu> asked about the "subver" field in "getPeerInfo" the other day :P
 76 2015-04-20 14:06:33 <priidu> looks like there IS a way to get it without decoding it yourself from getInfo
 77 2015-04-20 14:06:54 <priidu> (or reading the HTTP 'server' header)
 78 2015-04-20 14:07:14 <priidu> seems like the 'getNetworkInfo' RPC returns it ('subversion') since 0.10.0
 79 2015-04-20 14:07:51 <wumpus> ok then, good to know
 80 2015-04-20 14:14:35 <priidu> decoding it by hand fit my needs better anyways, so I did it that way
 81 2015-04-20 14:15:05 <priidu> but (re)discovered the getnetworkinfo rpc a bit later
 82 2015-04-20 14:46:48 <jonasschnelli> sipa: https://github.com/sipa/bitcoin/commit/eb3743acc55852e012e1fec575eae7bc7920a8c0#diff-8c859b51e45a48931abf131798a632ddR71
 83 2015-04-20 14:46:57 <jonasschnelli> why would you not derive hardened keys on the fly?
 84 2015-04-20 15:01:15 <ajweiss> are debug symbols saved off anywhere for release builds?
 85 2015-04-20 15:01:47 <wumpus> not by default, you need to edit the descriptors to build with debug symbols
 86 2015-04-20 15:03:43 <ajweiss> hrm
 87 2015-04-20 15:12:49 <jonasschnelli> ajweiss: i think you need to change this: https://github.com/bitcoin/bitcoin/blob/master/contrib/gitian-descriptors/gitian-linux.yml#L27
 88 2015-04-20 15:13:39 <wumpus> I think it would be useful to save the debug symbols before stripping, but I never felt like figuring out how to do that, for the few times I needed to debug problems with gitian executables I just change make install_strip to install
 89 2015-04-20 15:15:45 <wumpus> the gives you symbols not full debug information, for that you also need to make sure -g is passed in the CPPFLAGS, IIRC this does balloon the amount of memory used by g++ while building
 90 2015-04-20 15:15:48 <ajweiss> i was just looking at the docs
 91 2015-04-20 15:15:55 <ajweiss> objcopy looks like it will do it
 92 2015-04-20 15:16:33 <ajweiss>      objcopy --only-keep-debug foo foo.debug
 93 2015-04-20 15:16:43 <wumpus> right
 94 2015-04-20 15:17:30 <jonasschnelli> ajweiss: do you seek for analyze capability of crashes? Or a debuggable release version?
 95 2015-04-20 15:19:03 <earlz> So, when compiling 0.10.0, I notice that when using a custom set of CXXFLAGS, it gets passed twice when building leveldb
 96 2015-04-20 15:19:10 <ajweiss> yeah i have a core file
 97 2015-04-20 15:19:35 <earlz> like clang $CXXFLAGS -some-arg -DSOMEDEFINE $CXXFLAGS files...
 98 2015-04-20 15:19:59 <wumpus> earlz: strange, but shouldn't have any adverse consequences if both sets are equal
 99 2015-04-20 15:20:16 <earlz> they are equal, but I'm trying to use a custom option on clang that can only be specified once
100 2015-04-20 15:20:50 <ajweiss> yeah it's unclear if i'd be able to use symbols from a debug build with a core file from a release build
101 2015-04-20 15:20:53 <earlz> there are many settings and tunings (usually hidden under -mllvm) that can only be specified once
102 2015-04-20 15:21:46 <ajweiss> but who knows, maybe just symbols will be enough... i'll kick off a new gitian build of 0.10
103 2015-04-20 15:22:15 <wumpus> ajweiss: well if you just specify -g and don't change the optimization level, it should work because the rest of the build is deterministic
104 2015-04-20 15:23:53 <wumpus> -g in itself doesn't affect code generation, do be careful that some meanings of 'debug builds' also change the optimization options, in which case the underlying binary will obviously not match
105 2015-04-20 15:24:20 <ajweiss> the dwarf junk won't move addresses around or anything?
106 2015-04-20 15:24:38 <wumpus> no
107 2015-04-20 15:24:50 <ajweiss> (i'm woefully ignorant about gcc's code generation)
108 2015-04-20 15:25:01 <ajweiss> i'll give it a whirl
109 2015-04-20 15:25:47 <wumpus> well at least it shouldn't; dwarf just documents the generated code in additional sections, it is not itself mapped into memory while executing
110 2015-04-20 15:26:59 <earlz> er, it's not leveldb that has the problem it's everything under helpers
111 2015-04-20 15:27:15 <wumpus> (of course the address move around every time (due to address space randomization); but addresses relative to the start of the executable should remain the same, I think)
112 2015-04-20 15:32:05 <sinetekVII> is there a reason for all the 'using namespace XX' ?
113 2015-04-20 15:33:08 <shurnormal> It's nice for educational purposes.
114 2015-04-20 15:33:25 <wumpus> you don't know what it does, or?
115 2015-04-20 15:33:55 <ajweiss> comment it out, see what happens
116 2015-04-20 15:33:56 <wumpus> (try compiling without it)
117 2015-04-20 15:34:00 <ajweiss> haha
118 2015-04-20 15:34:01 <wumpus> heh ajweiss
119 2015-04-20 15:34:12 <sinetekVII> no I mean, it kind of pollutes the global namespace..
120 2015-04-20 15:34:54 <wumpus> you can also specify it within a function
121 2015-04-20 15:35:01 <wumpus> or in a smaller namespace
122 2015-04-20 15:35:06 <sipa> we've gradually been reducing the global using namespaces
123 2015-04-20 15:35:16 <sinetekVII> I was wondering if the patch would go in
124 2015-04-20 15:35:16 <sipa> especially in headers
125 2015-04-20 15:35:24 <wumpus> I wouldn't worry about it
126 2015-04-20 15:35:30 <sinetekVII> i've removed a bit of it
127 2015-04-20 15:35:33 <sinetekVII> bah i could do that
128 2015-04-20 15:35:34 <wumpus> there should be no "using namespace" in headers at all
129 2015-04-20 15:36:00 <sinetekVII> I don't see any in headers, thankfully
130 2015-04-20 15:36:08 <wumpus> that's indeed bug prone, but within compilation units it's not really an issue
131 2015-04-20 15:36:43 <sinetekVII> actually i do see a few, going to send a PR then
132 2015-04-20 15:36:45 <wumpus> please try to solve actual issues, don't contribute to the load of pulls that just change trivial things ormove things around :)
133 2015-04-20 15:37:09 <sinetekVII> yeah i suppose so
134 2015-04-20 15:37:33 <sipa> i would not object to a PR to remove them from headers, if any are left at all
135 2015-04-20 15:37:47 <sinetekVII> to be honest i had some issues compiling on openBSD, this is what led me to it
136 2015-04-20 15:38:15 <sinetekVII> I'd have to probe further tho to identify the real issue
137 2015-04-20 15:38:50 <wumpus> from a 'git grep' there's only two in headers, one in our code, and that is in a function scope so used exactly as it should
138 2015-04-20 15:39:43 <wumpus> ... the other one is in json spirit, and also in a function
139 2015-04-20 15:39:50 <sinetekVII> right.
140 2015-04-20 15:39:53 <sinetekVII> then that's that.
141 2015-04-20 15:42:59 <wumpus> anyhow if it causes compilation issues on some platform that's a good reason
142 2015-04-20 15:43:30 <sipa> what happened to the plan of ditching json spirit in favor of univalue?
143 2015-04-20 15:43:57 <wumpus> there's a pull for that somewhere
144 2015-04-20 15:44:20 <sipa> likely prehistoric.
145 2015-04-20 15:44:22 <wumpus> needs review, testing, etc
146 2015-04-20 15:45:38 <wumpus> I agree on the plan, but I'm not yet conviced the univalue code is fully mature, but I'm ok with being proven wrong there
147 2015-04-20 15:46:32 <sipa> fair enough
148 2015-04-20 15:46:57 <sinetekVII> there's a gettext issue with json_spirit
149 2015-04-20 15:47:22 <wumpus> json has some ugly edge cases with unicode and such, although I think json spirit fails too on some
150 2015-04-20 15:48:21 <sinetekVII> I looked into issue #5895, I cannot resolve it though
151 2015-04-20 15:48:22 <wumpus> (at a certain point we upgraded to a newer version of json spirit for that, but that broke monetary values, which was even worse :-)
152 2015-04-20 15:48:32 <wumpus> so that was reverted...
153 2015-04-20 15:48:59 <wumpus> in any case for reasons like that I don't feel qualified to judge a json implementation
154 2015-04-20 15:49:12 <sinetekVII> unicode text gets garbled before the Qt path. no idea about the json itself
155 2015-04-20 15:49:21 <wumpus> qt doesn't even get into the picture here
156 2015-04-20 15:49:45 <wumpus> I'm just talking about RPC over the network
157 2015-04-20 15:49:57 <sinetekVII> sorry i don't want to confuse the conversation. i was mentioning #5895. i suspect it's broken on non-qt too.
158 2015-04-20 15:49:58 <wumpus> probably in the GUI path there are tons of other places where it can screw up
159 2015-04-20 15:50:12 <wumpus> but not necessarily related to json_spirit
160 2015-04-20 15:51:42 <wumpus> yes #5895 is pretty funny
161 2015-04-20 15:52:48 <wumpus> looks like utf-8 sub-units are interpreted as individual unicode characters
162 2015-04-20 15:53:26 <sinetekVII> from what I can see it expects UTF-16 or UTF-32 and when you give it UTF-8 it breaks
163 2015-04-20 15:53:29 <wumpus> but the underlying issue is that error messages reported on RPC shouldn't be translated
164 2015-04-20 15:54:08 <wumpus> (utf-8 cleanness is still important for labels and such, but shouldn't play a role for error messages)
165 2015-04-20 15:54:23 <wumpus> hah don't mention UTF-16 or 32, that will only make it worse
166 2015-04-20 15:57:05 <wumpus> I vaguely remember the errors-translation issue was fixed in master, but maybe one was missed
167 2015-04-20 15:59:44 <wumpus> apparantly the "This is a pre-release test build - use at your own risk..." message IS translated
168 2015-04-20 16:09:55 <sinetekVII> yep
169 2015-04-20 16:10:58 <shurnormal> 6
170 2015-04-20 16:11:17 <wumpus> TBH I don't think json spirit as-is supports unicode at all, would be interesting to see how univalue handles this
171 2015-04-20 16:20:46 <kanzure> win 3
172 2015-04-20 16:20:49 <kanzure> whoops
173 2015-04-20 17:38:10 <earlz> anyone ever seen this on Mac? libtool:   error: ignoring unknown tag YASM
174 2015-04-20 17:39:55 <ajweiss> it looks like it's not possible to up parallelism for gitian builds.  is this for a reason?
175 2015-04-20 17:40:29 <ajweiss> i can't imagine it would matter, but lots of things happen that i can't imagine
176 2015-04-20 17:46:07 <earlz> what does this libtool error even mean?
177 2015-04-20 17:50:43 <earlz> er, that's an "error" but not what I'm having trouble with apparetly
178 2015-04-20 17:50:50 <earlz> what is this?
179 2015-04-20 17:50:51 <earlz> Building LevelDB ...
180 2015-04-20 17:50:52 <earlz> Makefile:18: *** multiple target patterns.  Stop.
181 2015-04-20 17:53:02 <cfields_> earlz: erm, building bitcoin?
182 2015-04-20 17:53:16 <earlz> yea, 0.10.0
183 2015-04-20 17:53:26 <cfields_> you get both of those errors?
184 2015-04-20 17:53:51 <earlz> yea, on Mac Yosemite... weird thing is I literally just built it from source, did a clean and compiled again and now I'm getting these errors
185 2015-04-20 17:53:58 <cfields_> oh wait, libtool error is building libsecp256k1 i guess?
186 2015-04-20 17:54:08 <earlz> yea I think so
187 2015-04-20 17:54:11 <cfields_> i can't remember if yasm was still used there in 0.10 or not
188 2015-04-20 17:54:25 <earlz> but that's not the error that's actually stopping me. The error is the multiple patterns bit
189 2015-04-20 17:56:25 <cfields_> earlz: i'd re-configure and make clean again, then retry. before going any further
190 2015-04-20 17:56:40 <cfields_> are you switching around between 0.10 and master?
191 2015-04-20 17:57:34 <earlz> no
192 2015-04-20 18:00:43 <earlz> Building LevelDB ...
193 2015-04-20 18:00:43 <earlz> make[1]: *** [all-recursive] Error 1
194 2015-04-20 18:00:43 <earlz> make[2]: *** [leveldb/libmemenv.a] Error 2
195 2015-04-20 18:00:43 <earlz> Makefile:18: *** multiple target patterns.  Stop.
196 2015-04-20 18:00:44 <earlz> make: *** [all-recursive] Error 1
197 2015-04-20 18:00:56 <earlz> after reconfigure and clean
198 2015-04-20 18:01:31 <earlz> for reference, what line it's choking on: $(shell CC="$(CC)" CXX="$(CXX)" TARGET_OS="$(TARGET_OS)" ./build_detect_platform build_config.mk ./)
199 2015-04-20 18:01:46 <cfields_> have you messed around with CC/CXX ?
200 2015-04-20 18:02:13 <earlz> no, messed with CXXFLAGS though
201 2015-04-20 18:02:58 <cfields_> same problem without doing that?
202 2015-04-20 18:07:00 <earlz> ugh... no such error when not changing cxxflags
203 2015-04-20 18:07:19 <earlz> isn't there something I can use to get more verbose debugging info?
204 2015-04-20 18:07:51 <cfields_> verbose debugging of what?
205 2015-04-20 18:08:05 <earlz> makefile I guess
206 2015-04-20 18:08:10 <earlz> the build process itself
207 2015-04-20 18:08:13 <wumpus> -ggdb -g3
208 2015-04-20 18:08:27 <cfields_> earlz: make V=1
209 2015-04-20 18:08:33 <cfields_> earlz: that's not our make though, that's leveldb
210 2015-04-20 18:08:39 <wumpus> there's various flags to get more debugging info
211 2015-04-20 18:09:01 <ajweiss> this smells like weird autotools versions to me
212 2015-04-20 18:09:46 <cfields_> earlz: if you're passing flaky options that can't be duped, you're best off passing them in CXX
213 2015-04-20 18:09:48 <ajweiss> oh wait, you are changing cxxflags
214 2015-04-20 18:09:59 <earlz> hmm.. well I'm sure it doesn't help that I'm using a custom compiled version of clang with experimental optimizations (hence what the CXXFLAGS is controlling)
215 2015-04-20 18:10:09 <cfields_> ./configure CXX="`which clang` -mfoo"
216 2015-04-20 18:10:21 <earlz> hmm that's a good idea
217 2015-04-20 18:10:28 <denisx> BlueMatt: your relaynetworkclient is working internally with ipv6 adresses but your relay adresses are only ipv4, is that correct?
218 2015-04-20 18:11:05 <earlz> I ended up just hacking away at the leveldb makefile (but AFTER that error occurs in the file, not before) to force the CXXFLAGS to not be passed in
219 2015-04-20 18:11:42 <wumpus>  * [new tag]         v0.10.1rc3 -> v0.10.1rc3
220 2015-04-20 18:11:51 <earlz> alright, apparently it's something to do with these experimental optimizations. I guess that leveldb bit is compiling something and expecting a returned value, and with my compiler it gives back some crzy output or some such
221 2015-04-20 18:12:46 <cfields_> earlz: if you're getting a make error, it sounds more like a quoting issue. "multiple target patterns" implies that clang isn't even invoked
222 2015-04-20 18:12:50 <cfields_> wumpus: hooray, building
223 2015-04-20 18:12:52 <wumpus> using bitcoin to test experimental optimizations sounds like a very bad idea
224 2015-04-20 18:13:08 <wumpus> e.g. the consensus code, the wallet, all places you really don't want experimental compiler behavior
225 2015-04-20 18:13:39 <earlz> wumpus: well it's not for production or anything. Bitcoin has the most thorough set of automated tests I know of
226 2015-04-20 18:14:36 <earlz> So maybe I shouldn't be asking for support here for my crazy stuff I'm doing, but I imagine if the tests pass and actually syncs, it's probably a good indication that the compiler is pretty sane
227 2015-04-20 18:16:01 <wumpus> cfields_: do you have these gbuild warnings as well (that you need to use --upgrade)?
228 2015-04-20 18:16:30 <wumpus> cfields_: seems that recently there have been problems with changes in the ubuntu vm used for building (not due to us)
229 2015-04-20 18:16:34 <cfields_> wumpus: i haven't started building quite yet. never seen them, though
230 2015-04-20 18:17:10 <wumpus> going to try to rebuild the image
231 2015-04-20 18:17:42 <wumpus> (--upgrade doesn't work this time)
232 2015-04-20 18:36:37 <cfields_> wumpus: seems to be no issues here
233 2015-04-20 18:38:58 <wumpus> cfields_: works here now too, after regenerating the image and killing qemu-xx
234 2015-04-20 18:39:31 <cfields_> hmm, weird. any idea what the cause is?
235 2015-04-20 18:40:14 <wumpus> nope
236 2015-04-20 18:40:49 <wumpus> I think there have been problems with kernel upgrades before, but install.log was empty in this case
237 2015-04-20 18:42:07 <wumpus> the error message to the console was "Could not download some packages, please run gbuild --upgrade"
238 2015-04-20 18:45:36 <cfields_> oh, looks like that was just added to gitian
239 2015-04-20 18:46:53 <cfields_> i'm not sure why it'd be doing a dist-upgrade anyway. seems to defeat the purpose...
240 2015-04-20 18:48:48 <jonasschnelli> 10.1rc3: 909f50c6ee1cac188895b2a001b2c19a1570996721ee953446f704fd78bb6ae6  bitcoin-0.10.1-linux32.tar.gz
241 2015-04-20 18:50:28 <cfields_> jonasschnelli: btw, i'm excited to play with your logdb wallet rfc, just haven't had a chance yet. planning to poke at it some asap
242 2015-04-20 18:51:45 <jonasschnelli> cfields_: cool! It's just the very basics of a possible new wallet
243 2015-04-20 18:52:23 <cfields_> jonasschnelli: understood, sounds like the logical way to start
244 2015-04-20 18:58:26 <cfields_> 909f50c6ee1cac188895b2a001b2c19a1570996721ee953446f704fd78bb6ae6  bitcoin-0.10.1-linux32.tar.gz
245 2015-04-20 19:01:32 <ajweiss> so it looks like i can get some symbols by rebuilding and notstripping
246 2015-04-20 19:01:55 <ajweiss> but adding -g, extracting the debugging and then linking it seems to annoy gdb
247 2015-04-20 19:02:55 <cfields_> ajweiss: all the offsets would be wrong that way
248 2015-04-20 19:02:59 <cfields_> what are you trying to do?
249 2015-04-20 19:03:18 <ajweiss> i have a core file from a release build
250 2015-04-20 19:03:44 <ajweiss> i'd like to inspect some locals, but i'm thinking that might be impossible
251 2015-04-20 19:04:09 <BlueMatt> denisx: yes
252 2015-04-20 19:04:17 <cfields_> i believe so too. For that to work, we'd have to have built that way originally
253 2015-04-20 19:04:23 <BlueMatt> because then i dont have to change code to use ipv6 :)
254 2015-04-20 19:05:03 <cfields_> i know wumpus has wanted that in the past. It'd be trivial to setup our releases that way now, not sure what the unintended consequences would be though
255 2015-04-20 19:05:07 <ajweiss> so when i do a regular build on my machine, -g and -O2 are used
256 2015-04-20 19:05:20 <ajweiss> is that true with gitian builds too?
257 2015-04-20 19:05:29 <denisx> BlueMatt: ok, thats a good thing then. bad thing is, that freebsd has problems with AI_V4MAPPED so I switched back to ipv4 code
258 2015-04-20 19:05:37 <wumpus> cfields_: 'unintended consequences'?
259 2015-04-20 19:05:38 <cfields_> wumpus: are you still interested in building releases with -g, then splitting them out to debug files and stripped binaries?
260 2015-04-20 19:05:45 <denisx> BlueMatt: public.eu.relay.mattcorallo.com is correct for europe?
261 2015-04-20 19:06:05 <wumpus> cfields_: nah, I'd already be happy if the symbols were copied to a file without -g
262 2015-04-20 19:06:26 <wumpus> e.g. even without -g, gcc adds some symbol information that we strip
263 2015-04-20 19:06:32 <ajweiss> that doesn't give you any locals though
264 2015-04-20 19:06:34 <cfields_> wumpus: i'm not sure how much the end-compile changes with -g enabled. ignoring the strippable symbols
265 2015-04-20 19:06:43 <BlueMatt> denisx: see https://github.com/TheBlueMatt/RelayNode/issues/2
266 2015-04-20 19:06:44 <wumpus> cfields_: it shouldn't change at all
267 2015-04-20 19:06:48 <BlueMatt> (bsd/osx, same thing...)
268 2015-04-20 19:06:55 <BlueMatt> denisx: yup
269 2015-04-20 19:06:58 <wumpus> cfields_: dwarf just documents the code, it doesn't affect code generation
270 2015-04-20 19:07:20 <BlueMatt> denisx: try defining X86_BSD
271 2015-04-20 19:07:21 <ajweiss> i noticed a few changed bytes
272 2015-04-20 19:07:27 <BlueMatt> denisx: it may work already, otherwise read the issue :)
273 2015-04-20 19:07:35 <wumpus> cfields_: as long as you don't change the other optimization flags, of course
274 2015-04-20 19:07:38 <ajweiss> i think it might have to do with the executable metadata but i'm not sure
275 2015-04-20 19:07:39 <denisx> ok, thanks
276 2015-04-20 19:08:06 <wumpus> cfields_: the only drawback would be larger memory usage during compile/linking
277 2015-04-20 19:09:27 <cfields_> wumpus: mm, i'll take your word for it
278 2015-04-20 19:09:47 <cfields_> wumpus: well, for without -g, that should be trivial. I can PR that addition
279 2015-04-20 19:11:08 <wumpus> cfields_: there are plenty of projects (e.g. graphics drivers) that are built with full debug information that is stripped for release
280 2015-04-20 19:11:32 <wumpus> cfields_: then kept around pivately in troubleshooting
281 2015-04-20 19:12:03 <cfields_> wumpus: sure, i have no issue with doing it that way. just making the case that we might want to poke at the result a bit
282 2015-04-20 19:12:15 <wumpus> it's not *that* useful for actual debugging, though
283 2015-04-20 19:12:41 <wumpus> to usefully debug in  c++ you really want to dial down the optimization as well, but for troubleshooting it's usable
284 2015-04-20 19:12:53 <ajweiss> do you get locals?
285 2015-04-20 19:13:05 <wumpus> eh, sure
286 2015-04-20 19:13:10 <wumpus> if they aren't optimized out
287 2015-04-20 19:13:41 <ajweiss> i got something weird, where function names were filled in, in the backtrace... and their prototypes were present, but no named locals...
288 2015-04-20 19:14:30 <ajweiss> (that was just install-strip to install, with objcopy to extract the debug info)
289 2015-04-20 19:15:06 <wumpus> without -g you certainly won't get specific information
290 2015-04-20 19:15:42 <wumpus> just enough for a stacktrace
291 2015-04-20 19:16:09 <wumpus> with -g you'll get loads of information, the only question is whether it's useful :-)
292 2015-04-20 19:16:29 <ajweiss> and worth the overhead
293 2015-04-20 19:16:45 <ajweiss> in this case, it was an abort so stuff should be intact
294 2015-04-20 19:16:59 <ajweiss> (would have been intact, i guess)
295 2015-04-20 19:17:18 <wumpus> objcopy'ing the symbols to addr2line stacktraces and such would be useful though, so yes let's do that
296 2015-04-20 19:18:15 <cfields_> which?
297 2015-04-20 19:18:19 <wumpus> but you can't reproduce the problem on a more instrumented build?
298 2015-04-20 19:18:52 <ajweiss> interestingly, changing the gitian descriptor to do a make install instead of a make install-strip and then doing a install -s after the fact produced slightly different binaries from the original install-strip build
299 2015-04-20 19:19:26 <ajweiss> maybe, i'm working on that...
300 2015-04-20 19:19:32 <ajweiss> it's intermittenty
301 2015-04-20 19:19:46 <wumpus> yes well maybe it calls strip with different parameters
302 2015-04-20 19:20:22 <ajweiss> or some debuglink type stuff
303 2015-04-20 19:20:24 <wumpus> one thing is for sure, strip won't make any difference to offsets in the executable, it will not relocate
304 2015-04-20 19:21:06 <wumpus> for that it doesn't make a difference wether make calls strip or it's done manually afterward, you'd say
305 2015-04-20 19:21:10 <cfields_> strip dinks with timestamps too
306 2015-04-20 19:21:50 <wumpus> yes
307 2015-04-20 19:21:53 <cfields_> which also ends up changing the checksum
308 2015-04-20 19:22:11 <wumpus> in any case, no need to worry about that
309 2015-04-20 19:22:38 <cfields_> wumpus: so you want split symbols, or split symbols + build with -g ?
310 2015-04-20 19:22:57 <wumpus> cfields_: just split symbols would be a start, adding -g is easy after that :)
311 2015-04-20 19:23:15 <cfields_> roger
312 2015-04-20 19:24:50 <wumpus> also makes it easy to check whether the -g affects the resulting, stripped executable
313 2015-04-20 19:25:37 <wumpus> (apart from silly timestamps, build ids and checksum bytes)
314 2015-04-20 19:30:01 <denisx> BlueMatt: eu does not work, I switched to us-west for now
315 2015-04-20 19:32:08 <BlueMatt> hmm? willlook
316 2015-04-20 19:42:18 <morcos> wumpus: what do you think about giving 5159 a milestone for .11, hopefully encourage some review...
317 2015-04-20 19:43:08 <wumpus> morcos: good idea
318 2015-04-20 19:57:45 <ajweiss> 909f50c6ee1cac188895b2a001b2c19a1570996721ee953446f704fd78bb6ae6  bitcoin-0.10.1-linux32.tar.gz
319 2015-04-20 19:57:48 <ajweiss> 56332b7081df411868b3720ac68769880e93f1b446f246b306cfbc962626203a  bitcoin-0.10.1-linux64.tar.gz
320 2015-04-20 20:28:30 <gielbier> Dutch police did a cybercrimechallenge today. And they asked this: What are the first 5 chars of the bitcoin addy.
321 2015-04-20 20:28:52 <gielbier> well it probably starts with a 1 or a 3 :)
322 2015-04-20 20:29:00 <gielbier> talking about loosing entropy
323 2015-04-20 20:30:15 <m__> hey i am kind of a bitcoin noob, but can somebody help explain API and how to setup automated withdrawl systems to move bitcoins around with an ebay like site?
324 2015-04-20 20:54:11 <phantomcircuit> Luke-Jr, the bitcoind getblocktemplate transactions list enforces the sigops limit right?
325 2015-04-20 20:54:26 <nemild> @m__, do you want to provide some more details on what you want to do? What’s your background with languages/programming? Feel free to private message me
326 2015-04-20 20:54:45 <Luke-Jr> phantomcircuit: as much as it can (which it can't because it doesn't do the gen tx)
327 2015-04-20 20:54:52 <phantomcircuit> ah it's CreateNewBlock
328 2015-04-20 20:54:53 <phantomcircuit> i see
329 2015-04-20 20:55:01 <phantomcircuit> Luke-Jr, alrighty
330 2015-04-20 22:35:11 <cfields_> gitian builders: osx rc3 sig is up: https://bitcoincore.org/cfields/bitcoin-0.10.1rc3/signature.tar.gz