@eyedeekay
&kytv
&zzz
+R4SAS
+RN
+RN_
+T3s|4
+dr|z3d
+hk
+not_bob
+orignal
+postman
+wodencafe
Arch
DeltaOreo
FreeRider
FreefallHeavens
Irc2PGuest15271
Irc2PGuest28511
Irc2PGuest64530
Irc2PGuest77854
Nausicaa
Onn4l7h
Onn4|7h
Over
Sisyphus
Sleepy
Soni
T3s|4_
Teeed
aargh3
acetone_
anon4
b3t4f4c3
bak83
boonst
cancername
cumlord
dr4wd3
eyedeekay_bnc
hagen_
khb_
plap
poriori
profetikla
r3med1tz-
rapidash
shiver_1
solidx66
u5657
uop23ip
w8rabbit
weko_
x74a6
zzz
eyedeekay, congrats for knocking about 1500 lines out of the release diff, that's real progress
zzz
ping eyedeekay re: RouterVersion STATUS
zzz
for those who are on the latest and want to cleanup the stray on-disk netdb mess:
zzz
rm -r ~/i2p/netDb ~/.i2p/netDb/client*
zzz
eyedeekay, I suggest you post an advisory somewhere
zzz
actually I've seen "exploratory" also, so:
zzz
rm -r ~/i2p/netDb ~/.i2p/netDb/client* ~/.i2p/netDb/expl*
eyedeekay
Ack will do
eyedeekay
Re: RouterVersion.STATUS it is for embedders/easy-installs now so they can put `alpha` `beta` and `rc` status into the version before the build/extra, so they can have versions like 2.4.0-beta1, etc
mesh
eyedeekay: what you call a 'STATUS' is usually called a 'release qualifier' or 'version qualifier'. Also good idea to keep it all caps so it stands out if present
zzz
eyedeekay, ok, so if we're at 2.4.0-alpha2 and want to go to beta, what will it be...
zzz
2.4.0-beta3? 2.4.0-beta2? 2.4.0-beta1?
zzz
STATUS is the field in RouterVersion, I didn't make it up
eyedeekay
Yeah the intent would be to switch to beta1 after alpha2 in your example
zzz
thats what I thought
zzz
see VersionComparator
zzz
changing BUILD backwards will break unsigned updates
zzz
it needs to be 2.4.0-2-beta1
eyedeekay
Ok I see what you mean
zzz
i.e. STATUS needs to be _after_ BUILD
zzz
you want a ticket?
eyedeekay
Probably better
zzz
coming right up
eyedeekay
Thanks
zzz
np :)
zzz
#441
mesh
btw any news on the "unsupported encryption options" bug?
eyedeekay
Progressing still WIP
eyedeekay
It should go away when I fix lifecycle issues in the newest draft MR on gitlab
eyedeekay
Far and away the lifecycle stuff seems to be trickiest to fix
zzz
want help?
zzz
thought I dropped enough clues on how to do it pretty easily but maybe not...
eyedeekay
Nah I think I got it from here it's just kind of extensive
zzz
if it is extensive, maybe that's the wrong way, you _sure_ you don't want help?
zzz
because the way I'm thinking will fix a lot of your other issues too
eyedeekay
Sure
zzz
you want me to eyeball your WIP, or you tell me what you're doing, or I tell you how I'd do it?
eyedeekay
What I've done so far is split the getSubNetDb into get/create/remove and switched to the primary session as the dbid source, but I can't always get the primary session hash from where I call get* so I had to make a way to get at it
eyedeekay
Tell me how you'd do it
zzz
- remove FNDS HashMap storage
zzz
- store client FNDF in ClientConnectionRunner next to SKM, add create/start/stop code in there next to the SKM equivalents
zzz
add ctx.clientManager().getClientFNDF(Hash) method which can return null
zzz
change all DBID strings to just use the hash instead
zzz
- remove expl subdb which I still dont understand why
zzz
EOT
zzz
this fixes your FNDS thread-safe issues too
eyedeekay
Ack, I'll try it that way. Re: clients_exploratory right now is only still there for debugging, I've been using it to catch any client with a null dbid which should never happen and it will go away soon
zzz
my way solves lifecycle issue by binding the FNDF precisely to the client, removes "magic" FNDF creation, and ensures start and stop always happen
zzz
there's plenty of other ways to do it that could be just as good, dunno. But SKM has the same requirements, and we have no SKM lifecycle bugs atm, so my first thought is to do it just like SKM
zzz
so if you follow down my path, you have to decide whether FNDS.getSubDB() can return null (causing you to add null checks and handling throughout the codebase) or returns the maindb if not found (much simpler, but may have undesirable side effects)
zzz
bug fixes may resolve most of the client-not-found null cases but you almost certainly can't eliminate all possibility due to concurrency
zzz
note that clientManager().getSessionKeyManager(Hash) works for subsession hashes also, so copying that code will solve your subsession problem above also
zzz
would you please start squashing your merge commits again (and change your default in your gitlab settings) to minimize the commit log?
eyedeekay
Yes I will
zzz
thanks :)
zzz
orignal, reproduced U router issue, verified I broke it in January, working on fix now
orignal
for NTCP2 you mean?
mesh
d
mesh
oops, sorry
zzz
orignal, yes
zzz
it's an NTCP2 bug, not updating the address after transitioning to firewalled