03:57:39 <dexter> where can i find this monerod.log : ~/monero/monero/build/Linux/master/release/bin$ ./monerod --log-file monerod.log
03:57:55 <moneromooo> in .
03:58:33 <moneromooo> If not, there's a remote possibility it puts it in ~/.bitmonero.
04:03:27 <dexter> yup i found it there (~/.bitmonero), Thanks,  I am trying to build from latest commit of master branch of monero i built it successfully but on running it with following command ./bin/monerod --log-file monerod.log --detach
04:03:42 <dexter> i see a error
04:05:07 <dexter> how do i share my monerod.log
04:05:15 <dexter> or if this works :
04:05:17 <dexter> 2020-12-29 04:00:13.520     7f5c10930c00        INFO    global  src/daemon/p2p.h:63     Initializing p2p server...
04:05:21 <dexter> 2020-12-29 04:00:13.524     7f5c10930c00        INFO    stacktrace      src/common/stack_trace.cpp:133  Exception: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >
04:06:09 <moneromooo> Try asking in #monero after running with --log-level 1 and pasting the relevant log to pastebin.com or similar.
04:07:33 <dexter> Appreciated v
04:09:06 <Mmmmmmmmmm> Hello, what is "COMMAND_RPC_DESCRIBE_TRANSFER" in https://github.com/monero-project/monero/blob/8286f07b265d16a87b3fe3bb53e8d7bf37b5265a/src/wallet/wallet_rpc_server_commands_defs.h (Line 586). What is its purpose? I thought one would only need to provide unsigned_txset in the Request, but multisig_txset is also needed. Is this a multisig-only
04:09:06 <Mmmmmmmmmm> request?
04:10:16 <moneromooo> It parses a transfer, can be either multisig or signed from a cold wallet IIRC. If it needs multisig, it's buggy.
04:12:14 <Mmmmmmmmmm> I see, well if a field is optional it is serialized with KV_SERIALIZE_OPT instead of KV_SERIALIZE. So it looks like both are needed. Do you suggest I not support this in my library?
04:12:42 <moneromooo> std::string defaults to empty, so KV_SERIALIZE_OPT is not needed.
04:13:41 <Mmmmmmmmmm> Oh I see, in that case it's fine to send unsigned_txset or multisig_txset, but not both, I presume
04:14:01 <Mmmmmmmmmm> Is that correct?
04:14:08 <moneromooo> Yes. Both might work, but it'll likely pick the one it checks first.
04:14:15 <Mmmmmmmmmm> Thanks
05:34:08 <Mmmmmmmmmm> I posted this question publicly so others can see the answer in the future:
05:34:09 <Mmmmmmmmmm> https://monero.stackexchange.com/questions/12586/what-is-the-difference-between-sweep-all-and-sweep-single
05:52:21 <zib> Getting a strange error from monero-wallet-cli at commit b222188 . Unable to connect to daemon.
05:52:28 <zib> debug log says "contrib/epee/include/storages/portable_storage_from_bin.h:168   Too many array elements"
05:53:19 <Mmmmmmmmmm> Looks like there is a PR for that: https://github.com/monero-project/monero/pull/7219
05:54:45 <zib> oh. Missed it since it was just listed "some people dont want it" :D
05:55:01 <zib> Since the cli won't connect i'm sure alot people dont want it :D
06:01:33 <selsta> zib: 7222 should also help
06:03:12 <zib> thx, compilin'
06:08:31 <selsta> so you need 7220 + 7222
06:09:02 <selsta> sorry
06:09:09 <selsta> 7219 + 7222
06:15:22 <zib> yeah thats what i did. Slow to compile.. ;)
06:31:35 <Mmmmmmmmmm> How do I get a + beside my name?
06:32:09 <Mmmmmmmmmm> Rbrunner vetted me, and I authored this, which is now in the Monero Ecosystem. Have I earned my keep?
06:32:10 <Mmmmmmmmmm> https://github.com/monero-ecosystem/csharp-monero-rpc-client
06:34:44 <selsta> voiced on IRC does not mean anything really
06:34:54 <selsta> we used to voiced everyone due to spam issues
06:35:09 <Mmmmmmmmmm> It adds clout
06:35:36 <Mmmmmmmmmm> But I guess it isn't permanent anyways...
06:37:23 <selsta> nice your code got added to monero-ecosystem
06:38:24 <Mmmmmmmmmm> Yeah, Rbrunner gave me great advice, and I built ontop of it. Currently working on reconciling the source code with the documentation (I built all the client-side RPC calls using the documentation).
06:38:51 <Mmmmmmmmmm> So there are some commands that I haven't added yet
07:05:12 <zib> selsta: same error even with 7219 + 7222
07:05:35 <selsta> could you post the exact error?
07:05:58 <selsta> 7219 removes the whole check so it is unlikely the same error
07:07:01 <selsta> also did you rebase release-v0.17 to the latest version?
07:08:03 <selsta> also did you restart CLI + daemon?
07:08:07 <zib> let me do some verification
07:08:50 <selsta> I did a full wallet scan from height zero with release-v0.17 + 7219 + 7222 and did not have issues
07:09:08 <selsta> but would be good to know if there are still issues
07:09:23 <zib> like you said. 7219 should have removed the error but i'm still seeing it. Maybe the make clean didnt wipe it all heh
08:21:01 <zib> selsta: yeah there was some inconsitency, make clean, make again and it works.
08:21:08 <zib> sorry for bugging you ;)
09:23:20 <mj-xmr> @sels
09:24:09 <mj-xmr> selsta: RE: ccache. Could you give me a branch name or something? I agree with hyc, that it could be linkage problem.
09:24:29 <mj-xmr> but I'd like to experiment on this.
09:59:42 <mj-xmr> selsta: Now that I look at the code, your error might be a result of a non-conformant main(), because it misses the argc and argv. While you're there, could you please replace main() with main(int argv, const char * argv[]) ?
10:00:06 <mj-xmr> sorry, main(int argc, char * argv[])
10:02:39 <hyc> the compiler doesn't care about that
10:03:58 <mj-xmr> I'd ask the compiler what it thinks :)
10:04:41 <hyc> it's always legal in C for a function to use fewer arguments than were passed to it, and ignore the rest.
10:05:32 <hyc> and the linker won't care either, it just needs to know the function name and address.
10:07:17 <mj-xmr> My suspicion is, that clang generates a warning of a non-conformant main(), and this triggers a non 0 return code. Possibly because this warning is treated as error now. Who knows without checking it.
10:09:38 <hyc> which is why we need to see the stderr output, yes
10:10:19 <sech1> hyc this is C++ we're talking about here, but https://en.cppreference.com/w/cpp/language/main_function
10:10:28 <sech1> so int main() {} is also perfectly ok
10:10:58 <hyc> right
10:11:59 <hyc> also read the note about implementation-defined forms... lots of systems passed char *env[] as 3rd argument
10:12:51 <hyc> but again, it doesn't matter, because the C calling convention is defined such that functions can ignore additional arguments beyond what they know about
10:14:20 <mj-xmr> Well if main() is conformant and it the program returns an integer, then I don't know.
10:15:15 <hyc> most likely some other env var is wrong in the invocation that cmake spits out
10:15:34 <hyc> but agai, we can't know without seeing the actual invocation and its output
10:15:44 <hyc> which cmake always makes so hard to obtain...
10:20:55 <mj-xmr> ccache is also not something you'd use to produce a release version of a rocket guidance computer.
10:21:10 <mj-xmr> or even a car.
10:27:04 <mj-xmr> But in that case, I'd try:
10:27:05 <mj-xmr> execute_process(COMMAND "${ICECC_CXX_COMPILER}" "${TEMP_CPP_FILE} 2>&1 /tmp/ccache-log"  RESULT_VARIABLE RET)
10:27:15 <mj-xmr> and
10:27:21 <mj-xmr> cat /tmp/ccache-log
10:27:40 <mj-xmr> ICECC_CXX_COMPILER -> CCACHE(...)
12:03:17 <SaltilloLC> ryo_ru: If i was on their place i would shit bricks daily from recognising a thought thatactually more inclined and financial backed guys can come and knock you down. So i would hurry for resolution asap
12:03:18 <SaltilloLC> fice: But they are stupid and short sighted, with each release they think it is the last one, pat themselves on the back and declare mission accomplished. Welcome to Monero. Are you tired of winning yet?
12:38:46 <aichi-japan> my monerod status says 2262781/2262781 (100.0%) but wallet syas Refreshed 2248083/2262781(out of sync)?
12:42:42 <selsta> aichi-japan: self compiled monero?
12:43:19 <aichi-japan> yes , master 2bccbee
12:44:35 <selsta> ok, you need 7218 + 7221
12:44:48 <selsta> we will merge them today
12:45:21 <aichi-japan> fine
12:46:19 <sech1> selsta what's the back story about 7218?
12:51:08 <selsta> array limit broke wallet sync and wallet changes would have been required
12:51:48 <selsta> though I wonder if 7221 is enough for wallet sync, can try it I guess
12:59:19 <selsta> mj-xmr: will try but afaik it failed due to complaining about missing -lc++
13:00:05 <mj-xmr> How did you figure it out?
13:01:03 <mj-xmr> hyc: Error: ld: library not found for -lc++
13:01:05 <mj-xmr> I see
13:02:01 <mj-xmr> Now I understand the whole conversation :)  I didn't have my coffee back then yet :)
13:03:15 <mj-xmr> So this would mean, that my CMake -> CCache invocation is missing a standard library path via -L
13:05:43 <mj-xmr> Maybe you can use CMAKE_CXX_FLAGS variable around the invocation, or like hyc said, add the -c option.
13:06:34 <mj-xmr> I think using the CMAKE_CXX_FLAGS var would make a more versatile test - ie. testing what you would actually get from CMake in near future, after the check is done.
13:07:44 <mj-xmr> execute_process(COMMAND "${CCACHE_FOUND}" "${CMAKE_CXX_COMPILER}" "${CMAKE_CXX_FLAGS}" "${TEMP_CPP_FILE}"  RESULT_VARIABLE RET)
13:07:54 <mj-xmr> or
13:08:03 <mj-xmr> execute_process(COMMAND "${CCACHE_FOUND}" "${CMAKE_CXX_COMPILER}" "-c" "${TEMP_CPP_FILE}"  RESULT_VARIABLE RET)
13:08:24 <mj-xmr> Please let me know if it worked. I need a break now.
16:38:55 <selsta> can a second person take a look at 7221? it works fine but a code review would be good
16:38:58 <selsta> sech1 maybe :D
16:39:33 <sech1> maybe
16:39:37 <selsta> moneromooo: could you rereview / reapprove 7207 after I added vtnerds suggestions?
16:39:44 <selsta> afterwards we have everything for the tag
16:40:44 <sethsimmons> Will this be v0.17.2.0 because it contains so many fixes?
16:41:18 <dEBRUYNE> I'd prefer it, but we need to get ahold of someone at Ledger to update the Monero App
16:41:19 <selsta> we can’t call it v0.17.2.0 without breaking ledger support... annoying but that's how it is
16:41:50 <sethsimmons> Ahh
16:41:54 <sethsimmons> That’s.. obnoxious
16:43:57 <selsta> I doubt that the attacks will be over after this release
16:44:04 <moneromooo> OK, maybe in a couple hours. I'll need to go read asio docs for this.
16:44:12 <selsta> soo we still have time for 0.17.2.0
16:44:13 <selsta> ok thanks
16:44:57 <binaryFate> <selsta> I doubt that the attacks will be over after this release <-- agree
16:46:00 <selsta> mj-xmr: execute_process(COMMAND "${CCACHE_FOUND}" "${CMAKE_CXX_COMPILER}" "-c" "${TEMP_CPP_FILE}"  RESULT_VARIABLE RET) works
16:46:23 <mj-xmr> and CMAKE_CXX_FLAGS not?
16:46:53 <sethsimmons> <selsta "I doubt that the attacks will be"> Yeah I’m sure we’ll have more to deal with 🙄
16:47:42 <sech1> reviewed, 7221 looks pretty straight-forward
16:47:46 <selsta> mj-xmr: no
16:47:53 <mj-xmr> OK, thanks for confirming
16:51:19 <mj-xmr> selsta: perhaps with this change the FreeBSD will work as well.
16:53:16 <selsta> mj-xmr: are you going to PR it?
16:53:24 <selsta> .merges
16:53:24 -xmr-pr- 7207 7208 7218 7219
16:53:29 <selsta> .merge+ 7221 7222
16:53:29 <xmr-pr> Added
16:53:58 <mj-xmr> I thought it's already PRd. If not, then sure. I have 30 minutes left until I leave.
16:55:04 <selsta> It is not PRed yet
17:01:36 <mj-xmr> I will want to push one more change after the successful build, to see how FreeBSD reacted.
17:01:54 <mj-xmr> But thanks for the quickest review, I've ever had :)
17:02:04 <mj-xmr> *empty change I meant
17:42:40 <mj-xmr> selsta: please see my comment at 7226
17:43:10 <mj-xmr> We "fixed it" by shutting one eye :)    No J/K. This is not an actual fix.
17:43:32 <mj-xmr> I'll have a closer look tomorrow. At least we know what the cause is.
17:48:22 <selsta> mj-xmr: ok, it used to work fine on mac, it stopped working with a recent compiler or cmake update
17:52:16 <mj-xmr> No surprise for me.
18:02:30 <moneromooo> selsta: approved
18:03:02 <selsta> thanks, please also the branch equivalent 7208
18:03:25 <selsta> luigi1111w: do you have time for merges?
18:22:21 <selsta> also ping Snipa :)
18:22:28 <selsta> afaik we have everything for a tag now once the current merges are done
18:24:30 <Snipa> .merges
18:24:31 -xmr-pr- 7207 7208 7218 7219 7221 7222
18:24:39 <Snipa> Kk, will scan through shortly.
18:24:44 <Snipa> Just on morning standup right now.
18:26:19 <selsta> nice
18:48:11 <Snipa> Merged
18:49:25 <selsta> ty :)
18:49:42 <selsta> I guess let's wait a bit before tag
20:23:56 <sethsimmons> I just built release-v0.17 after those merges and am getting stack traces: https://paste.debian.net/1178785/
20:25:33 <sethsimmons> Seems to be working still but figured I’d share in case its helpful
20:25:41 <sethsimmons> Happy to debug whatever would be helpful.
20:26:57 <sethsimmons> Seems boost related, maybe? I’m compiling with 1.71 IIRC, double checking now.
20:27:32 <iDunk> ...randomx...LargePageAllocator...allocate...
20:27:55 <iDunk> Reboot and try again. Or don't :)
20:28:41 <iDunk> It's probably one of the most common traces now.
20:29:25 <sethsimmons> Ah, good to know, thanks
20:29:27 <sethsimmons> I’ll try that
20:30:16 <sethsimmons> Probably because I just had xmrig paused and not closed when starting monerod, I suppose?
20:31:29 <sethsimmons> Yeah no trace after restart
20:31:34 <sethsimmons> Sorry for the bad report :)
20:31:38 <sech1> If xmrig is paused it still has memory allocated so monerod didn't have enough RAM to create RandomX VM
20:38:11 <sethsimmons> Yeah thats what I figured
22:13:13 <selsta> luigi1111w: are you available later for tagging v0.17.1.8?
22:14:23 <sethsimmons> <sech1 "If xmrig is paused it still has "> Odd, that stack trace started occurring again as soon as I started up XMRig.
22:16:35 <iDunk> It probably means you don't have enough RAM for the amount of mining threads you are running, in addition to monerod doing its own randomx thing.
22:16:47 <sech1> You probably need to allocate more huge pages
22:16:53 <iDunk> Thus running out of huge pages.
22:23:04 <sech1> I've checked the code and this exception should be caught inside RandomX lib and then the VM should be created without huge pages
22:23:10 <sech1> so monerod shouldn't crash
22:24:18 <sech1> It's more like a warning than an error
22:24:23 <sethsimmons> I wonder what changed. All of my Xmrig and monerod config are the exact same. No RAM amount changes, still 32GB
22:24:51 <sethsimmons> I can try bumping huge pages and see what happens.
22:25:02 <sech1> you've run out of available huge pages. You could try to increase vm.nr_hugepages
22:27:25 <sethsimmons> I forgot I never actually set it in sysctl.conf, and relied on XMRig to set.
22:27:37 <sethsimmons> I’ll try increasing from the default that I think XMRig is setting.
22:28:18 <sethsimmons> Any idea whats appropriate for 32GB of RAM?
22:28:24 <sethsimmons> 1280 is the recommended by XMRig
22:28:47 <iDunk> xmrig maybe does set them, but monerod doesn't ;)
22:29:42 <sethsimmons> Weird I’ve never seen this issue before now, but manually setting hugepages to 1512 seems to be working so far
22:29:50 <iDunk> So if you plan running several randomx apps, set them manually to the appropriate amount.
22:30:07 <sethsimmons> Thanks :)
22:38:41 <augusto5> hhi
22:46:02 <luigi1111w> selsta yes
23:09:45 <selsta> luigi1111w: ok please tag whenever you have time
23:09:57 <selsta> v0.17.1.8
23:10:02 <selsta> and once you tagged please ping me
23:28:23 <mnt_grrrl> can someone point me at the gitify docs please?
23:31:16 <selsta> never heard of gitify
23:35:30 <iDunk> contrib/gitian if you meant gitian.
23:59:20 <mnt_grrrl> yes thank you!