1 2016-06-03 06:18:52 0|GitHub68|[13bitcoin] 15pstratem opened pull request #8142: Improve CWallet API with new GetAccountPubkey function. (06master...062016-06-02-cwallet-getaccountpubkey) 02 https://github.com/bitcoin/bitcoin/pull/8142
2 2016-06-03 06:54:01 0|GitHub160|13bitcoin/06master 14f45f51e 15Pieter Wuille: Fix interrupted HTTP RPC connection workaround for Python 3.5+
3 2016-06-03 06:54:01 0|GitHub160|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/a82f03393a32...ae5575ba41c8
4 2016-06-03 06:54:02 0|GitHub160|13bitcoin/06master 14ae5575b 15MarcoFalke: Merge #8139: Fix interrupted HTTP RPC connection workaround for Python 3.5+...
5 2016-06-03 06:54:11 0|GitHub177|[13bitcoin] 15MarcoFalke closed pull request #8139: Fix interrupted HTTP RPC connection workaround for Python 3.5+ (06master...06fixwalletbackup) 02 https://github.com/bitcoin/bitcoin/pull/8139
6 2016-06-03 11:37:13 0|MarcoFalke|Why is travis not picking up any pulls?
7 2016-06-03 11:58:27 0|MarcoFalke|temporarily down, apparently. Working again...
8 2016-06-03 12:00:40 0|phantomcircuit|MarcoFalke, the docker repo is broken
9 2016-06-03 12:00:47 0|phantomcircuit|https://github.com/docker/docker/issues/23203
10 2016-06-03 12:00:53 0|phantomcircuit|also dat issue number
11 2016-06-03 13:30:01 0|GitHub175|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/ae5575ba41c8...c141c14c9f5f
12 2016-06-03 13:30:02 0|GitHub175|13bitcoin/06master 14719de56 15Kaz Wesley: lock cs_main for chainActive...
13 2016-06-03 13:30:02 0|GitHub175|13bitcoin/06master 14efb54ba 15Kaz Wesley: lock cs_main for State/Misbehaving...
14 2016-06-03 13:30:03 0|GitHub175|13bitcoin/06master 14c141c14 15Wladimir J. van der Laan: Merge #7942: locking for Misbehave() and other cs_main locking fixes...
15 2016-06-03 13:30:11 0|GitHub84|[13bitcoin] 15laanwj closed pull request #7942: locking for Misbehave() and other cs_main locking fixes (06master...06locking) 02 https://github.com/bitcoin/bitcoin/pull/7942
16 2016-06-03 13:48:08 0|GitHub142|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/c141c14c9f5f...8c1e49ba13a8
17 2016-06-03 13:48:09 0|GitHub142|13bitcoin/06master 1404eaa90 15Jonas Schnelli: Add more clear interface for CoinControl.h regarding individual feerate
18 2016-06-03 13:48:09 0|GitHub142|13bitcoin/06master 143b35e48 15Jonas Schnelli: [RPC] add feerate option to fundrawtransaction
19 2016-06-03 13:48:10 0|GitHub142|13bitcoin/06master 148c1e49b 15Wladimir J. van der Laan: Merge #7967: [RPC] add feerate option to fundrawtransaction...
20 2016-06-03 13:48:15 0|GitHub162|[13bitcoin] 15laanwj closed pull request #7967: [RPC] add feerate option to fundrawtransaction (06master...062016/04/fund_fee) 02 https://github.com/bitcoin/bitcoin/pull/7967
21 2016-06-03 13:53:54 0|GitHub157|[13bitcoin] 15fanquake closed pull request #8119: [trivial] Add .DSYM to .gitignore (06master...06ignore_debug) 02 https://github.com/bitcoin/bitcoin/pull/8119
22 2016-06-03 13:56:08 0|GitHub35|[13bitcoin] 15laanwj closed pull request #7995: main: Make version bits GUI warning clearer to translators (06master...062016_05_minor_message_change) 02 https://github.com/bitcoin/bitcoin/pull/7995
23 2016-06-03 13:57:43 0|sipa|\o/ 4 pages of pull requests
24 2016-06-03 14:00:24 0|wumpus|:o
25 2016-06-03 14:02:53 0|wumpus|luke-jr: I disagree with #8132, we should be adding backwards compatibility code for pulls that were never merged. Also this creates a downward spiral, making it harder and harder to merge because more code is added to be compatible with older versions of the same pull request
26 2016-06-03 14:05:49 0|gmaxwell|I demand backwards compatiblity code for functionality I had in a dream.
27 2016-06-03 14:06:54 0|wumpus|definitely, that should be the next step
28 2016-06-03 14:07:06 0|wumpus|although it's a bit disconcerting that you dream about bitcoind functionality :)
29 2016-06-03 14:07:20 0|sipa|at least we should be backward compatible with the future features we envision!
30 2016-06-03 14:07:28 0|sipa|wait...
31 2016-06-03 14:08:14 0|gmaxwell|am I the only person here that dreams about Bitcoin?
32 2016-06-03 14:08:29 0|GitHub94|[13bitcoin] 15instagibbs opened pull request #8143: comment nit: miners don't vote (06master...06notavote) 02 https://github.com/bitcoin/bitcoin/pull/8143
33 2016-06-03 14:08:37 0|sipa|i don't usually remember my dreams
34 2016-06-03 14:08:52 0|gmaxwell|reorg?
35 2016-06-03 14:09:36 0|sipa|i guess a reorg is somewhat like a deja vu in the matrix
36 2016-06-03 14:09:58 0|instagibbs|replay attack maybe
37 2016-06-03 14:11:58 0|ozanyurt|hello can I ask key signing question here?
38 2016-06-03 14:12:19 0|sipa|is it related to bitcoin development?
39 2016-06-03 14:12:34 0|ozanyurt|no thanks :)
40 2016-06-03 14:12:47 0|ozanyurt|it is related to my bitcoin development
41 2016-06-03 14:13:56 0|sipa|this channel is about development of bitcoin core
42 2016-06-03 14:14:21 0|ozanyurt|ok
43 2016-06-03 14:14:49 0|instagibbs|ozanyurt, try #bitcoin
44 2016-06-03 14:15:13 0|ozanyurt|I will do, thanks
45 2016-06-03 14:24:34 0|Chris_Stewart_5|Are BIP141,143,144 finalized? Or is this witness program extra byte thing going to affect one of them?
46 2016-06-03 14:25:19 0|sipa|it affects 141
47 2016-06-03 14:26:16 0|sipa|oh, the limit is not included in bip141
48 2016-06-03 14:26:26 0|instagibbs|yes it is
49 2016-06-03 14:26:42 0|instagibbs|https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#witness-program
50 2016-06-03 14:27:03 0|sipa|oh yes
51 2016-06-03 14:29:42 0|Chris_Stewart_5|Thanks -- this is only a hardfork to testnet correct? I was tryign to follow the dev meeting yesterday
52 2016-06-03 14:37:06 0|sipa|jl2012: feel Chris_Stewart_5 indeed
53 2016-06-03 14:39:42 0|sipa|uh
54 2016-06-03 14:40:03 0|sipa|jl2012: feel like updating bip141 for the program size extension?
55 2016-06-03 14:40:10 0|sipa|Chris_Stewart_5: indeed
56 2016-06-03 14:50:15 0|Chris_Stewart_5|sipa: I have to say that is one of the strangest comments i've been tagged on in irc :-)
57 2016-06-03 14:50:45 0|sipa|you clearly need to spend more time on irc then
58 2016-06-03 14:50:48 0|sipa|:)
59 2016-06-03 14:52:24 0|instagibbs|so, will this relaxation only effect v1+?
60 2016-06-03 14:52:54 0|instagibbs|v0 explicitly restricts sizes to 20 and 32
61 2016-06-03 14:58:14 0|sipa|instagibbs: unnecessary complication to do that
62 2016-06-03 15:01:25 0|instagibbs|"do that" meaning to not do it for all versions?
63 2016-06-03 15:01:51 0|sipa|i mean: adding code to make it only affect v1+ would be unnecessarily hard
64 2016-06-03 15:02:13 0|sipa|if you mean whether a naive relaxation will only affect v1+? no
65 2016-06-03 15:02:21 0|instagibbs|yep thanks
66 2016-06-03 15:09:14 0|instagibbs|hm, so the bip is slightly misleading then, if v1-16 was actually size restricted for the witness to 32 bytes max
67 2016-06-03 15:10:01 0|sipa|A scriptPubKey (or redeemScript as defined in BIP16/P2SH) that consists of a 1-byte push opcode (for 0 to 16) followed by a data push between 2 and 32 bytes gets a new special meaning. The value of the first push is called the "version byte". The following byte vector pushed is called the "witness program".
68 2016-06-03 15:10:39 0|instagibbs|I know that, I'm reading later in the text, but I suppose it's actually no contradictory
69 2016-06-03 15:11:21 0|instagibbs|"If the version byte is 1 to 16, no further interpretation of the witness program or witness happens, and there is no size restriction for the witness."
70 2016-06-03 15:11:30 0|instagibbs|perhaps "no further size restriction"
71 2016-06-03 15:12:05 0|instagibbs|oh, witness, not program?
72 2016-06-03 15:12:18 0|instagibbs|not a big deal either way
73 2016-06-03 15:14:21 0|luke-jr|wumpus: gmaxwell: sipa: that one was merged in Knots, and therefore there are wallets in the wild using it.
74 2016-06-03 15:19:49 0|gmaxwell|how did my dreams end up in knots?
75 2016-06-03 15:21:01 0|wumpus|I've had dreams about bitcoin sometimes, though usually about things going wrong
76 2016-06-03 15:21:25 0|wumpus|luke-jr: I understand, but this is quite awkward
77 2016-06-03 15:21:50 0|btcdrak|knots is its own thing...
78 2016-06-03 15:22:25 0|wumpus|I just don't like merging the first version of something then already having to handle an older version of it; it's not like the wallet isn't enough of a mess as it is
79 2016-06-03 15:22:59 0|wumpus|so my question is, doesn't this backwards compatible logic belong in knots but not in bitcoin core?
80 2016-06-03 15:23:31 0|luke-jr|wumpus: depends on how badly it breaks Core to omit it
81 2016-06-03 15:24:33 0|wumpus|well I agree, though there's a limit up to what core will support other people's wallet changes
82 2016-06-03 15:24:44 0|wumpus|it shouldn't crash at least, agred
83 2016-06-03 15:24:51 0|wumpus|(or otherwise lose private keys)
84 2016-06-03 15:25:18 0|luke-jr|the only other possibility I see is it destroying the info, so crash/error seems the least problematic result
85 2016-06-03 15:25:48 0|luke-jr|whatever it is, downgrading would have the same effect, so probably should figure out what it is
86 2016-06-03 15:25:51 0|wumpus|what was the use case why you wanted to merge this so badly before it was finished?
87 2016-06-03 15:26:04 0|wumpus|this is more like sidegrading than downgrading though
88 2016-06-03 15:26:19 0|wumpus|downgrading to a version that doesn't support the functionality at all works
89 2016-06-03 15:26:21 0|luke-jr|there wasn't any reason at the time to see that it would be changed significantly. it had stagnated for months IIRC
90 2016-06-03 15:27:34 0|wumpus|in any case you made it more complex to merge because there's even more scenarios to consider
91 2016-06-03 15:29:02 0|luke-jr|it seems that is the result, yes
92 2016-06-03 15:31:51 0|wumpus|I do think we want the functionality, especially with deterministic wallets, we want to be able to detect if there's e.g. any imported keys
93 2016-06-03 15:32:26 0|luke-jr|unfortunately, foresight is not as good as hindsight; had I known it'd complicate things, I'd have held off - as you say, there was no great urgency
94 2016-06-03 15:33:01 0|wumpus|well it makes clear how careful we need to be with wallet format changes
95 2016-06-03 15:33:19 0|wumpus|if any little change needs to be supported forever, even if it never made it into an release
96 2016-06-03 15:34:10 0|luke-jr|I wonder if we should change the key storage to be like wtx, which uses a key/value map
97 2016-06-03 15:34:13 0|wumpus|that was kind of my reason to hold off on it a bit in the first place, I wanted to be sure not to introduce a problem like this where we'd need a second version
98 2016-06-03 15:34:56 0|wumpus|going from 8 to 32 bits seemed to be a good idea for future extensibility in that regard, although possilbly it's not needed I don't know...
99 2016-06-03 15:36:08 0|wumpus|I suppose we can always make a version 2 and add this migration code *IF* we need 32 bits
100 2016-06-03 15:36:19 0|gmaxwell|"now we can start packing data from the keys inthe version to save space!"
101 2016-06-03 15:36:23 0|wumpus|instead of doing an upgrade for something we're not sure we'll eer need
102 2016-06-03 15:36:40 0|luke-jr|hmm
103 2016-06-03 15:36:50 0|wumpus|ah I see jonasschnelli already proposes that
104 2016-06-03 15:37:38 0|sipa|i moved ctaes to bitcoin-core
105 2016-06-03 15:37:50 0|wumpus|gmaxwell: hah, I imagine that's what it was like in the 80's where every bit counted
106 2016-06-03 15:38:15 0|jonasschnelli|sipa: ack: +1
107 2016-06-03 15:38:18 0|wumpus|sipa: nice
108 2016-06-03 15:38:48 0|wumpus|8-bit bitfields even sounds very retro, maybe the bitcoind port to MSX can make progress now :)
109 2016-06-03 15:39:05 0|jonasschnelli|:-)
110 2016-06-03 15:39:33 0|sipa|we can stop treating the wallet encrypted keys as padded cbc, and get 12 of storage :p
111 2016-06-03 15:39:36 0|jonasschnelli|Yes. It was my "limited space" that made me use 8bit in the first place. We should really use 32bits for a such thing.
112 2016-06-03 15:40:08 0|jonasschnelli|BTW: is there a reason for not having a function to decrypt the wallet?
113 2016-06-03 15:40:15 0|jonasschnelli|I mean permanently decrypt.
114 2016-06-03 15:40:17 0|sipa|jonasschnelli: yes
115 2016-06-03 15:40:18 0|wumpus|jonasschnelli: just trying to avoid this awkward upgrade scenario
116 2016-06-03 15:40:27 0|wumpus|there should be no need to do that ever
117 2016-06-03 15:40:48 0|jonasschnelli|There is no upgrade scenario right now because we haven't merged anything regarding key-metadata
118 2016-06-03 15:40:55 0|sipa|jonasschnelli: if we'd design it from scratch, i think wallets would always be encrypted (though perhaps with an option to have an empty key)
119 2016-06-03 15:41:09 0|jonasschnelli|But I think a 32bit bitmap for key metadata could make sense for a wallet upgrade.
120 2016-06-03 15:41:22 0|jonasschnelli|Can be use to determin where the key came from, if it's HD generaded, etc.
121 2016-06-03 15:41:33 0|jonasschnelli|sipa: Good point.
122 2016-06-03 15:42:14 0|jonasschnelli|Should I take a second attempt use use LogDB for the wallet database?
123 2016-06-03 15:42:31 0|jonasschnelli|I have factored out logdb as a standalone C library: https://github.com/liblogdb/liblogdb
124 2016-06-03 15:42:57 0|jonasschnelli|So we could use a simple subset for bitcoin-core (not a subtree, more like 2-3 files like ctaes)
125 2016-06-03 15:43:52 0|jonasschnelli|I could even add callbacks for the hashing to avoid duplicated sha256 implementation.
126 2016-06-03 15:44:55 0|wumpus|I agree with sipa. Optionally allowing an empty key would be ok, it would still avoid some file system leaks
127 2016-06-03 15:45:46 0|jonasschnelli|Right. I also think we should support *full*-wallet-encryption.
128 2016-06-03 15:46:18 0|jonasschnelli|(require unlock of level 1 when staring Bitcoin-Qt/bitcoind)
129 2016-06-03 15:46:29 0|jonasschnelli|(require unlock for level 2 when signing stuff)
130 2016-06-03 15:46:30 0|luke-jr|(IMO wallet encryption is mostly a PR stunt from 2011, and we should focus on hardware wallet support.)
131 2016-06-03 15:46:40 0|jonasschnelli|luke-jr: +1.
132 2016-06-03 15:46:50 0|gmaxwell|I worry multiple passwords means the user will forget the signing one and not realize there are two.
133 2016-06-03 15:46:56 0|jonasschnelli|I once started to specify the "detached signing".
134 2016-06-03 15:47:08 0|gmaxwell|we really don't want to make the data loss worse from wallet encryption, I'd rather have it gone than that.
135 2016-06-03 15:47:08 0|jonasschnelli|Sadly there is no standard API for hardware wallets...
136 2016-06-03 15:47:44 0|jonasschnelli|gmaxwell: maybe the data loss is also because we don't offer a clear recovery-process during encryption.
137 2016-06-03 15:47:50 0|luke-jr|gmaxwell: could we have them be the same, and only cache the decryption key (not the passphrase) at runtime?
138 2016-06-03 15:48:01 0|jonasschnelli|Like allowing the user to write somthing down or print out a "backup" key or something.
139 2016-06-03 15:48:28 0|gmaxwell|I suggested an idea a while back that we just define an interface where we fork a process that speaks a bitcoin-core specific protocol to bitcoin... then speaks whatever the wallet needs to speak, and can open up UIs and whatnot.
140 2016-06-03 15:48:54 0|gmaxwell|e.g. signhardware=bobpocketwallet-qt.exe
141 2016-06-03 15:49:19 0|wumpus|I'm not sure about full wallet encryption, you can always store the wallet on an encrypted volume that's likely safer
142 2016-06-03 15:49:31 0|wumpus|(you can store your other secret files there too.)
143 2016-06-03 15:49:32 0|jonasschnelli|I was thinking after more torwards TCP/IP httpd interface
144 2016-06-03 15:49:51 0|wumpus|I doubt the bitcoin wallet metadata is the only metadata you'd want to hide
145 2016-06-03 15:49:52 0|jonasschnelli|signhardware=http://x:y@127.0.0.1:8888
146 2016-06-03 15:50:01 0|gmaxwell|wumpus: the model I like is where you use the signing key to derrive an access key (e.g. H(KDF(passphrase)) = viewkey) and then you simply save the viewkey on disk in a seperate file.
147 2016-06-03 15:50:02 0|wumpus|yes, support for hardware key storage and signing would be nice
148 2016-06-03 15:50:25 0|gmaxwell|wumpus: then if you backup/restore (e.g. to the 'cloud') you'll need to enter your passphrase once to unlock.
149 2016-06-03 15:50:36 0|wumpus|(or "isolated CPU conclave" if that's what you prefer)
150 2016-06-03 15:50:44 0|gmaxwell|but your backups are still confidential without extra steps.
151 2016-06-03 15:50:52 0|jonasschnelli|Each hdwallet could offer a tiny daemon (httpd) that listens for requested sign processes and build up a UI once a signing-request comes in.
152 2016-06-03 15:50:58 0|jl2012|sipa: what's the decision?
153 2016-06-03 15:51:02 0|jonasschnelli|hdwallet=hardwarewallet
154 2016-06-03 15:51:08 0|sipa|jl2012: 40 bytes
155 2016-06-03 15:51:18 0|gmaxwell|Yea, on your local meachine metadata privacy is almost totally pointless, your browser cache tells anyone with your computer almost anything you did with the bitcoin wallet.
156 2016-06-03 15:51:18 0|wumpus|gmaxwell: yes, that is a good idea.
157 2016-06-03 15:51:24 0|gmaxwell|but for backup it's useful.
158 2016-06-03 15:51:33 0|wumpus|two passwords is too much for most people
159 2016-06-03 15:51:48 0|jonasschnelli|Yes. That's true.
160 2016-06-03 15:51:58 0|jl2012|Ok, will do it tomorrow
161 2016-06-03 15:52:17 0|jonasschnelli|Maybe encrypting the disk is the way to go.
162 2016-06-03 15:52:19 0|wumpus|well the wallet encryption is for local security I suppose. Backups you'd certainly want fully encrypted, I agree
163 2016-06-03 15:52:28 0|wumpus|OTOH that doesn't need to be wallet.dat format
164 2016-06-03 15:53:01 0|gmaxwell|encrypting your disk is a great idea. I've encrypted all my disks since .. uh.. 1998? WD sent me back an RMA drive with someone elses data... often when a drive fails you can't zeroize it first.. sooo.
165 2016-06-03 15:53:37 0|gmaxwell|wumpus: thats true, wrt format.
166 2016-06-03 15:53:42 0|luke-jr|I prefer to encrypt only my sensitive data, so I can un-decrypt it when I step away
167 2016-06-03 15:54:10 0|wumpus|I encrypt my disks too, except for 'junk' partitions like where I store zillions of copies of the blockchain
168 2016-06-03 15:54:39 0|jonasschnelli|heh
169 2016-06-03 15:54:41 0|wumpus|I suppose with a newer CPU with encrypt/decrypt instructions the overhead is so low that you don't really care and just encrypt everything
170 2016-06-03 15:55:23 0|wumpus|(I do always encrypt swap with random key too)
171 2016-06-03 15:56:55 0|wumpus|in any case, for backups encrypting the full thing makes a lot of sense, certainly for cloud backups
172 2016-06-03 15:58:51 0|wumpus|dropbox must have a lot of wallet metadata
173 2016-06-03 16:01:03 0|luke-jr|for backups, definitely want to encrypt the whole thing IMO
174 2016-06-03 16:06:09 0|wumpus|yes
175 2016-06-03 16:06:37 0|wumpus|I just encrypt my entire backups so such functionality in bitcoind wouldn't help me much, but I guess some people would be helped by it
176 2016-06-03 16:11:37 0|gmaxwell|encrypting it is also good for metadata preservation, e.g. evenutally we could have some ftp or webdav or whatever kids uses these days, url in the config you could set to push a new backup every time your metadata changes.
177 2016-06-03 16:12:22 0|luke-jr|well, hopefully that new BIP metadata storage thing works out..
178 2016-06-03 16:14:30 0|sipa|can't we just store the metadata in a dht cloud blockchain, with rainbow tables for security?
179 2016-06-03 16:16:42 0|wumpus|and render the rainbow tables in actual rainbow colors in the GUI
180 2016-06-03 16:16:47 0|wumpus|with dancing unicorns
181 2016-06-03 16:18:27 0|wumpus|nothing protects your wallet better than distributed colorful random cloud technology
182 2016-06-03 16:18:47 0|sipa|copied from a random github repository
183 2016-06-03 16:20:31 0|luke-jr|ââ¬Â¦
184 2016-06-03 16:21:25 0|gmaxwell|back it up by finding a random pull reqest and then open up a copy against a fork of the origin project with the data added...
185 2016-06-03 16:21:32 0|gmaxwell|non-zero probablity that they merge it.
186 2016-06-03 16:30:33 0|sipa|a certain linux thorvalds quote comes to mind
187 2016-06-03 16:38:03 0|sipa|s/linux/linus/
188 2016-06-03 16:39:26 0|sipa|s/lastname/last name/
189 2016-06-03 16:56:46 0|GitHub154|[13bitcoin] 15MarcoFalke opened pull request #8144: [rpc] fundrawtransaction: Fix help text (06master...06Mf1606-rpcDoc) 02 https://github.com/bitcoin/bitcoin/pull/8144
190 2016-06-03 17:27:00 0|cfields_|MarcoFalke/wumpus: re: #8133, suggestions for how to fixup the import paths? I used a quick hack for the first one, but since we need another, i'd rather avoid adding more hacks on top
191 2016-06-03 17:27:55 0|MarcoFalke|Would also help if there was a comment for the hack, so it is easier to understand when looked at later.
192 2016-06-03 17:28:08 0|MarcoFalke|Did you manage to look at the python issue?
193 2016-06-03 17:28:28 0|MarcoFalke|I can try to play a bit locally when that's fixed
194 2016-06-03 17:29:19 0|cfields_|MarcoFalke: yea, it's the same issue that the "a few ugly hacks" commit fixes, just a different place.
195 2016-06-03 17:29:43 0|cfields_|MarcoFalke: ok, maybe easier if i just apply another ugly hack for now, and you can run cleanup afterwards? :)
196 2016-06-03 17:30:08 0|MarcoFalke|If I can figure out something better ;)
197 2016-06-03 17:31:00 0|cfields_|MarcoFalke: the underlying issue is that the scripts in the read-only srcdir need to import a script from the builddir, which is in an unknown location
198 2016-06-03 17:31:22 0|MarcoFalke|ok
199 2016-06-03 17:31:59 0|cfields_|the hack fix is to assume we're running from builddir, and add the path of the to-import files relative to pwd before doing the actual import
200 2016-06-03 17:36:26 0|cfields_|MarcoFalke: aha, wait. we already have the path set in the makefile. The problem is the .pyc lingering around in srcdir
201 2016-06-03 17:36:38 0|cfields_|(that's why travis passed)
202 2016-06-03 17:43:51 0|cfields_|ok. since we require python3 now, i don't think that's a problem. looks like it should just be a one-time delete.
203 2016-06-03 18:32:24 0|MarcoFalke|cfields_: I am missing the background but what about adding the rm *pyc to `make clean`?
204 2016-06-03 18:32:52 0|MarcoFalke|The same pycs need to be removed in the qa folder, I guess
205 2016-06-03 18:32:57 0|MarcoFalke|(Same error)
206 2016-06-03 18:33:07 0|cfields_|MarcoFalke: 'make clean' now removes __pycache__, which does just that
207 2016-06-03 18:33:59 0|cfields_|MarcoFalke: it's just the old python2 .pyc's that are trouble. More specifically, only when the .pyc exists and the .py is in a different path (builddir/srcdir)
208 2016-06-03 18:34:48 0|MarcoFalke|When I first tried to build out of dir, it told me to do 'make distclean' in the src dir.
209 2016-06-03 18:35:22 0|cfields_|MarcoFalke: you got another error in qa? tests_config.pyc i'm guessing?
210 2016-06-03 18:35:25 0|MarcoFalke|So keeping the code to remove pyc's in `make clean` temporarily would make sense
211 2016-06-03 18:35:46 0|MarcoFalke|jup, test_config
212 2016-06-03 18:35:50 0|cfields_|MarcoFalke: aha, good point!
213 2016-06-03 18:36:17 0|cfields_|MarcoFalke: so adding those 2 files to the distclean would solve it in a more obvious way.
214 2016-06-03 18:36:43 0|MarcoFalke|I guess so
215 2016-06-03 18:38:20 0|MarcoFalke|Also there is pyc's in qa/rpc-tests/test_framework/ like __init__.pyc
216 2016-06-03 18:38:26 0|MarcoFalke|I am assuming they don't hurt?
217 2016-06-03 18:40:05 0|cfields_|MarcoFalke: I believe it's only the ones that don't exist in srcdir (the pre-processed files)
218 2016-06-03 18:43:12 0|cfields_|MarcoFalke: pushed with that change instead. thanks for the reminder about the forced distclean.
219 2016-06-03 18:43:29 0|MarcoFalke|testing...
220 2016-06-03 18:45:12 0|cfields_|MarcoFalke: it might cause the same error for you now, but remember that you're passed the forced distclean. You can do another to simulate.
221 2016-06-03 18:47:59 0|MarcoFalke|distclean works
222 2016-06-03 18:50:20 0|cfields_|ok great. thanks for testing!
223 2016-06-03 18:55:03 0|MarcoFalke|copying rpc-test.py instead of linking would be considred bad practice?
224 2016-06-03 19:00:17 0|cfields_|MarcoFalke: we could, but I was afraid it'd get confusing.
225 2016-06-03 19:39:51 0|sipa|would it help to move roc-test.py to the roc-tests directory?