On Fri, Aug 7, 2009 at 3:24 PM, Matthew Toseland<[email protected]> wrote: > On Friday 31 July 2009 01:53:59 Juiceman wrote: >> On Thu, Jul 30, 2009 at 1:04 PM, Matthew >> Toseland<[email protected]> wrote: >> > On Sunday 26 July 2009 00:20:03 Matthew Toseland wrote: >> >> On Monday 13 July 2009 07:03:53 Juiceman wrote: >> >> > On Sat, Jun 13, 2009 at 1:57 PM, Zero3<[email protected]> wrote: >> >> > > Matthew Toseland skrev: >> >> > >> On Tuesday 02 June 2009 09:22:13 Zero3 wrote: >> >> > >>> Matthew Toseland skrev: >> >> > >>>> On Thursday 21 May 2009 17:32:55 Juiceman wrote: >> >> > >>>>> On Thu, May 21, 2009 at 6:58 AM, Zero3 <[email protected]> >> >> > >>>>> wrote: >> >> > >>>>>> Matthew Toseland skrev: >> >> > >>>>>>> On Sunday 17 May 2009 11:41:00 Zero3 wrote: >> >> > >>>>>>>> Matthew Toseland skrev: >> >> > >>>>>>>>>> Detecting the version of an installed application in the >> >> > >>>>>>>>>> launcher (at >> >> > >>>>>>>>>> least in Windows) shouldn't be a problem. It will most >> >> > >>>>>>>>>> likely be >> >> > >>>>>>>>>> registered in the registry next to the .exe path we are >> >> > >>>>>>>>>> checking already >> >> > >>>>>>>>>> for the individual browsers. We can also check the version >> >> > >>>>>>>>>> info of .exes >> >> > >>>>>>>>>> as an alternative (most Windows applications are compiled >> >> > >>>>>>>>>> with various >> >> > >>>>>>>>>> static info like version and author). The Windows launcher >> >> > >>>>>>>>>> is already >> >> > >>>>>>>>>> running Chrome with a command line argument making it start >> >> > >>>>>>>>>> in privacy >> >> > >>>>>>>>>> mode btw. >> >> > >>>>>>>>> You should prioritise Chrome with privacy mode over Firefox >> >> > >>>>>>>>> without it. >> >> > >>>>>>>> Agreed: https://bugs.freenetproject.org/view.php?id=3118. >> >> > >>>>>>> I thought you had already done this? >> >> > >>>>>> At time of writing, no. But since then I managed to figure git >> >> > >>>>>> out and >> >> > >>>>>> changed it (hence the bug is now "resolved"). >> >> > >>>>>> >> >> > >>>>>> ... which leads to another thing to consider: We need to make it >> >> > >>>>>> possible to update the start.exe/stop.exe/freenetlauncher.exe >> >> > >>>>>> files for >> >> > >>>>>> existing users when new updates are made available. >> >> > >>>>>> >> >> > >>>>>> The easiest way to do this right now would probably be to add >> >> > >>>>>> them to >> >> > >>>>>> the update.cmd script. >> >> > >>>>>> >> >> > >>>>>> - Zero3 >> >> > >>>>>> >> >> > >>>>> I would be happy to do this, however I will need a defined >> >> > >>>>> directory >> >> > >>>>> structure on the download site, with known file names. Like we >> >> > >>>>> have >> >> > >>>>> the .url link for the freenet.jar. I believe I can use the .sha1 >> >> > >>>>> file >> >> > >>>>> to check for updates if you want to have a static name. ie >> >> > >>>>> wrapper_win32x86.exe etc. Also I would prefer to not have them >> >> > >>>>> inside >> >> > >>>>> a zip unless we have have a built-in unzipping program in Windows >> >> > >>>>> I >> >> > >>>>> can reliably call by command line. Otherwise we will have to >> >> > >>>>> bundle >> >> > >>>>> yet another third party utility. >> >> > >>>> Well, they should be fetched from >> >> > >>>> http[s]://checksums.freenetproject.org/latest/<filename>, not from >> >> > >>>> downloads... are the relevant files currently available from >> >> > >>>> checksums? >> >> > >>> I don't know if they are? I never had anything to do with the actual >> >> > >>> uploading of the files to anywhere on freenetproject.org. >> >> > >> >> >> > >> I do ... what files exactly do you need? Note that we may need to >> >> > >> change from https://checksums.freenetproject.org/latest/filename to >> >> > >> some other domain at some point, but we can hopefully do that by >> >> > >> changing the update scripts. >> >> > > >> >> > > Besides the wrapper .exe and .dll, we need at least the latest built >> >> > > freenerlauncher.exe to be available, so that we can >> >> > > add/remove/update/reprioritize browser support. >> >> > > >> >> > > - Zero3 >> >> > >> >> > I'm working on the update.cmd script handling these binaries... it >> >> > seems the .sha1 of all of these files is blank on the website. The >> >> > wrappers, start.exe, stop.exe and the freenetlauncher.exe. I'll need >> >> > that fixed please to continue my work ;-) >> >> >> >> Will fix before releasing next stable build. Sorry. >> >> >> > Sorry, these are uploaded manually at the moment. The sha1's have been >> > fixed for now. >> >> Thanks! > > I have reviewed your recent changes to master. Two quibbles: > - We need to check the sha1 when downloading the tray utility for the first > time.
We do: ::Get the tray utility and put it in the \bin directory ::We don't need to exit the program because it's not running since it's not even installed. echo - Downloading freenettray.exe ..\bin\wget.exe -o NUL -c --timeout=5 --tries=5 --waitretry=10 http://downloads.freenetproject.org/alpha/installer/freenettray.exe -O freenettray.exe Title Freenet Update Over HTTP Script if not exist freenettray.exe goto error3 FOR %%I IN ("freenettray.exe") DO if %%~zI==0 goto error3 java -cp ..\lib\sha1test.jar Sha1Test freenettray.exe . ..\%CAFILE% > NUL if %ERRORLEVEL% NEQ 0 goto error4 Title Freenet Update Over HTTP Script ::Copy it to the /bin folder copy /Y freenettray.exe ..\bin\freenettray.exe > NUL if not exist ..\bin\freenettray.exe goto unknownerror ::Offer to install freenettray.exe in the all users>start folder When we run sha1test.jar it puts the .sha1 file in the folder for comparison next time around. > - Typo copying wrapper.exe.sha1 when we should be copying wrapper.dll.sha1: Nice catch! Fixed in 2377ccf2 _______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
