IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#i2p-dev
/2024/09/03
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\
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