08:15:37 <tankf33der> o/
08:17:12 <tankf33der> found undefined behavior in hmac+keccak, where to report better?
08:23:16 <sech1> https://github.com/monero-project/monero/issues
08:23:52 <tankf33der> sech1: ok
09:45:01 <ErCiccione[m]> We really need a clarification from the core team about when are hard forks are going to happen. Last time i brought this up in a dev meeting, seemed like nothing changes and we are still going for hard forks every 6 months. Then  i read of people mentioning that we moved to 9 months hard fork and now i'm reading the logs of yesterday's MRL meeting and people were assuming that now we have yearly hard forks.
09:45:21 <ErCiccione[m]> So, what's the deal? Ledger/trezor devs also asked for a timeline, but i think nobody can give one.
09:46:14 <ErCiccione[m]> I remember luigi mentioning that core were thinking about changing forks time, but rightn ow i have really no idea of what's going on.
09:46:37 <ErCiccione[m]> Can we have a final word on this? This uncertainty isn't helping anybody
11:12:35 <moneromooo> It's uncertain because we don't know. If we don't know, we can't tell you.
11:13:10 <moneromooo> I'm not sure why you'd want to determine in advance when we'll fork. It'll be decided when it is.
11:13:37 <moneromooo> There's no point in forking on a particular date just because there's a date.
11:25:27 <ErCiccione[m]> That's a bit of a contrast with what we always said: "let's keep a scheduled hard fork time so that merchants and service are prepatred and know when to expect a network upgrade". If now we moved to "we fork when it's needed" we should make that known and clear, because now somebody think we cfork every year, somebody every 9 months and somebody every 6.
11:26:23 <dEBRUYNE> That was the expectation, but in practice most services weren't aware a HF would be performed
11:26:38 <dEBRUYNE> Also we were constantly trying to scramble to get everything out on time imo
11:27:59 <moneromooo> Well, different people want different things.
11:28:48 <dEBRUYNE> The RandomX fork arguably went really smooth and it is probably because we deviated from the original schedule
11:28:53 <ErCiccione[m]> That's what i'm saying. This uncertainty is going to be a problem, because at the end is core that decide
11:29:33 <dEBRUYNE> I cannot speak with certainty, but I think most of core are basically in line with what mooo stated
11:29:49 <ErCiccione[m]> I'm only asking to clearly define a workflow here, because something this important cannot be "everyone has a different opinion", because people expecting a fork in one year will have their plans messed up if it happens after 6 months, same for all the other cases
11:30:25 <ErCiccione[m]> dEBRUYNE: I would just like to have a clear statement. Last time luigi said that core was working on the problem of the schedule and nothing else from that moment on
11:31:21 <moneromooo> CLSAG's really the only thing we'd want in a fork IIRC. And we don't know when it'll be mergeable due to the audit that's going nowhere in a hurry.
11:32:11 <moneromooo> Now there's the gingeropolous method, which is to fork anyway even with no actual changes, just to keep people running recent software :)
11:34:26 <dEBRUYNE> moneromooo: Do you know who took it upon them to manage the audit?
11:34:27 <ErCiccione[m]> Isn't this discussion proving my point? 🙂 We really don't know, but we need to give timeframes. Trezor (or ledger, don't remember) asked for a date of the next hard fork because they have to be prepared. If we tell them 1 year because some of us think that's the schedule and then we fork after 4 months, it's going to be a problem.
11:35:46 <ErCiccione[m]> There is an audit workgroup afaik
11:37:12 <moneromooo> I don't know.
11:38:38 <ErCiccione[m]> To further clarify my point: i don't care of the timeframe for the HF (1 year, 9 months, 6 months, when it's needed). I care that there is a defined plan and that we are all aware of it. That's what i'm asking core.
11:44:39 <dEBRUYNE> I do agree it would be good to have a blog post or a similar document to which we can point
11:44:48 <dEBRUYNE> Perhaps this can be discussed in the next dev meeting?
11:44:55 <dEBRUYNE> <moneromooo> I don't know. <= All right, I will ask around
11:48:30 <ErCiccione[m]> That would be good. Last time i didn't have much success.
13:55:59 <RowanSkye> Hey guys, any tips on creating a coin of my own? I have plans to use either an EOS token, an SLP token, or a coin?
13:57:28 <moneromooo> Sure, first tip is to ask in a channel where it's on topic.
14:17:14 <RowanSkye> alright
14:17:17 <RowanSkye> my bad
14:38:25 <stackdump66> trying to run monerod on 64bit rasbian - getting a crash https://gist.github.com/stackdump/fe68c4bdfcc6394b5473a005bb7af5c4
14:38:42 <stackdump66> there is a crashfile produced - not sure what else I can try to debug
14:39:00 <moneromooo> Did you build this for hte right arch ?
14:39:07 <moneromooo> ie, armv8/armv7 etc.
14:39:08 <stackdump66> I downloaded the binary
14:39:22 <moneromooo> Did you download a binary for the right arch ?
14:39:31 <stackdump66> yes AFAIK
14:40:04 <moneromooo> Try setting the env var: MONERO_USE_SOFTWARE_AES=1, then run again.
14:40:48 <stackdump66> similar result
14:41:10 <moneromooo> What does gdb say the ill insn is ?
14:44:08 <stackdump66> sorry minimal experience w/ using gdb - what should I do?
14:44:43 <moneromooo> gdb monerod
14:44:44 <moneromooo> run
14:44:49 <moneromooo> li
14:45:07 <moneromooo> It should show the instructions around where it died.
14:45:49 <stackdump66> awesome - it shows "1       ../sysdeps/unix/sysv/linux/aarch64/init-first.c: No such file or directory."
14:46:30 <stackdump66> hah well maybe this is more relevant Program received signal SIGILL, Illegal instruction.0x0000aaaaab23232c in aes_expand_key ()(gdb) li
14:47:38 <moneromooo> It's apparently trying to use aes insns which your CPU does not have.
14:48:11 <moneromooo> If MONERO_USE_SOFTWARE_AES=1 does not help, you need to tell your compiler to not generate aes insns.
14:48:32 <moneromooo> Or find a binary where this was done.
14:49:55 <stackdump66> cool I can try to make a build
14:50:55 <stackdump66> I did try to compile *on* my PI - generally should I be doing this from another X64 Linux & cross-compiling?
14:51:18 <moneromooo> Cross compiling will be faster if you already have a setup for it.
14:52:03 <stackdump66> thx I'll try to do this
15:04:17 <bysnack> Hey moneromooo, about the serialization discussion you had before... I was doing some research about what can be adapted in epee::serialization for the json structures to use rapidjson.
15:04:17 <bysnack> I have also seen a PR by vtnerd which replaces the rapidjson streams with a byte stream class for zmq which could be used there too.
15:04:17 <bysnack> The main idea is to keep the current abstraction improving the json serialization speed and code maintainability, which is quite hard to read right now, with a well known and maintained library as rapidjson.
15:04:17 <bysnack> There were some discussions in the past about doing this but I'd like to ask just in case before actually getting into it, could we want this?
15:04:17 <bysnack> BTW the main benefits of doing so are here https://github.com/bertptrs/json-speedtest
15:06:57 <moneromooo> I'm not buying the maintenability argument. It'll just be other problems. I don't like big changes just because someone prefers another lib. IIRC the speed tests did demonstrate a good advantage to switching though.
15:10:01 <moneromooo> (and to build time)
15:12:00 <moneromooo> So if someome were to do this and the claimed gains were confirmed, I'd be fine with the change. Though I'd prefer if the author tried to keep the diffs contained if possible.
15:13:30 <bertptrs> Hey, an unexpected mention. I think someone suggested a "bastard child of epee and rapidjson" to keep the diff down when I showed this? I never got around to implementing it unfortunately
15:16:28 <moneromooo> I do recall something like this.
15:20:52 <bysnack> Sounds like a plan
17:41:21 <moneromooo> hyc, vtnerd: any idea about the last comment in https://github.com/monero-project/monero/issues/6454 ?
17:41:29 <moneromooo> I don't see what's undefined.
18:10:56 <hyc> looking
18:11:41 <hyc> unsigned long compared to unsigned long? wtf is wrong with that? I think the tool is broken
18:12:34 <hyc> what's different in bytecoin's keccak.c ?
18:13:03 <moneromooo> IIRC I added the aligned test at some point.
18:14:12 <moneromooo> There's probably something clever going on I can't see.
18:14:24 <moneromooo> Oh.
18:14:32 <moneromooo> Wait, no.
18:15:00 <moneromooo> I was thinking alignment, but the pointer would have the right alignment in memory would it.
18:15:19 <hyc> the address of the pointer, vs what it points to?
18:15:28 <moneromooo> Yes.
18:15:42 <moneromooo> What it points to is not necessarily aligned (thus the test).
18:15:43 <hyc> yah, compiler would ensure the pointer itself is aligned
18:15:59 <hyc> and nobody is taking the address of the pointer there
18:16:07 <moneromooo> Could there be a compiler with 32 bit pointers and 64 bit unsigned long ?
18:16:44 <hyc> mm, yes possible
18:17:08 <moneromooo> Yeah, doesn't matter, even if the pointer was aligned on 32 bit only, the compiler should memcpy properly to use as uint64_t.
18:17:10 <hyc> that's the x64 model actually. 64bit registers but only 32bit address space
18:18:10 <moneromooo> Sounds like a waste. You need large pointers before large ints usually.
18:18:25 <moneromooo> And then you can use long long if you do.
18:18:34 <hyc> I guess it's for some number crunchers, dunno who really uses it
18:19:38 <sech1> https://stackoverflow.com/questions/10473573/why-is-out-of-bounds-pointer-arithmetic-undefined-behaviour
18:20:12 <hyc> that's not the situation here
18:20:13 <sech1> not a real problem on our platforms
18:20:21 <sech1> #define IS_ALIGNED_64(p) (0 == (7 & ((const char*)(p) - (const char*)0)))
18:20:29 <sech1> that's exactly the situation here
18:21:33 <sech1> or no
18:21:38 <moneromooo> IIRC, pedantically doing this subtraction is undefined to cater for segmented archs.
18:22:02 <moneromooo> Segmented or otherwise machines with different types of memory.
18:23:00 <sech1> https://news.ycombinator.com/item?id=4374598
18:23:05 <hyc> why is that test not just (!(p & 7)) ?
18:23:16 <sech1> so technically the current macro is UB
18:23:38 <moneromooo> Feels more polite to cast pointer to integer first :)
18:23:44 <hyc> fair enough
18:24:11 <hyc> anyway, casting to uintptr_t is legal, and taking anyt int & 7 is legal
18:24:17 <hyc> so I think the tool is broken
18:24:54 <moneromooo> sech1's link says "any other arithmetic". Though that's not a standard quote.
18:25:08 <hyc> bitops aren't arithmetic
18:25:12 <moneromooo> So I guess &7 would be arithmetic. Is bit twiddling considered... ok.
18:26:40 <hyc> even so, you're doing &7 of a uint, not a pointer
18:26:56 <sech1> I don't see anything wrong with #define IS_ALIGNED_64(p) ((((uintptr_t)p) & 7) == 0)
18:27:06 <sech1> it should be correct everywhere
18:27:41 <moneromooo> Maybe some archs have ints so small 7 is off the range ^_^
18:28:44 <sech1> I think that tool is broken: "warning: The following sub-expression cannot be evaluated:" hence the error later
18:37:29 <hyc> agreed. if it can't evaluate a subexp (unsigned long)x & (unsigned long 7) it's braindead
18:37:57 <hyc> I think they should report this to the tool maker
18:38:01 <hyc> not us
18:38:26 <moneromooo> I suspect it's not that dumb, and the messages may be non obvious.
18:38:53 <hyc> then report to the toolmaker that their diagnostic messages suck
18:38:55 <moneromooo> Like, it can't because of a constraint somewhere that it's not mentioning.
18:38:59 <moneromooo> Fair.
18:42:10 <hyc> none of this source line numbers correspond to our source
18:42:15 <hyc> s/this/his/
19:11:34 <gingeropolous> of course, the other option is to make compiling the wallet optional.
19:12:11 <gingeropolous> if wallet2.h is only used when creating monero-wallet-cli .
19:12:53 <gingeropolous> just making up a random statistic, but i'd bet 80% of the time, a developer compiling monero is optimizing/hacking something in the daemon
19:13:20 <gingeropolous> but then again its me, and for all i know wallet2.h is used when compiling the daemon because logic.
19:14:32 <gingeropolous> for the record, this is regarding the compile time reduction ccs / effort
19:15:02 <moneromooo> You can already compile just the daemon, that's what I do.
19:15:08 <moneromooo> (and deps)
19:15:29 <gingeropolous> right, but something something defaults
19:15:37 <gingeropolous> something something
19:16:44 <gingeropolous> hell thats probably a makefile mod, right? i bet even i could figure that out
19:17:03 <moneromooo> Yes. Two lines. Including a blank one.
19:20:38 <gingeropolous> we'll see. i surprise myself with how incompetent i am sometimes
19:23:49 <moneromooo> Actually, I was thinking of "all:\n\n", and you'd have to do make -C build/release daemon wallet otherstuff, but that can't work since you have to run cmake anyway.
19:33:27 <UkoeHB_> who needs enemies when you have your inner voice
19:47:15 <hyc> I usuallu just cd src/daemon and then do a bunch of makes from there
21:03:07 <sarang> Has the `test-ubuntu` CI action been disabled/removed?
21:03:28 <sarang> It doesn't appear in a recent commit/push I did on a branch
21:04:51 <selsta> no
21:05:10 <selsta> it just starts once the build-ubuntu one is finished
21:05:22 <selsta> so it will look invisible at first
21:05:30 <sarang> Heh, so I've clearly missed that _the entire time_
21:05:31 <sarang> =p
21:05:45 * sarang goes away now
21:05:51 <selsta> we could start it from the beginning, not sure if that would be preferred
21:06:21 <sarang> Yup, just appeared now that `build-ubuntu` completed :)
21:11:14 * sarang withdraws his comment
21:38:51 <UkoeHB_> https://github.com/monero-project/monero/issues/6456