@eyedeekay
&kytv
&zzz
+R4SAS
+RN
+RN_
+dr|z3d
+hk
+orignal
+postman
+wodencafe
Arch
DeltaOreo
FreeRider
FreefallHeavens
Irc2PGuest10850
Irc2PGuest19353
Irc2PGuest23854
Irc2PGuest46029
Irc2PGuest48064
Irc2PGuest77854
Nausicaa
Onn4l7h
Onn4|7h
Over
Sisyphus
Sleepy
Soni
T3s|4__
Teeed
aargh3
acetone_
anon4
b3t4f4c3
bak83_
boonst
cumlord
dr4wd3_
eyedeekay_bnc
hagen_
khb
mittwerk
plap
poriori
profetikla
rapidash
shiver_
solidx66
u5657_1
uop23ip
w8rabbit
weko_
x74a6
zzz
eyedeekay, in your recent prop. 166 rewrite, you've sprinkled "I2P Socket" everywhere
zzz
I believe what you intended was I2PSocketManager ?
zzz
an i2p socket is, of course, just a single socket
eyedeekay
Yup, looks like it, thanks for pointing out the error, I will edit that today
zzz
2.6.1 release status eyedeekay ?
eyedeekay
core release has been done for weeks, I have the 2.6.1 Easy-Install Bundle "done" in that I've got it all together to flip the switch, but I've either got a sophisticated user-error or a complicated bug that's got me worried to point people at it until I know which it is
eyedeekay
because I received an immediate report of a potential critical bug in it, which I can't reproduce or rationalize how it could have happen at all
eyedeekay
The reporter claims that the bundle is using the wrong config directory after the update, resulting in an entirely new config directory being created with entirely new clients.config.d, tunnels.config.d, etc
eyedeekay
So it works, but they end up with entirely new config files, according to them
eyedeekay
AFAICT this is impossible, because the part that computes the config directory hasn't changed since 2.2.0, and updates continued to work after that
eyedeekay
The only thing that's changed is that it no longer checks for a regular I2P install before running, it just runs from it's own directory which is a subdirectory of the install directory and it's always the same subdirectory
eyedeekay
and I can't reproduce it so I'm losing my mind because I want to flip the stupid switch and I'm either being trolled or I made something worse or if the reporter has done something that has broken their install
eyedeekay
The reporter claims that the bundle is not conflicting with an existing I2P installation
eyedeekay
but also claims that they have switched back between install types multiple times
eyedeekay
which means they might have got a non-jpackaged update by migrating router.config files which would break their install
eyedeekay
So I will flip the switch when I am sure I'm not going to break every single one of them, which should also be today
dr|z3d
could be windows version dependent, eyedeekay
dr|z3d
I've seen strange behavior in the past wrt profile dirs on windows.
eyedeekay
Yeah that had crossed my mind too
dr|z3d
iirc I've seen a profile stored deep in the bowels on c:\windows\system32\
dr|z3d
*of
eyedeekay
There's also NSIS where I, in several places, reference environment variables which sometimes change between Windows versions, which is another reason why I'd like to ditch NSIS soon, but it's a chicken-or-egg thing, I need to know the existing updates work well enough to migrate to a new style of updates
eyedeekay
My plan for today is to work through all the possible circumstances in VM's starting from a new snapshot for both 10 and 11, and try updates from 2.1.0-2.6.1, 2.3.0-2.6.1, and 2.5.2-2.6.1 with fresh router.configs and router.configs migrated from an actively used i2p.i2p installation
eyedeekay
Oh also, different configurations of Windows(even the same version) have different ways of handling NSIS, including some that disable silent mode entirely, which will also break updates
eyedeekay
Others disable argument passing...
eyedeekay
that could be it
eyedeekay
because if it doesn't have the install directory passed to the installer, and the install directory is not the default, it would make a new install in the default directory and immediately start it...
eyedeekay
but the installer would still have the PID of the old one from the old install directory so that's the one it would kill
eyedeekay
And... non-default directory gets erroneously migrated to default directory? that's plausible
eyedeekay
Have to test that too
zzz
hpmh. ok, thanks for update, good luck
eyedeekay
the last one that I just thought of seems likely at the moment, it's a complicated part, the UPP sets up environment variables with details about the install before launching NSIS, then NSIS reads them and handles them, like it sleeps in a loop while it checks if the PID of I2P.exe still exists and doesn't attempt to place files until it's gone, it gets the real install directory instead of the default,
eyedeekay
there's the initial communication between the 2 executables and it could have broken down, just working on why