IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#i2p-dev
/2022/04/14
+R4SAS
+RN_
+acetone
+mareki2p
+orignal
+postman
+qend-irc2p
AlaskaBear
Arch
FreefallHeavens
Irc2PGuest23015
Irc2PGuest24082
Irc2PGuest30827
Irc2PGuest60679
Irc2PGuest61348
Irc2PGuest64300
Irc2PGuest6656
Irc2PGuest77286
Irc2PGuest88388
MatrixBot
NiceBoat
Onn4l7h
Onn4|7h
Over1
Romster_
Sisyphus
Sleepy
U1F642
Zapek
aargh3
ahiru
ananas
anontor
b3t4f4c3__
cims
dhvkm
duanin2
eche|off
eyedeekay_
hagen_
leopold
mahlay
makoto
marek
marek22k
n2
nilbog
noidea
not_bob_afk2
nyaa2pguy
o3d3
poriori
profetikla
rapidash_
rednode
solidx66
stormycloud[m]
sublimia
test3847473
u0_a292
uop23ip
wodencafe
zelgomer
zzz
Irc2PGuest40217 Defintion: skift - a little boat that is running late
dr|z3d got a java.lang.NumberFormatException issue, zzz. i2ptunnel.jar doesn't like b64s piped to ping with a leading -
zlatinb the rekeying happened again. It seems that it's happens always after extended downtime if firewalled
zlatinb extended == about a day
zlatinb 3 threads this time
zzz zlatinb, that looks like an equivalent deadlock as yesterday, in getPorts(), are you running with the fix, because it doesn't look like it
zlatinb no, still 1.7.0
zlatinb it's hard to update to git build when running an embedded router
zzz re: rekeying, I think I finally see why it's happening
zzz checkin yesterday prevented the rekeying but this one fixes the root cause
zlatinb I'm not sure I follow the logic but I'll update my standalone router and give it a few days
zzz yeah it's 100% reproducible for me now so I'm pretty sure I got it
zlatinb how do you reproduce it?
zzz firewalled peer, shutdown for an hour, like you said
zzz whataboutit
mesh what do you think? is that something that could happen?
zzz we already discussed it
zzz since you have a workaround, it's low priority
mesh the split packages are a big pain and there's no good work around. I figure renaming them on your end is the easiest solution but not sure what the impact might be
zzz if you don't want us to forget about it, create an issue on our repo, not yours
zzz you said that putting apache first in the classpath was an effective workaround
mesh zzz: if we keep apache components off the modulepath and ahead of i2p on the classpath it will "work" but this isn't really a solution
zzz so you agree it's an effective workaround for now?
mesh zzz: for developers running code inside eclipse it will work. I don't think it makes sense to even try to release to users like this
mesh before we do a bunch of work trying to hack around this, I guess the question is, is this something that could be fixed on your end in the near future? I imagine a package rename should be a simple affair but I don't know the impact
zzz it's been like that for 7 years, you're the first to complain
zzz as I said, I assess it as low priority. the way to get something fixed is to put an issue on our repo and state your case, not by bugging me
zzz thank you
obscuratus I had some intermittent success replicating the re-keying issue on start-up last night on -13, but I just tried to replicate with -14, and didn't run into any occurances.
T3s|4 o/ zzz: some minor end-user input: when running -13 against fully updated ArchLinux with java-18-openjdk (default), I see nothing unusual or of concern
zzz thanks obscuratus I'm optimistic I finally got it
zzz thanks T3s|4 not expecting any issues with 18, I know zlatinb is testing also
T3s|4 thanks zzz, good to know, but I will report if 'new' problems appear so you can have a look
zzz ok. rumor has it that it uses less memory