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.
- Typo copying wrapper.exe.sha1 when we should be copying wrapper.dll.sha1:
+::Wrapper .dll
+if %WRAPPERDLLUPDATED%==0 goto wrapperdllcopyend
+copy /Y wrapper-windows-x86-32.dll ..\lib\wrapper-windows-x86-32.dll > NUL
+::Prepare .sha1 file for next run.
+if exist wrapper-windows-x86-32.exe.sha1 del wrapper-windows-x86-32.exe.sha1
+if exist wrapper-windows-x86-32.exe.sha1.new ren 
wrapper-windows-x86-32.exe.sha1.new wrapper-windows-x86-32.exe.sha1
+echo    - Copied updated wrapper dll
+:wrapperdllcopyend

Rough changelog:
Wininstaller: master changes:
- Work better with service problems.
- Copy files so can be uploaded when build it.
- Update script: (juiceman)
-- version 3.4
-- Rename variables.
-- Rename labels.
-- Refactor generally.
-- Missing quote marks.
-- Check for updater update earlier on.
-- create update_temp dir, use it for downloads.
-- refactor, do everything in update_temp, don't need to keep .new.bak's, 
simplify.
-- delete old stuff that should be in update_temp, or move it there.
-- EXTJARUPDATED flag, like MAINJARUPDATED.
-- if freenet-ext.jar.new in wrapper.conf, delete the old one.
-- backup changes
-- move code around
-- detect silent failure to downloads sha1test.jar
-- beginnings of support for updating wrapper exe, wrapper dll, start exe, stop 
exe, tray utility, launcher.
-- code (currently skipped) to offer to install the tray utility if the 
prerequisites are present.
-- ******** c98aa97aa8ddae7f7d4851235e4184d63df25c32 - when we download the 
tray exe for the first time, we don't check the sha1?
-- cacls fix.
-- simplify moving files, sha1's.
-- backup all files.

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
Devl mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to