13:46:08 -xmr-pr- moneromooo-monero opened pull request #6877: p2p: add --max-connections-per-ip daemon option 13:46:08 -xmr-pr- > https://github.com/monero-project/monero/pull/6877 14:21:40 Would it be worthwhile to put a reminder on the mailing list regarding the upcoming scheduled network upgrade? 14:26:14 Hi guys! 14:26:29 Is exist guide for running python tests in monero project? 14:27:52 got "Unresolved reference 'framework'" when i'm trying to run monero/tests/functional_tests/sign_message.py 14:28:17 How to fix this error and execute tests? 14:28:20 pls help!!! 14:52:26 dEBRUYNE: I think it woulds. We are less than a week away from the hf 14:56:51 How are you running it ? 14:57:25 dEBRUYNE: maybe wait till selsta's released again, there's one very soon AIUI. 14:57:40 Anyway, tests: make release-test 15:03:54 ErCiccione[m: All right. As a side note, I updated the pruning guide on the Monero SE 15:04:04 moneromooo: Yeah I think tomorrow or tuesday 15:04:16 Will write up a draft in any case, then we can push it to the mailing list shortly after the release 15:04:28 Cool. Thanks for that dEBRUYNE 15:04:36 Yeah if there is a point release coming, better wait 15:06:59 I do think someone mentioned that blocks recently have been mined faster than average 15:07:06 Which basically brought forward the hf date by a bit 15:15:42 what does mean "Next needed pruning seed: 4" by sync_info ? I didn't pruning... 15:16:24 It's the pruning slot the next needed block falls in. 15:17:07 This doesn't depend on whether you prune or not, it's deterministic based on height. 15:55:40 fyi, CVE-2020-26947 has been assigned to https://github.com/monero-project/monero-gui/issues/3142#issuecomment-705940446 15:59:58 Kinda pisses me off they'd just do that without LD_LIBRARY_PATH. 16:00:19 It's really a problem with ld.so. 16:00:40 Or whatever looks anywhere that's not system and not in LD_LIBRARY_PATH. 16:06:52 there's $ORIGIN to do this in a safer way, but the release tar ball doesn't contain any libs anyway 16:09:11 Hmm. Never heard of that var. I'll look it up, thanks. 16:11:14 It's unlookupable :D 16:16:03 `rpath $origin` is what you want to google for :) 16:16:27 ty 16:16:44 but you should be able to just drop the rpath all together, on my system all libs are loaded from /usr/lib or /usr/lib64 anyway 16:20:12 Looks like this is enough: set(CMAKE_SKIP_RPATH ON) 16:20:19 (tested on daemon) 16:24:52 I'm on a static build though. 18:04:30 on that note, the CLI builds have an embedded rpath too 18:05:52 RUNPATH /home/ubuntu/build/monero/contrib/depends/x86_64-linux-gnu/lib: 18:06:44 I noticed it while working on $6862 18:09:44 hyc: which binary is that? 18:18:00 all of them 18:18:09 in the reproducible CLI builds 18:19:10 it's been like that for probably all of the reproducible releases 18:25:03 moneromooo: in case you're interested, I've revamped the crypto API in LMDB https://git.openldap.org/openldap/openldap/-/tree/mdb.master3 18:25:27 still not sure howe we get from here to there since the DB format is incompatible with LMDB 0.9 18:25:58 hyc: the binaries currently in arch linux are fine, the daemon is on 0.17.0.1 and the gui is still on 0.16.0.3 because the update got flagged 18:26:00 easiest is to use mdb_dump in 0.9 and mdb_load in 1.0 18:26:50 kpcyrd: I guess arch isn't using gitian for reproducible builds then 18:29:23 OK. The conversion problem would not apply since the wallet does not use LMDB atm. 18:29:45 yes but we would have 2 different versions of LMDB library 18:29:54 if we don't convert the daemon+blockchain 18:29:58 Oh. Even if we don't use crypto, it changes ? 18:30:04 yes 18:30:23 I mean, the crypto feature is built on LMDB 1.0 18:30:44 I had originally written it on LMDB 0.9, but it's been tweaked since then 18:30:54 OK. 18:31:32 I suppose I could try to backport it onto 0.9 again 18:32:17 Well, we'd first need someone willing to tackle a LMDB wallet. 18:32:23 true 18:32:36 hyc: https://github.com/archlinux/svntogit-community/blob/packages/monero/trunk/PKGBUILD#L44-L46 (not sure how this compares to what gitian does) 18:35:09 probably something flaky in our contrib/depends/toolchain.cmake 18:49:09 hm, setting SET(CMAKE_SKIP_RPATH ON) in the toolchain file doesn't work 18:49:31 cmake is still seeing CMAKE_SKIP_RPATH OFF, and emitting an rpath 18:53:38 I put it in CMakeLists.txt, right before set(CMAKE_C_FLAGS_RELEASE "-DNDEBUG ${OPT_FLAGS_RELEASE}") 18:56:20 still no joy 18:56:24 always get this 18:56:24 CMAKE_SKIP_RPATH:BOOL=NO 18:56:28 in CMakeCache.txt 18:57:49 wtf.... it just doesn't want to obey that setting 18:58:55 ok it takes it if I put -DCMAKE_SKIP_RPATH=ON on the cmake command line 19:01:47 btw what version of cmake did you use? 19:01:55 gitian build uses 3.10.2 19:02:21 my regular build env uses 3.13.4 19:05:58 and that setting definitely removed the rpath from the resulting monerod, good 19:06:13 now the question is why I can't turn it off with CMakeLists.txt or the toolchain file 19:50:17 doesn't cmake ignore stuff in the CMakeLists.txt file if there is already a CMakeCache.txt file? maybe delete the cache file and rerun cmake 19:58:28 I deleted everything before each run 19:58:32 rm -rf * 19:58:47 same result. the only way that worked was -D on the cmdline 20:36:11 I still got a tx as a red "failed" with monero-wallet-cli using --trusted-daemon on 0.17.0.1 with a 0.17.0.1 node. 20:44:26 initially failed? 20:45:11 did you connect to an unrestricted node? 21:01:08 -xmr-pr- muff1nman opened issue #6878: Cannot use `show_transfers in` without being connected to daemon 21:01:08 -xmr-pr- > https://github.com/monero-project/monero/issues/6878 21:14:56 selsta: my own node 21:15:15 Inge-: is your node restricted rpc? 21:15:25 yes --restricted-rpc 21:15:34 and what is the exact problem? 21:16:25 that a sent tx displays as a red failed 21:16:59 but then at some point it gets sent anyway. The going theory was that I had not added --trusted-daemon the first times I saw it, and that it is related to D++ 21:17:15 but now I've seen it with --trusted-daemon 21:19:50 Inge-: no, the theory is that your node is restricted 21:20:05 maybe I mistyped last time 21:20:21 can you try unrestricted node (with rpc login) 21:21:30 the issue is that the mempool is hidden in d++ stem phase (or so) so the client does not know the status of the transaction, so it gets shown as failed 21:21:40 with unrestricted node your client sees the mempool 21:28:28 I will test that out. But this is going to be a common error for remote node users in 0.17.1 then? 21:31:40 vtnerd suggested multiple ways to fix this