1 2014-08-18 00:24:02 <michagogo> offline/cold storage wallets often have an online component that has only the public keys
2 2014-08-18 00:24:51 <michagogo> so it watches for transactions affecting the wallet and generally acts just like an online wallet would, except that it doesn't have the private keys to sign transactions
3 2014-08-18 00:25:33 <michagogo> Instead, you tell it to create a transaction, it spits out an unsigned transaction, which you take offline by sneakernet or similar to sign
4 2014-08-18 06:10:39 <BlueMatt> gmaxwell: bitcoin.ninja/RelayNodeClient.jar
5 2014-08-18 06:10:47 <BlueMatt> now sends local inv's
6 2014-08-18 06:11:26 <BlueMatt> and logs block hash, as requested
7 2014-08-18 10:07:34 <epscy> can someone build bitcoin with this patch and give me copy of the binary? https://github.com/bitcoin/bitcoin/pull/4701
8 2014-08-18 10:08:47 <wumpus> sure, what platform?
9 2014-08-18 10:09:10 <epscy> x86_64
10 2014-08-18 10:09:22 <epscy> ubuntu (if that matters)
11 2014-08-18 10:09:25 <wumpus> linux, mac or windows?
12 2014-08-18 10:09:26 <wumpus> right
13 2014-08-18 10:11:06 <epscy> i would do it myself but i'm on 14.04 and bitcoin fails to build due to the wrong version of libboost
14 2014-08-18 10:11:43 <epscy> gmaxwell said the pulltester would build a binary, but it's been several days and there isn't one yet
15 2014-08-18 10:14:02 <sipa> pulltester was stuck on 4682
16 2014-08-18 10:14:05 <sipa> i've reset it
17 2014-08-18 10:14:32 <sipa> weird
18 2014-08-18 10:14:54 <wumpus> weird indeed
19 2014-08-18 10:17:25 <epscy> ah ok, so shall i just wait?
20 2014-08-18 10:18:11 <wumpus> well I kicked off a gitian build, so we'll see who has an executable first
21 2014-08-18 10:18:24 <epscy> cool ;)
22 2014-08-18 10:19:43 <wumpus> bitcoin failing due to boost versions shouldn't happen though, pulltester has a boost from before history :p
23 2014-08-18 10:20:40 <epscy> trusty only has 1.54 and bitcoin needs 1.53 i think
24 2014-08-18 10:20:59 <wumpus> no, it doesn't need any specific boost version at all
25 2014-08-18 10:21:08 <epscy> to build?
26 2014-08-18 10:21:21 <wumpus> yes
27 2014-08-18 10:21:53 <wumpus> I have 14.04 with boost 1.55, works fine
28 2014-08-18 10:22:08 <wumpus> boost is a very stable library, apart from some bugfixes, not so much happens with it
29 2014-08-18 10:23:19 <epscy> ok, i'm trying a build again, one sec
30 2014-08-18 10:23:46 <epscy> checking for exit in -lboost_system... no
31 2014-08-18 10:23:48 <epscy> configure: error: Could not link against boost_system !
32 2014-08-18 10:26:00 <epscy> ok i think this might just be me
33 2014-08-18 10:27:48 <epscy> i thought i had installed all the boost packages but i hadn't
34 2014-08-18 10:32:15 <epscy> ok now i am just running out of memory when trying to compile ;)
35 2014-08-18 10:32:23 <epscy> a binary would be appreciated
36 2014-08-18 10:48:38 <wumpus> epscy: https://download.visucore.com/tmp/bitcoind-lin64-52ac637.tar.gz
37 2014-08-18 11:07:29 <epscy> wumpus: thanks
38 2014-08-18 11:32:57 <jgarzik> hrm
39 2014-08-18 11:33:05 <jgarzik> all of a sudden, everything is failing pull tester
40 2014-08-18 11:34:13 <sipa> something wrong with pulltester, or a bad pr got merged?
41 2014-08-18 11:37:43 <dsnrk> last pass by the pull tester was https://github.com/bitcoin/bitcoin/pull/4691#issuecomment-52022414
42 2014-08-18 11:38:05 <dsnrk> first failure https://github.com/bitcoin/bitcoin/pull/4718#issuecomment-52474610
43 2014-08-18 11:38:23 <sipa> but several things got merged in between
44 2014-08-18 11:38:42 <wumpus> hmm lets see
45 2014-08-18 11:40:16 <sipa> i stopped pulltester, and removed the results of those tests, so they'll be tested again
46 2014-08-18 11:45:13 <wumpus> /bin/bash: line 5: 9914 Aborted ${dir}$tst
47 2014-08-18 11:45:13 <wumpus> FAIL: test/test_bitcoin
48 2014-08-18 11:45:13 <wumpus> Running 125 test cases...
49 2014-08-18 11:45:13 <wumpus> terminate called after throwing an instance of 'boost::thread_interrupted'
50 2014-08-18 11:45:24 <wumpus> are the testcases failing for anyone else on master?
51 2014-08-18 11:45:27 <sipa> not for me
52 2014-08-18 11:45:31 <wumpus> (not for me locally at least)
53 2014-08-18 11:45:35 <sipa> but i'm not building gui/wallet usually
54 2014-08-18 11:45:44 <wumpus> it's not the gui testcases that fail
55 2014-08-18 11:46:04 <wumpus> those are ok: Totals: 3 passed, 0 failed, 0 skipped
56 2014-08-18 11:49:20 <wumpus> breakage may be caused by https://github.com/bitcoin/bitcoin/pull/4663
57 2014-08-18 11:58:55 <wumpus> going to submit a pull that reverts that to test
58 2014-08-18 12:20:06 <jgarzik> wumpus, not failing for me locally... and qt tests pass. just non-qt tests fail, in the pull tester.
59 2014-08-18 12:20:19 <michagogo> wumpus: I'll build and test, if you want
60 2014-08-18 12:20:22 <jgarzik> wumpus, make sure you restart pull tester
61 2014-08-18 12:24:42 <jgarzik> wumpus, (sipa stopped it)
62 2014-08-18 12:24:50 <jgarzik> wumpus, also, in theory, you can run the .jar locally
63 2014-08-18 12:25:04 <jgarzik> ACTION has never done so... but needs to set that up
64 2014-08-18 12:25:45 <michagogo> How do you run the tests again?
65 2014-08-18 12:27:51 <jgarzik> michagogo, an excellent question
66 2014-08-18 12:28:22 <michagogo> Well, do you know the answer?
67 2014-08-18 12:28:24 <jgarzik> no
68 2014-08-18 12:29:05 <jgarzik> if USE_COMPARISON_TOOL
69 2014-08-18 12:29:06 <jgarzik> check-local:
70 2014-08-18 12:29:41 <jgarzik> --with-comparison-tool path to java comparison tool (requires
71 2014-08-18 12:29:42 <jgarzik> --enable-tests)
72 2014-08-18 12:30:02 <jgarzik> so, enable at configure time, point to jar, "make check"
73 2014-08-18 12:30:14 <michagogo> ah, `make check`
74 2014-08-18 12:30:21 <michagogo> That sounds familiar
75 2014-08-18 12:30:39 <michagogo> Testsuite summary for Bitcoin Core 0.9.99
76 2014-08-18 12:30:40 <michagogo> ============================================================================
77 2014-08-18 12:30:40 <michagogo> # PASS: 1
78 2014-08-18 12:30:40 <michagogo> # TOTAL: 1
79 2014-08-18 12:31:01 <jgarzik> michagogo, yes. --with-comparison-tool adds moar tests to "make check"
80 2014-08-18 12:36:25 <wumpus> if it is what I think it is, checking it locally won't help (this looks like a specific problem with the ancient boost on the pulltester machine)
81 2014-08-18 12:40:39 <wumpus> I've logged into the pull tester machine, how do I start the pull tester?
82 2014-08-18 12:40:50 <wumpus> 'jenkins' is still running
83 2014-08-18 12:47:19 <sipa> wumpus: pulltester is a python or shell script that runs in a while loop in a command line in screen
84 2014-08-18 12:47:30 <sipa> there's some readme somewhere
85 2014-08-18 12:47:58 <sipa> sorry, on mobile 2g connection from a train now, ssh'ing is a bit annoying
86 2014-08-18 12:47:58 <wumpus> ah yes I remember now
87 2014-08-18 12:50:18 <wumpus> ugh, There is no screen to be attached
88 2014-08-18 12:51:14 <sipa> i probably deleted it by closing the last window in ot
89 2014-08-18 13:58:18 <Luke-Jr> sigh, master doesn't build -.-
90 2014-08-18 13:58:51 <Luke-Jr> http://0bin.net/paste/CGGnLnX5NlpHNOId#eBYHhmakZtmYV+lp5APYlsKe2ei+zmB9hDVdBiy02Gv
91 2014-08-18 13:59:17 <wumpus> ...huh?
92 2014-08-18 13:59:40 <wumpus> since when do you get that? there have been no recent changes to that part of the code afaik
93 2014-08-18 14:01:01 <Luke-Jr> wumpus: I don't build master on a regular basis, so I'll have to bisect
94 2014-08-18 14:01:11 <wumpus> would have to make sense to use quint64 there, though
95 2014-08-18 14:01:19 <wumpus> -have to
96 2014-08-18 14:01:43 <Luke-Jr> not sure about C++, but in C it's invalid to use uint64_t unless <stdint.h> is included
97 2014-08-18 14:02:58 <wumpus> can you try this patch http://paste.ubuntu.com/8080175/
98 2014-08-18 14:04:06 <Luke-Jr> wtf @ having to login
99 2014-08-18 14:04:08 <wumpus> probably also the case in C++, but on other systems it appears that uint64_t is included indirectly, you're the first to report this (and that code already exists for a whiel)
100 2014-08-18 14:04:34 <wumpus> Luke-Jr: huh you have to login for that pastebin?
101 2014-08-18 14:04:46 <Luke-Jr> yes
102 2014-08-18 14:04:51 <Luke-Jr> and I can't curl it to patch :/
103 2014-08-18 14:05:34 <wumpus> my build system is completely messed up at the moment
104 2014-08-18 14:05:41 <wumpus> I'll submit a pull later after I've tested itmyself
105 2014-08-18 14:05:42 <Luke-Jr> at least that file builds with the patch
106 2014-08-18 14:07:37 <michagogo> 16:58:19 <Luke-Jr> sigh, master doesn't build -.- <-- It did for me a couple hours ago
107 2014-08-18 14:08:08 <michagogo> Also, I don't seem to have to login for that pastebin
108 2014-08-18 14:09:02 <michagogo> Oh, I'm building without the GUI, nvm
109 2014-08-18 14:09:28 <wumpus> well I build with the gui and it wasn't broken for me either
110 2014-08-18 14:09:53 <wumpus> somehow the system or qt include files on luke-jr's machine are somewhat different
111 2014-08-18 14:18:57 <wumpus> Luke-Jr: with that change it compiles succesfully?
112 2014-08-18 14:19:10 <Luke-Jr> yes
113 2014-08-18 14:19:18 <wumpus> ok, thanks
114 2014-08-18 14:19:20 <Luke-Jr> that file does; full build is still going
115 2014-08-18 14:20:18 <Luke-Jr> (I did make clean in the meantime)
116 2014-08-18 14:25:12 <jgarzik> wumpus, sipa: did pull tester get re-enabled to check #4722?
117 2014-08-18 14:25:53 <sipa> still travelling, sorry
118 2014-08-18 14:28:18 <wumpus> I still haven't found out how to do it
119 2014-08-18 14:31:17 <wumpus> ah, finally found where it is, in /mnt!
120 2014-08-18 14:31:29 <jgarzik> of course it is ;p
121 2014-08-18 14:34:16 <Luke-Jr> wumpus: build finished success
122 2014-08-18 14:35:13 <Luke-Jr> cfields: wumpus: any idea why Bitcoin-Qt is being linked with an Objective C++ compiler on non-Mac? O.o
123 2014-08-18 14:35:44 <jgarzik> there is no such thing as Objective C++ ;p
124 2014-08-18 14:35:44 <wumpus> Luke-Jr: no idea, it works fine for me and I don't have any objective c stuff on my system at all
125 2014-08-18 14:35:57 <Luke-Jr> jgarzik: automake calls it OBJCXXLD :p
126 2014-08-18 14:36:14 <wumpus> isn't that just the c++ linker?
127 2014-08-18 14:36:39 <wumpus> automake has strange names, I'd look at the actual command being executed
128 2014-08-18 14:38:31 <Luke-Jr> https://www.gnu.org/software/autoconf/manual/autoconf-2.68/html_node/Objective-C_002b_002b-Compiler.html
129 2014-08-18 14:46:27 <gavinandresen> wumpus: I'm around and can help to fix the pull-tester if needed
130 2014-08-18 14:47:14 <jgarzik> ACTION ^5's wumpus
131 2014-08-18 14:48:34 <wumpus> thanks, but I think I'm fine, and already found out how to do it (the clue was mostly where to look :-)
132 2014-08-18 14:48:58 <wumpus> it's running on pull #4722
133 2014-08-18 14:50:38 <wumpus> ah, passed
134 2014-08-18 14:52:10 <jgarzik> that's what I was ^5'ing ;p
135 2014-08-18 14:52:53 <jgarzik> emantics of FreeBSD and OpenBSD make conflict with this). In case of doubt you may want to require to use GNU make, or work around the issue with inference rules to generate the tests.
136 2014-08-18 14:52:53 <jgarzik> Please note that it is currently not possible to use $(srcdir)/ or $(top_srcdir)/ in the TESTS variable. This technical limitation is necessary to avoid generating test logs in the source tree and has the unfortunate consequence that it is not possible to specify distributed tests that are themselves generated by means of explicit rules, in a way that is portable to all make implementations (see Make Target Lookup in The Autoconf Manual, the s
137 2014-08-18 14:53:02 <jgarzik> ACTION nukes automaker from orbit
138 2014-08-18 14:54:16 <wumpus> UGH
139 2014-08-18 14:55:00 <jgarzik> ACTION has to create test-driver.{sh,py}.in and perform substitutions
140 2014-08-18 14:55:45 <jgarzik> wumpus, I think python will probably the eventual best test driver, in that case
141 2014-08-18 14:55:53 <jgarzik> off to figure out how to exec() stuff in python...
142 2014-08-18 14:55:59 <wumpus> jgarzik: subprocess :)
143 2014-08-18 14:57:16 <wumpus> easiest is to use .call(), but as you need other functionality such as redirecting the input/output, the Popen class is most flexible (use .communicate() to get the stdout and stderr output)
144 2014-08-18 14:57:20 <wumpus> ok the pull tester is on the loose again
145 2014-08-18 14:57:41 <wumpus> let's hope it passes the other pulls now
146 2014-08-18 14:58:28 <jgarzik> wumpus, ideally want strings for stdin/stdout/stderr rather than file handles
147 2014-08-18 14:58:47 <wumpus> jgarzik: yes, that's what communicate() does, it just accumulates everything into a string
148 2014-08-18 14:59:11 <wumpus> (well, two strings, one for stdout and one for stderr)
149 2014-08-18 15:00:00 <jgarzik> wumpus, communicate also seems to work for input. ok.
150 2014-08-18 15:00:15 <wumpus> yes
151 2014-08-18 18:43:30 <jgarzik> cfields, odd
152 2014-08-18 18:44:12 <jgarzik> when executing "make check" from $HOME/repo/bitcoin, the script reports CWD == $HOME/repo/bitcoin/src and TOP_SRCDIR=../..
153 2014-08-18 19:35:08 <wumpus> $PWD is always in the src directory
154 2014-08-18 19:35:24 <wumpus> as that's where the 'real' makefile is based which includes the rest
155 2014-08-18 19:35:43 <cfields> right
156 2014-08-18 19:35:52 <wumpus> but yes it's strange that the $srcdir is not relative to it :p
157 2014-08-18 19:36:09 <cfields> Luke-Jr: what's this about linking with objcxx ?
158 2014-08-18 19:36:45 <Luke-Jr> cfields: everything is linked with CXXLD except bitcoin-qt which gets OBJCXXLD
159 2014-08-18 19:37:19 <cfields> hmm, seems i missed out on lots of build-related fun this morning. anything still up in the air?
160 2014-08-18 19:37:21 <cfields> Luke-Jr: looking
161 2014-08-18 19:37:57 <wumpus> cfields: we had to revert the reduce exports pull, as it was still causing the pull tester to fail
162 2014-08-18 19:38:53 <moa> Luke-Jr: it's because of the two .mm mac uses ... set OBJCXX=clang++
163 2014-08-18 19:39:08 <cfields> wumpus: grr, ok
164 2014-08-18 19:39:35 <moa> env variable that is
165 2014-08-18 19:40:12 <Luke-Jr> moa: I'm not building for Mac
166 2014-08-18 19:40:22 <moa> oh, sori
167 2014-08-18 19:40:33 <Luke-Jr> though that's likely related I guess
168 2014-08-18 19:40:40 <moa> i saw same thing on mac
169 2014-08-18 19:40:49 <moa> what are you on?
170 2014-08-18 19:40:54 <cfields> wumpus: erm, wrong url? i don't see mention of visibility there
171 2014-08-18 19:41:58 <cfields> Luke-Jr: "CXXLD qt/bitcoin-qt"
172 2014-08-18 19:42:04 <cfields> you're seeing OBJCXXLD ?
173 2014-08-18 19:43:20 <Luke-Jr> cfields: yes
174 2014-08-18 19:43:24 <wumpus> cfields: where?
175 2014-08-18 19:43:25 <Luke-Jr> moa: Linux
176 2014-08-18 19:43:42 <cfields> wumpus: from your comment on that PR: http://jenkins.bluematt.me/pull-tester/p4718_88fe88cf3640caede5222380383d0816a42a73b7/test.log
177 2014-08-18 19:43:42 <Luke-Jr> OBJCXXLD qt/bitcoin-qt
178 2014-08-18 19:43:45 <wumpus> cfields: anyhow pulltester failed, reverted the pull, and it worked again
179 2014-08-18 19:43:57 <cfields> wumpus: understood, just trying to see why it failed
180 2014-08-18 19:44:30 <moa> Luke-Jr: clang?
181 2014-08-18 19:44:37 <wumpus> cfields: I remember it was correctly logging in configure output the warning about the boost version
182 2014-08-18 19:45:41 <wumpus> cfields: but in the compile output there were still the default visibility flags
183 2014-08-18 19:45:55 <wumpus> cfields: seems that got overwriiten by the pull tester; it succeeds now
184 2014-08-18 19:46:14 <cfields> ok, trying to track it down
185 2014-08-18 19:46:23 <wumpus> cfields: easiest way to find out would be to re-submit the pull
186 2014-08-18 19:48:20 <cfields> ok, i found one
187 2014-08-18 19:50:25 <cfields> Luke-Jr: will have a look after fixing the exports
188 2014-08-18 19:51:12 <cfields> wumpus: aha dammit, i reordered the checks at the last minute. will PR a fix
189 2014-08-18 19:51:15 <Luke-Jr> cfields: k, it doesn't actually cause a problem (for me), just an observation
190 2014-08-18 19:51:29 <cfields> wumpus: want me to re-revert, or just a clean do-over ?
191 2014-08-18 19:51:54 <wumpus> Luke-Jr: indeed, it doesn't actually cause problems, for example it buidls fine without a objective c compiler on the system
192 2014-08-18 19:52:37 <cfields> well, objcxx will almost always == cxx
193 2014-08-18 19:52:37 <wumpus> cfields: you could cherry-pick your old commit, or indeed revert the revert, I don't think it makes much difference
194 2014-08-18 19:52:43 <cfields> but it should be fixed nonetheless
195 2014-08-18 19:52:48 <cfields> ok
196 2014-08-18 19:53:11 <cfields> sorry about that, i had a feeling it'd give some trouble :\
197 2014-08-18 19:53:25 <wumpus> there was one minor conflict with another pull that affect configure.ac, but nothing serious
198 2014-08-18 19:53:54 <wumpus> cfields: also my fault, should have waited for the pull tester to actually confirm
199 2014-08-18 19:54:25 <cfields> wumpus: i'll have some sort of pull-tester ready to go this week. I'm tired of waiting on travis
200 2014-08-18 19:58:11 <wumpus> cfields: agreed
201 2014-08-18 19:58:59 <cfields> wumpus: i'm going to go ahead and push up the new gitian descriptors that use the depends system, but let's not merge until there's a tester in place to verify all of em, please
202 2014-08-18 19:59:29 <cfields> i've held off on pushing for that reason, but now since there are a few PRs regarding descriptors, it makes sense to start reviewing those i think
203 2014-08-18 20:01:24 <wumpus> well if you mention it's a WIP that will make sure it will not be merged
204 2014-08-18 20:01:38 <cfields> ok
205 2014-08-18 20:02:21 <sipa> if things that aren't ready to be merged get merged, there is a problem with our review process...
206 2014-08-18 20:02:43 <wumpus> cfields: AFAIK the only other pull regarding the gitian descriptors is the openssl upgrade
207 2014-08-18 20:02:55 <wumpus> sipa: is that the case?
208 2014-08-18 20:03:01 <sipa> wumpus: not that i know
209 2014-08-18 20:03:41 <cfields> wumpus: there's the visibility change as well (remove the linker script) that's superceded by the new descriptors
210 2014-08-18 20:04:12 <wumpus> cfields: and this one doesn't seem to be critical, so it's low priority
211 2014-08-18 20:04:22 <cfields> sure
212 2014-08-18 20:05:06 <sipa> wumpus: i'm just saying that if we trust our review process, we don't need to worry about WIP things accidentally getting merged
213 2014-08-18 20:05:06 <wumpus> cfields: didn't know that you already submitted a pull for that
214 2014-08-18 20:05:41 <wumpus> sipa: agreed
215 2014-08-18 20:12:13 <cfields> wumpus: on #4624, did you replace $TOP_SRCDIR/src with $srcdir as i did in the patch? or did you just switch vars?
216 2014-08-18 20:14:56 <wumpus> cfields: I just replaced the var
217 2014-08-18 20:16:36 <cfields> wumpus: right, that wouldn't run from the correct path then :)
218 2014-08-18 20:20:13 <cfields> jgarzik: are you sure about your paths above? CWD should indeed be "$HOME/repo/bitcoin/src", but TOP_SRCDIR should be "./.."
219 2014-08-18 20:20:57 <jgarzik> cfields, yes certain. That's why the tests failed when using @top_srcdir@
220 2014-08-18 20:21:16 <jgarzik> cfields, removed one period, resulting in the string you pasted, and it worked.
221 2014-08-18 20:21:51 <jgarzik> cfields, changed to @srcdir@ to get it working without manual intervention, but 'distcheck' still fails for as-yet-unknown reasons.
222 2014-08-18 20:22:15 <cfields> jgarzik: distcheck will likely be failing because a file wasn't added to the dist tarball
223 2014-08-18 20:22:24 <cfields> EXTRA_DIST
224 2014-08-18 20:22:47 <cfields> sec, let me see if i can find your tree from before your last rebase
225 2014-08-18 20:23:17 <jgarzik> cfields, the entire pull was rewritten into python since the last rebase ;p
226 2014-08-18 20:23:42 <cfields> jgarzik: heh, i know. but that's all unnecessary if the paths work as intended, no?
227 2014-08-18 20:23:55 <sipa> "i replaced the pull request by a script that applies some git patches"
228 2014-08-18 20:24:12 <jgarzik> cfields, I would not have coded it, were it unnecessary
229 2014-08-18 20:24:15 <jgarzik> ;p
230 2014-08-18 20:24:16 <sipa> (that's how i read "the entire pull was rewritten into python"
231 2014-08-18 20:24:40 <cfields> jgarzik: well it looked like you added a python test harness (adding the .in) to work around the fact that the paths weren't working
232 2014-08-18 20:24:55 <jgarzik> cfields, wumpus originally suggested a python test harness as superior. He is right.
233 2014-08-18 20:25:05 <jgarzik> cfields, it was rewritten to be more flexible, and fix that old bug.
234 2014-08-18 20:25:30 <jgarzik> python permits easier addition of new tests, including multi-execution paths + output compare
235 2014-08-18 20:25:42 <wumpus> right
236 2014-08-18 20:26:33 <cfields> erm, ok
237 2014-08-18 20:27:00 <jgarzik> if I am doing anything remotely complex, I do not want to do it in a language that lacks [] and {}
238 2014-08-18 20:27:13 <jgarzik> (lists and maps)
239 2014-08-18 20:27:24 <jgarzik> shell script just sucks as a language
240 2014-08-18 20:27:29 <wumpus> absolutely
241 2014-08-18 20:27:47 <cfields> jgarzik: understood and agreed. It's just a shame that we rely on so many runtimes for our tests
242 2014-08-18 20:27:54 <cfields> that's going to bite us at some point
243 2014-08-18 20:27:56 <wumpus> it's also very hard to write anything robust with regard to error handling in shell script
244 2014-08-18 20:28:00 <jgarzik> cfields, get rid of java then ;p
245 2014-08-18 20:28:02 <cfields> sh/python/java/c++
246 2014-08-18 20:28:10 <wumpus> requiring python is acceptable
247 2014-08-18 20:28:11 <jgarzik> java is the real problem.
248 2014-08-18 20:28:26 <sipa> yes, let's get rid of java :)
249 2014-08-18 20:28:27 <jgarzik> I've been wanting to rewrite regtests into C++ anyway
250 2014-08-18 20:28:37 <sipa> regtests?
251 2014-08-18 20:28:43 <jgarzik> well, C++ and a domain specific language
252 2014-08-18 20:28:59 <cfields> heh, before this goes any further, i wasn't arguing against python in any way, just grumping a little
253 2014-08-18 20:28:59 <gmaxwell> the advantage of the java is that its a seperate implementation, so it's always doing an interworking test.
254 2014-08-18 20:29:00 <jgarzik> the current java-based regression tests
255 2014-08-18 20:29:14 <sipa> jgarzik: i was thinking about python + dsl
256 2014-08-18 20:29:19 <gmaxwell> I don't think the blocktester should be just testing the same code against itself.
257 2014-08-18 20:29:26 <jgarzik> sipa, ok :)
258 2014-08-18 20:29:33 <gmaxwell> python is fine.
259 2014-08-18 20:29:34 <sipa> exactly for the reason that gmaxwell says
260 2014-08-18 20:29:58 <sipa> in c++ it would either use a copy of part of the code being tested, or require a silly rewrite of it
261 2014-08-18 20:30:10 <sipa> and python p2p libraries already exist
262 2014-08-18 20:30:30 <TheRelic> i am putting out a BOUNTY if you are capable of creating your own alt coin, PLEASE PRIVATE MESSAGE ME FOR MORE INFO you will get PAID UPFRONT.
263 2014-08-18 20:30:38 <sipa> TheRelic: not here
264 2014-08-18 20:31:30 <jgarzik> cfields, to return to OP, the python rewrite is desirable even if in absence of prior bugs
265 2014-08-18 20:31:41 <cfields> jgarzik: ok, np then
266 2014-08-18 20:31:50 <cfields> jgarzik: i'm working on your distcheck problem atm. building.
267 2014-08-18 20:32:21 <jgarzik> cfields, make sure you have 503524c with EXTRA_DIST fixes
268 2014-08-18 20:32:28 <Adlai> if you're willing to write your own shitcoin, i'll put a bounty on your head
269 2014-08-18 20:32:31 <Adlai> /s
270 2014-08-18 20:32:53 <cfields> jgarzik: oh, did that fix distcheck? or still something else?
271 2014-08-18 20:33:02 <jgarzik> cfields, distcheck still broken
272 2014-08-18 20:33:05 <cfields> ok
273 2014-08-18 20:34:23 <cfields> wumpus: if it's any consolation for all of the build trouble lately, I think i'm pretty much done messing with stuff now :)
274 2014-08-18 20:35:02 <cfields> the last few weeks i've been trying to get us to the point where ci builds can be on par with gitian, and that's done now (as soon as the fixed up visibility thing goes in)
275 2014-08-18 20:37:46 <wumpus> that's great :)
276 2014-08-18 20:37:58 <jgarzik> cfields, P.S. I'm pondering doing the substitution in bitcoin-util-test.py rather than bctest.py
277 2014-08-18 20:38:16 <jgarzik> pass the test dir to the module, rather than have the bctest module Know the dir
278 2014-08-18 20:43:45 <lifeofcray> test
279 2014-08-18 20:43:48 <lifeofcray> awesome
280 2014-08-18 20:43:50 <lifeofcray> anyways
281 2014-08-18 20:44:04 <lifeofcray> i just built my very own bitcoin client
282 2014-08-18 20:44:09 <lifeofcray> it was an ordeal but i made it :D
283 2014-08-18 20:45:08 <lifeofcray> anywho, i was wondering
284 2014-08-18 20:45:24 <lifeofcray> what's the share/pixmaps for?
285 2014-08-18 20:45:39 <sipa> it contains images
286 2014-08-18 20:46:32 <lifeofcray> haha yeah i know
287 2014-08-18 20:46:41 <lifeofcray> wondering more where in the program they're being used
288 2014-08-18 20:47:32 <sipa> all over the gui?
289 2014-08-18 20:47:59 <sipa> icons etc
290 2014-08-18 20:54:03 <cfields> jgarzik: ok, i see your problem. It's complicated by the fact that bctest.py is generated
291 2014-08-18 20:54:21 <cfields> generated files go into buliddir as opposed to srcdir (srcdir is intended to be read-only)
292 2014-08-18 20:55:25 <jgarzik> cfields, hmmm. should probably snarf $srcdir out of the env, if it's there.
293 2014-08-18 20:55:37 <cfields> jgarzik: very much so :)
294 2014-08-18 20:55:49 <cfields> unless more vars are needed, it'd make life much easier to do it that way
295 2014-08-18 20:56:38 <cfields> you can do it with the generated files, you'll just have to keep up with which ones end up in which places
296 2014-08-18 20:56:47 <lifeofcray> sipa i though that was src/qt/res/icons?
297 2014-08-18 20:57:37 <cfields> jgarzik: i'm happy to fix it up for you whichever way you'd prefer, so you don't have to spend the time on it
298 2014-08-18 21:00:06 <jgarzik> cfields, I'm on it
299 2014-08-18 21:00:23 <lifeofcray> ah, it's for the debian qt?
300 2014-08-18 21:00:29 <cfields> ok
301 2014-08-18 21:01:52 <cfields> Luke-Jr: interesting...
302 2014-08-18 21:02:05 <Luke-Jr> cfields: ?
303 2014-08-18 21:02:18 <cfields> Luke-Jr: libbase58
304 2014-08-18 21:02:19 <Luke-Jr> ah
305 2014-08-18 21:02:37 <cfields> Luke-Jr: secp got me thinking. I bet we could come up with an automake file that could be used as a standalone, or by a parent project
306 2014-08-18 21:02:57 <cfields> so that either project could just "include" it as necessary
307 2014-08-18 21:03:33 <cfields> Luke-Jr: if that were the case, would you be willing to maintain it in a way that was compatible with both scenarios ?
308 2014-08-18 21:03:41 <Luke-Jr> yeah, that's builtin to automake, but it only supports it by passing the exact same configure flags to all the child configures
309 2014-08-18 21:03:46 <jgarzik> ACTION loads up some DISTCHECK_CONFIGURE_FLAGS to smack BDB around a bit
310 2014-08-18 21:03:55 <Luke-Jr> cfields: the libbase58 automake stuff is all standard
311 2014-08-18 21:04:18 <jgarzik> meta-automake :)
312 2014-08-18 21:04:36 <cfields> Luke-Jr: understood. i have in mind something a bit different, a bit hard to explain
313 2014-08-18 21:04:53 <Luke-Jr> just the embedding it in the parent project whilest having separate configure flags (ie, to pass -fPIC and --disable-shared) needed some hacky stuff
314 2014-08-18 21:05:52 <cfields> Luke-Jr: i'll work on a POC. Ideally, we'd solve these the same way so hacks can be shared (libsecp256k1, libbase58, whatever else comes...)
315 2014-08-18 21:06:39 <Luke-Jr> cfields: it'd be pretty simple to make a m4 macro for the hack I have there; I don't know if it satisfies your differences-use-case though, as I don't understand what you're wanting there
316 2014-08-18 21:07:25 <cfields> Luke-Jr: to expand a bit, i'm looking to make it so that if it's one of our known subprojects (say libbase58 in this case), we don't actually configure the subdir, we just include a custom Makefile.am that includes the bits we need
317 2014-08-18 21:07:39 <cfields> but if you're building libbase58 as its own project, you'd configure it as usual
318 2014-08-18 21:08:45 <Luke-Jr> hm, wouldn't that basically be the same as a non-recursive makefile in a parent dir? ie, even if the subdir has a Makefile (from an independent build), ignore it
319 2014-08-18 21:09:28 <cfields> yes, pretty much. but you have to make the projects compatible enough for that to work
320 2014-08-18 21:09:58 <cfields> sharing some of the same vars and practices
321 2014-08-18 21:11:26 <cfields> imo that'd be a cleaner way to handle it, if you'd be up for going that route
322 2014-08-18 21:13:12 <Luke-Jr> well, picking and choosing pieces kinda implies the master project needs to be aware of the structure of the child projects anyway
323 2014-08-18 21:13:52 <jgarzik> cfields, that fixed it locally, thanks for spotting. let's hope pull tester likes it.
324 2014-08-18 21:14:14 <cfields> jgarzik: np
325 2014-08-18 21:15:00 <cfields> Luke-Jr: well, when using chained configure, lots of new issues crop up. 'make dist' becomes a nasty problem with only nasty solutions. same for 'make clean'
326 2014-08-18 21:15:32 <cfields> i was hoping to move away from that rather than deeper into it
327 2014-08-18 21:21:03 <cfields> wumpus: still around? seems pull-tester's dead again. and your clues above for restarting it are rather cryptic :p
328 2014-08-18 21:21:08 <BlueMatt> gavinandresen: when I mentioned the relay node client does not forward transactions to the local bitcoind, I was wrong
329 2014-08-18 21:21:16 <BlueMatt> two lines of source is easy to forget :)
330 2014-08-18 21:21:38 <cfields> i assume it's "/mnt/pull-tester.py", but i'm hesitant to run that without confirmation
331 2014-08-18 21:21:44 <cfields> ah, BlueMatt. ^^ posed to you
332 2014-08-18 21:21:50 <BlueMatt> cfields: isnt it in a screen session?
333 2014-08-18 21:21:55 <BlueMatt> cant you just go up and run again?
334 2014-08-18 21:22:02 <cfields> dunno
335 2014-08-18 21:22:07 <gavinandresen> should be a root-owned screen session....
336 2014-08-18 21:22:15 <gavinandresen> ⦠but maybe wumpus ran it a different way
337 2014-08-18 21:22:55 <BlueMatt> screen is not running :(
338 2014-08-18 21:23:05 <cfields> would one of you mind restarting then? i don't see any processes with "test" or "python" in em
339 2014-08-18 21:23:26 <sipa> it's running again
340 2014-08-18 21:23:46 <cfields> thanks
341 2014-08-18 21:23:49 <sipa> testing 4726
342 2014-08-18 21:29:08 <sipa> cfields: i'm trying to make secp256k1 tests and bench not include the .a library
343 2014-08-18 21:29:30 <sipa> but then it needs the compiled asm too, which it somehow doesn't get
344 2014-08-18 21:30:07 <cfields> sipa: ah right, sorry for dropping that one. Pretty sure I got lost in trying to over-solve it as usual :)
345 2014-08-18 21:31:11 <sipa> cfields: https://github.com/sipa/secp256k1/commit/2b9871e199885d554e3a7fb502f27fccfd7eb591
346 2014-08-18 21:31:16 <sipa> any idea why that doesn't work/
347 2014-08-18 21:31:41 <sipa> (even if it would work, not intended as a clean solution; just trying to make it do what i want...)
348 2014-08-18 21:32:39 <sipa> /bin/bash ./libtool --tag=CC --mode=link gcc -std=gnu99 -g -O2 -static -o tests tests-tests.o -lgmp -lcrypto
349 2014-08-18 21:32:42 <sipa> libtool: link: gcc -std=gnu99 -g -O2 -o tests tests-tests.o -lgmp -lcrypto
350 2014-08-18 21:32:57 <cfields> sipa: not sure off the top of my head, will have a look in a min
351 2014-08-18 21:58:29 <cfields> sipa: ok, quick hack..
352 2014-08-18 21:59:02 <cfields> sipa: towards the end of Makefile.am. .asm.lo -> .asm.o
353 2014-08-18 21:59:14 <cfields> I'm investigating the correct fix.
354 2014-08-18 22:18:51 <sipa> jgarzik: mind having another look at 4618?
355 2014-08-18 23:50:52 <cfields> sipa: http://pastebin.com/raw.php?i=6mxZSHEc
356 2014-08-18 23:51:16 <cfields> that goes on top of 8b5cdc46
357 2014-08-18 23:57:24 <gmaxwell> phantomcircuit: you may be interested in https://github.com/bitcoin/bitcoin/pull/4723