--- Day changed Wed Nov 21 2018 00:37 -!- \x [~user@unaffiliated/-x00/x-1893888] has joined #joinmarket 00:41 -!- \x [~user@unaffiliated/-x00/x-1893888] has left #joinmarket [] 01:51 < arubi> waxwing, I see you've been bitten by the infamous "space/time" thing :) 01:52 < arubi> to this day I don't know why that specific phrase is causing kickban in #bitcoin 02:11 -!- AdrianoOliveira [~AdrianoOl@109.255.195.143] has quit [Ping timeout: 244 seconds] 02:13 -!- undeath [~undeath@hashcat/team/undeath] has joined #joinmarket 03:22 < waxwing> arubi, orly? wow that's pretty weird 03:37 -!- GitHub45 [GitHub45@gateway/service/github.com/x-esowpnevbfcqkflg] has joined #joinmarket 03:37 < GitHub45> [joinmarket-clientserver] AdamISZ closed pull request #226: fix crash on bad podle revelation (master...fix-podle-crash) https://git.io/fp8Zl 03:37 -!- GitHub45 [GitHub45@gateway/service/github.com/x-esowpnevbfcqkflg] has left #joinmarket [] 03:37 -!- GitHub177 [GitHub177@gateway/service/github.com/x-wdxqzveapdvjlise] has joined #joinmarket 03:37 < GitHub177> [joinmarket-clientserver] AdamISZ pushed 2 new commits to master: https://git.io/fp85K 03:37 < GitHub177> joinmarket-clientserver/master 286d306 undeath: fix crash on bad podle revelation 03:37 < GitHub177> joinmarket-clientserver/master f96c0f5 AdamISZ: Merge #226: fix crash on bad podle revelation... 03:37 -!- GitHub177 [GitHub177@gateway/service/github.com/x-wdxqzveapdvjlise] has left #joinmarket [] 03:37 < waxwing> oh keep forgetting to change git signing key setting .. that should be the last commit with the old key 03:37 < undeath> right now it's still valid 03:38 < waxwing> yes. but i've done everything to switch to the new key (it's on github), just forgot to change it on git. doesn't matter. 03:42 < undeath> is a new release needed for that? 03:43 < waxwing> probably, it's one of various Qs i'm now thinking about 03:43 < waxwing> well, it's more, should we wait to finish or change something else before pushing a release 03:43 < waxwing> there are several other issues cropping up here, but i guess most of them can be delayed till later. 03:44 < undeath> it's rather critical, most changes in the pipeline are only refactorings of some kind 03:44 < undeath> or are you thinking of something particular? 03:46 < waxwing> one Q which certainly can be put off, but which is bothering me is: i'm reasonably sure that refactoring a setup like ygrunner.py to make it part of automated tests should not be too hard; but how can we automate tests of two different versions of the code? 03:46 < waxwing> (and yes, that is long term, not short term, but i'm sitting here wondering if there are any related bugs we've missed, that's why it's on my mind) 03:46 < waxwing> but for now, the boring conclusion is correct: push a fix release, today. 03:46 < undeath> the py3 bug wasn't caused by differing versions 03:47 < undeath> in general I expect the chance of such errors to be slim 03:47 < waxwing> ok, encryption/decryption routine borked, true, but it is very possible for incompatibility to happen like that. 03:47 < waxwing> you think you are sending the same message but you are not due to e.g. unicode. 03:47 < undeath> a higher priority would be having any kind of tests for the communacation channel 03:49 < waxwing> but what exactly do you mean by that? there's the irc level which kind of is tested, there's the enc/dec which is tested but only in isolation. i think you mean end to end? 03:49 < undeath> yes 03:49 < waxwing> if a single join with the same setup as ygrunner was in the test suite that would already go a long way. 03:49 < undeath> one full cj, even a single valid one would do 03:49 < undeath> yes, something like that 03:49 < undeath> just for some sanity checking 03:50 < waxwing> i might just look at it for an hour or two, this bug has been out there for like 1.5 years, i don't think another few hours will kill us :) 03:50 < waxwing> number of bots in the pit actually went up in the last day lol 03:50 < undeath> lol 03:52 < undeath> I wonder if twisted offers a way to mock the communication channel so we can bypass actually having to use irc 03:53 < waxwing> well i mean, that's already in the test suite, so i guess no need to remove it 03:53 < undeath> what do you mean? 03:53 < waxwing> and it's more realistic right. (if not entirely; miniircd is a pretty skeletal version of an IRC server) 03:53 < undeath> oh, well, is it really in the test suite currently? 03:54 < waxwing> well if we're trying to do E2E testing so we make sure we catch any failure anywhere in the stack 03:54 < waxwing> undeath, yes there's a test_irc in the jmdaemon test suite 03:54 < undeath> well, using actualy network communication is prone to non-deterministic erros 03:54 < waxwing> oh no hang on, maybe not. i forgot 03:54 < waxwing> maybe it just mocks the IRC part, i'd have to check. 03:55 < waxwing> undeath, right, good point. 03:55 < waxwing> in practice probably not, here, but as a general observation. 03:56 < undeath> in a test we'd probably have to mock whatever is in jmdaemon/message_channel.py 03:56 < waxwing> oh yeah it does use miniircd, i remember now 03:57 < waxwing> test_irc_messaging.py see it subclasses IRCMessageChannel 03:57 < waxwing> i remember now you can watch the test run from your local irc client (not that it's very interesting) 03:58 < waxwing> anyway this seems like a slight tangent, i think the thing to do is what we said earlier, just get an E2E in the test suite 03:59 < undeath> it's a bit hard to verify if it's not in "test form" 03:59 < undeath> but well, that's probably the only part that actually requires any work 03:59 < undeath> making a test case of the ygrunner 04:00 < waxwing> i don't understand what you mean. 04:00 < waxwing> but, what i find difficult about it is, if you run it as part of the existing test suite, you have to worry about starting the reactor (only one reactor per run), maybe run it as a second pytest instantiation 04:01 < waxwing> then there's the matter of getting the taker running in the same reactor loop, which i suspect is not an issue, but haven't tried it yet. 04:02 < undeath> if we can run jmdaemon and jmclient in the same reactor loop, multiple jmclients shouldn't make much trouble I guess 04:17 -!- azizLIGHT [~azizLIGHT@unaffiliated/azizlight] has quit [Ping timeout: 245 seconds] 04:19 < undeath> oh, for mocking we only need to implement the couple methods in MessageChannel 04:19 < undeath> that'd be easy 04:21 < waxwing> undeath, are you still talking in terms of the e2e coinjoin test? because i don't see why we need to mock anything for that? 04:22 < undeath> i think it would be easier to use than the "real" full suite including an ircd 04:22 < undeath> although one full e2e test would not be a bad thing to have either 04:23 -!- azizLIGHT [~azizLIGHT@unaffiliated/azizlight] has joined #joinmarket 04:54 < waxwing> ok, half-working (got it started but crashed on the commitments file location), enough to be promising and prob worth tidying up so it works. 04:55 < waxwing> i guess i'll stick it in test/ and call it something like test_full_coinjoin and then run it as a second pytest instantiation. 05:21 -!- d3spwn [~Jimmy@83.161.157.200] has quit [Ping timeout: 244 seconds] 06:40 < waxwing> it's working now. i'll probably take a couple of hours time to clean it up before PR. it hardly took any time at all (which is obviously nice, and i remember thinking this some time in 2017, but it was another one of those 100 things that were useful but i felt disinclined to do :) ) 06:40 < undeath> nice :) 06:51 -!- undeath [~undeath@hashcat/team/undeath] has quit [Quit: WeeChat 2.3] 07:41 < Lightsword> yeah, that encryption bug got past me due to incomplete test coverage since I was heavially leaning on tests for validating the conversions 07:41 < arubi> so what's the verdict on install.sh checking gpg signatures? do we want to keep that, or is simply checking the hash of the .tar.gz enough? 07:42 < Lightsword> waxwing, btw why does this abomination exist? https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/jmbitcoin/jmbitcoin/secp256k1_transaction.py#L12-L34 07:59 < waxwing> Lightsword, it's a leftover from pybitcointools (Vitalik's lib) which is what belcher copied over to start with. 07:59 < waxwing> not that i'm blaming belcher , i was fully on board at the time :) 07:59 < belcher> that is the reason, 2014 bitcoin was a different era 07:59 < waxwing> Lightsword, i saw yesterday you were talking about how crappy it is, and i agree, we could take a more radical approach here 08:00 < Lightsword> yeah…that function is a good example of bad python coding practices I think 08:00 < waxwing> i would like to switch to python-bitcoinlib but there'd be several steps we'd have to take. 08:00 < waxwing> i've actually been thinking about it today but busy fixing all this other stuff. 08:01 < Lightsword> basically you generally want to avoid any sort of automatic type conversion/type detection code, it makes testing/conversion much more difficult since you get tracebacks in confusing places 08:02 < Lightsword> it’s better to do the conversions explicitely from the call sites IMO 08:03 < waxwing> Lightsword, it had some fun features (that pybitcointools lib) like, entering an infinite loop on the script OP_TRUE .. (that was the auto-detection screwing up) 08:04 < waxwing> i mean not literally, it ran out of stack, but you get my drift :) 08:04 < Lightsword> lol 08:06 < Lightsword> waxwing, once my fixed python3 style conversion is merged I’ll give another shot at converting jmbitcoin I think, I’ll try and replace those functions with ones that don’t use autoconversion 08:06 < Lightsword> now that I’m getting somewhat familiar with that part of the code from all my previous failed attempts 08:07 < Lightsword> previously I was trying to just minimize the diff, but that part of the codebase is too horrible I think for that to be a good idea 08:07 < waxwing> ok, that sounds def worth a shot (i've tended to be too pessimistic about this i think). give it a couple of days at least, i have to make a 0.4.2 release after getting this new test done. 08:07 < waxwing> and we can concentrate on these new py3 compat changes after that. 08:07 < waxwing> i mean not that it should stop you if you want to do it now, but i get it that rebasing gets messy. 08:08 < Lightsword> yeah, I don’t really want to try it until the previous python3 conversions are merged due to rebase issues 08:08 < Lightsword> waxwing, maybe these changes should go in a dev branch for now? 08:08 < Lightsword> instead of master 08:09 < waxwing> that's actually what i originally thought for this 08:09 < Lightsword> that way if I accidentially break the build we don’t have to revert 08:09 < waxwing> there's still housekeeping work that way, but it's saner/simpler i guess 08:09 < Lightsword> although…having in master can be nice since others will catch bugs 08:10 < waxwing> right, can argue both ways. i'd lean towards the branch. 08:10 < Lightsword> I’d say merge to master still if you can 08:10 < Lightsword> just since you otherwise risk the branch getting out of sync 08:10 < Lightsword> and then bugs like that last one become way harder to trace 08:11 < Lightsword> I basically just had to work my way through the call stack until I came accross the encryption/decrytion routines 08:12 < Lightsword> when doing these py2 to py3 style conversions I think best practices are to merge to master since those imports guard against re-introducing py2 only changes 08:13 < waxwing> ok 08:13 < waxwing> we'll just be thorough in tests (and hopefully this new test i'm polishing off now will be a big step up, but i think it's only the basics) 08:14 < Lightsword> yeah, good tests make things much easier, especially integration tests, unit tests are more prone to missing issues 08:15 < waxwing> funny thing is i originally wrote a test_tumbler.py which was a full e2e test and put it in travis, but ditched it as it was taking too long :) 08:16 < waxwing> (part of that though is why twisted ended up being a thing, it's kind of a long story but stuff like that gets really hairy if you do it with threads. not that it'll necessarily be perfect with twisted, either) 08:16 < waxwing> but i'm deliberately keeping it much simpler this time, 1 coinjoin. 08:16 < Lightsword> I like twisted, I’ve used it for a number of projects(although with inlinecallback style) 09:06 -!- undeath [~undeath@hashcat/team/undeath] has joined #joinmarket 09:10 -!- GitHub197 [GitHub197@gateway/service/github.com/x-qjdawowzfvxtxulf] has joined #joinmarket 09:10 < GitHub197> [joinmarket-clientserver] AdamISZ opened pull request #227: add full coinjoin test (master...full-coinjoin-test) https://git.io/fp4l1 09:10 -!- GitHub197 [GitHub197@gateway/service/github.com/x-qjdawowzfvxtxulf] has left #joinmarket [] 09:14 < waxwing> seems to take around 40-50 seconds on my machine, ymmv 09:17 < undeath> that's acceptable I guess 09:18 < waxwing> when i do ./test/run_tests.sh i get 'Packages in requirements-dev.txt could not be installed, Exiting' ; anyone have an idea why? 09:19 < waxwing> timing depends on maker_timeout_sec setting; i don't think dropping it much below 15 will work. probably we can cut it down further but yeah i think it's acceptable for now. 09:20 < arubi> waxwing, does it show the actual dependency that failed to install? 09:20 < undeath> so it doesn't automatically terminate? 09:20 < waxwing> something weird, sorry, it seems that it's claiming the file's not there, but it is 09:21 < arubi> and you're actually running `./test/run_tests.sh` (from the main dir) right? 09:22 < waxwing> yeah 09:22 < waxwing> ls ./req... etc shows it 09:22 < waxwing> the script doesn't seem to be changing dir before that point. puzzling. 09:23 < arubi> is virtualenv turned on? 09:24 < waxwing> yes 09:24 < arubi> oh yea 09:24 < waxwing> interesting, when i run it from command line: python-coveralls 2.9.1 has requirement coverage==4.0.3, but you'll have coverage 4.5.2 which is incompatible. 09:24 < waxwing> (i mean when i run the same pip command) 09:24 < undeath> travis is show this error for ages 09:24 < arubi> yea that's been that way for a while 09:25 < arubi> what's the value of ${VIRTUAL_ENV} waxwing ? 09:25 < waxwing> oh; but, it runs on travis? why does it stop with that error here, i wonder? 09:25 < arubi> coveralls is broken on travis too 09:25 < waxwing> do you mean while the script's running, or now on the command line arubi ? 09:25 < arubi> command line 09:26 < waxwing> ah! yes, that's right 09:26 < waxwing> it's not correct for me, i have a custom location 09:27 < waxwing> anyway undeath to state the obv let me know if there's any issue you see with that script (it's pretty simple/basic), i'll try to add a line for it in the run_tests 09:27 < arubi> too bad it's not very easy to move a virtualenv around :( you could just symlink the file 09:27 < arubi> oh but that might not be enough.. 09:28 < arubi> maybe it'll be useful to add another flag to install.sh for assigning a custom name for the jmvenv dir 09:29 < undeath> the test doesn't actually check if the cj happened, it only hopes to catch any exception that my be happening? 09:29 < undeath> but even in case of an exception reactor would probably continue running and the test still pass? 09:30 < arubi> ^ we've actually seen this behavior before somewhere else I think 09:31 < arubi> I can't remember what it was. something was /supposed/ to throw an exception, and the assert of catching the exception was commented out because the exception itself never reached the assert check 09:37 -!- d3spwn [~Jimmy@83.161.157.200] has joined #joinmarket 09:37 < arubi> ah it wasn't an assert. in jmdaemon/test/test_irc_messaging.py , there's junk_longmsgs() and () that have "with pytest.raises..." commented out 09:38 < arubi> I think the exception is missed for the same reason 09:40 < arubi> *and junk_fill() 09:42 < waxwing> undeath, hmm. so you're talking about if final_check doesn't get it called, right. 09:42 < waxwing> heh, maybe the biggest worry is that it might run forever :) 09:44 < waxwing> i'll take a look again in a while, i remember there is a shutdown after a timeout when it doesn't work, but i'm sure you're right something more needs to be done to catch that 09:45 < undeath> does calling start_reactor multiple times even work? 09:45 < undeath> i thought it's a blocking call 09:50 < waxwing> undeath, no it's not actually calling reactor.run multiple times :) 09:51 < waxwing> start_reactor has an amusing keyword argument rs (reactor start) :) 09:51 < undeath> oh 09:51 < waxwing> should rename it but w/e 09:55 < waxwing> doh, forgot to remove coinjoin test from travis pytest run, nbd will fix in next commit 09:56 < undeath> isn't it supposed to run on travis? 09:56 < undeath> i though that was the goal 09:58 < waxwing> yes. as i said, it would need a separate instantiation of pytest 09:59 < undeath> ah 09:59 < waxwing> or is there a problem with that idea that i missed undeath ? 09:59 < undeath> no, i don't think so 10:07 < undeath> but why is a separate pytest instance needed? 10:07 < undeath> can't you do the same thing we're doing in test_coinjoin.py? https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/jmclient/test/test_coinjoin.py#L263 10:12 < waxwing> oh; what does that do? 10:12 < waxwing> undeath, 10:13 < undeath> it will run after the test is finished and remove all delayed calls 10:13 < undeath> so you end up with a "clean" reactor 10:14 < waxwing> hmm, without twisted.trial can we have another reactor run in the same test, though? 10:15 < undeath> just put it in a fixture that has not a module scope 10:16 < waxwing> i don't know how that'd work, i'm inclined to put it off though, i'd rather (a) fix why i can't run run_tests.sh, (b) add it as another pytest and then (c) address your first concern (what happens if there's some crash and it doesn't complete?) 10:16 < undeath> instead of @pytest.fixture(scope='module') use @pytest.fixture 10:18 < waxwing> but i'm not allowed to have more than one reactor.run() call in the process, am I? hmm maybe it works because the other ones use twisted.trial? 10:18 < waxwing> i can try it now i guess 10:18 < undeath> oh, not sure 10:18 < undeath> i thought there is some magic in pytest that will just make twisted work 10:20 < waxwing> i know by default it won't allow you to run multiple reactors 10:20 < waxwing> that's why that weird twisted.trial code was there 10:21 < undeath> it's possible you don't need to call reactor.run() in tests 10:21 < undeath> test_coinjoin.py doesn't and it still works 10:24 < waxwing> it seems to just hang with that change. i'd rather go back to the way of doing things that i can understand, at least for now. 10:24 < undeath> ok 10:33 -!- undeath [~undeath@hashcat/team/undeath] has quit [Read error: Connection reset by peer] 10:33 -!- undeath [~undeath@hashcat/team/undeath] has joined #joinmarket 11:03 < waxwing> arubi, i want to check two different success (i.e. return) values in the run_tests.sh script, how do i modify this line to do that? https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/test/run_tests.sh#L60 11:04 < undeath> success = $[ $success + $otherret ] 11:05 < arubi> no no 11:05 < arubi> what if success == -1 and othererr == 1 ? 11:05 < arubi> (ignoring weird syntax :P ) 11:06 < arubi> hm 11:08 < waxwing> arubi, so is it that you have to use integers in bash, or something? 11:08 < waxwing> like there's no logical operator to use? 11:09 < arubi> there's a bunch of logical ops in $(( ... )) 11:09 < waxwing> oh, so like, the return values are specifically -1 in bash for erros 11:09 < arubi> I'm testing locally here 11:09 < waxwing> but i have a vague memory that errors can be other things than -1 for errors 11:09 < arubi> errors are usually positive 11:09 < undeath> everything not 0 is usually an error 11:09 < waxwing> ah yeah, anythhing non zero 11:09 < waxwing> right 11:11 < arubi> I'm actually kinda surprised `echo $(( (0 == 0) && (1 == 0) ))` echoes 0 11:11 < arubi> that's what I first thought about suggesting but obviously something is wrong here 11:12 < undeath> return $[$a || $b] seems to work on zsh 11:12 < arubi> ohh right 11:12 < undeath> but that will return 1, not -1 11:12 < arubi> the (( returns 1 for true 11:12 < undeath> bash scripting is such a mess 11:13 < arubi> it is not :) 11:13 < arubi> waxwing, `return "$(( ! ((${1} == 0 ) && ($2 == 0)) ))"` 11:14 < arubi> obviously replace $1,$2 with your returned values. this should return 0 if both are successful 11:14 < undeath> so you call that not a mess? 11:15 < arubi> it's by design that True in (( is 1 11:15 < waxwing> heh. thanks. 11:15 < arubi> if it were [[ then it'd be 0, but writing that would be less pretty 11:15 < undeath> python: return a or b 11:15 < arubi> undeath, sorry really but I lova bash :) 11:15 < arubi> err, Love. 11:16 < waxwing> arubi, why is 1 in {} and 2 not in that expr? 11:16 < arubi> just me half assing it 11:16 < undeath> i tend to write all scripts I need in python because bash is so messy 11:16 < arubi> {} always better 11:16 < waxwing> ok cheers 11:17 < arubi> I can't blame you undeath. I've been getting into python at work for some time (migrated from bash really) and I find myself doing the same 11:17 < waxwing> and i need return " ... " i.e. it needs double quotes, right 11:17 < arubi> it's better to always quote yea 11:18 < arubi> we're only doing logical expr stuff on what we assume to be always numbers, so it's "safe" without, but better with. 11:19 < undeath> zsh is a bit nicer, it doesn't need any quotes 11:19 < undeath> gets rid of so many mistakes 11:19 < arubi> but zsh isn't so ubiquitous. at work I'm using a lot of different os'es 11:19 < undeath> unfortunately 11:20 < arubi> heh well, customers get what they pay for. hopefully linux will replace everything else asap 11:21 < undeath> :D 11:23 < arubi> some day I'll be comfortable enough with python that maybe I can start contributing real code instead of just install\test framework stuff :) we'll see 11:36 < waxwing> arubi, could you take a look at the delta i put to that script here: https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/227 ; i'm sure it could be done better 11:38 < arubi> waxwing, maybe worth to insert after line 55 : 'success="$(( ! ((${success} == 0 ) && (${success2} == 0)) ))"' , then leave everything else the same 11:38 < arubi> by same I mean revert edits, sry 11:44 < arubi> er again maybe I'm not clean, "everything else" means everything after the would be line 56 :) it's hard to tell if you're making sense on irc 11:44 < arubi> clear* 12:22 < undeath> arubi: can you take a look at #202? 12:24 < arubi> undeath, ah I saw that before and forgot! I think it's worth to keep the xenial image because: 1. it's a clean image vs. travis' setup that has a lot of stuff preinstalled, 2. it doesn't affect test runtimes on travis because it executes jobs at batches of 5 (I think it was 5) 12:26 < undeath> ok, thanks :) 12:26 < arubi> cheers 13:48 < Lightsword> waxwing, are you planning to merge #223 or #227 first? 14:03 < waxwing> Lightsword, #227 i guess, but i need to think for a little more whether i can easily make sure it fails on any coinjoin failure. i'm in no rush with #223. 14:03 < waxwing> we should have a release because of the crash bug. 14:04 < Lightsword> kk, I’m somewhat blocked until #223 is merged since it will cause rebasing issues for dependent changes 14:06 < waxwing> Lightsword, understood. if it's important to you to do it quickly, i'll make it more of a priority. 14:07 < Lightsword> yeah, would be good to do quickly if possible since I need to base the jmbitcoin refactoring on top of it 14:07 < undeath> i think you can safely base your other pr off the #223 code 14:08 < undeath> once #223 is merged you can just rebase without trouble 14:08 < Lightsword> well, I’ve also got the coincurve one 14:08 < Lightsword> although that’s more manageable 14:09 < waxwing> ok message received, undeath if you think we should merge 223 now go ahead, it does mean the release will include that though. 14:09 < undeath> i haven't yet tested that code 14:10 < waxwing> undeath, 223? 14:10 < undeath> yes 14:10 < waxwing> oh sorry i got confused 14:10 < waxwing> thought we were talking about 224 14:10 < waxwing> the python3 thing 14:11 < undeath> that one looks ok now 14:11 < waxwing> everything i said above was about 224, sorry. you actually did mean 223 or 224 above? 14:11 < waxwing> Lightsword, ^ 14:11 < undeath> we were talking about 223 14:11 < undeath> (coincurve) 14:11 < Lightsword> I meant 224, woops 14:12 < waxwing> right wouldn't make sense otherwise, ok so we were both communicating correctly but with the wrong number :) 14:12 < undeath> seems to work for you :P 14:17 < waxwing> undeath, so by 'that one looks ok' you'd give a rough tested-ack on #224? 14:17 < undeath> i think 0.4.2 should be released to fix the crash, after that we can merge 224 and have it on master for a while 14:17 < Lightsword> yeah, that should work 14:17 < waxwing> yeah that would be my leaning too. 14:18 < undeath> so far i haven't encountered any problems with 224 14:18 < waxwing> and 227 doesn't matter either way, i would say though: running it locally is a nice sanity check (with -s), even if i can't figure out how to make sure any errors get picked up in automated 14:18 < waxwing> although i've only just started thinking about it. 14:18 < waxwing> anyway, i guess i'll just go ahead and release the bugfix tomorrow then. 14:19 < undeath> sounds good 14:20 < undeath> i think #202 and #219 can be safely merged 14:21 < undeath> that might even be desirable before the release 14:21 < undeath> at least #219 14:21 < undeath> so hopefully people don't get any problems when running install.sh any more 14:21 < waxwing> right since arubi acked it i'll merge 202 now 14:22 -!- GitHub188 [GitHub188@gateway/service/github.com/x-ggeypipqkidafetn] has joined #joinmarket 14:22 < GitHub188> [joinmarket-clientserver] AdamISZ pushed 2 new commits to master: https://git.io/fp4yO 14:22 < GitHub188> joinmarket-clientserver/master dfb2f7c undeath: update travis main distribution 14:22 < GitHub188> joinmarket-clientserver/master 08c2999 AdamISZ: Merge #202: update travis main ubuntu distribution... 14:22 -!- GitHub188 [GitHub188@gateway/service/github.com/x-ggeypipqkidafetn] has left #joinmarket [] 14:22 -!- GitHub13 [GitHub13@gateway/service/github.com/x-gbfgwjzhxdnfdeys] has joined #joinmarket 14:22 < GitHub13> [joinmarket-clientserver] AdamISZ closed pull request #202: update travis main ubuntu distribution (master...update-travis-distri) https://git.io/fxQnT 14:22 -!- GitHub13 [GitHub13@gateway/service/github.com/x-gbfgwjzhxdnfdeys] has left #joinmarket [] 14:23 < waxwing> so you're acking 219 undeath ? sorry to be useless but i really haven't got into understanding the technicals there. i put up a test report but that's the best i can do for now :) 14:24 < undeath> since it seems to generally work I'm confident it'll work better than previously 14:24 < waxwing> using 'ACK' on PRs and such like was almost unnecessary at one point but now we have roughly 4 people fairly active it's quite useful to do it i guess. 14:24 < undeath> my only question there was about the keyserver but that has been resolved 14:25 < waxwing> yeah but i can't remember who thinks what, please use ACK in future :) 14:25 < undeath> ok :) 14:26 -!- GitHub167 [GitHub167@gateway/service/github.com/x-scpujfvxvhnneduk] has joined #joinmarket 14:26 < GitHub167> [joinmarket-clientserver] AdamISZ closed pull request #219: Use gpg for fetching keys from key servers (master...installsh_gpg_recv_keys) https://git.io/fpZWq 14:26 -!- GitHub167 [GitHub167@gateway/service/github.com/x-scpujfvxvhnneduk] has left #joinmarket [] 14:26 -!- GitHub22 [GitHub22@gateway/service/github.com/x-epticrxsdyrtetpy] has joined #joinmarket 14:26 < GitHub22> [joinmarket-clientserver] AdamISZ pushed 3 new commits to master: https://git.io/fp4yz 14:26 < GitHub22> joinmarket-clientserver/master b102b5d fivepiece: use gpg for fetching pubkeys 14:26 < GitHub22> joinmarket-clientserver/master 69f898d fivepiece: check gpg signatures on travis 14:26 < GitHub22> joinmarket-clientserver/master 554fc63 AdamISZ: Merge #219: Use gpg for fetching keys from key servers... 14:26 -!- GitHub22 [GitHub22@gateway/service/github.com/x-epticrxsdyrtetpy] has left #joinmarket [] 14:27 < undeath> btw, have you looked at #205? (not suggesting to merge it now) 14:27 < waxwing> oh yeah that had a travis error 14:28 < undeath> 205? 14:28 < waxwing> no the one i just merged, heh 14:28 < undeath> that was a cache error i think 14:28 < waxwing> i asked in the thread but no reply, was curious about whether it was important 14:28 < waxwing> ok cool 14:28 < waxwing> undeath, as i said the other day, i haven't even started looking at 205, sorry 14:29 < undeath> ah, must have missed that, alright 14:29 < waxwing> i'd tend to think that comes into the category of protocol upgrade, but, obv i may be wrong there. there are some subtleties around the idea of mixed address types. 14:30 < undeath> the same thing is already possible, but only with potentially privacy-decreasing workarounds 14:30 < undeath> so it's really more of a fix than an enhancement 14:31 < waxwing> ah i see, yes, now i read it, it's a kind of backend thing. cool. 14:32 < undeath> the thing is, your auth key has to be of the same version but the other keys/addresses don't matter right now 14:32 < waxwing> right 14:32 < undeath> with tha pr the version of your auth key/address doesn't matter either 14:32 < waxwing> yes, nice update, thanks 14:47 < undeath> the build failed again for the same reason on master 14:47 < undeath> is there a way to clean the cache or do we have to wait for it to resolve itself eventually? 14:49 < waxwing> i do agree with you it's much better to release with that if it fixes the key thing. and i believe it did in my test, although i should try again. 14:50 < waxwing> undeath, just to be clear, we're talking about this right: https://travis-ci.org/JoinMarket-Org/joinmarket-clientserver/jobs/458169065#L737 14:51 < waxwing> arubi, ping, thoughts? 14:51 < waxwing> i'll try it on a VM now if I can. my previous test was on a non-clean machine. 14:51 < undeath> well, that was a non-deterministic network error 14:51 < undeath> but that, in consequence, caused this one https://travis-ci.org/JoinMarket-Org/joinmarket-clientserver/jobs/458169066#L1343 14:52 < undeath> oh, actually not, that's simply an unrelated error on the mac build 14:53 < undeath> but for some reason the .sig file is not in the cache, but the install script only checks for the presence of the .tar.gz file in order to decide whether to download the .tar.gz + .sig 14:54 < undeath> since the .tar.gz is there it just errors out on missing the .sig 15:49 -!- undeath [~undeath@hashcat/team/undeath] has quit [Quit: WeeChat 2.3] 17:11 -!- AgoraRelay [~jmrelayfn@p5DE4AA4D.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds] 17:21 -!- AgoraRelay [~jmrelayfn@p5DE4AD38.dip0.t-ipconnect.de] has joined #joinmarket 18:45 < Lightsword> https://i.redd.it/et48l7mvr5c11.jpg 20:00 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Quit: ZNC 1.6.3+deb1+xenial0 - http://znc.in] 20:07 -!- achow101 [~achow101@unaffiliated/achow101] has joined #joinmarket 21:26 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 21:26 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #joinmarket