00:41:31 <one-horse-wagon[> hyc: The build instructions as they are set up now include 25 different dependencies.  Only 10 of them are necessary according to the chart.  What about throwing out the 15 optional ones, build, and see if the error disappears.  If successful, then start bringing back the optional dependencies, one at a time to see which one is the problem.
00:46:03 <hyc> sounds like a workable approach
00:48:07 <selsta> one-horse-wagon[: just to confirm the binaries downloaded from getmonero are v0.18.1.2?
00:48:50 <one-horse-wagon[> Yes.  I made sure.
00:49:02 <selsta> which ubuntu version are you using?
00:49:11 <selsta> or which OS?
00:50:24 <one-horse-wagon[> Debian Linux
00:53:25 <selsta> which boost version?
00:57:03 <one-horse-wagon[> Debian Linux 11.5
01:00:48 <one-horse-wagon[> <selsta> "one-horse-wagon: just to confirm..." <- The error occurs when trying to build dircetly from Github.  Get Monero works fine.
01:01:36 <selsta> boost version, not linux version
01:05:15 <selsta> 1.74 from what I can tell
01:07:45 <one-horse-wagon[> Checked Synaptic manager and it's 1.74
01:40:23 <one-horse-wagon[> s/dircetly/directly/
01:49:55 <ArticMine[m]> <fr33_yourself[m]> "I personally think the mass..." <- How about none of the above.
01:49:55 <ArticMine[m]> Baby boomer perspective. Monero scales way better today for mass adoption than BankAmericard did in 1959 when l was 2 years oild
01:51:03 <ArticMine[m]> In 19 years Monero can have a higher TPS than VISA
01:51:24 <ArticMine[m]> Correction 10 years 
01:51:58 <ArticMine[m]> BankAmericard later became VISA
06:49:44 <jozsef[m]> Good scaling, plus, Monero can already, fairly easily, avoid totalitarian crackdown: just use i2p and no one can tell you are using Monero. But people have to be less chicken that they will be "breaking the law" and feel a little less entitled to convenience.
06:49:44 <jozsef[m]> Also, there is no need for "mass adoption". Have they been able to stop p2p file exchange, for example? Not even close. Did they "outlaw it", sure, but who cares? The real question that matters is: can they mass-enforce their "laws"? Nope. Only on those who are too chicken and they feel they must be fully law-abiding.
12:41:24 <rbrunner> I started an attempt to debug the problem from Friday, that self-compiled Monero binaries on Debian don't want to work with SSL, there are connection errors between monero-wallet-cli and monerod
12:41:33 <rbrunner> I know a little more in the meantime
12:45:26 <rbrunner> With everything default, the 2 decide on using SSL, and that works - initially: there is a successful SSL handshake, and some successful RCP calls from wallet to daemon
12:45:53 <rbrunner> But then, after a number of calls that is not allways the same, the connection seems to break down somehow
12:46:20 <rbrunner> I could not yet see exactly how, the HTTP client simply tells a a given monent: HTTP_CLIENT: Failed to SEND
12:47:28 <rbrunner> After that error, if you try "refresh" again in the wallet, again some calls work, until there is that error again
12:48:45 <moneromooo> No more precise message than that ?
12:48:57 <moneromooo> (I assume you bumped log level)
12:49:07 <rbrunner> Could not coax the Monero logging system to get more precise than that so far
12:49:49 <rbrunner> Currently using +net.ssl:TRACE,net.http:INFO
12:50:15 <rbrunner> Maybe go for +net:TRACE?
12:50:34 <moneromooo> This message looks like a high-ish level message. Find the send function it's calling, add logs to failure paths. Repeat till you reach the boost layer. There, you should see either an exception (log it) or an error code as param (log it).
12:50:46 <moneromooo> Sure. Can't hurt if it's quick to get.
12:53:02 <rbrunner> It got a little bit more specific: Problems at write: Broken pipe
12:54:47 <moneromooo> Could be the peer cuts off the conncetion. Looks at the logs on the peer side.
12:54:49 <rbrunner> That seems to come from net_helper.h
12:55:15 <rbrunner> You mean I should concentrate next on the daemon side?
12:55:47 <moneromooo> I mean you should read the matching logs on the other side from the log that says "Broken pipe".
12:56:26 <moneromooo> Well, that's what I suggest anyway. Broken pipe hints that the peer might have cut the connection hard.
12:57:20 <rbrunner> Any quick idea for a log configuration for the daemon that does not flood me with tons of messages but leaves the intersting ones for this case?
12:57:44 <moneromooo> If it's offline and local, net*:DEBUG's a good start.
12:58:02 <moneromooo> Then add X:ERROR if category X seems unintereting and spams a lot.
12:58:55 <rbrunner> Ok, I try that
12:59:15 <moneromooo> *throttle*:ERROR is a good one IIRC.
13:03:52 <rbrunner> Hmm, the daemon does not seem to show anything interesting with +net*:DEBUG - https://paste.debian.net/1255713/
13:08:25 <rbrunner> That looks pretty crazy, doesn't it? First transfers a lot of bytes without problems, then breaks down, then recovers and transfers again.
13:08:36 <rbrunner> On the wallet side
13:09:03 <rbrunner> And all that only with self-compiled binaries, not with the release binaries ...
13:13:04 <rbrunner> Thanks for the help, moneromooo. I think I put that away for the moment, let's see whether other people comment
13:49:33 <moneromooo> If it connects, then it's not cipher suite compatibility.
13:50:20 <moneromooo> If no other errors, you might have to run with strace to see which syscall fails with EPIPE.
13:50:30 <moneromooo> That *might* be a clue. Or not.
13:51:51 <moneromooo> Oh, did you build with those same libs though ? You said yesterday or the day before you had updated your OS very recently.
13:54:37 <rbrunner> I updated some packages yesterday, but that changed nothing: Had the problem before that, have the problem still now.
13:56:40 <rbrunner> Hmmm, that strace tool looks like a whole new world to learn if I glance at the help text ...
14:20:16 <moneromooo> It just logs syscalls, their parameters and return values.
14:20:37 <moneromooo> strace -o strace.log COMMAND-GOES-HERE
14:20:54 <moneromooo> Gotta use -f or -ff if your command forks.
18:14:06 <one-horse-wagon[> I followed up on yesterday.  I built the monero binaries from Github after throwing out all of the optional dependencies.  I made sure the necessary binaries were all there.  I had to add libboost-all-dev and libzmq3-dev.  monerod is running fine.  When I started up monero-wallet-cli, it threw an error--"refresh failed: no connection to daemon. Please make sure daemon is running.. Blocks received: 0"
18:16:16 <one-horse-wagon[> My conclusion is one of the necessary dependencies is causing the error and not the optional dependencies.  
18:16:17 <moneromooo> Maybe you can go through the lib dependencies and log the versions of each on your system and on the gitian setup.
18:16:51 <moneromooo> openssl and boost are the main suspects here.
18:18:24 <rbrunner> one-horse-wagon: Can you read my debugging results from a few hours ago in the backlog?
18:19:01 <rbrunner> It's even crazier than simply no connection at all :)
18:22:58 <one-horse-wagon[> I looked at your report when you first posted it.  I would like to say I can see where the problem lies but i can't.
18:25:02 <rbrunner> Alright. I am also hesitating to go even deeper into this rabbit hole. It will probably turn out to be something stupid, or simply vanish with the next Boost or OpenSSL update
18:26:54 <one-horse-wagon[> Libboost has a new version out --1.8--released in August I believe.  Could it possibly help?
18:27:16 <selsta> rbrunner: you can try to manually compile latest boost and openssl and and set it in cmake
18:28:14 <rbrunner> Thanks, maybe I will try that. No promises yet.
18:29:14 <selsta> debian seems to have boost 1.74 which is 2 years old and no one reported issues with it yet
18:43:58 <rbrunner> Yup: Version: 1.74.0.3
19:47:39 <selsta> rbrunner: is this something you want to look into? https://github.com/monero-project/monero/issues/8560
19:47:45 <selsta> not sure who else to ask regarding Windows
19:49:34 <rbrunner> Alright, I will experiment a little with that tomorrow evening. Maybe I am lucky and see something. Probably not because Windows :) But still worth a try
20:01:08 <duggavo[m]> monero-wallet-rpc appears to make all the RPC requests time out while it's syncing up with the daemon. Is this wanted or it is a bug?
20:01:21 <duggavo[m]>  * monero-wallet-rpc appears to be making all the RPC requests time out while it's syncing up with the daemon. Is this wanted or it is a bug?
20:01:53 <esai[m]> hello guys, I am a Blockchain dev
20:02:07 <esai[m]> If you want my help, I will.
20:37:25 <hyc> duggavo[m]: the wallet should always reply "BUSY" until syncing is done
20:37:39 <hyc> (hm. mebbe I'm thinking of the daemon)
20:50:36 <duggavo[m]> <hyc> "duggavo: the wallet should..." <- I've had that error in the past with the daemon, not with the wallet
20:51:02 <duggavo[m]> wallet just doesn't answer to the RPC requests
21:02:39 <hyc> yeah it's been a while since I've sync'd an rpc wallet. usually it runs 24/7 so it's always in sync already
21:26:11 <plowsof> i remember moo saying rpc is single threaded , as in, it doesn't respond when syncing ? i just "loop until rpc requests stop timing out" then i know its synced/ready 
23:42:30 <one-horse-wagon[> <selsta> "debian seems to have boost 1...." <- Since the release of boost 1.74, there have been 6 upgrades to the present 1.80.  The linux kernel in Debian Linux is version 5.10 and since then there are now 9 upgrades to 5.19.  Obviously, bugs have have fixed with the upgrades.  I just wonder if I have been "chasing rainbows" with older buggy software.  My question is would an up to date linux distro like Arch which can keep up with
23:42:31 <one-horse-wagon[> the latest in all packages be better to run instead of Debian Linux?  
23:43:30 <one-horse-wagon[> * like Arch, which, * all packages, be
23:44:59 <selsta> I think it would be best to manually compile newest boost and openssl as a test
23:45:04 <selsta> to see if this solved the issue
23:45:05 <selsta> on debian