-
selsta
luigi1111w: let's act like 3 hours passed
-
gingeropolous
the earth is spinning faster according to the internets
-
selsta
luigi1111w: need to go to sleep soon and would like to tag before that
-
nioc
luigi1111 approved these changes 3 hours ago
-
ofrnxmr[m]
luigi1112: luigi1111_:
-
ofrnxmr[m]
(He did say to said msg all of them 😅)
-
luigi1111w
merged
-
selsta
luigi1111w: tag pls whenever you wake up and come online
-
Guest29
Wht is all this stuff,i am just tired of the questions in mind. As ECC is based on discrete logarithm problem but everyone knows Dlp repeats the sames result when squaring crosses modNo-1 means two relativity prime no and the mod one is 17 the no squared is 7 when reaches 7^17-1 the result produced will be same so do the same happens in ecc or not
-
luigi1111w
.
-
sech1
I've started building v0.18.1.0
-
jeffro256[m]
@Guest29 Could you try rephrasing please? I'm having trouble parsing that sentence
-
jeffro256[m]
.merges
-
xmr-pr
8299 8323 8352 8359 8379 8381 8415 8419 8427 8428 8442 8444 8450 8460 8462 8464 8465 8490
-
jeffro256[m]
@selsta luigi1111w are we merging the stuff in the merge queue before tagging 18.1.0 or just tagging ?
-
luigi1111w
the queue has nothing to do with the taggin
-
luigi1111w
g
-
jeffro256[m]
well yeah but I was under the assumption that we were gonna flush the queue before tagging 0.18.1.0
-
selsta
different branches
-
selsta
v0.18.1.0 is tagged at all who participate in reproducible builds
-
jeffro256[m]
Ah, I didn't release that ALL of them were master merges. That makes sense
-
scoobybejesus
-
sech1
my hashes match with these ^
-
sech1
still building (Windows and MacOS left)
-
selsta
please upload them again like last time
-
sech1
sure
-
hyc
just started a build
-
sech1
I'm on a notebook so it's sloooow
-
hyc
my linux hashes match scooby
-
hyc
ca8c9daeaee758d482d5cde94912d33b2f62656719c821b2a496fd81c0d52a79 monero-aarch64-linux-android-v0.18.1.0.tar.bz2
-
hyc
0ea5ddb0630d6657810d38b1968ae76ba8e54806f46a2cc9bd02602f999aa741 monero-arm-linux-android-v0.18.1.0.tar.bz2
-
hyc
1076d260b8b8fe513653916dabfa3c3790030836750d3af6bca56fc138a06af1 monero-x86_64-unknown-freebsd-v0.18.1.0.tar.bz2
-
hyc
ed18233503b6135a29732a79b261b50aced24b99686843bc11e7e9fb2d50cf42 monero-i686-w64-mingw32-v0.18.1.0.zip
-
hyc
d0e2b3255163ec0499de42639cc86cf4ddae0bc5fa65aa7377ff9c40305da8fd monero-x86_64-w64-mingw32-v0.18.1.0.zip
-
hyc
065766f5799c6b972145e2b27830a584c18f64bdd276f31801493b7ef9e51b3c monero-aarch64-apple-darwin11-v0.18.1.0.tar.bz2
-
hyc
da87ac5c713f17985cd57bcd007ec76ffe75123cb546cd655edb14fdd8c3d745 monero-x86_64-apple-darwin11-v0.18.1.0.tar.bz2
-
hyc
all done
-
sech1
lol, how many CPU cores do you have?
-
sech1
I started 2 hours before it was tagged, and it's still building on my notebook
-
hyc
8 cores, make -j8
-
sech1
hmm, I use 4 cores and it's been going for almost 4 hours. Maybe it's because it's a fresh Ubuntu VM
-
hyc
this system already built v0.18.0.0 so all the dependencies were already present
-
sech1
-
sech1
selsta binaries:
p2pool.io/v15
-
selsta
ty
-
sech1
Running v0.18.1.0 on my nodes, so far so good
-
hyc
just noticed this on my v0.18.0.0 console
-
hyc
2022-08-10 12:38:10.371 I Recalculating difficulties from height 2661600 to height 2686520
-
hyc
never seen that before
-
selsta
it shows up once per week or so
-
hyc
ok. well, it's on 18.1 now
-
sech1
It was a workaround for some old difficulty bug which is fixed now, but the weekly recalculation is still there just in case
-
selsta
difficulty bug was not fully fixed while
monero-project/monero #8384 was merged
-
selsta
so there is still a bug somewhere
-
hyc
hmm. not reassuring...
-
selsta
but it's also possible that it got triggered because "Make RPC server functions that read db thread safe" was wrong
-
selsta
sech1: i remember you also got back inconsistent data with it, right?
-
sech1
yes, ZMQ notification returned new block, but get_block_template returned the old block height
-
selsta
since we currently calculate the difficulty once with cache and once without there is no risk if a difficulty drift is detected, it would just print a spammy log message
-
jberman[m]
unless I'm missing something I don't think 8384 is related to this difficulty recalculation
-
sech1
it isn't
-
selsta
not recalculation
-
selsta
while we had 8384 merged the daemon would get a difficulty drift every couple days
-
selsta
the cache and the non cache values would drift apart
-
selsta
ofrnxmr[m] can confirm
-
jberman[m]
interesting
-
selsta
sorry, not 8384 but the patch that got reverted by it
-
jberman[m]
right I follow, that's strange
-
selsta
-
hyc
huh, #8491 didn't get merged into v0.18.1.0?
-
selsta
should be fine to include in the next release
-
selsta
.merge+ 8491
-
xmr-pr
Added